Dette technique d'un MVP : ce qu'on accepte volontairement, et ce qu'on refuse dès le premier sprint
« Zéro dette technique » est un argument commercial, pas un objectif d'ingénierie. Un MVP livré vite en contient forcément. Voici comment séparer la dette qu'on rembourse en trois jours de celle qui vous coûtera une réécriture, et la liste de ce qu'on ne négocie jamais, même sous contrainte de délai.
title: "Dette technique d'un MVP : ce qu'on accepte volontairement, et ce qu'on refuse dès le premier sprint" seoTitle: "Dette technique d'un MVP : quoi accepter" description: "« Zéro dette technique » est un argument commercial, pas un objectif d'ingénierie. Un MVP livré vite en contient forcément. Voici comment séparer la dette qu'on rembourse en trois jours de celle qui vous coûtera une réécriture, et la liste de ce qu'on ne négocie jamais, même sous contrainte de délai." seoDescription: "La dette technique qu'un MVP peut assumer, celle qui impose une réécriture, et la courte liste de ce qu'on refuse dès le premier sprint." date: "2026-09-23" author: "Équipe Raicode" tags: ["mvp", "saas", "architecture", "développement"] category: "SaaS & MVP" keywords: ["dette technique MVP", "dette technique SaaS", "refactoring MVP", "zéro dette technique", "qualité de code MVP", "architecture MVP startup", "raccourcis techniques startup", "rembourser la dette technique"]
Votre développeur vous annonce qu'il lui faut trois semaines de refactoring avant d'ajouter la fonctionnalité que deux prospects réclament. Vous n'avez pas trois semaines : vous avez un rendez-vous commercial dans dix jours et six mois de trésorerie. La conversation qui suit ressemble toujours à la même — lui parle de dette technique, vous entendez « perfectionnisme », et personne dans la pièce n'a de critère pour trancher. Le problème n'est pas le désaccord. Le problème est que vous discutez d'un bloc indifférencié appelé « dette technique » alors qu'il contient deux choses qui n'ont rien à voir : des raccourcis qu'on rembourse en trois jours quand le produit trouve son marché, et des décisions qui ne se rattrapent qu'en réécrivant.
Le marché n'aide pas. Plusieurs agences françaises vendent aujourd'hui du « zéro dette technique » comme argument de différenciation. C'est une promesse commerciale confortable, parce qu'elle est invérifiable par l'acheteur et flatteuse pour le vendeur. Elle est surtout fausse dans les deux sens : un MVP livré en huit semaines contient nécessairement de la dette, et une équipe qui n'en prend aucune ne livre pas un MVP, elle livre un produit de version 2 avec deux trimestres de retard. La bonne question n'a jamais été « combien de dette ». Elle est : cette dette-là, saurons-nous la rembourser, et à quel prix ?
Une dette n'est un problème que si elle capitalise
Le mot est bien choisi et mal utilisé. Une dette a un principal — le travail à refaire — et un intérêt : ce qu'elle vous coûte chaque semaine tant que vous ne l'avez pas remboursée. Les équipes ne se noient jamais à cause du principal. Elles se noient parce que l'intérêt devient supérieur à leur capacité de livraison.
Trois critères suffisent à classer un raccourci, et ils se posent avant de l'accepter, pas après.
Le coût de remboursement est-il connu ? Dupliquer une fonction de calcul de TVA dans trois fichiers coûte une demi-journée à refactorer, et ce chiffre ne changera pas dans six mois. Stocker les données de tous vos clients dans les mêmes tables sans discriminant coûte, selon le volume, entre trois semaines et une migration en clientèle avec fenêtre d'interruption. La première dette a un prix affiché, la seconde a un prix qui dépend du nombre de clients que vous aurez entre-temps.
Le périmètre est-il contenu ? Une dette locale se rembourse sans toucher au reste. Une dette structurelle — un modèle de données, un format d'identifiant, un choix d'authentification — irrigue tout le code qui vient après elle. Chaque écran écrit par-dessus en fait une dépendance supplémentaire. C'est ce qui explique la sensation classique en mois six : rien n'a empiré, on a seulement écrit trois mille lignes de plus au-dessus du même raccourci.
L'intérêt augmente-t-il avec l'usage ? Une absence de tests sur un back-office utilisé par vous seul coûte à peu près zéro. Une absence de tests sur le parcours de paiement coûte un incident client par déploiement dès que vous en avez vingt. La même dette technique n'a pas le même intérêt selon l'endroit où elle se trouve.
Un raccourci qui passe les trois critères est un arbitrage. Un raccourci qui en échoue un seul est une décision de conception qu'on est en train de prendre par défaut, en se racontant qu'on l'a prise par vitesse.
Ce qu'un MVP peut assumer sans hésiter
Voici ce que nous laissons volontairement dans un MVP livré en six à huit semaines, et pourquoi le remboursement reste bon marché.
La duplication. Trois versions légèrement différentes du même formulaire valent mieux qu'une abstraction inventée avant de savoir ce qui varie. La factorisation prématurée est la dette la plus chère du lot, parce qu'elle vous impose une structure fausse que le code suivant devra contourner. On duplique, on attend le troisième cas réel, on factorise à ce moment-là — et cette fois-ci on sait sur quel axe.
Le back-office. Pas d'interface d'administration au premier sprint. Les opérations internes — créer un compte, prolonger un essai, rembourser — se font en requête SQL ou en script, exécutés par vous. Une interface d'administration représente facilement 15 à 20 % du budget d'un MVP pour servir trois personnes. Elle se construit quand le support devient un poste, pas avant.
Les tests d'interface. On ne teste pas l'affichage d'un produit dont les écrans changeront quatre fois en deux mois. Les tests d'interface écrits trop tôt sont supprimés avant d'avoir attrapé un seul bug, et entre-temps ils ont freiné chaque itération. La logique métier, elle, se teste dès le premier jour : elle, elle ne bougera pas.
L'absence d'infrastructure asynchrone. Pas de file d'attente, pas de système de tâches distribué. Un envoi d'email bloquant et une tâche planifiée toutes les cinq minutes tiennent très loin. Le jour où une opération dépasse dix secondes, on introduit une file — et ce jour-là, le travail consiste à déplacer trois appels de fonction, pas à redessiner l'application.
Le monolithe. Une seule application, une seule base, un seul déploiement. Le découpage en services avant d'avoir des utilisateurs multiplie les surfaces d'erreur pour un bénéfice qui n'existe qu'à une échelle que vous n'avez pas. Cette dette-là a l'avantage rare de se rembourser progressivement, module par module.
Les performances non optimisées. Requêtes non optimisées, pas de cache, pas d'index au-delà des évidents. À quelques milliers de lignes, une base Postgres correctement structurée pardonne presque tout. Le jour où une page ralentit, un index résout neuf cas sur dix en une heure.
Le point commun de ces six raccourcis : chacun se rembourse sans rien casser d'autre, et leur coût de remboursement est connu à l'avance. Ce sont eux qui permettent de tenir un calendrier de six à huit semaines. Si votre prestataire vous vend un MVP en refusant ces arbitrages, vérifiez son chiffrage — c'est l'une des variables qui creusent l'écart entre des devis de 12 et 58 k€ pour le même brief.
Ce qu'on refuse dès le premier sprint
La liste suivante est courte. Elle est courte exprès : c'est parce qu'elle est courte qu'elle est tenable sous contrainte de délai. Tout ce qui s'y trouve partage la même propriété — on ne le rattrape pas sans migration, et son coût de remboursement croît avec le nombre de clients.
L'isolation des données entre clients. Chaque table métier porte son identifiant de compte dès la première migration, et l'isolation est appliquée au niveau de la base, pas de la vue. Ajouter cette colonne le jour où vous avez quarante clients suppose de reprendre toutes les requêtes existantes en espérant n'en oublier aucune — et l'oubli qui reste est une fuite de données d'un client vers un autre. C'est, avec la facturation, l'une des deux fondations d'un SaaS qu'on ne rattrape pas après le MVP.
L'authentification et le modèle de permissions. Pas forcément riche : un rôle propriétaire et un rôle membre suffisent largement au départ. Mais le contrôle d'accès doit être vérifié côté serveur, à un seul endroit, dès le premier écran. Une application dont les permissions sont vérifiées dans l'interface a une faille par page, et les corriger après coup suppose de relire chaque route.
Les migrations de schéma versionnées. Aucun changement de base appliqué à la main en production. C'est une contrainte de dix minutes au premier sprint et le seul moyen de garder un environnement reproductible ensuite. Les projets que nous reprenons et dont le schéma de production diffère du schéma de développement coûtent systématiquement une semaine avant même de comprendre l'existant.
Les secrets hors du dépôt. Clés d'API, identifiants de base, jetons de paiement : jamais dans le code, jamais dans un fichier commité. Une clé poussée dans l'historique Git y reste après suppression, et la révoquer six mois plus tard suppose de savoir où elle est utilisée. C'est l'un des défauts les plus fréquents dans les MVP générés par un agent de codage, où la configuration est écrite en dur pour que la démo tourne.
La traçabilité minimale. Journaux structurés côté serveur et remontée d'erreurs vers un outil externe. Deux heures de travail. Sans elles, votre premier incident client se diagnostique en demandant à l'utilisateur de refaire l'action pendant que vous regardez, et votre deuxième incident se diagnostique de la même façon.
La source de vérité de la facturation. L'état d'abonnement d'un compte se déduit d'un seul endroit, et cet endroit est votre base, synchronisée depuis le fournisseur de paiement. Un produit qui interroge directement l'API de paiement à chaque page pour savoir si le client a le droit d'entrer finira par facturer quelqu'un deux fois ou par donner un accès gratuit, et ces bugs-là se paient en remboursements et en confiance.
La suppression des données. Savoir effacer un compte et tout ce qui lui est rattaché. Ce n'est pas un sujet de conformité lointain : c'est la première demande d'un client B2B qui résilie, et un modèle de données qui ne permet pas de répondre proprement se corrige au même prix qu'une migration d'isolation.
Sept points. Aucun ne demande plus d'une journée au moment où on le fait, et ensemble ils représentent peut-être trois à quatre jours sur un projet de huit semaines. C'est exactement l'arbitrage que nous appliquons sur nos projets de développement de MVP et de SaaS : le socle non négociable tient en quelques jours, et tout le reste du calendrier est négociable au profit de la vitesse.
Écrire la dette pour qu'elle reste remboursable
Une dette acceptée et non écrite devient, en deux mois, une dette oubliée — et une dette oubliée est indiscernable d'un bug pour la personne qui reprend le code. Trois habitudes suffisent à garder le registre exploitable.
Un fichier de dettes, pas des commentaires épars. Un tableau dans le dépôt : ce qui a été court-circuité, pourquoi, ce qui déclenche le remboursement, et l'estimation. Une ligne ressemble à ceci — « pas de file d'attente sur les exports ; déclencheur : un export dépasse 10 s ou plus de 50 exports par jour ; coût estimé : 2 jours ». Ce document, relu tous les mois, vous évite la réunion où personne ne sait ce qui est intentionnel.
Un déclencheur chiffré, pas une échéance. « À refaire en janvier » ne se respecte jamais. « À refaire quand la table dépasse le million de lignes » se vérifie en une requête. Le déclencheur transforme un arbitrage en décision automatique, ce qui vous dispense de rejouer le débat à chaque sprint.
Des frontières explicites autour des raccourcis. Le code bâclé est acceptable s'il est isolé derrière une interface propre. Un module d'export écrit en deux heures et appelé par une seule fonction se remplace en une journée. Le même code, appelé depuis douze endroits, ne se remplace plus : il se contourne. La discipline ne porte pas sur la qualité interne du raccourci, elle porte sur la taille de sa surface de contact.
Le signal qui dit que vous avez dépassé la limite
Il y en a un, et il est mesurable sans outillage : le temps qu'il faut pour livrer une modification simple. Notez, sur trois demandes de faible ampleur — changer un libellé, ajouter un champ, modifier une règle de calcul —, le délai entre la demande et la mise en production. Tant qu'il reste dans la journée, votre dette est sous contrôle, quelle que soit son ampleur apparente. Quand une modification d'un champ demande trois jours parce qu'il faut la répercuter à sept endroits et vérifier à la main qu'on n'a rien cassé, l'intérêt de la dette est devenu supérieur à votre capacité de livraison. Ce n'est plus un sujet de qualité, c'est un sujet de trésorerie : chaque semaine, vous payez des développeurs pour produire moins que le mois précédent.
C'est le même mécanisme, à un stade plus avancé, que celui qui fait durer un MVP huit mois sans utilisateur payant : le périmètre gonfle d'un côté, la vélocité s'effondre de l'autre, et les deux courbes se croisent avant la mise en ligne.
Ce que cela change dans vos discussions avec un prestataire
Un prestataire qui vous promet zéro dette technique vous vend soit un mensonge, soit un budget de version 2. Un prestataire qui n'évoque jamais la dette vous livrera un produit dont vous découvrirez le coût réel à la première évolution. Celui qu'il faut chercher est le troisième : il vous dit ce qu'il coupe, pourquoi, et ce que ça coûtera de le reprendre.
Demandez-le explicitement pendant le chiffrage. « Quels raccourcis prenez-vous pour tenir ce délai, et lesquels refusez-vous de prendre ? » Une réponse précise — trois exemples de dette assumée, une liste courte de non-négociables — vous apprend plus sur l'équipe que n'importe quelle référence. Une réponse floue, ou l'affirmation qu'il n'y en aura pas, est le signal.
La prochaine action
Ouvrez un fichier dans votre dépôt et écrivez les cinq raccourcis que votre équipe connaît déjà. Pour chacun, trois colonnes : ce qui le déclenche, ce qu'il coûte à reprendre, ce qu'il coûte chaque semaine tant qu'il est là. L'exercice prend une heure et vous donnera immédiatement l'information qui manquait à la conversation du début : vos trois semaines de refactoring sont-elles une exigence ou un arbitrage, et quelle partie de ces trois semaines est réellement bloquante pour le prochain client payant. Dans la plupart des cas que nous voyons, la réponse tient en trois jours, pas trois semaines — et ce sont les trois jours de la liste des non-négociables.
Besoin d'aide pour votre projet web ? Contactez Raicode pour en discuter.
Un MVP à sortir ? Cadrons-le ensemble.
Périmètre tranché en une semaine, sprints hebdomadaires démontrables, mise en production avec paiement et authentification. Devis ferme après cadrage.
Articles similaires
Multi-tenant et facturation par abonnement : les deux fondations d'un SaaS qu'on ne rattrape pas après le MVP
Faire coder son MVP par une IA : ce qu'elle écrit vraiment, et ce qu'il faut reprendre avant de vendre
