La due diligence technique n'est pas une revue de code. C'est la réponse à une question : combien coûtera-t-il d'amener cette technologie là où la thèse d'investissement en a besoin ?
La plupart des due diligences techniques produisent un document que personne n'utilise. Il liste des frameworks, compte des tests, note que la documentation pourrait être meilleure — puis le deal se fait ou ne se fait pas pour des raisons totalement étrangères. C'est gâcher une véritable occasion de valoriser le risque.
Une due diligence technique utile répond à trois questions en termes business : cette technologie peut-elle soutenir le plan que vous financez, combien coûtera la fermeture des écarts, et quels risques peuvent détruire de la valeur plutôt que simplement la ralentir.
À quoi sert réellement la due diligence technique
Un investisseur en capital-risque n'achète pas une base de code. Il achète une thèse : cette équipe atteindra cette échelle dans ce délai. La technologie ne compte que là où elle rend cette thèse plus ou moins probable.
| La thèse dit | Donc la diligence doit établir |
|---|---|
| Croissance ×10 des utilisateurs en 24 mois | Où l'architecture casse, et le coût pour déplacer ce plafond |
| Expansion vers l'UE | Si le traitement des données survit au RGPD, et ce que coûte une version conforme |
| C'est une activité de paiement | Intégrité du grand livre, idempotence, réconciliation — ce qui perd de l'argent réel |
| L'équipe sait exécuter | Débit de livraison et bus factor, pas la qualité des CV |
| Technologie défendable | Si la barrière est de l'ingénierie réelle ou une fine couche sur l'API d'un tiers |
Les cinq domaines qui comptent
1. Architecture et marge de montée en charge
Tout système a un plafond. La question est de savoir où il se situe par rapport au plan, et combien coûte son relèvement. Un monolithe qui sert 100 000 utilisateurs sans peine n'est pas un constat ; un monolithe avec une base de données à maître d'écriture unique et un plan de croissance à 10 millions, si.
- Les points uniques de défaillance — et si l'équipe sait lesquels
- La couche de données — généralement le vrai plafond, et la chose la plus coûteuse à changer plus tard
- Si la charge a déjà été testée, ou si la montée en charge est supposée
- Courbe de coût cloud : l'unit economics survit-elle à ×10, ou l'infrastructure mange-t-elle la marge ?
2. Intégrité de l'argent et des données
Pour toute entreprise touchant aux paiements, aux soldes ou aux données réglementées, c'est le domaine où l'erreur coûte le plus cher — et celui qu'on saute le plus souvent, car son inspection exige une expertise métier.
- Le solde est-il dérivé d'un grand livre immuable, ou est-ce un nombre modifiable que le code peut écraser ?
- Idempotence sur les chemins de paiement et de webhook — un réessai peut-il débiter deux fois ?
- Argent stocké en entiers d'unités mineures, jamais en flottants
- Réconciliation : un écart serait-il détecté en interne, ou par un client ?
3. Exposition sécurité et conformité
Les constats de sécurité n'ont de sens que reliés à une conséquence. « Les dépendances sont obsolètes » est du bruit. « Un endpoint non authentifié renvoie les enregistrements d'autres clients » est une clause contractuelle.
- Autorisation appliquée côté serveur à chaque requête, pas cachée dans l'interface
- Isolation multi-tenant — de loin le constat sérieux le plus fréquent en SaaS B2B
- Gestion des secrets, et si des identifiants traînent dans l'historique git
- Quelles données réglementées sont stockées — et si elles devraient l'être
- Écart avec la certification qu'exige le go-to-market (SOC 2, ISO 27001, PCI DSS)
4. Capacité de livraison
Cela prédit les deux prochaines années mieux que la base de code actuelle. Une base de code médiocre avec une forte discipline de livraison s'améliore. Une base de code élégante sans capacité à livrer sûrement, non.
- Fréquence de déploiement et délai pour un petit changement
- Si le rollback est une routine éprouvée ou une théorie
- Couverture de test sur les chemins qui comptent (argent, auth) plutôt qu'un pourcentage global
- Détection d'incidents : trouvent-ils les problèmes avant les clients ?
5. Risque équipe et personne-clé
- Bus factor : combien de personnes comprennent les sous-systèmes critiques — si la réponse est « une », c'est un risque de deal
- Si la connaissance existe hors des têtes
- Dépendance à des prestataires sur la PI centrale, et si la cession de PI est propre
- Réalisme du plan de recrutement face à la roadmap financée
Signaux d'alerte, classés par ce qu'ils coûtent vraiment
| Constat | Gravité | Pourquoi |
|---|---|---|
| Soldes modifiables / pas de grand livre dans une fintech | Niveau deal | Les pertes sont illimitées et peuvent avoir déjà eu lieu sans être détectées |
| Accès aux données inter-tenants | Niveau deal | Une divulgation met fin aux ventes entreprise et alerte les régulateurs |
| Un seul ingénieur détient tout le savoir critique | Élevée | Son départ réinitialise la roadmap |
| Aucune automatisation de déploiement | Élevée | Plafonne le débit quels que soient les recrutements |
| Propriété intellectuelle floue côté prestataires | Élevée | Juridique, pas technique — mais tue les sorties |
| Dépendances obsolètes | Faible | Maintenance de routine, chiffrée en jours |
| Style de code incohérent | Bruit | À ignorer |
L'objet de la due diligence technique n'est pas de trouver une raison de renoncer. C'est de savoir précisément ce que vous achetez, pour que le prix et le plan le reflètent.
Comment les constats deviennent des clauses du deal
- Budget de remédiation — chiffrer les corrections et les financer explicitement dans le tour plutôt que de les découvrir au sixième mois
- Conditions de jalons — déblocage de tranche lié à une remédiation précise (courant quand des écarts de conformité bloquent le go-to-market)
- Ajustement de valorisation — là où la remédiation est importante au regard du tour
- Plan post-closing — une roadmap technique à 90 jours convenue avant le virement, pas improvisée après
Combien de temps cela prend
| Profondeur | Durée | Quand l'utiliser |
|---|---|---|
| Screening | 2-3 jours | Amorçage, petit ticket, simple contrôle de cohérence |
| Standard | 1-2 semaines | La plupart des tours Series A / Series B |
| Approfondie | 3-4 semaines | Fintech, healthtech, gros ticket, ou cible réputée désordonnée |
Plus long n'est pas meilleur. Au-delà de deux semaines, la plupart des missions produisent du détail plutôt que des décisions — sauf si le domaine l'exige réellement, comme les paiements ou les données de santé réglementées.
Délimiter la revue avant la collecte des preuves
La revue doit refléter la thèse d'investissement. Définir questions, systèmes essentiels et preuves avant de noter le risque.
- Relier croissance prévue, capacité et coûts d'exploitation observés.
- Séparer déclarations, tests vérifiés et informations indisponibles.
- Distinguer conditions de clôture et plan financé après acquisition.
Questions fréquentes
Quelle différence entre due diligence technique et audit de code ?
Un audit de code examine la qualité du code. La due diligence technique examine si la technologie, l'équipe et le processus de livraison peuvent soutenir un plan d'affaires précis — et ce que coûtent les écarts. Le code n'est qu'un intrant sur cinq ; architecture, sécurité, capacité de livraison et risque de personne-clé pèsent généralement davantage dans la décision d'investissement.
Qui paie la due diligence technique ?
Presque toujours l'investisseur, au titre des frais de transaction. Parfois un fondateur la commande avant la levée pour trouver et corriger les problèmes avant les investisseurs — argent généralement bien dépensé, car les constats découverts par la partie adverse coûtent bien plus en négociation qu'en ingénierie.
Faut-il la coopération de la startup ?
Oui. Une diligence significative exige un accès en lecture au dépôt, une présentation de l'architecture et une conversation avec les ingénieurs. Une cible qui y résiste constitue elle-même un constat à noter.
Une due diligence technique peut-elle se faire en quelques jours ?
Une passe de screening, oui, et elle attrapera de façon fiable les problèmes de catégorie : pas de grand livre dans une société de paiement, pas d'automatisation de déploiement, bus factor de un. Elle ne vous dira pas ce que coûte la remédiation. Pour un tour valorisé, une à deux semaines sont le minimum réaliste.
Peut-on poursuivre avec un accès limité ?
Oui, avec un périmètre réduit et des limites explicites. Documenter l'incertitude et demander les preuves nécessaires avant de considérer la conclusion comme établie.
Une diligence sur une société de votre portefeuille ?
Nous livrons des constats classés par impact business, avec des coûts de remédiation exploitables en négociation — en une à deux semaines.
Pour aller plus loin
Audit de code pré-investissement : que demander avant de virer les fonds
Vous êtes sur le point d'acheter une part d'un actif que vous n'avez pas inspecté. L'audit de code est l'inspection — mais seulement s'il est cadré pour répondre à des questions d'investissement, pas d'ingénierie.
Audit technique de MVP : ce que nous vérifions dans les 48 premières heures
La plupart des audits de MVP produisent un document. Un audit utile produit des décisions : ce qui brûle, ce qui peut attendre, et ce que coûte la correction.