COBOL, 62 ans, testé positif au Coronavirus. Quelles sont les conséquences?
Cela fait déjà un an que nous traversons une crise planétaire. Elle aura impacté énormément de secteur dont celui du domaine informatique. Le phénomène marquant révélé dans ce milieu, c’est le manque de développeur dans le monde du Mainframe.
La pénurie de programmeurs Cobol a été mis en lumière dès lors que les premières évolutions de l’environnement des anciens systèmes ont été nécessaire dû à la Covid-19. L’un des pays qui en a le plus souffert n’est qu’autre que les États-Unis. Les obstacles rencontrés reflètent l’état d’esprit et la manière dont est perçu le Cobol en 2020/2021.
Effectivement, le manque de programmeur Cobol a été très marqué et même médiatisé. L’effet immédiat de la crise est la perte d’emploi qui va causer une augmentation de manière considérable le taux de chômage dans tout le pays (et dans le monde entier au passage). Le souci est que le système de gestion du chômage est géré par …. le Cobol! De tel changement nécessitent des mises à jours du système informatique.
C’est à ce moment précis que commence une série de mauvaises surprises. Premier constat, une grosse vague de développeur avait déjà pris leur retraite. Deuxième constat, il n’y a pas eu de remplacement prévu dû à cette vague. Troisième constat, il y a très peu de programmeurs Cobol disponible et pratiquement pas de jeune. Ce phénomène est dû au fait qu’un grand nombre d’Université n’enseigne plus ce langage estimant qu’il est devenu obsolète.
Cette mauvaise série a poussé les États concernés à médiatiser cette difficulté rencontrée afin d’avoir des renforts le plus rapidement possible. La solution express du moment est de rappeler les personnes volontaires et retraitées pour débloquer la situation. C’est une belle option mais seulement temporaire!
Cette crise sanitaire a la malheureuse réputation d’impacter les plus âgés (plus de 60 ans). On estime que la moyenne d’âge des experts Cobol se situe entre 55 et 60 ans. Ce qui fait que le domaine du Mainframe est directement touché par cette pandémie. Certains des développeurs les plus âgés ont contracté le virus, ce qui fait réduire encore plus les effectifs. De ce fait, la Covid-19 aura pointé du doigt le manque d’expert en Cobol et fait même affaiblir les équipes déjà en place.
La seule vraie solution est de former le plus grand nombre de développeur sur le langage afin d’assurer une relève et de transmettre le savoir et les compétences qui permettra de gérer les futurs projets. Que ce soit pour mettre à jour les systèmes actuels ou faire une potentielle migration vers un autre langage plus moderne, le nombre d’évolution ne désemplira pas.
Pourrions-nous éradiquer tous les symptômes dans le monde du Mainframe? Arriverons-nous à rectifier le tir et à apprendre de nos erreurs? Sommes-nous capable d’attirer plus de jeunes à ce langage longtemps considéré comme vieux et démodé? Une chose est sure, c’est que le Cobol reste un élément incontournable dans nos systèmes et aura un bel avenir devant lui. La Covid-19 a peut-être bien gagné cette petite bataille mais certainement pas la guerre. Espérons que les dispositifs mis en place porteront ces fruits et permettront de ne plus reproduire la même situation que nous avons traversé.
Sharif HAMED
J’espère que cet article vous a aidé à mieux comprendre comment est perçu le COBOL et les conséquences de cette perception. N’hésitez pas à partager si vous aimez et de donner votre avis sur le sujet. Cela m’encouragera à écrire d’autres articles concernant le monde du Mainframe.
Qui parle encore le Cobol, l’un des plus vieux langages informatiques ? Majoritairement cinquantenaires, les derniers développeurs partent petit à petit à la retraite, sans qu’ils soient remplacés. Problème : le Cobol est encore utilisé dans des infrastructures critiques, comme les banques.
« Nous sommes en l’an 3000, et l’humanité a enfin trouvé un moyen de ressusciter les personnes qui ont été cryogénisées », commence la blague. « La première femme à être ramenée est une développeuse, et elle n’en revient pas ! Elle pose beaucoup de questions, mais le médecin en chef arrive en courant et la coupe, ‘C’est urgent ! Une question de vie ou de mort ! Est ce que vous savez coder en Cobol ?’ ». Le Cobol, c’est de l’histoire ancienne, résument ceux qui savent encore l’écrire, un des tout premiers langages informatiques, un ancêtre vieux de plus de 60 ans, que peu de gens aujourd’hui maîtrisent.
Pourtant, le Cobol est partout : plus de 220 milliards de lignes de code existent encore aujourd’hui, auxquelles sont ajoutées plusieurs millions d’autres tous les ans. Aux États-Unis, où le Cobol structure la majorité des sites gouvernementaux, le manque d’experts du langage a entraîné de nombreux problèmes. À cause de la pandémie de Covid-19, un nombre record d’Américains se sont connectés sur l’équivalent de Pôle Emploi, faisant crasher le système. Seulement, personne n’a su le remettre en place dans l’immédiat, créant la panique au sein de certaines administrations et retardant de plusieurs semaines l’arrivée des aides financières.
En France, les demandes d’aides financières se sont faites par mail, en fournissant à l’organisme correspondant un formulaire comportant diverses informations. Il n’y a de ce fait pas eu de problèmes de saturation des sites du gouvernement, bien que le site de la sécurité sociale soit programmé en Cobol. La situation pourrait cependant vite devenir problématique : l’âge moyen des développeurs se situe autour de 55 ans.
Un langage universel
Le Cobol, abréviation de « common business-oriented language » et traduisible par « langage courant pour les affaires », est une création de l’armée américaine. En 1959, elle souhaite développer un langage commun aux premiers ordinateurs qui permettrait lui-même d’écrire de nouveaux programmes, ce qui était impossible jusque-là avec les langages existants. Le groupe de travail mis en place souhaite cependant que son utilisation ne soit pas réservée à l’armée et veut doter le Cobol de fonctions lui permettant d’être largement utilisé, et surtout simple à comprendre. La capitaine de l’armée Grace Hopper, qui sera surnommée plus tard la « grand-mère du Cobol », prévoit d’utiliser des commandes basées sur l’anglais plutôt que sur des expressions algébriques, le rendant facile à lire.
« Par exemple, si on veut retrouver un jeu de données en particulier, on utilise SEARCH, et si on veut l’afficher on utiliser DISPLAY, c’est plutôt intuitif », explique Véronique Gianfermi, une développeuse Cobol indépendante qui travaille dans les systèmes bancaires. « C’est un langage simple, efficace et robuste ». Ce sont ces qualités qui feront sa popularité : entre 1960 et 1980, le Cobol est le langage de référence, utilisé par les banques, les assurances, les compagnies aériennes, les impôts… Si sa popularité diminue au fil du temps avec l’arrivée de langages plus modernes, le Cobol reste toujours là, à faire tourner les back offices.
Aujourd’hui encore, plus de 70 % des distributeurs de billets et entre 60 et 80 % des activités des entreprises reposent sur des applications Cobol. « Une personne lambda a recours au moins 8 fois par jour à un système géré en Cobol, sans en avoir conscience », indique Philippe Fraysse, un spécialiste du Cobol qui édite un logiciel de développement pour le langage. C’est tout un écosystème, d’une complexité édifiante, qui a été construit depuis plus de 60 ans et représente aujourd’hui l’un des socles de l’informatique.
La pénurie ?
Alors pourquoi y a-t-il une pénurie de développeurs aux États-Unis ? Parce que le Cobol est dépassé. « Ça fait 30 ans qu’on dit que le Cobol est mort. Il est toujours là, mais ça fait 30 ans que personne ne veut en faire », résume Philippe à Numerama. C’est partout le même son de cloche : « les jeunes ne veulent pas faire ça », faisant que « les cobolistes », comme ils se surnomment, sont en grande majorité cinquantenaires, approchant de la retraite. Et personne ne se bouscule pour prendre leur place.
« Il n’y a cependant pas encore de pénurie en France », rassure Alain Dubois. Âgé de 71 ans, ce développeur admet cependant que son profil est recherché, et qu’il n’a jamais eu de mal à trouver du travail, malgré son âge. Véronique confirme : si elle n’a « jamais été accueillie comme le messie » en arrivant dans une entreprise, les missions Cobol sont légion. Ils ont tous les deux été formés au Cobol lors de son âge d’or, quand la « demande explosait et qu’on formait des gens en masse pour y répondre ».
POUR SE FORMER, IL FAUT DANS LA PLUPART DU TEMPS « APPRENDRE SUR LE TAS ».
Beaucoup de jeunes ayant suivi des études scientifiques, comme des biologistes ou des chimistes n’arrivant pas à trouver du travail à la sortie se tournent vers ces formations, dispensées de manière expéditive en seulement quelques mois. Encore un avantage du Cobol : grâce à sa syntaxe intuitive, pas besoin d’avoir au préalable de « bagage en informatique », détaille Véronique.
Aujourd’hui, les écoles ne dispensent plus de formation en Cobol. Pour se former, il faut dans la plupart du temps « apprendre sur le tas ». « Lors de mon apprentissage dans une filiale du Crédit Agricole, on m’a mis sur une mission d’archivage de relevé bancaire », raconte Momar Ndiaye. « Tous les systèmes déjà mis en place étaient en Cobol, du coup j’ai été obligé de m’y mettre ». Aujourd’hui âgé de 29 ans, il travaille comme consultant chez LCL et estime que les profils juniors sont une minorité, représentant seulement « 10 % des personnes connaissant le langage ».
Comme un minitel
« Personne ne veut travailler sur des missions Cobol en sortie d’école », déclare-t-il, « ils veulent des postes plus intéressants, sur du développement web ou des applications ». Il faut dire que le Cobol souffre d’une mauvaise image. « Ceux qui ne travaillent pas directement avec le langage sont persuadés que c’est un truc de vieux, que ce n’est pas une compétence d’avenir ». L’interface Cobol leur donne raison. Police de caractères austère, vert fluo sur fond noir, pas de souris… « L’aspect minitel refroidit les potentiels étudiants », reconnaît Serge Gueguen, un formateur Cobol depuis 20 ans.
De plus, « les missions Cobol ne sont pas mises en avant sur les sites de recrutement », reprend Momar, « parce que ce n’est pas un boulot tendance ». Les missions proposées peuvent sembler rébarbatives. Beaucoup de mises à jour, peu de développement, ou alors sur des projets de back-office bancaires… On ne peut pas créer de « trucs cool » en Cobol. « Mon fils commence déjà à me dire que Java est dépassé, qu’il veut travailler sur des langages développés par Google, alors le Cobol… », complète Véronique.
Momar a cependant fait le choix de continuer. « Je me suis vite dit que c’était intéressant de parler ce langage. Les banques ont beau développer de nouvelles applications en Java, la base reste en Cobol. Tout le monde a besoin de ce langage, les gens ne se rendent pas compte de l’étendue qu’il a dans la vie de tous les jours ». S’il a décidé de poursuivre, c’est également par calcul. « Pour l’instant, les missions Cobol sont mal payées, mais les développeurs vieillissent. Dans 10 ans, il n’y aura plus personne, et à ce moment-là, les banques seront prêtes à payer une fortune pour mes compétences ».
Des formations existent toujours, mais ne séduisent pas
Si les écoles ne forment plus au Cobol, il existe encore des formations disponibles pour les nouveaux cobolistes. Ils ne sont souvent pas là par choix. « On remarque que certaines entreprises recrutent des gens sans leur dire qu’ils vont faire du Cobol », annonce Serge. « On les affecte sur ces projets par surprise, forcément ils n’apprécient pas du tout ». Il travaille également avec beaucoup de particuliers en reconversion, « profils scientifiques à bac +5, qui décident de se mettre à l’informatique, mais qui n’ont aucune expérience préalable ». Comme beaucoup de leurs prédécesseurs, formés dans les années 80.
Mais ce n’est cette fois-ci pas parce que la demande explose, au contraire. « Nous avons moins de demandes depuis à peu près 5 ans. En 2019, nous avons formé 6 personnes. En 2018, personne ». Le peu de personnes formées est ensuite majoritairement embauché par des ESN (Entreprises de Service Numériques, anciennes SS2I), qui placent ensuite leurs cobolistes dans des banques afin d’assurer des mises à jour ponctuelles ou de nouveaux projets de développement. « On ne voit pas vraiment les nouveaux formés remplacer ceux qui partent à la retraite ».
Formés, mais pas experts
C’est justement là que le bât blesse : « les entreprises ont pris conscience du problème et forment leurs ingénieurs, mais ce sont des formations express, au rabais », explique Serge. La relative facilité d’apprentissage du Cobol cache un autre problème : la complexité de tout l’écosystème construit autour de ses applications. Chaque entreprise ayant son organisation propre, « un développeur très compétent met tout de même près de 4 ans à être optimal sur un autre système, qui aura d’autres règles de fonctionnement ».
De vieilles structures, construites sur des dizaines d’années par couches successives, des développeurs différents (« qui laissent parfois des passages codés de manière dégueulasse », nous confie l’un d’eux), et sans documentation. « La situation est pire lorsqu’il y a eu des rachats et des fusions. Les systèmes sont empilés de manière très complexe, avec beaucoup d’interactions entre eux », détaille François Chaix, qui développe des applications pour les institutions financières et côtoie le Cobol depuis plus d’une dizaine d’années . « Les systèmes informatiques, c’est le carbone 14 des banques ».
« QUAND TOUT LE MONDE TE DIT QU’UN LANGAGE EST MORT, ÇA NE MOTIVE PAS À RESTER »
Pour certains environnements très complexes, François reconnaît qu’il ne reste parfois « qu’un seul coboliste qui s’y connaît, mais pour d’autres il y en a 50 de disponibles ». « Le manque se situe seulement sur des parties très spéciales. Pour l’instant, je n’ai jamais vu quelqu’un qui ne savait pas vers qui se tourner », tempère-t-il. « Mais ça pourrait peut-être changer ».
Il est difficile de garder les gens sur des missions Cobol. Les profils juniors veulent autre chose, il y a beaucoup de turn over. Au total, les projets comptent en moyenne 8 ans de retard, selon François. « Quand tout le monde te dit qu’un langage est mort, ça ne motive pas à rester », résume Momar.
Trop compliqué de migrer
Alors, pourquoi continuer en Cobol ? Migrer l’ensemble des données d’une banque vers un nouveau système informatique présente plusieurs problèmes d’envergure. Tout d’abord, le prix : « une opération comme ça coûterait plusieurs dizaines de millions d’euros, voire des centaines », estime François. Un changement de système nécessiterait en effet au préalable des années de travail, et représenterait un casse-tête. Serge est d’ailleurs catégorique, ces migrations sont extrêmement risquées. « Ce sont de vieilles lignes de codes, très peu documentées : il suffit qu’on oublie de remplacer une petite partie pour que tout soit perdu ».
En 2018, la banque anglaise TSB en a fait l’expérience. Après une erreur, près de 1,9 million de clients n’ont pas eu accès à leurs comptes pendant presque un mois, d’autres n’ont pas pu d’utiliser leurs cartes bancaires, tandis que certains ont eu accès pendant plusieurs jours aux comptes d’autres personnes. Une catastrophe, qui a coûté à TSB 330 millions de livres et plus de 80 000 clients.
« LA MÊME CHOSE VA ARRIVER À JAVA D’ICI 20 ANS »
Enfin, « pourquoi changer une méthode qui marche ? », demande Véronique. « Le Cobol est ultra robuste, quand tu as besoin de traiter des millions d’informations rapidement, c’est super solide et très rassurant ». Une machine de guerre, qui marche toujours 60 ans après sa conception. « La technologie peut sembler vieillotte, mais sur les nouvelles applications que nous développons, à chaque fois qu’il y a un problème, ça vient de la partie Java. Jamais du Cobol ».
Destiné à mourir, mais toujours vivant, le Cobol est un code à part entière chez les développeurs, à mi-chemin entre créature mythique et Renault 4L. « À un moment où à un autre, il n’y aura plus suffisamment de développeurs Cobol », confie Caroline Couturier, qui travaille à la direction informatique de LCL, « on s’y prépare ». « Il y a 5 ans, tout le monde disait que la pénurie arriverait maintenant. Nous y sommes, et tout va bien pour l’instant », déclare Serge, avant de lancer : « La date est impossible à prévoir, mais elle arrive ».
Peut-être pas aujourd’hui, ni demain, mais sûrement. « C’est normal, c’est le progrès. La même chose va arriver à Java d’ici 20 ans », prophétise-t-il.
Le déficit en compétences Cobol n'est ni aussi extrême ni aussi simple que l'on pourrait le penser. Pour maintenir leurs systèmes Cobol, les entreprises peuvent choisir entre la formation de ressources internes ou le recours à des consultants spécialisés. Ce qu'il faudrait savoir avant de franchir le pas.
Les besoins en compétences en Cobol se font périodiquement ressentir dès qu’une application installée depuis quelques décennies doit être modifiée. Des incidents qui défraient quelquefois la chronique comme c’est arrivé dans l’Etat du New Jersey lorsque l’administration n’a pas pu, au début de la pandémie, incorporer les dispositions du CARES Act apportant un complément financier aux personnes sans emploi. Le problème remonte à plus de 20 ans et les programmes Cobol sont toujours à l’oeuvre dans de nombreux systèmes d’information, à moitié compris par les entreprises qui continuent à s’appuyer sur eux après l’échec de coûteux projets engagés pour les remplacer. Et maintenant, de nombreux experts réfléchissent à de nouvelles façons d’aborder le problème et de développer des compétences pour travailler avec Cobol.
L’un des problèmes dans ce contexte, c’est que l’on suppose souvent l’existence de profils spécifiques comme si Cobol était quelque chose de bien différent du reste du monde de la programmation. Ce n’est pas le cas. Pour Mark Cresswell, PDG de LzLabs, c’est une fausse piste. Il rappelle que Cobol est juste une syntaxe pour exprimer des règles métiers. « La plupart des programmeurs sont polyglottes. Vous pouvez avoir une spécialisation ou être meilleur dans tel ou tel langage, mais vous ne vous direz pas que vous n’allez pas faire de C++ parce que vous êtes un programmeur Java. Comme tous les autres langages, Cobol a ses propres particularités ». Il faut garder en tête que Cobol signifie « Common business-oriented language », c’est un langage écrit pour les problématiques de gestion d’entreprise. Créé en 1950, il a été spécialement conçu pour permettre aux non-spécialistes de programmer les ordinateurs qui commençaient à arriver dans le monde des échanges commerciaux. « Il est censé être facile à lire et à comprendre », rappelle Emad Georgy, CTO de Georgy Technology Leadership. « Je pense qu’il y a cette énorme peur autour de lui parce qu’il fait fonctionner des systèmes assez critiques, mais en fait, en tant que programmeur, il est très facile à apprendre ».
Expertise sur IMS et CICS également requise
Cobol n’est pas construit autour d’une programmation orientée objet et manque de fonctionnalités d’héritage, de sorte que ceux qui se sont fait les dents sur les systèmes modernes auront en fait plus de facilités à le prendre en main que le contraire. Bien qu’il existe néanmoins des versions orientées objet de Cobol, elles ne sont pas utilisées dans les anciens systèmes qui utilisent Cobol en production tels qu’on peut les trouver le plus souvent. En réalité, quand on parle de « pénurie de compétences Cobol », c’est plutôt un raccourci pour désigner quelque chose de plus compliqué. On pourrait, par exemple, télécharger GnuCobol et commencer à jouer avec du code qui pourrait tourner ensuite sur une machine Linux familière, mais cela ne préparerait pas à l’expérience de travailler avec du code Cobol tel qu’il est utilisé en production dans son contexte d’origine.
« Apprendre Cobol est facile, mais ses applications requièrent une expertise rare avec les technologies plus anciennes telles que les systèmes de base de données IMS et CICS d’IBM », indique Michael Yurushkin, CTO et fondateur de BroutonLab. « Le principal défi n’est pas d’apprendre le langage, mais de disposer d’une expertise sur des technologies qui ont plusieurs décennies d’existence ». Mark Cresswell, de LzLabs, met en évidence le fait que les outils modernes utilisés ces dernières années par les développeurs ne s’appliquent tout simplement pas aux environnements mainframes. « Si je veux compiler et tester un programme, je n’appuie pas sur la petite flèche verte de la barre d’outils », fait-il remarquer. « J’exécute quelque chose qui s’appelle un travail par lots [batch job] qui fait une compilation et un lien. Lorsqu’il s’agit de configurer un environnement de test, je ne peux pas simplement lancer un container sur mon poste de travail pour tester mes modifications. Je dois parler aux administrateurs systèmes pour configurer des partitions avec des sous-système et des configurations. Tout cela allonge le cycle de développement et c’est tellement spécifique qu’il est très difficile de s’y retrouver pour quelqu’un qui est habitué à développer à la vitesse d’Internet sur des plateformes cloud ».
Démêler la logique du programme
Lorsque l’on a affaire à une application critique qui tourne depuis longtemps, démêler la logique du programme peut devenir le principal défi. « Tous ces systèmes ont été conçus au fil des décennies », souligne Ben Stevens, ingénieur en chef et architecte solution chez Art+Logic, qui a travaillé pendant des années dans des administrations gouvernementales qui s’appuyaient sur Cobol. « Si vous ne connaissez pas les tenants et les aboutissants, savoir programmer en Cobol ne servira pas à grand chose. Cela finit par devenir un projet de rétro-ingénierie sur lequel on agit en tant qu’archéologue. Même si vous connaissez le langage, c’est un peu comme si vous lisiez des textes anciens sans aucun contexte : d’accord, je peux traduire ce mot par tel mot, mais qu’est-ce-que cela signifie ? ».
Prenons le cas d’une entreprise qui utilise une base de code Cobol pour une application critique. Comment peut-elle s’assurer d’avoir accès aux compétences dont elle a besoin – tant en termes d’environnement de programmation et mainframe qu’en termes de logiques métier sous-jacente – pour maintenir son système opérationnel, au moins à court terme ? L’une des stratégies possibles consiste à travailler sur le développement de compétences en interne. Cela ne signifie pas de recruter de nouveaux programmeurs Cobol dès leur sortie de l’école (puisque cela n’existe pas). Cela ne signifie pas nécessairement non plus de retenir les anciens collaborateurs à temps complet alors qu’ils préféreraient prendre leur retraite. « Mon objectif pour mon équipe ne serait pas de leur apprendre Cobol, ce serait de leur apprendre mon système », expose Emad Georgy. « Le contexte est essentiel. Vous voulez qu’ils apprennent Cobol juste ce qu’il faut. Vous n’allez sans doute pas lancer de nouveaux projets en Cobol, il faudra donc investir au bon niveau de façon judicieuse ». L’une des façons de le faire est d’associer des développeurs internes intéressés aux ressources dont on dispose, en se concentrant sur les besoins métiers. Cela peut impliquer d’avoir des développeurs plus âgés qui ont travaillé sur l’application en question – peut-être toujours dans l’effectif ou peut-être rappelés en tant que sous-traitants – pour encadrer les plus jeunes.
Résoudre un problème spécifique en équipe
« J’aime avoir des cas d’usage ou des problèmes très spécifiques que nous essayons de résoudre avec l’apprentissage », explique M. Georgy. Par exemple en faisant travailler une équipe avec un collaborateur retraité qui vient quelques heures par semaine en leur disant : « Notre objectif d’ici la fin du mois, c’est de résoudre ce bug ». Bien sûr, les développeurs devront suivre une formation plus générale en Cobol et en programmation mainframe pour compléter ce qu’ils apprennent sur leurs propres systèmes. IBM a un intérêt évident à maintenir une masse critique de programmeurs Cobol sur le marché et propose un ensemble de ressources pédagogiques tels que des cours de programmation Cobol gratuits et des certifications de programmation mainframe. Ces temps de formation mobiliseront les équipes mais il est probable que l’investissement en vaut la peine. « Nos clients doivent également se rappeler que les applications critiques qui ont été optimisées sur les dernières décennies nécessitent elles aussi une maintenance », indique Barry Baker, vice-président logiciel sur l’activité IBM Z. S’imaginer que l’on peut le faire dans l’à peu près et sans investir dans des talents, c’est simplement une recette qui peut conduire au désastre, prévient-il.
Ne pas hésiter à demander de l’aide
Néanmoins, on peut se retrouver dans une situation où l’on ne dispose tout simplement pas des ressources internes pour surmonter son problème Cobol. Dans ce cas, on peut vouloir se tourner vers des consultants externes spécialisés dans les interventions sur les systèmes Cobol. C’est ce que fait une entreprise comme Chetu et les situations dans lesquelles elle est amenée à intervenir sont souvent assez désespérée. « Il y a eu de nombreux cas où le développeur principal de la plateforme legacy n’était plus dans l’entreprise », explique Pravin Vazirani, vice-président des opérations de Chetu. « Et la maintenance du système était faite par un développeur qui n’avait qu’une connaissance limitée du système et avait acquis juste assez d’expertise pour parvenir à faire fonctionner correctement les applications Cobol. On le voit généralement dans des endroits où l’on fait tourner des plateformes existantes avec peu ou pas de documentation appropriée ».
Pravin Vazirani pense que de nombreuses organisations, en particulier les plus petites, réaliseront des économies à long terme en recourant à des entreprises spécialisées comme la sienne. « L’expertise en développement Cobol n’est pas aussi courante en dehors des entreprises spécialisées dans les développements personnalisés, donc, à bien des égards, faire appel à l’une de ces firmes peut être moins coûteux et plus efficace plutôt que de recruter et de développer des talents internes », estime-t-il. « Et de nombreuses entreprises pourraient envisager de quitter leurs applications Cobol à plus ou moins long terme, de sorte que l’accent pourrait être davantage être mis sur l’acquisition de talents internes pouvant répondre aux besoins futurs de l’entreprise tandis qu’un tiers s’occuperait du système actuel ».
Article rédigé par Josh Fruhlinger / Infoworld (adapté par Maryse Gros)
Le langage de programmation Cobol a beau avoir 60 ans, il fait tourner une grande partie des systèmes d'entreprise les plus critiques dans le monde. Et la demande en programmeurs Cobol ne faiblit pas.
Certaines technologies ne meurent jamais, elles se fondent simplement dans le décor. Evoquer Cobol – Common Business Oriented Language – avec le développeur moyen vous vaudra d’être regardé comme si vous parliez du papier carbone, de l’essence au plomb ou du disque 78 tours. Comparé aux langages modernes tels que Go ou Python, ou même Pascal ou C, Cobol semble massif, verbeux, démodé. Mais il a résisté. Loin d’être une technologie obsolète que nous aurions abandonnée, Cobol est devenu une institution. Des bases de code Cobol massives sont toujours utilisées à travers le monde, nombre d’entre elles fonctionnant presque exactement comme elles le faisaient lorsqu’elles ont été créées. Donc, oui, Cobol est toujours pertinent et opportun, il l’est même douloureusement en fait. Ces derniers mois, Cobol a réintégré la conscience publique quand des états comme le New Jersey ont lancé un appel aux programmeurs pour les aider à transférer leurs applications Cobol dans le 21ème siècle. Qu’est-ce qui fait que ce langage se démarque encore aujourd’hui et qu’est-ce qui le rend si tenace ?
Petit historique
Cobol est apparu à la fin des années 1950 et au tout début des années 1960. Son développement était un projet soutenu par le département américain de la Défense (DoD) qui incluait un consortium de fournisseurs informatiques dont IBM, Honeywell, Sperry Rand et Burroughs. L’objectif était de créer un langage de programmation ayant les attributs suivants. Premièrement, une portabilité entre systèmes informatiques afin de faciliter la migration du logiciel à la fois entre les générations de matériels et entre les fabricants de matériels. Deuxièmement, une syntaxe plus proche de l’anglais que les autres langages de l’époque (par exemple le Fortran) pour encourager une plus large audience à y recourir, même si cela devait se faire au détriment d’une certaine vitesse opérationnelle. Troisièmement, il devait pouvoir s’adapter aux changements.
Les premières spécifications officielles sont sorties en 1960. Durant la décennie suivante, et à la consternation de ses détracteurs, Cobol devint de choix par défaut pour écrire les applications commerciales. Sa rapide propagation a résulté d’un effet de réseau. IBM, l’un des collaborateurs d’origine sur le langage, l’a adopté de façon précoce et vigoureuse et sa présence dominante dans le monde de l’informatique a contribué à l’adoption de Cobol. A cause de ses avantages de conception et de l’énorme soutien industriel dont il bénéficiait, Cobol a survécu, et de loin, aux systèmes pour lesquels il avait été élaboré à l’origine. Selon diverses estimations, en 1970, Cobol était le langage de programmation le plus utilisé dans le monde. En 1997, il devait faire tourner près de 80% des applications d’entreprise.
Le langage lui-même
Les concepteurs de Cobol ont rompu avec la syntaxe lapidaire des autres langages du moment (Fortran, encore lui). L’idée était qu’il puisse être lu et compris par des non-programmeurs, en particuliers des professionnels de la comptabilité, de la finance, de l’assurance et d’autres métiers. Prenons l’exemple d’une simple séquence « Hello World » écrite dans un des premiers dialectes de COBOL :
Pour des développeurs actuels habitués à la concision de langages tels que Python, ce code est verbeux. Mais la verbosité de Cobol vient du fait que le code est lu bien plus souvent qu’il n’est écrit, il doit donc être écrit pour être lisible. Une séquence similaire dans une version plus moderne de Cobol pourrait ressembler à cela :
Alors que cet exemple est plus concis, les mêmes principes de base s’appliquent : le code s’efforce d’être explicite sur ce qui se passe à chaque étape. Cobol a des règles strictes sur la syntaxe et sur l’organisation interne des programmes. Un programme Cobol est explicitement divisé en sections, ou divisions, qui aident à trouver et à comprendre ses composants d’un seul coup d’oeil :
– Identification division : essentiellement une section de métadonnées, contenant des détails sur le programme, son auteur, etc.
– Environnement division : contient des détails sur l’environnement de runtime, par exemple les alias pour les équipements externes, qui peuvent avoir besoin d’être modifiés lorsque le programme est exécuté sur un matériel différent. Cela aide à la portabilité entre systèmes quand, par exemple, les entrées/sorties peuvent être gérées de façon totalement différente.
– Data division : contenant les sections file et working storage, la division Data décrit les fichiers et les variables utilisés dans le programme.
– Procedure division : c’est ici que l’on trouve le véritable code du programme, séparé en unités logiques appelées sections, paragraphes, sentences et statements. Il est tentant de rapprocher, par analogie, aux modules ou fonctions, parce qu’elles remplissent à peu près les mêmes fonctions (elles divisent le code en blocs avec des contraintes sur les entrées et les sorties), mais elles sont beaucoup moins flexibles.
Des règles de formatage très strictes
Cobol a également des règles de formatage extrêmement strictes pour le code, allant jusqu’au nombre d’espaces précédant une commande. (Les utilisateurs de Python ne seront pas dépaysés) Certaines de ces restrictions sont un corollaire du passage à l’âge adulte de Cobol pendant l’ère mainframe des années 60, quand les programmes étaient encodés sur des cartes perforées et qu’il était important de respecter le respect du formatage à 80 colonnes. Mais les autres restrictions de formatage renforce la lisibilité.
L’objectif de cette discipline stricte est de rendre les programmes Cobol aussi auto-documentés que possible. Après tout, ils allaient probablement rester en place pendant des années ou des décennies. L’intention (même si le résultat final ne l’atteignait pas toujours) était de faire de chaque programme Cobol un artefact que tout développeur Cobol pourrait comprendre, même des années plus tard, sans l’aide de celui qui l’avait créé.
Les challenges de Cobol
La permanence – et l’inertie – de Cobol vient en grande partie du fait que les applications qu’il a permis de générer, ont tendance, une fois écrite, à rester en place indéfiniment, avec juste quelques modifications mineures. Plus l’application est grosse et critique pour l’activité d’une entreprise, moins on cherche à la perturber. Les mainframes, centrés aujourd’hui sur l’offre d’IBM, jouent un rôle clé. Ils ont été construits pour être hautement rétrocompatibles et pour exécuter les logiciels existants tels que les applications Cobol sur plusieurs générations de machines avec des modifications minimales. Il en résulte que des milliards de lignes de code Cobol fonctionnent depuis des décennies, pratiquement sans aucun changement.
Au fil des années, Cobol a néanmoins évolué, même si ce fut lentement. Il existe même une variante orientée objet, OO-Cobol, qui inclut le support de fonctionnalités modernes telles que Unicode, des paramètres régionaux, et des types de données plus avancées au-delà des strings (chaînes de caractères) et integers (entiers). Mais il a farouchement conservé sa rétrocompatibilité. Donc, même ces améliorations et extensions collent à cette mission visant à continuer à faire fonctionner les applications Cobol existantes. Les choix de conception retenus n’ont pas tous été populaires auprès des programmeurs Cobol. Certains ont conduit à des programmes trop complexes qui se sont révélés difficiles à comprendre ou à déboguer, et ont découragé les réécritures ou les améliorations. La commande Go To, comme son équivalent en C, a permis aux programmeurs de se déplacer librement au sein un programme et ainsi d’écrire des applications plus puissantes. Mais l’utilisation indisciplinée de Go To peut transformer un programme Cobol en noeud de références croisées difficiles à suivre.
Programmer en Cobol aujourd’hui
Cobol survit aujourd’hui dans quelques incarnations. IBM maintient activement ses propres mises en oeuvre Cobol et gère de nombreuses applications qui les exploitent. Micro Focus Cobol est une édition commerciale qui s’exécute sur Windows de Microsoft, compile les applications Cobol vers Java et .Net et se déploie même dans des environnements clouds comme Azure. On trouve aussi des mises en oeuvre open source de Cobol, telles que GnuCobol, qui est disponible gratuitement et compile vers le code machine source. Toutefois, elles peuvent ne pas disposer des fonctionnalités de déploiement ou de débogage les plus avancées des Cobol commerciaux. Bien que Cobol reste largement utilisé, les expertises approfondies sur le langage deviennent de plus en plus difficiles à trouver au fil des années.
Il en résulte que de nombreux programmeurs Cobol à la retraite sont sollicités pour faire basculer les anciennes applications dans le 21ème siècle. Souvent, ce ne sont pas les connaissances dans le langage proprement dit qui sont les plus importantes, mais la compréhension intime des environnements mainframe dans lesquels Cobol s’exécute. De nombreuses applications fonctionnent étroitement avec des technologies telles que la base de données hiérarchique IMS et le gestionnaire de transactions CICS d’IBM, qui requièrent une expertise de plus en plus rare. Ainsi, aussi vieux jeu que Cobol peut apparaître, le besoin d’expertise pour ce langage et son environnement de développement s’est accru d’année en année. Les offres d’emploi qui recherchent ce type d’expertises abondent. En mars 2020, l’état américain du New Jersey a lancé un appel d’urgence aux programmeurs Cobol pour l’aider à améliorer les systèmes de prestations chômage en pleine crise de Covid-19.
Apprendre Cobol
Compte-tenu de la demande croissante dont bénéficie Cobol, les développeurs modernes qui veulent se familiariser avec ce langage inoxydable ont plusieurs options. En Irlande, l’Université de Limerick propose un cours complet de programmation Cobol en ligne, avec l’aimable autorisation de son département des sciences informatiques et systèmes d’informations. Ce cours n’est pas aussi à jour que d’autres ressources, mais étant donné le peu de changement intervenu sur Cobol avec le temps, ce n’est pas nécessairement un défaut.
L’Open Mainframe Project propose également des ressources Cobol dont un cours de programmation complet, co-sponsorisé par IBM. Celui-ci est bien sûr plus actuel que le cours de l’Université de Limerick et il est adapté à la mise en oeuvre de Cobol sur zOS ( système d’exploitation des mainframes du constructeur) qui constitue une version largement déployée du langage. Cobol est un incontournable de l’informatique d’entreprise depuis des décennies et la demande de profils le connaissant ne cesse de croître. Si le maintien ou la modernisation des programmes Cobol vous intéresse, c’est plus que jamais le bon moment pour vous y mettre.
Article rédigé par Serdar Yegulalp, Infoworld (adapté par Maryse Gros)