COBOL : reprendre un existant que personne n’a écrit
Le COBOL n’est pas un langage mort, c’est un langage dont les auteurs sont partis. Les programmes tournent, les résultats sont justes, et plus personne dans l’équipe ne sait pourquoi telle règle est écrite ainsi. C’est ce vide-là que je viens combler.
Pourquoi ce code est toujours en production
Trois raisons reviennent, et aucune n’est de la nostalgie. D’abord l’exactitude : l’arithmétique décimale du COBOL calcule en base dix, comme un comptable, là où un flottant arrondit. Sur des montants, des intérêts ou des cotisations, ce détail vaut des années de contentieux évités. Ensuite la stabilité : un programme corrigé pendant vingt ans contient vingt ans de cas particuliers qu’aucune spécification neuve ne saura réénumérer. Enfin le coût : remplacer marche rarement du premier coup, et l’échec se paie en production.
Le risque réel ne porte donc pas sur le langage. Il porte sur la capacité de l’équipe à modifier ce code sans casser ce qu’elle ne voit pas.
Ce qui bloque concrètement
Le code est la seule spécification
La documentation, quand elle existe, décrit l’intention de départ, pas les vingt années de correctifs qui ont suivi. La règle de gestion vraie est dans une condition imbriquée, au milieu d’un paragraphe de quatre cents lignes, souvent commentée dans les termes de son époque. La lire demande autant de patience que de technique.
Les dialectes ne sont pas interchangeables
Le COBOL de la norme est une chose, le COBOL qui tourne chez vous en est une autre. Extensions du compilateur, appels système propres à la plateforme, gestion des fichiers indexés, ordre de tri des caractères, tailles et alignements. Ces écarts ne se voient pas à la lecture du programme, et ce sont eux qu’il faut avoir en tête avant de toucher à quoi que ce soit.
Les données ont une forme, pas seulement un contenu
Un enregistrement COBOL est une structure physique : positions, tailles, représentation condensée des nombres, zones redéfinies, tables à occurrences variables. Les copybooks décrivent cette forme et sont partagés entre des dizaines de programmes. Toucher à un copybook, c’est toucher à tout ce qui l’inclut — y compris aux fichiers déjà écrits sur disque.
Ce que je fais sur un parc COBOL
Maintien en condition opérationnelle
Analyse et correction d’anomalies, évolutions réglementaires, adaptation de chaînes batch, traitement des incidents de production. Le travail ordinaire, mené par quelqu’un qui lit ce code sans avoir besoin qu’on le lui traduise.
Audit et reconstitution documentaire
Inventaire des programmes, des copybooks et des chaînes, arbre des appels, dépendances entre traitements, identification du code mort et des règles de gestion réellement appliquées. Le livrable est un document qui reste après mon départ, et qui sert aussi bien à maintenir qu’à décider d’une migration.
Formation des équipes qui héritent
Sur votre code plutôt que sur des exemples d’école : structure des divisions, fichiers séquentiels et indexés, copybooks et appels, particularités de votre compilateur, méthode de lecture d’un programme inconnu. Trois à cinq jours, en intra-entreprise ou à distance. C’est la prestation qui vous rend autonome, et je la préfère aux missions qui s’éternisent.
Appui sur un projet de migration
Aux côtés de l’intégrateur, je tiens le côté existant : ce que le code fait vraiment, ce qui doit être reproduit à l’identique, ce qui peut être simplifié, et ce qui ne se transpose pas.
Le piège du transcodage automatique
Les outils de conversion convertissent la syntaxe, et ils le font bien. Ils ne convertissent pas ce qui compte. L’arithmétique décimale devient du flottant, et les centimes se mettent à diverger. L’ordre de tri change avec le jeu de caractères, et des états édités depuis quinze ans sortent dans un ordre différent. Les zones redéfinies deviennent des structures que le langage cible ne sait pas exprimer. Le résultat compile, passe les tests unitaires écrits par l’outil, et tombe sur le premier cas réel.
Cela ne condamne pas le transcodage : cela dit qu’il se pilote, avec un jeu de tests construit sur les données de production et quelqu’un capable d’expliquer chaque écart. C’est ce travail-là que je fais.
D’où vient cette expertise
J’ai débuté dans l’informatique de gestion sur gros systèmes Bull et IBM — c’est-à-dire au cœur même du COBOL, là où il a été écrit en quantité. Je suis ensuite passé à l’informatique industrielle, sur matériel DEC puis sur ce qui a suivi, et j’y ai retrouvé le même langage sous d’autres compilateurs. Quarante ans en tout, dont quinze à Fos-sur-Mer, où j’ai dirigé le service informatique de process du département Fonte. Avoir vu le COBOL sous plusieurs compilateurs et plusieurs systèmes est plus utile que de l’avoir vu sous un seul très longtemps.
Pour qui
Les DSI dont l’équipe COBOL s’est réduite à une ou deux personnes. Les sociétés de services qui ont remporté une TMA sur un parc qu’elles découvrent. Les directions qui doivent instruire une décision de migration et veulent un état des lieux indépendant de celui qui vendra le projet.
Interventions à distance et sur site, en France, en français et en anglais.