Quel avenir pour le langage Cobol ?
Posté le 24 avril 2018 par PierreB
On entends depuis des décennies que le langage Cobol est devenu un langage historique et obsolète, complètement dépassé. Son acronyme « Common Business Oriented Language » est d’ailleurs souvent détourné avec humour pour « Completely Obsolet Business Oriented Language ». Et pourtant plusieurs experts prédisaient déjà sa mort, et à plusieurs reprises, il y a de nombreuses années. Il est pourtant encore majoritairement utilisé dans le milieu bancaire, mais également dans la plupart des systèmes de gestion administratifs. Il y aurait même plus de lignes de code écrites en cobol que de lignes de code écrites dans n’importe quel autre langage ! Dans ce contexte, on peut alors se demander quel avenir peut avoir le Cobol, dans la mesure où sa popularité décroît fortement au fil du temps, alors que son utilisation et surtout sa demande reste encore massivement importante.
Le Cobol est bien vivant et à l’échelle mondiale
Face au peu de sujets présents sur le net concernant le langage Cobol, on pourrait croire qu’il est mort. Et pourtant, les chiffres parlent d’eux-mêmes : on estime à près de 310 milliards, le nombre de lignes de codes développées dans le monde et près de 220 milliards de lignes soit 71% du total, qui sont écrites en Cobol. Le volume des lignes écrites en Cobol augmenterait encore de 5 milliards chaque année. C’est donc un des langages les plus largement déployés dans le monde en termes de volume d’écriture.
Un langage clair et précis où réside sa force
Il faut savoir que le Cobol n’a jamais vraiment été considéré comme un langage à la pointe de l’innovation. Sa seule véritable force réside dans sa capacité à décrire les choses très clairement et de manière précise. À l’époque de sa création en 1959 par Grace Hopper, son design était façonné de manière à ce que la base de son écriture se rapproche le plus possible de la langue anglaise naturelle. Il se lit et relit donc très facilement. Même sur les plateformes les plus récentes, il peut facilement y exécuter de grosses applications vitales, ou gérer des transactions commerciales d’envergure. Il y a quelques années de ça, IBM affirmait que 82% des transactions financières dans le monde s’effectuent en COBOL et 60% des applications critiques seraient également rédigées en Cobol. Les établissements bancaires, les assurances, le gouvernement français & son appliciation de calcul d’impôts annuels, fonctionnent tous en Cobol.
Grace Hopper, conceptrice du premier compilateur A-0 System et du langage Cobol, pensait que les ordinateurs seraient un jour largement utilisés et que Cobol contribuerait à les rendre plus conviviaux.
Cobol et sa compatibilité
La simplicité qui réside dans le langage Cobol lui confère aussi un autre atout : celui de l’interopérabilité (ou interfonctionnement) avec les solutions de l’industrie de pointe, c’est à dire que Cobol a la capacité de fonctionner avec d’autres systèmes informatiques sans aucune restriction d’accès ou de mise en oeuvre. Autrement dit le langage Cobol est compatible avec d’autres systèmes aux architecrure modernes tels que les webservices, Big Data, Cloud Computing, IA… ce qui lui confère une toute autre image que celle du langage obsolète. Pour exemple, le gouvernement américian utilise justement cette interopérabilité pour coordiner les fonctions opérationnelles des forces nucléaires, des déclarations d’impôts, d’éligibilité et de calculs de montants de sécurité sociale…
Un langage sécuritaire « irremplaçable »
S’ajoute à tout ça un facteur non négligeable : le Cobol semble moins exposé à des virus informatiques puisqu’il fonctionne sur des mainframes peu exposés au web. Il a d’ailleurs été perfectionné par plusieurs générations d’informaticiens du secteur bancaire, secteur dont la sécurité a toujours été la priorité absolue. Le langage Cobol est donc un exemple de longévité maintenue par des ajustements successifs au cours des années. Remplacer ce langage serait virtuellement impossible, et extrêment coûteux tant son implémentation historique est massive au niveau mondial. On estime à près de 5 millions de développeurs nécessaires, programmant en continue pendant 65 ans, pour modifier la donne et redevelopper tout le patrimoine Cobol. Rien que ça…
Une concurrence historiquement forte avec l’apparition de nouveaux langages
Le langage Cobol a connu une résistance hors-norme au fil des années. À plusieurs reprises, il a tenu bon face à une concurrence très forte de nouveaux langages qui devaient restreindre progressivement la domination du Cobol. En effet, l’arrivée de plusieurs langages nouveaux est apparu comme une révolution technologique, à chaque fois laissant penser que la fin était proche pour le langage Cobol.
Cobol vs GAP
Pour premier exemple, l’arrivée du langage GAP (Générateur Automatique de Programmes) ou RPG en anglais (Report Program Generator), qui est un langage de gestion beaucoup plus simple que Cobol. L’histoire du GAP commence avec les cartes perforées vers 1960 et sa synthaxe en colonnes en est liée. IBM en a fait la promotion sur tous ces matériels bas de gamme destinés aux PME. AInsi, beaucoup prédisait déjà que le Cobol deviendrait inutile face à ces avancées. Et pourtant aujourd’hui, il n’y presque aucun programme écrit en GAP…
Cobol vs PL/1
Peu de temps avant les années 70, IBM innove encore avec l’arrivée du PL/1 (Programming Language number 1, littéralement « Langage de programmation numéro 1 »). Il devait lui aussi faire oublier le langage Cobol par sa structure améliorée, et sa capacité à traiter aussi bien des problèmes de gestion que du calcul scientifique, parmi d’autres possiblités…mais il n’en fût rien. Plusieurs entreprises conseillées par IBM ont eu le courage de se lancer dans d’immenses opérations de réécritures de l’ensemble de leurs programmes. Sombre échec pour ces derniers puisque le PL/1 est aujourd’hui tombé aux oubliettes.
Cobol vs Pascal
Une troisième révolution majeure apparaît avec l’arrivée du langage Pascal dans les années 70-80. Ce langage de programmation impératif avec une syntaxe claire et rigoureuse, facilitait la structuration des programmes. Un code intermédiaire était généré par un compilateur, qui était ensuite interprété par une machine virutelle. Ainsi, a vu le jour la fameuse portabilité des programmes. Le Pascal a connu un succès temporaire avant d’être remplacé par le Turbo-Pascal puis rapidemment dépassé par l’arrivée du langage C.
Cobol vs Basic
Le Basic de Microsoft aurait également pu remplacer le Cobol de par son extrême facilité d’utilisation et sa rapidité d’apprentissage. Une longue série de Basic ont été développé comme le Quik Basic ou le Visual Basic, utilisés par des millions de programmeurs dans le monde. Ce n’est que lorsque Microsoft pris la décision d’intégrer Basic dans son architecture .NET et de l’orienter objet pour obtenir Visual Basic.NET en 2001, que les problèmes commençèrent. En effet, l’arrivée de cette innovation a engendré une incompatibilité avec beaucoup d’anciens programmes, et il a fallu tout réécrire. Seulement le problème était simple : les programmeurs Basic ne disposaient pas des compétences adéquates pour utiliser cette toute nouvelle version de Basic. Ces derniers se sont donc tournés vers des langages plus simples à l’image du PHP. Le Cobol lui a donc survécu.
Cobol vs Java
Aujourd’hui le plus grand concurrent du Cobol, c’est Java. Vous pouvez d’ailleurs consulter notre précédent article sur le langage Java et son histoire. Son succès réside dans sa portabilité et dans son intérprétation de code via la Java Virtual Machine. Ainsi avec le Java, n’importe quel code développé sur une machine donnée peut être repris sur n’importe quel autre système (« Write once, run everywhere »). Sa diffusion fut relativement rapide sur les postes de travails grâce notamment aux applets et aux servlets (côté serveur). Cependant Java connaît des limites qui ont assez vite soulevé de nombreuses questions. L’exécution du code Java est relativement plus lente que celui du code compilé et la gestion de la mémoire n’est pas extraodinaire. Autre limite : les coûts de développement des applications Java sont très élevés car cela néccesite des compétences fortes en développement donc de faire appel à des développeurs très experimentés. De plus, la création prends beaucoup de temps. S’ajoute à tout ça, une maintenance relativement longue donc coûteuse. Une entreprise IT nommé Cast Software avait d’ailleurs estimé qu’il est 4 fois plus coûteux de maintenir du code Java que du Cobol. Voilà pourquoi il n’était pas pertinent de remplacer des milliards de ligne de code en Cobol par du Java. Aujourd’hui, les choses ont pas mal changer mais le problème reste relativement le même. Il est nécessaire d’étudier scrupuleusement ce que représente les coûts de développement, de maintenance, et d’exploitation d’un projet en Cobol de celui en Java et de les comparer minutieusement. Cela reste bien sur du cas par cas mais on comprends assez rapidemment pourquoi le milieu bancaire ne tire peu d’intérêt à migrer sur du Java.
Le développeur Cobol est-il en voie de disparition ?
L’image quelque peu « démodé » que renvoie le langage Cobol soulève le problème de sa non-attractivité envers les jeunes développeurs. En plus de ça, les développeurs Cobol actuellement en poste sont majoritairement seniors et se pose donc le problème de leur départ en retraite. L’étude de MicroFocus expliquait d’ailleurs en 2013, qu’il existait très peu de formations au Cobol. Sur 235 formations supérieurs en informatique recensées en France à l’époque, seulement 4 possédaient une formation Cobol, principalement des IUT. La plupart des étudiants sont formés sur des langages plus en vogue, et la tendance est d’apprendre Java au détriment du Cobol. Mais alors comment peut-on faire face à cette indifférence au langage le plus répandu dans le monde et répondre également aux demandes croissantes des entreprises ? Probablement en proposant déjà des meilleurs avantages profesionnels que ceux qui sont accordés actuellement aux développeurs Cobol, mais aussi et surtout en essayant de mieux promouvoir les formations au sein des universités et des écoles d’ingénieurs. Une chose est sûr, si vous développez en Cobol, vous avez une garantie de travail très élevée.
Source : Le Monde Informatique / ZDnet / Blog de Claude Salzman, consultant en système d’information
Postuler
bonjour,
et le COBOL évolue en permanence, nous sommes maintenant à COBOL LE.
Forza COBOL
Alain ( 35 ans de COBOL )
Helas peu valorisant aux yeus des SSII…..
la facturation journaliere est peu élevé d ou le salaire aussi…..
Je confirme ce que nokia_nokia a dit, la facturation est minable et c’est pas très valorisant.
Bonjour,
Le prix de facturation va bientôt monter en flèche, et l’attractivité et l’intérêt pour ce langage aussi….’
Cobol à intégré dans ses dernières versions toutes les innovations souhaitables des autres lanages, et son seul inconvénient est d’ être assez verbeux pour décrire les données, mais cet inconvénient s’est tourné en avantage avec les bibliothèques standard de copy de descriptions, facilitant très grandement la maintanibilite des programmes.
Le véritable sujet de préoccupation prioritaire est donc de revaloriser l’enseignement et l’entraînement à la conception et l’écriture de l’algorithmique structurée, incluant sa modélisation graphique hiérarchique, ceci à partir de la définition hierarchique des données à produire en résultat et des données permanentes et intermédiaires à manipuler, et à l’écriture des algorithmes en pseudo-langage naturel.
Le véritable parent pauvre de la formation est bien trop souvent la connaissance et l’aisance méthodologiques et en modélisation apte à revaloriser l’attrait pour la conception et l’écriture des programmes et sa dimension très fortement ludique et apaisante.
Bien cordialement et sincèrement.
Pierre Fischof.
J’ai écris des centaines de programmes avec ce langage, et je suis sûr qu’il va encore survivre. Les cobolistes sont des pros,
aiment leurs programmes, ils sont respectés et ne s’amusent jamais a écrire des virus, et les entreprises ont confiance dans ces gens.
Cobol est bien vivant, les facturations varient énormément selon les besoins des clients.
Pour ce qui est des formations, nous avons repris le flambeau d’IBM sur le système, la production ET le développement. Nous avons déjà monté plus d’une dizaine d’école en partenariat avec des clients et avons un partenariat avec l’UPEC. (d’autres à venir…).
Nous croyons et défendons les valeurs du Mainframe…tel est notre crédo…a tel point que nous avons développé une suite logiciel permettant de convaincre très souvent les DSI de réinvestir sur leur Mainframe !
N’hésitez pas à consulter notre site pour en savoir plus et nous contacter…nous recrutons 😉
Bonjour,
Je suis finissant d’un bac en gestion des technologie d’affaire à l’université. Je travail présentement dans une banque qui utilise la mainfraime et on m’a proposer de me former en Cobol puisqu’il y a beaucoup de personnes qui partent à la retraite et qu’il souhaite avoir de la relève. Au début je n’étais pas vraiment chaud à l’idée, cependant je me suis dit que cela pourrait devenir payant dans 2-3 ans. Est-ce que je dois essayer selon-vous ? Et est-ce que c’est un langage qui est difficile à apprendre.
PS: Je viens du Québec et non de la France 🙂
Bonjour Mathieu,
Si vous êtes intéressés par le développement, cela semble être une belle opportunité, le langage n’est pas des plus difficiles à appréhender. En effet, les personnes maîtrisant le langage Cobol sont sur le départ et il faudra certainement les remplacer dans un avenir proche. Néanmoins, je ne sais pas exactement ce qu’il en est de la situation au Québec.
Bon courage !
Bonjour,
Connaissez-vous des ouvrages, sites ou formation, pour se former à cobol.
Merci pour la réponse
Bonjour, vous pouvez surement trouver cela sur OpenClassRooms, Zeste de savoir, ou autre plateforme d’apprentissage en ligne. Vous pouvez également trouver des pdf gratuits sur le net pour cerner les bases et vous initier au langage. Bonne journée
Pour apporter ma contribution à ce débat, voici ma vision de ce langage.
Je trouve qu’au point de vue du coût et du développement d’une application, Cobol n’est pas cher.
Cobol est un langage simple, facilement maîtrisable, peu dépendant du système, ne nécessite pas un framework de développement compliqué …
Quand il est bien développé, il est modulaire, structuré, pas de bugs.
Il tire sutout sa force dans les batchs.
Il ne coute pas cher au management, efficace dans ce qu’on lui demande de faire .. .
Alors pourquoi est-il déprécié ? A mon avis …
– Il souffre du manque d’un interface utilisateur en natif. Chaque entreprise a sa propre popote pour résoudre le problème.
– Le développeur se trouve vite bloqué. Au bout de +- 2 ans il maitrise déjà presque tout du Cobol.
Dans un développement un engineer va mettre 80% de son temps dans le core business (entreprise dépendant) et 20% en technique Cobol pure.
Le développeur ne se vend donc pas bien, et sa valeur est dans le core business.
Il est condamné à rester longtemps dans son entreprise.
– La tournure que prend le monde ….
Le monde veut tout immédiatement, s’il n’y a pas de réponse dans les 10s on n’est pas content, et Cobol est mal préparé pour ça.
– Les apps se développent vertigineusement, je ne vois pas le Cobol percer dans les développements, il y a d’autres langages plus adaptés.
Le Cobol prend sûrement encore un certain créneau, mais un retour en arrière est impossible.
Il manque aussi une chose essentiel a COBOL, une licence libre, une implémentation PC/Linux et des tutoriels gratuits sur internet. Si tel était le cas, il y aurait des formation supérieur (car le prix y est ausi un frein) et il y aurait des développeurs a s auto former.
On peut se rabattre sur gnuCOBOL 2.2 pour se faire la main. Il n’est pas précompilé donc pas facile de démarrer avec le package.
Néanmoins je l’utilise avec OpenCobolIDE déjà précompilé avec gnuCOBOL 2.0 et offre un environnement de dévelopement avec éditeur prêt à l’emploi. Malheureusement l’auteur ColinDuquesnoy a arrêté le dévelopement. Si des gens pouvaient reprendre les rênes, ce serait intéressant.
Le problème du Cobol n’est pas le langage en soi, mais son environnement.
L’article mentionne : « secteur bancaire et/ou administratif », « 200 milliards de lignes de code », « 60% des applications critiques » et « exemple de longévité ».
Traduction : 200 milliards de lignes d’archéocode, maintenu en vie par un demi-siècle de patchs et de bidouillages, sur des applications critiques, dans un environnement professionnel purement bureaucratique.
Tellement sexy.
J’en ai fait pendant 30 ans, par finir par comprendre que le « go to » en était le poison …
En réponse à CHVLR. J’ai enseigné le COBOL de 1977 jusqu’à ma retraite en 2006 Dès 1985, j’ai couplé cet apprentissage avec la méthode de programmation des arbres programmatiques où l’usage du « go to » y était impossible !!
Le problème du langage COBOL est le même que celui du latin rapporté au français actuel. Connaitre le latin sert pour les prêtres et les médecins, c’est tout. COBOL c’est pareil. Le code « nouveau » écrit en COBOL sert à la maintenance de systèmes mainframe (IBM-Z et compagnie), et pour que l’existant continue à fonctionner poru pas trop cher.
Mais la paresse, et l’ignorance des commanditaires (les fameux très grands comptes), conduit à mettre de côté toutes les évolutions techniques (électroniques), pour imposer une « stabilité » magique (car tenant par miracle), et continuer à utiliser des logiciels codés par des personnes retraitées (voire mortes), ayant just oublier de documenter correctement leurs programmes.
Le portage de l’applicatif ne se fait pas par paresse, pas par incapacité, et aussi par ignorance. On l’oublie, mais une génération informatique c’est 3 années, pas 25. Donc cela fait 20 générations au moins que le COBOL existe, soit plus de 500 années humaines. Essayez donc de présenter vos comptes suivant les normes comptables de la renaissance aux services des impôts. On va bien rigoler.
Et bien l’existant en COBOL c’est pareil. Ca fonctionne, ça plante pas trop (on va mettre de côté aussi l’usage en mode speed trading du code COBOL, qui provoque régulièrement des pertes de transactions assez coûteuses), mais la documentation revient à faire de l’archéologie, et tenter de déchiffrer le linéaire A.
Je postule, je suis banquier et je crée ma banque. COBOL sera exclu. Peu documenté, matériel imposé (mainframe IBM), modèle logiciel contraint (DB-2 & Co). Ouverture du code et du modèle de développement voisine de zéro. Donc, un système coûteux de type boite noire, à la Apple, et sans possibilité réelle de quitter le piège sans y laisser des plumes.
Les solutions open-sources existent, et développer avec est plus simple, stable, durable et surtout, elles peuvent évoluer avec le matériel. COBOL est trop contraignant. Il est temps de développer des solutions alternatives ouvertes et cohérentes.
Alors la Jean-Marc, j’ai l’impression que tu ne sais pas de quoi tu parles ????
Le français vient du latin, derrière chaque mot français tu peux retrouver l’origine et sa signification.
Regarde dans le dictionnaire (s’il en existe encore) un mot au hasard, ça commence toujours par l’origine latine pour donner la définition du mot.
Je suis coboliste de 56 ans, j’ai connu plusieurs migrations vers Java pour des grandes institutions. Le résultat final a toujours été le même, a savoir que l’application historique (cobol) sont répartie dans 2 voir 3 environnements : Cobol et Java. En définitive on a splitter les fonctionnalités sur ces 2 systèmes.
Pourtant on a donner tous les moyens pour que la migration totale se fasse, mais chaque environnement a ses qualités et ses défauts/limites
Je suis un retraité informaticien, je programme en Cobol depuis 1975, j’ai connu assembleur pl1 Pascal r php visual basic fortran mais dès que j’ai un problème faisant appel aux fichiers indexés, table et tri je retourne à mon ami Cobol
Coboliste de 56 ans et je suis encore actif mais encore combien de temps ? pension ?
Il faut relativiser, j’ai répondu un poste à Jean-Marc, je rajoute un complément à sa critique sur « peu documenté, matériel imposé, modèle logiciel contraint (DB-2 & Co) » ??????? éh bien je peux dire qu’il a une vision et connaissance très très très limitée sur ses 3 points.
Le cobol étant implémenté majoritairement, pourquoi ? est-ce le coût ? oui et non.
Ma vision est que les 2 environnements Cobol et Java cohabitant me semble le meilleur résultat compromis.
Chaque environnement a ses qualités et ses limites, et il faut exploiter toutes les qualités.
Un batch fait en Java n’est pas envisable à cause du stabilité et sa lenteur, sa limite et dépendance Websphere, ……, par expérience concrète ce que le cobol exécute en 4 minutes, le java renvoit un nullpointerexception après 30min pour raison timeout. Conséquence : toute la chaine des jobs (schedule) est intérompue …. que du stress le matin en arrivant au bureau pour javaliste. Solution apportée ? : splitter le fichier en plusieurs parts et exécuter autant de fois qu’il y a de fichier. Sur cette expérience comparez le coût ????
Alors que dans une seule soirée une centaines de pgm cobol sont exécutée dans les batchs de nuit, je vois mal comment on peu gérer si c’est fait en Java.
Juste un exemple que je vous donne, il faut pas mettre en cause le cobol ni le java, il s’agit d’un mauvais choix politique de la part de la direction/responsable IT.
Je suis coboliste et je reconnais aussi que Java a beaucoup de qualités.
A ceux qui sont à la cherche ob, surtout les jeunes formés en Java, formez-vous en cobol, car la tendance du marché est en cours de mutation, on recherche de plus en plus une double compétences, d’ici 10 années il n’y aura plus de coboliste.
Bonjour Mik,
Je suis actuellement une formation de programmation, on m’a parlé il n’y a pas longtemps de se langage.
J’ai regardé les pour et contre du cobol. Mais comme tu as de la bouteille dans le domaine (si je peux me permettre).
Pourrions-nous discuter ensemble un moment pour m’éclaircir quelques points?
Merci.
Bonjour,
Je suis DSI, je pars bientôt à la retraite, j’ai beaucoup pratiqué et adoré développer en COBOL, et je souhaiterais m’y remettre en tant que retraité junior.
Connaissez-vous des sites, contacts qui permettraient d’entrer en relation avec des sociétés qui auraient des besoins dans ce domaine ?
Je vous remercie par avance pour votre retour.
Meilleures salutations.
Cobol a pour avantage sa très (trop ?…) grande base d’applications écrites avec ce premier langage de programmation (plus de 60 ans d’âge), qui (on l’oublie toujours) a été créé avec les contraintes des matériels de l’époque. Pour commencer il a été développé pour gérer des machines de tri et traitement de fiches cartonnées, qui servaient pour l’enregistrement des informations. Ces machines ont été majoritairement achetées par (oh surprise !…), ceux qui avaient des sous : banques, sociétés financières, états, et grandes administrations.
Ensuite, portage vers des machines plus élaborées (avec les premiers CPU), ne s’est pas fait (paresse des chercheurs, refus de financement, conservatisme pathologique des clients, …).
C’est pour ça aussi qu’une question se pose : quel satellite télécom à des logiciels de contrôle codé an Cobol ?… Quelle application médicale critique est rédigée en Cobol ?… Qui a un smartphone avec un OS codé en Cobol ?…
La réponse est simple, personne. Parce que Cobol n’est pas adapté au matériels actuels. Et compiler du Cobol vers les machines actuelles est de plus en plus risqué. Sans oublier l’absence d’ouverture du code source des outils de compilation, et c’est idiot.
Quand aux arguments avancés, genre sécurité, rapidité, fiabilité, trop coûteux, etc… C’est juste du flan. Si ça reste sûr et fiable, et rapide, et patati patata, c’est juste que les lignes de communications utilisées sont difficilement accessibles (comme celles de l’armée, ou encore des services de l’état). C’est l’isolement qui permet la relative sécurité des plateformes qui utilisent les applis en Cobol, pas le langage lui-même. Et cet isolement est de plus en plus faible (avec le paiement en ligne, les applis client pour contrôle de compte, et les banques virtuelles).
Soit Cobol se réécrit complètement, soit Cobol meurt. Cobol n’a que deux possibilités, évoluer ou mourir de vieillesse.