Due diligence technique : 8 points vérifiés par les investisseurs

Un fonds m'a envoyé un repo GitHub à auditer un vendredi soir. La startup levait 1,2 million d'euros. Le fondateur était confiant — son app tournait, il avait du trafic, ses métriques étaient bonnes.

Le lundi matin, j'ai rendu mon rapport. Zéro test unitaire dans tout le projet. Pas un seul. Le fonds a fermé le dossier dans la semaine.

Ce n'est pas le zéro test en lui-même qui a tué le deal. C'est ce que ça révélait : personne dans cette boîte ne savait si le code fonctionnait réellement, ni ce qui casserait à la prochaine modification. Pour un investisseur qui met plus d'un million sur la table, c'est un risque impossible à accepter.

Si vous préparez une levée de fonds, votre code va être passé au crible. Voici exactement ce que les auditeurs cherchent — et comment éviter les mauvaises surprises.

Pourquoi les investisseurs demandent un audit de code

Il y a cinq ans, seuls les fonds spécialisés tech faisaient auditer le code avant de signer. Les fonds généralistes regardaient le marché, l'équipe, les métriques — et faisaient confiance sur la partie technique.

Ça a changé. Un fonds avec lequel je travaille régulièrement ne signe plus aucun deal sans audit de code préalable. Il s'est fait brûler sur un investissement en 2023 : la startup avait une belle traction, mais le code était si fragile qu'il a fallu tout réécrire six mois après la levée. L'argent censé financer la croissance a servi à reconstruire les fondations.

Depuis, c'est systématique. Et ce fonds n'est pas un cas isolé. La multiplication des outils d'IA qui génèrent du code — Cursor, Lovable, Bolt — a amplifié le phénomène. Les investisseurs savent qu'un produit peut avoir l'air solide en surface et être un château de cartes en dessous.

Les 8 points passés au crible

Quand un fonds me mandate pour une due diligence technique, je ne lis pas le code ligne par ligne pendant trois semaines. Je vérifie huit points précis. Ce sont les mêmes à chaque fois, parce que ce sont ceux qui déterminent si un investissement technique est un pari raisonnable ou une loterie.

1. La sécurité des données

Premier réflexe : chercher des secrets en clair dans le code. Clés API, tokens, mots de passe de base de données. C'est le problème le plus fréquent et le plus immédiatement disqualifiant. Un fichier .env poussé sur GitHub, c'est l'équivalent de laisser les clés de votre bureau sur la porte d'entrée.

Ensuite, je regarde comment les données sensibles de vos utilisateurs sont protégées. Chiffrement, contrôle d'accès, politique de mots de passe. Si vos utilisateurs vous confient des données personnelles et que vous les stockez en clair, c'est un risque juridique en plus d'un risque technique.

2. La propriété intellectuelle

Qui possède réellement le code ? La question paraît simple. En pratique, c'est un nid de problèmes.

J'ai vu une startup dont 80% du code avait été écrit par un freelance sur Malt. Le contrat ne mentionnait pas la cession de propriété intellectuelle. Légalement, le freelance était toujours propriétaire du code. L'investisseur a demandé une régularisation avant de signer — ça a retardé le closing de deux mois et coûté 8 000€ en frais juridiques.

Si vous avez des cofondateurs, des freelances, des stagiaires qui ont contribué au code : vérifiez vos contrats. Maintenant. Pas la veille de la due diligence.

3. Les tests automatisés

C'est le point qui fait le plus de dégâts. Pas parce que les investisseurs sont obsédés par la couverture de tests — mais parce que l'absence totale de tests envoie un signal clair : chaque modification du produit est un acte de foi.

Personne ne s'attend à 90% de couverture sur un produit early-stage. Mais zéro test sur les fonctions critiques — paiement, authentification, accès aux données — c'est un red flag. Ça veut dire que personne ne peut garantir que l'app continue de fonctionner après une mise à jour. Pour un investisseur, c'est du risque pur.

4. L'architecture et la scalabilité

Est-ce que votre produit peut encaisser dix fois plus d'utilisateurs sans tout reconstruire ? L'auditeur ne cherche pas une architecture parfaite. Il cherche des signes que ça tiendra la charge — ou au contraire, des signaux d'alarme.

Un monolithe bien structuré, c'est parfaitement acceptable en early-stage. Un plat de spaghetti où le front-end, le back-end et la base de données sont mélangés dans les mêmes fichiers, beaucoup moins.

5. La dette technique

Toute startup a de la dette technique. C'est normal — vous avez priorisé la vitesse sur la propreté pour valider votre marché. L'auditeur ne cherche pas un code immaculé. Il mesure le volume de cette dette et évalue si elle est gérable ou si elle va paralyser l'équipe dans six mois.

C'est sur ce point que j'ai vu la décote la plus brutale. Une startup visait une valorisation de 3 millions d'euros. L'audit a révélé que la même logique métier était copiée-collée dans 15 fichiers différents, que les dépendances n'avaient pas été mises à jour depuis 18 mois, et que corriger le moindre bug prenait trois fois plus de temps que nécessaire. Le fonds a proposé 2 millions. 30% de décote en 48 heures, uniquement à cause de la dette technique. Le fondateur a accepté — il n'avait pas vraiment le choix.

6. Les dépendances et licences open source

Votre produit utilise probablement des dizaines de bibliothèques open source. Chacune a une licence. Et certaines licences — comme la GPL — sont "virales" : si vous utilisez du code sous GPL, tout votre code doit être open source aussi. Pour une startup qui lève des fonds, c'est un problème.

L'auditeur vérifie aussi si vos dépendances ont des vulnérabilités connues. Une faille critique dans une bibliothèque que vous utilisez, c'est une faille critique dans votre produit.

7. L'infrastructure et les déploiements

Comment votre produit est-il déployé ? Qui a les accès aux serveurs ? Existe-t-il des sauvegardes ? Un monitoring ?

J'ai audité une startup où le déploiement se faisait manuellement par le CTO depuis son ordinateur portable. Pas de pipeline automatisé, pas de serveur de staging. Si le CTO se faisait renverser par un bus, personne ne savait mettre le produit à jour. L'investisseur a exigé un plan de remédiation avant de signer.

8. La compétence de l'équipe technique

C'est le point le plus subjectif — et paradoxalement le plus déterminant. L'auditeur échange avec l'équipe technique. Il pose des questions sur les choix d'architecture, les compromis faits, les problèmes rencontrés.

Ce qu'il cherche, ce n'est pas un sans-faute. C'est la lucidité. Un CTO qui dit "on a de la dette technique ici, on sait pourquoi, et voilà notre plan pour la résorber" rassure infiniment plus qu'un CTO qui répond "tout va bien, le code est propre" alors que le rapport dit le contraire.

Si vous n'avez pas de directeur technique en interne, c'est le moment d'en trouver un — ne serait-ce que pour la durée de la due diligence. Quelqu'un doit pouvoir répondre aux questions de l'auditeur sans dire "je ne sais pas, c'est le freelance qui a fait ça".

Ce qui compte vraiment : la maîtrise, pas la perfection

Après avoir fait des dizaines d'audits pour des investisseurs, voici ce que j'ai compris : le code parfait n'existe pas en early-stage, et les investisseurs le savent.

Ce qui fait la différence entre un deal signé et un deal mort, ce n'est pas la qualité absolue du code. C'est la capacité du fondateur et de son équipe à expliquer leur produit, identifier ses faiblesses, et présenter un plan crédible pour les corriger.

J'ai vu un fondateur lever 800K€ avec un codebase moyen — parce qu'il avait fait auditer son code en amont, corrigé les failles critiques, et préparé un document d'une page expliquant la dette technique restante et le calendrier de remédiation. L'investisseur a signé en trois semaines.

Et j'ai vu un fondateur avec un produit techniquement supérieur échouer — parce qu'il ne savait pas expliquer comment fonctionnait l'authentification de sa propre app.

Comment préparer votre due diligence technique

La règle est simple : découvrez les problèmes avant que l'investisseur ne les découvre.

Faites réaliser un audit de code 4 à 6 semaines avant d'envoyer votre data room. Pas 4 jours — 4 semaines. Parce qu'il faut du temps pour corriger ce que l'audit va trouver. Un audit technique pre-levée coûte entre 2 000 et 5 000€ selon la taille de votre codebase. Rapporté à un deal de 500K à 2M€, c'est une assurance dérisoire.

Si vous avez construit votre produit avec des outils comme Lovable, Bolt ou Cursor, les points de vigilance sont encore plus spécifiques — j'en parle en détail dans cet article sur le vibe coding et la levée de fonds.

Checklist due diligence technique — les 8 points

Avant de partager votre code avec un investisseur, passez cette grille :

Si vous avez des red flags sur les points 1, 2 ou 3, réglez-les en priorité. Ce sont ceux qui tuent les deals.

Si vous recevez un rapport d'audit et que vous ne savez pas par où commencer, j'ai écrit un guide pour lire un rapport d'audit quand on n'est pas développeur.

Ce qu'il faut retenir

La due diligence technique n'est plus une option. Les fonds qui ne la faisaient pas il y a cinq ans la font aujourd'hui. Et ceux qui la faisaient sont devenus plus exigeants.

Mais le bar n'est pas inatteignable. Vous n'avez pas besoin d'un code parfait pour lever. Vous avez besoin de maîtriser votre sujet, de connaître vos faiblesses, et de montrer que vous avez un plan. Faites auditer votre code avant que l'investisseur ne le fasse — vous préférez corriger les problèmes vous-même plutôt que les découvrir pendant la négociation.