Pourquoi la modernisation de COBOL coûte plus cher que ne le laisse généralement entendre le budget

La modernisation de COBOL est rarement une simple migration de code. Il s'agit d'un projet de récupération des connaissances, dont le logiciel n'est que l'aboutissement.

C'est un aspect que de nombreux budgets de modernisation sous-estiment. L'estimation suppose que l'organisation remplace du code ancien par du code moderne. En réalité, l'équipe essaie souvent de redécouvrir des décennies de règles métier, d'exceptions opérationnelles, de conventions de données, de processus par lots, de dépendances de reporting et de connaissances institutionnelles qui existent désormais principalement à l'intérieur du système existant lui-même.

De récents exemples de modernisation au niveau fédéral montrent les deux aspects du problème. En avril 2026, le Department of Health and Human Services a annoncé avoir remplacé un système de paie existant basé sur COBOL par une plateforme sécurisée dans le cloud, destinée à réduire la charge administrative et à améliorer la prestation de services. Parallèlement, le GAO a indiqué en 2025 que l'IRS avait suspendu des programmes de modernisation en mars 2025 afin de réévaluer ses priorités et d'élaborer un nouveau cadre de modernisation.

Les deux exemples mènent à la même conclusion : la modernisation d'un système existant réussit ou s'enlise selon la capacité de l'organisation à comprendre ce que le système fait réellement avant d'essayer de le remplacer.

COBOL n'est pas seulement un code ancien

COBOL reste important, car il continue de faire fonctionner des systèmes essentiels dans les secteurs bancaire, assurantiel, public, logistique, de la paie et dans d'autres environnements traitant de nombreuses transactions. Les estimations du secteur citent couramment COBOL comme support d'une part importante des transactions effectuées par les distributeurs automatiques et des paiements, et IBM a estimé que des centaines de milliards de lignes de COBOL restent utilisées en production dans les principaux secteurs.

La persistance de ces systèmes ne s'explique pas simplement par la négligence. Beaucoup sont fiables, profondément intégrés et liés à des processus stratégiques qui ne peuvent tolérer une interruption inconsidérée. Ils gèrent souvent la paie, le traitement des impôts, les prestations, les sinistres, les transactions financières, les règles d'éligibilité, le règlement par lots et d'autres flux de travail pour lesquels l'exactitude compte davantage que la nouveauté.

C'est pourquoi la modernisation de COBOL diffère du remplacement d'un ancien site marketing ou de la refactorisation d'une application web familière. Une équipe ne fait pas que mettre à jour la technologie. Elle traduit la logique institutionnelle d'une époque de l'informatique vers une autre.

Le véritable problème réside dans la logique métier cachée

La partie la plus difficile de la modernisation de COBOL n'est souvent pas la syntaxe. Ce sont les sémantiques.

Un système existant peut contenir des règles ajoutées au fil des décennies : évolutions réglementaires, logique fiscale, gestion des exceptions, règles d'éligibilité, particularités des rapports, logique de rapprochement et conditions ponctuelles créées pour répondre à des exigences qui ne sont peut-être plus documentées nulle part ailleurs.

Ces règles ne sont pas toujours isolées dans des modules bien structurés. Elles peuvent être intégrées à des routines de validation, des traitements par lots, des formats de fichiers, des processus de reporting, des parcours d'écran ou des copybooks partagés. Une condition qui semble relever d'un détail d'implémentation peut en réalité représenter une exigence réglementaire, une règle comptable ou une exception opérationnelle essentielle à la mission.

C'est à ce stade que les projets de modernisation deviennent coûteux. Si l'équipe réécrit un comportement qu'elle ne comprend pas, elle risque de perturber l'activité. Si elle préserve aveuglément chaque comportement, elle risque de transférer des décennies de dette technique dans le nouveau système. Le travail consiste à déterminer quels comportements hérités sont essentiels, lesquels sont accidentels et lesquels doivent être repensés.

Pourquoi les estimations logicielles classiques déraillent

Une estimation logicielle classique suppose que l'équipe comprend suffisamment bien les exigences pour construire la solution. La modernisation de COBOL commence souvent ailleurs. La première tâche majeure consiste à découvrir les exigences en lisant le système.

Cette découverte peut être lente, car les systèmes existants sont généralement couplés de façons auxquelles les équipes modernes ne s'attendent pas toujours.

Structures de données partagées : Plusieurs programmes peuvent dépendre des mêmes copybooks, formats d'enregistrements ou conventions de champs.
Dépendances entre traitements par lots : Un processus peut dépendre de fichiers créés par des traitements exécutés plusieurs heures auparavant, dans un ordre précis.
Encodages et formats numériques : EBCDIC, décimaux condensés, enregistrements de longueur fixe et conventions propres aux mainframes peuvent nécessiter une traduction minutieuse.
Contrats informels : Les systèmes peuvent échanger des données par l'intermédiaire de fichiers, de files d'attente ou de traitements planifiés, sans le type de contrat d'API qu'attendrait une équipe moderne.
Exceptions non documentées : Les règles métier peuvent n'exister que sous forme de conditions dans d'anciens programmes.

Les outils d'analyse statique peuvent aider à identifier les dépendances, mais ils n'indiquent pas automatiquement à l'équipe pourquoi ces dépendances existent ni lesquelles sont importantes pour l'entreprise.

Trois facteurs de coût sous-estimés

1. Règles métier non documentées

Les systèmes COBOL contiennent souvent des règles métier implémentées directement dans le code, car c'était à l'époque la voie la plus rapide ou la plus pratique. Au fil des années, ces règles s'accumulent. La documentation prend du retard. Les développeurs d'origine partent à la retraite. Le code devient la source de vérité.

Les équipes de modernisation doivent extraire ces règles avec soin. Cela peut nécessiter l'analyse du code, l'examen des données de test, la comparaison du comportement en production, des entretiens avec les parties prenantes, des séances avec des experts métier et une vérification par rapport aux politiques ou exigences opérationnelles actuelles.

Ce n'est pas facultatif. Omettre une seule règle peut avoir des conséquences financières, réglementaires ou sur la prestation de services.

2. Mappage et transformation des données

Passer des formats de données de l'ère des mainframes à des bases de données, des API ou des systèmes orientés événements modernes n'est pas une simple exportation. Les enregistrements de longueur fixe, les décimaux condensés, la surcharge de champs, les encodages hérités, les problèmes historiques de qualité des données et les relations implicites peuvent tous créer des risques de migration.

Un modèle de données moderne impose également des choix. Le nouveau système doit-il conserver l'ancienne structure des enregistrements ? Faut-il normaliser les données ? Faut-il exposer des API ? Les particularités historiques doivent-elles être conservées pour assurer la compatibilité ? Comment les rapports seront-ils rapprochés entre les anciens et les nouveaux systèmes pendant la transition ?

C'est souvent lors de la migration des données que les projets de modernisation découvrent que l'ancien système effectuait davantage de traductions et de nettoyages que quiconque ne le pensait.

3. Validation du comportement

Dans la modernisation de COBOL, tester le nouveau système signifie prouver qu’il se comporte correctement dans les scénarios hérités, et pas seulement que le nouveau code réussit les tests unitaires.

Cela peut nécessiter des exécutions en parallèle, la comparaison des traitements par lots, la relecture des transactions, des suites de régression, des rapports de rapprochement et un examen attentif des cas limites. L’équipe doit savoir si le système modernisé produit le même résultat lorsque ce même résultat est requis, et un résultat délibérément différent lorsque le comportement hérité est corrigé ou repensé.

La validation peut nécessiter autant d’efforts que l’implémentation, car le coût d’une erreur subtile peut être élevé.

Ce que l’IA peut faire, et ce qu’elle ne peut pas faire

L’analyse de code assistée par l’IA transforme certaines étapes du processus de modernisation de COBOL. Les outils peuvent aider à analyser le code source COBOL, à résumer les programmes, à identifier les dépendances, à générer de la documentation, à expliquer des constructions peu familières et à proposer des transformations candidates.

Federal News Network a indiqué en 2024 que l’OPM avait reçu un financement du Technology Modernization Fund pour un projet de deux ans débutant en 2025, destiné à moderniser le code COBOL qui prend en charge son système de retraite, notamment grâce à l’utilisation de l’IA pour analyser et transformer l’environnement hérité. Ce type de travail montre où l’IA peut être précieuse : réduire le temps nécessaire à la compréhension de l’ancien code et accélérer la documentation.

Mais l’IA ne supprime pas la nécessité d’une expertise humaine du domaine.

Un modèle peut aider à expliquer ce qu’une section de COBOL semble faire. Il ne peut pas garantir que ce comportement est toujours légalement requis, nécessaire sur le plan opérationnel ou sans danger à modifier. Il peut suggérer un équivalent moderne. Il ne peut pas assumer les conséquences si la migration modifie la manière dont sont traités les prestations, la paie, les impôts, les demandes d’indemnisation ou les transactions financières.

Il est préférable de considérer l’IA comme un accélérateur de la découverte et de la documentation, et non comme un substitut à l’expertise métier, au jugement architectural ou à la validation.

Ce qui fonctionne réellement

La modernisation de COBOL fonctionne mieux lorsque les équipes la considèrent comme une récupération progressive des connaissances et une réduction des risques.

Commencer par la découverte du système : Répertorier les programmes, fichiers, traitements, intégrations, structures de données, rapports, utilisateurs et processus métier avant de s’engager dans une voie de migration.
Récupérer les règles métier : Extraire et documenter les règles à partir du code, des traitements par lots, des structures de données et du comportement en production. Les valider avec des experts du domaine chaque fois que possible.
Établir une cartographie des comportements : Comprendre ce que fait le système, et pas seulement comment le code est organisé.
Moderniser progressivement : Utiliser des approches telles que le modèle du figuier étrangleur, l’encapsulation par API, l’extraction de services ou le remplacement progressif des modules, plutôt que de tout miser sur une réécriture massive réalisée en une seule fois.
Valider en continu : Comparer les résultats des anciens et des nouveaux systèmes dans des scénarios réalistes, des cas limites, des cycles de traitement par lots et des données historiques.
Décommissionner de manière réfléchie : Conserver l’ancien système disponible jusqu’à ce que le remplacement ait été validé et que le risque opérationnel soit suffisamment faible pour retirer l’ancienne voie.

Cette approche est plus lente que ne le souhaiterait une présentation. Elle est aussi plus sûre que de découvrir après le lancement que l’équipe a remplacé le code sans préserver les comportements essentiels.

Le budget le plus cohérent

Un budget réaliste de modernisation de COBOL ne devrait pas considérer la découverte comme une petite tâche préliminaire. La découverte constitue une phase majeure du travail.

Une structure plus honnête ressemble généralement à ceci :

Première phase : découverte et documentation. Reconstituer la cartographie du système, les règles métier, les structures de données, les dépendances des traitements par lots, les points d’intégration et les risques liés à la modernisation. L’analyse assistée par l’IA peut être utile ici, mais la validation humaine reste essentielle.
Deuxième phase : migration progressive. Déplacer les fonctionnalités par tranches, en commençant par les domaines présentant le moins de risques ou la plus grande valeur, afin que l’équipe puisse démontrer la pertinence de l’approche avant de l’étendre.
Troisième phase : validation et décommissionnement. Effectuer les comparaisons, rapprocher les résultats, confirmer la préparation opérationnelle, former les utilisateurs, retirer soigneusement les composants hérités et préserver les éléments probants nécessaires à l’audit.

Si un plan de modernisation n’accorde que quelques semaines à la découverte et suppose que l’implémentation sera simple, il comporte probablement des risques cachés. L’organisation ne budgétise peut-être pas le problème réel.

Comment Ridiculous Engineering envisage la modernisation des systèmes hérités

Chez Ridiculous Engineering, nous abordons la modernisation des systèmes hérités d’abord comme un problème de connaissances métier et d’architecture, avant de la considérer comme un problème de conversion de code.

Cela est important, car le système hérité connaît souvent des éléments que l’organisation a oubliés. Les règles métier, la logique de conformité, les flux de travail, les rapports et les parcours d’exception peuvent n’exister que dans le système en fonctionnement. Avant de choisir une plateforme de remplacement ou de réécrire le code, l’équipe doit comprendre ce qui doit être préservé, ce qui doit changer et ce qui peut être retiré.

Nous aidons les organisations à structurer leur travail de modernisation autour de cette réalité. Cela peut inclure l’évaluation de l’état actuel, l’inventaire du système, la découverte des règles métier, la cartographie des flux de données, la planification de l’architecture, la stratégie d’API, la conception d’une migration progressive, la planification des tests, la documentation et l’accompagnement de la mise en œuvre.

Pour COBOL et les autres systèmes anciens utilisés depuis longtemps, l’objectif n’est pas de donner l’illusion de la modernisation. Il s’agit de réduire le risque opérationnel tout en préservant les comportements métier qui restent importants.

Budget pour l’archéologie

La modernisation de COBOL coûte plus cher que prévu lorsque les organisations budgétisent les modifications du code et négligent la récupération des connaissances.

Le code est ancien, mais le véritable risque ne réside pas dans son ancienneté. Le véritable risque consiste à remplacer un système critique sans comprendre la logique métier qui y est intégrée.

Si votre organisation évalue une modernisation de COBOL, le remplacement d’un système existant ou l’analyse de code assistée par l’IA, Ridiculous Engineering peut vous aider à planifier le travail de manière réaliste. Nous pouvons vous aider à évaluer ce dont vous disposez, à retrouver les règles importantes, à concevoir une approche de migration et à construire une démarche qui réduit les risques au lieu de prétendre que l’ancien système est plus simple qu’il ne l’est.

La modernisation ne consiste pas simplement à traduire du code. Il s’agit de traduire des décennies de réalité métier en systèmes que l’organisation peut maintenir, exploiter et auxquels elle peut faire confiance.

Sources et lectures complémentaires : HHS : le HHS remplace son ancien système de paie, GAO : l’IRS élabore un nouveau cadre de modernisation, Rapport du GAO : cadre de modernisation de l’IRS, Federal News Network : une subvention du TMF aide l’OPM à moderniser le code COBOL grâce à l’IA, FedTech : le casse-tête du COBOL du gouvernement, Forbes India : COBOL, IBM et les risques liés aux anciens systèmes

Pourquoi votre projet de modernisation de COBOL coûtera trois fois plus que prévu au budget — et comment y remédier