Réécrire un runtime en Rust avec Copilot : ce que le chantier révèle vraiment

Réécrire un composant critique dans un autre langage n’est pas une simple opération de traduction. Il faut préserver des comportements, comprendre les dépendances implicites, contrôler les écarts et décider quand une partie du nouveau système peut remplacer l’ancien. Le sujet devient encore plus délicat lorsque l’outil qui aide à produire le code intervient lui-même dans le chantier.

Dans un billet publié le 17 septembre 2026, GitHub décrit la migration de son runtime d’agent Copilot vers Rust. Le texte présente un périmètre de 800 000 lignes de Rust de production et explique qu’une réécriture de cette taille n’était pas abordable avant l’arrivée des agents. Cette information constitue un signal important, mais elle ne suffit pas à conclure que l’opération est automatiquement rapide, sûre ou reproductible dans un autre dépôt.

Le cas GitHub : une réécriture devenue envisageable

Le point intéressant n’est pas seulement le choix de Rust. C’est le changement de seuil économique et opérationnel décrit par GitHub : un chantier auparavant trop coûteux peut désormais être engagé avec l’aide d’agents et de Copilot. Cela ne transforme pas la migration en tâche mécanique. Cela rend possible un investissement qui exige toujours une méthode de contrôle.

Le billet ne doit donc pas être lu comme la preuve qu’un assistant peut convertir n’importe quel runtime sans supervision. Il documente un cas précis, porté par l’équipe qui connaît le code, ses contraintes et son environnement. Pour une autre équipe, la bonne question devient : quelles preuves faudrait-il réunir avant de considérer une réécriture assistée comme acceptable ?

Une migration assistée n’est pas un benchmark

Un nombre de lignes produit attire immédiatement l’attention, mais il ne mesure ni la compatibilité fonctionnelle ni la qualité du résultat. Une réécriture peut avancer tout en laissant ouvertes plusieurs questions : les entrées et sorties sont-elles identiques ? Les erreurs sont-elles conservées ? Les performances ont-elles changé ? Les dépendances externes se comportent-elles de la même manière ? Les cas rares sont-ils couverts ?

La première discipline consiste à séparer trois niveaux qui sont souvent mélangés :

• la production de code, que Copilot ou un agent peut accélérer ;
• la compatibilité observée entre l’ancien et le nouveau runtime ;
• la décision de remplacement, qui appartient à l’équipe responsable du système.

Cette séparation évite de transformer une capacité de génération en preuve de fonctionnement. Elle rejoint une règle utile pour tout chantier de migration : le diff est un livrable, pas le verdict.

Le protocole à appliquer avant de basculer

Une équipe qui souhaite s’inspirer de ce cas peut commencer par construire un protocole de comparaison, sans prétendre reproduire le travail de GitHub. Le protocole doit exister avant la réécriture, sinon les critères risquent de se déplacer au fil des résultats.

1. Délimiter le contrat. Recenser les interfaces, les formats, les erreurs attendues, les effets de bord et les comportements qui doivent rester inchangés.
2. Choisir une tranche vérifiable. Éviter de confier d’emblée tout le runtime à l’agent. Une tranche doit pouvoir être compilée, exécutée et comparée isolément.
3. Conserver un oracle. L’ancienne implémentation sert de référence comportementale lorsque cela est possible. Elle ne dispense pas de définir les cas attendus, mais elle permet de détecter certains écarts.
4. Enregistrer les décisions. Chaque divergence doit être classée : bug du portage, différence volontaire, hypothèse non documentée ou comportement de l’ancien système à corriger.
5. Prévoir un arrêt. Une hausse du périmètre, une dépendance mal comprise ou une impossibilité de comparer doivent déclencher une pause plutôt qu’une nouvelle génération automatique.

Ce que l’agent peut accélérer, et ce qu’il ne tranche pas

Dans une réécriture, l’IA peut aider à naviguer dans un grand volume de fichiers, proposer des transformations répétitives, expliquer des symboles ou préparer des tests. Elle peut aussi réduire le coût de premières itérations. En revanche, elle ne décide pas seule si une différence de comportement est acceptable, si une abstraction doit être conservée ou si une incompatibilité impose de revoir l’architecture.

Le risque principal n’est pas une erreur spectaculaire. C’est l’accumulation de petites décisions plausibles : une conversion de type qui modifie une limite, une gestion d’erreur simplifiée, une dépendance remplacée par équivalence apparente ou un test qui reprend l’implémentation au lieu de vérifier le contrat.

Une anecdote hypothétique : le portage qui passe les tests

Imaginons une équipe qui demande à Copilot de réécrire un module de traitement en Rust. La compilation réussit et les tests existants passent. Lors d’une comparaison plus fine, l’équipe découvre que les tests couvrent surtout les cas nominaux : une entrée vide, une erreur de dépendance et une séquence longue n’ont jamais été décrites. Le portage n’est pas nécessairement mauvais. La preuve disponible est simplement trop étroite pour justifier une bascule.

Dans ce scénario hypothétique, la bonne réaction n’est pas de relancer l’agent avec une instruction plus longue. Il faut enrichir le contrat, ajouter les cas manquants et décider si l’ancien comportement était voulu. L’IA peut ensuite contribuer à l’implémentation et à la préparation des tests, mais la définition de la preuve reste humaine.

Le coût réel se déplace vers la validation

Le billet de GitHub affirme qu’une réécriture de cette ampleur n’était pas abordable avant les agents. Cette formulation parle d’abord de faisabilité du chantier, pas d’une disparition du travail d’ingénierie. Plus la production de code devient accessible, plus la capacité de revue, d’exécution et de comparaison devient déterminante.

Une équipe doit donc suivre autre chose que le volume généré : le nombre de tranches réellement vérifiées, les divergences expliquées, les tests ajoutés pour couvrir les angles morts et les points où une décision humaine a été nécessaire. Sans ces traces, le gain apparent peut simplement correspondre à une dette de validation reportée.

Pour approfondir cette logique, la méthode consacrée au code legacy modernisé avec l’IA par petites étapes fournit un cadre adjacent, sans traiter le cas particulier du runtime de Copilot. La question n’est pas de copier un plan, mais de conserver le principe : caractériser, réduire le périmètre, comparer le comportement et garder un retour arrière.

Ce que cette étude de cas permet raisonnablement de retenir

Le cas GitHub montre qu’un agent peut modifier l’économie d’un chantier de réécriture très vaste. Il ne prouve pas qu’une migration Rust est sûre par défaut, ni qu’un autre projet obtiendra le même résultat. Pour une équipe développeur, la leçon opérationnelle est plus précise : investir dans la génération n’a de sens que si le protocole de validation grandit avec le périmètre.

Avant toute bascule, il faut donc pouvoir répondre à quatre questions : quel contrat doit rester stable ? Quelle partie est réellement comparable ? Quelle divergence est acceptable ? Comment revenir à l’ancienne implémentation ? Si ces réponses restent floues, le chantier doit rester une expérimentation encadrée, pas une migration considérée comme acquise.

La méthode de test reproductible pour comparer des agents de code peut compléter ce cadrage lorsqu’il faut comparer des outils ou des configurations. Elle ne remplace pas les tests propres au runtime, mais aide à éviter les jugements fondés sur une démonstration isolée.