Loading...
POC & retour d'expérience
10 POCs de migration legacy : ce qu'on a appris de 35 524 lignes converties par IA
Avant de signer un programme de modernisation legacy à plusieurs millions, personne ne s'engage sur la parité fonctionnelle. On a livré dix POCs internes pour calibrer la méthode AVANT toute mission cliente. Voici les chiffres et les cinq learnings qui ont stabilisé ATLAS Legacy.
POC & retour d'expérience · 6 min·6 minutes de lecture
10
POCs livrés (8 COBOL · 1 Delphi · 1 BizTalk)
35 524
lignes de code analysées
39 + 9
patterns COBOL et BizTalk stabilisés
Pourquoi la parité fonctionnelle bloque les programmes legacy
Sur un mainframe COBOL en production depuis vingt ou trente ans, la majorité des règles métier n'est plus dans la documentation. Elle est dans le code, parfois dans des branches de logique conditionnelle accumulées sur plusieurs générations de mainteneurs partis depuis longtemps.
Le DSI qui veut moderniser ce système se heurte à une question simple à formuler et terrible à répondre : comment prouver, après migration, que le nouveau système se comporte exactement comme l'ancien ? Sans réponse claire, le programme ne peut pas démarrer. Avec une réponse vague, il dérape à coup sûr en validation.
Notre conviction : avant de proposer un programme à un client, il fallait calibrer la méthode sur du code public, sans pression commerciale. Dix POCs plus tard, on a une réponse contractuelle.
Le protocole des 10 POCs
Sources volontairement publiques — IBM carddemo, GenApp, CBSA, Raptor (COBOL), DGFiP taxe foncière (Delphi), BizTalk Assurance (BizTalk Server). Pas de NDA, pas de patrimoine sensible, juste du code legacy représentatif des familles que nos clients nous demandent de moderniser.
Chaque POC suit le même protocole : périmètre défini, tests de caractérisation écrits AVANT migration, conversion pattern par pattern assistée par IA (Claude pour le raisonnement, Copilot pour l'autocomplete), runs parallèles legacy/cible, registre de discordances signé.
Durée par POC : une à trois semaines. Cellule type : 1 architecte senior + 1 développeur cible + assistance IA. Cible technique : TypeScript sur Cloudflare Workers (pour la simplicité de déploiement public) ou Logic Apps Azure pour BizTalk.
Les chiffres
35 524 lignes analysées au total sur les dix POCs. 39 patterns COBOL stabilisés (boucles PERFORM, fichiers indexés, sous-programmes appelés via CALL, sections d'environnement, déclarations FILE, traitements EBCDIC, etc.) et 9 patterns BizTalk (orchestrations, maps XSLT, pipelines de réception et d'envoi, schémas).
44 discordances identifiées et tracées sur l'ensemble des dix POCs, soit 0,12 % des lignes. Chaque discordance documente un comportement où le code cible ne reproduit pas exactement le legacy — typiquement des effets de bord d'arithmétique COMP-3, des conventions de tri EBCDIC vs ASCII, des cas limites de manipulation de caractères. Aucune discordance n'a affecté un cas de production majeur.
8 applications de démonstration sont aujourd'hui en ligne, exécutables, avec leur registre de discordances et leur suite de tests : portfolio, carddemo, cbsa, genapp, carddemo-ext, raptor-invoice, dgfip-taxe-fonciere, biztalk-assurance-migration. Voir la méthodologie ATLAS et le parcours COBOL vers Java.
Cinq learnings qui ont changé la méthode
Un — Le vibe coding accélère la conversion x2 à x3, mais ne remplace pas la phase Discovery. L'IA est efficace sur les patterns reconnaissables. Elle reste muette devant les règles métier non écrites, qu'il faut extraire à l'humain. Couper Discovery par optimisation IA = échec garanti en validation.
Deux — Le client signe un registre de discordances, pas un nombre de lignes. Le livrable contractuel n'est pas "on a migré 100 000 lignes". C'est "voici les 47 écarts entre legacy et cible, chacun documenté, arbitré, et signé par votre comité programme". C'est cette signature qui débloque le passage en production.
Trois — Les tests de caractérisation s'écrivent AVANT la migration, jamais après. Sans référence comportementale fixée en amont, la parité devient une opinion. Trois POCs ont commencé sans cette discipline ; tous les trois ont dû refaire la phase de capture après coup, doublant le délai.
Quatre — Les runs parallèles legacy/cible restent le seul proof définitif. Pas de big-bang. Pendant deux à six mois, le legacy et la cible tournent côte à côte, alimentés par les mêmes inputs, comparés sur leurs outputs. Toute divergence devient un ticket. C'est cher en infrastructure, c'est ce qui vous évite la catastrophe en production.
Cinq — La qualité de la Discovery détermine la qualité du code cible, pas l'inverse. Un POC bâclé en amont ne se rattrape pas par de la bonne ingénierie en aval. Si vous voulez un programme prévisible, payez la Discovery. C'est l'investissement avec le ROI le plus élevé que nous ayons mesuré.
Les pièges qui font dérailler un POC
Périmètre flou. "On migre le module factures" sans préciser quelles transactions, quels jeux de données, quels écrans. Le POC doit définir noir sur blanc ce qui est dedans et ce qui est dehors avant la première ligne convertie.
Refus client de figer la référence de vérité. Si le legacy continue d'évoluer en parallèle du POC, la cible court après une cible mouvante. Soit on fige une version pour la durée du POC, soit on accepte que le POC ne mesure rien.
Promesses d'IA non tenues. "L'IA va tout migrer toute seule" est une déclaration commerciale, pas un protocole technique. Les vendeurs qui le promettent ne livrent pas les programmes en production. Notre méthode : IA assistée, humain responsable, registre de discordances signé.
Absence de tests. Sans tests de caractérisation, vous ne migrez pas — vous spéculez. Trois semaines de tests bien écrits valent mieux que trois mois de migration aveugle.
Conclusion : ce que cela vous achète
Dix POCs internes ont permis de stabiliser une méthode (ATLAS Legacy), une bibliothèque de patterns (39 COBOL + 9 BizTalk), et une bibliothèque de discordances types (44 cas documentés). C'est ce capital méthodologique que vous achetez quand vous engagez Access sur un programme de modernisation.
Pour un programme client, le protocole est le même que sur les POCs publics — adapté à votre patrimoine, votre cible, votre gouvernance. Cadrage Intake gratuit. Un POC sur votre périmètre peut être livré en deux à six semaines avant d'engager le programme complet. Voir le produit ATLAS Legacy et les modèles de delivery.
Questions fréquentes
Ce que les décideurs demandent sur ce sujet.
Quelle est la durée moyenne d'un POC sur votre périmètre client ?+
**Deux à six semaines** selon le volume et la complexité. Une application Delphi mono-utilisateur de 50 000 lignes : 3 à 4 semaines. Un module COBOL mainframe de 10 000 lignes avec dépendances copybooks et JCL : 4 à 6 semaines. La phase Discovery représente typiquement la moitié de la durée — c'est normal et c'est sain.
Le POC prouve-t-il que la migration complète est faisable ?+
Le POC prouve trois choses : (1) la cible technique est viable sur votre patrimoine spécifique ; (2) la productivité réelle assistée IA est mesurable et reproductible ; (3) le ratio de discordances attendu est connu. Ces trois mesures permettent de chiffrer le programme complet avec une précision inaccessible sans POC.
Qui signe le registre de discordances ?+
**Votre comité programme**, après arbitrage interne. Access propose le registre rempli avec preuves (cas de test, captures d'écran, logs comparatifs), mais la décision d'accepter ou de demander correction reste chez vous. C'est ce qui rend le livrable contractuel : Access n'auto-valide rien.
Que se passe-t-il si le POC révèle un coût de migration supérieur au prévu ?+
C'est précisément la valeur du POC : transformer une incertitude en chiffre. Si la cellule fonctionnelle s'avère trois fois plus complexe que prévu, le programme complet est rechiffré sur cette base, ou son périmètre revu. **Mieux vaut découvrir cela en POC à 50 k€ qu'en programme à 5 M€.**
Le vibe coding remplace-t-il l'expertise COBOL ?+
**Non.** L'IA reconnaît les patterns syntaxiques mais ne comprend pas pourquoi telle règle métier existe ni pourquoi telle exception a été ajoutée en 2008. Nos architectes seniors restent indispensables pour arbitrer les ambiguïtés, valider les choix structurels, et signer le registre de discordances. L'IA accélère l'écriture, l'humain reste responsable.
Comment transférez-vous le savoir au client après livraison ?+
Trois leviers : (1) **documentation exhaustive** livrée avec le programme — patterns identifiés, discordances arbitrées, suite de tests automatisée ; (2) **pair-programming** avec vos équipes pendant les dernières semaines ; (3) **bibliothèque de patterns** transférable que vos équipes peuvent réutiliser sur les évolutions futures. À la livraison, vous êtes autonome.
Les POCs publics sont-ils confidentiels ?+
**Non, ils sont publics par construction.** Sources volontairement issues de code ouvert (IBM carddemo, GenApp, CBSA, BizTalk Assurance) précisément pour pouvoir partager la méthodologie sans NDA. Vous pouvez consulter les démos live et le registre de discordances de chaque POC. Sur vos missions, le NDA s'applique normalement.
Peut-on lancer plusieurs POCs en parallèle sur le même programme ?+
**Oui, et c'est même recommandé sur les programmes pluri-applicatifs.** Un POC par sous-système permet d'identifier les complexités spécifiques de chaque domaine fonctionnel et de calibrer plus précisément le chiffrage global. Le coût additionnel des POCs en parallèle est largement compensé par la précision du chiffrage de programme.
Votre programme ressemble à ce cas de figure ?
Nous cadrons chaque programme à l'Intake, avec un chiffrage transparent. Un POC court de quelques semaines peut être livré avant d'engager le programme complet.
Lancer un POC sur mon périmètre →