La dette technique n'est pas un problème technique
Elle est presque toujours la trace d'arbitrages passés, pris sciemment faute de temps ou d'argent. La traiter en sujet d'ingénierie explique qu'elle ne se résorbe jamais.
Le terme dette technique a un mérite et un défaut. Le mérite est d’avoir introduit l’idée d’un remboursement. Le défaut est d’avoir enfermé le sujet dans le vocabulaire de l’ingénierie, donc de l’avoir rendu inaudible par ceux qui décident.
D’où elle vient réellement
Dans les DSI d’ETI que je croise, la dette technique n’est presque jamais le produit d’une incompétence. Elle est le produit d’une suite d’arbitrages parfaitement rationnels au moment où ils ont été pris.
Une migration reportée parce que l’exercice budgétaire était tendu. Une reprise de données faite à la main parce que le prestataire coûtait trois fois le budget disponible. Une version figée parce que l’éditeur facturait la montée de version au prix d’un projet. Un contournement mis en place un vendredi soir pour rétablir la production, jamais repris ensuite parce que rien n’a plus jamais été aussi urgent.
Chacune de ces décisions était défendable. Leur accumulation ne l’est plus. Mais si vous présentez le résultat comme un problème technique, vous vous adressez à des gens qui n’ont pas le pouvoir de le résoudre, et vous laissez hors du sujet ceux qui l’ont créé et qui peuvent le financer.
Le mécanisme qui la rend invisible
La dette technique a une propriété désagréable : elle ne produit aucun signal tant qu’elle ne produit pas un incident majeur.
Un serveur hors support fonctionne exactement comme un serveur sous support, jusqu’au jour de la panne. Une procédure manuelle produit le même résultat qu’une procédure automatisée, jusqu’au jour où la personne qui la connaît est absente. Une base de données non migrée sert les mêmes requêtes, jusqu’au jour où un correctif de sécurité n’existe plus pour sa version.
Cette absence de signal intermédiaire explique le comportement des directions générales, qui n’est pas irrationnel : elles ne voient aucune dégradation, donc elles concluent à l’absence de problème. Une DSI qui répète que la situation est préoccupante sans pouvoir montrer de dégradation mesurable finit par être entendue comme une DSI qui demande du confort.
Rendre la dette mesurable sans devenir illisible
Le réflexe habituel consiste à construire un registre exhaustif. C’est une mauvaise idée : un tableau de trois cents lignes est une capitulation déguisée en méthode, parce qu’il ne permet toujours aucun arbitrage.
Trois indicateurs suffisent à rendre le sujet visible, à condition d’être suivis dans le temps et présentés ensemble.
Le nombre de composants hors support éditeur ou constructeur, avec leur date de sortie de support. C’est un fait opposable, indiscutable, et qui se dégrade mécaniquement si rien n’est fait. C’est l’indicateur le plus efficace en comité de direction, parce qu’il ne se discute pas.
Le délai de restauration constaté lors du dernier exercice, comparé au précédent. Pas le délai contractuel, pas le délai théorique : le délai chronométré lors du dernier test réel. Sa dégradation est le symptôme le plus fiable d’une dette d’infrastructure.
Le nombre de processus critiques reposant sur une seule personne. Cet indicateur touche à la continuité d’activité, sujet que les directions générales comprennent immédiatement, contrairement à l’obsolescence technique.
Le remboursement ne se négocie pas en bloc
Une demande de chantier global de résorption de la dette technique est presque toujours refusée, et ce refus est logique : elle demande un budget important pour un résultat que personne ne saura constater.
Deux approches fonctionnent mieux.
La première consiste à adosser le remboursement aux projets. Tout projet touchant un périmètre endetté inclut la remise à niveau de ce périmètre, chiffrée dans le projet. Le surcoût est réel, de l’ordre de dix à vingt pour cent selon les cas, et il est bien plus facile à faire accepter dans un projet financé que dans une ligne isolée.
La seconde consiste à réserver une capacité récurrente de l’équipe, protégée. Une journée par semaine et par personne, sanctuarisée. L’expérience montre que cette capacité est la première chose consommée par l’urgence si elle n’est pas explicitement défendue par le DSI lui-même, semaine après semaine.
Ce qu’il faut accepter
Une part de dette est optimale. Une DSI sans aucune dette technique est une DSI qui a trop investi dans la propreté au détriment de la valeur produite, et cela existe aussi.
L’objectif n’est pas de rembourser, mais de choisir ce qu’on garde en dette et de le savoir. Une dette documentée, datée et assumée est une décision de gestion. Une dette découverte le jour de l’incident est un échec de gouvernance, et c’est ce second cas qu’il s’agit d’éviter.
Questions fréquentes
- Quelle part du budget consacrer à la dette technique ?
- Il n'existe pas de ratio universel défendable. Un pourcentage fixe est surtout utile pour obtenir un accord de principe, mais il se fait couper dès que l'exercice se tend, précisément parce qu'il n'est rattaché à aucune conséquence. Rattacher chaque remboursement à un risque daté résiste mieux qu'un pourcentage.
- Faut-il tout documenter dans un registre de dette ?
- Non. Un registre exhaustif devient un cimetière que personne ne lit. Ne consignez que ce qui a une conséquence identifiable : un composant hors support, une dépendance unique à une personne, une reprise manuelle récurrente. Le reste relève de l'amélioration continue, pas de l'arbitrage.
- Comment convaincre une direction de financer un chantier invisible ?
- En cessant de le présenter comme invisible. Un composant hors support constructeur, un délai de restauration qui a doublé, une astreinte qui ne repose que sur deux personnes : ce sont des faits datables et quantifiables, pas des préférences d'ingénieur.