Depuis la création du Cobol en 1959, l’univers de la programmation informatique a fortement évolué, mais la silhouette du Cobol est toujours présente. Les technologies mainframe sont bien implantées dans les systèmes d’information d’entreprises et d’institutions, notamment au sein du milieu bancaire. D’où vient cette longévité ? Est-elle amenée à durer ? Quelques éléments de réponse à lire dans cet article.
Le Cobol au centre du Mainframe
Une question que nous devrions tous nous poser. Tous les jours.
De l’origine du Cobol…
La naissance
Nous sommes à la fin des années 50. Un certain nombre de grosses sociétés s’orientent vers une technologie moderne appelée informatique pour optimiser leur production et augmenter les profits. La technologie privilégiée à l’époque pour les besoins en informatique des grosses compagnies est le Mainframe. Ce terme, appelé en français Grands Systèmes, fait référence à une machine centrale capable d’exécuter l’ensemble des programmes et applications d’une organisation.
C’est dans ce contexte que Grace Hopper, informaticienne chevronnée alors employée chez IBM (notamment à l’origine de la conception du premier compilateur), imagine un langage informatique utilisant des mots en anglais plutôt que d’être calqué sur le langage machine. Pour COmmon Business Oriented Language, le Cobol voit le jour en 1959. Il s’agit d’un langage procédural relativement simple, et prévu, comme son nom l’indique, pour la programmation des applications de gestion.
C’est donc en toute logique que ce langage s’est imposé des années 60 à 80 dans les entreprises et administrations utilisant des ordinateurs centraux pour exécuter leurs traitements de gestion de données. IBM en fait même son langage de référence dès 1962 et développe ses machines Mainframe autour.
60 ans de pratique
Photo prise chez nos concurrents, nos dinosaures sont beaucoup plus beaux et sympathiques et nos bureaux plus lumineux.
Depuis 60 ans, on continue de l’utiliser dans les systèmes d’information de grandes entreprises et d’administrations. En pratique, on distingue 2 types d’applications : des traitements batch et transactionnel.
Batch ou TP ?
En batch, l’enchaînement des programmes écrits en Cobol est piloté par un script : le JCL, pour Job Control Language. Descendants directs de la carte perforée, ces modes de traitement permettent de gérer la mémoire au bit près. Du temps où la mémoire informatique était une denrée rare sur les machines, qu’il fallait économiser les octets et où les développeurs étaient limités à une ou deux compilation par jour, cette caractéristique était évidemment indispensable. Et cela en fait encore sa force aujourd’hui, les traitements peuvent toujours être optimisés au bit près. Ce qui est primordial lorsque des dizaines de traitements doivent s’enchaîner en un temps minimal pour ne pas perturber le bon fonctionnement du SI.
Le second terme (TP pour Transaction Processing) fait référence à des traitements en temps réel. Via une interface (un terminal), l’utilisateur fait défiler des écrans dont les données qui s’affichent proviennent de bases de données accédées par des programmes Cobol. Un programme ou ensemble de programmes est appelé via une transaction, d’où le nom transactionnel, pour lire, insérer, mettre à jour, les données en base, en fonction des actions de l’utilisateur.
Aujourd’hui les interfaces se sont modernisées, et si les écrans ne sont plus codés en Cobol, la partie métier l’est toujours.
Un système centralisé
Pour accéder au Mainframe, il faut passer par une interface, qui à l’époque n’est autre qu’un terminal. Le plus connu, développé par IBM en 1972, portait le nom de terminal 3270. On utilise aujourd’hui des émulateurs sur nos PC, mais ce nom est encore employé pour désigner l’interface de connexion au Mainframe. On a alors accès à un ensemble d’outils pour naviguer sur le Mainframe, accéder aux sources, coder, accéder aux bases de données, etc…
Le problème principal d’avoir tout centralisé sur une machine est que tout le monde y a accès en même temps. Il est donc facile de modifier une base de données de manière irréversible, ou encore d’écraser les lignes de code du collègue dans un programme avec ses propres modifications.
… Au Cobol moderne
Associer les mots Cobol et “moderne” peut faire sourire. Mais il faut savoir qu’à l’heure actuelle, le Cobol représente des milliards de lignes de code. Annoncée depuis 30 ans, sa mort n’est toujours pas intervenue. Les entreprises continuent de l’utiliser, ce qui implique une modernisation permanente du langage. D’un point de vue purement technique, une version récente vient de voir le jour avec Cobol V6. Rien de révolutionnaire dans la manière de coder, mais les exécutables générés lors de la compilation sont optimisés et permettent d’exécuter les traitements plus rapidement et efficacement.
Vers la fin des écrans 3270
Longtemps associés au Cobol, les écrans 3270, ces écrans noirs avec une police vert fluo, tendent à disparaître. Utilisés aussi bien pour développer que pour les applications transactionnelles, ces outils pour lesquels l’utilisation de la souris est bannie, sont remplacés par des outils plus ergonomiques.
Les outils de développement sont maintenant plus modernes. Les puristes auraient tendance à râler, mais l’utilisation de la souris est un vrai gain de temps et de confort dans les développements Cobol. Il est également possible de coupler l’environnement de développement à un outil de gestion des sources, tels que Git ou RTC, pour réduire les risques de versioning.
Les applications développées pour des écrans 3270 tendent à disparaître pour être remplacées par une interface plus moderne. Les programmes Cobol subsistent pour dialoguer avec les bases de données, mais la couche front-end est désormais codée avec des technologies récentes pour offrir une expérience utilisateur à la hauteur.
Aujourd’hui peu enseigné dans les écoles, le Cobol attire peu, voire pas du tout, de nouveaux développeurs. Avec toute une génération de développeurs Cobol sur le point de partir à la retraite, il y a un réel enjeu pour les remplacer. La question se pose donc : faut-il migrer toutes ces lignes de code vers une technologie plus moderne ou maintenir les programmes Cobol ?
Migration vs maintenance
Les vrais savent
Quelles alternatives ?
Des alternatives ont déjà été envisagées pour remplacer les traitements Cobol. Comme il s’agit principalement de dialoguer avec des bases de données et de traiter des fichiers de données de plusieurs millions de lignes, des solutions techniques sont déjà en place. Le passage vers des langages objet, plus modernes et attrayants tels que Java a été envisagé. IBM a même été jusqu’à créer le Cobol Orienté Objet dans les années 2000. Les solutions existent donc, il ne reste plus qu’à réécrire les traitements. Et cela représente un chantier d’une ampleur démesurée.
Des milliards de lignes à réécrire
On estime aujourd’hui le nombre de lignes écrites en Cobol et exécutées chaque année à quelque 800 milliards. Selon une étude récente, ce chiffre est plus élevé que les prédictions et le volume aurait tendance à croître. Ceci est dû notamment au fait que de nouveaux programmes Cobol voient le jour en permanence, en quantité supérieure à ce qui avait été envisagé. Reprendre ces milliards de lignes prendrait un temps gigantesque et serait très onéreux.
Pour la partie transactionnelle en revanche, c’est un peu différent. Les applications, à l’origine sur des écrans 3270, sont reprises pour être disponibles via des interfaces de type web plus modernes. Ce qui implique de créer toute la partie front-end. Se pose alors la question du back-end, qui à ce stade pourrait être migré vers d’autres langages. Mais cela impliquerait de basculer tout ou partie des bases de données dans un environnement récent. Et bien sûr de reprendre toute la partie métier sur des applications souvent critiques. Si les impacts sont mineurs, les applications peuvent donc être réécrites de A à Z dans une autre technologie. Mais bien souvent ce n’est pas le cas, les programmes Cobol demeurent indispensables.
Des années de travail
Les applications développées en Cobol sont souvent critiques. Utilisé beaucoup dans les milieux des banques, des assurances, ou encore certains ministères, il faut être extrêmement prudent en cas de réécriture. Donc en plus de la charge de coding, qui est déjà très conséquente, il faut prendre en compte ce caractère critique, ce qui fait augmenter d’autant plus la charge de travail.
Certaines institutions ont évalué cette charge pour réécrire l’ensemble de leurs applications qui tournent en Cobol. En première estimation, on arrivait à une dizaine d’années en moyenne. Quand on connaît les volumes de travail dans les services informatiques de ces grandes entreprises, aucun chef de projet n’a envie d’avoir à placer ces travaux dans son plan de charge… Ou de facturer une telle note à un prestataire. La maintenance semble être la solution la moins coûteuse et privilégiée.
Quel avenir pour le cobol ?
« y’en a qu’ont essayé ils ont eu des problèmes »
Les entreprises à l’heure de la modernisation du Cobol
À l’heure actuelle, les signaux sont plutôt en faveur d’un maintien du Cobol dans les entreprises. Le défi est donc de recruter et former une nouvelle génération de développeurs. Or, ce n’est pas la filière privilégiée. Pour attirer de nouveaux développeurs, une modernisation s’impose.
Solution IBM
Les entreprises mettent en place des solutions pour permettre aux développeurs de coder dans un environnement plus moderne. Avec la volonté notamment de supprimer les écrans 3270, IBM en tête, qui a sorti il y a quelques années sa solution RDz (pour Rational Development for Z systems). Basée sur Oracle, elle offre une interface bien plus sympathique pour le développeur, qui a la possibilité d’utiliser la souris, de scroller, d’utiliser les raccourcis clavier, etc… une révolution !
Des solutions en interne
Des solutions en interne voient également le jour. Chez i-BP notamment avec l’arrivée imminente de l’Usine de développement Cobol. Le développeur pourra s’appuyer sur Visual Studio Code pour écrire ses programmes, GitLab pour gérer le partage des sources, SonarQube pour les contrôles de qualité de code,… Autant d’outils qui vont permettre aux développeurs Cobol de travailler dans le même environnement que des langages récents.
Vers un choix durable du Cobol
L’arrêt de PACBASE
Un autre signal fort est le désengagement des entreprises de PACBASE, un outil de génération automatique de Cobol, pour privilégier l’écriture en Cobol natif. Développé dans les années 90 pour générer automatiquement des lignes de code en Cobol à partir d’instructions simples, PACBASE a été beaucoup utilisé pour développer. Mais le code généré est peu lisible et compliqué à maintenir. Beaucoup d’entreprises qui ont utilisé cet outil doivent réécrire les programmes générés. Plutôt que de passer à un autre langage de programmation, le choix a été fait de réécrire ces programmes en Cobol “propre”, dans le but de pouvoir les maintenir encore quelques années.
Un choix hybride
Les entreprises s’orientent vers une solution hybride plutôt qu’un remplacement total du Cobol. Pour proposer aux utilisateurs une interface moderne, il est indispensable de passer par des langages récents. Et pour le back-end, l’enjeu est de mesurer l’impact d’une réécriture. Et bien souvent, le choix est fait de maintenir les programmes Cobol.
Cobol des PROFILS recherchés
« Cobol is the new black, bientôt sur vos écrans »
Former, recruter
Le défi est donc de recruter un panel de développeurs Cobol, car il n’est pas près d’être mis à la corbeille. En plus de l’enjeu technologique, il existe un enjeu business. Les centaines de milliards de lignes à écrire ou maintenir représentent un marché conséquent. En interne, ou via des organismes externes, des offres de formation aux technologies Mainframe fleurissent. Le Cobol recommence à être enseigné dans les écoles de développeurs, mais il est rarement le choix n°1 en sortie d’école. Pour pouvoir attirer de nouveaux développeurs vers le Mainframe, l’accent est mis sur la formation de profils issus d’autres filières, notamment scientifiques.
Une rampe de lancement dans les métiers IT
Le Cobol est un langage relativement simple et rapide à apprendre. Mais les traitements pour lesquels il est utilisé sont souvent complexes et nécessitent une analyse poussée pour leurs maintenances ou leurs mises en place.
C’est une excellente rampe de lancement dans les métiers des technologies de l’information, car il est possible de combiner rapidement avec d’autres compétences, aussi bien techniques que fonctionnelles. Avec le choix de la solution hybride, le développeur peut rapidement associer son savoir-faire en Cobol à des langages récents. D’un point de vue fonctionnel, les traitements complexes dans lesquels s’insèrent les programmes Cobol offrent aux développeurs la possibilité de se plonger dans des sujets d’analyse poussés et de développer des compétences dans ce domaine. Ces profils se font rares et sont d’autant plus recherchés sur le marché.
En conclusion, que ce soit pour des raisons économiques ou d’efficacité, le Cobol reste indispensable dans bon nombre d’entreprises et d’administrations. Sa mort n’est plus annoncée, il retrouve même une nouvelle jeunesse en se modernisant et a encore de beaux jours devant lui.