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 au cœur de nombreux systèmes bancaires, de contrats d'assurance vie et IARD, et d'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. Beaucoup de développeurs COBOL approchent de la retraite. Les écoles d'ingénieurs l'enseignent très peu. 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 ». Le point d'inflexion est là : les équipes COBOL internes perdent des personnes sans recrutement compensateur, les SSII spécialisées augmentent leurs tarifs, 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. 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.

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 expert COBOL senior obligatoire en review systématique du code généré.

L'aide de l'IA reste limitée. On le documente noir sur blanc dans nos devis. Pour les langages modernes (PHP, Java), le gain est bien plus net ; pour le COBOL, il est plus limité. C'est honnête, et nous mesurons le gain projet par projet.

#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 : des centaines de milliers de lignes de code, des dizaines de modules interconnectés, plusieurs décennies 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 plusieurs années, dual-run de 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. Un hébergeur qualifié SecNumCloud est recommandé pour les projets soumis à 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.

#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 encapsulé progressivement les modules legacy.

#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 au quotidien sur nos projets de modernisation. 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 généralement correcte, sous revue.

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 de l'expert COBOL senior — 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

Nous ne publions pas de grille de prix pour la modernisation COBOL : l'écart entre un module isolé et un core banking complet est trop grand pour qu'un prix « à partir de » soit honnête. Nous chiffrons sur devis en 48 h après un premier échange.

Audit de faisabilité (5 à 15 jours, livrable : rapport chiffré avec stratégie recommandée) : du périmètre simple (une application) à l'audit complet d'un core banking multi-modules. Livré sous forme de rapport exploitable directement.

Modernisation par module, selon la complexité, la criticité et le niveau d'intégration avec le reste du SI.

Programme complet core banking : plusieurs années, chiffré module par module. ERP propriétaire complet : 12 à 24 mois à titre indicatif. Modules périphériques (reporting, batch, interfaces) : 6 à 18 mois à titre indicatif.

Équipe Nehos mobilisée sur un programme complet : un Tech Lead (Mohamed Tarroumi, expertise legacy industriel), un co-lead (Houssem Baklouti, expertise finance), des développeurs seniors sur la stack source (avec un expert COBOL externe), des développeurs seniors sur la stack cible (Next.js, Java moderne), un architecte cloud / DevOps et un Product Owner Nehos. L'équipe est renforcée pour les très gros programmes.

#Pourquoi le secteur banque-assurance est notre cible prioritaire

Le secteur Banque, Assurance & Finance est la cible prioritaire de notre offre 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 chez un hébergeur qualifié SecNumCloud recommandé, 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.