Logiciel personnalisé
La dette technique a un prix : comment la présenter à un conseil d'administration non technique
Vincent Wahidi
La dette technique est l'écart entre la façon dont votre logiciel fonctionne aujourd'hui et la façon dont il devrait fonctionner pour continuer à servir l'entreprise. Comme la dette financière, elle porte intérêt : chaque raccourci pris pour expédier plus rapidement rend le prochain changement plus lent, plus risqué et plus coûteux. Un conseil n'a pas besoin de comprendre le code. Il lui faut trois chiffres dans sa propre langue. Que nous coûte cette dette en perte de vitesse, que coûte son remboursement et qu’arrive-t-il au risque si nous la quittons ? Présentée de cette façon, la dette technique cesse d'être une plainte d'ingénierie et devient une décision de capital normale : dépenser maintenant pour éliminer un problème récurrent, ou continuer à payer des intérêts jusqu'à ce que quelque chose se brise.
Qu'est-ce que la dette technique en termes commerciaux simples ?
La dette technique est le coût futur créé par le choix d’une solution rapide maintenant au lieu d’une solution meilleure qui prendrait plus de temps. Certaines d’entre elles sont délibérées et sensées, prises pour respecter une date limite. Certains s’accumulent tranquillement à mesure que l’entreprise évolue et que les anciennes décisions ne conviennent plus. Quoi qu’il en soit, la facture arrive plus tard, sous la forme d’une livraison plus lente et d’un risque plus élevé.
L’analogie avec l’emprunt tient bien dans une salle de réunion parce que les mécanismes sont cohérents. Vous vous endettez pour obtenir quelque chose plus tôt que vous ne le pourriez autrement. Vous payez des intérêts tant qu’il reste là. Et si elle se développe de manière incontrôlée, elle peut tranquillement consommer la capacité dont vous avez besoin pour le travail qui fait réellement avancer l’entreprise.
Comment expliquez-vous le coût de la dette technique à un conseil d'administration ?
Traduisez-le en trois éléments qu'un conseil d'administration suit déjà : le coût, le temps et le risque. Évitez complètement le vocabulaire de la base de code. Le tableau ci-dessous mappe chacun d’entre eux à une question à laquelle le conseil sait déjà répondre.
| Préoccupation du conseil d'administration | Ce que cela signifie dans la dette technique | Comment l'exprimer |
|---|---|---|
| Intérêt (la traînée récurrente) | L'impôt que vous payez chaque jour où la dette existe. Les fonctionnalités qui devraient prendre une semaine en prennent trois. Les nouvelles recrues mettent plus de temps à devenir productives. | Une part de la capacité d’ingénierie perdue pour contourner le problème plutôt que pour créer une nouvelle valeur. |
| Ralentissement (le coût d'opportunité) | Chaque heure passée à lutter contre d’anciennes décisions est une heure non consacrée à quelque chose pour lequel un client serait prêt à payer. | Une feuille de route qui ne cesse de glisser, avec des lancements annoncés que la dette retarde. |
| Risque (l'événement extrême) | Certaines dettes sont une fuite lente. Il y a parfois une ligne de faille : une panne, une faille de sécurité, une personne qui est la seule à comprendre un système critique, une incapacité à respecter une nouvelle réglementation. | Probabilité et impact, de la même manière que le conseil d’administration interprète tout autre risque. |
Le fait de décrocher un terrain convertit l'effort en argent que le conseil d'administration peut comparer à d'autres investissements. Vous n'avez pas besoin d'un chiffre précis. "Environ un tiers de notre capacité de livraison est actuellement consacré à la résolution de ce problème, et cette part augmente chaque trimestre" est une phrase sur laquelle un conseil d'administration peut agir.
Comment justifier le remboursement ?
Traitez-la comme n'importe quelle autre proposition d'investissement, avec un coût, un rendement et une comparaison sans rien faire.
- Nommez la dette spécifique, pas la catégorie. « Notre système de facturation » bat « l'ancien code ». Les conseils financent des problèmes concrets, pas une hygiène abstraite.
- Quantifiez les intérêts que vous payez maintenant. Montrez le coût récurrent en termes de délai de livraison ou de capacité. C'est votre référence.
- Indiquez le coût de réparation. Un travail limité avec un prix et un délai. Si vous ne pouvez pas encore en évaluer la portée, la première demande est une brève enquête, pas un chèque en blanc.
- Affichez le retour. Livraison plus rapide, taux d'échec inférieur, risque supprimé. Liez-le à quelque chose qui intéresse le conseil d’administration, comme le lancement d’un produit que la dette actuelle retarde.
- Décrivez la voie de l'inaction. L'évolution des intérêts au cours de la prochaine année et le risque que vous acceptez en attendant. C’est souvent la partie la plus convaincante.
La raison pour laquelle la plupart des demandes de remboursement échouent est qu’elles sont présentées comme une qualité en soi. Une planche n'est pas contre la qualité. Il s’oppose à ce que l’on dépense de l’argent pour quelque chose sans rendement déclaré. Donnez-lui le retour et la comparaison, et la décision devient ordinaire.
Quel montant de dette technique est acceptable ?
L'objectif n'est jamais nul. Zéro dette signifie généralement que vous avez expédié un travail trop lent et trop technique qui n’en avait pas besoin. Une certaine dette est le prix correct et délibéré pour avancer à la bonne vitesse. La ligne à surveiller n’est pas le montant de la dette, c’est l’évolution des intérêts. Si la part des efforts consacrés à contourner les anciennes décisions est stable et faible, la dette est sous contrôle. Si cette part augmente d'un trimestre à l'autre, la dette s'aggrave et vous vous dirigez vers le point où la majeure partie de l'énergie de l'équipe reste immobile.
C'est le même instinct qui se cache derrière une décision lucide créer ou acheter un logiciel. Choisir de construire crée un actif que vous possédez et que vous devez entretenir, c’est-à-dire une dette que vous paierez volontairement. Choisir d’acheter transfère cette responsabilité sur le vendeur, avec ses propres compromis. Quoi qu’il en soit, le coût est réel et mérite d’être mentionné dès le départ plutôt que de le découvrir plus tard, ce qui est exactement l’objectif que nous appliquons à ce que coûte réellement un logiciel personnalisé et au travail de logiciel personnalisé que nous entreprenons pour rembourser une dette de ce genre.
Le point pratique à retenir
Avant d’entrer dans la réunion du conseil d’administration, écrivez une phrase : cette dette nous coûte X en vitesse perdue, la réparer coûte Y et la laisser coûte Z et un risque connu. Si vous pouvez remplir ces trois chiffres, même grossièrement, vous avez une proposition finançable. Si vous n’y parvenez pas, la première question honnête est le moment de le découvrir. Les conseils d’administration ne rejettent pas la dette technique parce qu’elle est technique. Ils la rejettent lorsqu’elle se présente sous la forme d’une plainte plutôt que d’une décision.

Vincent Wahidi
Auteur
Vincent Wahidi is the director of Encelyte, a computer engineer who builds production AI, automation, and custom software for enterprises across Cyprus and the wider region. He writes the strategy, cost and decision-maker pieces himself; the practical how-to guides are curated under the five mission-cat bylines below.
À lire ensuite
Que mettre dans un appel d'offres de développement logiciel (et les 5 clauses qui vous protègent)
Un problème qui mérite d'être résolu ?
Dites-nous ce que vous construisez ou corrigez. Nous vous répondrons dans un délai d'un jour ouvré avec une prochaine étape claire.
