Êtes-vous un développeur COBOL ? Si oui, il pourrait y avoir encore des opportunités pour vous
Dans le domaine de la finance

Le , par Bill Fassinou, Chroniqueur Actualités
COBOL, pour COmmon Business Oriented Language, est un langage de programmation conçu vers la fin des années 50 pour la programmation d'applications de gestion. Vu l’âge de ce langage, on serait en droit de penser qu’il est tombé en désuétude et que des technologies plus récentes ont pris sa place. Ce n’est pourtant pas le cas. COBOL est encore largement utilisé. Mieux, il reste le langage le plus utilisé dans le secteur des services financiers à travers le monde.

De plus, le langage semble bien parti pour être là encore longtemps, puisque pour les banques, changer tous leurs mainframes est une entreprise compliquée et coûteuse. Même une transition vers de nouveaux systèmes prendrait probablement plusieurs années. Et surtout, pourquoi penser à changer un système qui marche ? Chaque jour, des millions de transactions bancaires et des mainframes sont gérés par un logiciel programmé en COBOL.


Cependant, les experts en COBOL sont pour la plupart vieux ou vieillissants. Le langage n’est pas suffisamment populaire auprès des jeunes programmeurs. Les détracteurs du langage condamnent son manque de polyvalence. De plus, les jeunes développeurs ne sont pas très enclins à se servir d’un langage de programmation utilisé pour les mainframes alors que le cloud computing exerce une domination sans partage sur notre ère.

Ce qu’il faut cependant retenir, c’est que la sécurité que procure la conservation de COBOL aux grandes banques est la principale raison pour laquelle le système ne disparaîtra peut-être pas de sitôt. John Schlesinger, architecte en chef de Temenos, une entreprise qui vend des logiciels aux banques, déclare que « bien que de petites banques aient réussi à éliminer leurs anciens systèmes, aucune grande banque n’a osé le faire » parce que « le coût d'une révision majeure et le risque d'une mise à niveau bâclée laissant les clients sans accès à leurs comptes bancaires sont trop élevés ».

Toutefois, ce n’est pas comme si COBOL ne coûtait rien aux banques. Des estimations de l’entreprise de recherche Celent portent le montant total que les banques devraient dépenser en technologie cette année à 261 milliards de dollars. 67 % de cette somme faramineuse seront intégralement consacrés à l’entretien des vieux systèmes. Et il peut s’avérer bien plus coûteux d’essayer de superposer les nouvelles technologies de pointe à ces systèmes d’une autre ère.

Ne manquant que rarement à l’appel, les internautes se sont empressés d’opiner sur ce langage. Pour eux, il ne s’agit pas de langage ou encore de difficulté de superposition de technologie de deux ères différentes. Pour eux, il s’agit juste des banques qui ne veulent pas mettre la main à la poche pour payer des programmeurs compétents.

Source : The Wall Street Journal

Et vous ?

Qu’en pensez-vous ?
Quel est votre avis sur Cobol ?
Cobol a-t-il encore de l'avenir selon vous ? Pourquoi ?

Voir aussi

La Rubrique Programmation, Forum Cobol

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

Node.cobol / Node.fortran : exécuter du code COBOL et Fortran dans Node.js et inversement grâce à ces bibliothèques


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse Signaler un problème

Avatar de ShigruM ShigruM - Nouveau Candidat au Club https://www.developpez.com
le 01/10/2018 à 14:15
c'est surtout le risque d’être coincé dans ce domaine

vas trouver du boulot ailleurs ensuite quand on lira sur ton cv "développeur cobol" (situation vue début septembre)
on cherche un dev python et on as reçu un cv et le mec sa faisait 7ans qu'il était dans une banque a coder en cobol, on a bien rigoler à la réunion du matin et son cv est partie a la poubelle.
Avatar de 23JFK 23JFK - Membre expérimenté https://www.developpez.com
le 01/10/2018 à 14:20
Cobol est fini. L'organisme en charge de ces spécifications n'arrive pas à tenir ses propres délais avec pour conséquences l'apparition d'initiatives dissidentes aux fonctionnalités incompatibles entre elles et qui peuvent, en plus, ne pas correctement interpréter du code ancien.
Avatar de Shepard Shepard - Membre éprouvé https://www.developpez.com
le 01/10/2018 à 14:31
Citation Envoyé par ShigruM Voir le message
c'est surtout le risque d’être coincé dans ce domaine

vas trouver du boulot ailleurs ensuite quand on lira sur ton cv "développeur cobol" (situation vue début septembre)
on cherche un dev python et on as reçu un cv et le mec sa faisait 7ans qu'il était dans une banque a coder en cobol, on a bien rigoler à la réunion du matin et son cv est partie a la poubelle.
La réaction de recruteurs face à ce genre de profil est bonne à savoir, toutefois je pense que vous êtes passés à côté de quelqu'un d'au moins potentiellement intéressant. Quelqu'un qui est motivé par des langages récents tels que Python (et donc probablement jeune) mais qui est prêt à apprendre un langage ancien tel que Cobol pour une opportunité n'est probablement pas un guignol ...

Maintenant si il avait 64 ans alors je comprends mieux pourquoi vous avez réagi ainsi ^^
Avatar de benjani13 benjani13 - Membre chevronné https://www.developpez.com
le 01/10/2018 à 15:07
Tous ces vieux systèmes bancaires (en COBOL ou non) sont des bombes à retardement. J'ai vu des vieux projets tournant toujours, personne n'ayant plus aucune compétence sur la techno utilisé. En clair, ils regardaient le machin tourner en espérant que rien ne pète.

Autant dire que ces vieux systèmes sont totalement à la ramasse en terme de sécurité, ils passent sous le radars car pas trop exposés, mais en cas d'intrusion sur le réseau interne c'est la catastrophe assurée.
Avatar de Derf59 Derf59 - Membre habitué https://www.developpez.com
le 01/10/2018 à 15:36
Je ne suis pas développeur COBOL mais ma société a des programmes écrits en COBOL et ce qu'on est plutôt en train de faire c'est de quitter les gros systèmes (Mainframe) pour utiliser du COBOL sous Linux (Cobol IT : The Best alternative to mainframe & Micro focus Cobol). Microfocus (leader sur Mainframe) a d'ailleurs bien senti le vent venir et a racheté Cobol IT en 2017

Ce qui me désole dans ce genre de phrase
>> vas trouver du boulot ailleurs ensuite quand on lira sur ton cv "développeur cobol" (situation vue début septembre)
>> on cherche un dev python et on as reçu un cv et le mec sa faisait 7ans qu'il était dans une banque a coder en cobol, on a bien rigoler à la réunion du matin et son cv est partie a la poubelle.
C'est de voir que des personnes se croient "supérieures" à d'autres parce qu'elles utilisent un langage plus récent.

Dans tous les cas un langage ça sert à développer des algorithmes X ou Y. Je vois trop de prestataires dans notre société qui connaissent Java par exemple mais qui produisent du code horrible (en terme de logique même).
J'ai dans ma boite des personnes (à cause de gros systèmes) qui codent encore en Assembleur, je peux te dire qu'en terme de réflexion, ils sont plus calés que 80% des programmeurs Java qui sortent de l'école.

Si une personne est compétente en terme de raisonnement/algorithmique, l'adaptation à un nouveau langage (surtout comme Python) n'est qu'une question d'un peu de temps.
Avatar de abriotde abriotde - Membre éprouvé https://www.developpez.com
le 01/10/2018 à 16:18
C'est de voir que des personnes se croient "supérieures" à d'autres parce qu'elles utilisent un langage plus récent.
C'est pas une question de supérieur mais de choux et carottes. Si on recherche une personne qui parle Espagnol et que tu me dis "Moi je parle Chinois", eh bien désolé mais on va rire. Alors certes former quelqu'un qui parle déjà plusieurs langue c'est plus facile qu'un noob. Mais il n'empêche entre faire du Pyhon et du COBOL c'est le bout du monde. Il n'y a pas grand chose en commun. Les outils ne sont pas du tout les même les modules Open-Source n'existe en COBOL. Python s'utilise souvent en Linux/Windows mais pas sur du mainframe, Python ne se compile pas, les EDI n'ont rien a voir... Il n'y a pas plus opposé. Le C est déjà beaucoup plus proche, si tu maîtrise PHP Objet + C + Java on peux se dire que oui cela devrait être pas trop dure à apprendre. Mais Python a des tournure bien a lui :
Code : Sélectionner tout
a=[elt+1 for elt in lst]
COBOL est beaucoup plus proche de l'assembleur.
Avatar de SofEvans SofEvans - Membre expérimenté https://www.developpez.com
le 01/10/2018 à 16:42
ShigruM a juste précisé qu'il y avait écrit "7 ans de Cobol" sur le CV du gars. On ne sait pas ce qu'il y avait écrit à propos de Python.
Si ca se trouve, le gars fait du Python sur son temps libre.

Je sais pas, on a trop peu d'info, mais en tout les cas, je trouve que c'est une réaction pathétique de 1) en rigoler 2) passer le gars à la trappe rien que pour ça.
Avatar de el_slapper el_slapper - Expert éminent sénior https://www.developpez.com
le 01/10/2018 à 17:08
Citation Envoyé par Derf59 Voir le message
Je ne suis pas développeur COBOL mais ma société a des programmes écrits en COBOL et ce qu'on est plutôt en train de faire c'est de quitter les gros systèmes (Mainframe) pour utiliser du COBOL sous Linux (Cobol IT : The Best alternative to mainframe & Micro focus Cobol). Microfocus (leader sur Mainframe) a d'ailleurs bien senti le vent venir et a racheté Cobol IT en 2017
l'inconvénient du mainframe, c'est que c'est horriblement couteux. L'avantage, c'est que c'est horriblement sécurisé. COBOL lui-même a exactement 0 couches de sécurité, parcequ'il est apparu dans un contexte ou l'accès aux machines était très restreint. Sous mainframe, c'était toujours le cas. Il est très facile, quand on a les accès, de changer le montant de son compte en banque. C'est détecté en quelques minutes, et personne n'est assez fou pour le faire.

Je ne sais pas ce qu'il en est sous LINUX.

Citation Envoyé par Derf59 Voir le message
Ce qui me désole dans ce genre de phrase
>> vas trouver du boulot ailleurs ensuite quand on lira sur ton cv "développeur cobol" (situation vue début septembre)
>> on cherche un dev python et on as reçu un cv et le mec sa faisait 7ans qu'il était dans une banque a coder en cobol, on a bien rigoler à la réunion du matin et son cv est partie a la poubelle.
C'est de voir que des personnes se croient "supérieures" à d'autres parce qu'elles utilisent un langage plus récent.
d'ou le paradoxe de l'IT : on est en pénurie permanente, mais il y a plein de chômeurs. Bien sur, il y a d'autres raisons, mais ça, ça compte beaucoup. Bon, et je raconte toujours cette histoire de 2011. Un jour, on est venus nous demander de chiffrer une refonte d'une chaine de traitement COBOL. On est arrivé à 110 jours. La dame a râle, dit "il n'y a pas besoin de tout refaire"; mais après analyse, j'ai insisté : sur les 120 composants, seuls 4 étaient réutilisables. La dame a dit "grmble grmlb grmbl", et a demandé des specs techniques. Au final, on a consommé moins de 120 jours. Ce que je n'ai su qu'après, c'est qu'auparavant, elle avant demandé aux gens du JAVA, et que ceux-ci avaient largement dépassé les 200 jours dans leur estimation. Pour faire la même chose.

Après, évidemment, c'était essentiellement du traitement de masse de fichiers plats, le point fort du COBOL. Pour des trucs différents, je n'ai aucun doute que la situation n'aurait pas étée aussi favorable.

Citation Envoyé par Derf59 Voir le message
Dans tous les cas un langage ça sert à développer des algorithmes X ou Y. Je vois trop de prestataires dans notre société qui connaissent Java par exemple mais qui produisent du code horrible (en terme de logique même).
J'ai dans ma boite des personnes (à cause de gros systèmes) qui codent encore en Assembleur, je peux te dire qu'en terme de réflexion, ils sont plus calés que 80% des programmeurs Java qui sortent de l'école.
Le JAVA, c'est facile. L'assembleur, c'est difficile. Tes programmeurs JAVA qui sortent de l'école, ils ne sauront JAMAIS faire un programme assembleur, même si tu les forme pendant un an.

Citation Envoyé par Derf59 Voir le message
Si une personne est compétente en terme de raisonnement/algorithmique, l'adaptation à un nouveau langage (surtout comme Python) n'est qu'une question d'un peu de temps.
Avec ce petit détail quand même que la POO est contre-naturelle pour un coboliste. Qui sera très fort en algo, mais aura tendance à faire des réactions allergiques à toutes les formations objet qu'on peut trouver. "l'objet chien qui hérite de l'objet animal", c'est idéal pour le braquer. Il m'a fallu pas mal d'effort pour arriver à une compréhension d'ailleurs modérée du modèle objet. Et surtout éviter les tutoriels standard, qui m'ont tous repoussé totalement.
Avatar de el_slapper el_slapper - Expert éminent sénior https://www.developpez.com
le 01/10/2018 à 17:10
Citation Envoyé par abriotde Voir le message
(.../...)
COBOL est beaucoup plus proche de l'assembleur.
foutaises. COBOL est un langage verbeux, là ou l'assembleur est concis. COBOL est un langage de haut niveau, là ou l'assembleur est un langage de bas niveau. La seule ressemblance, c'est que les deux sont procéduraux. Tut le reste? Rien à voir.
Avatar de Derf59 Derf59 - Membre habitué https://www.developpez.com
le 01/10/2018 à 17:11
>> les EDI n'ont rien a voir...
Faut te mettre à la page, COBOL IT propose un EDI basé sur Eclipse (comme Python)
https://www.cobol-it.com/wp-content/...per_Studio.pdf

Quand à ta syntaxe, suffit de chercher un peu et rapidement sur le net (Developpeur, Google est ton ami), et tu vas hyper rapidement trouver des exemples :

# Affiche les carrés des éléments
liste = [1, 2, 3, 4, 5, 6, 7]
print [x ** 2 for x in liste] # Équivaut à notre map, en plus lisible et plus simple .

# Affiche les nombres pairs
print [x for x in liste if x % 2 == 0] # Plus simple que filter, également

# Affiche les carrés pairs (combinaison des deux)
print [x ** 2 for x in liste if x ** 2 % 2 == 0] # ou
print [x for x in [a ** 2 for a in liste] if x % 2 == 0]
Contacter le responsable de la rubrique Programmation