Ah l’innocence de la jeunesse… Régulièrement, un petit nouveau débarque au bureau et est stupéfait qu’il y ait encore des programmes en COBOL dans les entreprises. COBOL, ce n’est un modèle de korrigan, ni un lanceur de disque moins 10, c’est un langage informatique. Plutôt ancien. Mais encore utilisé dans beaucoup de grosses entreprises.
Pour lui, c’est une technologie obsolète, il n’en a jamais entendu parler à l’école. Et pour anticiper la future absence de ressources pour maintenir les systèmes, les entreprises devraient tout migrer sous des langages plus modernes, comme Java Websphere ou autre.
On lui explique que la plupart des grandes entreprises, banques, assurances, commerces, qui ont des millions de clients, ont besoin de systèmes fiables, ultra-rapides, et peu gourmands en espace (de données). Que ces grandes boîtes n’ont pas pour politique de balancer l’argent par les fenêtres. La refonte d’un système informatique qui a 40 ans de « vécu », ça se chiffre en centaines de milliers de jours/hommes, on ne s’amuse pas à faire ça sans une bonne raison.
Sans doute, certaines boîtes mal gérées ont été embobinées par des discours de commerciaux ou de petits jeunes frais émoulus de l’école tenant le même discours que lui.
J’ai assisté à la migration d’un demi SI (système d’information) du « grand système » (assimilé COBOL) vers un progiciel en Java. La première fois qu’ils ont fait un test de charge en conditions réelles du batch quotidien (le traitement qui tourne le soir pour mettre à jour et recalculer tout ce qui n’a pas pu l’être en temps réel, intégrer les fichiers venant des autres organismes, banques, état, Bourse, concurrents…), avec la moitié des contrats, le « batch de nuit » a duré 28 heures. Cad qu’il est censé tourner une fois par jour, entre la fermeture des agences le soir et leur réouverture le lendemain. Sinon les applications ne peuvent pas se rouvrir le lendemain matin.
Vous voyez le problème, du coup, s’il dure 28 heures? A moins de migrer la société (et les clients) sur une planète où la nuit dure 30 heures, ou au cercle polaire…
Bon, ils ont tout remis à plat pour voir où ça prenait du temps et optimiser, ajouter de la puissance, et au final il ne prenait plus « que » quelques heures. Mais quand même nettement plus que son prédécesseur.
C’est comme ça : plus tu rajoutes de couches et de complexité à un système et à un langage, plus il est lent. Or tous les langages récents sont des langages interprétés. Toutes les applications mainframe en temps réel que j’ai vues remplacées par des versions « nouvelles technologies », avec de jolies interfaces colorées en dégradés qui bougent, des menus déroulants, avaient des temps de réponse plus longs. Parce qu’il faut calculer le dégradé. Alors qu’en fait, OSEF du dégradé, l’important c’est que ton contrat te rapporte de l’argent. Si tu voulais faire du joli, mon gars, fallait t’orienter vers la création graphique, pas vers l’informatique bancaire.
Sans parler du fait que la « migration » se fait au chausse-pied, car un progiciel créé ailleurs a du mal à gérer les spécificités maison engendrées par 40 ans de développement en interne, et de « Oui mais les agence Bidule elles veulent ça », « On a vendu Truc au client il y a un an, on peut pas lui dire qu’on y arrive plus techniquement », etc… Sans parler du fait qu’il y a des réglementations. C’est interdit par la loi d’obliger des clients à résilier des contrats sous prétexte que ton nouveau système informatique ne sait pas les gérer, alors que l’ancien pouvait. Tant pis pour ta goule.
Le plus drôle, c’est que Nouveaucollègue essaie de nous convaincre en expliquant que en Java, comme c’est modulaire, tu n’as pas besoin de tout recoder à chaque fois, « il suffit » de trouver le bon module dans la bonne bibliothèque, qui fait ce dont tu as besoin.
Ouais. C’est sans doute utile si tu veux coder les interfaces graphiques, avec des scrolls horizontaux, des tableaux avec les entêtes en gras, et autres fioritures, et des trucs applicables au Cloud machinbidule.
Mais pour coder des calculs d’arrêtés comptables, de la gestion de stock de marchandise, on n’a pas besoin de cloud et de zigouigouis graphiques compatibles multi-plateformes. On a juste besoin de fonctions d’addition, multiplication, lecture-écriture… Toutes choses qui existent quasiment depuis Colossus. Pas le super-héros membre des X-Men, l’ancêtre des ordinateurs.
Au fil du temps, on a fignolé, complété. Mais se contenter d’ajouter une interface web pour faire plaisir au commercial, c’est plus sûr et moins coûteux que de tout refaire. L’important c’est le moteur, tu ne troques pas une Mercedes contre une 2CV sous prétexte que tu n’aimes pas la couleur. Tu fais repeindre la Mercedes.
Accessoirement, j’ai aussi codé dans des langages « orientés objet ». On passe parfois plus de temps à chercher le bon composant dans la bonne bibliothèque, qui fait réellement exactement ce dont on a besoin, et non, comme on s’en rend compte après quelques tests, faute de doc suffisamment détaillée, « ah mais non, pourquoi il gère ça comme ça, moi je voulais faire comme ci », que si on l’avait codé soi-même.
Autre argument énoncé par Nouveaucollègue ainsi que dans les commentaires de cet article : « Les banques devraient investir pour changer de technologie parce que plus personne ne saura bientôt coder en COBOL ». C’est « charmant », cette tendance des jeunes à croire qu’eux seuls existent et peuvent travailler… Mais il n’y a pas que les pré-retraités qui ont fait du Cobol.
Pour gérer le bug de l’an 2000 et le passage à l’euro, des dizaines de milliers de jeunes diplômés ont été embauchés et formés en quelques mois, voire quelques semaines, pour analyser les programmes et corriger les programmes existant. Pour créer une application entière de A à Z, ou coder proprement et optimisé, ça nécessite plus de métier. Mais pour faire de la maintenance de base sur du Cobol, quelques semaines de formation, voire quelques jours si on sait déjà coder, suffisent…
Aujourd’hui, 15 ans après, ils ont entre 35 et 45 ans, et au moins 20 ans de labeur devant eux avant de pouvoir prétendre à la retraite. Les banques ont le temps de voir venir. Vous me direz qu’ils ne seront pas développeurs toute leur vie, mais il y a des chances que si, vu qu’à l’heure actuelle la tendance est plutôt à recruter pour les fonctions de management des gens qui sortent de l’école avec le diplôme kivabien (même s’ils ne connaissent rien au métier), plutôt qu’à faire progresser les gens en interne.
Coder du COBOL permettra peut-être à certains de ne pas être jetés à 55 ans au motif qu’il faut dégraisser pour faire plaisir aux actionnaires.
Au pire, il suffira de former de nouvelles personnes. A partir du moment où on a un esprit logique, c’est possible d’apprendre. A l’heure actuelle d’ailleurs, on forme encore des gens au COBOL… En Inde, par exemple. Ce n’est peut-être pas un langage glamour, mais ça fait le job.
Fan Actuel 
Très bon article je ne pourrais dire mieux que ce que tu as cité dans ton article j’ajouterais juste ces quelques points sur mon point de vue:
– Lorsque j’ai fait ma formation informatique début 90 les profs à l’école prévoyait déja soi disant la fin du COBOL remplacé par les langages à l’époque orientés Objets C, C++, & co… on en voit la preuve aujourd’hui.
– Jai pourtant eu une partie de mon cursus fait sur du COBOL et cela ma bien servi dans mon cursus professionnel même si cela ne fait pas partie de mes activités de base plus sur du prog orienté objet.
Sur le fameux passage an 2000 tout comme toi je me souviens des boites qui sont allé chercher les Analystes programmeurs ( ah terme dépassé aujourd’hui qui semble même une insulte au plus djeunz qui débarquent) qui étaient bien content qu’on vienne faire appel à eux car presque plus personne ne maîtrisait le développement COBOL pour le fameux bug AN 2000 et le passage à l’euro dans les programmes Mainframe.
Les grosses boites continuent et continueront à utiliser le mainframe plus stable dans les traitements de gestion clairement, il leur suffit juste de faire un bel habillage d’interface client en JAVA / PHP / WEBSPHERE /WEBLOGIC & co… et tout le monde est content … les base en MY- SQL c’est beau mais ça ne tient pas la route en gestion face au mainframe…
Ah la jeunesse et ses idées pré conçues , bien sur ils vont déchanter mais je dois avouer que le cadre enseignant y est malheureusement pour beaucoup à leur faire miroiter un monde et un cadre de travail et de développement informatique qui est loin de la réalité ( non, tous ne vont pas faire du R&D à développer l’interface du futur sur des technologies qui ne seront disponibles que dans 10 à 15 ans … 🙂 le fait de faire des stages et des immersions en entreprise dans le cadre du cursus me semble de plus en plus vital c’est bien d’apprendre la théorie ( pour ma part je sors d’un DUT info avec spécialisation traitement d’image et en formation d’ingé au CNAM en cours du soir en plus du taf, faire la théorie et mener en même temps le boulot c’est ce qui m’a plu mais le discours des profs sur le cadre de boulot en info et les rémunérations etc… on ne vit clairement pas dans le même monde, heureusement que certains des profs en Ateliers / TD était issu du monde du travail , c’était des approches plus concrètes…) . Ton article est génial et je plussoie au max 🙂 MERCI 🙂
Moi-même je ne développe plus (et à dire vrai j’en suis bien contente). Mais pour avoir développé avec COBOL et avec d’autres langages plus modernes, dont certains orientés objets, j’ai trouvé que chacun avait ses avantages et ses inconvénients.
Personne ne songerait à utiliser un vélo de course pour faire du transport de frêt, il n’y a pas de raison de vouloir utiliser Websphere ou autre pour traiter des traitements de calcul comptable sur des millions de comptes clients.
Je crois que ça fait 30 ans qu’on prédit la mort du COBOL et du mainframe, mais pour l’instant j’ai surtout l’impression que les langages sont encore beaucoup trop gourmands et pas optimisés pour les remplacer.
Je plussoie à 100%, même si je ne développe pas en Cobol, mais en C# (bouh… 😉 ) Et il est clair que notre principal, énorme et quotidien problème, ce sont les performances…
Pas de souci, je n’ai rien contre les développeurs des autres langages XD
Je comprends l’attrait des langages modernes pour les interfaces, c’est juste que les limitations m’agacent.