La dette technique se chiffre, et elle se négocie

Dans les discussions d’acquisition, la dette technique est trop souvent traitée comme une humeur : "le code est propre" rassure, "il y a de la dette" inquiète, et la valorisation n’en tient aucun compte faute de chiffre. C’est une erreur des deux côtés de la table. La dette technique d’une cible se chiffre, avec la même discipline qu’un passif financier, et une fois chiffrée elle se négocie comme le reste.

Toute base de code en porte. La question de due diligence n’est jamais "y a-t-il de la dette" mais "combien coûte-t-elle, à qui, et quand".

Trois coûts font un chiffre

Nous décomposons la dette d’une cible en trois coûts, parce qu’ils n’ont ni le même calendrier ni le même effet sur le deal.

Le coût de correction : ce qu’il faudrait dépenser pour ramener le système à l’état que le plan d’affaires suppose. Il s’estime en mois-ingénieur, poste par poste : la migration repoussée depuis deux ans, la couverture de tests à construire, le module que plus personne n’ose toucher. C’est le chiffre le plus simple à produire et le seul que les rapports d’audit classiques donnent.

Le coût de portage : ce que la dette coûte chaque mois tant qu’elle n’est pas corrigée. Il se lit dans le présent de l’équipe : part du temps d’ingénierie absorbée par les incidents et les contournements, vélocité qui décroît à effectif constant, facture d’infrastructure gonflée par une architecture inadaptée. Ce coût est récurrent, il court pendant toute la détention, et il est presque toujours oublié.

Le coût de roadmap, enfin : ce que la dette empêche de construire. Si la thèse d’investissement repose sur trois fonctionnalités majeures et que l’architecture actuelle interdit la première sans réécriture préalable, ce blocage vaut plus que les deux autres coûts réunis. C’est lui qui transforme une dette de confort en dette de thèse.

Quand la dette est acceptable

Une dette lourde peut être un dossier sain. Les startups qui ont trouvé leur marché vite ont presque toutes accumulé de la dette en route : c’est la trace d’arbitrages rationnels, pas d’incompétence. Trois conditions rendent une dette acceptable à nos yeux. L’équipe la connaît et peut la cartographier sans être poussée, signe qu’elle arbitre en conscience. Elle est concentrée dans des zones que la roadmap ne traverse pas. Et son coût de portage reste borné : les incidents se comptent, la vélocité tient.

À l’inverse, une dette modeste peut être disqualifiante si elle est invisible pour l’équipe qui l’a produite. Une équipe qui découvre sa propre dette pendant l’audit continuera d’en produire après le closing. Sur ce point, la dette rejoint les autres signaux d’alerte d’un audit technique : le révélateur de culture pèse plus que le stock.

Un mot sur un cas devenu fréquent : les bases de code largement générées par IA. Le volume de code produit par personne a explosé, et avec lui une forme neuve de dette, du code que personne n’a vraiment lu. Le sujet mérite sa propre analyse, que nous avons publiée dans code généré et dette technique.

Quand elle mange le plan de création de valeur

Le calcul décisif se fait contre le plan, pas contre un idéal de propreté. Prenez les initiatives qui portent la création de valeur (produits, intégrations, expansion) et posez pour chacune la question : l’état actuel du système la permet-il dans les délais du plan. Puis additionnez ce que coûtent les remédiations préalables, en argent et en mois.

Le seuil que nous utilisons : quand la remédiation absorbe plus que la première année du plan, la thèse doit être révisée, pas seulement le prix. Un acquéreur qui paie pour une trajectoire de croissance et passe dix-huit mois à réécrire une plateforme n’a pas fait une mauvaise affaire technique, il a acheté une autre entreprise que celle du mémo d’investissement. Ce scénario, nous l’avons rencontré, et il se détecte avant signature : les indices sont dans le code, dans les échanges avec l’équipe et dans l’écart entre la roadmap promise et la vélocité constatée.

Faire entrer la dette technique dans la valorisation

Une fois les trois coûts posés, la négociation devient un exercice ordinaire. Le coût de correction se traite comme un capex de remise à niveau : ajustement du prix ou enveloppe dédiée, sanctuarisée dans le plan post-closing pour ne pas être arbitrée contre les fonctionnalités dès le premier comité. Le coût de portage entre dans le plan d’affaires comme un frein temporaire à la marge d’ingénierie. Le coût de roadmap se traduit en décalage des revenus attendus, ce qui est un argument de valorisation au sens propre.

Ce cadre a une vertu de plus : il est audible par un comité d’investissement. "La dette est importante" n’aide personne à décider ; "18 mois-ingénieur de remise à niveau, dont 6 bloquants pour l’intégration prévue au S2" se discute, se contre-argumente et se négocie. C’est exactement le type de conclusion que doit produire une due diligence, comme nous le détaillons dans notre mode d’emploi de la due diligence technique.

Chiffrer la dette d’une cible demande de lire son code, de parler à son équipe et d’avoir soi-même arbitré ce genre de dette en production. C’est ce que nous faisons dans le cadre de notre due diligence technique, avec un registre des risques dont chaque ligne porte un coût et un délai.