Developpez.com - Programmation

Le Club des Développeurs et IT Pro

À plus de 60 ans, le langage COBOL est encore utilisé par des États américains,

Les laissant face à un manque de programmeurs et des coûts de développement énormes

Le 2021-03-04 03:37:23, par Michael Guilloux, Chroniqueur Actualités
Créé en 1959, le langage de programmation COBOL est encore utilisé dans de nombreuses organisations. La conséquence est que celles-ci souffrent d'un manque de programmeurs. Elles doivent également fournir de grands efforts de reprogrammation, même pour les plus petits changements, comme c'est le cas dans certains États américains avec leurs systèmes informatiques de chômage.

Avec la crise sanitaire de la COVID-19, les États-Unis ont en effet mis en place un plan de relance pour soutenir les personnes ayant perdu leur emploi durant la pandémie. Ce plan nécessitait pour chaque État d'implémenter des changements dans leurs systèmes informatiques de chômage. Plus un État prenait du temps, plus les personnes qui ont été mises au chômage à cause du coronavirus devront attendre avant de bénéficier de l'aide du gouvernement.

Certains États ont eu des difficultés particulières à implémenter les changements requis simplement à cause du langage dans lequel leurs systèmes sont écrits : COBOL. Eh oui, la soixantaine révolue, COBOL est encore utilisé par certains États pour leurs systèmes de chômage. C'est le cas notamment de l'Iowa, le New Jersey, le Kansas et l'Oklahoma.


À part l'Iowa qui avait suffisamment de développeurs COBOL, les autres États ont été confrontés à des difficultés importantes. Lorsqu'ils ont eu besoin de programmeurs pour mettre à jour leur « vieux code COBOL que personne n'a touché en 20 ans », cela est devenu un problème. « Ils ont réalisé que tous leurs programmeurs COBOL avaient pris leur retraite ou étaient décédés », a déclaré Dennis Brylow, professeur d'informatique à l'Université Marquette. Dans le même temps, de nombreuses universités n'enseignent plus le langage COBOL de manière approfondie, voire pas du tout, ce qui se traduit par très peu de nouveaux programmeurs COBOL.

Et même quand il y a les hommes qu'il faut, les problèmes avec COBOL ne sont pas encore terminés. Certains États ont essayé de moderniser leurs systèmes et se sont heurtés à des obstacles. Il s'agissait précisément de coûts de développement et de retards particulièrement élevés. Comme l'explique Brylow, le passage complet d'un système COBOL à un autre langage de programmation est loin d'être une solution parfaite. « Quand vous voyez quelque chose qui n'a besoin que de quelques ajustements et que c'est un gros système qu'ils ont passé des années à construire, c'est une dépense énorme et c'est en fait assez dangereux d'essayer de le réimplémenter totalement dans un nouveau langage de programmation », a-t-il déclaré.

S'il est vieux et dit dépassé, COBOL est étonnamment encore présent, notamment dans le secteur des banques et services financiers où il serait d'ailleurs le plus utilisé. Qu'est-ce pourrait donc expliquer cela ?

Et vous ?

Pourquoi COBOL est-il encore populaire aujourd'hui dans le secteur des finances ?
Qu'est-ce qui empêche les entreprises de ce secteur de passer à des technologies plus modernes ?
COBOL a-t-il encore de beaux jours devant lui ?

Voir aussi :

Êtes-vous un développeur COBOL ? Si oui, il pourrait y avoir encore des opportunités pour vous dans le domaine de la finance
Micro Focus annonce la sortie de Visual COBOL pour Visual Studio 2017 qui offre aux développeurs COBOL la possibilité de coder avec l'EDI
Jean E. Sammet, une informaticienne qui a participé au développement de COBOL, est morte à l'âge de 89 ans
  Discussion forum
14 commentaires
  • i5evangelist
    Membre éclairé
    Pourquoi COBOL est-il encore populaire aujourd'hui dans le secteur des finances ?
    Le Cobol est un langage adapté à la gestion, vous voulez le remplacer par quoi ? du python ?
    Qu'est-ce qui empêche les entreprises de ce secteur de passer à des technologies plus modernes ?
    CA veut dire quoi des technologies plus modernes ? Un technologie qui sera obsolète avant même que le projet de réécriture soit fini ? (reprenez les news de developpez.com d'il y a 10 et vous comprendrez)
    COBOL a-t-il encore de beaux jours devant lui ?
    Disons que pour ce genre de situation, bien sûr
  • el_slapper
    Expert éminent sénior
    Envoyé par yahiko
    Le problème n'est pas le langage, mais les pratiques de développement qui avaient cours durant les précédentes décennies.
    Quand on doit se farcir la reprise de ces programmes antédiluviens, peu importe que ce soit du Cobol, du PL/I ou du RPG, le nombre de WTF par minute explose.
    Je conseillerai aux boites qui reposent sur du Cobol non pas de changer de langage, mais de nettoyer leur code et de mieux l'architecturer.
    Souvent vrai. Pas toujours, mais les codes des années 1970 étaient très souvent horribles, j'en ai maintenu quelques uns, et il m'est même arrivé de les refondre. Une des contraintes, c'était la place mémoire. A tel point que les noms de variables ou de labals (pour les GO TO...) étaient souvent sur 2-3 caractères maximum.

    code de 1972 :

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
     A12.
         MOVE 1 TO YY
     A122.
         IF XX(YY) = 0
         GO TO A121.
         MOVE XX(YY) TO PP(YY)
         ADD 1 TO YY
         GO TO A122.
     A121.
    code de 2008 (refait par mes soins ou ceux de mon collègue)

    Code :
    1
    2
    3
    4
    5
    6
    7
    *Avoir les codes produits déjà initialisés permet de ********(secrets de fabrication)**********
     COPIE-PRELIMINAIRE-CODES-PRODUITS.
         PERFORM VARYING I-PRODUIT FROM 1 BY 1
           UNTIL CODE-PRODUIT-LU (I-PRODUIT) = 0
            MOVE CODE-PRODUIT-LU (I-PRODUIT) TO CODE-PRODUIT-ECRIT (I-PRODUIT)
         END-PERFORM
     .
    (bon, j'ai pas vérifié les bornes, je retape de mémoire, il y a peut-être une différence subtile entre les deux. Après 8 semaines de tests intensifs sur des volumétries de prod, en vrai, il n'y avait plus aucune différence dans ce que ça faisait)

    Entre ces deux codes, il y a 1,2 équivalents temps plein d'économisés en maintenance (mesuré sur les 4 premières années d'exploitation). Mon collègue et moi avions consommé 172 jours pour cette refonte (il y en avait à la pelle, des comme ça). Faites le calcul, et soudain, l'intervention de Yahiko devient inévitable. Un bon refactoring, et ces vieilles horreurs deviennent soudain très lisibles, maintenables, voire accessibles à des gens qui ne maitrisent pas le langage.

    Je suis quasiment sur que ces gens là refusent le télétravail. Sans quoi, je pourrais chercher à cachetonner chez eux. Même en prenant les frais de changes et les charges à la Française, ça doit bien payer.
  • J'ai le sentiment qu'il est important de ne pas se limiter au langage... et de repositionner le contexte

    Que serait Cobol sans l'AS400 (sa conception avec 10 ans d'avance, voir plus à l'époque), sa fiabilité, etc...
    Que serait Java sans l'édition entreprise, Spring, Android ?
    Etc...

    Au delà du langage, il y a le contexte projet et le contexte d'exécution, également le contexte d'employabilité des développeurs.

    80% de la vie d'une application c'est sa maintenance...

    Je sans que le débat va être animé !
  • yahiko
    Rédacteur/Modérateur
    Le problème n'est pas le langage, mais les pratiques de développement qui avaient cours durant les précédentes décennies.
    Quand on doit se farcir la reprise de ces programmes antédiluviens, peu importe que ce soit du Cobol, du PL/I ou du RPG, le nombre de WTF par minute explose.
    Je conseillerai aux boites qui reposent sur du Cobol non pas de changer de langage, mais de nettoyer leur code et de mieux l'architecturer.
    La formation au langage pouvant se faire sur quelques mois pour des profils motivés.
  • el_slapper
    Expert éminent sénior
    Envoyé par abriotde
    Le problème de Cobol, n'est pas vraiment son âge, mais le fait qu'il soit fermé. Du coup très peu d'informaticien sont formés. Même pour éditer du COBOL, il te faut encore bien souvent le terminal dédié. Impossible de faire ton programme sous Ubuntu, de le tester sur une VM, de le mettre dans GIT... Enfin il existe des implémentations Open-Source mais pas conforme sur tout évidemment.
    https://opencobolide.software.informer.com/4.6/

    Ce qui est fermé, ce sont les machines Z/OS. A part la couche objet (que je n'ai jamais vue utilisée), tout COBOL est utilisable en OpenCobolIde.
  • Andarus
    Membre confirmé
    Envoyé par i5evangelist
    Le Cobol est un langage adapté à la gestion, vous voulez le remplacer par quoi ? du python ?
    Il y a de nouveau projet lancé en Cobol?
  • escartefigue
    Modérateur
    La fin ou pas de COBOL ? Ce sujet, en bon marronnier, nous revient fidèlement et régulièrement

    L'épisode précédent ici
    https://www.developpez.net/forums/d1...l-fete-60-ans/

    Une petit poussée de fièvre sans gravité de temps à autre, comme ici :
    https://www.developpez.net/forums/d2.../#post11646159

    Un peu plus ancien là :
    https://www.developpez.net/forums/d1.../#post10004561

    A bientôt sur le même thème, sans aucun doute
  • Escapetiger
    Expert éminent sénior
    Envoyé par Michael Guilloux
    COBOL a-t-il encore de beaux jours devant lui ?
    Envoyé par escartefigue
    A bientôt sur le même thème, sans aucun doute
    Jusqu'en 9999 ?

    A Cobol programmer made so much money doing Y2K remediation that he was able to have himself cryogenically frozen when he died. One day in the future, he was unexpectedly resurrected.

    When he asked why he was unfrozen, he was told:

    "It's the year 9999 - and you know Cobol" *


    [Edit]
    Et pour l'outillage également:
    Micro Focus annonce la sortie de Visual COBOL pour Visual Studio 2017
    qui offre aux développeurs COBOL la possibilité de coder avec l’EDI

    *
    [Edit2]
    Je la cherchais en français, réponse sur developpez ici **
    Vous la connaissez sans doute

    C'est l'histoire du développeur COBOL qui a fait fortune avec les maintenances liées au passage à l'an 2000. Avec son argent, il décide de se faire cryogéniser et de tomber dans un sommeil (presque) éternel.

    Un jour quelqu'un le met au micro-onde et le réveille. Le développeur COBOL ouvre les yeux et demande: pourquoi vous me réveillez ? L'autre lui répond: on est en l'an 9999 , et il paraît que vous savez développer en COBOL...

    **
    Le langage de programmation Cobol fête ses 60 ans
    peut-il encore tenir longtemps face à la concurrence des nouveaux langages ?
  • abriotde
    Membre chevronné
    Envoyé par i5evangelist

    Aujourd'hui, tout est concentré sur le partage et l'exposition des données et la modernisation des interfaces.
    Dans le domaine bancaire, je ne suis pas certain que l'exposition des données soit à l'ordre du jour
    Dans le domaine bancaire comme ailleurs, il faut exposer les données au client (dans son smartphone), au banquier (Sur son tableur), au comptable, au fisc, aux autres banques. Aujourd'hui les banques sont hyper-connectées.

    Et si on expose les données, cela ne veut pas dire qu'il n'y a pas de backend.
  • TotoParis
    Membre expérimenté
    Envoyé par Andarus

    Oui, tout à fait, dans de grosse entités, par de grosses SSII.

    Envoyé par el_slapper

    Ne pas oublier en plus que dans les années 1970, l'écriture sur bordereau papier et transcription en cartes perforées, pour compilation la nuit et récupération du listing le lendemain matin étaient encore en vigueur...Et aussi, l'enseignement de la programmation était très peu poussé.

    Ce qui manque à COBOL, ce sont de vrais outils comme ECLIPSE, mais qui ne coûtent pas 1 bras comme RDZ d'IBM (1 bras par licence).
    Un débugger interactif comme XPEDITER, c'est génial, sous TSO ou en ayant lancé son JCL et avec interception sous TSO.
    FILE-AID (fichiers, DB2) est génial là aussi.
    Le langage est simple à apprendre. Mais il faut se méfier des options de compilation, très farceuses pour les zones numériques.
    L'interface TSO est très spartiate, mais pas pire que dans le monde UNIX, voire mieux avec les écrans ISPF (et les puissants langages de script comme CLIST et REXX).
    Par contre, merci les "GO TO" : une plaie connue depuis 40 ans au moins, mais toujours utilisables.
    Pour définir une structure de fichier, ou de table DB2, il n'y a pas mieux, à part PL/1, un peu comme les RECORD en Pascal, voir https://pascal.developpez.com/cours/.../?page=page_12.
    Il y a énormément de fonctions avec Language Environment. Mais il manque comme dans un langage plus moderne la possibilité de déclarer ses propres fonctions dans un programme, là encore, comme en Pascal : https://www.tutorialspoint.com/pasca..._functions.htm, https://www.tutorialspoint.com/pasca...procedures.htm).
    Car sinon la WORKING-STORAGE SECTION ressemble a un vaste grenier bien bordélique un peu trop souvent...et PROCEDURE DIVISION alors là, lol mais lol quoi...