Migration technique : ce que l’IA accélère vraiment, et ce qu’elle ne change pas

Une migration de code est rarement un projet qu’une équipe attend avec impatience. Elle ne crée pas de fonctionnalité visible, elle consomme des profils rares pendant des semaines, et elle expose à un risque que personne ne maîtrise complètement : casser un comportement métier que plus personne ne sait expliquer. C’est précisément là que se joue la question de l’IA. Non pas « l’IA va-t-elle faire la migration à notre place », ce qui est faux et trompeur, mais « sur quelles tâches précises déplace-t-elle réellement le curseur, et lesquelles restent du ressort de l’expertise humaine ». Cet article reprend le fond du webinar que nous avons animé le 12 février 2026.

La migration n’est pas un problème technique, c’est un problème de risque

Vue de l’équipe de développement, une migration ressemble à un travail de traduction : faire passer un codebase d’une version, d’un langage ou d’un framework à un autre. Vue du décideur, c’est autre chose. C’est un arbitrage entre quatre enjeux qui ne se posent jamais au même moment.

Le premier est la compétitivité : rester sur un stack vieillissant, c’est accumuler une lenteur de livraison qui se paie en parts de marché. Le deuxième est la sécurité : un runtime non maintenu n’est plus patché, et chaque CVE non corrigée devient une porte ouverte. Le troisième est la conformité : certaines obligations réglementaires supposent des versions supportées et des dépendances à jour. Le quatrième, le plus insidieux, est la dette qui se compose : plus on repousse, plus l’écart entre l’existant et la cible se creuse, et plus la migration future coûtera cher.

L’erreur classique consiste à traiter la migration comme une dépense à minimiser. C’est un investissement dont le coût d’inaction croît avec le temps. Et ce coût n’est pas tant celui d’écrire le nouveau code que celui de ne pas reproduire, à l’identique, un comportement métier souvent non documenté. C’est ce déplacement de la difficulté, du « réécrire » vers le « ne rien casser », qui explique pourquoi les migrations dérapent.

Pourquoi les migrations dérapent, et pourquoi ce n’est pas une question d’effort

Quatre causes reviennent sur la quasi-totalité des projets, et aucune ne se résout en mettant simplement plus de développeurs sur la tâche.

La première est le volume manuel. Une conversion de code traditionnelle avance, pour un développeur expérimenté, autour de 300 à 500 lignes par jour. Sur un codebase de plusieurs centaines de milliers de lignes, l’arithmétique est implacable et la phase de conversion s’étale sur des mois.

La deuxième est l’introduction d’erreurs. Chaque ligne migrée à la main est une occasion d’introduire une régression. Plus le volume est élevé, plus la probabilité d’un bug critique passé inaperçu augmente.

La troisième est la perte de connaissance. Le code d’origine encode des règles métier qui ne sont écrites nulle part ailleurs. Quand l’auteur initial a quitté l’entreprise, cette connaissance disparaît avec lui, et la migration devient une enquête autant qu’un travail d’ingénierie.

La quatrième est la mobilisation de profils rares. Une migration sérieuse réclame des développeurs seniors, ceux-là mêmes qui sont déjà sur les sujets à plus forte valeur. Les immobiliser plusieurs mois sur de la conversion a un coût d’opportunité considérable.

Le point commun de ces quatre causes mérite d’être nommé : le goulot d’étranglement n’est pas la vitesse de frappe, c’est la charge cognitive. Re-comprendre un legacy non documenté, ligne après ligne, pour le reproduire fidèlement, voilà ce qui prend du temps. Cette distinction est décisive, parce qu’elle indique exactement où l’IA peut aider et où elle ne le peut pas.

Anatomie d’une migration : cinq phases et leur vrai coût

Pour raisonner concrètement, il faut décomposer. Une migration de code se déroule en cinq phases, dont voici les ordres de grandeur. Ces chiffres sont des estimations méthodologiques, issues de notre modélisation d’un projet type. Ils servent à comparer le poids relatif des phases, pas à promettre un devis.

1. Analyse et conception d’architecture: 5 à 10 jours-hommes. Comprendre le code existant, cartographier les dépendances, concevoir l’architecture cible. Phase courte mais critique, car une erreur d’orientation ici se paie sur tout le reste du projet.
2. Migration du code: 30 à 200 jours-hommes. La conversion proprement dite, l’adaptation aux idiomes du langage cible, la résolution des incompatibilités. C’est de loin la phase la plus lourde.
3. Certification qualité et documentation: 35 à 65 jours-hommes. Tests unitaires, documentation technique, rapport d’impact avant/après.
4. Validation: 15 à 30 jours-hommes. Revue de code, tests d’intégration, tests de régression, validation fonctionnelle avant livraison.
5. Monitoring et optimisation: 10 à 30 jours-hommes. Mise en place du suivi, optimisation des performances, documentation des indicateurs.

Agrégé, cela donne des fourchettes parlantes : autour de 95 jours-hommes pour un projet de moins de 50 000 lignes, environ 200 pour un projet de 50 000 à 200 000 lignes, et de l’ordre de 335 au-delà de 200 000 lignes.

L’enseignement n’est pas dans les totaux, il est dans la répartition. La phase de conversion concentre, à elle seule, la moitié à deux tiers de l’effort. C’est mécaniquement là que l’augmentation par l’IA a le plus de levier, parce que c’est là que se trouve le plus gros volume de tâches bornées et répétitives. À l’inverse, la phase d’analyse, courte mais à forte densité de jugement, est celle où l’humain reste indispensable.

Ce contraste se retrouve sur le terrain. Lors du webinar, deux ordres de grandeur cités par des éditeurs rencontrés illustraient l’ampleur de ces chantiers : un éditeur du secteur financier évaluait sa modernisation de stack à environ 3 000 jours-hommes, et un éditeur de logiciels d’assurance chiffrait la refonte de sa plateforme autour de 2 millions d’euros sur deux ans. Ces chiffres ne sont pas des cas Go&Dev, ce sont des estimations terrain rapportées par des prospects. Ils donnent la mesure de l’enjeu.

Où l’IA déplace réellement le curseur : le cas Java 8 vers Java 21

Le cas que nous avons démontré en direct, une migration de Java 8 vers Java 21, est représentatif parce qu’il combine un saut de version important, des changements d’idiomes et un volume conséquent. C’est exactement le profil où la conversion manuelle s’éternise.

L’approche que nous mettons en œuvre ne consiste pas à brancher un assistant générique sur le dépôt et à espérer un bon résultat. Elle repose sur une orchestration de plusieurs agents spécialisés, ce que nous appelons une Squad Augmentée, où chaque agent prend en charge une tâche précise et vérifiable :

• un agent architecte analyse la structure du code et formalise la cible (diagrammes C4, UML) ;
• un agent migration réalise la conversion syntaxique, le mapping de types et la transposition de la logique métier ;
• un agent QA génère les tests unitaires et d’intégration, et mesure la couverture ;
• un agent refactoring optimise les performances et élimine le code mort ;
• un agent documentation rédige les README, les guides d’API et les diagrammes techniques ;
• un agent impact produit l’analyse de risques, la roadmap et l’estimation d’efforts.

Le principe directeur est important, et c’est lui qui sépare une approche sérieuse d’un gadget : chaque agent traite un périmètre borné, dont la sortie est contrôlable. L’agent migration ne décide pas de l’architecture, il exécute une transposition dans un cadre fixé par l’humain. L’agent QA ne valide pas le métier, il produit un harnais de tests que l’équipe relit. L’orchestration coordonne ces tâches, mais le jugement architectural et la décision finale restent du côté humain.

C’est précisément ce qui qualifie cette migration de cas d’usage Flow IA, l’IA appliquée au cycle de développement lui-même, par opposition à l’IA intégrée dans le produit du client. L’objectif n’est pas de retirer l’expertise de la boucle, mais de la concentrer là où elle compte : l’analyse en amont et la validation en aval, en déchargeant l’équipe du volume de conversion à faible valeur cognitive.

La QA, angle mort des migrations, devient un point d’appui

Il y a une ironie au cœur des migrations : on modifie massivement un code dont, le plus souvent, on ne dispose pas d’une couverture de tests suffisante pour garantir qu’on ne casse rien. La phase de validation arrive alors trop tard, en bout de chaîne, quand les régressions sont déjà incrustées.

La génération automatisée de tests change cet ordre. En produisant une couverture de tests sur le code source avant de le migrer, on fige le comportement attendu. Les tests deviennent un filet de sécurité : si la version migrée ne les passe pas, c’est qu’une régression a été introduite, et on la détecte immédiatement plutôt qu’en production.

Personne ne fait cela à la main sur un legacy volumineux, faute de temps : écrire rétroactivement des milliers de tests unitaires est un projet en soi, rarement priorisé. C’est exactement le type de tâche à fort volume et à logique répétitive où l’IA est pertinente. Elle ne remplace pas la réflexion sur les cas limites, mais elle produit la masse de tests de base que l’équipe n’aurait jamais écrite, et que les ingénieurs peuvent ensuite compléter sur les scénarios sensibles. Le bénéfice n’est pas qu’un gain de temps, c’est un gain de confiance dans la migration elle-même.

Ce que l’IA ne fait pas, et ne doit pas faire

Un discours crédible sur l’IA appliquée à la migration suppose d’en tracer les limites aussi nettement que les apports.

L’IA ne décide pas de l’architecture cible. Choisir comment structurer le système modernisé, quels compromis accepter, quelles dépendances retenir, relève d’un arbitrage technique et métier qui engage l’entreprise sur des années. C’est une décision humaine.

L’IA ne tranche pas les arbitrages métier. Quand une règle implicite du code d’origine est ambiguë, il faut quelqu’un qui connaisse le domaine pour décider de l’interprétation correcte. Un agent peut signaler l’ambiguïté, il ne peut pas la résoudre seul.

L’IA ne se substitue pas à la revue. Le code généré, comme tout code, doit être relu, testé et validé. La revue humaine n’est pas une formalité, c’est le mécanisme par lequel l’équipe garde le contrôle de ce qui entre dans son système.

Ce cadrage permet de lire correctement les gains que nous observons. Sur notre modélisation d’un projet type, l’augmentation par la Squad réduit l’effort de conversion d’environ 60%, et l’effort global de l’ordre de 50%, en faisant passer un projet d’environ 200 jours-hommes à environ 95. Ce sont des estimations méthodologiques, dépendantes de la nature du code, de sa qualité initiale et du périmètre. Elles ne valent pas garantie contractuelle, et nous nous méfions autant que vous des promesses de division par deux annoncées sans conditions. La bonne lecture est : sur la phase où le volume domine, le levier est réel et mesurable ; sur les phases de jugement, le gain est plus modeste, parce que l’humain y reste central, et c’est sain.

Comment aborder une migration en 2026

Pour une équipe qui a une migration au planning, quelques principes concrets se dégagent de tout ce qui précède.

Commencez par l’analyse d’impact et la mise sous tests, pas par la conversion. Avant de toucher une ligne, cartographiez les dépendances et générez une couverture de tests qui fige le comportement actuel. C’est ce qui transformera la suite en travail contrôlé plutôt qu’en pari.

Cadrez un POC sur un module représentatif. Plutôt que d’estimer dans le vide, choisissez un périmètre qui condense les difficultés du projet et mesurez sur lui le gain réel de l’approche augmentée. Notre méthodologie part d’ateliers d’identification de cas d’usage de un à trois jours, puis d’un POC ou MVP de deux à six semaines, avant tout déploiement. C’est sur ce POC que se valident à la fois la faisabilité technique et les ordres de grandeur de gain, sur votre code et non sur une moyenne.

Gardez l’humain sur l’architecture et la validation. Le bon usage de l’IA dans une migration consiste à lui confier le volume et à concentrer vos meilleurs profils sur les décisions structurantes et la revue. C’est cette répartition, et non l’outil seul, qui fait la différence entre une migration accélérée et une migration ratée plus vite.

La migration reste un chantier exigeant. L’IA bien orchestrée ne le rend pas trivial, elle en redistribue l’effort : moins de temps perdu sur la conversion, plus de temps disponible pour le jugement. C’est précisément ce déplacement qui justifie de s’y intéresser sérieusement.

Vous avez manqué le webinar, ou vous voulez revoir la démonstration en direct ?

Le replay du webinar « Réussir sa migration technique : les apports concrets de l’IA » est disponible. Vous y retrouverez la démonstration complète de la migration Java 8 vers Java 21 et de la génération automatisée de tests, commentée par nos équipes.

→ Voir le replay

Yasser Jebbari, Practice Manager IA chez Go&Dev.