Dette technique : comment prioriser ses actions avec une matrice coût / criticité

Dans la plupart des projets techniques, il n’est pas difficile de trouver quoi améliorer. C’est particulièrement vrai pour les projets comportant de la dette technique. Mais par où commencer ?

Après une phase d’analyse, qu’il s’agisse d’un audit technique, d’une reprise d’un existant ou d’un simple retour d’expérience, il est fréquent de se retrouver avec une liste conséquente d’actions, de natures très différentes, qui relèvent toutes directement de cette dette technique accumulée au fil du temps.

Tout semble important, mais tout ne peut pas être fait en même temps. Sans méthode claire, les décisions reposent alors sur l’intuition, l’urgence du moment ou le dernier incident rencontré, et les efforts finissent par se disperser sans réduire vraiment la dette technique.

Une approche simple permet de reprendre le contrôle et de structurer les décisions. Elle repose sur une matrice croisant coût et criticité, qui permet de hiérarchiser les actions de manière rationnelle et de construire une trajectoire de réduction progressive de la dette technique.

Nous l’avons appliquée sur un cas concret, ce qui a permis de clarifier rapidement les priorités et d’alimenter la feuille de route pour traiter la dette technique au fur et à mesure.

Pourquoi la dette technique génère-t-elle une liste d’actions inexploitable ?

La dette technique désigne l’ensemble des compromis techniques accumulés au fil des évolutions d’une application.

La difficulté vient de l’absence de hiérarchisation claire face à l’accumulation de sujets :

• montées de version du socle technique ou des dépendances ;
• renforcement de la sécurité ;
• amélioration de la qualité du code et de sa couverture de tests ;
• fiabilisation des déploiements via l’industrialisation ;
• mise à niveau des pratiques (documentation, changelog, internationalisation).

Il devient difficile de savoir par où commencer.

Dans la pratique, les décisions se prennent au fil de l’eau. Certaines actions avancent parce qu’elles semblent urgentes ou incontournables, d’autres sont repoussées sans réelle justification.

Le budget ajoute une contrainte incontournable, et les arbitrages ne reposent pas uniquement sur l’importance des sujets, mais aussi sur les moyens disponibles.

Les sujets techniques entrent souvent en concurrence avec les demandes fonctionnelles. Une équipe qui doit choisir entre digitaliser un nouveau processus métier demandé par les équipes ou anticiper la migration d’une version de Symfony avant sa fin de support, penche presque toujours pour la première option. Ses bénéfices sont visibles immédiatement, alors que les risques de la seconde (failles de sécurité, ralentissement progressif des développements futurs) ne se matérialisent que plus tard, souvent au moment où l’hébergeur, par exemple, impose la migration dans l’urgence. Sans cadre structuré, les décisions s’orientent naturellement vers ce qui est le plus concret ou le plus visible.

Progressivement, l’ensemble perd en cohérence. Les efforts sont réels, mais rien ne permet encore de décider objectivement lesquelles de ces actions auront le plus d’impact.

Figure 1 : Sans méthode de priorisation, la dette technique finit souvent par céder sa place aux demandes fonctionnelles.

Une approche simple pour prioriser efficacement sa dette technique

Pour sortir de cette situation, il faut un cadre de décision simple, compréhensible et partageable. Ce cadre consiste en un outil qui permet de comparer les actions entre elles de manière cohérente.

Le principe repose sur le croisement de deux dimensions complémentaires : le coût et la criticité.

Évaluer les actions de manière cohérente

La première étape consiste à évaluer chaque action selon les mêmes critères, avec une évaluation homogène plutôt qu’une mesure parfaitement exacte, pour pouvoir comparer les actions entre elles.

Chaque action est analysée selon deux dimensions complémentaires.

Le premier est la criticité. Elle mesure les conséquences d’une action si elle n’est pas réalisée et donc en quoi elle est importante. Elle regroupe notamment :

• le risque de sécurité,
• l’obsolescence du socle technique,
• un problème de maintenabilité,
• un risque de régression.

Cette lecture permet de qualifier l’impact réel de l’action, même lorsque celui-ci n’est pas immédiatement visible. La sensibilité à ces enjeux peut varier selon l’organisation, le contexte et les parties prenantes auxquelles l’application répond.

Le second est le coût. Il mesure l’effort nécessaire pour réaliser l’action plutôt qu’un chiffrage précis, et prend en compte notamment :

• la complexité technique,
• le temps de mise en œuvre,
• les éventuels impacts sur le reste du système.

Cette estimation peut être réalisée sur une échelle linéaire, exponentielle ou bien, comme cela est fait en agilité, en utilisant la suite de Fibonacci (1, 2, 3, 5, 8, 13, 21, 34, etc.).

Chaque action est évaluée avec le même niveau d’exigence, ce qui permet ensuite de les comparer entre elles de manière pertinente et d’obtenir une cohérence d’ensemble. Sans cette rigueur, la matrice perd de sa valeur, car les décisions reposeraient à nouveau sur des perspectives subjectives.

Figure 2 : Chaque action est évaluée selon sa criticité et son coût estimé, et placé dans la matrice.

Lire la matrice et en tirer des décisions

Une fois les actions évaluées, leur positionnement sur la matrice croisant ces deux dimensions permet de les comparer entre elles. Certaines actions apparaissent alors immédiatement comme prioritaires, car elles combinent un niveau de criticité élevé avec un coût maîtrisé. D’autres, plus coûteuses ou moins critiques, peuvent être planifiées différemment.

De cette base, une notion de gain peut être déduite. Celle-ci correspond au retour attendu d’une action au regard de sa criticité et de son coût. Sans calcul complexe, elle permet d’identifier les actions à fort levier et celles qui peuvent attendre.

L’intérêt de cette approche tient autant à sa simplicité qu’à sa capacité à structurer les échanges. La matrice permet de passer d’une liste linéaire à une vision partagée, plus lisible et objective. Les arbitrages deviennent plus clairs, les décisions ne reposent plus uniquement sur des perceptions ou des urgences, mais sur une lecture commune des enjeux.

Figure 3 : Illustration de la lecture de la matrice de décision. Chaque action est positionnée selon deux critères, la criticité et le coût, afin d’en déduire un niveau de priorité.

Un cas concret de priorisation de la dette technique

Cette approche a été appliquée lors de la reprise d’un parc applicatif composé de plusieurs solutions métiers, et à la suite d’un audit technique réalisé pour le client.

Cet audit a rapidement mis en évidence une dette technique importante, avec un volume conséquent d’actions à mener. Le client n’étant pas lui-même technique, et le budget disponible restant limité, l’enjeu n’était donc pas seulement de savoir par où commencer, mais de décider quoi traiter en priorité avec des moyens restreints.

La matrice a permis de présenter l’étendue de cette dette de façon lisible et d’accompagner le client dans ses choix.

Constats techniques

Les applications reposaient sur un socle hétérogène, avec des niveaux de maturité variables.

Certaines présentaient des obsolescences importantes, notamment des versions anciennes du framework Symfony (2.x et 4.x) et de PHP (7.x). Au-delà des risques de sécurité, ces technologies n’étaient plus maintenues, ce qui compliquait chaque nouvelle évolution et augmentait progressivement le coût de maintenance.

D’autres faisaient apparaître des faiblesses structurelles. Les déploiements étaient manuels, sans chaîne d’intégration continue, ce qui multipliait les opérations répétitives à chaque mise en production, augmentait le risque d’erreur et limitait la fréquence des livraisons. La couverture de tests était faible, voire inexistante sur certaines applications, rendant les évolutions risquées face à des règles métiers structurantes et malheureusement non documentées. La logique métier était également parfois mêlée aux couches de présentation, ce qui complexifiait la maintenance.

Enfin, des manques touchaient les pratiques transverses, comme la documentation, le suivi de version ou encore l’industrialisation des processus.

Chaque point restait légitime pris isolément, mais l’ensemble formait une liste difficile à exploiter dans un contexte budgétaire contraint.

Les résultats de la matrice

L’application de la matrice coût / criticité a permis de repositionner l’ensemble de ces actions et de dégager une lecture claire.

Sur l’ensemble du périmètre analysé, la répartition suivante a émergé :

• 13 actions à fort gain ;
• 8 actions à gain intermédiaire ;
• 3 actions à faible gain.

Les actions à fort gain combinaient un niveau de criticité élevé avec un coût maîtrisé. Elles concernaient principalement des sujets structurants comme la sécurisation du socle technique, certaines montées de version ou la mise en place de pratiques essentielles.

Les actions à gain intermédiaire, bien que pertinentes, ont été volontairement différées afin de concentrer les efforts à court terme sur les leviers les plus impactants.

Cette lecture a permis de passer rapidement d’une liste difficile à exploiter à une vision priorisée et partageable, et de rendre les arbitrages plus concrets. Dans un contexte de budget limité, les décisions se sont appuyées sur des critères objectifs plutôt que sur des urgences ponctuelles.

La matrice a ainsi joué un rôle de support de décision, facilitant les échanges entre les équipes techniques et les parties prenantes en rendant les enjeux comparables.

Figure 4 : Une même action peut être positionnée différemment selon le contexte de l’application.

Le client a ensuite engagé une partie des actions recommandées. Cette démarche lui a aussi permis d’anticiper l’échec probable d’un audit de sécurité prévu dans les semaines suivantes, du fait de l’obsolescence des versions de PHP et de Symfony en place, et de reporter cet audit plutôt que d’essuyer un refus.

Quelques mois plus tard, une mise à jour technique imposée de l’extérieur s’est révélée impossible à réaliser sans faire évoluer plusieurs autres composants en cascade, chacun bloquant le suivant. Cet épisode a confirmé ce que la matrice avait déjà mis en évidence : la dette technique non traitée finit par s’imposer d’elle-même.

Depuis, le client et nous continuons de nous appuyer régulièrement sur cette même matrice pour prioriser les actions restantes.

Transformer la priorisation de la dette technique en plan d’actions

La matrice permet de structurer la réflexion, mais sa valeur réelle apparaît lorsqu’elle est utilisée pour orienter les décisions.

Basée sur trois niveaux de gain, la lecture obtenue permet de construire un plan d’action progressif :

• les actions à fort gain, à traiter en priorité ;
• les actions à gain intermédiaire, à planifier ;
• les actions à faible gain, à différer.

Dans notre cas, les actions à fort gain ont constitué le socle du plan d’action de la première année. Elles permettent d’obtenir rapidement des résultats visibles et de traiter les sujets les plus critiques avec un effort maîtrisé.

Les actions à gain intermédiaire viennent ensuite structurer la trajectoire, et alimentent naturellement la feuille de route de l’ année 2, voire des suivantes, selon les contraintes de budget et de planning.

Les actions à faible gain sont assumées comme secondaires et différées, afin de concentrer les efforts sur les leviers les plus impactants. Leur criticité peut évoluer dans le temps et faire varier le gain : les différer ne signifie donc pas les oublier.

Dans un premier temps, l’objectif est de sécuriser et stabiliser l’existant, en réduisant les risques majeurs et en posant des bases techniques solides. Dans un second temps, les efforts se concentrent sur l’amélioration continue, avec des sujets plus complexes ou plus coûteux abordés dans un cadre désormais plus maîtrisé.

Ce découpage rend la trajectoire lisible et permet d’adapter les décisions aux contraintes réelles, notamment budgétaires, sans perdre de vue les enjeux techniques.

La matrice ne remplace pas la décision. Elle la facilite, en apportant un cadre commun et une vision partagée. Reste alors la question de l’arbitrage face aux demandes métier et du budget à y consacrer dans la durée, un exercice qui, comme le montre le cas concret précédent, gagne à être renouvelé régulièrement plutôt que traité une fois pour toutes.

Figure 5 : La dette technique s’intègre naturellement à la feuille de route, au même titre que les évolutions fonctionnelles.

Ce qu’il faut retenir, c’est que gérer la dette technique ne consiste pas à tout corriger, mais à faire des choix éclairés.

Face à une accumulation d’actions, un cadre objectif aide à décider lesquelles traiter en priorité. Sans cadre, les efforts se dispersent et les décisions deviennent difficilement lisibles.

La matrice coût / criticité apporte une réponse simple à ce problème. Elle permet de structurer la réflexion, d’objectiver les arbitrages et de transformer une analyse technique en plan d’action concret.

Au-delà de la dette technique, cette approche peut être utilisée dans de nombreux contextes. Elle s’applique dès lors qu’il est nécessaire de comparer des actions, de prioriser des efforts et d’aligner des décisions.

Sa force tient justement à sa capacité à rendre les décisions plus claires et plus partageables, sans nécessiter d’outillage complexe.

La dette technique n’a pas vocation à être traitée à part. Elle s’inscrit dans la feuille de route, au même titre que les évolutions fonctionnelles, avec ses propres priorités et son propre calendrier. La question n’est plus de savoir s’il faut la traiter, mais comment l’intégrer dans une trajectoire réaliste, qui tient compte du budget, du planning et des enjeux métier.

Crédit photo : Vadym Pastukh