GitHub vient de mener l’une des expériences les plus concrètes à ce jour sur ce que peut réellement accomplir le développement assisté par agents IA à grande échelle. L’entreprise a réécrit en Rust le runtime partagé qui alimente une grande partie de GitHub Copilot, produisant 832 378 lignes de code Rust en production, auxquelles s’ajoutent plusieurs centaines de milliers de lignes de tests.
Le projet aurait coûté environ 120 000 dollars en tokens IA et trois semaines de travail concentré d’un développeur. Mais son intérêt dépasse largement cette économie : certaines charges sont désormais exécutées jusqu’à 15,9 fois plus rapidement, tandis qu’un test avec dix clients a vu la consommation mémoire passer de 1 383 à 126 Mo. Une démonstration impressionnante, mais qui rappelle aussi une limite essentielle : les agents peuvent écrire énormément de code, pas encore garantir seuls qu’il fonctionne correctement.
Le runtime de GitHub Copilot était devenu trop lourd pour son propre écosystème
À l’origine du projet se trouve un problème d’architecture devenu de plus en plus visible à mesure que Copilot s’étendait à de nouveaux produits. Le runtime historique était développé en TypeScript autour de Node.js et du moteur V8. Cette architecture convenait aux premières versions du service, mais devenait contraignante lorsqu’il fallait intégrer Copilot dans des environnements développés en C#, Python, Java ou d’autres langages.
Chaque intégration devait notamment lancer un processus Node.js séparé. Les communications entre les différentes briques traversaient ensuite les frontières de processus via JSON-RPC, y compris pour des événements et opérations sur les fichiers. Les conséquences s’accumulaient : démarrage plus lent, consommation mémoire élevée, latence supplémentaire et isolation imparfaite lorsqu’un composant rencontrait un problème.
L’enjeu était d’autant plus important que ce runtime ne constitue pas une expérimentation périphérique. Il se trouve au centre de GitHub Copilot, de son application, de son outil en ligne de commande, du SDK décliné dans six langages, des extensions VS Code et Visual Studio ainsi que de plusieurs intégrations dans Excel, Outlook et PowerPoint. Il prend également en charge l’agent Copilot exécuté dans le cloud.
GitHub avait donc besoin d’un runtime plus léger, prévisible et surtout beaucoup plus facile à embarquer directement dans des applications développées avec des technologies différentes.
La réponse a été Rust.
832 378 lignes de Rust largement produites par les agents Copilot
Plutôt que de confier cette migration à une importante équipe pendant plusieurs mois, GitHub a décidé d’utiliser ses propres outils d’intelligence artificielle pour réaliser l’essentiel du portage.
Stephen Toub, l’ingénieur ayant piloté le projet, s’est appuyé sur Copilot et Copilot CLI pour convertir progressivement le runtime TypeScript en Rust. Les agents exploraient le code existant, identifiaient les dépendances, réalisaient les modifications et ouvraient leurs propres pull requests, ensuite examinées par des humains avant leur intégration.
Le résultat donne une idée de l’échelle atteinte : 832 378 lignes de Rust destinées à la production, sans compter plusieurs centaines de milliers de lignes supplémentaires consacrées aux tests.
GitHub n’a toutefois pas tenté une réécriture massive en une seule opération. Chaque pull request remplaçait progressivement un composant TypeScript par son équivalent Rust derrière une fine couche de compatibilité. Une fois la nouvelle implémentation suffisamment stable, l’ancienne disparaissait dans le même changement.
Cette approche incrémentale a permis au produit de continuer à évoluer pendant la migration. Sur une période de 14,5 semaines, GitHub a livré 135 versions, tandis qu’environ 1,3 pull request liée au portage était fusionnée chaque jour.
L’intérêt de cette méthode tient autant à la continuité qu’à la vitesse. Il n’y a pas eu de grand basculement obligeant l’entreprise à figer pendant des mois une branche entièrement réécrite avant de remplacer l’ancien système. Le nouveau runtime s’est progressivement substitué à l’ancien pendant que Copilot continuait à recevoir de nouvelles fonctionnalités.
Jusqu’à 15,9 fois plus rapide et presque onze fois moins de mémoire
Les gains obtenus montrent pourquoi GitHub était prêt à entreprendre une migration aussi importante. La nouvelle bibliothèque Rust expose une ABI C limitée à seulement 19 fonctions, ce qui permet aux différents SDK de la charger directement à travers leurs interfaces FFI. Pour de nombreux scénarios, il n’est donc plus nécessaire de lancer un processus Node.js ni d’embarquer V8.
Dans un benchmark portant sur 1 000 cycles de sessions à un tour avec 100 pipelines concurrents, l’ancien système atteignait 7,55 cycles par seconde. L’exécution Rust directement intégrée est montée à 120 cycles par seconde, soit environ 15,9 fois plus. Certains tests de reprise de sessions comportant 32 tours ont enregistré une amélioration allant jusqu’à un facteur 21.
La différence est encore plus parlante du côté de la mémoire. Lors d’un test impliquant 10 agents clients, l’architecture TypeScript consommait 1 383 Mo, contre seulement 126 Mo avec Rust. Ces gains peuvent sembler secondaires sur un PC disposant de dizaines de gigaoctets de RAM, mais ils prennent une autre dimension lorsqu’un runtime doit être embarqué dans de nombreux produits ou exécuté à très grande échelle dans le cloud. Quelques dizaines ou centaines de mégaoctets économisés par instance peuvent alors modifier significativement le coût et la densité de déploiement.
La migration a également permis de supprimer environ 60 dépendances npm et de produire un composant natif plus facile à intégrer dans des environnements qui n’ont aucune raison d’embarquer Node.js.
136 milliards de tokens et environ 120 000 dollars de coût IA
L’un des aspects les plus révélateurs du projet reste son économie. GitHub estime avoir consommé 136,3 milliards de tokens pendant la migration. Ce chiffre spectaculaire doit cependant être remis dans son contexte : 96,22 % provenaient de prompts mis en cache.
Les nouvelles entrées représentaient environ 900 millions de tokens, auxquelles s’ajoutaient quelque 600 millions de tokens générés en sortie. Aux tarifs utilisés pendant le projet, GitHub estime la facture totale autour de 120 000 dollars. À cela s’ajoutent environ trois semaines de travail concentré pour l’ingénieur pilotant l’opération.
La comparaison avec une migration traditionnelle est évidemment difficile à réduire à une simple équation financière. Il faudrait prendre en compte la taille de l’équipe, son expérience en Rust, les tests, la revue, la maintenance et le coût du développement qui aurait été consacré à autre chose pendant la migration.
Mais l’ordre de grandeur reste significatif. Une réécriture de plus de 800 000 lignes d’un composant critique, intégré à de nombreux produits en production, aurait traditionnellement pu mobiliser plusieurs ingénieurs pendant une période beaucoup plus longue.
Les données de GitHub montrent également quelque chose d’intéressant sur le travail réellement réalisé par les agents. Ceux-ci ont passé beaucoup plus de temps à lire, rechercher et comprendre le code qu’à l’éditer. C’est peut-être l’un des enseignements les plus importants du projet. À grande échelle, coder avec une IA ne consiste plus simplement à générer rapidement des fonctions. Le principal problème devient la capacité de l’agent à comprendre un système suffisamment vaste pour savoir où intervenir sans casser ce qui l’entoure.
Le code compilait, mais cela ne voulait pas dire qu’il fonctionnait
Le projet constitue néanmoins un bon rappel des limites actuelles des agents de programmation. GitHub a rencontré des dizaines de régressions pendant la migration. Certaines ont nécessité des corrections manuelles, démontrant que la capacité d’un modèle à produire du code compilable ne garantit toujours pas un comportement correct en production.
Fait intéressant, le fameux vérificateur d’emprunts de Rust n’a pas constitué l’essentiel du problème. Selon Stephen Toub, les erreurs liées aux règles d’emprunt ne représentaient qu’une petite partie des problèmes signalés par le compilateur. Les erreurs de types et de noms étaient beaucoup plus courantes.
L’utilisation de code unsafe est également restée très limitée. Le binaire final compte 158 blocs unsafe répartis dans 36 fichiers, tous associés à l’interopérabilité avec des systèmes externes. Environ 32 % concernent les frontières de l’ABI C, tandis qu’une grande partie du reste est liée aux API Windows et aux appels POSIX.
Aucune des régressions connues n’a été attribuée à ces blocs. Le cœur du système — logique des agents, clients des modèles et gestion des prompts — reste quant à lui entièrement dans le périmètre sûr de Rust.
Cette expérience dessine donc une séparation assez nette des responsabilités. Les agents peuvent absorber une énorme quantité de travail répétitif, naviguer dans le code et accélérer considérablement une migration. Mais les tests, la revue et le jugement humain restent indispensables pour déterminer si le résultat peut réellement partir en production.
Microsoft fait de Rust un langage stratégique, et l’IA accélère la transition
Le calendrier donne une dimension supplémentaire au projet. Quelques jours avant la publication du retour d’expérience de GitHub, Microsoft a annoncé que Rust devenait un langage Tier 1 pour son développement interne, rejoignant C++, C# et TypeScript parmi ses technologies pleinement prises en charge.
Microsoft a développé sa propre infrastructure autour du langage, avec notamment un backend de génération de code pour rustc intégré à sa chaîne d’outils MSVC. Rust serait déjà utilisé dans plus d’une centaine de dépôts et dans différents composants de Microsoft 365.
Le choix du langage dépasse les seules performances. Rust s’est largement imposé dans l’industrie grâce à ses garanties de sécurité mémoire, alors que Microsoft a déjà indiqué qu’une part importante des vulnérabilités historiques de ses logiciels était liée aux problèmes de mémoire rencontrés dans du code C et C++.
GitHub apporte ici une autre pièce à cette stratégie : l’IA pourrait rendre économiquement envisageables des migrations qui auraient auparavant été jugées trop longues ou trop coûteuses. Cela ne signifie pas que chaque application TypeScript devrait être réécrite en Rust. Stephen Toub insiste lui-même sur ce point. Les contraintes du runtime Copilot étaient particulières : démarrage rapide, faible consommation au repos, ressources prévisibles, intégration dans de nombreux langages et réduction de la surface liée aux dépendances. Pour une application classique où ces contraintes n’existent pas, les avantages d’un langage managé peuvent largement justifier de conserver l’architecture existante.
GitHub ne considère d’ailleurs pas le travail comme terminé. Le portage a principalement permis d’établir une nouvelle fondation. Les prochaines étapes doivent revoir certaines structures de données, améliorer le système de compilation et surtout repenser davantage l’architecture autour du modèle de propriété de Rust plutôt que de conserver une traduction trop directe des structures TypeScript.
C’est là que pourrait se trouver la prochaine phase du développement assisté par IA. Les agents savent déjà convertir massivement du code existant. Le défi suivant sera de savoir s’ils peuvent contribuer avec la même efficacité à repenser profondément une architecture plutôt qu’à la traduire.
Le plus spectaculaire dans cette migration n’est finalement ni les 832 378 lignes de Rust ni les 136 milliards de tokens consommés. C’est qu’un projet autrefois jugé économiquement difficile est devenu suffisamment accessible pour être réalisé progressivement, sans interrompre le développement du produit. GitHub vient ainsi de montrer que les agents IA peuvent déjà changer l’économie d’une réécriture logicielle — tout en rappelant que produire le code et être responsable du code restent, pour l’instant, deux métiers très différents.
