Acheter des services de modernisation COBOL ne ressemble à aucun autre achat de prestation logicielle. Le système concerné tourne depuis trente ou quarante ans, plus personne en poste ne le comprend entièrement, et les conséquences d’une erreur se mesurent en déclarations réglementaires manquées plutôt qu’en sprints ratés. Pendant ce temps, toutes les propositions posées sur votre bureau promettent le même résultat à des prix radicalement différents.

Ce guide expose ce que contient réellement une mission sérieuse, en quoi les catégories de prestataires diffèrent, et quelles questions séparent une offre bâtie sur des preuves d’une offre bâtie sur de l’optimisme. Il part du principe que c’est vous qui devrez défendre la décision ensuite.

Ce qu’il faut vérifier : une proposition crédible de modernisation COBOL comprend la découverte, la conception de l’architecture cible, la migration des données, la conversion ou le rehébergement, un programme de tests par comparaison, un fonctionnement en parallèle, la préparation de la bascule et le transfert de compétences. Si une offre ne chiffre que la conversion de code, ce n’est pas un plan de programme, c’est le quart le moins cher de ce plan.

Ce que recouvrent réellement les services de modernisation COBOL

Demandez une proposition à trois prestataires et vous recevrez trois définitions différentes du périmètre. Normaliser cette liste avant de comparer les prix est la chose la plus utile que vous puissiez faire, parce qu’une offre qui omet la moitié du travail paraîtra toujours meilleure sur la page de synthèse.

La découverte et l’analyse viennent en premier. Le prestataire analyse l’ensemble du parc, construit les cartes de dépendances et de lignage des données, repère le code mort et produit un inventaire des programmes, des copybooks, des chaînes de travaux et des objets de base de données. Cette phase doit aussi signaler les constructions qui font le coût : modules Assembleur, schémas transactionnels inhabituels, structures d’enregistrement variantes et tout ce que le compilateur tolère depuis des décennies.

L’architecture cible vient ensuite. Quelqu’un doit décider ce que devient le système : une charge COBOL réhébergée, une base de code convertie dans un langage moderne, un ensemble de services, ou une combinaison étalée dans le temps. Cette décision précède le début de la conversion, et elle doit être documentée avec son raisonnement visible plutôt qu’affirmée.

La migration des données couvre la conception du schéma, l’extraction, la conversion et la réconciliation. Les formats de données du mainframe portent un sens qu’un schéma relationnel ne peut pas exprimer directement, si bien que ce travail est analytique et non mécanique.

La conversion du code ou le rehébergement est la partie sur laquelle tout le monde se concentre, et elle représente en général une minorité de l’effort total. Les outils de migration mainframe en prennent une bonne part en charge, mais pas la totalité, et l’endroit exact où passe cette limite détermine la charge des autres phases.

Les phases que les acheteurs suppriment le plus souvent

Les tests et la comparaison sont l’endroit où part l’argent. Un programme sérieux construit un banc qui fait tourner l’ancien et le nouveau système sur des entrées identiques et compare les sorties champ par champ, puis traite chaque écart jusqu’à ce qu’il soit corrigé ou formellement accepté. C’est un projet logiciel à part entière et il doit être chiffré comme tel.

Le fonctionnement en parallèle et la bascule consistent à exploiter les deux systèmes pendant une durée définie avec les volumes réels de production, puis à basculer avec un plan de retour arrière testé. Les programmes qui sautent cette étape pour gagner du temps sont ceux qui finissent en étude de cas pour de mauvaises raisons.

Le transfert de compétences et le support referment la mission. Vos équipes doivent pouvoir exploiter et faire évoluer le résultat sans le prestataire. Si ce n’est pas un livrable explicite assorti de critères d’acceptation, vous n’avez pas acheté une modernisation, vous avez acheté une dépendance.

Les trois catégories de prestataires et leurs points forts

Le marché se divise en trois groupes aux forces véritablement différentes, et le bon choix dépend davantage de votre parc que d’un quelconque classement.

Les éditeurs d’outils et leurs partenaires avancent avec la conversion automatisée ou une plateforme de rehébergement. Leur technologie est généralement mature et leur débit de conversion réellement impressionnant. Le point d’attention est l’alignement des intérêts : leur intérêt commercial consiste à maximiser la part du travail réalisée par leur produit, ce qui ne coïncide pas toujours avec une base de code que vous aurez plaisir à maintenir. Ils lient aussi votre production à leur environnement d’exécution, une dépendance qu’il faut valoriser.

Les intégrateurs mondiaux apportent l’échelle, la gouvernance de programme et la capacité à staffer un effort pluriannuel. Si votre parc compte des millions de lignes réparties sur plusieurs entités, cette capacité compte et peu d’autres acteurs peuvent la fournir. La contrepartie tient à la structure de coûts et à la distance entre les personnes qui ont rédigé la proposition et celles qui feront le travail. Demandez précisément qui compose l’équipe, où ces personnes se trouvent et quelle est leur expérience.

Les cabinets d’ingénierie spécialisés sont plus petits, travaillent avec des profils seniors du début à la fin et sont généralement neutres vis-à-vis des outils, faute de produit à vendre. Ils conviennent aux parcs de quelques centaines de milliers de lignes, aux programmes par étapes et aux situations où la difficulté tient à la logique métier plutôt qu’au volume. Ils ne peuvent pas staffer un programme de deux cents personnes, et ils devraient le dire.

Il n’existe pas de réponse universellement correcte. Il existe une réponse correcte pour un parc donné, et tout prestataire qui prétend que son modèle convient à toutes les situations vous apprend quelque chose d’utile sur sa façon de vendre.

Les questions qui révèlent une offre faible

Les questionnaires d’achat font rarement remonter ce qui compte. Ces questions, si.

« Convertissez notre pire module et montrez-nous le résultat. » Choisissez le programme que tout le monde évite, idéalement un qui appelle de l’Assembleur et utilise un enregistrement variant à plusieurs niveaux. Demandez à voir le code généré, pas un résumé. Un prestataire confiant dans son approche le fera pour un forfait de cadrage modeste et défini. Une réticence est déjà une réponse.

« Comment traitez-vous l’arithmétique décimale et l’ordre de tri ? » Les champs décimaux condensés et la séquence de collation du mainframe produisent tous deux des écarts qui n’apparaissent que dans les résultats financiers et dans l’ordre des états. Les réponses doivent être précises et techniques. Le flou sur ce point annonce une recette utilisateur difficile.

« Que contient exactement votre périmètre de tests, et qui écrit le banc de comparaison ? » Vous cherchez un livrable nommé, une estimation de charge et une clarté sur qui fournit des données représentatives de la production. Si les tests sont décrits comme un pourcentage de la construction, le prestataire devine.

« Que faites-vous des écarts que vous n’arrivez pas à expliquer ? » Tout programme trouve des sorties qui diffèrent sans que personne sache pourquoi. Les bons prestataires décrivent un processus de tri avec validation métier. Ceux qui affirment que cela n’arrive pas n’ont jamais terminé un programme, ou ne sont pas francs.

« À qui appartient le code source produit, et pouvons-nous partir ? » La réponse doit être que tout vous appartient pleinement, sans licence d’exécution nécessaire pour continuer à exploiter. Si une partie de la réponse implique la licence continue d’une couche propriétaire, comprenez exactement ce qui arrive à votre production le jour où vous cessez de payer.

« Montrez-nous un programme qui s’est mal passé et ce que vous avez changé. » Toute organisation qui en a mené plus d’une poignée en a un. La réponse vous dit si vous parlez à des ingénieurs ou à une fonction commerciale.

Comment sont tarifés les services de modernisation COBOL

Les modèles de tarification varient, et chacun répartit le risque différemment. Comprendre cette répartition compte davantage que le chiffre affiché.

La régie est le modèle le plus honnête pour un travail comportant de véritables inconnues, et le plus inconfortable pour un conseil d’administration. Elle convient à la découverte, qui devrait presque toujours être achetée séparément et en premier, précisément pour que le reste puisse être chiffré sur des preuves plutôt que sur des hypothèses.

Le forfait par module ou par millier de lignes est courant pour la conversion et raisonnable une fois que la découverte a établi ce que contiennent les modules. Lisez les exclusions attentivement. Ces prix supposent en général du code situé dans une bande de complexité définie, et tout ce qui en sort est retarifé au cas par cas : c’est là que loge la variance.

La tarification à l’aboutissement, où le paiement est lié à l’équivalence fonctionnelle acceptée, aligne bien les intérêts mais exige des critères d’acceptation assez précis pour trancher un désaccord. Définir correctement ces critères vaut l’effort que cela demande.

Méfiez-vous d’un prix ferme et définitif pour un programme entier annoncé avant la découverte. Ce n’est pas une démonstration de confiance. Soit il intègre assez de provision pour couvrir le pire scénario, et vous payez alors un risque qui ne se matérialisera peut-être pas, soit il est optimiste et reviendra sous forme d’avenants dès que les modules difficiles apparaîtront. Aucune des deux options n’est une affaire.

Sur la question des remises, ce marché ne fonctionne pas vraiment ainsi. Les réductions significatives viennent du resserrement du périmètre, du découpage du programme pour que les phases suivantes profitent de ce qu’a appris la première, ou du retrait du code que la découverte montre inutilisé. Un prestataire qui baisse fortement son prix sans changer le périmètre vient de vous dire que le premier chiffre était arbitraire. Notre guide des coûts et des délais de migration COBOL détaille où part réellement le budget.

Les clauses contractuelles à imposer

Quelques clauses protègent le résultat mieux que n’importe quelle quantité de gouvernance.

Exigez la propriété pleine et entière de tout le code source livré, des schémas, des scripts et des actifs de test, y compris le banc de comparaison. Ce banc est un actif que vous réutiliserez pendant des années.

Définissez la recette comme l’équivalence fonctionnelle démontrée sur des jeux de données convenus, et non comme la livraison de code. La distinction entre « la conversion est terminée » et « les sorties correspondent » constitue tout le projet.

Réclamez une structure par étapes assortie de vraies portes de sortie. Un programme découpé en découverte, pilote, conversion progressive et bascule vous permet de vous arrêter après n’importe quelle phase avec quelque chose de valeur en main. Une mission monolithique unique ne le permet pas.

Nommez les personnes clés dans le contrat et prévoyez une clause de substitution. L’écart entre l’équipe qui a présenté et l’équipe qui arrive est la plainte la plus fréquente sur ce marché.

Enfin, faites du transfert de compétences un livrable doté de ses propres critères d’acceptation, prouvé par vos équipes réalisant une modification réelle sans aide. Sinon il devient un jeu de diapositives livré la dernière semaine.

Parlez à des ingénieurs plutôt qu’à des revendeurs

Mecanik intervient sur les programmes de modernisation COBOL et de migration COBOL en tant que cabinet d’ingénierie indépendant. Nous ne revendons pas de plateforme de conversion, donc notre recommandation d’outillage reflète ce dont votre code a besoin plutôt que ce que nous licencions.

Nous commençons par la découverte et un pilote payant sur votre module le plus difficile, parce que cela produit une estimation ancrée dans votre code réel au lieu d’une moyenne sectorielle. À partir de là, nous pouvons convertir, réhéberger, ou vous dire qu’aucune des deux options n’est justifiée pour l’instant, ce qui est parfois la bonne réponse. Nos pages sur le service de migration COBOL détaillent les phases, et notre guide sur la stratégie de modernisation mainframe traite du choix entre réécriture, refactoring et changement de plateforme, qui vient en amont.

Dites-nous approximativement la taille du parc et ce qui impose le calendrier, et nous vous dirons à quoi ressemble un programme réaliste.

À lire aussi : Migration COBOL vers Java - Guide entreprise UK , Migration COBOL vers C# : guide UK 2026 , Migration COBOL vers Python et Migration COBOL vers Go : guide pour l’entreprise UK .

Questions fréquentes

Que comprennent les services de modernisation COBOL ? Une mission complète couvre la découverte et l’analyse, la conception de l’architecture cible, la migration des données, la conversion ou le rehébergement, un programme de tests par comparaison, le fonctionnement en parallèle, la préparation de la bascule et le transfert de compétences. Les offres qui ne chiffrent que la conversion de code ne couvrent qu’une minorité du travail réel.

Qui réalise les migrations de COBOL vers un langage moderne ? Trois groupes le font : les éditeurs d’outils et leurs partenaires d’intégration, les intégrateurs mondiaux et les cabinets d’ingénierie spécialisés indépendants. Les éditeurs apportent une automatisation mature, les intégrateurs l’échelle pour les très grands parcs, et les spécialistes des ingénieurs seniors et une neutralité d’outillage pour les programmes de taille moyenne.

Comment sont tarifés les projets de modernisation COBOL ? Les modèles courants sont la régie, le forfait par module ou par millier de lignes, et la tarification à l’aboutissement liée à l’équivalence fonctionnelle. La découverte devrait être achetée séparément et en premier, afin que le reste soit chiffré sur des preuves plutôt que sur des hypothèses.

Faut-il accepter un prix ferme avant la découverte ? En général non. Un prix ferme annoncé sans analyse est soit gonflé d’une provision dont vous n’aurez peut-être pas besoin, soit optimiste et voué à revenir sous forme d’avenants. Achetez d’abord la découverte, puis servez-vous de ses conclusions pour obtenir des prix fermes sur les phases suivantes.

Comment vérifier qu’un prestataire maîtrise mon code ? Demandez-lui de convertir votre module le plus difficile pendant le cadrage et de vous montrer le code produit. Choisissez quelque chose contenant des appels Assembleur, des enregistrements variants et de l’arithmétique décimale condensée. Ce qu’il produit, et la facilité avec laquelle il accepte, en dit plus que n’importe quel appel de référence.