Moderniser 40 000 lignes de Fortran avec des agents IA : la méthode de Mistral

Le piège de la traduction brute ligne à ligne

Pour faire évoluer un simulateur de réservoir de 40 000 lignes de Fortran 77 (première étape d'un projet de 300 000 lignes) sans tests ni documentation centralisée, la traduction syntaxique directe ne suffit pas. Le Fortran 77 utilise des variables globales partagées appelées blocs COMMON (mémoire globale partagée à travers tout le programme) et un typage implicite basé sur la première lettre du nom des variables.

Si un agent d'IA (un programme autonome piloté par un modèle) bénéficie d'une autonomie totale sans cadre précis, il se contente de réécrire le Fortran en syntaxe C++ : les blocs COMMON deviennent des structures globales et les instructions de saut GOTO restent inchangées. Pour obtenir un code C++ orienté objet et propre, la structure globale doit être entièrement réarchitecturée.

double gasDensity (const GasProperties &gas, double pressure) {
    size_t i = lookup (gas.pressure, pressure);
    return gas.density[i] + gas.slope[i] * (pressure - gas.pressure[i]);
}

Valider la parité numérique avant de migrer

Avant de confier la réécriture aux agents, l'équipe a bâti un harnais de parité (un système de tests comparatifs) pour garantir que le nouveau code produit des résultats numériques strictement identiques à l'ancien.

• Export d'état : Ajout de sous-programmes dans le code Fortran pour exporter les états et variables intermédiaires (comme la valeur RHOG fixée à 42,71834 lors des essais).
• Cadre de test C++ : Mise en place d'un système pour charger ces points de contrôle et valider la précision du code modernisé.
• Fichiers de consignes : Utilisation de fichiers Skill.md (fichiers d'instructions pour guider les agents) afin de leur apprendre à exécuter eux-mêmes ces tests de parité.

« L'accord numérique est la preuve la plus économique et la plus convaincante qu'un module est achevé. »

Cartographier et documenter la base de code

Le projet ne disposant pas de documentation centralisée, l'équipe a analysé le code pour construire un arbre d'appels (une carte représentant la hiérarchie des fonctions qui s'appellent entre elles).

Via Vibe CLI (un outil d'interface en ligne de commande), plus de 100 agents ont été lancés en parallèle. En partant des fonctions de base pour remonter vers la racine, chaque agent documentait un composant en s'appuyant sur des documents PDF analysés par Mistral OCR (outil de reconnaissance optique de caractères). L'agent ouvrait ensuite une PR (Pull Request, une proposition de modification de code). Un agent réviseur tournait en tâche automatique planifiée (cron) pour relire ces propositions et demander des ajustements.

Trouver le bon niveau d'autonomie pour les agents

L'équipe a expérimenté trois configurations pour la phase de modernisation du code :

• Autonomie complète : Un agent dédié par sous-programme. Le résultat était fonctionnel mais conservait la structure obsolète d'origine.
• Équipe d'agents spécialisés : Un agent planificateur, un codeur, un testeur et un réviseur. La qualité s'est améliorée, mais les agents finissaient par bloquer en boucle sur des bogues complexes.
• Workflow hybride structuré : Le code est découpé en modules de moins de 10 000 lignes. Une chaîne d'agents (planification, implémentation, test) travaille sous la supervision d'un ingénieur humain qui valide les PR et débloque les situations complexes.

Cette approche démontre que des workflows structurés avec des étapes de validation humaine surpassent l'autonomie totale pour convertir du code historique complexe.