mardi 10 décembre 2013

Le Cobol n’est toujours pas mort

A priori Cobol est un langage dépassé, tombé dans les oubliettes de l’histoire informatique. D’ailleurs souvent on dit que l’acronyme ne veut pas dire COmmon Business Oriented Language mais Completely Obsolet Business Oriented Language. Mais est-ce si sûr ? J’ai écrit sur ce blog un court message le 19 décembre 2011 titré : « Quel avenir pour le Cobol ? ». C’était il y a deux ans ! Or aujourd’hui encore c’est un des textes les plus consultés du blog. Il se classe en second après celui sur : « La gestion de projet : peut mieux faire ». Ce texte représente 12% des consultations parmi la vingtaine de messages se trouvant sur le blog. L’analyse montre qu’une partie de ces lecteurs viennent par Google avec la recherche « avenir du cobol » ou « Cobol avenir ». Dans ces conditions on peut s’interroger et se demander si effectivement Cobol aurait un avenir ? 
Pourtant ce n’est pas un sujet très « sexy ». Il existe sur ce blog de nombreux sujets plus porteur que le Cobol comme par exemple : le cloud, le Big Data, Java, les tablettes, la 4G, le FTTH (Fiber To The Home), …. Il existe des thèmes nettement plus stratégiques que le Cobol comme les mesures nécessaires pour réussir à développer l’économie numérique en France et en Europe ou bien la recherche des moyens pour mieux financer les entreprises du secteur informatique et numérique. Mais, ce sujet apparait en tête des classements car les professionnels de l’informatique se posent de nombreuses questions depuis des années et ils ont du mal à trouver des réponses satisfaisantes.

Un silence étourdissant

En effet si on effectue quelques recherches sur Google ([1]) on s’aperçoit que l’avenir du Cobol est un thème traité de manière peu fréquente et lorsque ce sujet est évoqué c’est pour faire des offres d’apprentissage au Cobol. C’est intéressant mais peu de personnes s’intéressent à son avenir. De même vous pouvez aussi rechercher dans la presse informatique on line ou sur papier, et vous constaterez que c’est un sujet qui est rarement abordé. Il y a une sorte de « silence radio » sur le sujet, seul exception, de temps à autre le Monde Informatique publie un article sur le sujet, repris de Computerworld, ou d’un communiqué de presse de Micro-Focus. Mais aucune « autorité » ne s’exprime sur le cœur du sujet. Tout se passe comme si Cobol était mort. Or il est bien vivant.
Les chiffres sont là. On estime le total des lignes de codes développées par les utilisateurs dans tous les langages possibles est égal à 310 milliards de lignes. Or sur ce total 220 milliards de lignes, soit 71 % du total, sont écrites en Cobol ([2]). Plus étonnant encore la taille de ce parc augmente de 5 milliards de lignes par an. C’est un investissement considérable effectués par toutes les entreprises et les administrations. Faisons un rapide calcul : si une ligne de code coûte 15 dollars cela fait un investissement mondial de 3.300 milliards de dollars (Selon différentes études il est compris évalué entre 1.500 et 5.500 milliards de dollars). Il est difficile qu’on puisse imaginer de passer par Pertes et Profit une somme pareille. Il est donc nécessaire d’admettre que la communauté informatique va vivre avec pendant encore un certain nombre d’années. 
L’idée d’une disparition prochaine de ce langage vieux de plus de 50 ans ([3]) est en fait une illusion. Il va, probablement, continuer de se développer mais curieusement on l’ignore. Ceci explique en grande partie l’attitude de nombreux professionnels et donc cherche des informations sur ce sujet.

La concurrence était rude

Malgré les annonces récurrentes de la prochaine disparition du Cobol il est toujours là. Il manifeste une résistance remarquable. En effet il a survécu à tous les langages partis à l’assaut de sa domination et notamment à quatre approches qui ont été présentés comme des révolutions technologiques et qui auraient normalement dues le tuer. 
La première fut le Gap (générateur automatique de programmes), appelé en anglais le RPG (Report Program Generator). C’est un langage beaucoup plus simple que le Cobol qui a l’avantage d’être assez proche des opérations que faisaient jadis les mécanographes avec des cartes perforées, des trieuses et des tabulatrices. IBM en a fait la promotion sur tous ces matériels bas de gamme destinées aux PME : 1130, série 3, IBM 32 et 34, AS/400,… Il devait rendre Cobol inutile. Aujourd’hui les programmes écrits en Gap ont quasiment disparu. 
La seconde est venue du PL/1 développé dans les années 70 par IBM. Il devait remplacer le Cobol car il était mieux structuré, était capable de traiter aussi bien des problèmes de gestion que du calcul scientifique, disposait de pointeurs, … En somme le meilleur des deux mondes. Certaines entreprises fortement conseillées par IBM se sont lancées dans de colossales opérations de réécritures de l’ensemble de leurs programmes en pure perte. Aujourd’hui qui se souvient de PL/1 ? 
La troisième révolution fut celle du Pascal. Qui se souvient que Pascal était un langage informatique ([6]) ? Pourtant dans les années 80 c’était la coqueluche des programmeurs. Un compilateur développé UCSD générait un code intermédiaire (le p-code) qui était ensuite interprété par une machine virtuel. Il a permis de résoudre l’éternel problème de la portabilité : « Write once, run anyware ». Une partie du système d’exploitation du Macintosh ou la première version de Photoshop ont été écrit en Pascal. Il a ensuite été remplacé par le Turbo-Pascal développé par Borland, puis il a sombré dans l’oubli, dépassé par le C. 
Le 4ème candidat à la succession de Cobol a été le Basic. Il aurait pu l’emporter si Microsoft ne s’était pas remarquablement tiré une balle dans le pied. Au début de la micro-informatique, en 1977, Bill Gates et Paul Allen avaient eu le génie de développer un interpréteur Basic qui fonctionnait avec seulement 4 kilo-octets de mémoire centrale. Il a été livré en standard avec tous les premiers micro-ordinateurs. Ensuite une longue série de Basic ont été développés dont Quik Basic, Visual Basic,… Des millions de programmeurs dans le monde ne travaillaient qu’en Basic qui comme son nom l’indiquait était simple et ne nécessitait pas un long apprentissage. Mais Microsoft a eu la curieuse idée d’intégrer Basic dans son architecture .NET et de mettre de l’objet dans Basic pour finalement obtenir Visual Basic.NET. C’était très bien sauf que les anciens programmes étaient incompatibles avec les nouveaux interpréteurs. Il fallait tout réécrire. Plus grave : les programmeurs Basic n’avaient pas le niveau de compétences nécessaires pour utiliser cette nouvelle version du Basic. Ils l’ont abandonnés au profit de langages plus simples comme PHP.
Ceci explique que Cobol soit toujours là.

Les charmes de Java

Plus récemment un cinquième concurrent de Cobol est apparu. Il porte le nom d’une île : Java. La création de ce langage est lié à la difficulté d’utiliser le C et sa version orientée objet C++. Ces langages, proches des macros de l’assembleur, demandent des programmeurs très compétents et ayant une grande expérience. Leur succès est dû à leur remarquable portabilité.
Java est à l’origine un sous-ensemble de C++. Mais au fil du temps de nombreuses fonctions ont été ajoutés. Elles ont rendu le développement à l’aide de ce langage plus complexe et il est devenu délicat à mettre en œuvre. Il a connu une rapide diffusion tant sur les postes de travail, grâce aux applets, que sur les serveurs, avec les servlets. Mais sur le poste de travail il est concurrencé par d’autres solutions comme Flash d’Adobe, GWT (Google Web Toolkit), Javascript, PHP,… et bientôt par HTML5. L’utilisation de Java sur le serveur s’est traduit pas le développement du framework JEE (ancien J2EE : Java 2 Entreprise Edition) avec des produits comme Weblogic, WebSphere Application Serve, JBoss,… Mais dans le cas de traitements volumineux on bute sur des problèmes de performance.
Un des facteur clé du succès de Java est la JVM, « Java Virtual Machine » qui est un interpréteur de code Java. Elle fonctionne dans tous les environnement : Windows, MacOS, AIX, z/OS, MVS, OS/400, Linux, Unix, Android, Solaris, HP-UX, …. Elle fonctionne sur des processeurs temps réels notamment les systèmes à base de processeurs ARM, Power, Sparc,… Elle est intégrée dans des applications ou dans des ERP comme SAP avec NetWeaver. Cette universalité est permise par le byte-code. Le code source écrit en Java est dans un premier temps compilé pour produire un code intermédiaire proche du langage machine qui est ensuite interprété par la JVM. Notons que le code source n’est pas forcement du code écrit en Java mais peut utiliser un autre langage. 
Ainsi Java peut fonctionner dans tous les environnements : de la télécommande de téléviseur au mainframe. Du code développé sur une machine donné peut être repris sur n’importe quel autre système. C’est la grande idée du : « Write once, run everywhere ». La réalité est plus nuancée. C’est plutôt : « Write once, debug everywhere ». La portabilité n’est jamais parfaite et nécessite l’intervention régulière des développeurs. 
Java a quatre limites :
-   C’est fait un langage semi-compilé. Le code du byte-code est interprété au moment de l’exécution. Ceci fait qu’il s’exécute relativement plus lentement que du code compilé.
-      Les performances des applications sont médiocres à cause d’une gestion mémoire médiocre, des accès disques non-optimisés et l’interprétation du code,
-      Les coûts de développement des applications sont élevés car il est nécessaire de faire appel à des programmeurs de niveau Bac + 5 et la mise au point des programmes est longue,
-      La maintenance des applications écrites en Java est délicate. Le code est difficile à lire ceci fait qu’il est difficile de repérer l’endroit où il est nécessaire d’intervenir. Cast Software estime qu’il est 4 fois plus coûteux de maintenir du code Java que du Cobol "Erreurs de programmation : Java coûte plus cher que Cobol".
Dans ces conditions il n’est pas raisonnable d’envisager à court terme de remplacer les milliards de lignes de code écrit en Cobol par du Java. Les entreprises qui ont cherché à convertir leurs applications qui assurent le cœur de métier en Java ont eu des déceptions (voir « Les banques seront fidèles à Cobol plusperformant que Java » dans le Monde Informatique. Il existe maintenant un certain recul sur ce sujet. Afin d’en avoir le cœur net il serait souhaitable d’en profiter pour effectuer un certain nombre d’études quantitatives afin de mesurer les coûts de développement, de maintenance et d’exploitation de ces applications en Cobol et en Java. L’absence d’étude de ce type est un signe qui ne trompe pas.

Un choix stratégique

Cela ne veut pas dire que dans les années à venir on va revenir massivement au Cobol. Il y a des situations où il s’impose et d’autres cas où il existe de meilleures solutions. Il y a deux domaines où il s’impose et reste l’approche la plus efficace :
-      L’interface avec les bases de données. Les applications de gestion reposent sur la maîtrise de flux importants de données avec des saisies, des contrôles, des interfaces, des éditions,… Cobol effectuent ces traitements dans de bonnes conditions.
-      Les traitements batchs. Même si de plus en plus d’opérations se font en transactionnel une partie des opérations se font à l’aide de traitements périodiques. Ce sont, par exemple la paie, l’arrêté comptable, lafacturation,… Cobol effectue ces opérations de manière très efficace.
Dans ces deux cas il n’y pas de doute. Ecrire ces traitements en Java, en C ou en C++ n’est pas la solution la plus efficace.
Par contre il y a deux types d’application qui méritent réflexion :
-      Le transactionnel. Un nombre croissant d’opérations se font sous forme de requêtes envoyées à un site central suivi d’une réception quasi-instantanée de la réponse. C’est le domaine traditionnel du moniteur CICS qui est un système particulièrement efficace. Pour IBM, c’est une véritable rente cas sa solution est efficace. Elle est coûteuse car les redevances des logiciels sont chères et elle oblige de recourir à un mainframe qui est lui aussi coûteux. La situation est d’autant plus délicate qu’il n’y pas de solution concurrente sauf Tuxedo qui existe sur les machines fonctionnant sous Unix. Mais c’est un produit vieillissant. A l’origine il a été développé par les Bell Lab. Ensuite il a été acheté par Novell puis a été repris par BEA qui à son tour a été racheté par Oracle qui l’a finalement intégré dans son système Fusion Middleware. Manifestement Oracle ne croit plus au produit. Microsoft avait aussi essayé de proposer un moniteur transactionnel : MTS (Microsoft Transaction Server). Qui s’en souvient et surtout qui s’en sert ? En fait le marché pousse à utiliser des serveurs d’application comme Websphere, Weblogic, JBoss, .Net, Zend (PHP), … Ces systèmes sont intéressants mais posent encore de graves problèmes de performance.
-      Le poste client : Windows ou Web. De plus en plus de traitements se font sur le poste de travail notamment la saisie des données mais aussi la consultation des bases de données. Il existe une forte pression pour faire fonctionner l’application à l’intérieur du navigateur à l’aide de pages contenant du code JavaScript, PHP, HTML5,… Mais est-ce la bonne solution ? Comment sécuriser dans de bonnes conditions les transactions de saisie ?
Une des solutions consiste à développer sur le poste de travail et sur le serveur des programmes écrits en Cobol qui échangent entre eux des données à l’aide d’un protocole rapide et fiable. Or justement le compilateur de Micro Focus génère du byte-code qui peut s’exécuter sur les JVM du poste client ainsi que sur celle du serveur. Il est ainsi possible de faire fonctionner des programmes Cobol sur des micro-ordinateurs, des serveurs RISC ou des mainframes. 
De même IBM continu de miser sur le Cobol et propose à ses clients du monde des mainframes le compilateur « Cobol IBM for z/OS » qui est interopérable avec Java et CICS. De son côté Fujistu ([4]) propose des outils de migration de code Cobol vers des systèmes sous Linux. Mais est-ce que l’objectif est de faire migrer toutes les applications de gestion sur des serveurs à base de processeur Intel ? Il est certain qu’à puissance équivalente le coût des mainframes est nettement supérieur à celui des serveurs à base de PC. Mais les systèmes centraux ont l’avantage de la redondance, de la sécurité et de la fiabilité. Si on s’efforce de bâtir des architectures à base de serveurs-PC ayant des niveaux de qualité et de sécurité équivalents l’écart est moins net. 

Y-a-t’il une autre solution possible ?

Dans ces conditions on peut s’interroger sur la nécessité de quitter le Cobol et de trouver un langage plus performant et plus efficace. Il faut d’abord s’interroger sur l’échec ou le succès des cinq langages analysés ci-dessus : GAP, PL/1, Pascal, Basic et Java. Les trois premiers sont probablement définitivement mis au musée de l’informatique et ont peu de chance de ressusciter. Le Basic est victime de la politique confuse de Microsoft. A force d’essayer d’en faire un langage capable de tout faire il est devenu complexe et peu utilisable. Seul reste Java. 
Mais il faut se rappeler que l’informatique ne manque jamais de solutions mais peu perdurent. On constate que beaucoup de produits et de logiciels sont lancées mais peu réussissent et encore moins survivent à long terme. L’évolution des technologies informatiques a été caractérisée par l’apparition de centaines de produits, de logiciels, de protocoles,… qui ont aujourd’hui complètement disparus. Le cimetière des solutions informatiques est immense. En matière de langage qui se souvent de l’APL, de l’Algol, de Forth, de Perl, de Simula, de BPCL (l’ancêtre de C), de Logo, de Smaltalk, d’Eiffel, …. Tous ces langages ont eu leur heure de gloire avant de disparaître.
Un grand nombre de responsables pensent qu’il faut plutôt miser sur les ERP pour traiter la plupart des applications de gestion. Dans ce cas le choix du langage n’est plus un problème pour le client (par contre cela reste une préoccupation pour l’éditeur). Cela n’empêche que de temps à autre on constate que les paramétrages prévus ne permettent pas d’obtenir ce que l’utilisateur demande. Il est alors nécessaire de développer des programmes. Sous SAP il existe pour cela un langage spécifique : Abap. C’est une variante de Cobol. Depuis quelques années SAP a intégré à l’ensemble de ses outils de développement dans un système appelé NetWeaver dont le cœur est Java. De même Oracle, c’est aussi Java. D’abord par ce qu’elle possède depuis le rachat de Sun les droits sur le langage mais par ce qu’elle dispose aussi d’un catalogue impressionnant de logiciels intégrés avec Oracle E-Buisness Suite mais aussi PeopleSoft, JD Edwards, Siebel, Oracle Fusion,… Tous ces systèmes sont orientés Java.
Dans ces conditions certains responsables essaient de faire des mariages audacieux en bâtissant des « plateformes » avec un langage, Java, un serveur d’application, une base de données, différents progiciels et un EAI. Si l’ensemble de ces progiciels viennent d’un seul fournisseur les risques sont limités mais on a alors la crainte de devoir adopter des solutions qui ne sont pas toujours performantes. Quant à l’idée de prendre des produits venant de différents fournisseurs elle se heurte à de très nets problèmes d’intégration et donc d’efficacité.

Le problème de la formation au Cobol

Dans ces conditions l’idée de voir rapidement disparaître le Cobol ne semble pas très réaliste. Il est là et il va continuer de se développer. Il va donc falloir vivre avec pendant de nombreuses années. Mais y aura-t’il à l’avenir assez de cobolistes pour faire face à cette charge de travail d’autant plus que certains sont âgés et vont bientôt partir à la retraite. Il faut donc envisager de les remplacer. Mais il y a un petit problème : où se forme les nouveaux cobolistes ? 
Une étude récentede Micro Focus montre qu’il existe peu de formation à Cobol. Sur 235 formations supérieures à l’informatique recensées en France seulement quatre forment leurs étudiants à Cobol. Ce sont tous des IUT. Ce sont ceux de Paris V (Paris Descartes, avenue de Versailles), de Limoges, de Nancy et de Rodez. Le reste des étudiants est formé à Java et à toutes sortes de langages comme Caml, Ada, Goovy, PythonRuby, Delphi (avec Pascal Objet), …. ([5]). 
Cette indifférence au langage le plus répandu dans le monde n’est pas propre à la France. C’est un phénomène international. Dans une autre étude de Micro-Focus portant sur 119 universités situés dans les cinq continents ayant des enseignements informatiques seules 32 forment au Cobol, soit 27 %. C’est mieux que les 2,3 % de la France, mais cela montre le degré de déconnexion des universités et des écoles des besoins du marché. Bien entendu il est toujours possible d’apprendre seul le Cobol. Mais est-ce vraiment efficace ?

Voir sur le même sujet, sur ce blog :"Quel avenir pour le Cobol ?", paru le lundi 19 décembre 2011.



[1] - Cobol : 6 760 000 résultats. Recherches associées à Cobol : cours cobol, apprendre cobol, compilateur cobol, emploi cobol, tutoriel cobol, cobol pdf, inspect cobol et open cobol. 
[2] - Gary Barnett, directeur de la recherche chez Ovum estime que 90 % de toutes les transactions financière et 75 % de l’ensemble des transactions dans le monde allant du retrait d’argent à un DAB, à la réservation d’un billet d’avion ou à la saisie d’une facture se font à l’aide de programmes écrits en Cobol. Il évalue le nombre des transactions quotidiennes supportées par un programme écrit en Cobol à 30 milliards.
[3] - Cobol  a été créée en 1959. La dernière version date de 2002 et elle orientée objet.
[4] - Pour suivre l’actualité de Cobol voir le site : Cobol Center qui n’est pas très à jour mais a le mérite d’exister.

1 commentaire:

Pierre Fischof. a dit…

Ce rapport (ancien de la fin de 2013) me semble toutefois toujours brosser un aperçu très lucide et objectif de la situation réelle du langage Cobol dans les entreprises et organisation du monde, en s'appuyant sur des source fiables. A l'opposé de discours toujours plus en vogue, peut-être guidés par des considérations marketing, apparemment à des années-lumières de la situation la plus générale de terrain.
L'alternative potentielle des ERP, dans une partie des cas, y est également présentée.
Il reste que l'aperçu, dans ce rapport, des écarts de coûts de maintenance entre le langage Cobol et différents autres langages pourra sembler assez "renversant" pour certains observateurs...
Cela semble, néanmoins, me semble-t-il, la métrique la plus importante à prendre en compte avant décisions, si l'on souhaite assurer la bonne continuité et l'évolution possible à moyen et long terme des patrimoines numériques et si l'on veut des systèmes d'information robustes et durables.