La dette technique est souvent perçue comme un caillou dans la chaussure du développeur. Si vous l'enlevez immédiatement, vous pourrez continuer votre marche sans encombre. Mais si vous le laissez, il finira par vous faire mal au pied et ralentira votre progression. Plus vous tardez à l'enlever, plus il vous ralentira et plus votre période de convalescence sera longue. Dans cette optique, il est donc préférable de s'attaquer à la dette technique dès que possible, avant qu'elle ne devienne un véritable fardeau pour votre équipe et votre projet.

Cependant, il existe aussi des situations où la dette technique est un choix délibéré, une décision prise pour servir des intérêts commerciaux. Dans ce cadre, la dette technique n'est pas seulement subie, mais adoptée stratégiquement pour répondre à des besoins spécifiques du business.

Comment la dette technique peut-elle passée de “subie” à “choisie” ?

Revenons un peu en arrière. La dette technique, comme son nom l’indique, est une dette. Une dette que l’on contracte auprès de son logiciel et qui se rembourse par du temps de développement, entraînant potentiellement des retards dans le planning de déploiement des fonctionnalités ainsi que des coûts (salaires, prestations, etc.).

La dette technique survient dès lors qu’un choix a été fait et qu’il est, sur le plan technique, objectivement mauvais. Attention, cela ne signifie pas que votre équipe technique est incompétente ! Non ! Cela veut simplement dire que de mauvais choix techniques ont été faits, point final. Car même la meilleure équipe technique du monde souscrit à de la dette technique, tout le temps, pour tous les projets. C’est une réalité. Et parfois, cette dette est même contractée… volontairement ! En effet, bien que techniquement mauvais, un choix peut parfois s’avérer bon sur le plan stratégique ou produit. De nombreuses raisons peuvent conduire à accumuler de la dette technique. Donnons quelques exemples.

Exemple #1 : quand l’évolution du projet choisit de générer de la dette technique

Votre équipe technique n’a pas de boule de cristal et elle ne peut pas deviner l’orientation que va prendre votre business et/ou votre produit. Cela signifie qu’elle ne peut donc pas faire les choix techniques optimaux qui anticiperaient l’évolution de votre produit, surtout si celui-ci évolue dans des directions imprévues.

Il y a, bien entendu, des moyens de construire un projet avec pour principal enjeu la modularité. Mais la modularité a un coût : conception plus longue, développement plus long, profils plus seniors, etc.

Choisir d’investir dans la modularité ou d’accumuler de la dette technique est un choix qui doit être fait au niveau business et qui dépend notamment du budget dont vous disposez à un instant T.

Exemple #2 : choisir la dette technique pour respecter des deadlines

Il arrive parfois que vos besoins business et commerciaux imposent un deadline très court : par exemple : l’arrivée d’un évènement important ou une présentation à des investisseurs. Et qui dit deadline très court dit également difficulté (voire impossibilité) à garder un niveau de qualité élevé.

Car oui, nous savons qu’un développement optimal demande plus de temps de conception et plus de temps de réalisation. Alors si vous avez besoin de présenter votre projet à un événement dans deux mois et que votre équipe vous annonce qu’elle va avoir besoin de trois mois pour développer ce dont vous avez besoin, elle va devoir faire des concessions. Et où ces concessions peuvent-elles être faites ? Sur la qualité !

C’est une des raisons pour lesquelles accumuler de la dette technique peut s’avérer être un bon choix business. Cependant, il ne faut pas le faire n’importe comment !

Exemple #3 : la dépendance aux services tiers, accélérateur de dette technique

Un choix stratégique business peut être de faire reposer le projet sur l’interconnectivité avec d’autres services tiers. Ce choix peut, par exemple, permettre un gain de temps et d’argent à court terme.

Cependant, la connexion de ces outils tiers avec votre solution se fait par APIs : il s’agit de protocoles permettant d’échanger des données. Si l’un des services tiers met à jour ses APIs, cela signifie qu’une dette technique se crée indirectement chez vous puisqu’il va falloir mettre à jour votre propre solution pour prendre en compte les changements du service tiers dont elle dépend.

C’est pourquoi il faut faire attention à la dépendance que peuvent avoir vos actifs techniques à un trop grand nombre d’autres services sur lesquels vous n’avez pas la main.

Exemple #4 : accepter la dette technique dans le cadre d’un POC

Vous souhaitez lancer un POC (Proof of Concept) et vous avez un budget limité pour le développer. Car c’est précisément à cela qu’il va vous aider : lever des fonds.

Évidemment, vous allez réduire tous les coûts, y compris la qualité. Vous voulez quelque chose qui fonctionne, qui prouve la solidité de votre business model, et non pas une Rolls Royce des applications… du moins pas tout de suite.

Maintenant que vous savez ce qu’est une dette technique, vous savez aussi qu’il est très risqué de construire votre projet sur ce POC qui en a accumulé en masse. Alors, une fois les fonds levés, vous pourrez le mettre de côté (à la poubelle ?) car il aura rempli sa mission. Vous comptez bien repartir sur des bases saines.

Exemple #5 :  la dette technique et les profils junior

Prenons le cas où votre CTO est stagiaire, et en deuxième année d’une très bonne école.  Pas la peine de vous expliquer pourquoi votre projet va souscrire pas mal de dette technique, même s’il suit son cursus dans une très bonne école.

Pour éviter la dette technique liée au recrutement, vous avez besoin de profils expérimentés sur les postes critiques (CTO, lead dev) afin de vous épargner une grande partie de cette dette technique sans que cela vous coûte. Leur expérience permettra à votre projet d’éviter les pièges les plus courants. Ils sauront quand prendre de la dette, comment et quand la rembourser. Et plus important, ils seront conscients de la dette technique qu’ils prennent. Car le plus grand risque avec la dette technique, c’est de la souscrire sans que quiconque ne s’en rende compte.

Cependant, il est possible que vous ne disposiez pas toujours du budget pour faire appel à des profils seniors et que vous pensiez devoir embaucher des profils plus juniors. Dans ces cas-là, évaluer également la possibilité de prendre un CTO Part-time expérimenté pour épauler votre CTO plus junior.

Exemple #6 :  la dette technique pour dépasser la complexité d’un sujet

Vous souhaitez intégrer un algorithme à votre solution, ou une IA pour être à la mode, même si le terme est inexact. Et votre équipe vous fait part de ses inquiétudes face à l’ampleur de la tâche. Votre CTO vous propose donc un certain nombre de raccourcis ou de simplifications pour démarrer. Autrement, la première version de votre solution risque de ne sortir que sur un ordinateur quantique dans plus d’une décennie.

Vous accumulerez encore une fois, volontairement, de la dette technique qu’il faudra rembourser au fur et à mesure que votre produit évolue. Nous parlons ici d’IA à titre d’exemple, mais ce cas ne concerne évidemment pas uniquement les algorithmes. Il s’applique à tout projet ambitieux qu’il est souhaitable de réaliser par itérations successives.

Conclusion

La dette technique, souvent vue comme une entrave au développement fluide de projets, peut se transformer en un atout stratégique lorsqu’elle est gérée avec discernement. À travers les différents exemples que nous avons explorés, il devient clair que la dette technique n’est pas uniquement une contrainte subie, mais peut également être un choix délibéré, permettant de répondre à des impératifs business.

Qu'il s'agisse de faire face à l'évolution imprévisible d'un projet, de respecter des délais critiques, de s'adapter à des services tiers, ou encore de lancer rapidement un POC pour lever des fonds, la dette technique peut être un outil puissant lorsqu'elle est utilisée de manière réfléchie. Toutefois, cette approche nécessite une conscience aigüe des compromis réalisés et une planification rigoureuse pour assurer un remboursement efficace de cette dette au fur et à mesure de l'évolution du projet.

En fin de compte, le véritable enjeu est d'adopter une gestion proactive de la dette technique, en reconnaissant quand elle peut être bénéfique et en établissant des stratégies claires pour la rembourser. Cela inclut le recours à des profils expérimentés, la planification des mises à jour nécessaires et l'acceptation des compromis de manière consciente et contrôlée.

La clé est donc de ne pas craindre la dette technique, mais de l'utiliser comme un levier stratégique pour faire avancer votre business tout en gardant en vue l'objectif final : un produit solide et pérenne.