Dette technique informatique : notre méthode pour la calculer

Aujourd’hui, nous allons parler du sujet de la dette technique, qui bien qu’il existe depuis de nombreuses années n’est pas nécessairement compris ni par les équipes ni par les clients.

Nous allons donc essayer de proposer une formule ou une grille de calcul permettant d’évaluer la dette technique d’un logiciel ou d’un SILe SI désigne le système d'informations d'une organisation.. L’objectif est de fournir un repère chiffré permettant de visualiser et d’appréhender cette dette et de coordonner les acteurs afin de la minimiser.

De quoi parle-t-on ?

Voici une définition théorique de la dette technique (cf. Wikipedia) :

La dette technique est une métaphore du développement logiciel inventée par Ward Cunningham. Il s’inspire du concept existant de dette dans le contexte du financement des entreprises et l’applique au domaine du développement logiciel.

Cette définition reste vague mais pose le principe d’un coût représenté par un logiciel ou un SI relativement à sa qualité, sa maintenance ou son cycle de vie. Concrètement quel peut être l’intérêt d’une telle approche, et comment peut-elle m’aider dans mes choix ?

Pourquoi se préoccuper de la dette technique ?

Ou à l’inverse, que se passe t-il si l’on ne s’en occupe pas ? Immanquablement, la dette technique se constitue et augmente, de manière non visible mais absolument réelle, avec d’abord peu d’impacts, puis de plus en plus avec le temps, de sorte que la dette va augmenter de façon exponentielle.

Au quotidien, voici les manifestations de la dette technique :

1. il devient impossible de faire évoluer rapidement les fonctionnalités
2. chaque évolution nécessite des études d’impact fort
3. on ne peut plus faire évoluer une solution car la technologie est obsolète
4. une nouvelle technologie sort et on ne peut pas du tout s’y adapter (exemple : la mode du cloud, et nos applications ne sont pas comptabiles)

Si vous retrouvez vos logiciels ou votre SI à travers ces quelques propositions, alors il est temps de se préoccuper de la dette technique.

Les différentes formes de la dette technique

Une des formes les plus évidentes de dette technique est le retard technologique, mais il en existe de nombreuses autres, parfois nichées là où l’on ne s’y attend pas.

La dette technique liée à l’environnement

Cette forme de dette technique regroupe tous les retards accumulés quant à l’environnement technique.

Si vous possédez une ferme de serveurs, la dette technique sera le nombre de retards de montée de versions majeures de votre environnement. Par exemple, vous avez deux serveurs Windows XP (si si ça existe) et deux RDHL 4, vous avez donc une dette technique de plusieurs versions de vos serveurs.

Ce concept de dette technique « environnement » peut donc comprendre n’importe quel élément de la stack « infra / serveur » qui n’est pas directement lié à vos applicatifs. Par exemple, si vous êtes en environnement virtualisé, une version de retard de VSphere rentre dans cette catégorie.

Pourquoi des versions de retard créent elles une dette ? Parce qu’un jour ou l’autre vous serez obligé de mettre à jour ces environnements (et parfois de manière contrainte), et plus vous serez loin de la cible (disons la version actuelle) et plus l’effort sera dur. Nous proposons donc une simple formule pour calculer cette dette technique :

• 1 version de retard sera comptabilisée 1 point
• 2 versions de retard seront comptabilisées 3 points
• 3 versions de retard seront comptabilisées 6 points

Ainsi votre dette technique « environnement » sera la somme de ces points sur l’intégralité de vos environnements divisée par le nombre d’environnements. Libre à vous par la suite de valoriser ces valeurs en euros.

La dette technique logicielle

Plus connue et plus simple à aborder, elle correspond à la dette technique de vos applicatifs logiciels. Elle se décompose selon nous en 5 parties :

• la stack applicative
• la qualité
• les bugs
• la documentation
• l’automatisation des tests

La dette technique de la stack applicative

La stack applicative correspond à l’intégralité des technologies utilisées pour faire l’applicatif. Par exemple le langage JavaLangage de développement très populaire ! avec un framework Java EE, le tout orchestré par Maven. La dette se composera donc de l’intégralité des retards de chacune des briques applicatives utilisées.

Une composante plus difficile à mesurer est la pérénité de la technologie. Prenons le cas d’un framework JavaScript (AngularAngular est un framework de développement JavaScript populaire basé sur TypeScript. par exemple). Ce framework est-il correctement maintenu ? Est-ce le bon choix concernant le futur ? Cette estimation est d’autant plus complexe à réaliser que les technologies concernées évoluent rapidement (en particulier pour la partie frontale / web).

Les points se comptabilisent de la même manière que précédemment :

• 1 version de retard sera comptabilisée 1 point
• 2 versions de retard seront comptabilisées 3 points
• 3 versions de retard seront comptabilisées 6 points

La dette technique de qualité

Il s’agit ici de la qualité intrinsèque de l’applicatif. Pour la mesurer, il convient d’avoir un oeil expert et d’évaluer la qualité du code produit. Une bonne approche pour évaluer cette qualité est de vérifier que le code respecte le paradigme de développement de la technologie utilisée. Cette approche, bien que non chiffrée, s’avère souvent la plus logique.

• mettre une note de 1 à 5 par application

La dette technique liée aux bugs

Plus facile à mesurer si vous avez un suivi des anomalies. Il convient de prendre en compte le nombre de bugs issus du code sur une période de temps donnée (rapportée à la taille de l’application).

• mettre une note de 1 à 5 par application

La dette technique de la documentation

Souvent les audits se basent sur la taille de la documentation, mais cette approche ne nous parait pas pertinente. Par exemple, la Javadoc et la documentation Oracle sont largement pléthoriques, mais la majorité de ces informations est parfaitement inutile.

La qualité de la documentation se jugera donc davantage sur la facilité d’entrée d’un nouveau membre dans l’équipe de développement. Pour cela, la meilleure documentation reste une bonne présentation de l’application, de son architecture et de ses règles de conception.

• si l’intégration d’un développeur prend moins d’une semaine mettre 1 point
• si l’intégration d’un développeur prend moins de deux semaine mettre 3 points
• si l’intégration d’un développeur prend moins d’un mois mettre 5 points
• sinon mettre 10 points

La dette technique d’automatisation des tests

Plus classique, nous mesurons ici la couverture des tests sur l’applicatif.

• mettre une note de 1 à 5 en fonction de la couverture de tests

Formule de valorisation de la dette technique

Une fois ces définitions posées, nous pouvons envisager de créer une sorte d’indicateur qui permette de définir si, oui ou non, la question de la dette technique devient prioritaire pour vous.

Voici donc un référentiel simple, qui vous permet d’avoir une vision plus claire de la dette technique de vos applications et de votre SI :

Faites la somme de tous les points obtenus. Si le total est inférieur à 5, aucun problème majeur. Entre 5 et 10, il faut commencer à s’inquiéter. Au dessus de 10… ça commence à sentir le roussi !

N'hésitez pas à nous contacter pour en discuter !