COBOL n'est pas mort. Les devs qui le maintenaient, oui.

Le rapport METI 2025 est sans appel : 85 % des grandes entreprises japonaises font tourner leurs systèmes critiques sur du COBOL ou des mainframes IBM Z. L'âge moyen des développeurs capables de les maintenir est de 58 ans. La fenêtre se ferme. C'est ce que l'on appelle le "2025 cliff", et il est là, maintenant.

La réponse classique des intégrateurs : "on va vous mettre Copilot, ça va aller". Non. Copilot écrit du Python correct. Il ne migre pas trente ans de dette technique COBOL/CICS/DB2 vers du cloud-native sans casser la prod. Voici notre approche.

Pourquoi un LLM seul ne suffit pas

Un programme COBOL bancaire moyen, ce sont 200 000 à 800 000 lignes, avec des PERFORM imbriqués, des COPY enchâssés, des appels CICS, des accès DB2 hardcodés, et une logique métier qui dépend de l'ordre exact des champs dans des copybooks. Donnez ça à GPT-4 ou Claude en mode chat : il lira 8 000 lignes, perdra le contexte, et inventera la suite. C'est exactement ce qui se passe dans 90 % des PoC qu'on nous demande de reprendre.

Notre approche : les trois agents Abbeal

Nous appliquons à COBOL la même méthodologie multi-agents que sur le legacy Java ou .NET (voir notre article sur la modernisation legacy). Trois agents spécialisés, chacun avec ses outils, ses garde-fous, son owner humain.

1. The Archaeologist : parse le COBOL avec un AST dédié (proleap-cobol-parser), reconstruit le call graph, identifie les règles métier réelles via l'analyse statique + l'exécution sur traces de production réelles.
2. The Architect : propose une cible Java 21 ou Kotlin sur Spring Boot, avec un plan de migration par bounded contexts, et la stratégie d'interopérabilité pendant la transition (souvent via des MQ Series existantes).
3. The Cleaner : génère le code cible par modules de 2 000 à 5 000 lignes, avec tests d'équivalence rejouant les inputs production capturés.

Le piège du big bang

Tout migrer d'un coup est un suicide. Notre méthode : strangler fig pattern. On encapsule le COBOL existant derrière des API REST internes (via z/OS Connect ou un wrapper Java JNI), puis on remplace progressivement chaque endpoint par une implémentation cloud-native. Le mainframe meurt par tranches, sans interruption de service.

java
// Strangler facade : le client appelle l'API moderne,
// le routeur décide si la requête va vers le legacy ou la nouvelle impl
@RestController
public class CustomerController {
    @Autowired private CobolGateway legacy;
    @Autowired private CustomerServiceV2 modern;
    @Autowired private FeatureFlag flags;
    
    @GetMapping("/customers/{id}")
    public Customer get(@PathVariable String id) {
        if (flags.isEnabled("customer-v2", id)) {
            return modern.findById(id);
        }
        return legacy.callCobolModule("CUSTGET", id);
    }
}

Le facteur humain

Les équipes COBOL existantes ne sont pas un problème à liquider, ce sont des sources de connaissance métier irremplaçables. Notre process inclut systématiquement des sessions de pairing entre les développeurs COBOL seniors et nos ingés cloud-native. Les agents IA capturent et formalisent cette connaissance, qui aurait disparu autrement.

Le résultat sur nos projets COBOL

• Réduction du temps de migration : 70 à 85 % vs. réécriture manuelle.
• Couverture comportementale capturée : > 92 % via tests d'équivalence sur traces production.
• Coût total : généralement divisé par quatre sur la durée du projet.
• Risque de régression : -60 % vs. approche big bang classique.

Le 2025 cliff n'est pas une menace abstraite. Si vous opérez du COBOL, vous savez exactement combien de mois il vous reste avant que votre dernier expert parte à la retraite. Nos équipes franco-japonaises ont la double expertise COBOL legacy et cloud-native moderne. Le moment de discuter, c'est maintenant, pas dans dix-huit mois.