Site ou appli avec Claude Code ou Codex : erreurs à éviter

Les erreurs de débutant qui coûtent le plus cher

Les erreurs les plus coûteuses avec Claude Code ou Codex sont rarement des bugs visibles : accepter le code sans le lire, croire qu’une donnée masquée à l’écran est protégée, laisser la base de données ouverte et exposer une clé d’API. Elles viennent de l’absence de vérification humaine, pas du modèle.

Un agent de code écrit vite et il écrit du code qui tourne. Le risque pour un débutant n’est donc pas que le site plante, c’est qu’il fonctionne sans que personne n’ait vérifié qui peut lire ou modifier quoi. Ces erreurs valent pour les deux outils (pour choisir entre eux, voir notre comparatif Claude Code et Codex).

Le classement ci-dessous est un jugement éditorial : il va des erreurs les plus difficiles à réparer vers celles qu’on rattrape facilement. La dernière, le RGPD, n’est pas la moins grave, elle est la plus lente à se manifester.

Lire, masquer, ouvrir, exposer : les erreurs sur le code et les données

1. Accepter le code sans lire ce qui change

• Symptôme : vous cliquez sur « accepter » à chaque proposition et vous jugez le résultat à ce que le navigateur affiche.
• Conséquence : le site peut s’afficher correctement et contenir une route sans protection, un secret écrit en dur ou un fichier supprimé, sans que rien ne vous le signale.
• Bon réflexe : lire le diff avant chaque commit. Un diff désigne la liste des lignes ajoutées et retirées entre deux versions d’un fichier. Demandez à l’agent d’expliquer chaque fichier modifié en une phrase, et refusez ce que vous ne comprenez pas. Pour réfléchir sans rien modifier, Claude Code propose un mode plan qui explore en lecture seule, et Codex une lecture seule via /permissions (Claude Code Docs, OpenAI Developers).

2. Croire qu’une information masquée à l’écran est protégée

• Symptôme : un bouton d’administration, un prix d’achat ou un e-mail n’apparaît pas dans l’interface, donc vous le considérez comme caché.
• Conséquence : le serveur renvoie quand même la donnée au navigateur. Les outils de développement (onglet Réseau) ou une requête directe suffisent à la lire. C’est un défaut de contrôle d’accès : seul le serveur peut décider qui a le droit de voir une donnée.
• Bon réflexe : pour chaque donnée sensible, posez cette question à l’agent : « Que reçoit quelqu’un qui appelle directement cette API, sans passer par l’interface ? » Le mécanisme est détaillé dans notre article sur les risques de sécurité du vibe coding.

3. Laisser la base de données ouverte faute de règles d’accès

La Row Level Security (RLS) est un mécanisme de PostgreSQL qui décide, ligne par ligne, quel utilisateur peut lire ou modifier quoi. Avec Supabase, très répandu dans les applications générées, la clé publique (ex-« anon », renommée « publishable key » en 2026) est conçue pour être dans le code du navigateur. Sa sûreté dépend entièrement de la RLS et de la justesse des politiques source : Stingrai, 2026.

• Symptôme : l’application marche parfaitement, personne n’a jamais parlé de RLS.
• Conséquence : si une table n’a pas de politique ou si la RLS est désactivée, n’importe qui peut la lire avec la clé copiée depuis le JavaScript du site source : Pluton Apps, 2026. La formule à retenir : clé publique et RLS activée, c’est acceptable ; clé publique sans RLS, c’est une base ouverte source : Elegant Software Solutions, 2026.
• Bon réflexe : exiger la RLS sur chaque table, relire les politiques, puis tester en étant déconnecté.

4. Mettre une clé d’API dans le code livré ou dans Git

• Symptôme : une clé collée dans un fichier pour « que ça marche », puis commitée.
• Conséquence : tout ce qui est livré au navigateur est lisible par le visiteur. La clé de service (« secret key » aujourd’hui) contourne toute la RLS via l’attribut PostgreSQL BYPASSRLS et ne doit exister que côté serveur source : Stingrai, 2026. Dans Git, un secret supprimé reste dans l’historique.
• Bon réflexe : variables d’environnement, fichier .env hors du dépôt, et règle deny Read(./.env) dans Claude Code pour que l’agent ne lise pas le fichier (exemple officiel). Si une clé fuit : rotation immédiate, usages déplacés côté serveur, vérification des journaux d’accès source : Pluton Apps, 2026.

Git, cahier des charges, règles : cadrer l’agent

5. Travailler sans Git, sans branche ni sauvegarde

• Symptôme : un seul dossier, aucun commit, l’agent modifie vingt fichiers d’un coup.
• Conséquence : si le résultat est mauvais, il n’y a pas de version précédente à retrouver.
• Bon réflexe : un commit avant chaque tâche, une branche par tâche, et des commits qui ne contiennent que des fichiers nommés.

Chez Peechy, on a une preuve récente que Git ne protège que si on l’utilise avec méthode. Le 12 octobre 2026, sur le dépôt du blog de peechy.fr, deux agents travaillaient en même temps dans le même dossier. Un changement de branche lancé par l’un a sorti l’autre de sa branche de travail pendant qu’il réécrivait huit articles. Rien n’a été perdu, parce que chaque commit ne contenait que des fichiers nommés explicitement. L’erreur était la nôtre, pas celle des outils.

La règle qui en est sortie : un worktree Git par agent, et jamais de changement de branche dans un dossier partagé. Un worktree Git est un dossier de travail supplémentaire rattaché au même dépôt, avec sa propre branche, ce qui évite que deux agents se marchent dessus.

6. Démarrer sans cahier des charges ni fichier de règles

• Symptôme : le premier prompt est « fais-moi un site pour mon activité ».
• Conséquence : l’agent comble les trous avec ses propres choix (structure des données, comptes, hébergement) et vous les découvrez après coup.
• Bon réflexe : écrire une page de cahier des charges (objectif, utilisateurs, données manipulées, interdits) et un fichier de règles. CLAUDE.md donne à Claude Code le contexte et les conventions du projet (documentation du dossier .claude). Codex lit AGENTS.md, mais en quantité limitée au premier tour de session : project_doc_max_bytes règle la taille lue par fichier, donc un AGENTS.md trop long peut être tronqué (configuration avancée de Codex). Gardez-le court. Pour structurer vos demandes, voir préparer son brief.

Ces fichiers ne sont pas des mécanismes de sécurité. Dans Claude Code, une consigne dans CLAUDE.md oriente ce que Claude essaie de faire, mais ne change pas ce que l’outil autorise source : Claude Code Docs, 2026.

Permissions : ce que disent les documentations officielles

7. Laisser l’agent lancer des commandes destructrices sans validation

• Symptôme : vous avez activé un mode « sans confirmation » pour ne plus être interrompu.
• Conséquence : une commande de suppression, un git push ou une écriture hors du projet part sans que vous la voyiez.
• Bon réflexe : garder la validation humaine pour tout ce qui est irréversible.

Les règles de permission sont appliquées par Claude Code lui-même, pas par le modèle. Pour accorder ou retirer un accès, la documentation renvoie à /permissions, aux règles, à un mode de permission ou à un hook PreToolUse source : Claude Code Docs, 2026. Côté Codex, l’agent tourne par défaut avec le réseau désactivé et un bac à sable appliqué par le système d’exploitation, qui limite l’accès au dossier de travail (Codex, approbations et sécurité).

Un exemple officiel de settings.json pour Claude Code : autoriser Bash(npm run *), demander confirmation pour Bash(git push *), interdire Read(./.env), avec acceptEdits comme mode par défaut (référence des réglages). Le réglage permissions.blockReadsOutsideWorkingDirectories refuse les lectures hors des dossiers de travail dans tous les modes, y compris bypassPermissions (Claude Code v2.1.257 ou plus). Un « auto mode » existe aussi, où un classifieur relit les actions à votre place : c’est un filet, pas une relecture humaine.

Pour Codex, la valeur du drapeau --sandbox est l’une de trois : read-only, workspace-write ou danger-full-access (référence CLI). Attention aux vieux tutoriels : la politique approval_policy = "untrusted" a été retirée, et un reste de cette configuration peut empêcher le client de démarrer.

Pour un débutant, la règle simple est de ne jamais activer bypassPermissions ou --yolo sur sa machine de travail. Si vous voulez moins d’interruptions, utilisez les règles allow ciblées plutôt que de tout ouvrir. Pour les accès que l’agent obtient via des serveurs MCP, voir lesquels et avec quels droits.

Second compte et RGPD : les vérifications avant la mise en ligne

8. Mettre en ligne sans avoir testé avec un second compte

• Symptôme : vous avez testé avec votre compte, souvent administrateur, et tout fonctionne.
• Conséquence : un utilisateur ordinaire peut voir ou modifier les données d’un autre, par exemple en changeant un identifiant dans l’URL ou dans une requête. Ce défaut est invisible tant qu’on n’est connecté qu’avec un seul compte.
• Bon réflexe : créer deux comptes ordinaires, A et B. Avec A, créer une donnée. Avec B, essayer de la lire, de la modifier, de la supprimer. Refaire l’essai déconnecté. Un agent peut vous aider à dérouler ces tests dans le navigateur (voir faire tester son site par Claude dans Chrome), mais c’est à vous de lire le résultat.

9. Oublier les obligations RGPD

• Symptôme : le formulaire, les comptes et les journaux collectent des données, personne n’a listé lesquelles.
• Conséquence : vous êtes responsable de traitement, que le code ait été écrit par vous, par un agent ou par un prestataire. La question de la responsabilité est traitée dans RGPD et site généré par IA.
• Bon réflexe : dresser la liste des données avant de coder, ne collecter que le nécessaire, fixer une durée de conservation, informer les personnes.

Le guide RGPD de la CNIL pour les développeurs est découpé en fiches : identifier les données personnelles, minimiser les données, gérer les utilisateurs, tester ses applications, informer les personnes, gérer la durée de conservation. Aucune fiche ne vise le code généré par IA : conclure que ces règles s’appliquent aussi aux projets construits avec un agent est une déduction de notre part, mais elle est logique, puisque les obligations portent sur le traitement des données et non sur l’outil qui a écrit le code. Le guide rappelle que le registre des activités de traitement est obligatoire dans la plupart des cas, et que les données personnelles se cachent dans des endroits inattendus : journaux serveur, fichiers de cache, fichiers Excel (version GitHub du guide).

Questions fréquentes

Faire relire par un professionnel : la limite honnête

Tout ce qui précède se vérifie sans être développeur : lire les diffs, activer la RLS, ranger les clés dans des variables d’environnement, travailler sur une branche, tester avec deux comptes. Pour un site vitrine sans données personnelles, c’est suffisant dans bien des cas (voir le déroulé d’un site vitrine avec Claude Code).

La limite est nette. Dès que votre projet comporte des comptes utilisateurs, des paiements ou des données personnelles, une erreur de contrôle d’accès ou de configuration touche vos clients, pas seulement votre site. À partir de là, faites relire le code et la configuration par un professionnel avant la mise en ligne. Une relecture externe coûte moins qu’une base de données lisible par n’importe qui, et la refonte avec l’IA seule montre où mène l’économie inverse.

Avant votre prochaine mise en ligne, faites un seul test : connectez-vous avec un compte ordinaire et essayez de lire la donnée d’un autre compte. Si ça fonctionne, ne publiez pas.