Xavier nous montre ses meilleurs techniques
Alexis invite Xavier pour développer une application SaaS de gestion de produits avec Cursor et Claude 4, aboutissant à la mise en place des fondations techniques et d'une interface de connexion avec des problèmes de liaison Supabase.
À propos de cette session
Alexis démarre la session avec Xavier, développeur no-code depuis 5 ans et CTO. Xavier présente sa méthode structurée en expliquant qu'il a préparé trois éléments clés : un PRD (Product Requirements Document), un fichier de bonnes pratiques, et une base de données Supabase.
Xavier configure Cursor en mode Claude 4 et partage son écran. Il commence par charger son PRD dans le chat, expliquant qu'il préfère mettre le document directement dans la conversation plutôt que dans un fichier, par habitude des outils comme Lovable.
Alexis découvre que Xavier utilise un système de refroidissement corporel high-tech pendant qu'il code. Xavier explique sa philosophie : travailler avec l'IA par contraintes en lui disant ce qu'elle ne doit pas faire plutôt que ce qu'elle doit faire.
Xavier demande à Claude de découper le PRD en tâches granulaires avec un fichier de suivi. L'IA génère un plan détaillé en 11 phases réparties sur plusieurs sprints. Xavier insiste sur l'importance de l'ordonnancement pour éviter les dépendances problématiques.
L'agent démarre l'implémentation en créant automatiquement l'architecture React/TypeScript. Xavier remarque que Cursor fait des commits automatiques, ce qu'il n'avait pas prévu et qu'il désapprouve normalement.
L'IA installe et configure de nombreux outils : ESLint avec des règles strictes, Storybook pour la documentation des composants, et Playwright pour les tests. Xavier note que l'interdiction des useEffect dans ses règles n'est pas respectée par l'IA.
Pendant plus d'une heure, l'agent travaille de manière autonome, dépassant la limite habituelle de 25 actions. Il crée la documentation technique, les fichiers de configuration, et commence l'interface utilisateur.
Des problèmes techniques apparaissent : configurations Tailwind incorrectes, multiples serveurs de développement lancés simultanément, et erreurs de liaison avec Supabase. Xavier explique qu'il aurait normalement corrigé ces problèmes manuellement ou avec une autre IA.
La session se termine avec une interface de connexion fonctionnelle visuellement mais non connectée à Supabase, illustrant les réalités du vibe coding en live.
Points clés
- ### Aspects méthodologiques et préparation
- Préparation cruciale : Xavier investit des heures en amont sur le PRD, les bonnes pratiques et la base de données, démontrant que le vibe coding professionnel nécessite un cadrage rigoureux avant l'implémentation.
- Méthode par contraintes : Dire à l'IA ce qu'elle ne doit pas faire (comme les useEffect) s'avère plus efficace que de lui donner des instructions positives, mais reste imparfaitement respecté.
- Découpage granulaire indispensable : Plus les tâches sont atomiques, plus l'IA a de chances de réussir. La planification détaillée réduit significativement les erreurs et les déviations.
- Fichiers de suivi essentiels : Maintenir un état d'avancement visible permet de recadrer l'agent quand il dévie du plan initial, problème récurrent du vibe coding.
- ### Limitations techniques découvertes
- Limites des règles ESLint : Même avec des configurations strictes, l'IA outrepasse régulièrement les interdictions techniques, nécessitant une surveillance constante.
- Gestion des commits problématique : Les commits automatiques par l'agent représentent un risque pour le versioning et la maîtrise du code, nécessitant une désactivation explicite.
- Problème de la sur-installation : L'agent installe parfois des outils non demandés (Playwright, MSW) qui rallongent inutilement le setup et créent des dépendances supplémentaires.
- Fragilité des connexions externes : L'intégration avec Supabase échoue malgré la configuration, illustrant la difficulté des agents à gérer les services tiers sans outils MCP spécialisés.
- ### Problèmes récurrents du vibe coding
- Gestion des serveurs chaotique : L'agent lance multiple serveurs de développement simultanément, créant des conflits de ports et des erreurs difficiles à diagnostiquer.
- Surveillance indispensable : Malgré l'autonomie apparente, le développeur doit constamment vérifier les actions de l'agent, particulièrement sur les choix d'architecture et les installations.
- Redondance des instructions nécessaire : Xavier répète "respecte les principes DRY, KISS, SOLID" à chaque étape, révélant la tendance de l'IA à oublier les contraintes précédentes.
- ### Bonnes pratiques identifiées
- Documentation automatique précieuse : La génération automatique d'ADR (Architecture Decision Records) et de Storybook apporte une valeur documentaire significative souvent négligée en développement manuel.
- Règles d'accessibilité intégrées : Inclure les règles d'accessibilité dans le PRD et les faire vérifier automatiquement lors du build représente une excellente pratique.
- Gestion des environnements séparés : Maintenir des fichiers de configuration d'environnement séparés permet un meilleur contrôle des accès aux services externes.
- ### Réalités concrètes du vibe coding
- Écarts entre démo et réalité : Le live révèle des problèmes (erreurs Tailwind, configurations cassées) qui auraient été résolus hors caméra, soulignant la différence entre vibe coding marketing et pratique.
- Compétences techniques requises : Contrairement au marketing no-code, le vibe coding professionnel exige une solide maîtrise technique pour diagnostiquer et corriger les erreurs de l'agent.
- Nécessité d'un environnement maîtrisé : Travailler en local avec Cursor/Windsurf demande une configuration d'environnement de développement que tous les utilisateurs ne maîtrisent pas, contrairement aux outils cloud.
- ### Stratégies qui fonctionnent vraiment
- Utilisation d'IA complémentaires : Xavier utilise ChatGPT pour le debugging quand Cursor échoue, illustrant l'approche multi-agent comme stratégie de contournement.
- Corrections manuelles ciblées : Plutôt que de laisser l'agent corriger ses erreurs en boucle, intervenir manuellement sur les points bloquants s'avère plus efficace.
- Template de bonnes pratiques réutilisable : Maintenir un fichier de bonnes pratiques évolutif par stack technique permet de capitaliser sur l'expérience entre projets.