L'auditeur de l'acheteur trouvera tout. La seule question : avant vous, ou après vous ?
Vous vendez votre application, votre SaaS ou votre startup. L'acheteur signe une lettre d'intention, puis il envoie son équipe technique fouiller votre code. Chaque secret oublié dans un fichier de config, chaque module sans test, chaque dépendance abandonnée devient un argument de négociation contre vous. La vendor due diligence technique consiste à faire ce travail avant lui, pour arriver à la table avec un dossier propre au lieu d'une liste de concessions.
Dans cet article, vous allez découvrir :
- •Ce que l'auditeur de l'acheteur regarde en premier, et pourquoi il le trouve toujours
- •Les constats qui font chuter le multiple et ceux qui le font monter, avec leur traduction dans le contrat (décote, séquestre, earn-out)
- •Le plan d'action à six mois, trois mois et un mois de la vente, dans le bon ordre
- •L'auto-évaluation gratuite en 10 questions à faire avant tout le reste
- •Les cinq pièges qui coûtent le plus cher aux vendeurs
La valeur d'une application se lit dans son code. L'expert-comptable donne la valeur comptable, le banquier donne un multiple ; le code dit ce que l'actif vaut une fois le risque technique déduit.
Vendor due diligence : de quoi parle-t-on exactement ?
La vendor due diligence (VDD) est l'audit que le vendeur commande lui-même sur son propre actif, avant d'ouvrir la data room aux acheteurs. Côté financier et juridique, c'est une pratique courante dans les cessions d'entreprise. Côté technique, elle reste rare, et c'est précisément pour cela qu'elle rapporte.
Sa version technique porte sur le code source, l'architecture, l'infrastructure, la sécurité, les dépendances, les licences et l'équipe. Elle produit un rapport que vous choisissez de partager, en tout ou partie, avec les acquéreurs. Elle ne remplace pas la due diligence technique de l'acheteur : elle vous permet d'arriver avant elle.
Ce que l'auditeur de l'acheteur va regarder
Un auditeur technique mandaté par un acquéreur travaille toujours dans le même ordre, parce que c'est l'ordre du risque :
- 1.Les secrets : clés d'API, mots de passe et tokens présents dans le dépôt ou son historique Git.
- 2.La reproductibilité : peut-on cloner le dépôt, suivre le README et obtenir une application qui tourne ?
- 3.Les tests : existe-t-il une suite automatisée, passe-t-elle, couvre-t-elle les parcours qui génèrent du chiffre d'affaires ?
- 4.Les dépendances : versions, vulnérabilités connues, paquets abandonnés, licences incompatibles avec une exploitation commerciale.
- 5.La concentration des connaissances : qui a écrit quoi, qui sait déployer, que se passe-t-il si cette personne part le lendemain de la signature ?
- 6.L'infrastructure : coûts d'hébergement, dépendance à un fournisseur, sauvegardes testées ou non.
Il trouvera tout cela en quelques jours : il lui suffit d'un accès au dépôt et d'une checklist. Autant que ce soit vous qui ayez la checklist en premier.
Pourquoi le rapport du vendeur change le rapport de force
Quand l'acheteur découvre un problème, il le chiffre à sa manière et l'inscrit dans la négociation : baisse de prix, séquestre, garantie de passif élargie, earn-out conditionné. Quand c'est vous qui le signalez, avec un plan de correction daté et un coût estimé, le même problème devient un point de discussion technique, pas un levier de pression.
La différence entre les deux situations se mesure en pourcentage du prix de cession. Un problème découvert vaut toujours plus cher qu'un problème déclaré.
Avant tout le reste : l'auto-évaluation en 10 questions
Avant de commander un audit, avant d'ouvrir un seul chantier, il faut savoir où vous en êtes. ONDEV met à disposition un diagnostic de dette technique gratuit en 10 questions : deux minutes, pas de jargon, un résultat immédiat sur l'état réel de votre socle.
Les dix questions reprennent les points que l'auditeur de l'acheteur vérifiera : tests, documentation, dépendances, déploiement, dépendance à une personne. Si vous hésitez sur plusieurs réponses, c'est déjà une information. Le vendeur qui ne sait pas répondre à « combien de temps faut-il à un nouveau développeur pour déployer en production ? » a sa première priorité.
Ce diagnostic ne remplace pas une vendor due diligence complète. Il vous dit si vous avez trois mois de travail devant vous ou dix-huit, et c'est exactement ce qu'il faut savoir avant de fixer une date de mise en vente.
À lire aussi : Due diligence technique : le guide complet pour les acquéreurs - ce que l'acheteur vérifie, qui le fait, combien ça coûte et les dix drapeaux rouges qu'il cherche. Lisez-le comme on lit la copie de l'examen avant de le passer.
Ce qui fait chuter le multiple, ce qui le fait monter
Un acquéreur paie un multiple de revenu ou de résultat, puis ajuste ce multiple en fonction du risque qu'il perçoit. Le risque technique est l'un des plus faciles à objectiver, donc l'un des plus utilisés pour négocier. Voici la traduction concrète des constats les plus fréquents.
| Constat de l'auditeur | Ce que l'acheteur en fait | Ce que vous pouvez faire avant |
|---|---|---|
| Secrets dans le code ou l'historique Git | Décote immédiate, condition suspensive de rotation des accès | Rotation de tous les secrets, purge de l'historique, gestionnaire de secrets |
| Aucun test automatisé | Earn-out conditionné à la stabilité post-cession | Tests sur les parcours critiques en priorité, pipeline CI qui les exécute |
| Une seule personne sait déployer | Clause de rétention du fondateur ou du développeur clé, prix différé | Documentation de déploiement, second référent formé, déploiement automatisé |
| Dépendances obsolètes ou abandonnées | Provision pour mise à niveau déduite du prix | Mise à jour des versions majeures, remplacement des paquets morts |
| Licence copyleft dans une brique commerciale | Garantie de passif élargie, parfois rupture | Inventaire des licences, remplacement des composants problématiques |
| Infrastructure non reproductible | Allongement de la due diligence, décote de risque | Infrastructure décrite en code, environnement de recette identique à la production |
| Documentation absente | Décote « temps de reprise » | README opérationnel, schéma d'architecture, journal des décisions techniques |
Ce qui fait monter le multiple
Le miroir de ce tableau est tout aussi concret. Un acquéreur paie plus cher, ou négocie moins, quand il constate :
- •Une suite de tests qui passe au vert dans un pipeline visible, avec une couverture honnête des parcours qui génèrent du revenu.
- •Un dépôt qu'un développeur extérieur fait tourner en une heure en suivant la documentation, sans appeler personne.
- •Des dépendances à jour et un fichier de licences propre, prêt à être joint à la data room.
- •Une architecture lisible, un schéma à jour et un journal des choix techniques qui explique pourquoi.
- •Un plan de reprise documenté : qui fait quoi pendant les six mois qui suivent la signature.
- •Une équipe qui n'est pas un point unique de défaillance : au moins deux personnes capables de livrer et de déployer.
Chacun de ces points réduit le temps de due diligence de l'acheteur, et le temps est son premier coût. Un dossier technique propre accélère la signature autant qu'il protège le prix.
Le plan à six mois, trois mois et un mois de la vente
L'ordre compte plus que la quantité de travail. Les chantiers lourds doivent être terminés et stabilisés quand l'acheteur arrive ; les chantiers de forme peuvent attendre le dernier mois. Voici la séquence que nous recommandons.
À six mois : les chantiers lourds
C'est le moment des corrections qui demandent du temps de calcul et du temps de recul :
- •Rotation complète des secrets et purge de l'historique Git. C'est long si des clés traînent depuis des années, et il faut vérifier que rien ne casse.
- •Mise à niveau des dépendances majeures : framework, runtime, base de données. Une montée de version faite dans la précipitation, à un mois de la vente, se voit dans les logs d'erreur.
- •Tests sur les parcours critiques : inscription, paiement, fonctionnalité cœur. Pas 80 % de couverture, mais 100 % de ce qui rapporte.
- •Remplacement des composants à licence problématique, parce qu'un remplacement de brique touche souvent plusieurs modules.
C'est aussi le moment de décider ce que vous corrigez et ce que vous déclarez : tout ne se corrige pas en six mois, et un acquéreur préfère une dette chiffrée à une dette dissimulée.
À trois mois : l'hygiène et la transmissibilité
Les corrections lourdes sont livrées. Il reste à rendre l'application transmissible :
- •Documentation d'installation et de déploiement testée par quelqu'un qui ne connaît pas le projet.
- •Pipeline d'intégration continue qui exécute les tests et déploie sans intervention manuelle.
- •Second référent technique formé sur le déploiement, la base de données et les incidents fréquents.
- •Inventaire des accès : qui a accès à quoi (hébergeur, DNS, dépôts, services tiers, comptes de facturation), et sous quel compte. Les comptes personnels du fondateur sont à migrer vers des comptes de l'entreprise.
- •Sauvegardes restaurées au moins une fois, avec le compte rendu dans la documentation.
C'est aussi la fenêtre idéale pour un audit de code indépendant : assez tôt pour corriger ce qu'il remonte, assez tard pour que le rapport reflète l'état que verra l'acheteur. Un rapport d'audit daté de trois mois avant la cession, suivi d'un plan de correction exécuté, est une pièce de data room qui vaut cher.
À un mois : la data room technique
Le dernier mois ne sert plus à corriger, il sert à présenter. La data room technique contient :
- 1.Le rapport de vendor due diligence (ou d'audit de code) et le suivi des corrections.
- 2.Le schéma d'architecture et la liste des services tiers avec leurs coûts mensuels.
- 3.L'inventaire des dépendances et des licences.
- 4.La documentation d'installation, de déploiement et d'exploitation.
- 5.L'organigramme technique : qui a écrit quoi, qui reste après la cession, pour combien de temps.
- 6.Les métriques d'exploitation : disponibilité, incidents des douze derniers mois, coûts d'infrastructure.
Un acquéreur qui trouve ces six pièces le premier jour sait qu'il a affaire à un vendeur sérieux. Son auditeur passera moins de temps à chercher, donc moins de temps à trouver des arguments.
Les cinq pièges qui coûtent le plus cher aux vendeurs
Les dirigeants qui préparent une cession dans l'urgence commettent souvent les mêmes erreurs, avec le même effet : transformer un problème gérable en argument de négociation.
1. Maquiller plutôt que corriger. Supprimer les tests qui échouent au lieu de les réparer, masquer les avertissements de sécurité, désactiver les alertes. L'auditeur de l'acheteur lit l'historique Git : il verra le commit, et il saura ce que vous avez voulu cacher.
2. Lancer une réécriture à six mois de la vente. Une refonte complète du socle est la pire décision possible avant une cession : vous livrez à l'acheteur un code neuf, non éprouvé, sans historique de production. Corrigez, modernisez par morceaux, mais ne réécrivez pas.
3. Taire le point faible que vous connaissez. Si vous savez qu'un module est fragile, dites-le, chiffrez-le, proposez un plan. Un problème déclaré se négocie en jours de travail ; un problème découvert se négocie en pourcentage du prix.
4. Négliger la dépendance aux personnes. Un acquéreur n'achète pas seulement du code, il achète la capacité à le faire évoluer. Si cette capacité tient à un seul développeur, l'acheteur l'exigera dans le contrat, et le prix s'en souviendra.
5. Laisser l'auditeur découvrir les accès. Comptes d'hébergement au nom du fondateur, nom de domaine sur un compte personnel, facturation des services tiers sur une carte bancaire privée. Chaque découverte de ce type ajoute une clause et retarde la signature.
Ce que nous en savons : exploiter ses propres SaaS
Chez ONDEV, nous ne parlons pas de transmissibilité en théorie. Nous exploitons nous-mêmes des produits SaaS, et chacun pose les questions qu'un acquéreur poserait.
Wiloq, application SaaS de vestiaire numérique pour l'événementiel, aligne plus de 12 fonctionnalités réparties sur 3 interfaces (organisateur, personnel de vestiaire, participant) et 2 sites vitrines. Trois interfaces, c'est trois parcours critiques à couvrir par des tests, trois surfaces d'accès à inventorier et une documentation qui doit permettre à un développeur extérieur de livrer sur chacune sans nous appeler.
Swap&Share, plateforme d'échange de compétences entre professionnels, compte 100 à 200 utilisateurs et plus de 200 échanges réalisés, avec des paiements gérés par Stripe. Un acquéreur regarderait d'abord la gestion des secrets Stripe, la traçabilité des transactions et la reproductibilité de l'environnement de paiement en recette. Ce sont les points que nous maintenons en permanence, pas la veille d'une data room.
Cette pratique nous donne un regard de propriétaire sur le code que nous auditons pour des tiers. Les applications sur-mesure que nous livrons suivent les mêmes règles : documentation testée par un tiers, secrets hors du code, déploiement automatisé, aucune personne indispensable. C'est ce qui fait qu'une application se vend.
FAQ : vendor due diligence technique
Si l'auto-évaluation révèle un socle technique en fin de vie, une refonte d'application web engagée six mois avant la mise en vente transforme un argument de décote en argument de prix.
Qu'est-ce qu'une vendor due diligence technique ?
Combien de temps faut-il pour préparer la vente d'une application ou d'un SaaS ?
Faut-il réécrire l'application avant de la vendre ?
Que faire si je sais qu'un module de mon application est fragile ?
Quelle différence entre un audit de code et une vendor due diligence ?
En résumé : vendez un actif, pas une liste de concessions
L'auditeur de l'acheteur trouvera les secrets dans le code, les tests absents, la dépendance à une personne et les licences douteuses. La vendor due diligence technique vous permet de les trouver en premier, de corriger ce qui peut l'être et de déclarer le reste à vos conditions. Six mois pour les chantiers lourds, trois mois pour la transmissibilité, un mois pour la data room : c'est l'ordre qui protège le multiple.
Commencez par le diagnostic gratuit en 10 questions. Il vous dira en deux minutes si vous avez trois mois ou dix-huit mois de travail devant vous.
Vous préparez la cession de votre application ou de votre SaaS et vous voulez savoir ce que l'auditeur de l'acheteur verra avant lui ? Parlons de votre projet : nous vous disons où vous en êtes, ce qu'il faut corriger et dans quel ordre.
