Appli faite avec l'IA : la check-list avant mise en ligne

Que vérifier avant d’ouvrir une appli faite avec l’IA ?

Avant d’ouvrir une appli faite avec l’IA à de vrais utilisateurs, il faut vérifier neuf points : les réponses du serveur, l’isolation entre deux comptes, les règles d’accès de la base, l’absence de clé secrète exposée, la limitation des tentatives, les dépendances, la sauvegarde, le journal d’erreurs et les obligations légales.

Cette check-list s’adresse aux dirigeants et aux équipes qui ont un site ou une appli avec comptes générés par Lovable, Bolt, Claude Code ou un outil équivalent. Chez Peechy, chaque site passe par une check-list de fin de projet avant sa mise en ligne : secrets, sécurité, dépendances, liens, formulaires, pages légales, bandeau cookies, puis vérification de la production (statut HTTP et contenu rendu). Voici la version à dérouler soi-même, avec pour chaque point le test, et le signe qu’il faut s’arrêter. Pour comprendre pourquoi ces failles apparaissent, lis d’abord Vibe coding : les risques de sécurité.

Prérequis

• Un environnement de test avec de fausses données, jamais la base de production.
• Deux comptes de test (A et B) avec deux adresses e-mail distinctes.
• Un navigateur avec les outils de développement (touche F12).
• L’accès au dépôt Git et au tableau de bord de la base de données.
• Un terminal avec Node.js pour les commandes npm.

Les références utilisées sont l’OWASP Top 10:2025, construit à partir de données portant sur plus de 2,8 millions d’applications source : Imperva, 2025, et l’OWASP API Security Top 10 2023.

Étape 1 : lis les réponses du serveur dans l’onglet Réseau

Pourquoi : une appli renvoie souvent l’objet complet de la base, et l’écran n’en affiche qu’une partie. OWASP classe ce risque en API3, l’autorisation défaillante au niveau des propriétés d’un objet source : OWASP API Security, 2023.

Vérifie :

1. Ouvre F12, onglet Réseau, filtre Fetch/XHR.
2. Navigue dans l’appli, puis clique sur chaque requête et ouvre l’onglet Réponse.
3. Compare chaque champ reçu avec ce que l’écran affiche.

Stop si tu vois un champ que l’écran n’affiche pas : e-mail d’un autre utilisateur, rôle, hash de mot de passe, jeton, note interne.

Étape 2 : teste avec deux comptes

Pourquoi : Le BOLA (Broken Object Level Authorization) désigne une faille où le serveur sert un objet à partir d’un identifiant envoyé par le client, sans vérifier que l’appelant y a droit. C’est le risque n°1 des API selon OWASP (API1:2023) source : OWASP API Security, 2023. Il relève du contrôle d’accès, première catégorie (A01) du Top 10:2025 source : OWASP, 2025.

Vérifie :

1. Connecte-toi avec A, repère l’identifiant d’une donnée de A dans l’URL ou la requête.
2. Crée une donnée avec B, copie son identifiant.
3. Reconnecte-toi avec A et remplace l’identifiant par celui de B, en lecture puis en modification et suppression.
4. Refais le test déconnecté, puis appelle une route d’administration avec un compte ordinaire.

Stop si A obtient les données de B ou peut les modifier. La réponse attendue est un 403 ou un 404. Ce test se fait à la main, car les scanners automatiques détectent mal ces failles source : Salt Security, 2023.

Étape 3 : contrôle les règles d’accès de chaque table

Pourquoi : La RLS (Row Level Security) est un mécanisme de la base qui décide, ligne par ligne, qui peut lire ou écrire. Elle fait partie des mesures contre le BOLA source : Wiz Academy. Une table sans règle est lisible par quiconque connaît l’adresse de l’API.

Vérifie : ouvre le tableau de bord de la base, liste toutes les tables, confirme que les règles sont activées sur chacune (le détail pour Supabase est dans Supabase RLS : le guide pour débutants). Interroge ensuite une table avec la clé publique, sans être connecté.

Stop si une table répond sans connexion, si la règle est désactivée, ou si une politique autorise tout (true).

Étape 4 : cherche les secrets dans le code et dans Git

Pourquoi : Une clé secrète est un identifiant qui donne des droits sur un service (paiement, e-mail, base de données) et ne doit jamais quitter le serveur. Toute variable préfixée NEXT_PUBLIC_, VITE_ ou PUBLIC_ est envoyée au navigateur. OWASP place la mauvaise configuration en 2ᵉ position du Top 10:2025 source : OWASP, 2025.

Vérifie :

git grep -nEi "sk_live|secret|service_role|api[_-]?key" $(git rev-list --all)

Dans le navigateur, ouvre Réseau, charge les fichiers JavaScript et cherche les mêmes mots.

Stop si une clé apparaît quelque part. La supprimer ne suffit pas, l’historique Git la garde : révoque-la et génère-en une nouvelle (marche à suivre).

Étape 5 : limite les tentatives de connexion et de formulaire

Pourquoi : Le rate limiting (limitation de débit) consiste à refuser les requêtes d’un même client au-delà d’un seuil. Sans lui, un robot peut tester des milliers de mots de passe (A07, défaillances d’authentification) ou déclencher des envois d’e-mails facturés à la requête (API4) source : OWASP API Security, 2023.

Vérifie : envoie une vingtaine de connexions avec un mauvais mot de passe, puis soumets un formulaire plusieurs fois de suite.

Stop si le serveur répond toujours normalement. Un code 429 ou un blocage temporaire est le comportement attendu.

Étape 6 : dépendances, sauvegarde et journal d’erreurs

Pourquoi : OWASP a élargi les composants obsolètes en « Software Supply Chain Failures », désormais A03 source : Qualys, 2026. Une appli générée embarque souvent des paquets dont personne n’a vérifié l’utilité. La catégorie A09 vise aussi l’alerte, pas seulement la journalisation.

Vérifie :

• Dépendances : lance npm audit et npm outdated, et vérifie que chaque paquet a une raison d’être.
• Sauvegarde : restaure-la sur un environnement de test et ouvre l’appli restaurée.
• Journal : provoque une erreur volontaire et vérifie qu’elle apparaît dans un journal, et qu’une alerte te parvient.

Stop si une vulnérabilité critique reste sans plan de correction, si la sauvegarde n’a jamais été restaurée, ou si l’erreur ne laisse aucune trace.

Étape 7 : pages légales et procédure en cas de fuite

Pourquoi : un site avec comptes collecte des données personnelles. Les mentions légales, la politique de confidentialité et, si tu utilises des traceurs, le bandeau cookies sont attendus dès l’ouverture (qui est responsable ?).

Vérifie : les pages existent, sont liées depuis le pied de page et décrivent les vrais traitements. Rédige ensuite une procédure d’une page : qui coupe l’accès, qui révoque les clés, qui notifie. En cas de violation de données présentant un risque pour les personnes, le responsable de traitement notifie la CNIL dans les 72 heures (article 33 du RGPD, via le téléservice de cnil.fr).

Stop si personne ne sait qui prévient la CNIL. Après la mise en ligne, contrôle la production : le statut HTTP des pages et le contenu rendu.

Pièges courants

• Tester uniquement avec un compte administrateur, qui voit tout.
• Masquer un bouton dans l’interface et croire la fonction protégée : seul le serveur protège.
• Corriger un point sans refaire le test.
• Retirer une clé du code sans la révoquer.
• Faire la check-list une fois : refais-la à chaque grosse modification, et fais relire le code avec une revue de sécurité par Claude Code.

Tableau récapitulatif

Un seul « stop » suffit pour repousser l’ouverture : corrige, refais le test, puis ouvre.