Modernisation applicative : les économies s’additionnent en procédant par étapes

Pour un DSI, le bien-fondé de la modernisation applicative ne fait guère de doute. Ouverture, souplesse, économies substantielles, amélioration des performances, gestion des compétences, les arguments, en effet, ne manquent pas. Pourtant, beaucoup hésitent à se lancer dans un projet qui apparaît trop risqué en raison de son coût, de sa lourdeur et de la crainte d’un effet tunnel incontrôlable.

S’il existe plusieurs options pour moderniser ses applications legacy, jusqu’à la réécriture complète, le replatforming permet de répondre à l’essentiel des objections et d’obtenir les bénéfices escomptés en maîtrisant risques, coûts et délais.

Le replatforming consiste à porter le code, de façon iso-fonctionnelle et iso-syntaxique, vers un nouvel environnement, par exemple de Cobol mainframe vers Cobol sur système ouvert. Données, fonctionnalités, interfaces, tout est préservé et, aux améliorations de performances près, la transition est transparente pour les utilisateurs. À l’exception des tests de non régression – bien évidemment essentiels –, on s’affranchit donc de toute considération fonctionnelle. Le coût de ce projet d’intégration technique, qui nécessite de recourir à des experts, , correspond souvent à une année de coût de fonctionnement du système considéré. Il est assez simple d’en démontrer le ROI, qui est à la fois très important et très rapide. Avec jusqu’à 70 % de réduction des coûts d’exploitation par rapport au système d’origine, le projet est intégralement payé en moins de 2 à 3 ans et, à partir de là, constitue un gain net sur le budget de la DSI.

« À titre d’exemple, le plus important projet de replatforming jamais réalisé au monde (55 000 MIPS) par Atos a permis à la CNAF des économies très significatives en regard de l’investissement consenti : 20 M€ de réduction annuelle des coûts pour 22 M€ investis ! »

Les économies s’additionnent. On gagne sur la maintenance matérielle et logicielle, les licences des outils propriétaires (souvent remplacés par des équivalents open-source), les compétences, la consommation énergétique, le développement et l’intégration des projets ultérieurs… Sans contester ces bénéfices, les DSI souhaitent toutefois pouvoir les détailler et les chiffrer avant de se lancer. En procédant pas à pas, on va non seulement répondre à cette préoccupation légitime, mais également préparer le terrain technique afin de désamorcer les risques et notamment celui de l’effet tunnel.

Procéder par étape pour maîtriser les coûts

La première étape consiste à procéder à un état des lieux et à cartographier le patrimoine legacy concerné. À l’aide d’outils non intrusifs, on vérifie le code : sa volumétrie et son périmètre, sa qualité et sa complexité, et les dépendances qui vont conditionner les lotissements possibles. On fait également l’inventaire des composants, lequel, dans des systèmes vieux parfois de plusieurs décennies, recèle souvent des surprises. D’une durée de deux à trois mois, cette étude initiale permet de préciser les besoins, l’ampleur et la complexité des travaux, le coût du projet et donc son ROI (on estime notamment les ressources à mobiliser côté client pour de nombreux tests sur l’environnement mainframe, dont les résultats seront comparés avec ceux réalisés sur plateforme Open) et le planning envisagé (en incluant des fenêtres de gel applicatif cohérentes avec les besoins métier). Si la proposition n’est pas retenue, ce travail n’aura pas été vain car il permet malgré tout à la DSI de connaître en détail des environnements généralement critiques et pourtant souvent mal documentés.

Pendant quatre à six mois, l’étape suivante va consister à réaliser un prototype sur un sous ensemble représentatif d’une taille significative de façon à démontrer la faisabilité technique, la performance de la cible, la justesse des évaluations et la pertinence des choix d’outils. Ce n’est qu’ensuite que sera lancé le projet proprement dit mais, là encore, si le feu est rouge, le travail réalisé aura permis de moderniser un périmètre applicatif homogène.

Aborder ainsi le projet de replatforming apporte la visibilité et les réponses indispensables pour le sécuriser. Cela permet en particulier de se focaliser sur les aspects techniques qu’il ne faut en aucun cas sous-estimer. La modernisation applicative reste une entreprise d’une très haute technicité, qui réclame l’intervention conjointe d’experts des mainframes, des compilateurs et des moteurs transactionnels, de l’exploitation, de la conduite de grands projets… La rigueur méthodologique permet de tirer le meilleur de ces compétences mais ne saurait se substituer à la capacité à pouvoir les mobiliser au sein d’une même équipe, ce qui demeure le premier facteur du succès.