← Retour au catalogue
Dojo Épisode #25 1:00:07

Vibe Coding Dojo avec Joyce Kettering : on construit une app avec WeWeb

Dojo avec Joyce Kettering (DevRel chez WeWeb) sur la construction d'une application avec WeWeb à l'ère du vibe coding : démonstration du nouveau backend full stack, du MCP WeWeb et de la création d'un test de personnalité Big Five — comparant Codex, Claude Code et WeWeb AI sur un même projet, avec une réflexion sur le rôle des plateformes professionnelles face aux outils de vibe coding pur.

Stack technique

Résumé de la session

Pour ce dojo, Alexis reçoit Joyce Kettering, DevRel chez WeWeb depuis quatre ans et demi. Le sujet : comment WeWeb évolue à l'ère du vibe coding, entre backend natif, MCP et IA intégrée. Joyce commence par revenir sur les deux grandes nouveautés de 2026 : le backend full stack (sorti mars-avril) et le MCP WeWeb (mi-juin). Le backend natif répond à un constat simple : quand les utilisateurs peinaient à connecter Xano, Supabase ou Airtable depuis l'éditeur visuel, on les perdait à cette étape — sans parler des bugs qu'ils attribuaient à WeWeb alors qu'ils venaient du backend tiers. L'IA ne pouvait pas non plus avoir le contexte du backend externe. Le MCP, lui, vient intégrer WeWeb dans les flux de travail existants (Claude Code, Codex, Cursor) pour les utilisateurs qui ont déjà leur propre manière de coder.

La démonstration porte sur un test de personnalité Big Five, inspiré d'une vidéo de Mark Manson expliquant pourquoi c'est le seul test reconnu scientifiquement par les chercheurs en psychologie. Joyce a utilisé ChatGPT pour trouver les questions officielles (open source, issues d'un projet de recherche), puis a lancé la construction avec différents outils pour comparer les approches.

Avec Claude Code et Sonnet 5, le résultat la déçoit : l'application est laide et les interactions laborieuses. Avec Codex et GPT 5.5, le résultat est bien meilleur — la landing page, le formulaire et la page de résultats sont générés en one-shot. Mais un bug d'intégration OpenAI (variable d'environnement mal configurée côté WeWeb) la bloque pendant des heures : elle envoie l'erreur à l'IA, qui propose un fix, qui ne marche pas, et la boucle s'auto-entretient. La leçon : il faut savoir s'arrêter, réfléchir et simplifier le problème plutôt que de laisser l'IA tourner en rond. Une fois cette démarche adoptée, le bug est résolu en 20 minutes.

Le débat porte ensuite sur la différence fondamentale entre WeWeb et les outils de vibe coding pur (Lovable, Bolt). WeWeb offre un cadre contrôlé : tables, workflows, authentification, gestion des permissions, middleware, environnements séparés (dev/prod) et un bouton pour mettre en ligne. Là où le vibe coding pur oblige à gérer l'hébergement, la base de données, la sécurité et la mise en production, WeWeb industrialise ces aspects. Joyce insiste : « Le MCP va construire, mais toute la partie contrôle et maintenance, je vais les gérer manuellement sans consommer de tokens. »

La discussion s'élargit aux bonnes pratiques : découper les tâches en itérations de 15-30 minutes pour maîtriser le contexte et le coût en tokens, démarrer une nouvelle conversation par feature, et rester « l'humain qui contrôle toutes les demi-heures ». Joyce et Alexis s'accordent sur le fantasme du prompt du soir qui produit une app prête au réveil : « C'est de la connerie absolue — on construit des applications par petits bouts, on teste, on itère, on reste en contrôle. »

Le live se termine sur une réflexion sur l'emploi. Les agences no-code souffrent, les grands comptes adoptent les plateformes comme WeWeb pour leur contrôle, et les développeurs traditionnels équipés d'outils IA rattrapent leur retard de productivité. Le marché se recompose autour de la valeur professionnelle plutôt que de la promesse magique du « tout par l'IA ».

Ce qu'on a appris

  • WeWeb a sorti un backend full stack (mars-avril 2026) et un MCP (mi-juin 2026) pour s'intégrer dans les flux Claude Code, Codex et Cursor — l'IA peut désormais avoir le contexte du backend.
  • Le backend natif résout un problème clé : quand les utilisateurs connectaient un backend tiers, on les perdait à cette étape et les bugs étaient attribués à WeWeb alors qu'ils venaient de l'extérieur.
  • Avec Claude Code et Sonnet 5, le résultat d'une même application était décevant. Avec Codex et GPT 5.5, le même brief donnait un bien meilleur résultat — le modèle et l'environnement impactent fortement le rendu final.
  • Quand l'IA tourne en boucle sur un bug, il faut savoir s'arrêter, réfléchir et simplifier le problème plutôt que de lui renvoyer l'erreur sans fin — la boucle pourrit le contexte et coûte des tokens.
  • Le bug de la démo (variable d'environnement OpenAI mal configurée) a été résolu en 20 minutes une fois la démarche de simplification adoptée, après des heures d'itérations stériles avec l'IA.
  • WeWeb offre des garde-fous professionnels : tables, authentification, permissions, middleware, environnements séparés, et un bouton de mise en ligne. Le vibe coding pur oblige à gérer tout ça soi-même.
  • « Le MCP va construire, mais toute la partie contrôle et maintenance, je vais les gérer manuellement sans consommer de tokens » — l'éditeur visuel reprend la main là où l'IA coûte trop cher.
  • Découper les tâches en itérations de 15-30 minutes maîtrise le contexte et le coût en tokens. Nouvelle feature = nouvelle conversation.
  • Le fantasme du prompt du soir qui produit une app prête au réveil est irréaliste : on construit par petits bouts, on teste, on itère, on reste en contrôle.
  • Les agences no-code souffrent face aux développeurs équipés d'IA et aux clients qui se débrouillent seuls avec Lovable. Les grands comptes adoptent WeWeb pour son contrôle et sa sécurité.
  • Être passé par la difficulté du no-code visuel (WeWeb) prépare mieux à l'IA que débarquer de nulle part avec un prompt Lovable — la compréhension des fondamentaux reste un avantage décisif.
  • Le MCP WeWeb utilise des tokens pour construire, mais la maintenance visuelle (éditeur de tables, workflows) n'en consomme pas — un avantage économique sur le long terme.
  • Préciser dans le prompt « je veux être l'humain qui contrôle toutes les 30 minutes » évite les sessions trop longues et les dérives de contexte.