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, Python, Ruby, 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.
[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.
