800 000 lignes de code réécrites avec l’IA : la migration logicielle est-elle en train de changer ?

La migration d’un grand système logiciel d’une technologie vers une autre a toujours été un processus coûteux, lent et présentant un risque élevé. Il ne s’agit pas simplement de traduire du code d’un langage de programmation vers un autre. Le comportement du système, ses intégrations, ses performances, sa sécurité et sa compatibilité avec les produits qui en dépendent doivent tous être préservés.

L’utilisation de l’Intelligence Artificielle modifie l’échelle à laquelle de tels projets peuvent être réalisés.

Le 16 septembre 2026, avec une mise à jour publiée le 23 septembre, GitHub a expliqué comment Copilot avait été utilisé pour réécrire son runtime de TypeScript vers Rust. Le résultat comprenait plus de 800 000 lignes de Rust utilisées en production et intégrées au moyen de 128 pull requests. Selon GitHub, la majeure partie du code a été écrite par des agents d’IA, tandis que la migration a été réalisée progressivement, et non par le remplacement complet du système en une seule opération.

Ce cas montre que la migration logicielle avec l’IA n’est plus uniquement une expérimentation portant sur de petits fragments de code. Les agents de programmation peuvent participer à la transformation de grands systèmes, mais le résultat continue de dépendre de l’architecture, des tests et de la supervision humaine.

La migration ne consiste pas simplement à traduire le code

Lorsqu’un système passe de TypeScript à Rust, le processus ne peut pas être réduit au remplacement d’une syntaxe par une autre.

Les deux langages possèdent des modèles d’exécution, des méthodes de gestion de la mémoire, des approches de traitement de l’état et des modes d’organisation des dépendances différents. Une fonction traduite peut produire le même résultat lors d’un test simple, mais se comporter différemment lorsqu’elle interagit avec d’autres composants.

C’est précisément pour cette raison que les migrations de grande ampleur nécessitent davantage que la simple génération de code. Il faut comprendre l’objectif de chaque composant, son contrat avec le reste du système et le comportement qui doit être préservé après la modification.

Les agents d’IA de programmation peuvent accélérer la production du nouveau code, mais ils ne suppriment pas la nécessité de comprendre le système existant.

Pourquoi GitHub a transféré le runtime vers Rust

Le runtime de GitHub Copilot avait initialement été conçu avec TypeScript, Node.js et le moteur V8. Cette architecture avait favorisé le développement rapide du produit, mais elle créait certaines limites lorsque le runtime devait être utilisé dans différents produits et environnements.

Selon GitHub, son utilisation par l’intermédiaire du SDK nécessitait le lancement d’un processus distinct qui exécutait Node.js et V8. Cela entraînait une consommation supplémentaire de mémoire, des communications entre processus et davantage d’éléments à surveiller.

Rust a été choisi pour créer un runtime comportant moins de dépendances, offrant une utilisation plus prévisible des ressources et pouvant être intégré directement dans des applications écrites dans différents langages.

Toutefois, cette décision ne signifie pas que toutes les applications TypeScript doivent migrer vers Rust. Le choix de la technologie doit être lié aux exigences concrètes du système, aux objectifs de la migration et au coût de maintenance à long terme.

Les agents d’IA rendent possible une autre échelle de travail

L’un des éléments les plus importants de ce projet est son ampleur.

La migration initiale avait été estimée sur la base d’environ 130 000 lignes de TypeScript, mais le système continuait à évoluer pendant que la migration était en cours. Au total, environ 430 000 lignes de TypeScript sont passées par ce processus, tandis que le nouveau runtime a atteint plus de 832 000 lignes de Rust utilisées en production.

Dans un projet traditionnel, une transformation de cette ampleur aurait pu nécessiter une grande équipe et une période beaucoup plus longue. GitHub explique que le travail a été réalisé principalement par un développeur en quelques mois, avec l’aide de GitHub Copilot et d’agents de programmation, tandis que le reste de l’équipe poursuivait le développement de nouvelles fonctionnalités.

Cela ne signifie pas que l’IA a réalisé la migration de manière indépendante. Les agents ont produit une grande partie du code, mais le projet nécessitait toujours une stratégie technique, un ordre précis pour le traitement des composants, des instructions claires et une vérification continue.

La migration progressive a réduit les risques liés au changement

GitHub n’a pas construit un nouveau système complet afin de remplacer l’ancien en une seule fois.

La migration a été réalisée composant par composant. Chaque pull request remplaçait une partie de l’implémentation en TypeScript par sa version correspondante en Rust. De cette manière, la branche principale du projet restait fonctionnelle et les nouvelles versions pouvaient être testées tout au long du processus.

Cette approche a rendu chaque modification plus limitée, plus compréhensible et plus facile à contrôler. Lorsqu’un problème apparaissait, il pouvait être associé à un ensemble restreint de modifications et corrigé sans devoir analyser l’ensemble de la migration.

Pour les grands projets, il s’agit de l’un des enseignements les plus importants. L’IA peut produire du code rapidement, mais les changements doivent être divisés en unités pouvant être examinées, testées et annulées si nécessaire.

Les tests deviennent le contrat définissant le comportement du système

Lorsque le code est réécrit dans un autre langage, la question principale n’est pas de savoir si la nouvelle version ressemble à l’ancienne. Il faut déterminer si elle conserve le même comportement.

Pour cette raison, les tests existants ont joué un rôle central dans la migration. Des tests de bout en bout ont été exécutés sur les nouveaux composants en Rust à chaque étape. Lorsqu’une modification ne respectait pas les exigences définies, elle n’était pas intégrée à la branche principale.

Dans la migration logicielle avec l’IA, les tests ne servent pas uniquement à détecter les erreurs. Ils fournissent à l’agent et à l’équipe une définition vérifiable du comportement qui doit être préservé.

Plus l’écriture du code est automatisée, plus la qualité des tests devient importante. Si les tests sont incomplets, le code généré peut passer les contrôles sans garantir que le système fonctionnera correctement dans des situations réelles.

Les régressions ne disparaissent pas simplement parce que le code est produit par l’IA

Au cours de la migration, des régressions liées à l’exactitude et aux performances ont été découvertes. Certaines ont été détectées pendant le développement, d’autres dans les versions préliminaires et certaines uniquement après que les modifications ont été déployées plus largement.

Cela montre que la génération rapide de code n’élimine pas les risques. Un agent peut créer une implémentation qui semble correcte, réussit une série de tests et modifie malgré tout le comportement du système dans un cas qui n’avait pas été anticipé.

La vérification doit donc inclure davantage que l’exécution automatique des tests. La revue du code, l’analyse des performances, la surveillance après la publication et des mécanismes permettant de relier les problèmes aux modifications qui les ont provoqués sont également nécessaires.

L’IA peut réduire le temps d’implémentation, mais la responsabilité de la qualité du système reste entre les mains de l’équipe qui conçoit et approuve la modification.

L’architecture doit être préparée à la migration

Avant que la partie la plus complexe du runtime ne soit traduite, le projet a été divisé en composants plus faciles à gérer.

Les éléments comportant une logique pure et aucun état partagé ont été traités en premier. Les composants les plus interdépendants, comme l’orchestration des sessions, ont été réservés aux étapes suivantes, après que les modèles d’intégration, de test et de communication entre TypeScript et Rust ont été validés.

Cela montre que la réussite d’une migration ne dépend pas uniquement de la capacité de l’IA à écrire du code. Elle dépend également de la manière dont l’architecture divise le système en parties pouvant être transformées sans interrompre l’ensemble du produit.

Un système doté de limites claires entre ses composants est plus facile à migrer, que le travail soit réalisé par des personnes ou avec l’aide d’agents d’IA.

La vitesse de programmation n’est pas identique à la vitesse de migration

Les agents d’IA peuvent produire rapidement une grande quantité de code. Cependant, une migration ne se termine que lorsque le nouveau code a été testé, intégré, publié et validé dans des conditions réelles d’utilisation.

Si la génération progresse plus rapidement que la capacité de l’équipe à contrôler les modifications, un nouveau goulot d’étranglement apparaît. La revue du code, les tests et l’analyse des régressions peuvent devenir les parties les plus lentes du processus.

Cela signifie que la productivité ne doit pas être mesurée uniquement selon le nombre de lignes produites. Elle doit être évaluée en fonction des composants migrés de manière sécurisée, des problèmes évités et des améliorations réelles apportées aux performances, à la maintenance et à la stabilité.

Dans ce modèle, l’IA augmente la capacité d’implémentation, tandis que le développeur doit préserver l’équilibre entre rapidité et fiabilité.

Le rôle du développeur se déplace vers la stratégie et la vérification

Dans une migration traditionnelle, une grande partie du temps peut être consacrée à la réécriture manuelle de fonctions et de structures répétitives.

Lorsque ce travail est assisté par des agents d’IA de programmation, le développeur peut se concentrer davantage sur l’ordre de la migration, la définition des limites architecturales, la sélection des tests et l’analyse des situations dans lesquelles les deux implémentations ne se comportent pas de la même manière.

Son rôle devient ainsi moins centré sur la production manuelle de chaque ligne de code et davantage orienté vers la direction de la transformation technique.

Toutefois, pour exercer ce rôle, le développeur doit comprendre le système en profondeur. Sans connaissances de l’architecture, des modèles d’exécution et des exigences du produit, il devient difficile de déterminer si le code généré est réellement approprié.

La migration avec l’IA exige une responsabilité documentée

Pour Soft&Solution Group, l’utilisation de l’IA dans les migrations de grande ampleur doit être accompagnée d’un processus clair de responsabilité.

Pour chaque composant, il faut savoir pourquoi il est migré, quelles instructions ont été données à l’agent, quels tests ont été utilisés, quelles modifications ont été approuvées et comment son comportement a été surveillé après la publication.

Cet historique documenté devient particulièrement important lorsque le code est généré à grande échelle. Sans traçabilité, l’équipe peut avoir des difficultés à comprendre pourquoi une décision a été prise ou quelle modification a provoqué un problème.

Comme l’explique Ermal Beqiri, fondateur de Soft&Solution Group :

« L’Intelligence Artificielle peut considérablement accélérer la réécriture d’un système, mais une migration ne se mesure pas au nombre de lignes produites. Elle se mesure au comportement préservé, aux problèmes évités et au niveau de confiance avec lequel le nouveau système est mis en production. L’agent peut écrire le code, mais l’architecture, le contrôle et la responsabilité doivent rester clairement définis. »

La réécriture du runtime de GitHub Copilot montre que les agents d’IA peuvent également être utilisés dans des transformations logicielles d’une ampleur qui aurait auparavant nécessité beaucoup plus de temps et de ressources.

Mais le principal enseignement n’est pas que l’IA peut produire 800 000 lignes de code. Il réside dans le fait qu’une telle migration devient possible lorsque l’automatisation est associée à une décomposition rigoureuse du système, à des tests continus, à des publications progressives et à une supervision humaine.

La migration logicielle avec l’IA ne supprime pas la complexité. Elle transforme la manière dont celle-ci est gérée.