Technical due diligence : le guide de préparation du fondateur non-technique
L’e-mail arrive un mardi après-midi. Le lead investor de votre Série A est “presque prêt” et il a mandaté un cabinet de technical due diligence. L’équipe de TDD aura besoin d’un accès en lecture au dépôt, d’un appel de 60 minutes avec la personne qui gère le build et de la liste de tous les services tiers dont dépend le produit. Le kickoff, c’est lundi. Vous transférez l’e-mail à votre unique développeur et vous restez assis avec la question que chaque founder non-technique apprend à redouter le premier jour d’une vraie levée : qu’est-ce qui est sur le point d’arriver à mon entreprise.
La technical due diligence est un audit indépendant du logiciel, de l’infrastructure et des pratiques d’ingénierie d’une entreprise, commandé par un investisseur ou un acquéreur avant d’engager du capital. Elle existe pour répondre à une seule question : le produit que l’entreprise vend correspond-il à la réalité d’ingénierie derrière lui ? L’audit couvre la qualité du code, l’architecture, la sécurité, la capacité de l’équipe et la discipline opérationnelle qui tient le stack entier. Pour un founder non-technique, c’est la première fois qu’une personne extérieure, lampe à la main, vient regarder à l’intérieur de la boîte.
Voici le guide du founder pour cet audit. Ce que les investisseurs regardent vraiment, les sept red flags qui font tomber des deals et un playbook de quatre semaines de préparation qui en règle la plupart.
Ce qu’est la technical due diligence, concrètement
La définition de manuel tient en une phrase : la technical due diligence est la revue structurée qu’un acquéreur commande pour confirmer que ce qu’il achète ou finance tient techniquement la route. L’acquéreur est en général un fonds de venture capital en Série A ou B, un acquéreur stratégique en M&A, un fonds de private equity sur un growth deal, ou parfois un client enterprise sur le point de signer un contrat assez gros pour justifier l’exercice.
L’audit dure de une à quatre semaines. Il implique une petite équipe (en général deux à quatre ingénieurs d’un cabinet spécialisé comme Snyk, MEV, TechCXO ou une boutique comme Quandary Peak) qui déroule un playbook fixe : code review, entretien d’architecture, scan de sécurité, entretiens avec l’équipe et un rapport écrit remis à l’acquéreur. Le rapport ne va pas à l’entreprise auditée sauf si elle le demande. L’acquéreur le lit seul et décide quoi en faire.
Deux termes sont souvent utilisés de manière interchangeable, autant les démêler une bonne fois. Technical due diligence et technology due diligence sont, en pratique, la même chose. Certains cabinets préfèrent l’une, d’autres l’autre ; le livrable est identique. Dans la construction et l’immobilier, TDD désigne un processus complètement différent (audit structurel d’un bâtiment). Si un résultat de recherche sur le sujet ne mentionne pas le logiciel, ce n’est pas le document que vous cherchez.
Pourquoi cela vous arrive maintenant
La TDD apparaît à quatre moments précis de la vie d’une entreprise, et le déclencheur indique en général sur quoi l’audit va se concentrer.
Le premier, c’est une levée Série A. Le lead a lu le deck, a vu la démo et il teste maintenant si le produit tient à dix fois la charge actuelle. La TDD ici est forward-looking : cette équipe d’ingénierie peut-elle vraiment livrer la roadmap qui est sur le slide ?
Le deuxième, c’est la M&A. Soit un acquéreur stratégique veut absorber l’entreprise, soit un fonds de private equity veut une position de contrôle. Cette TDD est centrée sur le risque. L’acquéreur paie un multiple de revenu et il doit s’assurer qu’il n’achète pas en même temps un passif technique de la taille du prix d’achat.
Le troisième, c’est une levée late seed ou stratégique où un investisseur sophistiqué (Tiger, Sequoia, un bras de corporate venture de premier rang) fait une TDD légère dans le cadre de sa construction de conviction. Elle est plus courte, souvent juste une code review et un appel d’architecture, et tend à rester informelle.
Le quatrième, et celui que la plupart des founders ne voient pas venir, c’est le client flagship. Une banque, un réseau d’hôpitaux, un grand opérateur télécom : tout contrat assez gros pour justifier l’équipe juridique de l’acquéreur finit par inclure une clause exigeant une TDD avant l’entrée en vigueur. Nous l’avons vu frapper des entreprises pré-Série A qui pensaient que leur premier vrai audit n’arriverait que dans douze mois.
Quel que soit le cadre, le travail est le même. Ce qui change, c’est le niveau d’exigence.
Les quatre zones que les auditeurs sondent réellement
Enlevez les marques des cabinets et tout rapport de TDD couvre les mêmes quatre zones. La PAA préférée “quels sont les 4 composants de la due diligence” (financier, opérationnel, juridique, RH) est la mauvaise liste pour le logiciel ; celle-là, c’est la due diligence corporate générale. La version technique se découpe ainsi.
1. Code et architecture
L’équipe d’audit va cloner votre dépôt et le lire. Pas tout. Elle va échantillonner par dossier et par récence : qu’est-ce qui a changé la semaine dernière, qu’est-ce qui ressemble à la logique métier centrale, que dit le rapport de test coverage. Elle cherche du signal sur trois choses : le code est-il cohérent (une équipe l’a écrit, ou cinq prestataires sur trois ans), l’architecture est-elle cohérente (les frontières entre modules ont du sens, ou tout a fusionné en un seul monolithe), et est-il maintenable (un nouvel ingénieur peut-il ramp up en un mois, ou le bus factor est-il de un).
Ce qui vous tue ici, ce n’est pas le code laid. Les auditeurs s’attendent à du code laid ; le logiciel est toujours plus laid que ce que le founder croit. Ce qui tue, c’est l’incohérence : trois patterns différents pour le même problème, pas de tests, pas de documentation et aucun historique de versionnement qui explique les décisions.
2. Infrastructure et opérations
Comment le produit tourne-t-il réellement en production ? Où sont les serveurs (un vrai compte cloud sur AWS / GCP / Azure, ou le Linode personnel d’un founder sur lequel plus personne ne peut se connecter), à quoi ressemble le déploiement (une seule commande sur une pipeline CI, ou un développeur en SSH sur une machine à 23h), et qu’arrive-t-il quand quelque chose casse (une astreinte avec paging, ou un message Slack que personne ne lit jusqu’au lendemain matin).
Les auditeurs y tiennent parce que c’est la dimension la moins chère pour vérifier si l’entreprise est réelle. Belle démo plus infrastructure fragile, c’est le pattern de défaillance le plus courant qu’ils attrapent.
3. Sécurité et compliance
Quelqu’un a-t-il déjà fait tourner un vrai scan de sécurité ? Les secrets sont-ils dans des variables d’environnement ou collés en clair dans le codebase ? Existe-t-il un audit log de qui a accédé aux données clients ? Si l’entreprise vend à des secteurs régulés, les affirmations SOC 2 / HIPAA / RGPD du site correspondent-elles à la réalité d’ingénierie ?
C’est la zone où les résultats de TDD font le plus souvent tomber un deal directement. Un acquéreur cohabite avec du code en désordre. Il ne cohabite pas avec un constat de sécurité qui crée un passif réglementaire qu’il hériterait au closing.
4. Équipe et processus
L’équipe d’audit va interviewer vos développeurs individuellement. Elle va demander : comment décidez-vous quoi construire, qui fait les code reviews, que se passe-t-il en cas d’incident en production, et qu’arriverait-il si votre lead engineer partait demain. Les entretiens sont courts, et les auditeurs cherchent la cohérence entre ce que dit le founder et ce que dit l’équipe.
C’est ici que le problème du bus factor apparaît. Si les entretiens révèlent qu’une seule personne est la seule à comprendre un système critique, cette phrase atterrit dans le rapport et les termes du deal commencent à bouger.
Les sept red flags qui font tomber les deals
Sur chaque TDD que nous avons accompagnée avec un client, le rapport de l’auditeur tourne autour des mêmes quelques problèmes. Aucun n’est exotique. Tous se règlent avec du préavis.
Le premier, c’est un bus factor de un. Le lead engineer est la seule personne à avoir lu le codebase entier, et il n’existe aucune documentation qui survive à son départ. C’est le constat le plus courant et celui que les investisseurs prennent le plus au sérieux, parce qu’ils sont sur le point de signer un chèque qui dépend d’une personne qu’ils n’ont pas embauchée.
Le deuxième, c’est aucun historique de versionnement digne de ce nom. Le dépôt existe, mais le premier commit est “initial commit” avec 60 000 lignes balancées d’un coup. Impossible de voir qui a décidé quoi, ni quand. Cela signifie en général que le codebase a été migré (typiquement depuis la machine d’un freelance précédent) et que l’historique s’est perdu. Les auditeurs le pointent parce que cela veut dire que l’entreprise ne peut pas prouver que le code lui appartient.
Le troisième, c’est une propriété intellectuelle mal définie. Le travail a été fait par un prestataire, le contrat de développement logiciel ne comportait pas de clause de work-for-hire ou de cession d’IP, et l’entreprise, techniquement, n’est pas propriétaire du code qu’elle vend. Ce seul constat a déjà tué des deals au stade de la due diligence.
Le quatrième, c’est des secrets dans le dépôt. Clés d’API, mots de passe de base de données, tokens tiers, le tout en clair dans le codebase. Les auditeurs modernes lancent des scans automatiques de cela dans la première heure, et ils trouvent toujours quelque chose.
Le cinquième, c’est aucune observabilité en production. L’équipe ne sait pas quand l’application est tombée. Pas de monitoring d’uptime, pas d’error tracking, pas de logs lus par qui que ce soit. Quand l’auditeur demande “à quelle fréquence l’app tombe ?”, la réponse de l’équipe est “je ne sais pas, personne ne s’est plaint”.
Le sixième, c’est une dépendance excessive à un seul service tiers. Le produit, à l’inspection, n’est qu’une couche fine au-dessus de l’API d’un fournisseur. Si ce fournisseur change ses prix, déprécie l’endpoint ou tombe, l’entreprise tombe avec lui. L’audit quantifie cette exposition et lui colle un montant à côté.
Le septième, c’est une dette technique que l’équipe n’arrive pas à décrire. Pas l’existence de dette technique en tant que telle (chaque produit en a) mais l’incapacité à la pointer du doigt. Quand le lead engineer dit “le code va bien” mais que l’auditeur trouve trois migrations à moitié faites et un framework déprécié, l’écart entre ce que l’équipe sait et ce qui est réellement là devient le constat qui tue le deal.
Le playbook de quatre semaines de préparation à la TDD
Si vous avez quatre semaines de préavis avant le démarrage de l’audit (et la plupart des founders les ont, parce que le lead investor ou l’acquéreur le signale avant l’engagement formel), les sept red flags ci-dessus sont, presque toutes, réparables. Le playbook ci-dessous est celui que nous déroulons avec les clients qui affrontent leur première TDD.
Semaine un : propriété et inventaire
Confirmez par écrit que chaque ligne de code du dépôt a été écrite soit par un salarié sous contrat de travail standard, soit par un prestataire sous contrat de work-for-hire. Si le contrat d’un prestataire n’incluait pas de clause de cession d’IP, envoyez une lettre de cession d’une page et récupérez la signature avant le premier appel avec l’auditeur. C’est la réparation la moins chère, et celle qui a le plus gros downside si elle est ignorée.
Construisez un inventaire de chaque service externe dont dépend le produit : cloud provider, base de données, authentification, paiements, e-mail, analytics, monitoring. Une ligne par service : ce qu’il fait, qui paie la facture, qui a l’accès admin. L’auditeur va demander cette liste le premier jour. L’avoir prête signale du professionnalisme et vous épargne une semaine d’e-mails de relance.
Semaine deux : tuez le bus factor
Le problème du bus factor ne se règle pas entièrement en deux semaines, mais il se réduit de façon mesurable. Mettez votre unique développeur en binôme avec un deuxième ingénieur (un junior déjà présent, un prestataire de confiance, ou un studio partenaire) et faites-leur passer la semaine à lire le codebase ensemble. Rédigez à la main un document d’architecture d’une page : quels sont les composants principaux, qu’est-ce qui parle à quoi, qu’est-ce qui casse si un service précis tombe. Ce document fait davantage pour votre note d’audit que cent nouvelles features.
Si vous n’avez pas de deuxième ingénieur disponible et que le deal est assez gros pour le justifier, c’est la semaine pour faire venir un technical advisor. Un ingénieur senior qui a déjà vécu des TDDs côté audité peut lire votre codebase, identifier ce qui sera flagué et, dans certains cas, co-signer des décisions pendant les entretiens d’audit.
Semaine trois : nettoyez les constats évidents
Lancez un scanner de secrets gratuit sur le dépôt (le scanner natif de GitHub attrape les cas courants). Faites tourner les clés qui apparaissent. Déplacez chaque credential dans des variables d’environnement ou dans un secrets store managé. C’est un travail de deux jours qui évite le constat automatique le plus courant.
Mettez en place une observabilité de base. Sentry pour les erreurs, un monitor d’uptime simple (Better Stack, Pingdom, ou même un compte gratuit UptimeRobot) qui frappe votre URL de production chaque minute. Le but n’est pas une couverture parfaite. Le but est que, quand l’auditeur demande “comment savez-vous quand l’app est en panne ?”, vous ayez une réponse qui ne soit pas un haussement d’épaules.
Semaine quatre : documentation et répétition
Rédigez quatre documents courts : un README qui explique comment lancer le projet en local, un runbook de déploiement qui explique comment une release arrive en production, une note de réponse aux incidents qui explique quoi faire quand quelque chose casse et un overview de sécurité d’une page qui liste les données stockées et la façon dont elles sont protégées. Aucun n’a besoin d’être long. L’équipe d’audit vérifie qu’ils existent et qu’ils sont honnêtes, pas qu’ils soient peaufinés.
Faites un entretien à blanc avec votre développeur. Posez-lui les questions que vous savez que l’auditeur va lui poser, dans l’ordre où il va les poser. Enregistrez les réponses. La première fois que votre unique ingénieur entend “que se passerait-il si tu partais demain” ne peut pas être devant l’auditeur.
Ce qui se passe après le rapport
L’auditeur remet le rapport à l’acquéreur, pas à vous. Dans la plupart des cas, l’acquéreur partage au moins un résumé avec le founder pendant la négociation, surtout si les constats déplacent les termes du deal. Attendez-vous à trois issues possibles.
Rapport propre, deal qui se ferme aux termes initiaux. C’est rare pour un premier audit et cela mérite d’être célébré quand cela arrive.
Rapport mitigé, deal qui se ferme avec conditions. L’acquéreur conditionne le closing à de la remédiation (embaucher un deuxième ingénieur sous 60 jours, finaliser un SOC 2 sous six mois, transférer l’IP d’un prestataire précis). C’est l’issue la plus courante, et les conditions sont presque toujours négociables. Le calendrier de remédiation compte plus que le constat lui-même.
Rapport mauvais, deal qui se renégocie ou meurt. Le prix descend, les termes se resserrent, ou l’acquéreur s’en va. Les constats qui produisent cette issue se trouvent presque toujours dans les catégories IP, sécurité ou bus factor. Ce sont les sept red flags ci-dessus, dans leur pire version.
Les founders qui traversent le mieux une TDD sont ceux qui traitent l’audit comme une évaluation indépendante et payée de la santé de l’ingénierie, séparée du deal. Les constats sont utiles même quand le deal ne se ferme pas. Le rapport vous dit quoi réparer ensuite, sur l’argent de quelqu’un d’autre.
FAQ
Qu’est-ce que la technical due diligence ?
La technical due diligence est un audit indépendant du logiciel, de l’infrastructure, de la sécurité et des pratiques d’ingénierie d’une entreprise, commandé par un investisseur ou un acquéreur avant d’engager du capital. C’est la contrepartie technique de la due diligence financière.
Qu’est-ce que la technology due diligence ?
La même chose que la technical due diligence. Les deux termes sont interchangeables dans le contexte logiciel. Hors logiciel (construction, immobilier, énergie), “technical due diligence” peut désigner un autre processus, donc vérifiez le contexte.
Quels sont les quatre composants de la due diligence ?
Dans la due diligence corporate générale, les quatre composants sont financier, opérationnel, juridique et RH. La technical due diligence est un chantier à part, avec ses propres quatre zones : code et architecture, infrastructure et opérations, sécurité et compliance, et équipe et processus.
Comment préparer une technical due diligence en tant que founder non-technique ?
Déroulez le playbook de quatre semaines ci-dessus : confirmez la propriété de l’IP par écrit, construisez l’inventaire des services tiers, réduisez le bus factor en mettant un deuxième ingénieur sur le codebase, nettoyez les constats automatiques (secrets, absence d’observabilité) et rédigez les quatre documents courts que les auditeurs cherchent (README, runbook de déploiement, note d’incident, overview de sécurité). Si le deal est gros, faites venir un technical advisor pour les entretiens.
Combien coûte une technical due diligence ?
C’est l’acquéreur qui paie, pas l’entreprise auditée. Les engagements typiques vont de 15 000 à 75 000 dollars selon le périmètre et le cabinet. Pour le founder, le coût indirect est le temps de l’équipe consommé pendant la fenêtre de l’audit : en général deux à quatre semaines de distraction significative pour l’ingénierie.
Combien de temps dure une technical due diligence ?
De une à quatre semaines de travail actif pour l’équipe d’audit. Depuis le siège du founder, prévoyez six semaines de distraction partielle : préparation, audit, réponse au rapport.
Peut-on refuser certaines parties de l’audit ?
Techniquement oui, en pratique non. Tout ce qui est refusé devient un red flag dans le rapport. Le bon mouvement est de négocier le périmètre en amont avec l’acquéreur (certains cabinets sur-périmètrent par défaut) puis de coopérer pleinement sur ce qui est dans le périmètre.