Autant vous le dire de suite, je ne trouve pas beaucoup de qualités à COBOL. Ce n’est pas le langage que je préfère, loin s’en faut. C’est verbeux, inconfortable, ne supporte aucune abstraction de données et pratiquement aucune abstraction fonctionnelle.

Bref, aux standards d’aujourd’hui, COBOL n’est vraiment pas un langage formidable.

Je ne vais donc pas essayer d’y trouver des vertus imaginaires, malgré les enthousiastes de tous poils qui se pâment en disant que c’est le seul langage qui ait résisté à l’épreuve du temps, critère à peu près aussi utile pour les langages de programmation que pour les fraises et la crème chantilly.

Mais là n’est pas la question.

Quels qu’en soient les défauts ou vertus, réels pour les premiers, imaginaires pour les secondes, COBOL est essentiel à notre vie économique. C’est tout aussi vrai pour le Mainframe, sans qu’il soit toujours aisé de faire la part des choses, et de déterminer une fois pour toutes lequel du langage ou de la plateforme implique l’autre.

Nos banques, nos compagnies d’assurance, nos gouvernements, une multitude d’organisations qui régissent nos existences sont entièrement dépendantes de programmes COBOL qui ont été écrits il y a 10, 20, 30 ans et plus.

Vu de loin, la tentation de réécrire ces applications vieillissantes est compréhensible, mais c’est loin d’être aussi simple. Ces exercices de réécriture monopolisent les équipes de développement pendant des années pour le seul privilège de reproduire une fonctionnalité existante généralement adéquate. De plus, la charge de ces projets est souvent dramatiquement sous-évaluée (comment croire que l’on puisse remplacer quelque chose qui a demandé 30 années d’évolution constantes en un projet éclair sur 3 ans?) Et la bascule devient un problème à part entière. Et la migration de données aussi.

Bref, réécrire des grands systèmes d’information n’est pas une sinécure.

On peut vouloir refaire le passé, encore et encore, cela nous fait des conversations amusantes, mais cela ne fait pas avancer les choses.

Aujourd’hui, COBOL est un fait.

La stratégie de Raincode est donc centrée autour de 3 idées fortes :

1. Conserver le code COBOL en l'état car il représente la vraie valeur ajoutée du système d’information
2. Déployer le code COBOL historique dans des technologies modernes (containers, etc.) et le libérer des pesanteurs architecturales du mainframe
3. Moderniser graduellement le code existant en offrant une intégration transparente entre COBOL et des langages plus modernes.

Avec les technologies Raincode, les transactions CICS ou IMS, ainsi que les batches peuvent être déployés par des chaines d’intégration continue dans des containers, orchestrés par Kubernetes, interagir par dapr, pour une architecture et un déploiement totalement remis au goût du jour.

Nous faisons tout pour éviter la contagion : le code existant reste en COBOL, mais tout nouveau développement peut se faire dans des langages plus modernes, et interagir de manière transparente avec l’existant.

Il y a donc peu de chances que vous entamiez un nouveau développement majeur en COBOL en 2023 (même si en cela comme en toutes choses relatives à l’informatique, nous pourrions tous être étonnés). Par contre, si votre domaine de prédilection implique le gouvernement, la banque, le monde de l’assurance et même souvent l’industrie lourde, on peut parier sur le fait qu’à un moment ou à un autre, vous deviez lire et comprendre du code COBOL, le modifier, même superficiellement, et à tout le moins, en comprendre les concepts, toutes choses paradoxalement plus difficiles que de coder un système à partir d’une page blanche.

Bref, si l’informatique est votre domaine, ne pas connaître COBOL serait une erreur.