Début de la refonte de la plateforme du Cercle des Ops
Alexis lance le développement d'une nouvelle version de sa plateforme pédagogique "Cercle des Ops" avec Zite, mais se heurte dès la première session à un bug critique d'authentification qui bloque complètement l'avancement.
À propos de cette session
Alexis démarre cette première session d'une série prévue pour refaire entièrement la plateforme du Cercle des Ops. Il présente d'abord le contexte : une plateforme pédagogique basée sur 30 challenges pratiques, actuellement développée avec Softr mais devenue obsolète au niveau ergonomique.
Le travail préparatoire était solide. Alexis avait créé un PRD complet en utilisant Gemini, alimenté par un screencast de 13 minutes expliquant l'existant. Il avait également préparé un schéma de pages et un backlog dans Whimsical, connecté sa base Airtable existante à Zite.
La première itération génère des résultats visuellement impressionnants. Zite produit automatiquement une interface moderne avec un design néo-brutaliste qui correspond aux attentes d'Alexis. Le tableau de bord généré est esthétiquement réussi avec des statistiques utilisateur et une navigation intuitive.
Cependant, un problème critique apparaît rapidement : les données utilisateur ne correspondent pas. Quand Alexis se connecte, le système affiche les informations de Stéphane, un autre membre de la plateforme. Le bug persiste même en se connectant avec différents comptes - toujours les mêmes données incorrectes remontées.
Alexis passe plus d'une heure à diagnostiquer le problème. Il identifie une incohérence entre l'authentification frontend (qui récupère le bon identifiant) et le backend (qui retourne systématiquement les données du même utilisateur). Le problème semble lié à la fonction getCurrentUser du SDK Zite.
Plusieurs tentatives de correction échouent. Zite consomme les crédits en prétendant corriger le bug à chaque itération, mais le problème persiste. Alexis ajoute une ligne de debug dans le footer pour visualiser les identifiants frontend/backend, confirmant la dissociation.
La session se termine sur une frustration, Alexis devant upgrader son compte Zite (19$/mois) pour continuer les tentatives de correction, avant de finalement contacter le support technique.
Points clés
- ### Limitations des outils de vibe coding
- Les outils jeunes peuvent avoir des bugs critiques dans leurs fonctionnalités core (ici l'authentification)
- Impossible de debugger en profondeur quand le problème vient du SDK propriétaire
- Pas de versionning Git possible avec Zite, enfermement dans l'écosystème
- Consommation de crédits pour des corrections qui n'aboutissent pas
- ### Préparation de projet essentielle
- Un PRD détaillé permet de démarrer efficacement même avec des outils de vibe coding
- L'utilisation d'un screencast pour alimenter l'IA est une technique efficace pour transmettre le contexte
- La documentation du schéma de pages et du workflow aide l'IA à structurer l'application
- ### Stratégies de debugging
- Ajouter une ligne de debug visible pendant le développement est plus efficace que les console.log
- Tester avec plusieurs comptes utilisateur permet d'identifier les problèmes d'authentification
- Le mode chat de Zyte pour faire analyser les problèmes avant de demander des corrections
- ### Gestion des données existantes
- La connexion native Airtable de Zite évite la migration vers Supabase
- Les bases de données legacy avec des champs obsolètes compliquent l'interprétation par l'IA
- La structure des relations (lookups, rollups) n'est pas toujours bien comprise par les outils de vibe coding
- ### Problèmes récurrents du vibe coding
- L'IA prétend souvent avoir trouvé et corrigé un problème sans que ce soit effectif
- Difficile de distinguer les bugs de l'outil des erreurs de prompt
- Les outils consomment des crédits même pour des tentatives infructueuses
- Pas de transparence sur la consommation de crédits en temps réel
- ### Architecture et sécurité
- L'alignement frontend/backend pour l'authentification est crucial mais opaque dans Zyte
- Les systèmes d'authentification intégrés limitent la personnalisation
- La sécurité des données utilisateur dépend entièrement de la robustesse du SDK
- ### Bonnes pratiques identifiées
- Commencer par tester l'authentification et les flux critiques avant le design
- Garder des moyens de debug visibles pendant le développement
- Préparer des comptes de test multiples pour valider les fonctionnalités utilisateur
- Documenter les structures de données legacy avant de les connecter à des outils IA
- ### Collaboration avec l'IA
- Les prompts en mode "analyse du problème" sont plus efficaces que les demandes directes de correction
- Fournir le contexte complet (debug info, comportement observé) améliore les propositions de solution
- L'IA a tendance à sur-promettre ses capacités de résolution de bugs techniques
- ### Insights sur les outils business-app
- Zite produit des interfaces visuellement abouties même pour des applications métier
- La limitation aux "business apps" n'empêche pas un design moderne et engageant
- L'intégration native avec les outils SaaS populaires (Airtable, Google Sheets) est un avantage concurrentiel majeur
- ### Réalités économiques du vibe coding
- Les plans gratuits se consomment rapidement sur des projets réels
- Les upgrade sont proposés avec des dark patterns (4x par défaut au lieu de 2x)
- Le coût peut rapidement grimper si l'outil n'est pas mature
- ### Gestion de projet et expectatives
- Prévoir plus de sessions que prévu initialement (10 au lieu de 5 estimées)
- Les bugs critiques peuvent complètement bloquer l'avancement
- L'importance d'avoir des alternatives techniques (Supabase + Cursor) en backup