Comment un chef de produit sans bagage technique a monté deux pilotes en une semaine avec Claude et Kiro

Un product manager sans expérience pratique en développement a décrit un cas où en une semaine il a construit et déployé deux pilotos fonctionnels à l'aide de Claude, Kiro, Figma Make et des serveurs MCP. L'histoire est intéressante non seulement par le résultat en lui-même, mais aussi par la façon dont elle change la barrière d'entrée pour lancer les premières versions d'un produit sans une équipe d'ingénierie complète.

Composition du stack

Au cœur du flux se trouve une division des rôles entre plusieurs outils d'IA. L'auteur a utilisé Claude Sonnet 4.5 pour la découverte : audience, points de douleur, jobs-to-be-done, contraintes et valeur métier y étaient chargés. Les résultats incluaient l'analytique, le contenu et les prompts pour les étapes suivantes. Figma Make était responsable de la génération du frontend, et Kiro d'Amazon gérait l'assemblage, les décisions architecturales et le déploiement. Pour l'infrastructure, Supabase était utilisé pour la base de données, GitHub Pages pour l'hébergement et les serveurs MCP pour le contexte et les tests.

• Claude Sonnet 4.5 — découverte, analytique, contenu et prompt système
• Figma Make — génération du frontend pour la version pilote
• Kiro — assemblage du projet, documentation des solutions et déploiement
• Supabase et GitHub Pages — base de données et publication
• Context7 et Playwright via MCP — mémoire entre sessions et vérifications e2e basiques

Cet ensemble est intéressant car il ne cherche pas à forcer un seul outil à tout faire. L'auteur a distribué les tâches selon les points forts de chaque service, réduisant ainsi le nombre d'éditions manuelles. Selon son évaluation, rien que l'étape d'analytique et de design a permis d'économiser environ 40 heures — précisément parce que les artefacts de découverte passaient à la génération d'interface puis à l'assemblage avec des pertes minimales.

Flux étape par étape

Le processus commençait non par du code, mais par la définition du problème. Pour chaque produit, un assistant séparé dans Claude était créé, auquel on transmettait tout le contexte : qui est l'utilisateur, quel problème le service résout, ce qui compte comme valeur et quelles contraintes ne peuvent pas être violées. Après cela, les matériaux étaient transférés à Figma Make, où un frontend était généré sans affinage manuel. Dans le cas, il s'agissait de deux projets : un site personnel de consulting en produit et un outil agile gratuit que l'auteur considère comme une alternative précoce à Jira pour les startups.

L'étape suivante était de passer le frontend et l'analytique à Kiro. L'auteur met l'accent sur cet outil comme centre de tout le pipeline, car Kiro formule d'abord les solutions par écrit, puis les implémente sans sauter directement au code. Ensuite, trois serveurs MCP étaient connectés : Context7 pour maintenir le contexte entre sessions, Supabase MCP pour le schéma de base de données et les migrations, Playwright MCP pour vérifier les scénarios critiques utilisateur.

L'étape finale avait l'air maximalement pratique : inscription sur GitHub et Supabase, création de base de données, déploiement sur GitHub Pages et instructions pour la liaison de domaine.

Où sont les goulots d'étranglement

L'auteur formule directement la limitation principale : ce flux fonctionne bien pour les pilotos et MVP, mais ne résout pas les questions de qualité sur le chemin vers la production complète. Si le produit est conçu pour une charge élevée, des intégrations complexes ou un support à long terme, l'architecture doit toujours être revérifiée par une personne. Cela s'applique particulièrement aux décisions que Kiro peut prendre automatiquement : l'article note que certaines d'entre elles semblent douteuses sans un examen technique basique.

Il en va de même pour les fenêtres de contexte : Context7 aide à ne pas perdre le fil du projet, mais ne fait pas complètement disparaître le problème de la mémoire.

"Le vibe-coding n'est pas un remplacement pour les développeurs."

Un autre risque est lié aux tests. Playwright MCP, selon l'observation de l'auteur, couvre avec assurance le happy path, c'est-à-dire les scénarios basiques, mais n'élimine pas la nécessité de vérifier séparément les edge cases. Par conséquent, le stack décrit se présente comme un outil de vérification rapide d'une hypothèse et un processus prévisible pour un product manager non technique ; sa faiblesse est le besoin d'impliquer un ingénieur à temps quand le piloto commence à se transformer en un vrai produit.

Ce que cela signifie

Le cas montre un changement dans l'économie du lancement : aujourd'hui, un product manager ou un fondateur peut assembler un piloto fonctionnel sans embaucher une équipe et sans semaines de préparation s'il peut formuler clairement les exigences et assembler les outils dans un flux cohérent. Mais c'est aussi là où réside la limite de l'approche : l'IA accélère la première version, pas la discipline d'ingénierie, quand un produit commence à croître.