Où COBOL en production fait encore le vrai travail

COBOL reste en production là où une organisation a passé des décennies à inscrire l'argent, les droits et la gestion des exceptions dans un chemin opérationnel fiable. Le langage apparaît dans la bibliothèque source, mais le système comprend aussi le JCL, les ordonnanceurs, les fichiers, les bases de données, les moniteurs transactionnels, les procédures d'exploitation, les rapports de rapprochement et les accords avec tous les systèmes voisins. Remplacer uniquement les programmes revient à remplacer la partie la moins difficile.

La formule bien connue «les banques utilisent encore COBOL» est exacte et presque inutile. Elle masque les charges qui en dépendent encore et les raisons pour lesquelles leurs propriétaires continuent de les financer. COBOL se concentre dans le règlement par lots, l'administration des polices d'assurance, les grands livres bancaires et le calcul des prestations publiques. Ces systèmes sont restés actifs parce qu'ils produisaient des résultats corrects dans des conditions pénibles. Ils bougent quand le coût du changement devient inférieur au risque cumulé de la perte de personnel, des limites de la plateforme, de la lenteur des changements de produit et d'une frontière d'interface que personne ne peut plus étendre sans danger.

La carte de production suit l'argent et les droits

COBOL reste utilisé lorsqu'un dossier volumineux et durable doit traverser de nombreuses transactions et que quelqu'un devra expliquer le résultat plus tard. Quatre catégories de charge représentent une grande partie du parc de production sérieux.

Le règlement par lots prend l'activité acceptée de la journée, applique frais et ajustements, équilibre les totaux de contrôle, comptabilise les résultats et produit des fichiers pour les parties en aval. L'interface en ligne peut employer un langage récent tandis que l'état financier définitif vient encore de travaux COBOL planifiés après une heure limite.

L'administration des polices conserve l'historique contractuel des produits d'assurance. Elle calcule les primes, applique les avenants, renouvelle les contrats, produit factures et documents, et enregistre la couverture en vigueur à une date donnée. Un portail web peut se placer devant ce système sans le remplacer.

Les grands livres bancaires centraux comptabilisent débits et crédits, maintiennent les soldes, calculent les intérêts, appliquent les règles d'écriture et clôturent les périodes comptables. Les applications mobiles et les API de paiement sont des canaux. Le grand livre décide ce que la banque considère comme arrivé.

Le calcul des prestations publiques applique lois et règles de programme aux demandes, historiques de revenus, données du foyer, dates d'effet, trop-perçus et recours. Les documents budgétaires de la Social Security Administration décrivent par exemple le traitement des demandes dans plusieurs anciens systèmes COBOL isolés. Il s'agit d'une dépendance opérationnelle concrète, pas d'une nostalgie pour un vieux langage.

Ces catégories se recoupent. Une plateforme de prestations possède des grands livres. Un assureur exécute des lots de règlement. Une banque administre des produits avec des dates d'effet proches de celles d'une police. La distinction utile est l'invariant métier: le règlement doit s'équilibrer, une police doit reproduire la couverture à une date, un grand livre doit conserver la vérité comptable et un système de prestations doit expliquer une décision de droit.

Le règlement par lots est une chaîne contrôlée

Un parc de règlement est un graphe de dépendances minuté dont la sortie a des conséquences financières. Une nuit typique ne commence qu'après la fermeture des fenêtres d'entrée des canaux. Les travaux vérifient les nombres de fichiers, trient les enregistrements, enrichissent les transactions, calculent les frais, comptabilisent les récapitulatifs, comparent les totaux, créent les fichiers sortants et transmettent les exceptions aux équipes d'exploitation. Une reprise peut partir d'un point de contrôle sûr plutôt que du début.

La documentation z/OS d'IBM qualifie le traitement par lots de fonction fondamentale de z/OS et explique comment JES reçoit les travaux, les planifie et contrôle leur sortie. Cette description corrige une erreur courante de modernisation: l'exécutable COBOL ne possède pas tout le flux. Le JCL nomme les entrées et sorties, les procédures cataloguées fournissent les étapes partagées, l'ordonnanceur apporte calendriers et dépendances, et les opérateurs interprètent les codes retour et les sorties spool.

Un petit extrait de travail montre la quantité de comportement située hors du code source de l'application:

//SETTLE   JOB CLASS=A,MSGCLASS=X
//POST     EXEC PGM=POSTDAY,PARM='RESTART=CHK7'
//INTRANS  DD DSN=BANK.CLEARING.ACCEPTED,DISP=SHR
//OUTPOST  DD DSN=BANK.LEDGER.POSTED(+1),
//            DISP=(NEW,CATLG,DELETE)
//EXCEPT   DD DSN=BANK.SETTLE.EXCEPT(+1),
//            DISP=(NEW,CATLG,DELETE)
//SYSOUT   DD SYSOUT=*

Le remplacement doit répondre aux questions soulevées par cet extrait. Qu'est-ce qui crée la génération (+1)? Une étape en échec supprime-t-elle une sortie partielle? Quels codes retour autorisent le travail suivant? Que signifie CHK7 après une comptabilisation partielle? Qui décide qu'un fichier d'exceptions est complet? Convertir POSTDAY dans un autre langage sans recréer ces contrôles peut produire un code valide et un processus de règlement invalide.

Les systèmes de règlement restent parce qu'ils sont adaptés à la discipline des heures limites, à la reprise et aux entrées-sorties de masse. Ils finissent par bouger lorsque de nouveaux canaux exigent des écritures plus fréquentes, que des contreparties demandent d'autres frontières de fichier ou d'API, que les fenêtres de lot heurtent des horaires mondiaux ou que trop peu de personnes savent reprendre une chaîne en échec.

L'administration des polices conserve le temps comme donnée

Un système d'administration des polices doit répondre à «qu'est-ce qui était vrai alors?» autant qu'à «qu'est-ce qui est vrai maintenant?». Dates d'effet et de transaction, avenants rétroactifs, résiliations, remises en vigueur, renouvellements, règles territoriales et versions de produit modifient la réponse. Ce modèle temporel explique pourquoi une simple migration de base de données remplace rarement le système.

Prenons un avenant saisi aujourd'hui mais prenant effet avant la dernière facture. Le système peut devoir recalculer la prime sur une partie de la période, conserver les documents déjà émis, créer une nouvelle créance et laisser une trace expliquant l'écart. Un service naïf qui ne stocke que le dernier état de la police détruit les preuves. Un remplacement fidèle traite séparément événements, périodes d'effet, valeurs dérivées et pièces émises.

COBOL convient à ce travail parce que les enregistrements métier fixes, l'arithmétique décimale, le traitement séquentiel et les branches explicites correspondent au domaine. Le parc environnant ajoute souvent des copybooks partagés, des tables gérées hors du code, des modèles de document, des modules de tarification et des traitements nocturnes de facturation. Certaines règles existent deux fois car le devis en ligne et la facturation du renouvellement ont évolué séparément. Les deux logiques peuvent ne diverger que pour une version rare du produit, précisément là où une réécriture propre peut changer un résultat client valable.

Les propriétaires n'ont pas arrêté ces systèmes parce que les navigateurs et serveurs d'application avaient changé. Ils ont ajouté des portails, des outils de workflow et des API autour d'eux. Ce choix restait rationnel tant que les produits étaient stables et que le noyau produisait des résultats défendables. La décision change lorsque lancer ou modifier un produit exige des retouches dans de vieux programmes, que chaque version dépend d'un groupe de relecteurs qui rétrécit ou qu'un composant documentaire ou d'intégration non pris en charge bloque tout le chemin.

Un remplacement doit prouver son comportement temporel avec des scénarios datés. Testez une nouvelle police, un avenant en cours de période, une correction rétrodatée, une résiliation suivie d'une remise en vigueur et un renouvellement traversant une frontière de version du produit. Comparez l'argent, le statut, les périodes de couverture, les documents, les écritures et les explications. Faire correspondre la ligne actuelle d'une table de polices ne suffit pas.

Les grands livres survivent car les erreurs s'accumulent

Un grand livre central tourne encore en COBOL parce que changer le moteur de comptabilisation peut modifier les comptes de l'établissement. Le travail dépasse largement l'addition et la soustraction de soldes. Ordre des écritures, dates de valeur, blocages, contre-passations, intérêts courus, frais, précision des devises, comptes d'attente et contrôles de fin de période interagissent.

Le secteur confond souvent grand livre et service de solde. Un service de solde répond rapidement à une lecture. Un grand livre enregistre des écritures ordonnées et durables, puis permet leur reconstruction. Si une migration copie les soldes actuels mais perd l'historique des écritures ou les liens de contre-passation, les chiffres peuvent coïncider le matin de la bascule et devenir inexplicables dès le premier litige.

Le traitement transactionnel en ligne passe souvent par CICS. La documentation Enterprise COBOL d'IBM explique que les programmes utilisant les services CICS compilent les instructions CICS intégrées via l'interface de commande CICS. Ce détail signale une autre frontière à découvrir: le périmètre d'une transaction peut dépendre des ressources CICS, du travail Db2, de fichiers, de files d'attente et de la gestion des erreurs plutôt que des seules instructions COBOL.

Le remplacement d'un grand livre échoue de façon reconnaissable. Une équipe mappe les lignes de compte vers de nouvelles tables, réimplémente les écritures du cas normal et valide des tests unitaires. Pendant l'exécution parallèle, une ancienne contre-passation arrive après que la transaction liée a franchi une frontière de date comptable. Le nouveau système applique la règle actuelle et l'ancien applique la version attachée à l'écriture d'origine. Les deux exécutions semblent raisonnables. Une seule correspond aux comptes reconnus par l'établissement.

La réponse n'est pas de garder chaque défaut historique. L'équipe doit classer le comportement. Les invariants comptables et les résultats contractuels exigent la parité. Un formatage d'affichage accidentel, peut-être pas. Une règle suspecte exige une décision métier explicite, consignée avant que quelqu'un ne la «corrige». Sinon, les ingénieurs prennent des décisions de politique métier en revue de code, là où personne ne voit la conséquence financière.

Le calcul des prestations mêle droit et histoire opérationnelle

Les systèmes publics de prestations conservent COBOL parce que les règles exécutables reposent sur de longs historiques de demandeurs et des procédures administratives. Un calcul peut dépendre des périodes de revenus, de la composition du foyer, du handicap, de décisions antérieures, des interactions entre programmes, des dates d'effet, des règles d'arrondi, plafonds, compensations et corrections ultérieures. Un recours peut obliger l'administration à reproduire une décision avec les faits et règles applicables à l'époque.

La loi n'est pas la spécification exécutable. Règlements, manuels de politique, mises à jour de tables, calendriers de lots, règles de nettoyage des données et procédures d'exception comblent l'écart entre texte juridique et paiement. Deux dossiers apparemment équivalents pour un nouveau service peuvent suivre des chemins différents parce qu'un ancien indicateur conserve la manière dont l'administration a résolu une divergence précédente.

Les programmes de modernisation dérapent lorsqu'ils déclarent des champs étranges obsolètes avant d'en suivre l'usage. Un code d'un caractère peut choisir une branche de calcul, supprimer un avis, envoyer un dossier en examen manuel ou conserver une décision antérieure. Le retirer peut modifier le paiement d'une personne sans provoquer d'erreur logicielle. Le programme tourne, l'API renvoie un succès et le défaut n'apparaît que lorsqu'un demandeur ou un agent conteste le résultat.

Le remplacement d'un calcul de prestations exige donc des preuves au niveau de la décision. Pour chaque dossier enregistré, capturez les entrées normalisées, la version des règles, les calculs intermédiaires, le montant final, la période d'effet, les avis, les codes motif et le routage vers l'examen manuel. Masquez ou tokenisez les données personnelles avant qu'elles quittent leur périmètre autorisé. Dans un environnement réglementé, l'infrastructure de test et les modèles peuvent devoir tourner dans le même périmètre que les données sources.

La pression augmente lorsque les changements législatifs prennent trop de temps, que les anciennes interfaces empêchent de rapprocher les dossiers en sécurité, que le personnel ne sait plus expliquer certains chemins ou que l'approvisionnement de la plateforme se réduit. Le contrôle public rend une réécriture précipitée particulièrement dangereuse. La vitesse de changement compte, mais la reproductibilité des décisions compte davantage.

Ces systèmes sont restés car le risque était asymétrique

Conserver un parc COBOL opérationnel était souvent le choix financièrement sensé. Le coût de l'attente s'accumulait lentement sous forme de maintenance, de livraisons ralenties et de risque humain. Le coût d'un remplacement défectueux arrivait d'un coup sous forme de soldes erronés, de règlements ratés, de mauvaises couvertures ou de prestations mal calculées.

Plusieurs conditions renforçaient cette asymétrie. Les fonctions transactionnelles et de lot du mainframe géraient déjà planification, contrôle d'accès, reprise et entrées-sorties massives. Les mises à niveau du matériel et du compilateur prolongeaient la plateforme sans imposer une réécriture. Des formats de fichier stables permettaient aux canaux récents de s'intégrer en bordure. Surtout, l'entreprise possédait des preuves de production que l'ancien chemin fonctionnait, dont des décennies d'exceptions absentes de tout cahier des charges.

L'affirmation populaire selon laquelle COBOL a survécu par peur du changement est trop simpliste. Les dirigeants ont financé de nombreux changements autour de ces noyaux. Ils ont remplacé les terminaux par des interfaces web, introduit des courtiers de messages, exposé des services et déplacé le reporting. Ils ont évité de remplacer le centre avec état parce que l'analyse économique ne compensait pas le risque.

Une autre recommandation populaire consiste à traduire chaque paragraphe COBOL en code équivalent dans un langage récent. Elle séduit car elle produit un taux de conversion mesurable et garde le comportement proche de la source. Comme état final, elle est mauvaise. Une traduction paragraphe-vers-fonction conserve l'état global, les frontières conçues comme des fichiers, les hypothèses de lot et des décennies de compromis structurels. L'organisation possède alors une architecture mainframe écrite dans une syntaxe inhabituelle, souvent avec de moins bons outils d'exploitation.

Une décision saine sépare trois questions. La plateforme actuelle est-elle assez fiable pour le prochain horizon de planification? L'organisation peut-elle modifier les règles métier à la vitesse requise? Sait-elle encore reprendre et expliquer les échecs sans dépendre d'une ou deux personnes? Un «oui» à la première n'annule pas un «non» à l'une des autres.

La longévité crée aussi une fausse confiance dans la documentation. Les cahiers d'exploitation décrivent souvent le planning normal et la dernière procédure de reprise que quelqu'un a pensé à écrire. Ils ne consignent pas forcément pourquoi un total de contrôle exclut une source, pourquoi un fichier doit précéder un autre ou pourquoi un opérateur accepte un code retour non nul mais s'arrête au suivant. Ces choix survivent comme habitudes. Une migration les découvre lorsqu'une exécution parallèle diverge, donc tard et à grands frais.

Traitez le savoir opérationnel comme une logique de production. Observez un cycle entier, avec heure limite, reprise, rapprochement, arrivée tardive et réparation manuelle. Demandez aux opérateurs d'expliquer les preuves auxquelles ils se fient, puis reliez ces preuves aux travaux et données qui les produisent. Si quelqu'un utilise une feuille de calcul privée ou une liste de commandes pour clôturer la journée, incluez-la même si les schémas d'architecture l'omettent. Le remplacement exige un contrôle pris en charge ou une décision explicite d'abandonner la pratique.

Ne confondez pas silence et simplicité. Les noyaux mûrs semblent souvent calmes parce que les opérateurs absorbent les irrégularités avant qu'elles n'atteignent la gestion des incidents. Comptez les interventions manuelles, relances, dérogations, rapprochements et appels à d'anciens membres de l'équipe. Ces signaux montrent si la stabilité vient du logiciel ou des personnes qui compensent ses défauts.

L'événement déclencheur se trouve souvent hors du compilateur

COBOL lui-même fixe rarement l'échéance. La décision devient inévitable lorsqu'une contrainte externe supprime la possibilité d'attendre. Un fournisseur cesse de prendre en charge une base, une couche écran, un ordonnanceur ou un produit d'intégration. Une fusion impose d'unifier deux grands livres incompatibles. Un nouveau produit exige un comportement intrajournalier d'un noyau nocturne. Une évolution réglementaire demande une traçabilité que le flux actuel ne fournit pas à coût acceptable. Un mainteneur central part avec la connaissance de la reprise.

Le coût de plateforme peut contribuer, mais comparer seulement les licences donne un dossier de migration faible. Un remplacement distribué a ses propres coûts de calcul, d'observabilité, de stockage, de réseau, de sécurité et de personnel. Si le projet suppose une infrastructure incroyablement bon marché, il échouera à l'arrivée des volumes et de la rétention de production.

Le risque humain exige aussi de la précision. «Les développeurs COBOL partent à la retraite» ne dit pas au CTO quoi approuver. Mesurez la propriété au niveau des fonctions métier. Identifiez qui sait expliquer la reprise de fin de mois, changer une règle de prime, justifier pourquoi un code d'écriture contourne une file et rapprocher un traitement de prestations. Le danger vient de la concentration du savoir, pas de l'âge moyen d'une communauté linguistique.

La pression architecturale devient décisive quand chaque nouvelle capacité doit passer par quelques frontières rigides de fichiers ou de transactions. Les équipes ajoutent des adaptateurs, dupliquent les référentiels et attendent une confirmation de lot. Le coût finit par apparaître en retard produit et en ambiguïté opérationnelle plutôt que sur une facture mainframe. Le remplacement trouve alors un propriétaire hors de l'infrastructure: le dirigeant chargé de lancer des produits, de réunir des opérations ou de tenir une date légale.

Rédigez une note sur l'événement déclencheur avant d'approuver le travail. Nommez la contrainte, la date ou condition qui la rend obligatoire, les résultats métier touchés, la durée de coexistence acceptable et les preuves requises pour la bascule. Si la note dit seulement «dette technique», le périmètre dérivera car personne n'a défini la décision que le projet doit rendre possible.

Le risque de migration vit entre les composants

Une réécriture fiable commence par découvrir le comportement observable de tout le parc. L'analyse des sources compte, mais le code seul ne révèle ni dérogations de l'ordonnanceur, ni actions des opérateurs, ni formes réelles des données, ni consommateurs non documentés, ni règles dans les tables. L'inventaire doit relier programmes, travaux, jeux de données, objets de base, files, écrans, rapports et accusés en aval.

Partez des chemins de production plutôt que des dossiers du dépôt. Pour un résultat métier, suivez l'événement initial jusqu'à l'écriture ou l'avis final. Notez chaque composant, entrée, sortie, effet secondaire, point de contrôle et action de reprise. Recommencez pour les exceptions: entrée dupliquée, référence manquante, panne partielle de base, arrivée tardive, reprise après création d'une sortie et correction manuelle.

Un enregistrement de comportement peut prendre cette forme simple:

{
  "case_id": "settlement-late-file-restart",
  "inputs": ["accepted-transactions", "fee-table-v17"],
  "pre_state": "checkpoint-6-complete",
  "action": "restart-from-checkpoint-7",
  "outputs": ["posted-generation", "exception-generation"],
  "invariants": ["debits-equal-credits", "no-duplicate-posting"],
  "evidence": ["job-log", "control-report", "ledger-query"]
}

Cet enregistrement ne dépend volontairement d'aucune implémentation. Il précise ce qui doit rester vrai et l'origine de la preuve. Construisez ces enregistrements à partir de variantes réelles, puis ajoutez des cas limites conçus pour les frontières que le trafic n'a peut-être pas exercées pendant l'observation.

Exécutez les anciens et nouveaux chemins avec la même entrée acceptée et comparez des résultats normalisés. La normalisation retire les valeurs qui peuvent légitimement différer, telles que les identifiants générés ou horodatages, tout en conservant l'argent, les dates, le statut, l'ordre significatif, les codes motif et les effets secondaires. Stockez les écarts comme pièces révisables. Un compteur vert sans différence concrète encourage l'abandon d'écarts inexpliqués.

Le trafic enregistré est une preuve forte, pas une spécification complète. Il ne prouve que les cas observés. Associez-le aux branches tirées du code, valeurs de copybook, domaines des tables, entretiens avec les opérateurs et procédures de rapprochement. La distinction importe: les tests de rejeu mesurent la compatibilité avec l'usage observé, tandis que les tests de règles couvrent le comportement valide absent de la capture.

Sécurité et confidentialité façonnent la méthode. Les enregistrements de production peuvent contenir des données de compte, police, santé ou identité. Gardez capture, tokenisation, exécution des modèles et comparaison dans l'environnement autorisé lorsque les données ne peuvent pas en sortir. Conservez les relations référentielles dans les scénarios tokenisés, sinon de nombreuses règles entre dossiers deviennent impossibles à tester.

La représentation des données mérite sa propre surface de test. Les copybooks peuvent décrire des décimaux compactés, champs signés, superpositions, groupes répétés et valeurs dont le sens dépend d'un autre champ. Les fichiers peuvent utiliser EBCDIC, des longueurs fixes ou des conventions locales pour les valeurs manquantes. Un analyseur qui supprime silencieusement les espaces ou normalise une date invalide peut fusionner des états autrefois distincts. Générez des scénarios de frontière pour chaque forme déclarée, puis comparez valeurs lues et rejets avant les règles métier.

Des copybooks partagés ne garantissent pas un sens partagé. Un programme peut traiter un code comme état de compte, un autre comme décision de routage. Suivez les lectures et écritures, pas seulement les noms. Si les formats ont changé, identifiez les producteurs qui peuvent encore envoyer chaque version et la manière dont les consommateurs les distinguent. Ce travail empêche le nouveau modèle canonique d'effacer une information encore nécessaire à un fichier tardif ou un rejeu historique.

La conversion des données et le remplacement de l'application créent des risques différents. Convertir un historique prouve que les dossiers atteignent la forme cible, pas que le traitement de demain créera les bons dossiers. Testez soldes d'ouverture et conversion historique séparément du comportement transactionnel, puis réunissez-les dans une répétition générale traversant une vraie frontière comptable ou de facturation. Rapprochez nombres, totaux, soldes, références orphelines et chaque rejet. Un total juste peut masquer deux erreurs opposées de même montant, donc échantillonnez aussi au niveau de l'écriture et du client.

Les tests de performance doivent reproduire la forme du travail, pas son volume moyen. Un règlement subit des pics d'arrivée et une heure de fin ferme. Un grand livre en ligne a des contraintes de latence et de contention sur les comptes populaires. Un recalcul de prestations peut lire un historique profond et créer plusieurs effets. Préservez ordre et conflits de verrouillage dans les données de test, mesurez le temps de reprise et incluez la consommation en aval. Un producteur rapide qui sature le système suivant n'améliore pas le chemin métier.

Traitez codes retour et messages opérateur comme des interfaces jusqu'à preuve du contraire. Les ordonnanceurs bifurquent dessus, le support les recherche et les procédures les utilisent pour décider si une sortie est complète. Associez chaque ancienne condition à une erreur typée, une règle de reprise, une alerte et une action de récupération. Rendez l'idempotence explicite: une relance après délai ne doit jamais doubler une écriture, un document ou le traitement d'une exception.

Le groupe de revue doit inclure ceux qui rapprochent les résultats, pas seulement ceux qui maintiennent le code. Les opérations financières savent quels totaux certifient le règlement. Les spécialistes des polices connaissent les documents datés à reproduire. Les agents savent quels motifs entraînent un examen manuel. Leurs preuves transforment une différence technique en décision de bascule. Sans elles, l'équipe peut fermer des milliers d'écarts et manquer celui qui modifie un engagement.

Enfin, définissez une règle pour le comportement inconnu. Si l'ancien chemin produit un résultat inexpliqué, ne le copiez pas automatiquement et ne le corrigez pas en silence. Isolez le cas, gardez entrées et preuves, désignez un propriétaire métier et consignez le comportement cible choisi. Cette file contiendra défauts, règles obsolètes et exceptions légitimes. Son rythme de fermeture mesure mieux la préparation que le pourcentage de fichiers convertis.

Remplacez la frontière et prouvez la bascule

La cible doit moderniser la propriété et les interfaces tout en conservant les résultats requis. Définissez des services bornés autour des capacités métier, choisissez un modèle de données durable et rendez explicites les responsabilités en lot et en ligne. Ne laissez pas l'ancienne structure dicter chaque module. Laissez son comportement contraindre chaque résultat matériel externe jusqu'à l'approbation d'un changement par l'entreprise.

Une séquence pratique comporte cinq parties:

1. Figez l'inventaire des points d'entrée, travaux planifiés, stockages et consommateurs du segment métier choisi.
2. Construisez le banc de parité avant le remplacement afin que chaque décision d'implémentation reçoive les mêmes preuves.
3. Implémentez la nouvelle architecture derrière des adaptateurs stables, avec reprise, rapprochement et contrôles opérateur.
4. Faites passer les scénarios historiques et le trafic de production enregistré par les deux chemins, puis classez chaque écart.
5. Basculez avec des critères explicites de retour arrière et gardez le rapprochement actif jusqu'à la fermeture de la fenêtre de risque convenue.

Choisissez des segments qui finissent par un résultat métier vérifiable. «Convertir 200 programmes» n'est pas un segment. «Traiter une source de règlement jusqu'à l'écriture et au rapprochement» en est un. Celui-ci expose les dépendances et fournit aux dirigeants des preuves évaluables.

CodeHero applique cette méthode en lisant ensemble COBOL, JCL et le reste de l'arbre, en réécrivant l'architecture en Go, Rust, TypeScript et Postgres, puis en vérifiant le comportement avec un banc de parité face au trafic de production enregistré. Ses projets sont livrés en moins de 30 jours, y compris avec une exécution isolée dans le périmètre du client lorsque l'environnement l'exige.

La vitesse ne retire pas au propriétaire ses responsabilités de bascule. L'organisation décide encore quels comportements sont contractuels, quelles anomalies corriger, quelles preuves satisfont les équipes de risque et d'audit, et qui autorise un retour arrière. Le code source ne permet pas de déduire ces décisions en sécurité.

Un système COBOL ne doit pas bouger parce que sa syntaxe paraît vieille. Il doit bouger lorsque la frontière actuelle bloque l'entreprise et que le remplacement peut prouver, cas par cas, que l'argent, les droits, l'historique, la reprise et l'explication fonctionnent encore. Approuvez la réécriture lorsque ces deux conditions sont réunies.