Audit de code Vibe : 10 vérifications critiques avant votre lancement

En mars 2026, des chercheurs de Georgia Tech ont identifié 35 nouvelles vulnérabilités CVE directement liées à du code généré par IA. Ce seul mois a produit plus de vulnérabilités que toute l’année 2025 combinée, et la même équipe estime que le nombre réel dans l’open source est cinq à dix fois plus élevé.

Si votre produit a été développé avec Lovable, Bolt, Cursor ou Replit, ces données devraient redéfinir votre notion de « prêt à lancer ». Le code s’exécute. Les utilisateurs s’inscrivent. La démo est excellente. Rien de tout cela ne vous indique si un inconnu peut lire votre table d’utilisateurs entière en vingt minutes. Les risques de sécurité liés au « vibe coding » au sein de ces bases de code se regroupent dans les mêmes endroits prévisibles, quel que soit l’outil qui a généré le code.

Un audit de code « vibe » est un examen structuré du code généré par IA qui met en évidence les problèmes que le trafic de production rencontrera en premier. Des travaux d’audit comme le nettoyage de code « vibe » améliorent systématiquement la maintenabilité de 80 à 90 %, et les dix mêmes constatations sont généralement ce qui freine cette amélioration.

Pourquoi le code généré par IA échoue en production

La vitesse est tout l’argument du « vibe coding ». Des outils comme Cursor et Lovable optimisent pour un résultat fonctionnel, pas pour un résultat sécurisé. Ce ne sont pas la même chose, et l’écart est précisément ce qu’un audit de code « vibe » approprié est censé combler.

La Cloud Security Alliance a analysé des recherches de Veracode portant sur plus de 100 grands modèles de langage et a constaté que 45 % des échantillons de code générés par IA introduisent des vulnérabilités OWASP Top 10. Le taux de réussite ne s’est pas amélioré de manière significative entre 2025 et 2026, malgré les affirmations contraires des fournisseurs.

Une démo fonctionnelle réussit le test visuel. Elle ne vérifie pas si votre flux d’authentification fuit, si votre base de données renvoie les lignes d’autres utilisateurs, ou si une dépendance hallucinée vient d’atterrir en production. Si vous développez des logiciels pour startups à un rythme soutenu, vous devez auditer le code généré par IA avec la même rigueur que vous appliqueriez à une pull request d’un ingénieur junior. Le même risque s’étend au territoire de la détection de l’IA cachée : du code livré par des équipes d’ingénierie où personne ne suit la quantité de code généré par l’IA.

Les 10 vérifications critiques avant le lancement

Ces dix vérifications proviennent de travaux d’audit réels, classés par fréquence d’apparition et gravité des dommages. Chacune d’elles doit figurer dans tout examen approfondi d’une application « vibe » avant son lancement. Certaines peuvent être vérifiées en cinq minutes avec un scan rapide. D’autres nécessitent qu’un ingénieur expérimenté lise votre code manuellement. Exécutez-les dans cet ordre pour identifier ce qui fait planter la plupart des applications « vibe » avant que les utilisateurs payants ne le découvrent pour vous.

1. Secrets et clés API exposés

Le défaut le plus courant dans le code généré par IA, et de loin. Les outils d’IA intègrent régulièrement des identifiants dans les bundles côté client ou les committent dans des dépôts publics. Une fois une clé révélée, elle l’est définitivement. La rotation coûte de l’argent, du temps et la confiance des clients.

Une plateforme sociale développée en « vibe coding », Moltbook, a divulgué 1,5 million de jetons d’authentification dans les trois jours suivant son lancement, comme l’Infosecurity Magazine l’a rapporté. Le fondateur a ensuite déclaré publiquement qu’il n’avait écrit aucune ligne de code. Il n’en avait pas non plus relu.

Vérifiez trois endroits : les bundles JavaScript côté client, les fichiers d’environnement committés dans Git, et la configuration CI/CD. Exécutez un scanner de secrets comme TruffleHog ou GitGuardian sur l’intégralité de votre historique de commits, pas seulement la branche actuelle. Si vous trouvez quoi que ce soit, faites pivoter les clés d’abord, puis nettoyez l’historique Git.

2. Authentification côté serveur

Les outils d’IA adorent un schéma de composants propre. Ils ajouteront un contrôle isAdmin sur le frontend et considéreront que c’est suffisant. Du point de vue de l’expérience utilisateur, le tableau de bord se cache correctement. Du point de vue de la sécurité, n’importe qui avec les DevTools du navigateur peut changer le drapeau et entrer.

Chaque point d’accès protégé doit vérifier l’identité côté serveur, avec un jeton validé par rapport à votre fournisseur d’authentification à chaque requête. Pas le cookie. Pas la valeur stockée localement. Le jeton signé, vérifié côté serveur.

Effectuez un test rapide : déconnectez-vous, copiez une requête vers un point d’accès protégé, rejouez-la avec l’en-tête d’authentification supprimé. Si les données reviennent, ce point d’accès est ouvert. Répétez pour chaque route privilégiée.

3. Sécurité au niveau des lignes et autorisation (IDOR)

L’authentification indique au serveur qui vous êtes. L’autorisation indique au serveur ce que vous êtes autorisé à voir. Les outils d’IA gèrent raisonnablement bien la première partie. Ils ne gèrent presque jamais la seconde.

La faille classique est une référence d’objet directe non sécurisée (Insecure Direct Object Reference). L’utilisateur A se connecte normalement, modifie un ID numérique dans l’URL et lit les données de l’utilisateur B. Avec Supabase, cela signifie généralement que la sécurité au niveau des lignes est désactivée ou partiellement configurée au niveau de la base de données.

Testez comme le ferait un attaquant. Connectez-vous en tant qu’utilisateur de test, puis essayez de lire, mettre à jour ou supprimer une ressource appartenant à un autre utilisateur. Si l’un de ces appels réussit, vous avez un bug d’autorisation. Corrigez-le au niveau de la base de données, pas seulement de l’API.

4. Validation et assainissement des entrées

Chaque champ de formulaire, paramètre de requête et corps JSON arrivant à votre API est hostile jusqu’à preuve du contraire. Les outils d’IA font confiance aux entrées par défaut, ce qui ouvre la porte aux injections SQL, aux scripts inter-sites (XSS) et aux falsifications de requêtes côté serveur (SSRF).

La recherche de la Cloud Security Alliance place le taux de vulnérabilité OWASP Top 10 dans le code généré par IA à 45 %, les attaques par script inter-sites et les injections SQL étant citées comme les schémas les plus courants.

Validez les entrées à la frontière, avant qu’elles n’atteignent votre logique métier. Utilisez des requêtes paramétrées pour chaque appel à la base de données, sans exception. Assainissez tout ce qui sera rendu en HTML. Pour les téléversements de fichiers, vérifiez le type, la taille et le contenu. Les fonctions sont courtes et bien documentées dans tous les frameworks modernes.

5. Limitation des requêtes sur les points d'accès critiques

Deux types de points d’accès échouent de manière opposée lorsqu’ils ne sont pas soumis à une limitation de débit. Les points d’accès d’authentification sont la cible d’attaques par force brute. Les points d’accès des API externes se transforment en une facture que vous ne voudrez pas voir le lundi.

La même logique s’applique à tout ce qui déclenche un appel sortant : envois de SMS, campagnes d’e-mails, requêtes LLM, confirmations de paiement. Un attaquant oisif disposant d’un script peut épuiser votre budget mensuel en une heure.

Définissez des valeurs par défaut raisonnables sur trois niveaux : tentatives de connexion par adresse IP par minute, appels API par utilisateur authentifié par minute, et opérations coûteuses sortantes par utilisateur par heure. La plupart des frameworks fournissent un middleware de limitation de débit prêt à l’emploi. L’IA l’ajoute rarement sans y être invitée, alors vérifiez explicitement, et vérifiez avant que les paiements ne soient mis en ligne.

6. En-têtes de sécurité et CORS

Les en-têtes de sécurité au niveau du navigateur font un travail discret mais important. Ils se situent entre votre serveur et le navigateur de l’utilisateur, empêchant des catégories entières d’attaques que vous devriez autrement gérer dans le code de l’application.

Au minimum, vos réponses devraient inclure les éléments suivants :

• Content-Security-Policy (bloque les scripts injectés)
• Strict-Transport-Security (force le HTTPS)
• X-Frame-Options (arrête le détournement de clics)
• X-Content-Type-Options (empêche l’analyse MIME)
• Referrer-Policy (contrôle les URL que vous divulguez)

CORS mérite une vérification à part. Les configurations générées par l’IA commencent souvent par Access-Control-Allow-Origin: *, ce qui signifie que n’importe quel site web sur Internet peut effectuer des requêtes authentifiées vers votre API. Verrouillez CORS aux domaines exacts que vous servez, et rejetez tout le reste.

7. Vérification des signatures de webhook

Les fournisseurs de paiement, les services de calendrier et la plupart des plateformes SaaS modernes envoient des mises à jour à votre application via des webhooks. Chacun d’eux est essentiellement un point d’accès public que n’importe qui sur Internet peut appeler. La signature est ce qui vous indique que l’appel provient réellement de Stripe, et non d’un script aléatoire qui a trouvé votre point d’accès.

Les gestionnaires de webhook générés par l’IA omettent fréquemment la vérification de la signature. L’intégration fonctionne en test car personne ne falsifie les appels. Elle échoue la première fois qu’un paiement se passe mal, ou pire, un attaquant déclenche un faux événement “abonnement payé” et débloque les fonctionnalités premium gratuitement.

Pour chaque récepteur de webhook, vérifiez la signature avec la bibliothèque du fournisseur, utilisez des clés d’idempotence pour dédupliquer les tentatives, et enregistrez chaque charge utile pour le débogage.

8. Suppressions logiques et flux de suppression conformes au RGPD

Lorsqu’un utilisateur clique sur “supprimer le compte”, que se passe-t-il réellement avec ses données ? Dans la plupart des applications codées de manière superficielle, la ligne est supprimée d’une table tandis que le reste du système continue de faire référence à l’enregistrement manquant. Attendez-vous à des plantages mystérieux en production une semaine plus tard.

Deux problèmes se cachent derrière cela. Le premier est d’ingénierie : vous avez besoin de suppressions logiques (une colonne deleted_at plutôt qu’une instruction DELETE) pour que votre application reste cohérente. Le second est légal. L’article 17 du RGPD accorde aux utilisateurs européens un droit à l’effacement, et vous devez le respecter dans les journaux, les sauvegardes et les analyses, pas seulement dans la base de données principale.

Cartographiez tous les emplacements où résident les données utilisateur, puis créez un flux de suppression qui les touche tous. Testez-le avant que tout utilisateur ne puisse appuyer sur le bouton.

9. Vulnérabilités des dépendances

Les outils d’IA suggèrent des packages avec assurance, y compris ceux qui n’existent pas. Les chercheurs appellent cela du “slopsquatting” : des attaquants enregistrent les noms de packages halluciné sur npm ou PyPI et distribuent des logiciels malveillants à quiconque les installe. Même lorsque le package existe, l’IA a tendance à suggérer d’anciennes versions avec des CVE connues. Votre package.json finit par ressembler à un musée des vulnérabilités de l’année dernière.

Exécutez une audit de dépendances sur votre fichier de verrouillage complet : npm audit pour Node, pip-audit pour Python, ou Snyk pour l’un ou l’autre. Ajoutez une étape CI qui échoue la compilation en cas de découvertes de haute gravité. Réexécutez le scan chaque semaine, car de nouvelles CVE sont constamment découvertes sur des packages existants.

10. Durcissement de la configuration de production

Les vingt derniers pour cent des problèmes avant le lancement se situent dans votre configuration de déploiement. Les coupables habituels sont le mode débogage qui affiche toujours des traces de pile, les cartes sources servies avec le JavaScript de production, les identifiants administrateur par défaut que personne n’a changés, et les pipelines CI/CD qui divulguent des secrets dans les journaux de compilation.

Une liste de contrôle rapide pour la configuration de déploiement :

• Modes de débogage et d’erreur verbeuse désactivés.
• Cartes sources non servies au navigateur.
• Tous les identifiants par défaut remplacés.
• Journaux de compilation nettoyés des secrets.
• TLS 1.3 appliqué partout.
• Réponses d’erreur génériques, avec les détails enregistrés uniquement dans les journaux internes.

Cette liste semble évidente à lire. Elle couvre également environ la moitié des incidents embarrassants post-lancement qui finissent sur Hacker News. Exécutez-la avant chaque déploiement, pas seulement avant le lancement.

Bonnes pratiques de revue de code : quoi corriger en premier

Dix vérifications, c’est beaucoup à assimiler en une seule fois. Le profil de dommage est cependant inégal, et une poignée de problèmes causent la plupart des brèches qui font les gros titres. Vous pouvez vous en occuper en premier.

Corrigez dans cet ordre :

• Avant qu’un utilisateur de production ne s’inscrive : secrets exposés (#1), authentification côté serveur (#2), sécurité au niveau des lignes (#3). Ces trois éléments sont à l’origine de la plupart des brèches majeures de 2026. Trois de ces vérifications sont également celles sur lesquelles notre équipe passe le plus de temps lors d’une audit, car les modes d’échec ne ressemblent pas à des bugs.
• Avant la mise en ligne des paiements : validation des entrées (#4), limitation des requêtes (#5), signatures de webhook (#7). Tout ce qui touche à l’argent ou aux services externes dépend de ces trois éléments.
• Avant la mise à l’échelle ou la levée de fonds : vulnérabilités des dépendances (#9) et configuration de production (#10). Les investisseurs et les acquéreurs examineront les deux lors de la due diligence technique.
• Avant de servir des utilisateurs européens ou de soins de santé américains : suppressions logiques (#8) et en-têtes de sécurité (#6).

Les outils d’IA rendent le code rapide. La production nécessite une revue lente et délibérée. Pour les équipes qui préfèrent un second regard, une revue de code externe et une revue de code complète peuvent couvrir ce que cette liste de contrôle ne peut pas. Si c’est votre cas, nous sommes à deux clics, et nous vous aiderons.

FAQ

Combien de temps prend une audit de code ?

Pour un petit projet avec un seul développeur, un dépôt et un ensemble de fonctionnalités limité, une évaluation initiale structurée prend une à deux semaines. Les bases de code plus importantes ou plus complexes prennent plus de temps, souvent trois à quatre semaines pour une revue complète. L’audit lui-même est la partie rapide ; la remédiation, en particulier pour les problèmes d’autorisation et de base de données, est là où la majeure partie du temps est consacrée. Une audit terminée vous fournit une liste priorisée, des évaluations de gravité et un plan de remédiation que vous pouvez confier à un développeur.

En quoi une audit de code diffère-t-elle d'un test d'intrusion ?

Une audit examine votre code source à la recherche de problèmes structurels et de sécurité. Un test d’intrusion attaque l’application en cours d’exécution de l’extérieur, à la recherche de ce qu’un attaquant réel trouverait. La plupart des applications codées de manière superficielle ont besoin de l’audit en premier, car les problèmes sont intégrés dans le code et un test d’intrusion ne vous montrera pas tout ce qui ne va pas. Effectuez le test d’intrusion après la remédiation, pas avant.

Puis-je auditer mon code généré par l'IA moi-même ?

Les dix vérifications ci-dessus permettront de détecter les problèmes les plus dommageables, et vous pouvez exécuter la plupart d’entre elles avec des outils gratuits. Les problèmes dépendant du contexte sont plus difficiles. Les défauts de logique métier, le découplage architectural et le mappage de conformité nécessitent un ingénieur expérimenté qui a vu les mêmes modèles sur de nombreuses bases de code. La plupart des équipes adoptent un modèle hybride où les revues de code alimentées par l’IA effectuent la première passe et un ingénieur expérimenté la dernière.

Quel est le problème le plus courant dans les applications codées avec vibe ?

Désactivation de la sécurité au niveau des lignes dans la couche de base de données. Des données d’audit indépendantes le montrent dans la plupart des applications construites par Lovable, et le schéma se répète dans les projets Bolt et Cursor basés sur Supabase. Combiné à des clés API exposées, cela signifie que tout utilisateur authentifié peut lire les données de tout autre utilisateur en quelques frappes. Ce problème figure en tête de presque tous les rapports d’audit qui en valent la peine, car la correction est simple et le risque est élevé.