Vibe coding et levée de fonds : préparer la due diligence

J'ai vu un deal de 500K€ mourir à cause d'un fichier que le fondateur ne savait même pas qu'il existait.

Son app marchait. Du trafic, des premiers revenus, une roadmap crédible. L'investisseur était quasi convaincu. Sauf qu'il a demandé un audit technique avant de signer. Et dans le code, poussé sur un repo GitHub public, il y avait un fichier .env avec les clés API Stripe en clair. N'importe qui pouvait les récupérer.

L'investisseur a fermé le dossier. Pas à cause du fichier — ça se corrige en cinq minutes. Mais parce que ça révélait quelque chose de plus profond : personne ne maîtrisait la technique dans cette boîte.

Si vous avez construit votre app avec Cursor, Bolt ou Lovable et que vous préparez une levée, cet article est pour vous. Pas pour vous faire peur — pour vous éviter de perdre un deal bêtement.

Le vibe coding, en deux mots

Le terme vient d'Andrej Karpathy, ex-directeur IA chez Tesla et cofondateur d'OpenAI. L'idée : vous décrivez ce que vous voulez en langage naturel, et une IA génère le code. Vous ne codez plus — vous pilotez.

Cursor, Bolt, Lovable, Replit Agent — les outils se multiplient. Et ils sont bluffants. En quelques heures, un fondateur non-technique peut avoir un MVP fonctionnel avec un design propre qui tourne en production.

Sauf que "ça tourne" et "c'est solide", ce sont deux choses très différentes. Et les investisseurs commencent à le comprendre.

Ce que les investisseurs trouvent quand ils regardent le code

Je fais des audits de code pour des fonds et des startups. Voici ce qui revient systématiquement sur du code généré par IA.

Des secrets en clair dans le code source

Clés API, tokens d'authentification, mots de passe de base de données — directement dans les fichiers, parfois poussés sur GitHub en public. C'est le problème le plus fréquent et le plus grave. L'IA génère du code qui fonctionne, pas du code sécurisé. Elle met les clés là où c'est le plus simple, pas là où c'est le plus sûr.

L'authentification côté client

L'IA a tendance à mettre la vérification des droits d'accès dans le navigateur plutôt que sur le serveur. Concrètement, un utilisateur un peu malin peut contourner toutes vos protections en modifiant le JavaScript dans son navigateur. C'est comme un coffre-fort dont la serrure est collée sur la porte avec du scotch.

Zéro test

Sur les audits de code vibe-codé que j'ai réalisés, je n'ai encore jamais trouvé un seul test automatisé. Pas un. Ça veut dire que personne ne peut vérifier que l'app continue de fonctionner quand on modifie quelque chose. Pour un investisseur, c'est un signal clair : toute évolution du produit est un risque.

Du code dupliqué partout

La même logique copiée-collée dans 12 fichiers différents. Ça marche, mais le jour où il faut corriger un bug, il faut le corriger 12 fois. On en oublie toujours.

Le vrai red flag, ce n'est pas le code

Voilà ce que j'ai compris après plusieurs audits pour des fonds : le code sale, ça se nettoie. L'incompréhension du fondateur, non.

Ce qui fait vraiment fuir un investisseur, ce n'est pas de trouver du code imparfait en early-stage. Personne ne s'attend à du code parfait à ce stade. Ce qui le fait fuir, c'est quand le fondateur est incapable d'expliquer comment son propre produit fonctionne.

"C'est Lovable qui a fait ça, je ne sais pas trop comment ça marche." "L'authentification ? Je crois que c'est géré, oui." "Le code est sur le GitHub de mon ancien freelance."

J'ai entendu ces phrases. Elles sont pires qu'un fichier .env en clair. Parce qu'un investisseur n'investit pas dans un produit figé — il investit dans une équipe capable de le faire évoluer. Si personne ne comprend la technique, qui corrigera le bug critique un dimanche soir ? Qui saura scaler quand le trafic explosera ?

Le vibe coding est-il un deal breaker pour lever ?

Non. Pas en seed ou pre-seed.

À ce stade, ce qui compte, c'est la traction, le marché et l'équipe. Le code, c'est un sujet — mais pas le sujet principal. À une condition : ne pas avoir de faille de sécurité béante.

Deux choses changent la donne quand même.

Les due diligence techniques se démocratisent. Il y a cinq ans, seuls les fonds tech faisaient auditer le code avant de signer. Aujourd'hui, les fonds généralistes s'y mettent aussi. Un fonds avec lequel je travaille ne signe plus aucun deal sans audit technique préalable. Il s'est fait brûler une fois — une startup dont le code tenait avec du scotch, impossible à maintenir six mois après l'investissement. Depuis, c'est systématique.

Le dernier dossier qu'il m'a envoyé : 40% du code était du copier-coller de ChatGPT sans adaptation, pas un seul test, et des routes API accessibles sans authentification. Le deal n'a pas été signé.

À partir de la Series A, le bar monte. Les montants sont plus élevés, les exigences aussi. Si votre app tient avec des prompts et de la chance, ça ne passera plus. Il faut un plan technique crédible — et idéalement un directeur technique capable de l'exécuter.

Ce qu'il faut nettoyer avant de montrer votre code

La bonne nouvelle : c'est rattrapable. J'ai vu un fondateur reprendre son code en main en deux semaines avec l'aide d'un dev senior. L'audit initial était catastrophique — secrets dans le code, pas de tests, une architecture incompréhensible. Deux semaines plus tard, les fondamentaux étaient en place. Le deal a été signé.

Le bar n'est pas si haut en early-stage. Voici les bases.

Virez tous les secrets du code source. Clés API, tokens, mots de passe — tout doit aller dans des variables d'environnement, jamais dans le code. Et attention : même si vous supprimez un fichier, il reste dans l'historique Git. Il faut purger l'historique aussi. Demandez à un dev si vous ne savez pas faire.

Vérifiez que l'authentification est côté serveur. Si la vérification des droits se fait dans le navigateur, ça ne protège rien. C'est la faille la plus courante dans le code généré par IA, et c'est celle qui fait le plus tiquer les auditeurs.

Écrivez quelques tests. Pas besoin de tout couvrir. Cinq à dix tests sur vos fonctions critiques — paiement, inscription, accès aux données sensibles — suffisent pour montrer que vous prenez le sujet au sérieux.

Documentez l'architecture en une page. Un schéma simple : quel service communique avec quel autre, où sont stockées les données, comment c'est déployé. Un investisseur technique doit pouvoir comprendre votre stack en cinq minutes.

Ayez quelqu'un capable de répondre aux questions. Que ce soit vous, un CTO, un dev senior ou un conseiller technique — quelqu'un doit pouvoir expliquer chaque brique sans répondre "c'est l'IA qui a fait ça". C'est probablement le point le plus important de cette liste.

"Je préfère ne pas montrer le code"

J'ai eu un fondateur qui refusait de donner accès à son repo. "Le code, c'est notre propriété intellectuelle, on ne peut pas le montrer comme ça."

L'investisseur a abandonné le dossier dans la journée.

Refuser de montrer son code, c'est comme refuser d'ouvrir ses comptes à un acheteur potentiel. Le message est limpide : il y a quelque chose à cacher. Même si ce n'est pas le cas, c'est ce que l'investisseur retient.

La transparence technique est un signal de maturité. Vous n'avez pas besoin d'un code parfait. Vous avez besoin de montrer que vous savez où sont les faiblesses et que vous avez un plan pour les corriger.

Se faire auditer son code avant de le montrer à un investisseur, c'est la même logique qu'un audit comptable avant une cession. Mieux vaut découvrir les problèmes soi-même.

Checklist pre-due diligence

Avant de partager votre code avec un investisseur, passez cette liste en revue :

• Aucun secret dans le code — clés API, tokens, mots de passe → variables d'environnement uniquement
• Historique Git nettoyé — les fichiers supprimés restent dans l'historique, purgez-le
• Authentification côté serveur — jamais de vérification de droits uniquement dans le navigateur
• Tests automatisés — au minimum 5 à 10 tests sur les fonctions critiques
• CORS configuré correctement — pas de wildcard * qui ouvre votre API à n'importe quel site
• Rate limiting actif — vos endpoints publics doivent limiter le nombre de requêtes par utilisateur
• Architecture documentée — un schéma d'une page, lisible par un non-dev
• Référent technique identifié — une personne capable de répondre à un auditeur

Si vous cochez ces huit points, votre code vibe-codé passera la due diligence d'un seed sans problème. Si vous n'en cochez aucun, réglez ça avant d'envoyer votre deck.

Ce qu'il faut retenir

Le vibe coding n'est pas un problème pour lever des fonds. Le manque de préparation, si.

Les investisseurs ne s'attendent pas à du code parfait en early-stage. Ils s'attendent à ce que vous compreniez votre produit et maîtrisiez les risques techniques. Un fichier .env en clair, ce n'est pas grave en soi — c'est grave si personne dans votre équipe ne savait qu'il existait.

Faites auditer votre code avant que l'investisseur ne le fasse. Vous préférez corriger les problèmes en amont plutôt que les découvrir pendant la due diligence — quand chaque red flag peut tuer votre deal.