Migrer dans un monde d'IA : le modèle lit le code, vous faites la migration

Un fournisseur met un modèle génératif sur un morceau de COBOL vieux de trente ans et le laisse expliquer en direct ce que fait le code. Dans la salle, tout le monde acquiesce. Ce qui reste, c'est un sentiment : la migration que vous reportez depuis des années semble soudain une affaire de mois. C'est là que les choses commencent à déraper.

Le modèle n'a rien fait de mal. Il a lu le code plus vite qu'un humain et l'a résumé correctement. Le problème réside dans le saut que fait la salle, de « l'IA comprend le code » à « l'IA fait la migration ». Ces deux choses sont très éloignées l'une de l'autre, et c'est dans cet écart que la plupart des projets succombent.

Ce que l'IA fait réellement dans une migration

Commençons par ce qui est juste. Migrer un ancien système signifie d'abord comprendre ce qui existe, et c'est souvent la partie la plus difficile. Les personnes qui ont écrit le code sont à la retraite, la documentation est un dossier de captures d'écran, et les règles métier sont cachées dans une procédure que plus personne n'ose toucher. Un modèle qui parcourt ce code et en produit une explication lisible vous fait gagner des semaines. C'est un travail qui rapporte déjà aujourd'hui.

Il y a d'autres endroits où cela aide. Il cartographie un modèle de données et compare les champs entre l'ancien et le nouveau système. Il écrit des tests qui prouvent qu'un nouveau module donne la même réponse que l'ancien. Des tâches où l'IA accélère le travail lent et où un humain garde le cap. Utilisez-les, elles se rentabilisent d'elles-mêmes.

Notez ce que ces tâches ont en commun. Elles vous aident à comprendre le code et à vérifier le résultat. Le choix de la règle métier que vous supprimez et le jugement de savoir si vous pouvez basculer aujourd'hui, cela reste l'affaire d'un humain. Cette distinction paraît minime et elle détermine si votre migration réussit.

Là où la promesse bascule

Gartner a regardé les projets qui vont le plus loin, les entreprises qui veulent quitter complètement leur mainframe. La prévision de juin 2026 est tranchante. Plus de 70 % des projets de sortie de mainframe lancés en 2026 n'atteignent pas les bénéfices visés, et la raison que cite Gartner est une surestimation de ce que l'IA générative peut faire. La technique fait souvent ce qu'elle promet. C'est le postulat en dessous qui coince, celui d'un modèle qui reprend le gros du travail.

Pourquoi cela tourne-t-il ainsi ? Un modèle qui convertit du code produit quelque chose qui a l'air correct et qui fonctionne le plus souvent. Le plus souvent. Les exceptions se logent dans les cas limites qui rendent votre entreprise unique : le client au contrat atypique, l'écriture qui court sur deux exercices, la remise qui n'est autorisée qu'une fois par an. Là, le code généré donne une réponse plausible qui est juste erronée, et personne ne le remarque jusqu'à ce qu'un client appelle. Qui confie la migration au modèle perd précisément la connaissance qui fait la différence.

Le risque diminue par la méthode, pas par le modèle

Ce qui rend une migration sûre n'est ni nouveau ni palpitant. Vous découpez le travail en morceaux et vous placez derrière chaque morceau un go ou no-go. Si le premier module fonctionne pour de vrai, avec de vraies données et de vrais utilisateurs, alors vous construisez le suivant. S'il ne fonctionne pas, vous vous arrêtez avant de vous enfoncer davantage. C'est ainsi que nous construisons par vagues avec une décision à chaque étape, et cette décision est l'affaire des humains. Un modèle peut mettre les options sur la table, mais c'est vous qui tranchez.

Il y a une deuxième règle qui va de pair. L'ancien système continue de tourner jusqu'à ce que le nouveau fasse ses preuves. Pas de vendredi où vous débranchez l'ancien pour espérer le lundi que le nouveau tienne. Vous faites tourner les deux en parallèle un certain temps, vous mettez leurs résultats côte à côte, et vous ne basculez que lorsque les chiffres concordent. Cette exécution parallèle est lente et ennuyeuse, et c'est la raison pour laquelle vous dormez la nuit.

Le big-bang reste la voie la plus coûteuse

Les chiffres sur les grands projets ne se sont pas améliorés. McKinsey a étudié, avec l'Université d'Oxford, des projets IT de plus de 15 millions de dollars. En moyenne, ils dépassaient le budget de 45 % et livraient 56 % de valeur en moins que promis. Dans 17 % des cas, cela tournait si mal que la survie de l'entreprise était menacée. Cette étude date de 2012, bien avant la vague actuelle de l'IA, et c'est justement ce qui la rend utile. Elle montre le risque fondamental d'une migration sans qu'un modèle vienne colorer les chiffres.

L'IA ne fait pas pencher ces probabilités en votre faveur tant que vous ne changez pas l'approche. Un big-bang avec un modèle de langage en dessous reste un big-bang. Générer du code plus vite pour le mettre en production d'un seul coup signifie surtout que vous arrivez plus vite au bord de la falaise. Un modèle qui écrit le code laisse en grande partie subsister les 17 % de l'étude. Ils se déplacent tout au plus vers un autre type d'erreur, une que vous ne voyez que lorsque le nouveau système tourne déjà.

Le code en propriété et les standards ouverts rendent chaque étape contrôlable

Vous ne pouvez prendre un go ou no-go par étape que si vous voyez ce qui se passe. Cela demande deux choses. Le code se trouve dès le premier jour dans votre propre dépôt, pour que vous et votre équipe puissiez lire chaque modification, et pas seulement le fournisseur. Et la stack tourne sur des standards ouverts, pour que vous puissiez inspecter les données et les systèmes sans demander la permission. Notre plateforme est bâtie là-dessus : votre code, vos données, une stack standard que vous exploitez vous-même et pouvez transférer. Sans cette propriété, chaque contrôle est une question de confiance dans ce que le fournisseur vous raconte.

Changer de fournisseur est par ailleurs plus facile qu'il y a trois ans. L'EU Data Act, le règlement (UE) 2023/2854, oblige les fournisseurs de cloud depuis le 12 septembre 2025 à offrir des possibilités de changement et à réduire les frais de migration. En 2024, Google Cloud puis AWS ont supprimé les frais d'egress pour qui quitte le cloud, notamment sous la pression de cette même loi. Le prix pour quitter un système qui ne vous convient pas baisse. Qui planifie sa migration en morceaux utilise ce seuil plus bas au lieu de l'ignorer.

D'abord cartographier le processus, ensuite l'outil

Avant de lâcher un modèle sur votre legacy, il y a une étape qu'aucune IA ne fait pour vous : déterminer ce que le système actuel doit vraiment continuer à pouvoir faire, et ce qui peut disparaître. Un audit établit cela, avec les règles métier et les flux de données, avant qu'un seul module ne soit construit. Ce n'est qu'ensuite que vient la question de l'outil que vous employez, et là l'IA est l'un des plus pratiques dont vous disposez.

Dans les années à venir, l'IA deviendra meilleure pour lire l'ancien code et écrire les tests, et c'est une bonne nouvelle pour quiconque doit migrer quelque chose. Là où se situe le risque ne change pas : dans la bascule elle-même, dans les cas limites, dans le moment où vous osez éteindre l'ancien. Cela reste l'affaire des humains, par morceaux, avec une issue à chaque étape. Utilisez l'IA pour le travail qu'elle sait faire, et laissez la décision aux personnes qui en portent les conséquences.