Dette technique en startup : quand la rembourser, quand l'assumer

Votre CTO vous dit que le code “tient avec du scotch”. Votre investisseur vous demande pourquoi vous ne livrez plus aussi vite qu’au début. Et vous, vous êtes coincé entre deux sprints qui n’en finissent pas de corriger des bugs que personne n’avait prévus. Bienvenue dans le problème de la dette technique — mal compris, mal géré, et pourtant inévitable.

La dette technique n’est pas un échec d’ingénierie

Le terme vient de Ward Cunningham, l’un des pères de l’Agile. Son idée originale était simple : parfois, on choisit délibérément une solution imparfaite pour aller plus vite, avec l’intention de la corriger plus tard. C’est une métaphore financière — comme un emprunt, la dette technique a un coût (les intérêts) qui s’accumule si on ne la rembourse pas.

Le problème, c’est que la plupart des startups n’ont pas contracté cette dette délibérément. Elle s’est accumulée par manque de temps, de ressources, ou de vision à long terme. Et là, la métaphore change : ce n’est plus un emprunt consenti, c’est un découvert qu’on n’a pas vu venir.

Il faut donc distinguer deux types de dette :

La dette stratégique est celle que vous choisissez consciemment. Vous savez que votre architecture de base de données ne tiendra pas au-delà de 10 000 utilisateurs, mais vous avez 200 utilisateurs aujourd’hui et six mois pour valider votre modèle. Vous l’assumez, vous la documentez, vous planifiez son remboursement.

La dette subie est celle qui s’accumule sans décision explicite — du code dupliqué, des dépendances non maintenues, une absence de tests, des secrets d’API hardcodés dans le repo. Elle ne rapporte rien et coûte cher dès qu’on touche au système.

La première est un outil. La seconde est un risque opérationnel.

Ce que la dette technique coûte vraiment

Les équipes tech ont tendance à parler de dette technique en termes abstraits — “le code est sale”, “c’est difficile à maintenir”. Ce langage ne parle pas aux fondateurs non-techniques, et c’est un problème.

Traduisez-le en termes business : une dette technique élevée, c’est une vélocité de développement qui diminue de 20 à 40 % sur 18 mois selon les études de McKinsey sur les organisations engineering. C’est aussi un risque de sécurité réel — les failles les plus exploitées viennent rarement de zero-days sophistiqués, mais de dépendances obsolètes et de configurations négligées. Et c’est un frein au recrutement : les bons ingénieurs fuient les codebases chaotiques.

Il y a aussi un effet moins visible : la dette technique crée de l’incertitude dans les estimations. Quand votre équipe ne sait plus combien de temps prendra une feature parce que “ça dépend de ce qu’on va trouver en chemin”, vous avez perdu le contrôle de votre roadmap. Et perdre le contrôle de sa roadmap en early-stage, c’est perdre le contrôle de son go-to-market.

Selon votre stade, la bonne décision change radicalement

Pre-seed et seed : assumez, mais documentez

À ce stade, votre priorité absolue est la validation. Vous n’avez pas les ressources pour construire une architecture parfaite, et vous ne devriez pas essayer. Le pattern classique de l’erreur ici, c’est le fondateur technique qui passe trois mois à construire une infrastructure “scalable” avant d’avoir un seul client payant.

La règle pratique : construisez pour 10x votre taille actuelle, pas pour 100x. Si vous avez 50 utilisateurs, construisez pour 500. Pas pour 50 000. Chaque heure passée à over-engineer est une heure de moins sur la validation produit.

Ce que vous devez faire en revanche, c’est documenter vos choix. Pas dans un wiki que personne ne lit — dans le code lui-même, en commentaires, en ADR (Architecture Decision Records) simples. Quand vous lèverez des fonds et que des ingénieurs seniors rejoindront l’équipe, ils auront besoin de comprendre pourquoi les choses sont comme elles sont. “On a fait ça vite” n’est pas une explication.

Série A : le moment du remboursement sélectif

La levée de série A change l’équation. Vous avez maintenant des ressources, une équipe qui grandit, et des attentes de croissance qui vont mettre votre système sous pression. C’est le moment de rembourser — mais pas tout.

La tentation est de tout refaire. C’est presque toujours une erreur. Les rewrites complets sont longs, risqués, et souvent décevants (Joel Spolsky l’a documenté dès 2000 dans son article “Things You Should Never Do”). Ce que vous devez faire, c’est identifier les points de friction critiques — les parties du système qui ralentissent le plus votre équipe ou qui présentent les risques les plus élevés — et les traiter en priorité.

Un framework simple : classez votre dette en trois catégories. La dette qui bloque la croissance (vous ne pouvez pas onboarder de nouveaux clients sans intervention manuelle, par exemple). La dette qui crée un risque de sécurité ou de conformité (RGPD, données personnelles, authentification). La dette qui ralentit l’équipe sans impact immédiat sur le produit. Traitez dans cet ordre.

Ce que votre CTO devrait vous dire (et comment l’entendre)

Un bon CTO ne vous dit pas “on a de la dette technique”. Il vous dit “voici les trois choses qui nous coûtent le plus cher en ce moment, voici ce que ça nous coûte en temps d’ingénierie par semaine, et voici ce qu’il faudrait investir pour les corriger”.

Si vous n’avez pas cette conversation avec votre équipe technique, c’est le premier chantier à ouvrir. Pas pour blâmer, mais pour piloter. La dette technique est un actif au bilan de votre produit — elle doit être visible, mesurée, et gérée comme telle.

Du côté des fondateurs non-techniques, le piège symétrique existe aussi : ignorer le sujet jusqu’à ce qu’il devienne une crise, ou au contraire paniquer à chaque alerte de l’équipe tech. Ni l’un ni l’autre n’est utile. Ce qu’il faut, c’est une cadence régulière — une revue mensuelle ou trimestrielle de l’état de la dette, avec des métriques simples : temps moyen pour livrer une feature, nombre d’incidents en production, couverture de tests sur les parties critiques.

Ce qu’il faut vraiment faire

Commencez par un audit honnête. Pas un audit de code exhaustif — une conversation structurée avec votre équipe technique pour identifier les cinq zones du système qui posent le plus de problèmes. Donnez-leur le temps de le faire sérieusement, pas entre deux sprints.

Ensuite, traduisez en impact business. Pour chaque zone identifiée, estimez le coût en temps d’ingénierie par mois et le risque associé. Ce travail de traduction est souvent révélateur : certaines dettes que l’équipe tech considère comme critiques ont un impact business faible, et inversement.

Enfin, intégrez le remboursement dans votre cadence normale. La règle des 20 % — allouer un cinquième du temps d’ingénierie au remboursement de dette et à l’amélioration de l’infrastructure — est un point de départ raisonnable. Elle ne fonctionnera que si elle est protégée : si les 20 % sont systématiquement sacrifiés dès qu’une feature urgente arrive, vous n’avez pas une politique de gestion de la dette, vous avez une intention.

La vraie question n’est pas “avons-nous de la dette technique ?” — toutes les startups en ont. C’est “est-ce que nous la pilotons, ou est-ce qu’elle nous pilote ?” La différence entre les deux, c’est souvent la différence entre une équipe qui accélère et une équipe qui s’enlise.