- Le patrimoine applicatif : statu quo ou évolution
- A unified
- L'acteur belge de la dématérialisation des factures Unifiedpost Group s'installe en France
- L'acteur belge de la dématérialisation des factures Unifiedpost Group s'installe en France
- alain-carpentier-directeur-ventes-mondiales-daruba-scaled
- gcs21_eclairage-1
Une des difficultés du DSI et de son service informatique réside dans la gestion des applications et données, vieilles de 10, 15, 20 ou 25 ans. Ce patrimoine, souvent dénommé legacy, est parfois vécu comme un véritable boulet qu'il faut conserver, projet après projet. Quels sont les choix pour le DSI ?
Dressons tout d’abord un constat : le patrimoine applicatif et de données représente un héritage très hétérogène, mainframe ou non, qui va du Cobol aux premiers Java en passant par VB, Smalltalk, Perl, Pac- Base, les outils et librairies maison non standard, etc. La documentation technique est de qualité variable, si elle existe. Il faut dire qu’il y a encore plus de 200 milliards de lignes de code Cobol. “Cinq milliards de nouvelles lignes de code Cobol se rajoutent chaque année !” commente Henrik Jacobsen, Directeur Technique de Micro Focus France.
Le poids du patrimoine applicatif se révèle par un chiffre simple : le coût de la maintenance de cet existant représente 70 à 80 % du budget IT (Forrester, 2005). Cela constitue une immobilisation des moyens humains et financiers considérable, qui grève l’investissement. On comprend mieux les enjeux colossaux du legacy et de sa modernisation.“Finalement, le patrimoine vieillit et même si on met en place une nouvelle application, celle-ci ne remplace pas forcément l’ancienne, qui perdure. La couverture (de la nouvelle application) n’est pas de 100 %. Cela ne simplifie pas le SI !”, commente Fabrice Bonan, directeur R&D de Talend.
