L'informatique connait actuellement un certain nombre de mutation. Les smartphones,les tablettes le cloud, les réseaux sociaux , le NoSQL et le bigdata: des mots qui rythment les avancées technologiques. Mais on oublie vite qu'il reste des milliers de programmes COBOL comportant des millions de ligne . Sur ces programmes reposent l'ossature des traitements réalisés par les Administrations, les Banques ou les assurances. Ces applications sont un peu les oubliées de l'informatique. Elles sont portant des belles anciennes.
3 choses à savoir au sujet de ces applications:
1 ) Il ne reste que le meilleur.... et le pire
Dans la plupart des cas les applications restantes sont bien écrites , seuls les meilleurs programmes ont survécus , un peu comme une sélection naturelle. Un mauvais programme , mal écrit , sans évolution possible parce que trop complexe a déjà fait l'objet d'un portage vers des technologies plus modernes. Il reste le haut du panier des programmes COBOL. Hélas à coté de ces bons élèves se trouvent des programmes 'stratifiés'. Chaque évolution faisant l'objet d'un empilement supplémentaire.
2) Coût de maintenance.
Elles ont un coût d'entretien faible car elles sont sûres Elles ont tourné des millions de fois avec des cas de figure inimaginables. Chaque recoin de l’application a été testé en réel. Le coût de correction d'une application COBOL est moins élevé que pour une application J2E
( 5,42 $ par ligne de code Java , tandis qu'une erreur sur Cobol ne coûte que 1,26 $)
3) Lecture simplifiée de l'algorithmie des programmes COBOL
La composition d'un programme COBOL facilite sa prise en main.
Sur 100 lignes de programmes COBOL seules 20 implémentent directement la partie métier. Les autres servent à mettre le programme en relation avec son environnent (ENVIRONMENT division )
ou à définir les données à traiter (DATA division). L’algorithmie est regroupée dans très peu de ligne dans la PROCEDURE division. Ce phénomène de concentration ne se retrouve pas dans des programmes issus d'une approche objet hébergés au sein d'un framework: on assiste dans ce cas un éparpillement façon puzzle de algorithmie générale du programme.
 |
| Façon puzzle : RIP |
Les coûts.
Aussi, les coûts / risques des anciens programmes (legacy) viennent d'un part de l'infrastructure MAINFRAME à entretenir (licence et matériel) et d'autre part de la perte de compétence sur la partie métier (absence de documentation générale) .
La génération des programmeurs COBOL va arriver à l'age de la retraite.
Je recommande aux jeunes ingénieurs de passer par la case 'COBOL' pour booster leur carrière
 |
| Le retour des disques vinyles |
Alors que faire ?
A la question: pourquoi les banques continuent à utiliser leurs programmes COBOL ?
Voici une des réponses qui résume bien:
J'ai travaillé dans l'autorité de conception technique pour Natwest Bank et Royal Bank of Scotland. Ceci est un résumé de ce que le chef de la stratégie technique m'a dit une fois:
Le montant d'argent que la banque a investi en COBOL et d'autres technologies plus anciennes est massive.
Cet immense investissement au cours des décennies a abouti à un système bancaire de base qui a des capacités qui ne sont pas reproduits par les éditeurs de progiciels.
Personne ne sait vraiment comment l'énorme monticule de code spaghetti fonctionne réellement. Le projet de reverse engineering serait un projet gargantuesque.
Les projets gargantuesques ne sortent jamais
Et quel serait l'avantage - le système fonctionne comme il est.
