Il y a des chantiers dont on se dit qu’ils ne concerneront jamais une petite entreprise. La migration de quarante mille lignes de Fortran 77 vers du C++ menée par Mistral pour un opérateur européen de l’énergie est de ceux-là. Trop gros, trop technique, trop loin de votre quotidien. Sauf que la méthode employée tient en quelques principes que n’importe quel dirigeant peut s’approprier le jour où il faut faire bouger un vieux logiciel métier.
Qu’a fait Mistral, concrètement ?
Il faut d’abord planter le décor. Un opérateur européen du secteur de l’énergie utilisait un simulateur de réservoir très axé sur la physique, écrit en Fortran 77. Quarante mille lignes. Le programme avait été livré sans suite de tests et sans documentation centralisée : tout ce qui le faisait tenir vivait dans la tête des auteurs d’origine, et dans le code lui-même.
Mistral a repris ce chantier avec des agents IA. Concrètement, elle a reconstruit l’arbre des appels du programme avec un analyseur, c’est-à-dire la carte de qui appelle quoi à l’intérieur du logiciel. Puis elle a lancé plus de cent agents, via sa CLI Vibe, pour documenter chaque nœud de cet arbre. Le travail partait des feuilles pour remonter vers la racine, chaque agent ouvrant une proposition de modification sur le dépôt. Un agent relecteur, programmé en tâche planifiée, relisait les nouvelles propositions au fil de l’eau.
Pourquoi un vieux logiciel est-il si difficile à reprendre ?
Fortran 77 est un langage normalisé en 1977, sans modules ni espaces de noms. L’état partagé passe par des blocs COMMON, autrement dit de la mémoire globale accessible un peu partout. Le typage est implicite selon la première lettre du nom de variable : une faute de frappe ne provoque pas d’erreur, elle crée silencieusement une nouvelle variable. Et les noms sont limités à six caractères, donc cryptiques.
Ajoutez à cela que migrer un programme procédural vers du C++ orienté objet ne se résume pas à traduire la syntaxe. Il faut restructurer l’architecture. Dès que la structure change, il n’existe plus de correspondance ligne à ligne à vérifier. C’est précisément ce qui rend la reprise difficile : on ne peut pas contrôler le résultat en le posant à côté de l’original.
Qu’est-ce que ça change pour une TPE ?
Rien de direct. Ce chantier demandait des ingénieurs, un client, des mois de travail. Aucune petite entreprise ne va migrer un simulateur scientifique, et personne de sérieux ne prétendra le contraire.
Ce qui se transpose, c’est le principe : la preuve avant l’automatisation. Le jour où vous demandez à une IA de reprendre un fichier client d’un ancien logiciel vers un nouveau, de migrer des devis et des factures, de récupérer un historique de stock ou d’extraire les données d’un vieil outil sans export propre, la première question n’est pas de choisir une IA. C’est de savoir comment vous vérifierez que rien n’a été perdu. Sans point de comparaison, personne ne peut répondre. Ni vous, ni l’IA.
Que faire avant de confier une reprise de données à une IA ?
Construire un banc de parité. Mistral l’a fait avant de lâcher ses agents, et c’est la leçon la plus transposable de tout le chantier. L’équipe a ajouté des sous-programmes qui exportaient l’état du programme Fortran, puis un cadre de test en C++ qui rechargeait ces valeurs comme points de contrôle. La parité voulait dire l’égalité numérique des sorties finales et de certains points intermédiaires critiques, choisis avec les ingénieurs du client.
Un exemple vaut mieux qu’un long discours : la valeur RHOG relevée à 42,71834 lors d’une exécution servait de référence pour tester le module C++ migré. Si le nouveau code retrouvait ce nombre, il était juste. Sinon, on le savait tout de suite.
Transposez. Avant de migrer vos clients, exportez un échantillon représentatif de fiches et notez ce qu’elles doivent contenir après la bascule. Avant de déplacer votre historique de factures, relevez le total encaissé d’une année, le nombre de lignes, les cas particuliers. Ces repères deviennent vos points de contrôle. Mistral décrit cet investissement comme clairement positif : il rend les longues exécutions d’agents plus sûres et donne une preuve simple à vérifier.
Comment avancer sans tout lâcher à une IA ?
Par étapes, et avec un humain qui garde la main. Mistral a essayé plusieurs niveaux d’autonomie avant de trouver le bon.
Première tentative : un agent par sous-programme, en autonomie complète pendant une semaine. Le résultat fonctionnait, mais ce n’était pas de la modernisation. Les blocs COMMON étaient devenus des structures globales à l’identique, et les sauts conditionnels, les fameux GOTO, étaient restés en place. Du Fortran réécrit avec une syntaxe C++.
Deuxième tentative : une équipe d’agents par module, avec un planificateur, un codeur, un testeur et un relecteur qualité. La qualité était nettement meilleure, mais les agents finissaient par se bloquer sur un bug, sans personne pour intervenir.
Compromis retenu : un humain pilote un petit ensemble composé d’un agent codeur, d’un agent testeur et d’un agent relecteur. La migration avance module par module. L’arbre des appels sert justement à isoler des blocs indépendants et de taille gérable, empiriquement moins de dix mille lignes de Fortran. Pour chacun : générer l’architecture C++ cible, la faire relire par un ingénieur du client, la découper en une file de tâches, puis dérouler planifier, implémenter, tester, recommencer.
Ce rythme, modestement transposé, ressemble à ceci. Un lot de cent fiches clients, pas dix mille. Vous regardez le résultat. Vous validez. Vous passez au lot suivant. Le jour où quelque chose dérape, un humain est là pour le voir.
Ce que vous pouvez retenir dès demain
Trois réflexes, sans dépendre d’un grand chantier. Construire la preuve de parité avant de laisser un agent travailler. Faire documenter l’existant, car un agent sait lire un vieux logiciel, repérer son arborescence de fonctions et ses fichiers mieux que personne n’a le temps de le faire. Avancer par petits lots, avec un point de contrôle humain, plutôt qu’en autonomie complète.
Un vieux logiciel métier n’est pas une fatalité. C’est souvent le cœur de votre activité, avec des années de données dedans. Le moderniser demande moins de courage que de méthode. À Auxerre comme dans le reste de l’Yonne, nous voyons des entreprises bloquées par un outil qu’elles n’osent plus toucher, faute de savoir ce qu’elles perdraient en le quittant. Ce doute se lève avec un peu de préparation.
Questions fréquentes
Question : Mistral a-t-il vraiment migré un logiciel avec des agents IA ?
Oui. Mistral a aidé un opérateur européen de l’énergie à migrer quarante mille lignes de Fortran 77 vers du C++. Le travail s’est appuyé sur des agents IA, encadrés par des ingénieurs.
Question : Ce type de projet est-il accessible à une petite entreprise ?
Non, pas tel quel. Le chantier demandait des ingénieurs et des mois de travail sur du code scientifique. En revanche, la méthode se transpose à des reprises plus modestes : migration d’un fichier client, de devis, de factures ou d’un historique de stock.
Question : Qu’est-ce qu’un banc de parité, en clair ?
C’est un ensemble de points de contrôle relevés avant la migration, puis comparés après. Si les mêmes valeurs se retrouvent de part et d’autre, on a une preuve que la reprise n’a rien perdu. Sans ces repères, personne ne peut l’affirmer.
Question : Faut-il laisser une IA travailler seule sur une migration ?
Non. Mistral a testé l’autonomie complète : le résultat fonctionnait, mais gardait la structure d’origine sans vraie modernisation. Le compromis retenu associe un humain à un agent codeur, un agent testeur et un agent relecteur, module par module.
Question : Par où commencer concrètement ?
Par l’étape qui coûte le moins : faire lire et documenter le vieux logiciel, noter ce qui doit absolument se retrouver après la bascule, puis avancer par petits lots avec une validation humaine entre chaque.
Envie d’avancer sur votre propre cas ?
La maquette gratuite DSR vous montre à quoi ressemble une première étape concrète, sans engagement : https://dsr-agency.com/configurateur-maquette