Audit de code d’une app Lovable, Bolt ou v0 : ce qu’on examine, ce qu’on fournit, ce qu’on doit recevoir

Vous avez une application construite avec Lovable, Bolt, v0 ou Cursor, des utilisateurs qui arrivent, et quelqu’un vous conseille de « la faire auditer ». Le mot recouvre des prestations sans rapport : un scan automatique relu en vingt minutes, une revue de sécurité de deux jours, un diagnostic complet qui finit par une décision. Toutes s’appellent « audit », et un founder qui n’a jamais lu de code n’a aucun moyen de les distinguer avant d’avoir payé.

Cet article ne vous apprend pas à auditer vous-même : nos check-lists de sécurité Lovable et Supabase et de mise en production sont faites pour ça. Il décrit la prestation : ce qu’on examine, comment l’audit se déroule, quels accès donner, ce que vous devez recevoir et comment repérer un audit bâclé. Il s’appuie sur une douzaine d’applications générées par IA que nous avons reprises et mises en production, dont une application RH et une messagerie chiffrée interne d’entreprise aux nombreuses failles de sécurité corrigées. Les faits sur Lovable, Supabase, GitHub et Vercel ont été vérifiés en octobre 2026.

Ce qu’un audit de code n’est pas

Trois choses se vendent sous ce nom et n’en sont pas.

Le scan intégré de l’outil. Lovable propose un scan rapide à chaque publication et un scan approfondi qui relit le code sur sept thèmes, dont le contrôle d’accès, les secrets et les paiements. Sa propre documentation prévient que ces outils « ne remplacent pas une revue de sécurité approfondie », que seules les vulnérabilités critiques des dépendances deviennent des alertes, et que vous restez responsable des exigences de sécurité de votre application (vérifié en octobre 2026). Un bon auditeur lance ces scans, puis vérifie ce qu’ils disent et ce qu’ils taisent.

Un test d’intrusion. Un pentest attaque l’application de l’extérieur, sans lire le code. Utile, mais muet sur le modèle de données, les tests ou le coût de la suite.

Un devis déguisé. Un « audit gratuit » qui conclut, après un coup d’œil à l’application en ligne, qu’il faut tout refaire avec le prestataire qui l’a mené, n’est pas un audit. Un audit lit le code et la base, et son verdict peut conclure qu’il n’y a presque rien à faire.

Les dix domaines qu’un audit doit couvrir

Un audit sérieux d’une application générée par IA couvre au minimum ces dix domaines. Le tableau sert de grille : vous pourrez la comparer au sommaire du rapport.

Chaque domaine a ses pièges propres sur du code généré.

Sécurité et RLS

C’est le cœur : une application Lovable ou Bolt branchée sur Supabase parle souvent à la base directement depuis le navigateur, et seules les règles RLS empêchent un utilisateur de lire les données d’un autre. L’auditeur lit chaque règle et la teste avec trois identités : un visiteur non connecté, un utilisateur A, un utilisateur B qui tente d’accéder aux données de A. Pour une application v0 ou Cursor avec ses propres routes serveur, la question se pose route par route. Le Security Advisor de Supabase aide, avec des alertes comme rls_disabled_in_public ou permissive_rls_policy, mais il ne connaît pas votre logique métier : une règle peut être correcte et laisser un employé voir les fiches de paie de toute l’entreprise.

Secrets

L’auditeur cherche les clés dans le code livré au navigateur, dans les fichiers .env versionnés et dans tout l’historique Git : une clé supprimée d’un fichier reste lisible dans les commits précédents. Le rapport doit dire quelles clés révoquer, pas seulement lesquelles déplacer.

Modèle de données

C’est le domaine qui décide le plus souvent du verdict. Une table profiles qui mélange identité, abonnement et préférences se corrige ; une application B2B sans notion d’organisation, alors que plusieurs utilisateurs d’une même entreprise partagent des données, demande de revoir chaque table et chaque règle. L’auditeur regarde aussi les contraintes : unicité, clés étrangères, montants en centimes plutôt qu’en décimaux.

Dépendances et versions

Un npm audit liste les vulnérabilités connues des dépendances déclarées. C’est un point de départ : une alerte sur un outil de développement qui ne part jamais en production ne pèse pas comme une faille dans la bibliothèque d’authentification. L’auditeur note aussi la génération du projet : Lovable génère du TanStack Start pour les nouveaux projets depuis le 13 mai 2026, les plus anciens restant en React et Vite, et les deux ne se reprennent pas de la même façon.

Structure du code et tests

Sur du code généré, on retrouve la même logique en plusieurs exemplaires, des règles de prix ou de droits dans l’interface, et des tests qui testent des simulacres ; nous avons détaillé ces défauts dans ce qu’il faut reprendre sur un MVP codé par IA. Ce qui intéresse le founder n’est pas un score, mais une réponse : un développeur qui arrive peut-il modifier le paiement sans casser l’inscription ?

Performances et coûts

L’auditeur repère ce qui ralentira avec le volume : une liste qui interroge la base une fois par ligne, des clés étrangères sans index, des règles RLS qui réévaluent l’utilisateur à chaque ligne. Le Performance Advisor de Supabase signale ces deux derniers cas, sous les noms unindexed_foreign_keys et auth_rls_initplan. Côté coûts, il relève les plans en cours, les quotas, et surtout les fonctions qui coûtent à chaque appel (API d’IA, e-mails, SMS) sans limite par utilisateur.

Déploiement et RGPD de base

Comment publie-t-on, et comment revient-on en arrière ? Un schéma de production modifié à la main, sans fichiers de migration, ne se reconstruit pas après un incident. Côté RGPD, l’audit de code ne remplace pas un juriste, mais il voit ce que le juriste ne voit pas : quelles données personnelles sont réellement stockées, dans quelle région, chez quels prestataires, et si la suppression d’un compte efface vraiment ses données.

Comment se déroule un audit

Le déroulé varie, mais un audit honnête suit à peu près ces étapes.

1. Le cadrage. Un court échange : ce que fait l’application, qui l’utilise, ce qui vous inquiète, votre échéance. L’auditeur en tire un périmètre écrit et la liste des accès.
2. Les accès. Vous les donnez en lecture seule (voir plus bas). L’horloge du délai annoncé part de là.
3. La lecture statique. Code, schéma, règles RLS, configuration, historique Git, dépendances : l’essentiel du travail, et ce qu’aucun scan ne fait.
4. Les vérifications dynamiques. Requêtes rejouées sans connexion et avec deux comptes de test, recherche de clés dans le code servi, scans des outils. Jamais en modifiant des données de production.
5. La synthèse. Chaque constat est classé par gravité, relié à une preuve, et chiffré en effort.
6. La restitution. Un rapport écrit, et un échange pour le parcourir avant de décider quoi que ce soit.

Une faille critique trouvée en cours de route (une table de clients lisible par n’importe qui, une clé secrète publique) ne doit pas attendre le rapport : l’auditeur vous prévient le jour même, pour que vous révoquiez la clé ou coupiez l’accès.

Ce que vous devez fournir, et comment

Un auditeur a besoin de voir, pas de modifier. Mais la lecture seule n’existe pas partout, et il faut le savoir avant d’envoyer les invitations.

Quelques précisions, vérifiées en octobre 2026 :

• GitHub. Sur un dépôt personnel privé, un collaborateur ne peut pas avoir un accès en lecture seule : il peut pousser du code. Le rôle Read n’existe que pour les dépôts d’une organisation. Si votre code est sur votre compte personnel, créez une organisation à votre nom et transférez-y le dépôt : c’est de toute façon là qu’il devrait vivre.
• Supabase. Le rôle Read-only permet de consulter réglages et données et d’exécuter des requêtes SELECT, mais seulement sur les plans Team et Enterprise. Sur Free et Pro : un export du schéma, puisque supabase db dump exporte par défaut le schéma sans aucune donnée, ou un rôle plus large retiré à la fin de l’audit. Un export suffit pour lire les règles RLS, pas pour les tester en conditions réelles.
• Vercel. Le rôle Pro Viewer est gratuit sur le plan Pro et donne une lecture seule des projets et déploiements, mais pas des journaux. Sur Netlify ou un autre hébergeur, regardez quel rôle équivalent existe avant l’audit.
• Lovable. Le rôle Viewer d’un projet ne permet pas de le modifier. Pour un projet sur Lovable Cloud, la documentation ne décrit pas d’accès en lecture seule à la base elle-même : discutez avec l’auditeur de ce qu’il peut vérifier depuis le code et l’application publiée.

Deux règles valent pour tous les accès. Ne transmettez jamais une clé secrète par e-mail ou messagerie : une clé service_role ou sk_live_ envoyée « pour gagner du temps » est une clé à révoquer. Et un auditeur qui accède aux données personnelles de production agit en sous-traitant au sens du RGPD, ce qui suppose un contrat qui encadre ce qu’il peut en faire, comme le prévoit l’article 28 du règlement. S’il peut travailler sans voir de données réelles, c’est encore mieux.

Ajoutez à ces accès le lien de l’application publiée, deux comptes de test avec des rôles différents, et la liste de ce qui vous inquiète.

Ce que vous devez recevoir à la fin

Un rapport d’audit se juge à une question : pouvez-vous décider avec ? Il doit contenir quatre choses.

Un verdict : reprendre ou refaire

Garder l’existant et le renforcer, ou reconstruire, en tout ou en partie. Le verdict doit être argumenté par des critères que vous pouvez discuter, pas par une préférence : « le modèle de données ne permet pas d’isoler les clients, et chaque table devrait changer » est un critère ; « le code est sale » n’en est pas un. Même un verdict « refaire » doit dire ce qui se garde : écrans, parcours validés par vos utilisateurs, contenus.

Une liste de constats priorisée

Chaque constat a la même forme, qui permet de le vérifier et de le confier à n’importe quel développeur :

[CRITIQUE] Table invoices lisible sans connexion
Preuve : requête GET /rest/v1/invoices avec la seule clé publique,
         renvoie les factures de tous les clients
Impact : fuite de données personnelles et financières
Correction : activer le RLS, règle de lecture limitée au propriétaire
Effort : 0,5 jour

La priorité ne suit pas seulement la gravité technique : elle suit ce qui bloque l’ouverture à vos clients. Trois niveaux suffisent généralement : à corriger avant d’ouvrir, à corriger dans le mois, à tolérer. Une faille critique dans une fonctionnalité que vous comptez supprimer passe après une faille moyenne dans le paiement.

Une estimation d’effort

En jours, poste par poste, avec des fourchettes plutôt qu’un chiffre au jour près : sécurité, stabilisation du code, briques de production manquantes, évolutions. Vous devez pouvoir retirer une ligne et savoir ce que vous perdez. Cette estimation est ce qui vous permet de comparer des devis de reprise ; ce qui la fait varier est détaillé dans ce que coûte la reprise d’une app Lovable, Bolt ou v0.

Le périmètre réellement couvert

Ce qui a été regardé, avec quels accès, et surtout ce qui ne l’a pas été. Un audit qui n’a pas eu accès à la base ne peut rien affirmer sur les règles RLS en conditions réelles ; il doit l’écrire. Le rapport vous appartient : vous devez pouvoir le donner à un autre prestataire pour qu’il fasse les travaux.

Les signaux d’un audit bâclé

Avant de payer, et en lisant le rapport, voici ce qui doit vous alerter.

• Le rapport est la sortie d’un outil. Des dizaines d’alertes npm audit ou du Security Advisor copiées telles quelles, sans tri ni explication de ce qui vous concerne.
• Aucune preuve. « Des failles ont été détectées », sans dire lesquelles ni comment les reproduire.
• Tout est critique. Quand vingt constats sur vingt sont prioritaires, aucune priorité n’a été établie.
• Des recommandations génériques. « Ajouter des tests », « améliorer la sécurité » : des intentions, pas des constats.
• Pas de verdict, ou un verdict sans critère. L’audit doit trancher entre reprendre et refaire, et dire pourquoi.
• Pas d’estimation d’effort. Sans elle, vous ne pouvez ni budgéter ni comparer.
• Les accès demandés sont trop larges. Un auditeur qui demande la clé service_role par e-mail ou les droits de propriétaire sur votre organisation ne respecte pas les règles qu’il est censé vérifier.
• La conclusion mène toujours au même endroit. Si l’audit conclut à une reconstruction complète par le prestataire qui l’a mené, sans critère, demandez un second avis.

À l’inverse, un bon audit dit aussi ce qui va bien. Sur une application générée, les écrans, les formulaires et une bonne partie de l’interface sont souvent solides ; un rapport qui ne le mentionne jamais n’a probablement pas tout lu.

Si l’application ouvre dans les prochaines semaines, passez d’abord la check-list de sécurité pour fermer l’évident : l’auditeur passera son temps sur ce que vous ne pouviez pas voir.

L’audit Raicode, en bref

Nous menons cet audit sur les applications Lovable, Bolt et v0, au forfait : le prix est annoncé avant de commencer, et le verdict écrit arrive sous 48 h après réception des accès. Il couvre la sécurité, la qualité du code, ce qui manque pour la production et l’estimation de la reprise, poste par poste. Le rapport vous appartient, et vous pouvez confier les travaux à qui vous voulez. Le détail est sur la page reprise d’app Lovable, Bolt et v0. Pour un projet construit par une autre équipe ou avec un autre outil, la démarche est décrite dans l’audit de la première semaine d’un projet IA repris.