Préparer une due diligence technique côté fondateur

Une due diligence technique se prépare, et 90 jours suffisent pour changer sensiblement ce qu’elle donnera à lire. Pas en transformant le produit : en corrigeant ce qui se corrige vite, en documentant ce qui existe et en préparant l’équipe à parler honnêtement de ce qui reste. Nous menons ces audits pour des fonds ; voici, depuis l’autre côté de la table, ce que nous regardons et ce que les meilleures équipes vendeuses avaient préparé.

Une conviction d’abord, qui commande tout le reste : l’objectif de la préparation n’est pas de cacher les problèmes, c’est de montrer que vous les connaissez. Un auditeur compétent trouvera l’essentiel de toute façon. La vraie variable, c’est ce que la découverte dira de vous.

Ce que l’équipe d’audit va regarder

Le périmètre type couvre l’architecture, le code, la sécurité, l’équipe et le produit : lecture du code et de l’historique git, revue de l’infrastructure et des accès, analyse des dépendances, entretiens avec l’équipe, et pour les produits IA, la pratique d’évaluation et l’économie unitaire.

Un point que les fondateurs sous-estiment : l’historique git est un enregistrement de plusieurs années de décisions, impossible à maquiller en trois mois. Il montre qui a écrit quoi, comment les choix se sont pris, si les revues existent, si la vélocité annoncée est réelle. Préparez-vous à ce qu’il soit lu.

Les 90 jours : corriger ce qui se corrige

Quatre chantiers rapportent plus que tous les autres.

Les secrets d’abord. Cherchez les clés d’API, mots de passe et jetons committés dans l’historique, sortez-les, et surtout révoquez-les : un secret retiré du code mais toujours valide reste une trouvaille d’audit. C’est l’un des signaux d’alerte les plus sérieux, et l’un des moins chers à corriger.

Les accès ensuite. Passez en revue qui peut entrer où : comptes d’anciens salariés ou de prestataires partis, droits administrateurs distribués trop largement, absence de double authentification sur les consoles critiques. Une matrice d’accès à jour se construit en quelques jours et répond d’avance à toute une série de questions.

La stratégie de tests, en version honnête. Ne courez pas après un pourcentage de couverture : des tests écrits en urgence pour gonfler un chiffre se repèrent immédiatement, et font plus mauvais effet que des trous assumés. Protégez les chemins critiques, et sachez expliquer votre stratégie : ce qui est testé, ce qui ne l’est pas, et pourquoi.

La documentation enfin, en visant juste. Un document d’architecture de cinq à dix pages, à jour, avec les flux de données et les dépendances externes, vaut mieux qu’un wiki exhaustif et périmé. Ajoutez un journal des incidents des douze derniers mois, même reconstitué de mémoire : il prouve que vous savez ce qui casse chez vous.

Ce qu’il ne faut pas faire

La pire dépense des 90 jours est la réécriture. Un chantier de refonte lancé pour l’audit sera à moitié fini au moment de l’audit, et une migration à moitié finie est le pire état possible : deux systèmes à comprendre, aucun terminé. Gelez les grandes manœuvres et livrez normalement ; la vélocité pendant la due diligence est elle-même un signal.

Ne maquillez rien. Une équipe que nous avons auditée présentait comme automatisée une fonctionnalité qui tournait en réalité à la main, un salarié exécutant chaque nuit ce que le pitch décrivait comme un pipeline. La découverte a coûté bien plus que l’aveu n’aurait coûté : à partir de là, chaque affirmation du management a été revérifiée, et le calendrier du deal s’est allongé d’autant.

La dette assumée vaut mieux que le vernis

Un registre de dette technique tenu à jour, avec le coût estimé de chaque élément et un ordre de traitement, est l’un des meilleurs signaux qu’une équipe vendeuse puisse produire. Il transforme la conversation : au lieu de découvrir des problèmes, l’auditeur vérifie une liste, et la dette devient un paramètre de négociation plutôt qu’une surprise. Les équipes matures savent dire "voilà ce que nous referions autrement, et voilà ce que cela coûte". C’est exactement ce qu’un fonds veut entendre, parce que c’est avec cette équipe qu’il va travailler plusieurs années.

Préparez aussi les entretiens, en particulier la session avec le CTO, qui pèse lourd dans la conclusion. Le CTO doit pouvoir raconter les pannes passées avec précision et sans posture défensive. C’est contre-intuitif, mais un récit de panne bien mené rassure davantage qu’une prétendue absence de pannes.

Si vous préparez une levée ou une cession, relisez votre dossier avec les yeux de l’équipe qui vous auditera. C’est le regard que nous appliquons dans nos audits techniques côté fonds, et il n’a rien de secret : de la vérification, de la cohérence, et une prime constante à l’honnêteté.