Toute startup a de la dette technique, et l'essentiel était le bon choix. La question n'est pas comment l'éliminer — c'est quelles parties facturent des intérêts que vous ne pouvez plus payer.
Délais de livraison
Risque opérationnel
Registre de dette
La dette technique a une mauvaise réputation qu'elle ne mérite pas entièrement. Prendre un raccourci pour valider une idée plus vite est généralement correct — l'alternative est de construire soigneusement vers quelque chose dont personne ne voulait. L'échec n'est pas de contracter la dette ; c'est de ne jamais vérifier le taux d'intérêt.
Les quatre types, et seulement deux comptent
| Type | Exemple | Verdict |
|---|---|---|
| Délibérée et éphémère | Logique en dur pour tester la demande, retirée ensuite | Correct — c'est l'outil qui fonctionne |
| Délibérée et permanente | Raccourci pris sciemment, jamais revisité | Dangereux — les intérêts s'accumulent en silence |
| Accidentelle | Personne ne connaissait mieux à l'époque | Normal — corriger quand cela commence à coûter |
| Cosmétique | Nommage, formatage, préférences de structure | Ignorer complètement |
Comment savoir que c'est devenu trop
Il n'y a pas de seuil absolu ; la dette n'a de sens que relativement à ce que vous essayez de faire. Mais ces signaux indiquent de façon fiable que les intérêts sont devenus insoutenables :
- Les estimations ne cessent d'augmenter pour des fonctionnalités de taille comparable — le signal quantitatif le plus clair
- L'équipe dit régulièrement « on ne peut pas faire ça avec l'architecture actuelle » à propos de demandes ordinaires
- Les bugs se concentrent dans les mêmes modules, encore et encore
- L'intégration d'un nouvel ingénieur prend des mois plutôt que des semaines
- Les gens évitent de toucher certains fichiers, et tout le monde sait lesquels
- Les déploiements sont groupés et planifiés parce qu'ils sont risqués
Quoi rembourser, et quand
La dette mérite d'être remboursée quand elle bloque quelque chose de précis, pas par principe. Trois règles qui fonctionnent :
- Remboursez la dette située sur la route à venir. Si les deux prochains trimestres passent par un module, nettoyez-le avant d'y construire. La dette dans du code que vous ne toucherez pas ne coûte rien.
- Remboursez immédiatement la dette qui touche l'argent, les données ou l'authentification, quelle que soit la roadmap — les défaillances y sont irrécupérables et pas seulement agaçantes.
- Refactorez de façon opportuniste. Améliorez ce que vous modifiez déjà plutôt que de planifier des projets de nettoyage séparés, qui sont les premiers coupés sous pression.
Le budget qui marche
Allouer une fraction fixe de la capacité — couramment 10 à 20 % — à la maintenance maintient la dette à peu près stable. En dessous, elle s'accumule ; nettement au-dessus, vous dorez au lieu de livrer. Ce qui compte plus que le chiffre exact, c'est qu'il soit protégé : une capacité sacrifiée à chaque échéance n'existe pas.
L'objectif n'est pas zéro dette technique. C'est une dette que vous avez choisie, que vous connaissez, et que vous pourriez rembourser si la roadmap l'exigeait.
Quoi dire aux investisseurs
Les fondateurs tentent souvent de cacher la dette pendant la due diligence. Cela se retourne contre eux : la diligence la trouve, et la découverte coûte plus cher en négociation que la divulgation n'aurait coûté. La position la plus forte est un registre écrit — quelle dette existe, ce qu'elle bloque, ce que coûte la remédiation. Une équipe capable de l'articuler paraît compétente ; une équipe prétendant à une base de code propre paraît soit naïve, soit évasive.
Prioriser la dette technique avec des preuves
La revue de code examine l'implémentation ; la revue d'architecture, les frontières et le fonctionnement. Partez d'une décision métier : le système supportera-t-il la prochaine livraison ou de nouveaux clients ? Évaluez conséquences, fréquence observée et effort. Traitez séparément les failles actives touchant sécurité ou intégrité des données.
| Rendre la décision mesurable | Les preuves à convenir avant de commencer |
|---|---|
| Délais de livraison | Relier une modification aux modules, attentes de revue et lacunes de tests. Comparer des changements similaires avant et après correction. |
| Risque opérationnel | Examiner incidents, traces et restaurations. Un accès absent signifie non vérifié, pas réussi. |
| Registre de dette | Consigner preuves, parcours affecté, responsable, fourchette d'effort et test de résolution. |
Aucun pourcentage universel de maintenance ne stabilise automatiquement la dette. Allouez la capacité selon les risques et la feuille de route, puis réévaluez-la. Une réécriture reste une option à étudier, pas la conclusion obligatoire d'un audit.
Questions fréquentes
Quelle quantité de dette technique est normale pour une startup ?
Une quantité importante, et c'est généralement correct — la vitesse en phase précoce vaut plus que la finition en phase précoce. Le problème n'est pas la quantité mais de savoir si elle est connue, délibérée, et confinée à des zones qui ne bloquent pas la roadmap et ne touchent ni l'argent ni les données.
Quel pourcentage du temps d'ingénierie consacrer à la dette technique ?
Couramment 10 à 20 % de la capacité, protégée plutôt que nominale. Moins et la dette s'accumule plus vite qu'elle n'est remboursée ; nettement plus et vous améliorez généralement du code qui n'en a pas besoin. Le chiffre exact compte moins que sa capacité à survivre à la pression des échéances.
Faut-il mettre les fonctionnalités en pause pour corriger la dette technique ?
Presque jamais. Les projets de nettoyage dédiés sont difficiles à justifier, difficiles à finir, et les premiers annulés. L'exception est la dette qui perd activement de l'argent ou des données — celle-là arrête tout jusqu'à sa correction.
Vous ne savez pas quelle dette compte vraiment ?
Nous la trions au regard de votre roadmap — ce qui vous bloque, ce qui coûte de l'argent, ce qu'il faut laisser tranquille.
Pour aller plus loin
Réparer un MVP en panne (sans tout recommencer)
Presque tout fondateur face à un MVP cassé demande s'il faut le réécrire. Presque à chaque fois, la réponse est non — et la raison est arithmétique, pas sentimentale.
Audit d'architecture système : quand il en faut un et ce qu'il trouve
Un audit d'architecture n'est pas un avis sur votre stack technique. C'est une carte des endroits où le système casse sous le plan que vous avez réellement.