Modernisation COBOL Mainframe — Méthode Strangler IA-Assisted Nehos

#Le COBOL ne disparaît pas — il vieillit

On entend depuis vingt ans que le COBOL va mourir. Il n'est pas mort. Il tourne encore aujourd'hui sur 220 milliards de lignes de code en production dans le monde (estimation Reuters / IBM 2023), supporte 80 % des transactions bancaires mondiales, gère les ⅔ des contrats d'assurance vie et IARD en Europe, et fait fonctionner la quasi-totalité des administrations publiques de plus de 30 ans. Le problème n'est pas le langage en soi — COBOL est stable, prévisible, fiable. Le problème, c'est la pénurie critique de développeurs qui le maîtrisent. L'âge moyen d'un développeur COBOL dépasse 60 ans. Les écoles d'ingénieurs ne l'enseignent plus depuis vingt ans. Quand un dev COBOL part à la retraite, personne ne prend sa place.

La fenêtre de modernisation se referme. Pour les directions IT bancaires, assurance et secteur public, la question n'est plus « faut-il moderniser » mais « peut-on encore se permettre d'attendre ». On a observé chez nos clients un point d'inflexion clair en 2024-2025 : les équipes COBOL internes perdent 1 à 3 personnes par an sans recrutement compensateur, les SSII spécialisées augmentent leurs TJM de 15-25 % par an, le coût de maintenance du legacy grimpe pendant que sa valeur métier reste constante. Le calcul devient déraisonnable.

#Notre méthode : Nehos Legacy Strangler IA-Assisted™

On applique au COBOL la Méthode Nehos Legacy Strangler IA-Assisted™ — pattern d'architecture Strangler Fig (Martin Fowler, 2004) combiné à l'IA-assistance moderne. Principe : on ne touche pas au mainframe tant que la stack moderne n'est pas prête. On construit le nouveau système à côté, on bascule progressivement bande par bande via API gateway et feature flags, on décommissionne le COBOL quand 100 % du trafic est migré. Zéro big-bang. Dual-run 90 jours minimum. Rollback opérationnel à tout moment. Pour le détail théorique du pattern, voir notre définition Strangler Fig pattern.

L'IA-assistance accélère trois phases spécifiques de la modernisation COBOL. Premièrement, l'analyse du code legacy : Claude Code lit le COBOL, identifie les modules, cartographie les dépendances, génère la documentation manquante. Sur un projet bancaire récent, 180 000 lignes COBOL ont été cartographiées en 6 semaines contre 4 mois estimés en méthode manuelle. Deuxièmement, la génération des équivalents modernes : le LLM propose la traduction vers Java Spring Boot ou Next.js + Symfony, le dev sénior valide et corrige. Troisièmement, les tests d'équivalence comportementale : le LLM génère des cas de test exhaustifs à partir du comportement COBOL observé en production, on rejoue les mêmes inputs sur l'ancien et le nouveau système, on compare les outputs. Couverture de tests typique : 30-40 % avant, 70-80 % après.

Limite assumée — et c'est important : le corpus LLM sur COBOL est faible. Claude, GPT-5 et Mistral Large ont vu beaucoup de PHP, Java moderne, Python, C#, JavaScript en pré-training. Ils ont vu peu de COBOL, encore moins de COBOL CICS / IMS / DB2 mainframe. Conséquence pratique : on garde un lead COBOL sénior obligatoire en review systématique du code généré. L'IA aide à 30-40 %, pas plus. On le documente noir sur blanc dans nos devis. Pour les langages modernes (PHP, Java), on observe des gains de 2-4× ; pour le COBOL, c'est 30-40 %. C'est honnête et c'est mesuré sur 5 projets refactor en 2024-2025.

#Cas d'usage typiques

#Core banking COBOL vers microservices modernes

Le sujet par excellence du secteur bancaire. Un core banking COBOL typique en banque mutualiste française : 200 000 à 1,5 million de lignes de code, 15 à 50 modules interconnectés, 30 à 40 ans d'âge, des règles métier non documentées que personne ne comprend plus dans le détail. Notre approche : découpage en bandes fonctionnelles (gestion compte courant, épargne, crédit, virement, conformité), migration module par module sur 24-36 mois, dual-run 90 jours par bande. Stack cible : Java Spring Boot 3 + Postgres + API gateway, ou Next.js 16 frontend + Symfony 7 backend + Postgres pour les modules avec UI. Hébergement OVHcloud SecNumCloud obligatoire pour respecter DORA et NIS2.

#Assurance vie / IARD legacy vers API-first

Les back-office d'assurance vie et IARD français sont massivement en COBOL, parfois avec une surcouche Java EE des années 2000-2010. Migration vers une architecture API-first qui ouvre l'accès aux courtiers, agents et clients via portails web modernes. Gain métier mesurable : time-to-market d'un nouveau produit assurance divisé par 3 à 5. Notre cas client fintech conformité DORA illustre cette approche sur un module DSP2 vers DSP3.

#Administration AS400 / iSeries vers Next.js

Les administrations publiques et grands comptes ont accumulé 20-30 ans de développements AS400 / iSeries en RPG et COBOL/400. Ces SI fonctionnent toujours, mais l'UI est en mode terminal 5250, le recrutement de devs RPG est impossible, et l'intégration avec les outils modernes (mobilité, API publiques, observabilité) est cauchemardesque. Notre approche : migration progressive vers Next.js + Payload CMS + Postgres, avec une couche d'API REST/GraphQL qui encapsule progressivement les modules legacy. Voir notre cas mécanique précision legacy pour un ETI industriel avec ERP 18 ans d'âge.

#ERP propriétaire 20+ ans vers architecture composable

De nombreuses ETI françaises tournent encore sur des ERP propriétaires développés en interne dans les années 1990-2000, souvent en COBOL ou en mix COBOL/Java EE. La modernisation vers une architecture composable (best-of-breed connectés par APIs) plutôt que vers un nouveau monolithe (SAP, Microsoft Dynamics) permet de garder la spécificité métier qui fait la valeur de l'ETI tout en supprimant la dette technique. Stack cible : composants spécialisés (CRM, ERP financier, supply, BI) reliés par un orchestrateur middleware + Next.js comme couche présentation unifiée.

#Stack moderne cible

Notre stack moderne cible Next.js + Postgres standard pour les modernisations COBOL : Next.js 16 (App Router, React Server Components) en frontend, Payload CMS pour la gestion de contenu, Postgres 16 comme base de données principale, APIs REST + GraphQL pour les intégrations, Docker + Kubernetes pour le déploiement, OVHcloud SecNumCloud pour l'hébergement souverain régulé. Pour les modules avec forte charge transactionnelle, on ajoute Java Spring Boot 3 ou Go en backend services. Hébergement Scaleway en alternative, jamais d'AWS/Azure/GCP imposé — on documente toujours l'option souveraine.

Monitoring et observabilité : Sentry + Grafana + Prometheus + OpenTelemetry. Feature flags via PostHog ou Unleash pour le routage progressif. API gateway Kong ou Traefik pour le dual-run avec routage 10/25/50/100 %. CI/CD GitHub Actions avec tests d'équivalence comportementale obligatoires avant chaque déploiement.

#L'IA pour la modernisation COBOL : ce qui marche, ce qui n'a pas marché

On utilise Claude Code et Cursor en production sur tous nos projets de modernisation depuis octobre 2024. Voici ce qu'on a appris spécifiquement sur le COBOL.

Ce qui marche : l'analyse statique du code COBOL avec un LLM contemporain donne des résultats utilisables. Le LLM identifie les modules, retrouve les dépendances entre programmes, génère une cartographie textuelle compréhensible. Sur les blocs PROCEDURE DIVISION simples (arithmétique, manipulation de chaînes, IO basique), la traduction vers Java ou Python moderne est correcte à 70-80 %. La génération de tests d'équivalence comportementale fonctionne bien : on donne au LLM le COBOL + des exemples d'input/output, il produit des cas de test exhaustifs en JUnit ou pytest qui valident le comportement.

Ce qui n'a pas marché : la traduction directe COBOL → Java/Python sur du code CICS, IMS, DB2 mainframe est mauvaise. Le LLM hallucine, propose des APIs qui n'existent pas, manque les subtilités du context mainframe (regions, transactions, locks). Sur ces parties, on garde 100 % du travail entre les mains du lead COBOL sénior — l'IA est juste un assistant de documentation. Pareil sur les règles métier implicites enfouies dans du COBOL accumulé pendant 30 ans : aucun LLM ne peut deviner pourquoi telle fonction multiplie par 0,9876 — il faut un humain qui parle au métier.

#Durées et tarifs typiques

Audit de faisabilité (5 à 15 jours, livrable rapport chiffré avec stratégie recommandée) : à partir de 1 522 € HT pour un périmètre simple (1 application, <50 k lignes), jusqu'à 18 15 872 € HT pour un audit complet de core banking multi-modules. Tarif fixe, livré sous forme de rapport exploitable directement.

Modernisation par module : 11,5 k€ HT selon la complexité, la criticité, et le niveau d'intégration avec le reste du SI. Un module isolé de 20-50 k lignes COBOL coûte typiquement 200-711 k€. Un module critique avec 100+ k lignes et fortes intégrations peut atteindre 600 k€.

Programme complet core banking : 2 à 8 millions d'euros HT sur 24-36 mois. Cas type : banque mutualiste avec 800 k lignes COBOL réparties en 18 modules. ERP propriétaire complet : 800 k à 2 millions d'euros HT sur 12-24 mois. Modules périphériques (reporting, batch, interfaces) : 6-18 mois et 121 k€.

Équipe Nehos mobilisée : sur un programme complet, 8 à 14 ETP — 1 Tech Lead Mohamed Tarroumi (expertise legacy industriel), 1 co-lead Houssem Baklouti (expertise finance), 2-3 dev séniors stack source (lead COBOL externe en partenariat), 3-4 dev séniors stack cible (Next.js, Java moderne), 1 architecte cloud / DevOps, 1 Product Owner Nehos. Pour les très gros programmes (>1200 k€), on peut monter à 18-22 ETP. Voir aussi notre cas banque mutualiste assistant IA pour une analogie sur la maîtrise du contexte bancaire.

#Pourquoi le secteur banque-assurance est notre cible prioritaire

Notre secteur Banque, Assurance & Finance concentre une part majeure de nos projets COBOL. Trois raisons : la criticité du legacy y est extrême, la pression réglementaire (DORA, NIS2, conformité ACPR) impose un mouvement, et l'enveloppe budgétaire est compatible avec une modernisation sérieuse. Pour les ETI industrielles, voir notre secteur Énergie & Industrie — les sujets sont similaires (AS400, ERP propriétaire) mais avec des contraintes budgétaires différentes.

Pour les projets régulés bancaire et assurance, hébergement OVHcloud SecNumCloud obligatoire, audit sécurité externe (TIBER-EU si applicable), incident reporting framework DORA, monitoring tiers ICT. On livre la documentation complète DORA / NIS2 en sortie de projet.