Audit de code avant une levée de fonds : préparer la due diligence technique côté fondateur

Ce que l'investisseur regardera dans votre code, ce qu'il faut corriger avant la data room, ce qui peut attendre, et comment organiser l'audit.

Points clés

  • Un audit commandé par vous, avant la levée, transforme des surprises en points connus et chiffrés. Celui de l'investisseur arrivera de toute façon ; mieux vaut qu'il ne trouve rien que vous ne sachiez déjà.
  • Le point qui bloque le plus souvent n'est pas technique, il est juridique : la société possède-t-elle vraiment son code ? En France, le code écrit par un freelance, une agence ou un fondateur avant la création de la société n'appartient pas automatiquement à la société.
  • Les licences open source et les dépendances vulnérables sont presque toujours concernées : l'étude OSSRA 2025 de Black Duck trouve des conflits de licence dans 56 % des applications auditées et des composants vulnérables dans 86 %.
  • Corrigez avant la data room ce qui touche à la propriété, aux failles critiques et aux sauvegardes. Le reste peut devenir une feuille de route chiffrée, financée par la levée.
  • Un investisseur ne cherche pas un code parfait. Il cherche une équipe qui connaît ses risques et sait les expliquer.

Une levée de fonds se joue d'abord sur le marché, l'équipe et la traction. Mais à partir du moment où le produit est le cœur de la valeur, un investisseur sérieux voudra savoir ce qu'il achète : il fera relire le code, l'architecture et les contrats par quelqu'un de confiance, souvent un ancien CTO ou un cabinet spécialisé. Ce guide prend le point de vue du fondateur : ce que cette relecture va chercher, comment la préparer, et quoi corriger avant. Si vous êtes de l'autre côté de la table, notre guide de la due diligence technique avant une acquisition ou un investissement décrit la démarche côté acheteur.

Pourquoi faire auditer son code avant l'investisseur

La due diligence technique de l'investisseur arrive tard, quand le calendrier est serré et que chaque point découvert devient un sujet de négociation : une condition suspensive, une garantie supplémentaire, un ajustement de valorisation, ou simplement un doute qui ralentit tout. Un audit commandé en amont change trois choses :

  • Vous connaissez vos risques avant lui. Un problème que vous présentez vous-même, avec son plan de correction, pèse beaucoup moins qu'un problème qu'on découvre à votre place.
  • Vous avez le temps de corriger. Céder des droits, retirer un composant sous licence incompatible ou mettre en place des sauvegardes testées prend des semaines, pas des jours.
  • Vous arrivez avec des documents. Un rapport récent, une liste des dépendances et un schéma d'architecture répondent d'avance à la moitié des questions.

Ce que regarde un relecteur technique

1. La propriété du code

C'est le premier point, et le plus souvent sous-estimé. En droit français, les droits sur un logiciel créé par un salarié dans l'exercice de ses fonctions reviennent à l'employeur (Code de la propriété intellectuelle, article L113-9). Pour tous les autres, freelances, agences, stagiaires hors cas particuliers et fondateurs avant la création de la société, il faut une cession écrite, qui précise les droits cédés, leur étendue, leur durée et le territoire (article L131-3).

Ce qu'on vous demandera : la liste de toutes les personnes et sociétés qui ont écrit du code, et pour chacune le contrat qui cède les droits à la société. Le cas typique qui fait tiquer : le premier prototype écrit par un freelance ou par un cofondateur avant l'immatriculation, sans aucun acte de cession. Notre guide sur la propriété du code source détaille ces règles.

2. Les licences open source

Toute application moderne repose sur des centaines de composants open source. La question n'est pas d'en avoir, mais de respecter leurs licences. L'étude OSSRA 2025 de Black Duck a trouvé des conflits de licence dans 56 % des applications auditées (Black Duck). Le point d'attention classique pour un SaaS : une bibliothèque sous licence AGPL, qui peut obliger à publier le code de l'application qui l'utilise à travers le réseau (GNU AGPL v3).

Ce qu'on vous demandera : un inventaire des dépendances avec leurs licences. Un SBOM (software bill of materials) au format SPDX se génère automatiquement et répond à la question.

3. La sécurité et les données

Le relecteur cherche les failles évidentes plutôt qu'un test d'intrusion complet : secrets (clés d'API, mots de passe) présents dans l'historique du dépôt, contrôle d'accès vérifié côté serveur, dépendances non mises à jour, données personnelles mal protégées. La même étude OSSRA trouve des composants open source vulnérables dans 86 % des applications, dont 81 % avec au moins une vulnérabilité à risque élevé ou critique. Si vous traitez des données personnelles, attendez-vous à des questions sur l'article 32 du RGPD et sur vos sous-traitants.

Des outils gratuits comme Gitleaks ou l'analyse des secrets de GitHub trouvent les secrets oubliés en quelques minutes. Pour un référentiel plus complet, l'OWASP ASVS est la grille la plus utilisée.

4. L'architecture face au plan de croissance

Votre deck annonce dix fois plus de clients dans deux ans. Le relecteur se demande si l'architecture actuelle peut suivre, et sinon ce que coûtera l'adaptation. Une architecture simple n'est pas un défaut ; un plan de croissance qui suppose une réécriture complète non budgétée en est un.

5. La dépendance aux personnes

Combien de personnes comprennent vraiment le système ? Si la réponse est « une », et que c'est un freelance ou un associé qui ne fera pas partie de l'aventure, c'est un risque majeur aux yeux d'un investisseur. Documentation, revues de code et au moins deux personnes capables de déployer sont les réponses attendues.

6. Les pratiques de l'équipe

Tests automatisés sur les parcours critiques, intégration continue, déploiements reproductibles, sauvegardes testées, suivi des erreurs en production, coût de l'infrastructure. Les métriques DORA (fréquence de déploiement, délai de mise en production, taux d'échec, temps de rétablissement) sont un langage que beaucoup de relecteurs utilisent.

Corriger avant, ou présenter comme feuille de route ?

Vous n'aurez pas le temps de tout régler, et ce n'est pas ce qu'on attend de vous. La règle simple : corrigez ce qui remet en cause la propriété, la sécurité des données ou la continuité du service ; présentez le reste comme un plan chiffré.

ConstatÀ corriger avant la data roomPeut rester sur la feuille de route
Code écrit par un freelance ou un fondateur sans cession écriteOui : faites signer les cessions
Composant sous licence incompatible avec votre modèleOui : remplacez-le ou obtenez une licence commerciale
Secrets dans le dépôt, faille critique connueOui : révoquez, corrigez, documentez
Pas de sauvegarde, ou sauvegardes jamais restauréesOui
Dépendances anciennes sans faille critiqueOui, avec un calendrier de mise à jour
Couverture de tests faible hors parcours critiquesOui
Architecture à faire évoluer pour la croissance annoncéeOui, avec une estimation
Documentation incomplèteEn partie : le minimum pour qu'un tiers comprenne et déploieLe reste

La feuille de route a une vertu : elle montre que vous savez où va l'argent levé côté technique, ce qui est exactement ce qu'un investisseur veut entendre.

Comment s'organiser

  1. Lancez l'audit avant d'ouvrir la data room, en gardant assez de marge pour corriger ce qui doit l'être. Les cessions de droits et les remplacements de composants sont les plus longs.
  2. Choisissez un auditeur indépendant de l'équipe qui a écrit le code. Un rapport rédigé par vos propres développeurs n'a pas la même valeur aux yeux d'un investisseur.
  3. Donnez-lui un accès complet : dépôt, historique, infrastructure, contrats des prestataires. Un audit sur un extrait ne rassure personne.
  4. Corrigez les points bloquants, puis demandez une vérification rapide des corrections.
  5. Préparez la partie technique de la data room : le rapport ou sa synthèse, le SBOM, les cessions de droits, un schéma d'architecture, la politique de sauvegarde, la liste des sous-traitants traitant des données personnelles.

Sur une application Next.js, notre article audit de code Next.js : ce que nous vérifions donne une première passe à faire vous-même ; ce que comprend un audit technique décrit le périmètre complet.

Questions fréquentes

Les investisseurs font-ils vraiment relire le code dès l'amorçage ? Pas systématiquement. En amorçage, la relecture se limite souvent à un entretien avec le CTO et à quelques questions sur la propriété du code. Elle devient plus fréquente et plus approfondie à partir de la série A, et quasi systématique quand le produit technique est l'actif principal. Dans tous les cas, la propriété du code est vérifiée.

Notre CTO peut-il faire cet audit lui-même ? Il peut et doit préparer le terrain : inventaire, SBOM, documentation. Mais un regard extérieur trouve ce que l'équipe ne voit plus, et un rapport indépendant pèse davantage auprès d'un investisseur.

Un rapport d'audit avec des problèmes va-t-il faire fuir l'investisseur ? Rarement, s'il est accompagné d'un plan. Aucun code n'est parfait. Ce qui inquiète, c'est un problème découvert par l'investisseur et dont l'équipe ignorait l'existence.

Faut-il faire signer un accord de confidentialité à l'auditeur ? Oui, avant de donner accès au code. C'est la norme, et un auditeur sérieux le propose de lui-même.

FNB Solutions réalise des audits techniques indépendants pour les fondateurs qui préparent une levée, comme pour les investisseurs qui l'examinent. Voir notre offre d'audit technique, ou parlez-nous de votre calendrier.

Sources

Tous les articles →