Un logiciel ancien peut continuer à rendre de précieux services tout en devenant difficile à faire évoluer. Les modifications prennent du temps, la documentation est incomplète et certaines règles métier ne sont connues que d’un développeur ou d’un collaborateur expérimenté.
L’intelligence artificielle ouvre des possibilités pour analyser cet existant et accompagner sa transformation. Encore faut-il organiser le travail pour préserver ce qui fait fonctionner l’entreprise.
Un retour d’expérience publié par Mistral le 9 septembre 2026 illustre cette difficulté. Il permet surtout de poser une question utile aux dirigeants : comment utiliser l’IA pour moderniser un logiciel tout en gardant la maîtrise du résultat ?
Article préparé le 9 octobre 2026.
Ce que Mistral a réellement modernisé
Mistral rapporte avoir accompagné un opérateur européen de l’énergie dans la migration d’un simulateur de réservoir, de Fortran 77 vers C++. Le premier sprint a couvert 40 000 lignes sur une base de 300 000 lignes, initialement dépourvue de suite de tests et de documentation centralisée. Le logiciel existant était néanmoins exécutable et autonome, ce qui facilitait les comparaisons.
L’équipe a préparé des vérifications des résultats numériques et utilisé des agents pour documenter le code. Elle décrit ensuite trois approches :
- des agents très autonomes ont produit une traduction conservant largement l’ancienne structure ;
- une organisation avec plusieurs rôles a amélioré le code, mais rencontré des blocages ;
- un travail par modules, avec des agents de développement, de test et de revue supervisés par un humain, a constitué le compromis retenu.
Ce retour d’expérience concerne donc une partie du logiciel et un contexte précis, plutôt qu’une réécriture intégrale réalisée sans supervision.
Commencer par définir le problème à résoudre
Avant de demander à une IA de modifier le code, il faut préciser le bénéfice attendu.
Une entreprise peut vouloir faciliter la maintenance, remplacer une dépendance vieillissante, améliorer un import de données ou rendre une application compatible avec un environnement plus récent. Ces objectifs ne demandent pas nécessairement la même intervention.
Le questionnaire de modernisation proposé par AWS invite justement à examiner la valeur métier de l’application, ses technologies, ses interfaces, ses données et ses contraintes d’exploitation avant de choisir une trajectoire.
Pour une PME, ce cadrage peut commencer par quelques questions :
- Quelle difficulté coûte réellement du temps à l’équipe ?
- Quelle fonctionnalité doit continuer à fonctionner pendant les travaux ?
- Qui peut confirmer que le résultat est correct ?
- Comment saura-t-on que la modernisation apporte une amélioration ?
Par exemple, « fiabiliser l’import des commandes fournisseurs » donne un objectif plus exploitable que « rendre notre application moderne ».
Retrouver les règles métier cachées dans l’existant
Une application ne se résume pas à ses fichiers sources. Son fonctionnement dépend aussi de ses données, de ses échanges avec d’autres outils et des habitudes de ses utilisateurs.
Prenons un exemple fictif : un import de commandes applique une règle particulière lorsqu’un fournisseur utilise une ancienne référence produit. Cette exception peut être peu visible dans le code, mais indispensable au travail quotidien.
Une première mission à confier à l’IA pourrait être :
Analyse uniquement le module d’import des commandes. Identifie les données d’entrée, les contrôles, les dépendances et les exceptions. Pour chaque règle décrite, indique le fichier ou la fonction qui la justifie. Signale les points incertains.
La documentation obtenue doit ensuite être confrontée aux pratiques réelles. Le développeur peut vérifier le cheminement technique ; l’utilisateur métier peut expliquer pourquoi une exception existe.
Cette étape évite de transformer une hypothèse de l’IA en règle officielle.
Définir les preuves de bon fonctionnement
Avant de modifier une fonctionnalité importante, il est utile de préparer des situations représentatives et leurs résultats attendus.
Pour un import, on peut sélectionner un fichier habituel, un fichier incomplet, une référence inconnue et une commande déjà enregistrée. Pour un calcul commercial, on peut comparer plusieurs combinaisons de remise, de quantité et d’arrondi.
L’IA peut aider à écrire des tests. GitHub souligne toutefois que les tests générés peuvent manquer certains scénarios et doivent être relus et complétés.
Le résultat attendu doit venir d’une référence vérifiée, pas uniquement du nouveau code que l’on cherche à contrôler.
Il faut également traiter les anomalies découvertes. Si l’ancien logiciel comporte une erreur connue, la reproduire dans la nouvelle version ne constitue pas une réussite. Sa correction doit être décidée explicitement, documentée et testée.
Cette démarche rejoint notre guide pour construire une recette métier avant la mise en production d’une IA : les critères de validation doivent correspondre au travail réel.
Choisir un premier périmètre maîtrisable
Pour démarrer, nous proposons de sélectionner une fonctionnalité dont les entrées, les sorties et les dépendances sont suffisamment connues.
Un export, une recherche ou un traitement bien délimité peut constituer un meilleur pilote qu’une refonte simultanée de l’authentification, de la base de données et de toute l’interface.
Sur certains systèmes, une modernisation progressive permet de faire coexister l’ancien et le nouveau fonctionnement. Le modèle dit « strangler fig », décrit par AWS, repose sur le remplacement successif de fonctionnalités, avec un mécanisme d’orientation des appels et un retour arrière prévu. Cette architecture demande toutefois un système qui s’y prête ; elle peut être disproportionnée pour une petite application simple.
Le principe à retenir pour le pilote est de limiter les changements simultanés afin de pouvoir comprendre et corriger un éventuel écart.
Encadrer les modifications proposées par l’IA
Une demande précise facilite la revue du travail. Elle peut indiquer le module concerné, le comportement attendu, les fichiers autorisés et les contrôles à exécuter.
Par exemple :
Modernise ce module d’export en conservant son format de sortie. Présente d’abord les modifications envisagées. N’ajoute pas de dépendance sans justification. Après modification, exécute les tests existants et explique les écarts éventuels.
GitHub recommande notamment de vérifier le fonctionnement, la cohérence avec l’architecture, la qualité du code et les dépendances proposées. Sa documentation attire aussi l’attention sur les tests supprimés ou ignorés et sur les API inventées par les outils d’IA.
Un compte rendu utile doit donc préciser les modifications effectuées, les vérifications réellement exécutées et les points restant à examiner.
Faire relire le résultat par une deuxième IA peut compléter ce dispositif. Pour approfondir cette question, consultez notre article sur les limites de l’évaluation automatisée par une autre IA.
Exemple : faire évoluer une ancienne application PHP
Imaginons une application PHP 7.4 que l’entreprise souhaite adapter à PHP 8.4. Cet exemple constitue une transposition pédagogique ; il ne correspond pas au projet Fortran présenté par Mistral.
Le manuel officiel de PHP fournit des guides de migration pour les différentes versions, avec les incompatibilités et les fonctionnalités dépréciées à examiner. Passer directement d’une ancienne version à la version cible demande de prendre en compte les changements intermédiaires pertinents.
Une démarche possible consiste à :
- reproduire le fonctionnement actuel dans un environnement de test ;
- inventorier les extensions et les bibliothèques utilisées ;
- vérifier les parcours métier importants ;
- identifier les incompatibilités ;
- corriger les modules progressivement ;
- comparer les résultats avant la bascule.
Il peut être judicieux de traiter d’abord la compatibilité, puis les améliorations d’architecture. Changer simultanément la version de PHP, le framework et les règles métier rendrait les écarts plus difficiles à expliquer.
Mesurer le résultat du pilote
Le nombre de lignes modifiées renseigne sur le volume de travail, mais peu sur le bénéfice pour l’entreprise.
Pour évaluer le pilote, nous proposons plutôt d’observer :
- les scénarios métier validés ;
- les anomalies introduites ou corrigées ;
- le temps consacré au développement et à la revue ;
- la facilité à comprendre et à modifier le module ;
- les difficultés rencontrées lors du déploiement.
Le bilan doit inclure le temps de préparation, de vérification et de correction. Il permettra de décider si la méthode mérite d’être étendue à d’autres fonctionnalités.
Moderniser avec une méthode adaptée à l’entreprise
Le cas Mistral apporte un retour d’expérience concret sur l’utilisation d’agents IA dans un projet exigeant. Pour une PME, sa valeur est d’alimenter une démarche de modernisation progressive, accompagnée de preuves vérifiables.
L’objectif reste de disposer d’un logiciel plus facile à maintenir et capable de répondre aux besoins de l’activité. Un premier module bien choisi permet d’évaluer les outils, l’organisation et les compétences nécessaires avant d’engager des travaux plus larges.
Dixie Consulting accompagne les TPE et PME dans l’identification et le cadrage de leurs usages de l’intelligence artificielle. Pour examiner un premier cas d’usage, contactez notre équipe.
Sources
Sources consultées le 9 octobre 2026.
- Mistral — Modernizing complex legacy code with AI agents, 9 septembre 2026.
- AWS — Questionnaire d’évaluation pour la modernisation d’applications.
- AWS — Modernisation progressive avec le modèle « strangler fig ».
- GitHub — Vérifier et valider du code généré par l’IA.
- GitHub — Écrire et compléter des tests avec Copilot.
- PHP — Guide de migration vers PHP 8.4 et accès aux guides des versions précédentes.
