Dette technique : le guide du fondateur non technique (4 types, diagnostic)

Un mercredi de novembre, dans un bureau à Paris, le fondateur d’une fintech en Série A a entendu la même phrase pour la troisième fois du mois : « il faut qu’on arrête de faire des features pendant six semaines pour rembourser la dette technique ». C’était la première fois qu’il comprenait que ce problème était le sien, pas celui de son tech lead. Les investisseurs demandaient un plan produit pour les douze prochains mois. L’équipe ingénierie demandait six semaines d’arrêt. Les deux demandes entraient en collision, et la décision lui revenait.

C’est précisément le moment où la plupart des fondateurs non techniques découvrent ce qu’est la dette technique. Trop tard pour l’éviter, trop tôt pour comprendre ce qu’on leur propose.

Ce qu’est la dette technique, en langage de fondateur

La dette technique est tout choix d’ingénierie qui échange de la qualité future contre de la vitesse aujourd’hui. Vous écrivez le code plus vite maintenant, en sachant que vous paierez la différence plus tard : en maintenance, en bugs, en refactor, ou par un nouvel ingénieur qui mettra trois semaines à comprendre ce qui se passe.

Le terme a été forgé par Ward Cunningham dans les années 90, et la métaphore est précise. Comme la dette financière, la dette technique génère des intérêts. Chaque release construit sur une fondation fragile ajoute un peu plus de friction, un peu plus de temps, un peu plus de risque. Si vous ne payez jamais, les intérêts dévorent la vélocité de l’équipe. Si vous payez toujours, vous laissez de la vélocité sur la table qui aurait pu être investie en produit.

Ce qui compte pour le fondateur n’est pas la définition académique. C’est de comprendre que la dette technique n’est jamais une surprise créée par l’équipe. Elle est le sous-produit de décisions prises, explicitement ou implicitement, pour que vous puissiez livrer la démo investisseur, signer le premier client, lancer le pilote avant le concurrent. La dette n’est pas apparue par incompétence. Elle est apparue parce que quelqu’un a priorisé la vitesse. Probablement vous.

Pourquoi cela devient votre problème, pas celui du CTO

Trois choses changent quand la dette technique cesse d’être une conversation d’ingénierie et devient une conversation d’entreprise.

La première, c’est le rythme de release. Les équipes avec une dette lourde sentent chaque feature ralentir. Ce qui sortait en deux semaines commence à sortir en quatre. Pas parce que les ingénieurs sont devenus moins bons. Parce qu’une part croissante de leur temps est passée à contourner les pièges que l’ancien code a laissés.

La deuxième, c’est le risque de recrutement. Les équipes à dette lourde sont difficiles à élargir. Quand vous voulez doubler le squad pour accélérer, vous découvrez que le nouvel ingénieur a besoin de six semaines avant de pouvoir ouvrir une pull request sans casser trois choses. Votre taux d’onboarding s’effondre. Vous pensez que le recrutement coûte cher ; en réalité, c’est le ramp-up qui coûte cher.

La troisième, c’est le risque de due diligence. Dans une levée Série A ou une acquisition, l’investisseur engage un cabinet de due diligence technique. Il passe quatre jours dans votre dépôt, parle à l’équipe, et produit un document qui dit si la base de code soutient les vingt-quatre prochains mois ou non. Si la dette est trop haute, l’investisseur peut demander une décote sur la valorisation. Il peut demander des jalons de « remboursement de dette » avant la tranche suivante. Dans de rares cas, il peut se retirer.

Aucun de ces trois effets n’est technique. Tous sont business. Et tous remontent au fondateur tôt ou tard.

Les quatre types de dette technique qui comptent

Martin Fowler, l’un des chercheurs qui a le plus écrit sur le sujet, a créé une matrice à deux axes qui sépare les quatre situations où apparaît la dette technique. Pour le fondateur, la matrice est utile parce qu’elle répond à une question unique et importante : mon équipe fait-elle ça exprès, ou le fait-elle par négligence ? Cette question sépare la dette « stratégique » (que vous pouvez être content de porter) de la dette « dangereuse » (qui vous coûte de l’argent en silence).

1. Délibérée et prudente : « on sait ce qu’on fait, et on paiera plus tard »

L’équipe a choisi, en pleine conscience, d’écrire du code plus simple et plus rapide parce qu’elle devait arriver quelque part en premier. Peut-être la démo TechCrunch, peut-être le pilote avec un client stratégique, peut-être le release avant les vacances. Elle a documenté le choix. Elle sait où est le raccourci. Elle a une date, même approximative, pour revenir le faire correctement.

C’est la dette que vous voulez dans l’entreprise pendant les dix-huit premiers mois. Sans elle, vous n’atteignez pas le PMF à temps.

2. Délibérée et imprudente : « on sait ce qu’on fait, et on ne paiera jamais »

L’équipe a pris le raccourci, sait que c’est un raccourci, et est convaincue qu’il reste le temps de casser trois choses avant le release. Souvent, cette dette vient du fondateur lui-même : « j’en ai besoin pour vendredi, débrouillez-vous ». L’équipe avertit que c’est une mauvaise idée. Vous dites « on corrigera plus tard ». Ce n’est jamais corrigé.

C’est le type le plus courant et le plus cher. Pas parce qu’il est le pire techniquement, mais parce que le « plus tard » n’arrive jamais. Et parce qu’il s’accumule en silence : vous ne voyez pas la dette au bilan. Vous ne voyez que la feature livrée.

3. Accidentelle et prudente : « maintenant on sait comment on aurait dû faire »

L’équipe a fait du mieux qu’elle savait à l’époque, avec l’information qu’elle avait. Elle en a appris davantage sur le problème, sur l’architecture, sur les utilisateurs, et aujourd’hui elle ferait différemment. Ce n’est pas de la négligence, c’est la courbe d’apprentissage naturelle de tout nouveau produit.

Cette dette, vous l’aurez toujours. La bonne question pour ce type n’est pas « comment l’éviter ? ». C’est « quand est-ce que je reviens la refaire ? ». Et la réponse honnête est : quand la feature qui repose sur la mauvaise fondation commencera à coûter plus cher à faire évoluer qu’à réécrire.

4. Accidentelle et imprudente : « on ne sait même pas que c’est de la dette »

L’équipe ne sait pas qu’elle a choisi un mauvais chemin. Elle n’a rien documenté. Elle découvrira le problème la prochaine fois qu’elle devra toucher ce bout de code, et la prochaine personne qui y touchera souffrira sans comprendre pourquoi. C’est la catégorie la plus dangereuse parce qu’elle est invisible. Vous vous en apercevez seulement quand quelqu’un démissionne et que la connaissance s’en va avec lui, ou quand le nouveau dev senior ouvre le dépôt et inspire profondément.

La différence entre les types 2 et 4 est l’endroit où vit le travail du fondateur. Le type 2 se trace en parlant à l’équipe. Le type 4 demande une due diligence interne pour être trouvé, et presque aucun fondateur n’en fait avant que la facture arrive.

Le diagnostic en quatre questions

Vous n’avez pas besoin de feindre une profondeur technique pour découvrir combien de dette votre produit porte. Vous avez besoin de quatre questions, de vingt minutes avec chaque ingénieur, et du courage d’écouter les réponses sans vous défendre.

Question 1 : « Quel est le morceau de code que personne ne veut toucher ? »

Toute base de code en a un. Ce peut être le module de paiement, le système d’authentification, le moteur de calcul des commissions. Ce que vous cherchez, c’est un nom propre. Si trois ingénieurs répondent la même chose, c’est le cœur de votre dette accidentelle imprudente.

Question 2 : « Combien de fois lors du dernier sprint avons-nous fait un workaround parce que la bonne solution aurait pris trop de temps ? »

Cette question détecte la dette délibérée, celle du type 2. La réponse saine est « une fois, et on a ouvert un ticket pour revenir ». La réponse alarmante est « trois ou quatre, sans tickets ». Un workaround sans ticket est de la dette qui ne sera pas payée.

Question 3 : « Si on voulait doubler l’équipe demain, combien de semaines avant que le nouvel ingénieur ouvre sa première PR ? »

Les équipes saines répondent une à deux semaines. Les équipes à forte dette répondent quatre à huit. Au-delà, votre dette n’est plus un problème de produit. C’est un problème de scale d’équipe.

Question 4 : « Si on perdait l’ingénieur X, quel morceau du produit deviendrait orphelin ? »

Cette question est le croisement entre dette technique et bus factor. La connaissance non documentée est de la dette accidentelle imprudente, et elle disparaît avec la personne. Si la réponse est « la moitié », vous avez deux problèmes, pas un.

Les quatre questions cumulées donnent une carte raisonnable de l’état de votre base de code. Ce n’est pas une due diligence technique formelle. Mais c’est suffisant pour décider, la tête froide, si l’équipe a besoin de six semaines d’arrêt pour rembourser de la dette ou si elle demande six semaines d’arrêt pour réécrire quelque chose qui fonctionne.

Quand payer, quand porter, quand ignorer

Toute dette ne doit pas être payée. C’est l’erreur que la plupart des fondateurs font dans la direction opposée : après avoir compris le concept, ils s’inquiètent de « remettre la dette à zéro ». Ça ne marche pas comme ça.

Portez la dette qui est stable. Si un bout de code est désordonné mais que personne n’a eu à y toucher depuis six mois, ne touchez pas. La règle est simple : la dette ne vous coûte que si vous payez des intérêts. Le code que personne n’ouvre n’a pas d’intérêts.

Remboursez la dette qui est sur le chemin de la roadmap. Si le prochain trimestre exige des changements sur le module X, et que le module X est un capharnaüm, il vaut mieux payer la dette d’abord. Vous alliez payer le refactor de toute façon, incorporé dans la feature, sans visibilité.

Réécrivez (et non remboursez) la dette qui bloque la croissance. Si le système d’authentification ne supporte pas plus de mille utilisateurs simultanés, ou si le moteur de calcul met trois heures à tourner sur cinq mille clients, ce n’est pas de la dette. C’est de l’architecture qui doit être remplacée. Vous ne payez pas d’intérêts. Vous êtes dans une impasse. La conversation se transforme en réécriture de logiciel, qui est une décision différente et beaucoup plus chère.

L’heuristique que nous utilisons en travaillant avec des fondateurs non techniques : regardez la dette par le côté roadmap, pas par le côté code. Qu’est-ce qui va être touché dans les quatre-vingt-dix prochains jours, et qui est difficile à toucher ? C’est ça qui vaut la peine d’être payé. Le reste est cosmétique.

La conversation qui doit avoir lieu avec l’équipe

La mauvaise conversation commence ainsi : « pouvez-vous me donner une estimation de combien de dette technique on a ? ». Vous n’obtiendrez pas de réponse utile. Personne ne sait quantifier la dette en heures ou en euros avec précision. L’équipe va lancer un chiffre, vous allez douter du chiffre, et la conversation ne mènera nulle part.

La bonne conversation commence autrement. Prenez la roadmap des quatre-vingt-dix prochains jours. Pour chaque item, demandez : « cet item touche-t-il un morceau où on a de la dette qui vaudrait la peine d’être réglée avant ? ». Si la réponse est oui pour trois ou quatre items dans le même module, c’est là que vous voulez investir un sprint de refactor avant de continuer.

Cette conversation fonctionne parce qu’elle amarre la dette à ce qui est en construction. Ce n’est pas « arrêtez tout et réparez le passé ». C’est « investissons une semaine maintenant pour que le prochain trimestre avance plus vite ». Les investisseurs comprennent ce langage. Les cofondateurs aussi. Vous pouvez le défendre au board.

Et cela a un effet secondaire : ça oblige l’équipe à pointer de la dette spécifique, pas de la dette générique. « On a de la dette dans le module de paiement qui va peser sur les trois prochains projets » est une phrase actionnable. « On a beaucoup de dette technique » ne l’est pas.

Ce qui change quand vous externalisez le développement

Si vous n’avez pas d’équipe interne, et que votre produit est construit par une software house ou un partenaire de développement, la dynamique de la dette change sur deux points importants.

Le premier : la dette accidentelle imprudente est plus difficile à détecter. L’équipe externe n’est pas sur votre Slack tous les jours, donc la question « quel est le bout de code que personne ne veut toucher ? » doit être posée plus souvent, et la réponse doit venir avec des captures, des commits, des exemples. Faites confiance aux données, pas aux sensations.

Le second : la dette délibérée prudente est plus facile à porter, parce qu’un partenaire expérimenté vous dira, avant chaque release, ce qui est laissé en arrière et pourquoi. Les bons partenaires le font par habitude. Les mauvais partenaires livrent le produit et disparaissent. La différence entre les deux apparaît exactement dans cette transparence : savez-vous, oui ou non, où se trouve la dette quand le release sort ?

La règle que nous appliquons quand nous construisons du logiciel pour des fondateurs non techniques est simple : toute décision de prendre une dette délibérée prudente doit être consignée en une phrase sur la PR, et doit apparaître dans le document mensuel de statut. Si vous n’avez pas ça, vous êtes dans le noir. Ce n’est pas que le partenaire soit mal intentionné ; c’est que le processus est mal conçu.

Quand la dette technique devient un problème de coût de maintenance

Le coût mensuel de maintenance de votre produit est, en partie, le paiement des intérêts de la dette que vous avez prise. Si votre équipe passe soixante pour cent du temps à « réparer des choses » et quarante pour cent à « construire des choses », la plus grande partie de ces soixante pour cent ce sont des intérêts, pas des bugs.

Les équipes saines tournent autour de quatre-vingts-vingt (quatre-vingts à construire, vingt à réparer). Les équipes à dette lourde arrivent à l’inverse, soixante-quarante. Les équipes en état critique atteignent vingt-quatre-vingts, et à ce stade vous ne construisez plus de produit, vous maintenez un squelette en vie pendant que vos concurrents livrent des features.

Le ratio est l’une des choses les plus faciles à mesurer et l’une des plus sous-estimées. Si vous ne savez pas où vous en êtes, demandez à l’équipe. Elle le sait. Probablement depuis des mois.

Questions fréquentes

Qu’est-ce que la dette technique ?
C’est tout choix d’ingénierie qui échange de la qualité future contre de la vitesse aujourd’hui. Comme une dette financière, elle génère des intérêts : chaque release fait sur une fondation fragile ajoute un peu plus de temps, de friction et de risque. Elle peut être délibérée (vous avez choisi le raccourci) ou accidentelle (l’équipe a appris plus tard qu’elle aurait pu faire différemment).

Quelle est la différence entre dette technique et dette tech ?
Aucune. Les deux termes sont utilisés comme synonymes dans l’industrie. « Dette technique » est la version originale, légèrement plus formelle ; « tech debt » est l’abréviation que les ingénieurs utilisent en stand-up.

Quels sont les types de dette technique ?
La matrice la plus utilisée est celle de Martin Fowler, qui croise deux axes : délibérée/accidentelle et prudente/imprudente. Cela donne quatre types : délibérée et prudente (vous avez pris le raccourci et vous allez payer), délibérée et imprudente (vous avez pris le raccourci et vous ne paierez pas), accidentelle et prudente (vous avez appris plus tard et refaites quand ça vaut), accidentelle et imprudente (l’équipe ne sait même pas qu’il y a de la dette là). Les types 2 et 4 sont ceux qui blessent le plus le fondateur non technique.

Combien de temps faut-il pour rembourser de la dette technique ?
Il n’y a pas de réponse unique. Cela dépend de la taille de la base, du type de dette et de la part de la roadmap future qui la traverse. Une règle pratique que nous utilisons : si une zone spécifique bloque trois ou quatre items des quatre-vingt-dix prochains jours, investissez une à deux semaines de sprint dédié dessus avant de continuer. Les tentatives de « rembourser toute la dette » en un seul effort fonctionnent rarement : l’équipe perd des mois et le backlog produit gèle.

Comment mesure-t-on la dette technique ?
On ne la mesure pas avec précision. Vous pouvez l’approcher via le diagnostic en quatre questions ci-dessus, via le ratio construire/réparer (combien du temps de l’équipe se passe à réparer plutôt qu’à construire), et via le temps de ramp-up d’un nouvel ingénieur. Aucun n’est exact, mais ensemble ils vous disent si votre dette est en territoire sain ou dangereux.

La plupart des fondateurs non techniques apprennent le concept de dette technique au pire moment possible : quand l’équipe demande d’arrêter, quand l’investisseur demande d’accélérer, ou quand une due diligence pointe un problème que personne n’a vu venir. Le fondateur qui décide bien à ce moment-là n’est pas celui qui comprend le plus de code. C’est celui qui sait lire la dette comme une décision business et poser à l’équipe la bonne question : qu’est-ce qui, dans les quatre-vingt-dix prochains jours, est plus difficile parce qu’on n’a pas encore payé ?

Ce fondateur n’a pas besoin d’être technique. Il a besoin d’être clair.