GitHub a reconstruit le runtime qui sous-tend GitHub Copilot CLI, l’application Copilot et Copilot SDK, alors qu’il reposait auparavant sur TypeScript, Node.js et le moteur V8. Le résultat, selon l’article publié sur le blog de GitHub, représente plus de 800 000 lignes de Rust destinées à la production, dont la majeure partie a été réalisée avec l’aide d’agents d’intelligence artificielle au moyen de 128 pull requests intégrées progressivement à la branche principale.
L’auteur indique que le travail a été achevé en quelques mois, avec principalement la participation d’un seul développeur, tandis que le reste de l’équipe continuait à développer les capacités du runtime et à étendre son utilisation. GitHub affirme que les performances se sont améliorées « de manière significative » après la migration, sans fournir de chiffres détaillés dans la partie accessible de l’article pour mesurer cette amélioration.
Le problème ne concernait pas uniquement l’interface en ligne de commande
Le runtime de Copilot ne se limite pas à l’exécution de la CLI. Il s’agit d’une couche partagée utilisée par plusieurs éditions et produits, notamment GitHub Copilot CLI, l’application Copilot et Copilot SDK, ainsi que VS Code, Visual Studio, Cloud Agent, Copilot Code Review, Copilot Cowork, Copilot Studio et les applications Excel, Outlook, PowerPoint et Word.
Dans l’ancienne conception, le runtime et l’interface CLI étaient largement imbriqués. Lorsque les produits ont eu besoin d’un accès programmatique, le SDK a été construit en pratique par-dessus la CLI, avec l’exécution d’un processus Node.js distinct et une communication via JSON-RPC. Cette approche était rapide et flexible, mais elle imposait un coût opérationnel à chaque application cliente.
La création d’un nouveau CopilotClient impliquait de lancer un processus supplémentaire hébergeant Node.js et V8, d’analyser le code JavaScript généré à partir de TypeScript et d’assumer la mémoire associée au moteur. Les incidents provoquant l’arrêt de Node.js pouvaient également mettre fin à la session, tandis que les applications devaient surveiller au moins deux processus. Selon l’article, les packages SDK écrits en C#, TypeScript, Python, Rust, Go et Java consommaient environ 100 mégaoctets de l’ensemble de travail mémoire, au minimum, pour le runtime supplémentaire, même lorsqu’ils n’avaient besoin de Node.js pour rien d’autre.
Pourquoi Rust a-t-il été choisie ?
GitHub a défini des objectifs clairs pour la nouvelle couche : séparer le runtime de l’interface TUI, réduire les dépendances et les coûts opérationnels, permettre l’intégration au sein du même processus et améliorer l’évolutivité ainsi que la fiabilité. Il fallait également une interface C ABI permettant d’utiliser le runtime depuis les six éditions du SDK au moyen des différents mécanismes FFI.
L’article indique que Rust a contribué à répondre à ces exigences, tout en fournissant une chaîne d’outils prenant en charge une posture de sécurité plus moderne, une réduction des risques liés à la chaîne d’approvisionnement et un meilleur support du code correct par conception. Il souligne toutefois que cette expérience ne constitue pas une recommandation visant à convertir tout grand projet TypeScript en Rust : ce choix résultait d’exigences précises concernant le démarrage, la mémoire, l’intégration et la prévisibilité de la consommation des ressources.
Un remplacement progressif plutôt qu’une réécriture complète
GitHub n’a pas exécuté le projet au moyen d’une branche de longue durée ou d’une conversion unique à la fin du parcours. L’entreprise a choisi une approche au sein de la branche principale, dans laquelle chaque composant TypeScript était remplacé individuellement par un composant Rust. Chaque pull request ajoutait une fine couche de liaison appelant Rust et supprimait l’ancienne implémentation dans la même modification, de sorte que la branche reste livrable et que le nouveau code soit testé directement au sein du système.
- Le travail habituel des autres développeurs s’est poursuivi sans interrompre le projet.
- Chaque modification est devenue plus petite et plus facile à examiner qu’une réécriture complète.
- Les tests de bout en bout propres à la CLI et au SDK ont été exécutés à chaque étape.
- Les régressions ont été détectées et corrigées pendant la migration plutôt que reportées au moment de la conversion finale.
GitHub a également refusé de conserver longtemps deux versions parallèles de chaque composant. Le dépôt recevait des centaines de pull requests par semaine, et maintenir deux implémentations dans deux langages avec deux ensembles de dépendances aurait accru la complexité. La comparaison entre deux versions devient plus difficile dans les composants qui gèrent un état mutable, comme le formatage des sessions, car ils traitent des rappels et se connectent à de vastes parties du système.
Que révèlent les chiffres ?
L’estimation initiale, établie en mai 2026, portait sur environ 130 000 lignes de TypeScript, mais elle ne reflétait pas l’ampleur réelle du travail. Les composants qui avaient été comptabilisés dans la couche TUI ont ensuite été transférés vers le runtime, tandis que du nouveau code TypeScript continuait d’arriver parallèlement à la migration. Ainsi, environ 430 000 lignes de TypeScript ont effectivement fait l’objet du transfert.
Au cours de la même période, environ 300 000 lignes de production en TypeScript ont été ajoutées au projet et environ 430 000 ont été supprimées, tandis qu’environ 1 200 000 lignes de Rust ont été ajoutées et environ 365 000 supprimées. Ces chiffres montrent que la stabilité apparente du volume de TypeScript dans le dépôt ne signifiait pas une absence de progrès, mais masquait un mouvement important d’ajouts, de suppressions et de redistribution des responsabilités.
Pourquoi cette actualité est-elle importante ?
La valeur pratique de l’expérience ne réside pas uniquement dans l’utilisation de Rust, mais dans la manière de gérer la réécriture d’une couche fondamentale partagée par un grand nombre de produits. Le remplacement atomique de chaque composant, tout en maintenant une branche livrable et en exécutant continuellement les tests, réduit les risques d’une « grande conversion » et rend les retours en arrière ou la localisation des problèmes plus clairs.
En revanche, l’article ne démontre pas que cette approche convient à toute organisation, ni que les agents d’intelligence artificielle sont capables à eux seuls de garantir la qualité d’une réécriture de cette ampleur. La partie accessible ne fournit pas non plus de mesures publiées de la consommation avant et après, et ne précise pas le coût humain détaillé des revues, des tests ou du traitement des régressions. La leçon la plus claire concerne donc l’ingénierie progressive et la séparation des couches, plutôt que Rust ou les agents considérés comme une solution générale à toutes les migrations.