Premiers prototypes avec Claude Code et Lovable : quand le prototype devient une conversation

Alexia Maynart, Senior Consultant Data & AI chez Converteo, allie son expertise de Product Manager à ses compétences techniques en développement. En tant que Product Builder, elle conçoit des solutions innovantes basées sur l’IA et l’agentique, transformant les besoins métiers en produits technologiques à fort impact.

À retenir

• Grâce à Claude Code interrogeant directement la codebase, les Product Managers peuvent désormais créer des prototypes fonctionnels en quelques heures, sans mobiliser immédiatement designers ou développeurs.
• L’activation du protocole MCP permet à l’IA de se connecter à des outils de création comme Lovable pour générer des interfaces de test enrichies par le contexte réel du produit (design system, requêtes utilisateurs).
• Le prototypage change de rôle : de livrable coûteux réservé aux idées matures, il devient un support de dialogue précoce permettant d’explorer, de cadrer et de réduire l’ambiguïté avant même la rédaction des spécifications.

Deuxième session du Grand Rattrapage, la série de talks organisée par Converteo et Le Ticket, et changement de registre : après la veille, place au prototypage. Jules Boiteux, fondateur de Vibe Coding Academy, a déroulé un scénario que beaucoup de Product Managers vivent chaque mois.

Le scénario : une demande utilisateur, pas de designer disponible

Le fil rouge était volontairement réaliste. On se met dans la peau d’un PM chez Excalidraw, outil de whiteboard collaboratif open source, concurrent de Miro et FigJam, qui reçoit une demande utilisateur récurrente : ajouter un template de tableau, comme dans FigJam. Objectif : explorer et prototyper cette fonctionnalité sans ressource design ni intervention des devs.

Dans beaucoup d’équipes, cette situation se traduit encore par une attente, un wireframe rapide ou une spec abstraite difficile à discuter. Avec Claude Code et Lovable, ce même PM peut désormais produire une première version testable en quelques heures.

Le point clé souligné par Jules dépasse l’outillage : le vrai changement de paradigme n’est pas que les PM « codent », mais qu’ils peuvent désormais interroger directement la codebase, véritable source de vérité du produit, pour générer prototypes, specs et tickets avec un contexte réel, au lieu de se fier à une documentation produit souvent obsolète. Dans cette logique, Claude Code (version Desktop) est utilisé comme un véritable « système d’exploitation », de la discovery à la delivery.

Étape 1 – Prendre en main Claude Code

Le PM dispose d’un environnement local où tourne une copie de la codebase d’Excalidraw, ce qui permet d’expérimenter sans risque sur le produit en production. Quelques réflexes partagés en démo :

• Importer la codebase en donnant simplement le lien du repo GitHub (facilité ici par le fait qu’Excalidraw est open source).
• Préciser son niveau de technicité dès le départ : « je suis PM, pas dev ». Claude adapte alors ses réponses et s’en souvient pour la suite.
• Lancer plusieurs sessions en parallèle, chacune avec son propre contexte, pour traiter différents sujets sans mélanger les fils.
• Désactiver la QA automatique pour les tâches visuelles/front-end : par défaut, Claude prend le contrôle du navigateur pour vérifier le rendu, mais le PM peut le faire lui-même (gain de temps et de tokens).
• Ajuster le modèle à la tâche : pour une analyse simple (décrire une codebase), un modèle comme Sonnet avec un niveau d’effort medium suffit largement.

Étape 2 – Comprendre et activer le MCP Lovable

Rappel utile fait en séance : le MCP (Model Context Protocol), introduit par Anthropic, est un protocole qui permet à un LLM de se connecter à des outils tiers. L’image employée est celle d’une « prise USB » pour Claude, sans passer par des API classiques.

L’activation se fait via la commande /mcp dans Claude Code, qui liste les connecteurs disponibles par défaut, dont Lovable. Le processus : autoriser la connexion côté Lovable, puis redémarrer l’application pour qu’elle prenne effet. Conseil de Jules : toujours vérifier explicitement que la connexion fonctionne, en reformulant la question si besoin (« est-ce que je suis connecté par MCP ? » plutôt qu’un vague « à Lovable ? »). À noter aussi sur les coûts : avec Lovable, on consomme des tokens à la fois côté Claude et côté Lovable, alors qu’avec Notion ou Jira le coût est absorbé par l’API de l’outil tiers.

Étape 3 – Générer le prototype dans Lovable depuis Claude Code

Le workflow démontré tient en quelques mouvements :

1. Créer d’abord une réplique complète d’Excalidraw dans Lovable, le « Master Project », à ne jamais supprimer, qui sert de source de vérité pour tous les futurs prototypes.
2. Dupliquer (« remix ») ce master project pour chaque nouvelle fonctionnalité à tester, afin de ne jamais toucher à la référence.
3. Enrichir le prompt avec du contexte réel : captures d’écran de la fonctionnalité équivalente chez un concurrent (FigJam), lien vers l’issue GitHub remontée par les utilisateurs.
4. Claude Code scanne la codebase (design system, couleurs, police propriétaire « Excalifont »), puis appelle le MCP Lovable pour créer ou modifier le projet.
5. Résultat en quelques prompts (environ 10-15 minutes) : un prototype fonctionnel avec le nouveau bouton « tableau », proche sans être parfaitement fidèle, largement suffisant pour un premier test utilisateur.

Pourquoi Lovable plutôt que Figma, Claude Design ou un déploiement classique type Vercel ? Figma fonctionnerait aussi (un MCP Figma existe) : c’est une affaire de préférence d’interface. Claude Design ne permet pas encore de prompter la création directement depuis Claude Code. Et un déploiement Vercel dépend des contraintes techniques de l’entreprise, là où Lovable offre en plus un éditeur collaboratif en temps réel pour itérer à plusieurs sans repasser par tout le cycle Git.

Le vrai changement : le prototype arrive plus tôt dans la conversation

Le message central n’était pas « tous les PM vont devenir développeurs ». Il est plus subtil : le prototype devient un support de dialogue beaucoup plus tôt dans le processus. Au lieu de discuter d’une idée, d’un benchmark ou d’une spec, l’équipe réagit à un objet concret. Les utilisateurs testent, les designers challengent, les développeurs identifient les contraintes techniques, les parties prenantes comprennent plus vite ce qui est en jeu.

Cela déplace la valeur même du prototype : il ne sert plus seulement à montrer à quoi une fonctionnalité pourrait ressembler, mais à apprendre plus vite et à réduire l’ambiguïté. Une première version, même imparfaite, vaut souvent mieux que dix pages de spec pour aligner une équipe.

Le flux fonctionne d’ailleurs dans les deux sens. Une fois le prototype validé avec les utilisateurs, le MCP peut réimporter le contenu généré dans Lovable vers Claude Code pour produire des spécifications, créer des tickets ou faire une première analyse de faisabilité technique, avant de transmettre aux développeurs.

Pourquoi c’est un sujet structurel pour les équipes Product ?

Ce cas d’usage redéfinit la frontière entre l’exploration et la construction. Historiquement, le coût de production d’un prototype fonctionnel imposait de le réserver aux idées déjà bien cadrées. Quand ce coût s’effondre, la logique s’inverse : on peut prototyper pour cadrer, et non plus cadrer pour prototyper.

Deux enseignements pratiques renforcent le propos. D’abord, l’optimisation des tokens est un enjeu à part entière : Jules recommande de gérer la fenêtre de contexte de chaque session (plus elle est chargée, plus le risque d’hallucination et la consommation augmentent) et de la reset régulièrement, en s’appuyant sur des sub-agents pour sous-traiter des tâches précises. Ensuite, sur le ROI : produire un prototype haute-fidélité avec l’IA est désormais, selon Jules, plus rapide qu’une maquette Figma classique, et plus fidèle au produit réel, même en tenant compte du coût des modèles (Sonnet comme Opus 4.8 restent rentables face au temps de maquettage traditionnel).

L’IA ne supprime donc ni le travail de design ni celui de développement. Elle permet au PM d’arriver dans la conversation avec une matière plus tangible, plus testable et plus facile à critiquer, sans attendre que toutes les expertises soient disponibles pour commencer à apprendre. C’est toute la posture du Product Builder : rester autonome sur l’ensemble du cycle (discovery > prototype > specs > tickets) tout en continuant à collaborer avec le design et la tech.