Data room technique : les documents à préparer, et ce que leur absence révèle
La data room technique d’une due diligence tient en une dizaine de pièces : le code et son historique, l’architecture, les dépendances et les fournisseurs, les incidents, les procédures d’exploitation, l’équipe et la facture cloud, plus les jeux d’évaluation et les journaux de production pour une cible IA. Nous les demandons toutes le premier jour, et rien n’oblige à produire un document nouveau ; il s’agit de rassembler ce qui existe.
Cette nuance fait la valeur de l’exercice. Une data room montre ce que l’équipe sait de son propre système, et la vitesse à laquelle elle sait le montrer. Les deux se lisent avant d’ouvrir le premier fichier.
La liste que nous envoyons au démarrage
- Accès en lecture aux dépôts de code, historique compris
- Schéma d’architecture et flux de données, daté
- Inventaire des dépendances et des fournisseurs (hébergeur, API, SaaS)
- Historique des incidents des douze derniers mois
- Procédures de déploiement, de sauvegarde et de restauration
- Organigramme technique et responsabilités
- Factures cloud des six derniers mois
- Pour l’IA : jeux d’évaluation, derniers résultats, journaux de production
Chaque pièce répond à une question. L’historique git dit comment les décisions se prennent et si la vélocité annoncée est réelle ; la facture cloud décrit l’architecture telle qu’elle tourne, souvent mieux que le schéma ; les procédures disent si quelqu’un d’autre que leur auteur peut faire tourner le système. Pour l’IA, les jeux d’évaluation disent si la cible mesure ses erreurs ou les découvre par ses clients.
Ce qu’une startup de vingt personnes peut fournir, et ce qu’elle ne peut pas
D’une équipe de vingt personnes, nous attendons un document d’architecture de quelques pages, une feuille de calcul des fournisseurs, une page d’incidents tenue dans l’outil interne, un README de déploiement qu’un nouvel arrivant a déjà suivi, et des factures exportées depuis la console cloud. Nous n’attendons ni plan de reprise d’activité testé chaque année, ni base de gestion de configuration, ni SBOM signé.
Trois choses ne se négocient pas, quelle que soit la taille. Savoir restaurer une sauvegarde, et l’avoir fait au moins une fois. Savoir qui détient les accès administrateur, anciens prestataires compris. Savoir ce que coûte l’infrastructure chaque mois. Une équipe de cinq personnes peut répondre aux trois en une demi-journée ; une équipe de cinquante qui ne le peut pas révèle un problème d’organisation.
Lire les absences
Une data room se lit autant par ce qui manque que par ce qu’elle contient. Pas d’historique d’incidents : soit personne ne les écrit, soit l’équipe préfère ne pas les montrer. Le premier cas est le plus fréquent et se vérifie en une question pendant l’entretien avec le CTO, qui sait toujours raconter la dernière panne. Pas de schéma à jour : le système vit dans les têtes, et le nombre de têtes décide du risque homme-clé.
Une documentation produite la veille se reconnaît à sa date de création, à un vocabulaire plus propre que le code, et à des composants introuvables dans les dépôts. Une date récente ne gêne pas en soi, puisque nous avons demandé des documents. Le problème apparaît quand le document décrit le système que l’équipe aurait voulu construire : nous le confrontons au code, et l’écart devient un constat.
Un accès au code accordé par morceaux, ou une facture cloud qui arrive après trois relances, pèse aussi. Au-delà du délai, qui décale le rapport d’autant, la réticence a souvent une raison : des ressources oubliées qui tournent depuis deux ans, un dépôt qui embarrasse, ou une facture réglée avec la carte personnelle d’un fondateur.
Mettre en confiance ou faire gagner du temps
Une data room de trois cents documents met en confiance pendant une heure. Constituée par un cabinet, bien classée, elle contient des politiques que l’équipe n’a jamais lues, et nous y passons plus de temps à chercher qu’à comprendre.
Une data room qui fait gagner du temps contient dix pièces cohérentes avec le code, une personne nommée qui répond dans la journée, et une liste de ce que l’équipe sait ne pas avoir, écrite par elle. Le temps gagné va à la lecture du code et aux entretiens, là où la due diligence produit ses conclusions. Elle pèse plus dans notre avis final, parce qu’elle dit comment cette équipe travaillera avec un investisseur pendant plusieurs années.
Côté fondateur : préparer la data room une semaine avant
La data room se prépare dans la semaine qui précède le démarrage, parce que deux des pièces demandent une vérification. Restaurez une sauvegarde sur un environnement de test et notez le temps que cela a pris. Relisez le schéma d’architecture en face du code et corrigez-le. Reconstituez les incidents de l’année à partir des canaux d’alerte, même de mémoire. Exportez les factures. Nommez la personne qui répondra à l’auditeur, et prévenez-la.
Ne rédigez pas de politiques qui n’existaient pas la semaine dernière, et ne lancez pas de nettoyage du code. La préparation utile se joue sur les 90 jours qui précèdent et porte sur ce qui se corrige ; ce qui se maquille se voit à la lecture.
Nous envoyons cette liste le jour du cadrage, et ce qui revient dans les quarante-huit heures nous apprend déjà beaucoup. Pour un fonds qui prépare une opération, c’est aussi la première chose que nous partageons en cadrant une due diligence technique, avant même de parler de calendrier.