Discussion :

[Bill Fassinou]

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

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

[ShigruM]

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.

[23JFK]

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.

[Shepard]

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 ^^

[benjani13]

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.

[Derf59]

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.

[abriotde]

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 - Visualiser dans une fenêtre à part

a=[elt+1 for elt in lst]

COBOL est beaucoup plus proche de l'assembleur.

[SofEvans]

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.

[el_slapper]

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.

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.

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.

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.

[el_slapper]

(.../...)
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.

[Derf59]

>> 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]

[Derf59]

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.

N'inverse pas la "situation", je n'ai pas parlé de former des personnes à faire de l'assembleur, mais j'ai dis que des Cobolistes pour faire des programmes/algorithmes de type calcul/gestion en mode batch n'ont pas besoin d'avoir une très forte connaissance des langages.

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.

Idem, pour faire des traitements batchs pour de la gestion, on est rarement dans la POO

Cobol était un langage dont le parti-pris initial de définir un langage de programmation proche du langage naturel et on vante par ailleurs la facilité d'apprentissage de Python.
Je ne vois donc pas pourquoi pour faire des traitements "batchs" ca ne pourrait pas "matcher"

Evidemment si c'est pour faire des choses très complexes qui demande de la POO, des architectures à plusieurs couches, etc.... là ca ne le ferra pas

[23JFK]

... POO...

Depuis 2002 COBOL est censé supporter la POO.

[i5evangelist]

Les gars a qui on a dit il y a 30 ans : "z'êtes foutu les loulous, le Cobol c'est HasBeen !"
Je pense que ça les fait bien marrer :-))
Sur Mainframe, on peut encore créer un fichier en donnant sa taille en ... cylindres
Force est de constater que les gros, ceux qui ont de l'argent, on des routines critique la dessus, et le kéké qui ira dire au patron, "pas de soucis Boss, on va migrer tout ça en Java en 2 temps 3 mouvements !", soit il est pas encore né, soit il sort de l'asile :-))

[Pyramidev]

Python ne se compile pas

Pour information, on peut compiler du Python. Je l'ai déjà fait avec Nuitka.
En outre, franchement, quel est le rapport avec les compétences du candidat ?

Mais Python a des tournure bien a lui :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

a=[elt+1 for elt in lst]

Tu te focalises beaucoup trop sur la syntaxe.
En plus, dans ton exemple, la syntaxe des listes en compréhensions, en Python, ça s'apprend très vite.
Ce qui est plus long à apprendre, c'est un paradigme de programmation, par exemple la POO.
En effet, il ne suffit pas de connaître les règles d'un langage pour architecturer correctement un programme.

Depuis 2002 COBOL est censé supporter la POO.

J'avais échangé avec el_slapper à ce sujet en mai 2018 et il m'avait répondu, entre autres, que c'était verbeux de faire de la POO en COBOL et que la POO ne faisait pas partie de la culture des développeurs COBOL.

[jpouly]

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.

Après une tel réaction faut pas s'étonner de la suite :

d'ou le paradoxe de l'IT : on est en pénurie permanente, mais il y a plein de chômeurs.

Il ne faut pas que s'attarder sur la technique, parce que ça s'apprend (même rapidement si le gars est pas trop mauvais).

Par contre, la rigueur et l'algorithmie, c'est autre chose .

[survivals]

Les programmeurs COBOL ont toujours été très rechercher, il y a pénurie et c'est pas pour demain que les banques arrêteront le COBOL pour plusieurs raisons dont le coût de migration.

Pour avoir bossé pour les banques je peux vous dire que c'est très rarement les programmeurs COBOL qui font de la merde mais plutôt les programmeurs JAVA.
Un programmeur JAVA aura beaucoup plus de mal à s'adapter à un autre langage qu'un autre car c'est LE langage d'assistés.

Exclure quelqu'un parce qu'il a fait 7 ans de COBOL c'est juste débile surtout si il est prêt à vouloir sortir de sa zone de confort, les mecs sont justement motivé pour faire autre chose car dès que tu as une compétence COBOL, tu es occupé à faire que ça parce qu'il y a une pénurie qui se fait de plus en plus sentir.
Le langage ne devrait pas être un critère, la logique et le travail consciencieux est beaucoup plus important, un bon programmeur doit être justement capable de switcher sur n'importe quel langage selon les besoins. De même que le langage n'est qu'une partie du boulot, il faut aussi apprendre le domaine dans lequel tu travail.

Le problème d'aujourd'hui c'est que les personnes qui ont le pouvoir de décision dans le recrutement sont souvent des mauvais programmeurs si ils l'ont été (ou mauvais dans un autre domaine) car ils ont été placé là car ils faisaient de la merde autrement. Un bon programmeur (ou autre technicien/ingénieur) on le garde à sa place. Mais bon c'est un peu la faute au CDI et au coût de licenciement des mauvais (j'aurais jamais cru dire ça un jour :/), on préfère les mettre à des postes où ils feront moins de dégâts mais même à leur nouveau poste à priori ils font des dégâts, en l’occurrence ici, erreur de recrutement en préférant les personnes qui ont un profil qui leur ressemble, des beaux parleurs mais avec une logique bizarre et la plupart du temps sans conscience professionnel.

[champomy62]

Les programmeurs COBOL ont toujours été très rechercher, il y a pénurie et c'est pas pour demain que les banques arrêteront le COBOL pour plusieurs raisons dont le coût de migration.

Pour avoir bossé pour les banques je peux vous dire que c'est très rarement les programmeurs COBOL qui font de la merde mais plutôt les programmeurs JAVA.
Un programmeur JAVA aura beaucoup plus de mal à s'adapter à un autre langage qu'un autre car c'est LE langage d'assistés.

Exclure quelqu'un parce qu'il a fait 7 ans de COBOL c'est juste débile surtout si il est prêt à vouloir sortir de sa zone de confort, les mecs sont justement motivé pour faire autre chose car dès que tu as une compétence COBOL, tu es occupé à faire que ça parce qu'il y a une pénurie qui se fait de plus en plus sentir.
Le langage ne devrait pas être un critère, la logique et le travail consciencieux est beaucoup plus important, un bon programmeur doit être justement capable de switcher sur n'importe quel langage selon les besoins. De même que le langage n'est qu'une partie du boulot, il faut aussi apprendre le domaine dans lequel tu travail.

Le problème d'aujourd'hui c'est que les personnes qui ont le pouvoir de décision dans le recrutement sont souvent des mauvais programmeurs si ils l'ont été (ou mauvais dans un autre domaine) car ils ont été placé là car ils faisaient de la merde autrement. Un bon programmeur (ou autre technicien/ingénieur) on le garde à sa place. Mais bon c'est un peu la faute au CDI et au coût de licenciement des mauvais (j'aurais jamais cru dire ça un jour :/), on préfère les mettre à des postes où ils feront moins de dégâts mais même à leur nouveau poste à priori ils font des dégâts, en l’occurrence ici, erreur de recrutement en préférant les personnes qui ont un profil qui leur ressemble, des beaux parleurs mais avec une logique bizarre et la plupart du temps sans conscience professionnel.

Merci d'avoir résumé ma pensée

[Invité]

on a bien rigoler à la réunion du matin et son cv est partie a la poubelle

ya qd même une notion qui me semble otée je pense chez tous ceux qui sont tombés sur shigruM c'est que le profil qu'on recherche c'est pas le même en startup qu'en grosse boite.
en startup on veut pas forcément un coboliste (mais de manière plus générale plutot un gars formé sur la techno) parce que le time to market est bcp plus court (autrement dit: on veut des mecs qui soient bons tout de suite).
dans des grosses boites on veut plus des gars qui sont périns sur le long terme.

de là à exclure ce type de cv, je porterai(sans le s) personnellement plus d'intérérêt à un mec qui se reconvertit apres 7ans et qui a taffé sur du mainframe (parce que ca peut vite partir en sucette donc faut qd même du skill) qu'à un gars qui a maintenu un wordpress

ps: statistiquement je prends des risques, il y a pbmlnt plus de wordpress que de cobolistes qui lisent

[yildiz-online]

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.

Typiquement la réaction de personnes qui n'y connaissent rien en technique et recrutement, vous lui avez fait une fleur en jetant son CV.

Quand on a une personne avec 7 ans d'expérience, on ne parle pas seulement d'expérience dans un langage, c'est surtout 7 ans d'expérience PROFESSIONNELLE, avec tout ce que ça comporte comme apprentissage: travail en équipe, gestion des priorités, gestion du stress, connaissance du flux de travail, des outils de ticketting, test, documentation...

Une personne qui fait un virage technologique comme ça, c'est soit un désespéré (peu probable vu qu'il y a de la demande, mais d'autres facteurs peuvent entrer en compte), soit quelqu'un qui est vraiment motivé à apprendre ou professionnaliser sa connaissance personnelle, et ça, sans entretien, impossible de le savoir.

En tous cas, merci de démontrer que quand on se fait rembarrer c'est pas forcément parce qu'on est mauvais, ça peut être ceux d'en face qui le sont.