Sacha nous montre ses meilleures techniques
Sacha construit en live une application de portfolio films/séries connectée à l'API TMDB, en comparant Claude Code et Codex (OpenAI), tout en intégrant Supabase comme backend, avec un objectif secondaire de déploiement en PWA sur Vercel.
Stack technique
Outils utilisés
Résumé de la session
Sacha se présente comme un indépendant passé du no-code (WordPress, Webflow, Figma) au vibe coding avec Claude Code, sans background développeur. Il expose son projet : une app de suivi de films et séries connectée à TMDB, avec sauvegarde, notation, listes personnalisées, page poster, et comme twist final, un déploiement en PWA.
La session commence par une tentative d'utiliser Codex plutôt que Claude Code, pour comparer les deux outils en direct. Sacha essaie d'y connecter Context7 via MCP pour fournir la documentation TMDB à l'IA, mais la configuration MCP de Codex (en format TOML, différent du JSON habituel) échoue. La clé API Context7 fraîchement créée n'est pas reconnue à cause de guillemets superflus dans la saisie. Après quelques minutes perdues, Sacha abandonne le MCP et décide d'initialiser le projet avec Claude Code, puis de basculer sur Codex pour la suite.
Claude Code initialise le projet en React/Vite et génère un plan structuré. Sacha bascule ensuite vers Codex, mais découvre rapidement plusieurs frictions : raccourcis clavier différents (Shift+Entrée envoie au lieu de sauter une ligne, coller se fait avec Alt+V), impossibilité de déplacer le panneau Codex à droite de l'écran (résolue par un viewer du chat grâce au menu contextuel), et surtout la nécessité de valider manuellement chaque action de l'IA. Cette validation permanente crée une inertie importante, Sacha étant bloqué à cliquer "approve" en continu sans pouvoir faire autre chose.
Le premier prototype Codex fonctionne partiellement côté front mais sans fichier .env, la clé API TMDB est écrite en dur dans l'URL, et l'interface est visuellement basique. Une erreur 401 surgit sur les appels TMDB, probablement un problème de format de clé. Sacha compare avec la version préparée la veille avec Claude Code, nettement plus aboutie visuellement, avec autocomplete enrichi dans la recherche et connexion Supabase fonctionnelle en one-shot.
Face à l'écart de qualité visible, Sacha abandonne Codex et revient à Claude Code avec la base de code de la veille. Deux instances de Claude Code sont lancées en parallèle : une pour intégrer Supabase (login CLI, link projet, migration des tables via npx supabase db push), une autre pour refaire le design en mobile first. Cette tentative de parallélisation génère une cannibalisation du projet : les deux instances créent des conflits dans la structure des fichiers et la configuration Supabase. La session se termine sans avoir atteint l'objectif PWA/Vercel, mais avec une base fonctionnelle côté design et les tables Supabase créées.
La session commence par une tentative d'utiliser Codex plutôt que Claude Code, pour comparer les deux outils en direct. Sacha essaie d'y connecter Context7 via MCP pour fournir la documentation TMDB à l'IA, mais la configuration MCP de Codex (en format TOML, différent du JSON habituel) échoue. La clé API Context7 fraîchement créée n'est pas reconnue à cause de guillemets superflus dans la saisie. Après quelques minutes perdues, Sacha abandonne le MCP et décide d'initialiser le projet avec Claude Code, puis de basculer sur Codex pour la suite.
Claude Code initialise le projet en React/Vite et génère un plan structuré. Sacha bascule ensuite vers Codex, mais découvre rapidement plusieurs frictions : raccourcis clavier différents (Shift+Entrée envoie au lieu de sauter une ligne, coller se fait avec Alt+V), impossibilité de déplacer le panneau Codex à droite de l'écran (résolue par un viewer du chat grâce au menu contextuel), et surtout la nécessité de valider manuellement chaque action de l'IA. Cette validation permanente crée une inertie importante, Sacha étant bloqué à cliquer "approve" en continu sans pouvoir faire autre chose.
Le premier prototype Codex fonctionne partiellement côté front mais sans fichier .env, la clé API TMDB est écrite en dur dans l'URL, et l'interface est visuellement basique. Une erreur 401 surgit sur les appels TMDB, probablement un problème de format de clé. Sacha compare avec la version préparée la veille avec Claude Code, nettement plus aboutie visuellement, avec autocomplete enrichi dans la recherche et connexion Supabase fonctionnelle en one-shot.
Face à l'écart de qualité visible, Sacha abandonne Codex et revient à Claude Code avec la base de code de la veille. Deux instances de Claude Code sont lancées en parallèle : une pour intégrer Supabase (login CLI, link projet, migration des tables via npx supabase db push), une autre pour refaire le design en mobile first. Cette tentative de parallélisation génère une cannibalisation du projet : les deux instances créent des conflits dans la structure des fichiers et la configuration Supabase. La session se termine sans avoir atteint l'objectif PWA/Vercel, mais avec une base fonctionnelle côté design et les tables Supabase créées.
Ce qu'on a appris
- Techniques et méthodologiques**
- Préparer un prototype YOLO en premier permet de comprendre l'architecture sans s'y attacher. Sacha le fait la veille, et la session en bénéficie directement : la version préparée à l'avance est meilleure que celle construite "bien" en live.
- Le "mobile first" n'est pas juste du responsive : c'est d'abord une décision d'UX qui change comment l'IA structure les composants. Oublier de le spécifier en amont se voit immédiatement dans le résultat, et corriger après coup est coûteux.
- La parallélisation de deux instances Claude Code sur le même projet est risquée si les tâches touchent aux mêmes couches de l'app. Elle peut fonctionner sur des pans vraiment distincts (une page front isolée + config back), mais pas sur des fichiers partagés comme la config Supabase.
- Utiliser le CLI Supabase plutôt que le MCP Supabase est plus robuste : le MCP est limité par la fenêtre de contexte et fait parfois échouer des opérations longues. Le CLI, lui, est conçu pour être piloté par des commandes séquentielles que l'IA peut générer et exécuter.
- Laisser l'IA faire `npx supabase link`, créer les tables via migration et pousser le schéma est une approche qui fonctionne bien quand on lui donne le bon contexte dès le départ (projet déjà linké, variables d'env présentes).
- Limitations des outils découvertes**
- Codex via extension VS Code n'a pas de mode "full auto-approve" équivalent au `--dangerously-skip-permissions` de Claude Code. Chaque action PowerShell nécessite une validation manuelle, ce qui rend le travail interactif quasi impossible.
- Les configurations MCP de Codex sont en TOML, pas en JSON. C'est une friction réelle pour quelqu'un habitué à d'autres environnements, et la documentation est moins accessible.
- Le passage d'un LLM à l'autre en cours de projet (Codex puis Claude Code) laisse des incohérences dans le code : styles différents, structures de fichiers conflictuelles, noms de variables non harmonisés.
- Claude Code ne peut pas toujours récupérer une pop-up d'authentification tierce (comme Supabase login) depuis le terminal embarqué. Certaines étapes d'auth doivent être faites manuellement à l'extérieur.
- Le mode UltraThink de Claude Code ne garantit pas l'usage d'Opus : il peut rester sur Sonnet 4 en compensant par une meilleure utilisation du contexte. Pour forcer Opus, il faut le spécifier explicitement.
- Bonnes pratiques identifiées**
- Utiliser les "LLM prompts" officiels fournis par Supabase dans leur documentation est une excellente pratique : ce sont des instructions calibrées pour éviter les erreurs classiques que les LLM font avec leur API.
- Toujours ouvrir la console navigateur au premier chargement d'une nouvelle version générée. C'est le premier réflexe de debug, et ça permet de catcher les erreurs 401, les clés en dur ou les imports manquants avant de passer du temps à chercher ailleurs.
- Ne pas écrire le `.env` directement, mais demander à l'IA de générer un `.env.example` que tu dupliques. C'est plus propre et ça évite les fuites de clés dans les logs ou le versioning.
- Donner le contexte Supabase (structure de la DB, workflows attendus) avant de demander des scripts JavaScript Airtable ou des fonctions : Sacha constate que ses scripts Airtable générés par Claude sont fiables depuis qu'il documente la structure en amont.
- Préciser explicitement dans les instructions permanentes de ne jamais démarrer le serveur de dev : c'est l'IA qui prend trop souvent l'initiative de lancer `npm run dev`, ce qui bloque son terminal et force un redémarrage manuel.
- Insights sur l'architecture et la modélisation**
- Séparer les tables films et séries dans la DB peut avoir du sens fonctionnel (une série a une date de début et de fin, des saisons), mais si le cas d'usage est juste "contenu regardé", une table unifiée avec un champ type est plus simple à requêter et à maintenir.
- La question des saisons illustre un angle mort classique du vibe coding : l'IA implémente un statut binaire "vu/pas vu" pour les séries alors que la réalité est plus nuancée (vu X saisons sur Y). Sans spécification explicite, l'IA choisit toujours la version la plus simple, pas forcément la plus juste.
- La décomposition en petits composants (navbar, menu, cards) est une habitude que Sacha a acquise via le design Figma. Elle s'applique directement au vibe coding et réduit les fichiers monolithiques que Bolt et Loveable ont tendance à générer.
- Leçons sur la collaboration avec l'IA**
- L'apprentissage passif par exposition au code généré est réel. Sacha comprend maintenant les scripts Airtable sans les avoir appris formellement, par simple accumulation de lectures. Le vibe coding peut être une école d'immersion technique involontaire.
- Quand tu as trop bien préparé un projet la veille, la session live en souffre : le contraste entre le prototype préparé et celui reconstruit "en direct" est brutal et peut démoraliser. C'est une dynamique à anticiper pour les formats de démonstration.
- Savoir quel mode utiliser (Think, UltraThink, Opus) reste empirique. UltraThinkc pour les grosses features ou les sessions de debug qui bloquent, mode normal pour les modifications courantes. Il n'y a pas de règle formelle, c'est du ressenti accumulé.