Le process habituel — plusieurs semaines de double diamond, plusieurs semaines de dev — n'était pas tenable pour une feature bien comprise, dont les patterns existent déjà partout sur le marché. Lucas Didier a cherché un raccourci. Le résultat : moins d'une semaine de prototypage, une semaine de dev, une feature en bêta en deux semaines. L'ingrédient clé : un fichier Markdown appelé le Prototype Kit, qui donne à Claude Code la "constitution du design" du produit.
1. Quand on n'a pas de designer et qu'on doit aller vite
Le contexte : dans le cadre de l'intégration Bonsai-Zoom, l'équipe voulait ajouter une inbox email dans Bonsai — permettre aux utilisateurs de connecter Gmail ou Outlook et de voir l'historique de leur correspondance avec leurs contacts CRM, directement dans l'application. Un workflow classique, déjà implémenté dans HubSpot, Pipedrive et d'autres CRMs.
"Ce n'est pas quelque chose sur lequel on avait besoin de faire de la discovery très longue. Les problèmes étaient très clairs. Ce n'est pas quelque chose où on a besoin de réinventer la roue."
Contrainte supplémentaire : à ce moment-là, l'équipe n'avait pas de designer. La question : comment avancer vite sans designer, en gardant un niveau de qualité suffisant pour mettre la feature entre les mains des utilisateurs en bêta ?
Objectif : moins d'une semaine de prototypage + une semaine de dev, contre un mois à un mois et demi dans le process habituel.
2. Un fichier Markdown qui donne à Claude le contexte de votre produit
L'outil central du workflow est ce que Lucas appelle le Prototype Kit — un fichier Markdown qui décrit les règles de design du produit : couleurs, polices, composants (boutons, modals, inputs, cartes), règles d'espacement. "C'est un peu la constitution du design de votre produit."
Sans ce contexte, Claude génère un SaaS générique. Avec, le rendu est fidèle au produit existant. "Si vous n'avez pas de contexte, vous obtenez quelque chose d'OK, mais qui va ressembler à ce que n'importe qui peut faire en utilisant l'IA. Ça ne ressemblera pas à votre produit, à votre marque."
Le Prototype Kit de Bonsai contient aujourd'hui environ une trentaine de composants. Il a commencé avec les couleurs et les polices, et s'est enrichi progressivement. "Au début, il fallait vraiment expliquer de manière très minutieuse que tel composant est organisé de cette manière. Mais une fois que Claude comprend, là, c'est surpuissant."
Le fichier inclut aussi des bouts de code HTML/CSS d'exemple pour chaque composant. "Le Prototype Kit, c'est idéalement la même chose que ton design system, mais traduit dans le langage le mieux compris par Claude Code — un fichier Markdown avec du HTML et du CSS."
Lucas a mis à disposition un lien vers un Google Doc avec un prompt pour générer son propre Prototype Kit. Le prompt pose des questions et construit le fichier au fur et à mesure, à partir de captures d'écran du produit, d'un fichier Figma, d'une style guide ou de bouts de code front-end existants.
3. De cinq screenshots à un prototype interactif en dix minutes
Le workflow concret, illustré par un cas fictif (un module de to-do list pour Bonsai) :
Étape 1 : collecter des screenshots d'inspiration. Des outils comme Mobbin ou Dribbble permettent de trouver rapidement des exemples de patterns déjà bien explorés. "Il y a déjà plus de quatre-vingt-dix pour cent des réponses sur les problématiques produits qui existent déjà sur le marché."
Étape 2 : rédiger le prompt. Lucas utilise VS Code avec Claude Code. Son prompt type : utiliser le skill Front-end Design, utiliser le Prototype Kit, construire le prototype suivant [description du module], joindre cinq screenshots de produits concurrents avec l'instruction "regarde-les attentivement et identifie les patterns à reprendre de chacun — ce que toi tu y vois m'intéresse plus que ce que je pourrais décrire." Puis : utilise uniquement les vraies classes Bonsai du Prototype Kit, pas de style inventé, pas de Tailwind.
Étape 3 : analyser le retour de Claude. Claude commence par une synthèse des patterns qu'il a identifiés dans chaque screenshot (statuts colorés, groupage temporel, etc.), avant de générer le prototype.
Étape 4 : itérer. La première version est rarement parfaite. Lucas fait un follow-up : "Cette version a quelques problèmes d'espacement et d'alignement. Peux-tu vérifier ?" Claude identifie les problèmes et corrige. "La première version est rarement la bonne."
Résultat : un prototype HTML interactif (filtres cliquables, création de tâche, side panel de détail) généré en dix minutes, fidèle à l'UI de Bonsai.
"Pour quelque chose qui a pris dix minutes, je trouve ça vraiment solide. Surtout quand on regarde le temps que ça nous prenait il y a un an ou deux, quand on devait tout faire dans Figma."
4. Le dev a réutilisé une grande partie du code front-end généré
Sur la feature email inbox concrètement livrée : le rendu Claude montré en live et l'interface effectivement lancée en bêta sont très proches. Quelques différences mineures (largeur de la barre de recherche, tailles des images de profil), mais globalement fidèles. "Le développeur qui a intégré ça a pu réutiliser une grande partie du code front-end qui avait été généré. Ça nous a permis d'aller extrêmement vite."
Le passage du prototype à la prod fonctionne comme suit : les développeurs mettent le repo du prototype et la spec (un document de règles de fonctionnement rédigé en parallèle) dans un skill Claude. Claude génère une pull request pour la partie front-end déjà écrite. Le développeur se concentre sur ce qui reste — notamment le back-end (infrastructure de synchronisation email avec Google et Microsoft), qui "reste quelque chose d'assez lourd" non couvert par le prototype.
Sur le déploiement pour partager le prototype : Lucas utilise Cloudflare ou Vercel. "Claude peut pousser le prototype sur GitHub. Vous connectez Cloudflare ou Vercel à votre repo GitHub et vous publiez directement sur une page web partageable, avec mot de passe si besoin."
5. Scepticisme, enthousiasme hétérogène, et le kilomètre manquant
Côté développeurs. L'adoption de l'IA dans l'équipe est "assez hétéroclite". Certains devs appréciaient la précision des maquettes Figma pixel perfect et se plaignaient que le prototype Claude comporte des approximations. "Il y a certaines choses qui ne sont pas exactement fidèles à la production, peut-être quatre à quinze pour cent d'imprécision. Et certains profils aiment bien avoir les choses à cent pour cent de fidélité." L'équipe a fait un pas en arrière sur ce point et remet des maquettes Figma quand c'est nécessaire.
Sur les agents autonomes pour les bugs et petites améliorations : "On a commencé à mettre en place des agents basés sur Claude ou Cursor qui ouvrent des pull requests de manière autonome sur GitHub. Il y a encore beaucoup de faux positifs, du code parfois un peu spaghetti. On n'est pas encore au niveau de Stripe, où les PM ouvrent des PR directement approuvées par les devs."
Côté designers. Lucas ne voit pas les designers disparaître. "Le dernier kilomètre n'est pas parfait. Il y a besoin d'ajustements, et pour ça, tu as besoin d'un designer." L'usage qu'il en fait maintenant : générer deux ou trois explorations rapidement, les envoyer au designer comme base de discussion. "Le fait de pouvoir générer en dix minutes une illustration parfaite de ce que j'avais en tête, c'est génial. Le designer me comprend immédiatement." Son head of design a commencé à faire des remixs des explorations Claude.
Sur Claude Design (l'outil de génération d'interfaces d'Anthropic) : "Pour l'instant, il n'arrive pas à être complètement fidèle à notre design system. Il crée parfois des composants sortis de nulle part. C'est intéressant pour diverger, explorer des solutions dans tous les sens. Mais pas pour quelque chose de fidèle au produit."
Sur l'intégration prototype → Figma : deux approches explorées. Un plugin HTML to Figma (extension Chrome). Et le MCP Figma de Claude, qui permet d'envoyer directement le contenu d'un prototype dans Figma. "J'ai à peine commencé à explorer ça, mais c'est assez prometteur."
6. Le bon usage du workflow
Lucas pose des conditions claires pour que ce workflow soit pertinent.
Ça marche quand
Les patterns sont "commodity" — des UX explorées des milliers de fois, auxquelles les utilisateurs sont habitués (email, to-do, calendrier, CRM). Pas besoin de réinventer la roue. Les délais sont serrés et les problèmes bien compris. On n'a pas besoin de discovery profonde ni de research utilisateur étendue.
Ça ne marche pas bien quand
On est sur des UX nouvelles ou exploratoires. Les interactions sont complexes, avec beaucoup d'animations. Les problèmes sont mal définis et nécessitent une discovery approfondie.
Sur le jugement produit : Lucas revient plusieurs fois sur un point de vigilance. "Il faut faire attention à ne pas outsourcer en permanence le jugement produit à Claude. Il faut continuer à exercer son jugement. Si tu délocalises tout à l'IA, tu vas juste devenir un exécutant qui ne réfléchit pas."
"Le contexte, c'est ce qu'il y a de plus important. Si vous n'avez pas de contexte, vous obtenez un résultat générique. Avec un Prototype Kit, l'IA connaît ton design system et le rendu est beaucoup plus fidèle."