Les patterns COBOL durables qui résistent à l’épreuve du temps

Le code COBOL traverse les décennies. Non pas parce qu’il est figé, mais parce qu’il repose sur des fondations solides. Simplicité, efficacité mémoire, portabilité… certains patterns de développement utilisés depuis les années 60 sont encore pleinement pertinents aujourd’hui.

Dans un contexte où les systèmes critiques continuent de tourner sur mainframe, savoir identifier ces bons patterns devient une vraie force. Car bien structurés, ces blocs de code restent lisibles, maintenables, et surtout, performants.

Un code simple, lisible, direct

COBOL ne mise pas sur la sophistication, mais sur la clarté. Le langage a été conçu à une époque où chaque instruction devait être traduite en code machine de manière directe. Résultat : des blocs faciles à lire, comprendre, et optimiser.

Exemple typique :


01 EMPLOYEE-RECORD.
   05 EMPLOYEE-ID     PIC 9(5).
   05 EMPLOYEE-NAME   PIC X(30).
   05 EMPLOYEE-SALARY PIC 9(7)V99.

PROCEDURE DIVISION.
    MOVE 12345 TO EMPLOYEE-ID.
    MOVE "DUPONT JEAN" TO EMPLOYEE-NAME.
    MOVE 50000.00 TO EMPLOYEE-SALARY.

Pas d’abstraction inutile. Chaque ligne est lisible, et le compilateur produit un code machine efficace.

Une gestion mémoire prédictible

Le modèle mémoire COBOL est d’une efficacité redoutable : allocation fixe, absence de fragmentation, et accès rapide.

Déclaration typique :


01 EMPLOYEE-TABLE.
   05 EMPLOYEE OCCURS 100 TIMES.
      10 EMPLOYEE-ID     PIC 9(5).
      10 EMPLOYEE-NAME   PIC X(30).
      10 EMPLOYEE-SALARY PIC 9(7)V99.

Utilisation :


PERFORM VARYING I FROM 1 BY 1 UNTIL I > 100
    MOVE I TO EMPLOYEE-ID(I)
    MOVE "NOM" TO EMPLOYEE-NAME(I)
    MOVE 30000.00 TO EMPLOYEE-SALARY(I)
END-PERFORM.

On sait exactement combien de mémoire est utilisée. Et on peut prédire les performances d’accès sans surprises.

Des patterns qui évoluent avec le temps

Contrairement aux idées reçues, COBOL n’est pas un langage figé. Il a intégré au fil du temps des mécanismes adaptés aux nouveaux besoins.

Prenons l’exemple des fichiers indexés :


SELECT EMPLOYEE-FILE
    ASSIGN TO "EMPLOYEE.DAT"
    ORGANIZATION IS INDEXED
    ACCESS MODE IS DYNAMIC
    RECORD KEY IS EMPLOYEE-ID.

On structure les données comme dans une base, avec une clé. Et l’accès est optimisé sans toucher au reste du programme.

Portabilité sans douleur

COBOL, c’est aussi un code qui s’exécute sur mainframe, UNIX, Windows… sans tout réécrire.


COMPUTE TOTAL-SALARY = BASE-SALARY + BONUS.
ADD OVERTIME TO TOTAL-SALARY.

Le même bloc s’exécutera indifféremment sur un z/OS, un serveur Linux ou dans un environnement .NET, en fonction du compilateur.

Structurer le code comme un pro

Même sans objets, on peut appliquer des patterns modernes en COBOL. Par exemple, un Repository pour centraliser la logique d’accès aux données :


01 PRODUCT-REPOSITORY.
   05 GET-PRODUCT.
      10 PRODUCT-ID     PIC 9(5).
      10 PRODUCT-NAME   PIC X(30).
      10 PRODUCT-PRICE  PIC 9(7)V99.

Ou un Service Layer pour encapsuler des règles métier :


01 ORDER-SERVICE.
   05 CREATE-ORDER.
      10 CUSTOMER-ID PIC 9(5).
      10 ORDER-ITEMS OCCURS 10 TIMES.
         15 PRODUCT-ID PIC 9(5).
         15 QUANTITY   PIC 9(3).

Ce type d’architecture modulaire rend le code bien plus maintenable, même sur le long terme. Les patterns COBOL sont ainsi durables dans le temps malgré les croyances.

Documentation : le pattern ultime

Un bon code COBOL, c’est aussi un code bien documenté.

Pas besoin d’écrire un roman, mais des commentaires clairs, et une documentation de haut niveau sur les flux principaux, permettent de sécuriser la transmission et l’évolution du code. C’est une base pour éviter que le système devienne un vrai code legacy ingérable. Pour aller plus loin, vous pouvez retrouver cet sujet dans notre article Quand faut-il dire stop ? Reconnaître un code legacy trop coûteux à maintenir.

Et donc, un bon code COBOL ne va pas sans documentation claire :


* Calcul du montant total de la commande
* en tenant compte des remises et des taxes
COMPUTE TOTAL-ORDER = (SUB-TOTAL - DISCOUNT) * (1 + TAX-RATE)

On documente aussi l’architecture globale, les interfaces externes, les dépendances critiques. Et si possible, on automatise tout ça.


01 ORDER-SERVICE.
   05 CREATE-ORDER.
      10 CUSTOMER-ID PIC 9(5).
      10 ORDER-ITEMS OCCURS 10 TIMES.
         15 PRODUCT-ID PIC 9(5).
         15 QUANTITY   PIC 9(3).

Ce type d’architecture modulaire rend le code bien plus maintenable, même sur le long terme.

Et côté terrain ?

Ces patterns, on les applique aujourd’hui dans de nombreux projets critiques : dans la banque, l’assurance, la logistique…
Des bases de code COBOL maintenues depuis 30 ans qu’on structure, sécurise, et prépare à cohabiter avec les systèmes modernes.

Résultat : un code plus lisible, une maintenabilité retrouvée, et des équipes capables de s’approprier ces systèmes sans repartir de zéro.

Conclusion

Ce qui fait des patterns COBOL durables, c’est l’efficacité de son code. Une structuration claire, des fichiers bien gérés, une mémoire maîtrisée : ces choix techniques ont permis à des milliers d’applications de tenir sur des décennies, sans jamais lâcher en production.

Aujourd’hui, ces mêmes patterns continuent de prouver leur valeur, surtout lorsqu’ils sont remis en forme, nettoyés, et adaptés aux nouveaux usages : exposition en API, pipelines data, intégration DevOps…

C’est exactement ce qu’on fait déjà sur plusieurs projets critiques : on aide les équipes à reprendre en main leurs bases COBOL, parfois inchangées depuis les années 80, pour leur redonner une vraie marge de manœuvre. Sans tout casser. Sans repartir de zéro. Juste avec des fondations solides, compréhensibles, et durables.

Découvrez nos retours d’expérience :

Contact

Une base COBOL à stabiliser ou à faire évoluer ?

Nous accompagnons aujourd’hui des entreprises qui veulent remettre à plat leur base COBOL, la documenter proprement ou lui donner une nouvelle structure pour mieux préparer l’avenir. Vous vous posez la question pour votre système ? Contactez-nous, on peut en parler concrètement.