La réécriture de 40 000 lignes de Fortran par Mistral montre où l'autonomie des agents atteint ses limites

40 000 lignes sur 300 000, pour un client que personne ne peut vérifier

L'équipe Applied AI de Mistral affirme avoir migré 40 000 lignes de Fortran 77 vers C++ pour un opérateur énergétique européen, premier sprint d'un chantier de 300 000 lignes sur un simulateur de réservoir à forte intensité physique. L'entreprise a publié la méthode dans un article qui sert aussi de discours de recrutement pour cette même équipe.

Presque tout ce qui concerne le client en reste absent. Pas de nom, pas de pays, pas de code, pas de coût. Ce que l'article dit, en revanche, c'est que le simulateur n'avait ni suite de tests ni documentation centralisée, et que les ingénieurs réservoir du client ont examiné l'architecture cible.

Le Fortran 77 a été normalisé en 1977, et ses contraintes déterminent ce qui doit changer. Il n'y a ni modules, ni espaces de noms, ni types structurés. L'état du programme réside dans des blocs COMMON, une mémoire globale partagée par l'ensemble du programme. Les variables sont typées implicitement par leur première lettre, si bien qu'un nom mal orthographié crée silencieusement une nouvelle variable au lieu d'échouer à la compilation. Les noms sont limités à six caractères. Le volet C++ a également dû intégrer des frameworks modernes de calcul scientifique tels que PetSc.

La première tentative a produit du Fortran retapé en C++

La partie la plus utile de l'article est celle où la première tentative échoue. Mistral a confié une sous-routine Fortran à chaque agent et les a laissés travailler indépendamment pendant une semaine. Le résultat s'exécutait. Ce n'était pas de la modernisation. Les blocs COMMON se sont transformés en structures globales en correspondance un pour un, et le flux de contrôle piloté par GOTO a survécu intact au lieu d'être restructuré en boucles ou en retours anticipés. Selon la description de Mistral elle-même, le résultat ressemblait à du Fortran retapé en syntaxe C++.

Une deuxième tentative a ajouté de la structure : un planificateur, un codeur, un testeur et un relecteur de qualité de code travaillant ensemble sur chaque module. La qualité s'est nettement améliorée. Puis la complexité du code source a rattrapé les agents, qui tombaient sur un bug, tentaient quelques correctifs et se bloquaient, sans personne pour les débloquer.

Ce qui a été livré est un compromis : un humain pilotant un flux de travail d'agents codeurs, testeurs et relecteurs, migrant module par module et intervenant lorsque la boucle se grippait.

La parité numérique est le véritable livrable

Avant d'écrire le code de migration, Mistral a construit ce qu'il appelle un harnais de parité. Les agents ont instrumenté le Fortran pour exporter des instantanés d'état à des points que les ingénieurs réservoir du client avaient signalés comme critiques, et un framework de test C++ chargeait ces points de contrôle et les comparait aux modules migrés. Des fichiers Skill.md indiquaient aux agents comment utiliser correctement le harnais.

Un exemple tiré de l'article : une ligne a été insérée dans le Fortran pour exporter la valeur de RHOG, 42,71834 lors de cette exécution. Ce même chiffre est devenu le point de contrôle de référence pour le module C++. L'égalité entre les deux est peu coûteuse à vérifier et difficile à contester, raison pour laquelle Mistral soutient que le harnais doit se situer au début d'une mission de modernisation, et non à la fin.

La documentation avant la délégation

La seconde condition préalable est moins glamour et, selon Mistral, l'un des plus grands gains annexes du projet. La documentation était dispersée dans de vieux PDF et enfouie dans les commentaires Fortran. Parce que le code procédural peut être représenté comme un unique arbre appelant-appelé, l'équipe a analysé la base de code avec un parseur maison, puis a utilisé Vibe CLI pour lancer plus d'une centaine d'agents chargés de la documenter, en récupérant les PDF pertinents via des bibliothèques de documents et Mistral OCR.

Le travail a commencé aux feuilles de l'arbre et a progressé vers le haut. Chaque nœud lançait un sous-agent qui le documentait et ouvrait une pull request sur le dépôt d'origine. Un agent relecteur tournait en boucle selon une planification cron, cherchait les nouvelles PR, les examinait et programmait des tâches de correction.

À quoi ne ressembleront pas les 260 000 lignes restantes

Mistral trace lui-même la frontière. Les 40 000 lignes constituaient une fonctionnalité centrale dans une base de code autonome et exécutable, avec une physique documentée quelque part, si mal que ce soit. Les migrations qui dépendent de systèmes externes, qui n'ont pas de base exécutable de référence ou qui encodent une physique que personne n'a consignée poseraient des problèmes que ce sprint n'a pas eu à résoudre.

Le flux de travail de livraison est plus étroit que « les agents font la migration ». Les modules ont été choisis comme des sous-arbres indépendants de taille gérable, empiriquement sous environ 10 000 lignes de Fortran. Chacun a suivi la même séquence : générer une architecture C++, la faire examiner par un ingénieur réservoir, découper la conception approuvée en une file de tâches, exécuter planification, implémentation et tests tâche par tâche, puis faire examiner les PR par un humain et demander des modifications jusqu'à leur fusion.

Trois règles résument l'article : construire le harnais de parité avant d'écrire le code de migration, mettre la documentation en ordre avant de s'appuyer sur les agents, et maintenir des points de revue humaine dans la boucle, puisque l'autonomie totale comme les sessions entièrement pilotées à la main ont perdu face à l'hybride. Cette dernière affirmation vient d'un fournisseur qui vend des missions d'Applied AI, et l'article ne comporte aucune comparaison avec d'autres pratiques de migration, aucun chiffre de précision au-delà d'une variable exportée, ni calendrier ni coût pour les 260 000 lignes restantes.