Il y a quelques années, alors que j'étais étudiant en école d'ingénieur, un prof de génie logiciel nous dit, avec son accent du sud (pour bien visualiser, il faut penser à Galabru avec un air goguenard): "un jour mes cocos vous ferez du Cobol". Evidemment on a rigolé en disant que jamais de la vie on ferait des trucs pourris comme ça, que c'était pour les vieux informaticiens qui vivent cachés dans les sous-sols des banques à entretenir leurs vieilles applications des années 70. Malheureusement pour moi, cette vision prophétique s'est réalisée il y a quelques semaines sous la forme d'une mission chez un éditeur de logiciels de finance. En l'espace d'une semaine, je suis passé du C++ et des design patterns à l'ADL (un langage propriétaire proche du Pascal et du COBOL et intégrant en natif l'accès à la base de données) et à OpenVMS. Mon monde s'est écroulé. Durant les jours suivants, j'ai essayé de comprendre comment une entreprise avait pu s'enfermer dans des technologies pareilles, qui n'ont plus aucun avenir, et qui à terme vont poser de gros problèmes de maintenance et de pérennité. La réponse évidente et classique fut: ça marche très bien et ce serait suicidaire de vouloir tout réécrire. Ca marche très bien avec OpenVMS, ok, mais il devient difficile de trouver des VAX et les clients veulent de l'Unix. D'où la nécessité de trouver des solutions, au risque de se trouver dans une impasse, de perdre des clients, ce qui serait dommage car le produit est très riche et bénéficie de dizaines d'années de développements et d'expérience. Première solution: développer un interpréteur pour faire tourner l'exécutable VAX sur des machines Unix. D'où de sérieuses baisses de performances et de sérieux bugs ayant entre autres des impacts sur la manière de développer (ne pas écrires certains types de requêtes SQL, ne pas imbriquer de blocs conditionnels, ...). J'ai été surpris d'apprendre que cet interpréteur était développé en Python, mais apparemment ça marche quand même pas mal et les développeurs ont mis au point plusieurs techniques pour amélirer les performances (au début 100 fois moins rapide, le facteur n'est plus que de 10). Deuxième idée, en cours: développer un compilateur ADL pour Unix, ce qui semble une bien meilleure idée. Projet en cours, qui doit être super intéressant.A noter qu'à une époque un "développeur fou" avec écrit un programme qui traduisait le code ADL en code C pouvant être compilé sous Unix.
Tout ça pour dire qu'il faut prendre ses aînés au sérieux et que même s'il n'est pas toujours possible de tout refaire de zéro, ce n'est pas une raison pour ne pas prendre le temps de considérer son projet, la direction dans laquelle on veut l'emmener, et mettre en place des solutions visant à en assurer la pérennité.
