"Moi, je ne suis pas dev."
C'est ce que se dit Martin en commençant. Un besoin simple : centraliser ses design tokens quelque part.
Pas de budget pour une solution du marché.
Pas de développeur dispo.
Alors il le fait lui-même.
Un POC sur V0 avec le stockage local du navigateur.
Juste pour tester. Juste pour lui. Sur son PC.
Puis il en parle autour de lui.
À d'autres designers qui gèrent des design systems. Et il réalise que le besoin est partout. Et là, le side project devient un vrai SaaS avec base de données, API, plugin Figma, synchro multidirectionnelle, MCP.
Le tout vibe-codé. Par un designer.
Le jeudi 2 avril, Martin Molcrette va nous ouvrir les coulisses de cette construction de A à Z, du premier POC au produit en production :
↳ Comment passer d'un POC vibe-codé sur V0 à un SaaS scalable
↳ Les pièges de sécurité que personne ne voit venir quand on n'est pas dev
↳ Le débat : faut-il encore ouvrir Figma en 2026 ?
Ce qu'on va décortiquer ensemble :
1️⃣ Du besoin au POC : quand un designer décide de builder
→ Le point de départ : un besoin de centraliser les design tokens, zéro budget
→ Le premier POC sur V0 : stockage local, pas de base de données, juste pour tester
→ Le moment où il réalise que le besoin dépasse son propre usage
2️⃣ Du POC au SaaS : scaler un produit vibe-codé
→ Comment passer de V0 à Claude Code pour intégrer des fonctionnalités premium
→ Base de données, API, plugin Figma avec synchro multidirectionnelle
→ La standardisation via le DTCG (Design Token Community Group) pour rendre le produit compatible
3️⃣ Les risques que personne ne voit venir
→ Les tables Supabase exposées en clair quand n'importe qui peut dump ta base
→ Le piège : on se focus sur les features, on oublie la sécurité (politiques RLS, droits admin)
→ Les garde-fous à mettre en place skills, sub-agents, architecture propre
4️⃣ Si c'était à refaire : la méthode pour partir propre
→ Poser la vision produit avant de coder PRD, frameworks de cadrage
→ Avoir une architecture carrée dès le départ, quitte à s'aider des LLM pour la définir
→ Éviter le syndrome du "ça marche aujourd'hui, ça casse demain"
5️⃣ Le débat : les designers doivent-ils encore ouvrir Figma ?
→ Martin n'a pas utilisé Figma pour l'UI de son propre produit pourquoi ?
→ Le futur du product design : du craft Figma au prompt design
→ Les MCP, les design systems en code, l'adaptive UI ce qui arrive
🎒 Tu repartiras avec :
- Le parcours complet d'un designer qui a buildé un SaaS de zéro avec le vibe coding
- Les erreurs de sécurité à éviter absolument quand on n'a pas de background technique
- Une méthode pour passer d'un POC à un produit scalable
- Une vraie réflexion sur l'avenir du rôle de designer à l'ère de l'IA
🗓 Jeudi 2 avril – 12h00
📍 Live interactif en direct + Q&A
💬 Pour designers, product builders et tous ceux qui se demandent si un non-dev peut vraiment shipper un SaaS en 2026
