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.
L'audit de code pré-investissement s'inscrit dans la due diligence technique plus large, avec une mission plus étroite : établir ce qui existe réellement, si la propriété est propre, et si cela peut porter le plan financé.
Mal cadré, il produit une liste de reproches de style. Bien cadré, il produit deux ou trois constats qui changent le deal.
Quels accès demander
Demandez-les avant de signer la term sheet. Une résistance à ce stade est instructive en soi.
- Accès en lecture à tous les dépôts — y compris l'infrastructure-as-code et les scripts de déploiement, où l'état réel des choses est souvent visible
- L'historique complet des commits, pas un instantané écrasé : l'historique révèle qui a vraiment construit le système et à quelle vitesse il avance
- Une présentation de l'architecture avec l'ingénieur qui l'a construite, une à deux heures
- L'accès au gestionnaire de tickets et, s'ils existent, aux comptes rendus d'incidents
- La liste des services tiers dont dépend le produit
Les huit questions auxquelles l'audit doit répondre
- Le code existant correspond-il à ce qui a été décrit dans le pitch ? (Le demoware et les intégrations qui sont en réalité des processus manuels sont fréquents.)
- Qui l'a écrit, et ces personnes sont-elles encore là ?
- La propriété intellectuelle est-elle propre — prestataires sous cession, aucun code copié sans licence, aucune contamination de licence par des dépendances GPL dans un produit propriétaire ?
- Qu'est-ce qui casse en premier sous le plan de croissance, et que coûte le déplacement de ce plafond ?
- Les données clients sont-elles isolées entre tenants, et l'autorisation est-elle appliquée côté serveur ?
- Pour tout ce qui est financier : existe-t-il un grand livre immuable, et chaque chemin monétaire est-il idempotent ?
- L'équipe peut-elle déployer en sécurité — automatisation, rollback, supervision ?
- Quelle part du produit leur appartient vraiment, par rapport à une fine enveloppe sur des fournisseurs qui peuvent changer leurs prix ou disparaître ?
Constats qui justifient une clause
| Constat | Conséquence typique |
|---|---|
| Cœur construit par des prestataires sans cession de PI | Clore avant le virement — remède juridique, pas technique |
| Pas de grand livre dans une société qui déplace de l'argent | Budget de remédiation financé dans le tour ; tranching possible |
| Exposition de données inter-tenants | Correction en condition suspensive |
| Dépendance fournisseur critique sans solution de repli | Risque de concentration divulgué ; parfois un covenant |
| Bus factor de un sur le système central | Package de rétention ou assurance homme-clé |
| Aucun déploiement automatisé | Chiffré dans le plan post-closing |
Ce qui ne mérite pas votre attention
Les auditeurs facturant au constat vous remettront une longue liste. L'essentiel n'a aucune importance pour une décision d'investissement :
- Préférences de framework ou de langage — tout choix a ses détracteurs
- Style de code et formatage incohérents
- Faible pourcentage global de couverture de test, quand les chemins argent et auth sont couverts
- Dépendances obsolètes sans vulnérabilité atteignable
- Documentation absente — vraiment courant, rarement décisif, peu coûteux à corriger
Si le rapport d'audit ne peut être résumé en trois phrases à votre comité d'investissement, il a été cadré comme un exercice d'ingénierie plutôt que d'investissement.
À quoi ressemble un bon livrable
- Un résumé d'une page en langage business, avec une position de risque globale claire
- Des constats classés par conséquence, chacun avec des preuves vérifiables par l'équipe de la cible
- Un coût de remédiation en semaines-ingénieur, pour le convertir en argent
- Un plan technique recommandé à 90 jours après le closing
- Une liste explicite de ce qui n'a PAS été examiné, pour que personne ne présume d'une couverture inexistante
Préciser les preuves attendues dans la commande
L'acheteur doit pouvoir remonter d'un constat important à sa source et comprendre les conséquences d'une correction.
- Identifier dépôt, commit, environnement et date de revue.
- Demander exemples, parcours concernés et hypothèses d'effort.
- Exiger les exclusions et une option de vérification ultérieure.
Questions fréquentes
Combien de temps prend un audit de code pré-investissement ?
Trois à dix jours ouvrés pour la plupart des cibles seed et Series A. Fintech, healthtech ou bases de code inhabituellement grandes prennent plus longtemps. Au-delà de deux semaines, vous achetez généralement du détail plutôt que des décisions.
La startup saura-t-elle que nous l'auditons ?
Oui — un audit utile exige un accès au dépôt et du temps d'ingénieur, c'est donc un processus coopératif. Les cibles sérieuses s'y attendent et sont généralement à l'aise ; une résistance inhabituelle mérite d'être notée en soi.
Peut-on auditer sans accès au code source ?
Superficiellement seulement. Sans le dépôt, on peut évaluer le produit en fonctionnement, la posture de sécurité publique et les signaux d'équipe, mais pas la propreté de la PI, l'architecture réelle ou la maintenabilité — qui sont généralement les constats qui comptent.
Et si l'audit trouve de graves problèmes ?
C'est un audit réussi, et cela met rarement fin au deal. La plupart des constats se convertissent en budget de remédiation, condition suspensive, financement par tranches ou ajustement de valorisation. Le vrai échec, c'est de découvrir les mêmes problèmes au sixième mois, quand ils coûtent bien plus cher.
Le réviseur doit-il recevoir une base de production ?
Pas par défaut. Préférer données synthétiques ou expurgées et accès limité. Étendre l'accès uniquement pour une question précise impossible à résoudre autrement.
Besoin d'un audit avant de virer les fonds ?
Des constats classés par conséquence business, une remédiation chiffrée en semaines-ingénieur, livrés en moins de deux semaines.
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 ?
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.