Josh Fruhlinger – 06 Décembre 2020

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)