IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

À 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 , par Michael Guilloux

75PARTAGES

17  0 
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

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de i5evangelist
Membre éclairé https://www.developpez.com
Le 04/03/2021 à 5:19
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
7  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 04/03/2021 à 16:06
Citation Envoyé par yahiko Voir le message
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 : Sélectionner tout
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 : Sélectionner tout
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.
5  0 
Avatar de coder_changer_vie
Inactif https://www.developpez.com
Le 04/03/2021 à 8:56
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é !
3  0 
Avatar de yahiko
Rédacteur/Modérateur https://www.developpez.com
Le 04/03/2021 à 14:45
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.
3  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 04/03/2021 à 17:47
Citation Envoyé par abriotde Voir le message
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.
3  0 
Avatar de Andarus
Membre confirmé https://www.developpez.com
Le 04/03/2021 à 5:56
Citation Envoyé par i5evangelist Voir le message
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?
2  0 
Avatar de escartefigue
Modérateur https://www.developpez.com
Le 08/03/2021 à 16:20
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
2  0 
Avatar de Escapetiger
Expert éminent sénior https://www.developpez.com
Le 08/03/2021 à 18:44
Citation Envoyé par Michael Guilloux Voir le message
COBOL a-t-il encore de beaux jours devant lui ?
Citation Envoyé par escartefigue Voir le message
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 ?
2  0 
Avatar de abriotde
Membre chevronné https://www.developpez.com
Le 04/03/2021 à 16:49
Citation Envoyé par i5evangelist Voir le message

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.
1  0 
Avatar de TotoParis
Membre expérimenté https://www.developpez.com
Le 05/03/2021 à 21:49
Citation Envoyé par Andarus Voir le message

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

Citation Envoyé par el_slapper Voir le message

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...
1  0