Au début des années 1990, l’informaticien Ward Cunningham – l’inventeur du « wiki » - emploie la métaphore financière de la « dette » pour évoquer les surcoûts cumulés dans le processus de développement du logiciel, à chaque fois qu’on ne traite pas au plus vite les défauts, les non-qualités détectées sur un produit. Cette observation intervient dans un contexte où la mise en place des systèmes d’information devient déjà plus « itérative » (on ne parle pas encore d’agilité, le manifeste agile arrivant 10 ans plus tard, mais les méthodes de développement rapide apparaissent), et où il faut donc se préoccuper de la survie des prototypes qui se transforment en produits déployés, lesquels doivent continuer à évoluer au gré des demandes de leurs utilisateurs. À l’origine, la « dette technique » vise surtout le code, sa résorption fait appel aux bonnes pratiques de « refactoring », c’est-à-dire de restructuration et nettoyage du code existant pour le rendre plus robuste et plus malléable, mieux à même de faire l’objet d’extensions et d’évolutions.
En généralisant, la notion de « dette technique » s’applique au système d’information pris comme ensemble, et donc touche aussi à des considérations d’architecture technique ou applicative, aux dépendances entre composants et vis-à-vis de produits externes ayant leur propre cycle de vie technique et commerciale, et pas seulement à la qualité intrinsèque du code d’une application.
Le DSI et la dette technique
Le DSI, exploite un « patrimoine » de systèmes conçus à différentes périodes, dans des environnements techniques variés, tout en maintenant en conditions de fonctionnement, en le faisant évoluer et en le complétant par de nouveaux développements ou des solutions externes, en fonction d’une stratégie d’évolution du SI et d’un flux de demandes motivées par les métiers.
Le DSI a besoin – pour des raisons opérationnelles et économiques - de définir un référentiel technique et architectural (quelles plateformes, quels produits communs, quels modèles d’applications, etc.), et souhaite que les différents segments de son SI ne soient idéalement pas trop éloignés de ce niveau de référence. Enfin, il doit arbitrer régulièrement la répartition de ses moyens entre l’investissement sur les nouveaux produits - au risque de négliger les systèmes existants et d’accumuler un retard de ces produits par rapport à l’état de l’art technologique - et le besoin de rénovation ou de refonte de ces anciens systèmes.
Cinq fausses bonnes idées autour de la dette technique.
Il s’agit un sujet technique, donc ça ne concerne que la DSI et pas les métiers. La technique étant en général l’affaire de la DSI plutôt que celle des métiers, il suffirait que la DSI prenne en main une bonne fois pour toutes les questions de rattrapage technologique, de migration des applications informatiques sur les bons socles techniques, sans embêter les métiers avec ces questions ?
Oui, à condition de remettre tout ceci dans une perspective de gouvernance nécessairement partagée entre la DSI et les métiers, c'est-à-dire d’arbitrage sur les moyens nécessaires pour atteindre un objectif commun raisonnable, et de gestion partagée des contraintes et des risques.
- Dans quelle mesure l’investissement sur le socle technique du SI, et sur la migration des applications existantes vers ce socle technique, va ensuite donner de nouvelles capacités d’évolution du SI au bénéfice des métiers ?
- Pendant la refonte technique d’une partie du SI, quels seront les degrés de liberté pour ajouter des fonctionnalités aux applications ?
C’est un sujet technique, donc plus opérationnel que stratégique.
Pourquoi opposer technique et stratégie ? n’est-il pas stratégique de s’interroger sur la rationalisation des plateformes ? Et parmi les choix technologiques, il est certes utile de s’intéresser aux nouvelles technologies innovantes et à leurs usages, mais aussi à la capacité de déployer des technologies accessibles, stabilisées, en remplacement de très anciens dispositifs.
Avant d’être un sujet opérationnel, la feuille de route technologique fait normalement l’objet d’une analyse stratégique : quels scénarios pour répondre à quels enjeux ?
De plus, la stratégie technique et sa déclinaison opérationnelle vont constituer des leviers pour la modernisation, dégager des marges de manœuvre pour faire avancer les sujets numériques qui, justement, se trouvent ralentis par l’héritage de cette dette qui n’a pas été remboursée dans un délai raisonnable.
On a toujours vécu avec de la dette technique, ça n’empêche pas le SI d’évoluer.
L’enjeu de résorption de la dette technique s’accroît avec le niveau d’ambition de la transformation numérique. Le SI continue d’évoluer, mais seuls les nouveaux développements sans contraintes de reprise d’un existant peuvent profiter pleinement de ces nouveautés, avec les moyens restant après la charge dévolue au maintien de l’existant. En faisant l’effort d’assainir le paysage informatique, on dégagera des capacités pour les évolutions porteuses de valeur pour le métier.
On ne sait pas mesurer la dette technique.
Certes, la dette technique est multiforme, il n’existe pas d’indicateur unique, mais plusieurs points de vue, et différents niveaux de détail, selon qu’on s’intéresse à l’infrastructure, à l’architecture, au code des applications, etc. Mais on peut très bien analyser la situation à travers différents prismes, identifier les risques, donc identifier le poids de la dette dans ses différentes composantes.
La dette disparaîtra au fil de l’eau par la refonte progressive des vieilles applications.
Le programme ordonné de refonte des applications résulte justement, pour partie, d’une stratégie de traitement des anciennes applications, éclairée par un diagnostic et une évaluation des risques. Or, plus on attend, plus la refonte sera difficile, car les applications embarqueront de plus en plus de fonctionnalités devenues incontournables et dont la reproduction dans un environnement plus « moderne » – si elle est choisie – sera plus laborieuse.
Comment procéder ?
Analyser le risque technologique du SI
C’est une démarche classique d’analyse de risque, portant en réalité sur deux niveaux d’analyse :
- Les composants techniques, partagés ou dédiés à des parties du SI : les systèmes, les middlewares, les outils de développement et leurs bibliothèques, etc.
- Les applications informatiques, ou les composants fonctionnels.
La démarche (est la suivante :
- Cartographier le SI (ou partir d’une cartographie existante) jusqu’au plan technologique (identifier de façon aussi complète et précise que possible les adhérences entre les blocs fonctionnels, applicatifs, et les composants techniques, en précisant les versions et/ou configurations en jeu).
- Évaluer le caractère critique intrinsèque, le niveau de risque associé directement à chaque objet :
- Établir les niveaux de risques induits par les liens entre composants fonctionnels et techniques.
- Constituer ainsi un jeu d’hypothèses pour les étapes suivantes (établissement d’un plan d’action).
Cette approche ressemble d’une certaine façon à une évaluation de risque de sécurité du SI ; la méthode peut ainsi s’inspirer des approches pratiquées en matière de cybersécurité.
Identifier et évaluer les opportunités ouvertes par un « assainissement » du SI
La refonte des applications ne doit pas forcément se limiter à un besoin de remplacement de briques techniques. Dès lors que les futures applications s’appuieront sur de nouveaux socles techniques, de nouveaux champs d’opportunités deviendront accessibles : enrichissement fonctionnel, nouveaux modes d’accès (mobilité, etc.), possibilité de partage et d’ouverture sécurisée via des API, etc. La réflexion doit donc être globale, sans isoler l’angle strictement technique de l’analyse, car la modernisation technique est bien un levier pour donner plus de valeur aux projets qui en exploiteront les bénéfices. Il faut donc être en mesure d’évaluer la valeur nouvelle apportée par un assainissement du SI et de maximiser cette valeur prévisionnelle en fonction de la cible choisie. Ce choix de scénario peut prendre place dans une démarche de planification stratégique du SI, de type « schéma directeur du SI ».
Planifier la feuille de route technologique permettant d'assainir le SI.
Déterminer la cible et la trajectoire de refonte :
- On suppose que le choix d’un socle technique cible est déterminé par ailleurs (c’est un autre chapitre…) même si ce travail de définition d’une cible doit tenir compte du point de départ.
- L’idée est ici d’établir la trajectoire de refonte en jouant sur deux préoccupations :
- La mitigation du risque technique existant : comment limiter au plus tôt les dépendances vis-à-vis des composants techniques les plus faibles, les plus critiques
- La sécurisation de la transition vers de nouvelles plateformes : ceci peut notamment orienter l’ordonnancement des projets de migrations (les interfaces entre anciennes et nouvelles applications doivent rester les plus simples possible surtout s’il s’agit d’un état transitoire).
C’est une dimension de l’urbanisation du SI : comment agencer les évolutions techniques et fonctionnelles du SI ? Quelles en sont les conditions de succès ? (Compétences, maîtrise de l’environnement, etc.)
Conduire les programmes de migration technique qui s’imposent.
Il s’agit là de passer à la phase opérationnelle en tenant compte de la spécificité de ces programmes, du fait que certains projets apparaîtront plus techniques que des projets classiques d’évolution de SI métier. Par exemple, un programme de décommissionnement complet d’une filière technique obsolète, et par conséquent de portage ou refonte des applications informatiques concernées, devra composer avec les besoins d’évolution fonctionnelle desdites applications.
D’où un besoin de dialogue, pour ne pas dire de négociation, avec les métiers concernés, pour expliquer le bien-fondé de ces manœuvres qu’on souhaite rendre invisibles à l’utilisateur final, ou au moins de nature à éviter toute régression, mais avec des compromis à opérer le cas échéant entre les priorités respectives des besoins d’évolution fonctionnelle ou technique. Et donc pour arbitrer les moyens alloués à ces projets en démontrant leur nécessité et si possible leur retour sur investissement. Mais aussi un besoin de pilotage et de suivi particuliers, des dispositifs spécifiques d’intégration et de contrôle qualité exhaustifs (notamment pour tester la préservation des fonctionnalités des applications et de toutes les interfaces qui s’y rattachent) : si on a pris l’hypothèse de « bloquer » les évolutions fonctionnelles d’une application pendant une migration technique, il faudra réinjecter les évolutions fonctionnelles urgentes à un moment donné.
Par Reynald Bouy, Directeur de Pôle d’Activité, Groupe Noveane
