4 min de lecture

Strangler pattern : la seule méthode qui marche en migration COBOL

Le big bang ne fonctionne pas en migration mainframe. Le strangler fig pattern, si. Voici comment l'appliquer concrètement à une chaîne COBOL.

Architecture COBOL Migration Strangler Pattern
Abderrahmane Battiwa Consultant mainframe · ABConsult.tech

Martin Fowler a popularisé le terme en 2004 en observant les figuiers étrangleurs d’Australie : une nouvelle plante pousse autour d’un arbre existant, le remplace progressivement, et quand l’ancien tronc est mort, la nouvelle plante se tient seule. La métaphore est parfaite pour la migration mainframe.

Le big bang — réécrire tout d’un coup et basculer en une nuit — ne fonctionne pas sur les SI critiques. J’ai vu des projets de 3 ans échouer à la mise en production parce que la réplication exacte du comportement COBOL est impossible à valider dans sa globalité. Le strangler pattern, lui, permet de migrer pendant que la production tourne.

Le principe appliqué au COBOL

L’idée centrale : ne jamais supprimer de code legacy. On ajoute une couche nouvelle qui intercepte progressivement le trafic, et on laisse l’ancien code s’éteindre naturellement quand il n’est plus sollicité.

En pratique sur un SI mainframe, cela ressemble à ceci :

Avant :
  CICS transaction → COBOL Program → DB2


Après (phase intermédiaire) :
  CICS transaction → API Gateway → [COBOL Program OU microservice Java]
                                         ↕
                                      DB2 (partagé)

L’API Gateway devient l’intercepteur : il route les requêtes vers l’ancien ou le nouveau backend selon des règles métier précises. Vous pouvez migrer 10% des transactions, observer, valider, puis 50%, puis 100%.

Les quatre étapes concrètes

Étape 1 : Identifier les seams (coutures)

Avant de coder quoi que ce soit, il faut trouver les points d’entrée naturels dans le système. Sur un mainframe, les candidats sont :

  • Les transactions CICS : chaque transaction est un point d’entrée discret, identifié par un code à 4 caractères. C’est le seam idéal.
  • Les interfaces de fichiers : si un programme lit un fichier VSAM, ce fichier peut devenir une API REST ou un topic Kafka.
  • Les appels de sous-programmes : CALL 'CACULVAL' USING ... peut être remplacé par un appel HTTP vers un microservice Java.

Étape 2 : Créer la façade d’interception

C’est l’investissement central du projet. Sur z/OS, la façade peut être :

  • Un programme COBOL supplémentaire qui wrape l’existant et délègue selon une table de routing en DB2
  • Un API management layer externe (IBM DataPower, AWS API Gateway) qui reçoit les requêtes CICS reformatées via MQ Series ou Kafka Connect
//APIROUTE EXEC PGM=ROUTMGR
//STEPLIB  DD DISP=SHR,DSN=PROD.LOADLIB
//ROUTCFG  DD DISP=SHR,DSN=PROD.CONFIG(ROUTES)
//SYSOUT   DD SYSOUT=*

Étape 3 : Migrer par tranches fonctionnelles

Ne migrez pas “le module de calcul de taux”. Migrez “le calcul de taux pour les prêts immobiliers créés après le 01/01/2025”. Cette granularité permet :

  • De tester sur un sous-ensemble de données réelles
  • De revenir en arrière proprement si un problème survient
  • De comparer les résultats new/legacy en parallèle (shadow mode)

Le shadow mode est votre meilleur ami : pendant 4 à 8 semaines, la nouvelle implémentation tourne en parallèle de l’ancienne sans impacter la production. On compare les résultats ligne à ligne et on corrige les divergences avant la bascule.

Étape 4 : Valider et éteindre

Quand le nouveau service gère 100% du trafic depuis 4 semaines sans incident, on “éteint” l’ancien programme. Pas de suppression immédiate — on désactive le routing, on archive le code source, on garde le binaire LPAR pendant 6 mois pour rollback.

Les pièges à éviter

Le big bang du domaine. Certains disent “on va migrer tout le domaine sinistres en 6 mois”. Ce n’est pas du strangler pattern, c’est du big bang avec un planning plus long.

L’hysteresis de données. Si le nouveau service et l’ancien écrivent tous les deux en base, la cohérence devient cauchemardesque. Règle : pendant la transition, un seul système est writer, l’autre est reader.

Négliger les interfaces batch. Les interfaces CICS se migrent facilement. Les batchs JCL nocturnes qui s’enchaînent sur des GDGs (Generation Data Groups) sont autrement plus complexes. Planifiez-les séparément.

C’est exactement la phase B de ma méthode ABC. Si votre organisation prépare une migration mainframe, parlons-en — 30 minutes suffisent pour évaluer la faisabilité.

Articles récents