Une checklist n'est utile que si chaque point a une conséquence attachée. Celle-ci est ordonnée par ce qui change réellement un deal.
Propriété et dépendances
Produit et exploitation
Correction et décision
Utilisez-la comme document de travail pendant la diligence. Chaque section indique quoi demander, quoi vérifier et — surtout — ce qu'une mauvaise réponse signifie commercialement. Les points sont classés par coût de l'erreur, pas par facilité de vérification.
Avant de commencer : quoi demander
- Accès en lecture à tous les dépôts, y compris l'infrastructure-as-code
- Historique complet des commits (pas un instantané écrasé — l'historique révèle qui a vraiment construit et à quelle vitesse)
- Présentation de l'architecture avec l'ingénieur qui l'a construite, 1 à 2 heures
- Accès au gestionnaire de tickets et aux comptes rendus d'incidents
- Liste des services tiers et de leurs conditions contractuelles
- Contrats de prestataires et documents de cession de PI
Section 1 — Intégrité de l'argent et des données (niveau deal)
| Vérification | Une mauvaise réponse signifie |
|---|---|
| Soldes dérivés d'un grand livre append-only ? | L'argent peut être faux en silence et irrécupérable — financer la remédiation ou renoncer |
| Clés d'idempotence sur chaque chemin de paiement ? | Les réessais peuvent débiter deux fois ; des pertes peuvent déjà exister sans être détectées |
| Argent stocké en entiers d'unités mineures ? | L'arithmétique flottante accumule l'erreur sur chaque transaction |
| Réconciliation avec le règlement du prestataire ? | Les écarts remontent via les réclamations clients |
| Piste d'audit immuable incluant les actions admin ? | Impossible de répondre au régulateur ou en cas de litige |
Section 2 — Sécurité et cloisonnement (niveau deal)
- Autorisation appliquée côté serveur à chaque requête, pas en masquant des éléments d'interface
- Isolation multi-tenant vérifiée par test, pas supposée à la lecture du code
- Secrets dans un gestionnaire, absents de l'historique git (vérifier l'historique, pas seulement HEAD)
- Quelles données réglementées sont stockées, où, et si c'est nécessaire
- Écart avec la certification qu'exige le go-to-market (SOC 2, ISO 27001, PCI DSS)
Section 3 — Propriété et juridique (niveau deal)
- Cession de PI signée par chaque prestataire et fondateur
- Revue des licences open source — contamination copyleft dans un produit propriétaire
- Code copié d'anciens employeurs (posez la question directement ; cela arrive)
- Dépendance fournisseur : ce qui casse si un prestataire clé change ses prix ou ferme
Section 4 — Architecture et montée en charge (élevé)
- Où le système casse sous la croissance du modèle financier — un chiffre précis, pas des assurances
- Le plafond de la couche de données : maître d'écriture unique, requêtes non bornées, couverture d'index face aux vrais patterns
- Isolation des pannes : une dépendance lente dégénère-t-elle en panne totale
- Courbe de coût d'infrastructure à 10× — l'unit economics survit-elle
- Architecture adaptée à la taille de l'équipe (un système distribué avec une petite équipe est un coût, pas un titre de gloire)
Section 5 — Capacité de livraison (élevé)
| Signal | Sain | Préoccupant |
|---|---|---|
| Fréquence de déploiement | Plusieurs fois par semaine | Mensuelle, planifiée, redoutée |
| Délai pour un petit changement | Heures à un jour | Semaines |
| Rollback | Une commande, répétée | Jamais testé |
| Détection d'incidents | Supervision interne | Signalements clients |
| Tests sur les chemins argent/auth | Présents | Absents quelle que soit la couverture globale |
Section 6 — Équipe et personne-clé (élevé)
- Bus factor de chaque sous-système critique — s'il vaut 1 quelque part, c'est un risque de deal à couvrir
- La connaissance existe-t-elle par écrit ou seulement dans les têtes
- Exposition à la rétention : qui serait catastrophique à perdre dans les 12 mois
- Réalisme du plan de recrutement que suppose la roadmap
Notation : la conséquence, pas le goût
Notez chaque constat sur ce qui se passe s'il n'est pas corrigé, et laissez cela guider la réponse contractuelle :
- Niveau deal — intégrité de l'argent, exposition de données, PI floue. Condition suspensive ou remédiation financée.
- Élevé — plafond de charge inférieur au plan, dépendance à une personne, aucune sécurité de déploiement. Chiffré dans le plan à 90 jours post-closing.
- Moyen — dette cumulative qui ralentit la livraison. Noter et surveiller.
- Bruit — style, préférence de framework, volume de documentation. À exclure entièrement du rapport.
Si un constat ne peut être relié à de l'argent, du temps ou une exposition juridique, il n'a pas sa place dans un mémo d'investissement.
Ce qu'il faut exiger dans le rapport final
- Un résumé d'une page exploitable par un associé non technique
- Chaque constat accompagné de preuves vérifiables indépendamment par l'équipe de la cible
- Des estimations de remédiation en semaines-ingénieur, pour les convertir en argent
- Une mention explicite de ce qui n'a PAS été examiné — pour que personne ne présume d'une couverture inexistante
Transformer la checklist en dossier de décision
Chaque réponse doit renvoyer à des preuves et à une conséquence pour l'opération. Convenez des limites, accès et questions avant la collecte. Distinguez constats vérifiés, déclarations de direction et pièces indisponibles. Une case vide ne prouve pas un faible risque.
| Rendre la décision mesurable | Les preuves à convenir avant de commencer |
|---|---|
| Propriété et dépendances | Demander historique du dépôt, accords des contributeurs et inventaire des dépendances. Le conseil juridique valide les droits. |
| Produit et exploitation | Suivre un parcours important, vérifier déploiement et restauration, confronter architecture et hypothèses de croissance. |
| Correction et décision | Associer responsable, effort, dépendances et vérification à chaque constat. Séparer conditions préalables et plan après transaction. |
Le rapport distingue ce qui a été examiné, l'inconnu et les conséquences possibles. Une revue documentaire seule ne valide pas les contrôles en production ; une revue technique ne constitue pas une certification juridique.
Questions fréquentes
Que doit contenir une checklist de due diligence technique ?
Six domaines, par ordre de conséquence : intégrité de l'argent et des données, sécurité et isolation des tenants, propriété intellectuelle, architecture et marge de montée en charge, capacité de livraison, et risque de personne-clé. Chaque point doit avoir une conséquence commerciale énoncée — une checklist sans conséquences produit des rapports sur lesquels personne n'agit.
Quel est l'élément le plus souvent oublié ?
La cession de PI par les prestataires. Ce n'est pas une question technique, donc les relecteurs techniques la sautent et les juristes supposent que l'ingénierie l'a couverte. C'est aussi ce qui a le plus long délai de correction, raison pour laquelle cela se vérifie les premiers jours et non les derniers.
Les fondateurs peuvent-ils utiliser cette checklist eux-mêmes ?
Oui, et c'est une bonne idée avant de lever. Les constats que vous découvrez vous-même deviennent un plan de remédiation que vous contrôlez ; les mêmes constats découverts par le conseil d'un investisseur deviennent une position de négociation contre vous.
Envie que cela soit mené par quelqu'un qui le fait chaque semaine ?
Nous livrons une diligence avec des constats classés par conséquence business et une remédiation chiffrée en semaines-ingénieur.
Pour aller plus loin
Due diligence technique pour investisseurs : le guide complet
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 ?
Ce que les VC regardent vraiment en due diligence technique
Les investisseurs ne notent pas votre code. Ils valorisent le risque que la technologie arrête le plan qu'ils financent — et les fondateurs qui le comprennent se préparent très différemment.