Vous êtes sur le point de payer un logiciel sur la foi d'un pitch
Le vendeur vous a montré la démo et la courbe de chiffre d'affaires. Votre expert-comptable a validé les comptes, votre avocat relit le protocole. Personne n'a ouvert le code. C'est pourtant là que se cache l'écart entre le prix affiché et la valeur réelle de ce que vous achetez.
Dans un rachat de startup ou de logiciel, chaque faiblesse technique non détectée avant la signature devient, six mois plus tard, une dépense que personne ne vous remboursera. La due diligence acquisition sert à transformer ces inconnues en montants, puis ces montants en clauses.
Dans cet article, vous allez découvrir :
- •Les 7 risques techniques qui font chuter la valeur d'une application, chacun raconté par une situation concrète
- •Pour chaque risque, le levier de négociation qu'il ouvre : décote, séquestre, garantie de passif, earn-out, condition suspensive, clause de transition ou budget de migration
- •La règle en trois étapes qui transforme un constat technique en montant négociable
- •Ce que coûte une due diligence technique comparé à ce qu'elle protège
Un constat technique sans montant est une inquiétude. Un constat technique avec un montant est une clause.
Pourquoi le risque technique est le grand absent des négociations
Une acquisition mobilise trois regards : financier, juridique, commercial. Le code est traité comme une boîte noire qui fonctionne, puisque les clients paient. Ce raisonnement s'effondre dès que vous voulez ajouter une fonctionnalité, absorber plus d'utilisateurs ou remplacer le développeur historique.
La due diligence technique est l'examen indépendant du code, de l'architecture, de la sécurité, de l'infrastructure et de l'équipe, mené avant la transaction. Son but : dire ce que l'actif vaut une fois le risque déduit, et ce que chaque risque change au prix. Le périmètre et les livrables sont détaillés sur notre page dédiée à la due diligence technique avant rachat ou investissement.
Les sept risques qui suivent sont ceux que nous retrouvons le plus souvent. Pour chacun : une situation type, un ordre de grandeur et le levier contractuel qui en découle. Les montants sont des exemples de calcul, pas des chiffres clients.
Les 7 risques techniques et le levier que chacun ouvre
Risque 1 : la dette technique non chiffrée
La situation. Un SaaS de gestion, six ans d'existence, trois générations de développeurs. Chaque évolution prend deux fois plus de temps qu'annoncé. Le vendeur parle de « quelques refactorings à prévoir ». Personne ne sait combien.
Le calcul. Une due diligence liste les zones à reprendre et les estime en jours. Supposons 60 jours pour remettre le socle à niveau, à 600 euros HT la journée d'un développeur senior : 36 000 euros dépensés avant de livrer la moindre fonctionnalité nouvelle. Si le vendeur n'a pas déduit ce montant, il vous le facture sans le dire.
Le levier : la décote sur le prix. L'effort de remise à niveau, exprimé en jours puis en euros, se soustrait du prix d'acquisition. Le levier le plus simple à activer, à condition d'arriver avec un chiffrage défendable. Pour comprendre comment cette dette se forme et pourquoi elle grossit seule, notre guide complet sur la dette technique détaille les mécanismes et les signaux à surveiller.
Risque 2 : la faille de sécurité qui attend son heure
La situation. Une marketplace B2B, des données clients, des paiements. L'analyse révèle des dépendances non mises à jour depuis trois ans, dont deux avec des vulnérabilités publiques, et des identifiants d'accès en clair dans le dépôt de code. Rien n'a encore explosé. Rien ne garantit que cela dure.
Le calcul. La correction peut être modeste : quelques jours pour mettre à jour et renouveler les secrets. Le coût d'un incident, lui, ne l'est pas : indisponibilité, notification aux clients, perte de contrats, et une réputation que vous venez d'acheter qui se dégrade avant votre premier trimestre.
Le levier : la condition suspensive. Une faille connue avant la signature se corrige avant, pas après. La correction devient une condition de la vente, vérifiée par un nouveau contrôle : vous achetez un actif assaini, pas un problème à régler. Si le calendrier de closing ne le permet pas, le séquestre prend le relais (voir risque 4).
Risque 3 : un code dont personne ne possède vraiment les droits
La situation. La première version a été développée par un freelance, puis par une agence, puis par un stagiaire devenu CTO. Aucun contrat ne mentionne de cession de droits d'auteur. Une bibliothèque sous licence copyleft est embarquée dans le produit commercial, ce qui peut obliger à publier le code source.
Le calcul. Remplacer une bibliothèque se compte en jours. Une revendication de propriété par un ancien prestataire se compte en mois de procédure et en incertitude sur l'actif entier.
Le levier : la garantie de passif. Le vendeur garantit contractuellement l'absence de réclamation future sur la propriété du code et en assume les conséquences si elle survient. La régularisation des cessions de droits peut aussi devenir une condition de signature. Une due diligence sérieuse inclut un scan des licences et une revue des contrats de prestation.
Risque 4 : l'infrastructure qui ne tiendra pas la croissance promise
La situation. Le vendeur projette un doublement des utilisateurs en dix-huit mois. L'application tourne sur un serveur unique, la base de données n'a pas d'index sur ses tables principales, aucun test de charge n'a jamais été réalisé. La facture d'hébergement a triplé en deux ans sans que personne comprenne pourquoi.
Le calcul. Deux postes : l'investissement pour que l'architecture absorbe la croissance annoncée, et le surcoût d'exploitation récurrent si rien n'est fait. Une valorisation fondée sur un doublement du chiffre d'affaires est fausse si l'infrastructure ne suit pas, ou s'il faut dépenser 40 000 euros pour qu'elle suive.
Le levier : le séquestre. Une partie du prix est bloquée chez un tiers et libérée quand la preuve est apportée : test de charge concluant, migration validée, ou absence d'incident majeur pendant une période convenue. L'outil idéal quand le risque est réel mais incertain : il ne pénalise pas le vendeur si tout va bien, et vous protège sinon.
À lire aussi : Due diligence technique : le guide complet pour les acquéreurs - Ce qu'on vérifie, qui le fait, combien de temps cela prend, ce que contient le rapport.
Risque 5 : tout le savoir dans une seule tête
La situation. Le fondateur technique a écrit 80 % du code. Il connaît les règles métier non documentées et le script qui relance le serveur le dimanche soir. Il part dans trois mois. La documentation tient en un README de vingt lignes.
Le calcul. Combien de temps faut-il à une nouvelle équipe pour être autonome sans lui ? Une due diligence évalue la documentation, la lisibilité du code et la concentration des contributions. Si la réponse est « six mois avec lui, impossible sans lui », vous achetez une personne qui s'en va, pas un logiciel.
Le levier : la clause de transition. Le détenteur du savoir reste pendant une période définie, avec des objectifs explicites : documentation livrée, équipe formée, mises en production réalisées par d'autres que lui. Cette clause se double souvent d'un earn-out pour aligner son intérêt financier sur la réussite du transfert. Sans cela, « rester disponible » ne vaut que ce que vaut une bonne intention.
Risque 6 : des technologies en fin de vie
La situation. Le produit repose sur une version de framework sans correctifs de sécurité depuis deux ans, un langage dont la version est officiellement abandonnée et une base de données dont le support s'arrête l'année prochaine. Tout fonctionne, jusqu'au jour où une faille est publiée et où personne ne la corrigera.
Le calcul. Une migration majeure de framework n'est pas une mise à jour : c'est un projet, de plusieurs dizaines de jours à plusieurs mois selon la taille du code. Un investissement obligatoire, à date connue, que le vendeur a souvent repoussé parce qu'il préparait la vente. Sur le périmètre des sites web, notre guide de la refonte de site internet décrit les signaux qui rendent la migration inévitable et comment la budgéter.
Le levier : le budget de migration intégré. Le coût de la migration est documenté dans le rapport et soustrait de la valorisation, ou isolé dans une enveloppe dédiée du plan de financement. Ce coût existe, il ne disparaîtra pas : il doit figurer dans le prix plutôt que d'être découvert six mois après la signature, quand il est trop tard pour négocier.
Risque 7 : l'écart entre le pitch et le code
La situation. Le deck annonce un « moteur de recommandation par intelligence artificielle ». Dans le code, c'est une requête triée par date avec trois règles codées en dur. Le deck annonce une « API ouverte aux partenaires » : elle existe, personne d'autre que l'application ne l'a jamais appelée. Le vendeur a vendu la roadmap comme si elle était livrée.
Le calcul. Chaque fonctionnalité promise mais absente est un développement à financer. Si la valorisation repose sur ces promesses (un multiple plus élevé parce que « c'est une plateforme IA »), l'écart est une erreur de prix sur toute l'opération.
Le levier : l'earn-out. Une part du prix est différée et conditionnée à des résultats mesurables : fonctionnalités livrées, performances atteintes, clients signés sur l'offre annoncée. Si la roadmap se réalise, le vendeur touche son prix. Sinon, vous n'avez pas payé pour du vent. L'earn-out est le levier le plus juste quand le désaccord porte sur l'avenir plutôt que sur l'état présent.
Tableau récapitulatif : du constat à la clause
| Risque technique | Ce que révèle la due diligence | Levier de négociation |
|---|---|---|
| Dette technique non chiffrée | Jours de remise à niveau estimés | Décote sur le prix |
| Faille de sécurité | Vulnérabilités connues, secrets exposés | Condition suspensive |
| Propriété du code incertaine | Licences incompatibles, cessions de droits absentes | Garantie de passif |
| Infrastructure sous-dimensionnée | Capacité réelle vs croissance annoncée | Séquestre |
| Dépendance à une personne | Concentration du savoir, documentation | Clause de transition |
| Technologies en fin de vie | Versions abandonnées, dates de fin de support | Budget de migration intégré |
| Écart pitch et code | Fonctionnalités promises non livrées | Earn-out |
La règle de conversion : d'un constat technique à un montant
Un acquéreur non technique n'a pas besoin de comprendre pourquoi un index manque sur une table. Il a besoin de savoir ce que cela lui coûtera. La conversion tient en trois étapes.
- 1.Identifier le constat et sa criticité : sécurité, exploitation, évolutivité, conformité. Un défaut bloquant pour la croissance ne pèse pas comme un défaut cosmétique.
- 2.Estimer l'effort de correction en jours : l'étape qui demande d'avoir déjà corrigé ce type de problème pour savoir combien de temps il prend réellement.
- 3.Traduire en euros et choisir le levier : un coût certain et immédiat appelle une décote ; un coût certain et futur, un budget intégré ; un risque incertain, un séquestre ou une garantie ; un désaccord sur l'avenir, un earn-out.
L'étude The Developer Coefficient de Stripe évaluait à près d'un tiers la part du temps des développeurs absorbée par la dette technique. Chaque jour passé à réparer est un jour que l'acquéreur paie sans retour.
Ce que coûte la due diligence, et ce qu'elle évite
Chez ONDEV, le format express, centré sur les risques majeurs, démarre autour de 2 500 euros HT et se livre en cinq jours ouvrés. La due diligence complète se situe entre 5 000 et 12 000 euros HT selon la taille du code source et le périmètre, pour deux à trois semaines d'analyse.
Rapporté aux décotes, séquestres et garanties qu'elle permet d'obtenir, c'est presque toujours l'assurance la moins chère de l'opération. Dans l'exemple du risque 1, un seul constat chiffré justifiait une décote de 36 000 euros.
Le livrable qui compte n'est pas la liste des défauts : c'est la ligne « remise à niveau : X jours, Y euros » que votre avocat reprend dans le protocole.
Les erreurs qui coûtent cher aux acquéreurs
- •Faire confiance à la démo. Elle montre ce qui marche, jamais ce qui a été contourné pour que cela marche.
- •Confier l'audit au CTO du vendeur. Compétent, de bonne foi, et structurellement incapable d'être indépendant sur un code dont dépend son chèque.
- •Verrouiller le prix avant la due diligence. Sans clause d'ajustement, le rapport ne sert plus qu'à vous inquiéter.
- •Accepter des constats sans montant. « L'architecture devrait être revue » n'est pas négociable. « 45 jours de refonte du module de facturation, soit 27 000 euros HT » l'est.
FAQ : due diligence acquisition et rachat de logiciel
Pour transformer chacun de ces sept risques en montant négociable, notre audit de code restitue un plan d'action chiffré en jours, directement exploitable dans le protocole d'acquisition.
Qu'est-ce qu'une due diligence acquisition sur le plan technique ?
À quel moment lancer la due diligence technique dans un rachat de startup ?
Combien coûte une due diligence technique pour racheter une application ?
Le vendeur doit-il donner accès à sa production ?
Quelle différence entre décote, séquestre et earn-out ?
Conclusion : achetez du code, pas une promesse
Racheter un logiciel, c'est racheter un actif dont la valeur se lit dans son code. Les sept risques présentés ici ne sont pas des raisons de renoncer : ce sont des arguments. Chacun, une fois chiffré, devient une clause que vous n'auriez jamais obtenue sur la foi d'une démo. La différence entre l'acquéreur qui subit et celui qui négocie tient à une chose : arriver à la table avec des montants plutôt qu'avec des inquiétudes.
Vous préparez le rachat d'une application, d'un SaaS ou d'un logiciel métier ? Parlons de votre opération : nous vous dirons en 48 h ce qu'une due diligence technique peut sécuriser dans votre calendrier.
