TL;DR

Nous avons déployé plus de 30 projets headless en 18 mois chez Social Animal. Environ un tiers de nos dernières acquisitions sont des travaux de sauvetage provenant de projets dirigés par des designers qui ont livré des démos mais qui se sont cassés en production. Le guide "Claude Code for Designers" de Michael Nervegna sur Substack est légitime pour les prototypes -- mais il s'arrête avant la Row Level Security, l'actualisation des tokens d'authentification, les choix d'abstraction de base de données, le déploiement en rollback, la politique de sécurité du contenu, et l'authentification administrateur. Cet article couvre ces lacunes. Si vous déployez en production, vous en avez besoin.

Table des matières

Qu'est-ce que Claude Code et pourquoi les designers l'utilisent-ils ?

Claude Code est l'outil de codage basé sur terminal d'Anthropic qui a été lancé début 2025. Il fonctionne en tant que @anthropic-ai/claude-code et nécessite Claude Pro ($20/mois) ou Team ($30/siège/mois) avec accès à l'API. Vous écrivez, modifiez et déboguez le code via le langage naturel dans votre terminal.

Les designers l'utilisent parce qu'il comble le fossé entre "j'ai conçu ceci dans Figma" et "c'est une application Next.js fonctionnelle". Contrairement à v0 ou Bolt, Claude Code fonctionne sur votre système de fichiers réel. Il lit votre structure de projet, modifie les fichiers, exécute votre serveur de développement et itère sur les erreurs. Pour quelqu'un qui comprend la hiérarchie des composants mais ne veut pas mémoriser les génériques TypeScript, c'est genuinely utile.

Nervegna le positionne comme un outil qui permet aux designers de "penser en systèmes" plutôt qu'en syntaxe. Nous sommes d'accord. Là où nous divergeons, c'est sur ce qui se passe après le premier npm run dev réussi.

Qu'est-ce que le guide de Nervegna fait correctement ?

Nervegna cloue trois choses que la plupart des tutoriels de codage IA manquent.

Première : le contexte du projet. Il recommande de nourrir Claude Code avec un fichier CLAUDE.md contenant vos conventions de projet, votre pile technologique et vos tokens de conception. Nous avons vu Claude Code générer des utilitaires Tailwind par rapport à un projet utilisant CSS Modules parce que personne ne lui a dit les conventions. Établir le contexte avant d'écrire du code est la bonne approche.

Deuxième : la boucle itérative. Prompt, examiner la sortie, corriger le cap, répéter. Il ne traite pas Claude Code comme un bouton "décrire et livrer". Il le traite comme un partenaire d'appairage qui a besoin de supervision. C'est le bon modèle mental.

Troisième : commencer petit. Construisez un seul composant ou page avant de tenter un échafaudage d'application complet. Nous avons vu des designers inviter "construis-moi un tableau de bord SaaS complet avec authentification, facturation et administrateur" en un message. Le résultat est toujours un gâchis. L'approche incrémentale de Nervegna évite cela.

Là où le guide de Nervegna sert bien les designers est la phase 0-to-prototype. Le problème est que les prototypes deviennent du code de production, et c'est là que les lacunes ont de l'importance.

Où le guide s'arrête-t-il court ?

La pièce de Nervegna livre pour la phase de prototypage. Elle n'aborde pas les préoccupations qui deviennent urgentes lorsque vous connectez une vraie base de données, de vrais utilisateurs et une vraie infrastructure de déploiement.

Voici ce qui manque :

  1. Row Level Security (RLS) -- les projets Supabase générés par Claude Code n'ont presque jamais de politiques RLS correctes
  2. Handoff d'authentification -- l'écart entre Supabase Auth en développement et les flux de production avec actualisation des tokens, gestion des sessions et gestion des redirections
  3. Décisions d'abstraction de base de données -- quand utiliser le client Supabase directement vs. Prisma ou Drizzle ORM
  4. Stratégie de déploiement en rollback -- ce qui se passe quand un commit Claude Code casse la production
  5. Content Security Policy -- en particulier pour Next.js Image avec des ressources proxied/externes
  6. Authentification administrateur -- quand vous avez besoin d'accès basé sur les rôles au-delà d'une simple authentification utilisateur

Parlons de chacun.

Les pièges de la Row Level Security que Claude ne détectera pas

Row Level Security est le mécanisme de Supabase pour s'assurer que les requêtes de base de données retournent uniquement les lignes que l'utilisateur demandeur est autorisé à voir. Lorsque vous créez une table dans Supabase, RLS est désactivé par défaut. Tout utilisateur authentifié -- ou dans certaines configurations, toute demande anonyme -- peut lire chaque ligne.

Quand Claude Code scaffold un projet Supabase, il crée des tables et écrit des requêtes côté client. Il ajoutera parfois des politiques RLS si vous le demandez. Mais les politiques qu'il génère sont souvent erronées de manière subtile.

Les erreurs RLS courantes dans le code généré par l'IA

Erreur Ce qui se passe Comment corriger
RLS n'est pas du tout activé Tout utilisateur authentifié lit toutes les données ALTER TABLE your_table ENABLE ROW LEVEL SECURITY;
La politique utilise auth.uid() mais la table n'a pas de colonne user_id La politique compile mais ne correspond à aucune ligne, bloquant tous les accès Ajoutez user_id UUID REFERENCES auth.users(id) et remplissez-la
La politique SELECT existe mais pas de politiques INSERT/UPDATE/DELETE Les utilisateurs peuvent lire mais pas écrire leurs propres données Créez des politiques pour chaque opération séparément
La politique utilise uniquement auth.role() = 'authenticated' Tout utilisateur connecté peut voir toutes les lignes, pas seulement les siennes Ajoutez la condition auth.uid() = user_id
La clé de rôle de service est utilisée dans le code côté client RLS est complètement contourné N'exposez jamais SUPABASE_SERVICE_ROLE_KEY dans les bundles côté client

Nous avons vu ce dernier -- clé de rôle de service dans le code client -- dans trois projets distincts dirigés par des designers cette année. Claude Code utilisera parfois la clé de rôle de service parce qu'elle "fonctionne" et ne lance pas d'erreurs de permission. Cette clé contourne tout RLS. Elle doit figurer uniquement dans le code côté serveur (routes API, actions serveur, fonctions de périphérie). Jamais dans un composant use client.

Nervegna ne couvre pas RLS dans son guide, ce qui est compréhensible. Mais si vous suivez son flux de travail et vous connectez à Supabase, vérifiez chaque table manuellement. Exécutez ceci dans l'éditeur SQL Supabase :

SELECT schemaname, tablename, rowsecurity
FROM pg_tables
WHERE schemaname = 'public';

Si rowsecurity est false pour toute table qui contient des données utilisateur, arrêtez et corrigez-le avant de déployer.

Handoff d'authentification : l'écart entre prototype et production

L'authentification est le point d'échec le plus courant dans les projets dirigés par des designers. Non pas parce que la configuration initiale est erronée -- Supabase Auth est facile à scaffold -- mais parce que l'authentification de production implique des cas limites qui ne surgissent pas pendant le développement local.

Le guide de Nervegna se concentre sur faire fonctionner les choses localement. Voici ce qui casse quand vous déployez :

Les défaillances d'actualisation des tokens

Les tokens Supabase Auth expirent après 3600 secondes (1 heure) par défaut. Le client Supabase gère l'actualisation automatiquement -- en théorie. En pratique, si votre middleware Next.js ou vos composants serveur créent un nouveau client Supabase à chaque requête sans passer la session existante, vous obtiendrez des erreurs 401 intermittentes après la première heure.

Avec Next.js App Router, vous avez besoin de @supabase/ssr (version 0.5.x en février 2025) et d'une gestion appropriée des cookies en middleware. Claude Code génère souvent le package @supabase/auth-helpers-nextjs plus ancien, qui est deprecated. Vérifiez votre package.json.

Les incompatibilités URI de redirection

Les fournisseurs OAuth (Google, GitHub) nécessitent des URI de redirection exacts. Claude Code les configure pour localhost:3000. Lorsque vous déployez sur Vercel ou Netlify, vous devez ajouter votre URL de production et toutes les URL de déploiement d'aperçu aux deux la console du fournisseur OAuth et aux paramètres "Redirect URLs" de Supabase Auth. Cela prend 5 minutes mais bloque 100% des connexions OAuth si vous le manquez.

Le problème de synchronisation des sessions

Dans Next.js 14+, vous avez des composants serveur, des composants clients, un middleware, des routes API et des actions serveur -- tous ayant potentiellement besoin de la session utilisateur actuelle. Le client Supabase doit être créé différemment dans chaque contexte. Claude Code crée souvent une seule fonction createClient() et l'utilise partout, ce qui causes des incompatibilités d'hydratation et des sessions périmées.

Vous avez besoin au minimum de trois fonctions de création de client :

  • createBrowserClient() pour les composants clients
  • createServerClient() pour les composants serveur et les actions serveur
  • createMiddlewareClient() pour le middleware

Ceci est documenté dans le guide SSR de Supabase mais Claude Code ne le génère pas systématiquement correctement.

Supabase vs Prisma : pour lequel Claude Code devrait-il générer ?

Nervegna ne traite pas cette décision, et elle a plus d'importance que la plupart des designers le réalisent.

Client Supabase (@supabase/supabase-js) interroge la base de données via l'API PostgREST de Supabase. C'est pratique, n'a besoin d'aucun fichier de définition de schéma, et fonctionne directement avec RLS. Mais il ne vous donne aucune sécurité de type au-delà de ce que Supabase génère, et il couple fortement votre application à l'infrastructure de Supabase.

Prisma ORM (actuellement v6.x) se connecte directement à PostgreSQL. Il vous donne un fichier de schéma (schema.prisma), des types TypeScript générés, des migrations, et des requêtes indépendantes de la base de données. Mais il ne respecte pas les politiques RLS (il se connecte en tant qu'utilisateur privilégié), et il nécessite une étape de compilation pour générer le client.

Drizzle ORM (v0.36.x) est une alternative plus légère avec une syntaxe de type SQL et une meilleure prise en charge du runtime de périphérie.

Matrice de décision

Facteur Client Supabase Prisma Drizzle
Prise en charge de RLS Natif Doit être implémenté au niveau de l'application Doit être implémenté au niveau de l'application
Sécurité de type Généré via CLI Généré à partir du schéma Schéma en tant que code
Compatible avec le runtime de périphérie Oui Limité (Prisma Accelerate requis) Oui
Courbe d'apprentissage pour les designers Bas Moyen Moyen
Verrouillage du fournisseur Élevé (Supabase) Bas Bas
Qualité de génération Claude Code Bon Bon Incohérent

Notre recommandation : si vous construisez un prototype ou resterez toujours sur Supabase, utilisez le client Supabase. Si vous devez quitter Supabase ou si vous voulez un développement piloté par schéma strict, utilisez Drizzle. Nous nous sommes éloignés de Prisma pour les nouveaux projets en raison des limitations du runtime de périphérie, bien que Prisma Accelerate ($0 pour 60K requêtes/mois, puis $49/mois) ait amélioré cela.

Dites à Claude Code votre décision explicitement dans votre fichier CLAUDE.md. Si vous ne le faites pas, il mélangera les approches -- interrogeant parfois via le client Supabase, parfois via un ORM -- et vous vous retrouverez avec deux modèles d'accès aux données différents dans le même projet.

Deploy Rollback : ce qui se passe quand votre code généré par l'IA casse

Le guide de Nervegna marche dans la construction de fonctionnalités de manière itérative. Il n'aborde pas ce qui se passe quand une session Claude Code génère un commit qui réussit le dev local mais casse en production.

Cela arrive plus souvent que vous ne l'imagineriez. Claude Code peut modifier 15 fichiers en une seule réponse de prompt. Si vous validez cela comme une unité et déployez, revenir en arrière signifie rétablir tous les 15 changements -- même si 13 allaient bien.

Une stratégie pratique de rollback

1. Validez après chaque changement logique, pas chaque session Claude Code. Si Claude modifie l'authentification, l'interface utilisateur et le schéma de base de données en une session, créez trois commits séparés.

2. Utilisez le rollback instantané de Vercel. Si vous déployez sur Vercel, chaque déploiement est immuable. Vous pouvez revenir à n'importe quel déploiement précédent en moins de 10 secondes depuis le tableau de bord. Netlify offre la même chose.

3. Ne lancez jamais les migrations de base de données directement depuis Claude Code. Si Claude génère un fichier de migration, examinez-le manuellement avant de exécuter npx supabase db push ou npx prisma migrate deploy. Une colonne abandonnée n'est pas quelque chose que vous pouvez revenir avec un git revert.

4. Étiquetez les états connus-bons. Avant de commencer une session Claude Code qui touche des chemins critiques (authentification, paiements, modèles de données), créez une étiquette git : git tag pre-auth-refactor. Si quelque chose s'écarte, git reset --hard pre-auth-refactor vous ramène en arrière.

5. Les déploiements d'aperçu sont obligatoires, pas optionnels. Vercel et Netlify créent tous deux des déploiements d'aperçu pour chaque PR. Ne fusionnez pas à main sans cliquer à travers l'aperçu. Claude Code peut générer du code qui fonctionne localement mais échoue en production en raison de variables d'environnement manquantes, d'incompatibilités de runtime de périphérie ou de violations CSP.

Content Security Policy pour les ressources en proxy

C'est niche mais ça mord dur quand vous déployez un site dirigé par un designer.

Le composant <Image> de Next.js proxies les images externes via /_next/image par défaut. C'est super pour l'optimisation. Mais si vous avez un en-tête Content Security Policy (et vous devriez), vous devez explicitement autoriser les domaines d'où viennent vos images.

Claude Code configurera next.config.js avec remotePatterns pour l'optimisation d'image mais n'ajoutera pas d'en-têtes CSP. Quand vous déployez derrière les en-têtes de sécurité de Vercel ou ajoutez les vôtres via middleware, les images externes cassent silencieusement -- elles se chargent localement (où CSP est souvent lax) mais échouent en production.

Voici le minimum dont vous avez besoin dans votre middleware ou les en-têtes next.config.js :

// middleware.ts
const cspHeader = `
  default-src 'self';
  script-src 'self' 'unsafe-eval' 'unsafe-inline';
  style-src 'self' 'unsafe-inline';
  img-src 'self' blob: data: https://your-supabase-project.supabase.co https://your-cdn.com;
  font-src 'self';
  connect-src 'self' https://your-supabase-project.supabase.co;
  frame-ancestors 'none';
`;

Remplacez 'unsafe-eval' et 'unsafe-inline' par des nonces pour le durcissement de la production. L'idée est : si Claude Code tire des images d'Unsplash, Supabase Storage, ou tout autre CDN externe, et que vous n'ajoutez pas ces domaines à votre directive CSP img-src, vous obtiendrez des images cassées en production sans erreurs console en développement.

Quand avez-vous vraiment besoin d'une authentification administrateur ?

Le guide de Nervegna couvre l'authentification utilisateur de base. De nombreux projets dirigés par des designers ont besoin d'une interface administrateur -- un moyen pour le propriétaire du site ou l'équipe de contenu de gérer les données sans toucher directement à la base de données.

La question est : quand avez-vous besoin d'une authentification administrateur en tant que préoccupation distincte par rapport à simplement utiliser le tableau de bord de Supabase ?

Vous N'AVEZ PAS besoin d'authentification administrateur personnalisée quand :

  • Vous êtes la seule personne gérant le contenu
  • Votre client est à l'aise d'utiliser l'éditeur de tableau de Supabase
  • Le projet a moins de 3 types de contenu
  • Les mises à jour se produisent moins d'une fois par semaine

Vous AVEZ besoin d'authentification administrateur personnalisée quand :

  • Les membres non-techniques de l'équipe ont besoin de gérer le contenu
  • Vous avez besoin de flux d'approbation ou d'états brouillon/publié
  • Le projet a un accès basé sur les rôles (éditeur vs. administrateur vs. lecteur)
  • Vous gérez le contenu généré par l'utilisateur qui nécessite modération

Si vous avez besoin d'authentification administrateur, l'approche la plus simple est une colonne role sur votre table profiles (qui reflète auth.users) avec un enum : 'user' | 'editor' | 'admin'. Ensuite, ajoutez les politiques RLS qui vérifient ce rôle :

CREATE POLICY "Admins can do anything"
ON public.posts
FOR ALL
USING (
  EXISTS (
    SELECT 1 FROM public.profiles
    WHERE profiles.id = auth.uid()
    AND profiles.role = 'admin'
  )
);

Claude Code peut générer ceci si vous le promptez spécifiquement. Sans le prompt, il aura par défaut des politiques simples auth.uid() = user_id qui ne tiennent pas compte de l'accès administrateur. Vous vous retrouverez avec un administrateur qui ne peut pas voir le contenu d'autres utilisateurs.

Le flux de travail de Nervegna de définition des exigences dans un fichier CLAUDE.md attraperait ceci -- si vous pensez à inclure l'accès basé sur les rôles dans vos exigences. Ajoutez-le au fichier avant de commencer à construire.

Avant de pousser en production : la liste de contrôle

Voici ce que nous utilisons chez Social Animal avant de déployer tout projet construit ou significativement aidé par des outils de codage IA.

Base de données et sécurité

  • RLS est activé sur chaque table dans le schéma public
  • Les politiques RLS existent pour SELECT, INSERT, UPDATE, et DELETE sur chaque table
  • SUPABASE_SERVICE_ROLE_KEY est uniquement utilisé dans le code côté serveur (grep votre base de code : grep -r "SERVICE_ROLE" --include="*.ts" --include="*.tsx")
  • Aucun client Supabase n'est créé avec la clé de rôle de service dans tout fichier contenant 'use client'
  • Les migrations de base de données ont été examinées manuellement
  • Les contraintes de clé étrangère existent où elles sont attendues
  • Les index existent sur les colonnes utilisées dans les clauses WHERE et les politiques RLS

Authentification

  • @supabase/ssr est utilisé (pas le deprecated @supabase/auth-helpers-nextjs)
  • Les fonctions de création de client séparé existent pour les contextes navigateur, serveur et middleware
  • Les URI de redirection OAuth sont configurés pour le domaine de production ET les domaines de déploiement d'aperçu
  • L'actualisation des tokens est testée (définissez temporairement une expiration courte et vérifiez que les sessions survivent)
  • Les routes protégées redirigent vers la connexion quand la session est absente
  • La déconnexion efface tous les cookies et l'état de session côté serveur

Administrateur et rôles

  • Si les fonctionnalités d'administrateur existent, les vérifications de rôle se produisent au niveau RLS (pas seulement l'occultation au niveau UI)
  • Les routes administrateur sont protégées par middleware, pas seulement la restitution conditionnelle
  • Le rôle par défaut pour les nouveaux utilisateurs est le rôle avec les moins de privilèges

Déploiement et rollback

  • Les variables d'environnement sont définies dans la plateforme de déploiement
  • Une étiquette git connue-bonne existe d'avant les derniers changements assistés par l'IA majeurs
  • Le déploiement d'aperçu a été testé en cliquant à travers les flux essentiels
  • Le rollback instantané Vercel/Netlify est compris et documenté pour l'équipe
  • Les sauvegardes de base de données sont activées (le plan Supabase Pro inclut les sauvegardes quotidiennes pour $25/mois)

Sécurité du contenu et ressources

  • Les en-têtes CSP incluent tous les domaines d'image externes dans img-src
  • Les en-têtes CSP incluent l'URL du projet Supabase dans connect-src
  • next.config.js remotePatterns correspond aux domaines CSP img-src
  • Les polices sont auto-hébergées ou leur CDN est dans font-src
  • Pas de contenu mixte (ressources HTTP sur les pages HTTPS)

Qualité du code

  • Le mode strict TypeScript est activé ("strict": true dans tsconfig.json)
  • Pas de @ts-ignore ou les types any que Claude Code a ajoutés pour supprimer les erreurs
  • npm run build réussit sans avertissements (pas seulement npm run dev)
  • Les limites d'erreur existent pour les composants clients qui récupèrent les données
  • Les états de chargement et d'erreur existent pour les opérations asynchrones

Performance

  • Les images utilisent le composant Next.js <Image> avec width et height ou fill
  • Pas de récupération de données côté client pour les données qui pourraient être récupérées dans les composants serveur
  • La taille du bundle a été vérifiée (npx next@latest build affiche les tailles de route)
  • Le score Lighthouse est au-dessus de 90 pour Performance (exécutez sur le déploiement d'aperçu, pas localhost)

Cette liste de contrôle n'est pas exhaustive. C'est le minimum pour un projet qui touche Supabase, Next.js, et le code généré par l'IA.

FAQ

Claude Code est-il assez bon pour que les designers construisent des applications de production ?

Claude Code est excellent pour générer du code fonctionnant à partir de l'intention de conception. Mais la préparation à la production nécessite des connaissances en sécurité, authentification et infrastructure que l'outil ne fournit pas sans invite. Associez-le à une liste de contrôle et une révision de code par quelqu'un ayant une expérience backend.

Le guide de Nervegna fonctionne-t-il pour les projets au-delà des prototypes ?

Le flux de travail de Nervegna -- prompts contexte-first, construction incrémentale, révision itérative -- se met à l'échelle bien. L'écart se situe dans les préoccupations de production comme RLS, les cas limites d'authentification et la stratégie de déploiement. Son approche est saine ; elle a besoin de supplémentation pour tout ce qui est orienté utilisateur.

Dois-je utiliser Supabase ou Prisma avec Claude Code ?

Utilisez la bibliothèque cliente de Supabase si vous souhaitez l'application de RLS au niveau de la base de données et que vous êtes engagé sur la plateforme Supabase. Utilisez Drizzle ORM si vous souhaitez la portabilité de la base de données et la compatibilité du runtime de périphérie. Nous nous sommes éloignés de Prisma pour les nouveaux projets en raison des limitations de périphérie.

Comment puis-je empêcher Claude Code d'utiliser la clé de rôle de service Supabase dans le code client ?

Ajoutez une règle explicite à votre fichier CLAUDE.md : "N'utilisez jamais SUPABASE_SERVICE_ROLE_KEY dans les composants clients. Utilisez-le uniquement dans les actions serveur, les routes API, ou le middleware." Claude Code respecte les instructions au niveau du projet quand elles sont énoncées clairement.

Quel est le moyen le moins cher de déployer une application Next.js générée par Claude Code ?

Le plan Hobby gratuit de Vercel supporte un déploiement de production par projet. Le tier gratuit de Supabase inclut 2 projets avec 500MB de base de données et 1GB de stockage de fichiers. Coût total : $0/mois pour les sites à faible trafic. Attendez-vous à passer à Vercel Pro ($20/mois) et Supabase Pro ($25/mois) une fois que vous avez de vrais utilisateurs.

À quelle fréquence Claude Code génère-t-il du code avec des problèmes de sécurité ?

Dans notre expérience, environ 40% des sessions Claude Code impliquant des opérations de base de données produisent du code avec au moins une lacune RLS. Ce n'est pas malveillant -- l'outil optimise pour le code "fonctionnant", et les violations RLS ne produisent pas d'erreurs. Elles exposent simplement les données silencieusement. Auditez toujours manuellement.