Construire un MVP avec Claude : de l'idée au déploiement

Le jour où j'ai arrêté de tout coder seul

Pendant des années, construire un produit web en solo signifiait tout faire soi-même. Chaque composant React, chaque requête SQL, chaque animation CSS, chaque configuration de déploiement. Des semaines de travail pour un MVP que personne n'avait encore testé.

Quand j'ai commencé à utiliser Claude pour coder, le changement n'a pas été progressif. Il a été brutal. Ce qui me prenait une journée entière — construire un formulaire avec validation, gestion d'erreurs, connexion à Supabase, feedback utilisateur — se faisait en deux heures. Pas parce que le code était bâclé. Parce que je n'avais plus à chercher la syntaxe, à relire la doc, à débugger des erreurs de typage absurdes. Claude faisait le gros du travail mécanique. Moi, je me concentrais sur les décisions.

Ce n'est pas un article sur "l'IA va remplacer les développeurs". C'est un article sur comment un non-développeur de formation — je suis growth marketer — utilise l'IA pour construire des produits web complets et les mettre en production.

Mon setup de développement

L'environnement

Mon setup est simple. VS Code avec Claude Code intégré. Un terminal. Un navigateur. C'est tout.

Je ne lance pas Claude dans une interface web séparée pour copier-coller du code. Claude Code est directement dans mon éditeur. Il voit mes fichiers, comprend la structure du projet, peut lire et modifier le code en place. La différence est fondamentale : au lieu de décrire mon problème dans un chat, je travaille dans le contexte réel du projet.

Quand je dis "ajoute un champ téléphone au formulaire d'inscription avec validation format réunionnais", Claude voit le formulaire existant, comprend la stack (React, TypeScript, Tailwind), et modifie directement les bons fichiers. Pas de copier-coller, pas de "adapte ce code à ton projet". Le code est adapté par défaut.

Le repo template

Pour chaque nouveau projet, je pars d'un template que j'ai construit au fil du temps. Next.js, TypeScript, Tailwind, Supabase, Stripe. L'auth est configurée, le layout de base est en place, les variables d'environnement sont prêtes. Créer un nouveau projet, c'est cloner le repo, changer le nom, connecter une nouvelle instance Supabase, et commencer à construire les features spécifiques.

Ce template, je l'ai construit avec Claude. Les premières itérations étaient bancales — des configurations qui ne marchaient pas ensemble, des dépendances en conflit. Mais après trois projets (Kala, MafateRésa, Zinfluence), le template est solide. Il représente des dizaines d'heures de debugging condensées en un git clone.

Le process : de l'idée au code

Phase 1 : Structurer l'idée (1-2 jours)

Avant d'écrire une ligne de code, je passe du temps avec Claude à structurer le projet. J'ai détaillé ce process dans un article précédent, mais en résumé : on définit le problème, les personas, le parcours utilisateur, le business model, et surtout le périmètre du MVP.

Le livrable de cette phase, c'est une liste de features priorisées. Pas un cahier des charges de 50 pages — une liste. Pour MafateRésa, ça ressemblait à ça :

MVP (semaine 1-3) :

• Page d'accueil avec liste des gîtes
• Page gîte individuelle avec photos, description, tarifs
• Calendrier de disponibilités par gîte
• Formulaire de réservation
• Paiement Stripe
• Email de confirmation
• Tableau de bord gérant (voir réservations)

V2 (après validation) :

• Carte interactive de Mafate
• Système d'avis
• Messagerie gérant ↔ randonneur
• Gestion multi-gîtes

La frontière entre MVP et V2 est la décision la plus importante du projet. Claude m'aide à la tracer, mais c'est moi qui tranche.

Phase 2 : Le modèle de données (1 jour)

C'est là que Claude brille. Je décris en français ce que le produit doit stocker et gérer, et Claude me génère le schéma SQL complet avec les tables, relations, contraintes, et politiques RLS (Row Level Security) pour Supabase.

Pour Kala, la conversation ressemblait à ça :

"J'ai besoin de gérer des annonces de matériel outdoor. Chaque annonce a un propriétaire, un titre, une description, des photos, un prix par jour, une localisation, une catégorie. Les utilisateurs peuvent réserver du matériel pour des dates spécifiques. Il faut gérer la caution, le paiement, et le statut de la réservation."

Claude génère les tables profiles, listings, listing_images, bookings, reviews, avec toutes les foreign keys, les contraintes CHECK, les index, et les politiques RLS. Le RLS est crucial — c'est ce qui garantit qu'un utilisateur ne peut voir et modifier que ses propres données, directement au niveau de la base.

Je vérifie toujours le schéma avant de l'appliquer. Claude fait parfois des choix que je conteste — un TEXT là où je veux un VARCHAR(255), un CASCADE là où je préfère RESTRICT. Mais 90 % du schéma est bon du premier coup. Le 10 % restant, c'est de l'ajustement, pas de la reconstruction.

Phase 3 : Les pages et composants (1-2 semaines)

C'est la phase la plus longue, mais aussi celle où le gain de productivité est le plus visible. Je construis page par page, feature par feature, en dialogue constant avec Claude.

Ma méthode : je décris ce que je veux en langage naturel, Claude génère le code, je teste dans le navigateur, je corrige, j'itère. Le cycle complet — description → code → test → correction — prend entre 15 minutes et 2 heures selon la complexité de la feature.

Exemple concret : le calendrier de disponibilités de MafateRésa.

"Je veux un calendrier qui affiche les disponibilités d'un gîte sur les 3 prochains mois. Les jours disponibles sont cliquables, les jours complets sont grisés. Quand le randonneur sélectionne une date d'arrivée et une date de départ, le prix total s'affiche en dessous."

Claude génère un composant React avec :

• Un calendrier en grille CSS (pas de librairie externe)
• Les requêtes Supabase pour récupérer les réservations existantes
• La logique de sélection de plage de dates
• Le calcul du prix (nuitées × tarif)
• Les styles Tailwind

Le premier rendu est fonctionnel dans 80 % des cas. Les 20 % restants, c'est du fine-tuning : "le calendrier ne scroll pas bien sur mobile", "il faut désactiver les dates passées", "le prix doit inclure la commission". Chaque ajustement prend quelques minutes.

Phase 4 : L'intégration Stripe (2-3 jours)

Le paiement, c'est toujours la partie la plus technique. Pas parce que Stripe est compliqué — la doc est excellente — mais parce que les edge cases sont nombreux. Annulations, remboursements, cautions bloquées, webhooks, gestion des erreurs.

Claude connaît bien Stripe. Il génère les API routes Next.js pour créer les sessions de paiement, les webhooks pour confirmer les transactions, et la logique de mise à jour de la base après paiement. Mais c'est aussi la partie où je vérifie le plus. Un bug de paiement, c'est un client qui perd de l'argent. Pas de droit à l'erreur.

Pour Kala, la caution bloquée a été le morceau le plus complexe. Stripe permet de "capturer" un paiement plus tard (payment intent avec capture_method: 'manual'). Le flow : on autorise le montant de la caution au moment de la réservation, on le capture si le matos est endommagé, on l'annule sinon. Claude a généré la base du code, mais j'ai passé une journée entière à tester tous les scénarios — autorisation qui expire, capture partielle, annulation après capture.

Phase 5 : Le déploiement (quelques heures)

Vercel rend le déploiement trivial. Un git push et c'est en ligne. Mais il y a quand même des étapes :

• Configurer les variables d'environnement en production (Supabase URL, Stripe keys, etc.)
• Mettre en place le domaine custom
• Configurer les DNS
• Tester le paiement en mode live (pas juste test)
• Vérifier les emails transactionnels
• Mettre en place Sentry pour le monitoring d'erreurs

Claude m'aide sur chaque étape. "Comment configurer le DNS pour un domaine .re sur Vercel ?" "Comment tester les webhooks Stripe en local avec le CLI ?" Ce sont des questions que je pourrais chercher dans la doc, mais avoir la réponse contextualisée à mon projet fait gagner un temps considérable.

Les limites de Claude pour le dev

Il ne voit pas l'écran

Claude ne sait pas à quoi ressemble l'app dans le navigateur. Il peut générer du code CSS parfait syntaxiquement mais visuellement cassé. Un composant qui overflow, un z-index mal placé, une animation qui saccade — il ne les détecte pas. C'est à moi de tester, de faire des captures d'écran, de décrire ce qui ne va pas.

Avec Claude Code, c'est mieux — il peut lancer un serveur de dev et prendre des screenshots. Mais le feedback loop reste plus lent que si un humain regardait l'écran en temps réel.

Il oublie le contexte

Sur un long projet, Claude perd le fil. Il ne se souvient pas que la table bookings a changé de structure hier, ou que j'ai décidé de ne pas implémenter la messagerie. Il faut régulièrement re-contextualiser. "Rappel : on utilise Supabase RLS, pas de vérification côté API."

La solution : un fichier CLAUDE.md à la racine du projet avec les conventions, les décisions d'architecture, les choix techniques. Claude le lit au démarrage et ça réduit les rappels nécessaires.

Il fait des erreurs subtiles

Claude ne fait presque jamais d'erreurs grossières. Mais il fait des erreurs subtiles — un useEffect avec des dépendances manquantes, un await oublié dans un try/catch, une requête Supabase qui ne filtre pas par user_id. Ces bugs passent la compilation TypeScript mais explosent en production.

Ma parade : TypeScript strict, Sentry en production, et des tests manuels systématiques de chaque feature avant de pousser. Je n'ai pas de tests automatisés sur mes MVPs — le rapport coût/bénéfice ne le justifie pas quand tu es seul et que le produit va pivoter trois fois avant de stabiliser.

Il ne connaît pas le terrain

Claude ne sait pas que les gérants de Mafate ont 60 ans et utilisent un Samsung Galaxy J3 avec un écran de 5 pouces. Il ne sait pas que le réseau 3G à Marla coupe toutes les 30 secondes. Il ne sait pas que les propriétaires de chiens réunionnais paient en espèces au marché forain.

Ces contraintes, c'est moi qui les apporte. L'IA est un outil, pas un product manager. La connaissance du terrain, les conversations avec les utilisateurs, l'intuition construite sur 7 ans de growth marketing — ça, aucune IA ne le remplace.

Les gains de temps réels

Voici une estimation honnête du temps gagné avec Claude, par projet :

MafateRésa :

• Sans IA : 8-10 semaines de dev (estimation basée sur des projets similaires avant Claude)
• Avec Claude : 3 semaines
• Gain : ~60 %

Kala :

• Sans IA : 12-15 semaines (plus complexe : marketplace, caution, multi-rôles)
• Avec Claude : 5 semaines
• Gain : ~65 %

Zinfluence :

• Sans IA : 6-8 semaines
• Avec Claude : 2 semaines (en cours, estimation)
• Gain : ~70 %

Le gain augmente avec le temps. Pas parce que Claude s'améliore (même si c'est le cas) — parce que je m'améliore dans la façon de l'utiliser. Je sais quoi lui demander, comment formuler, quand vérifier, quand faire confiance.

Ce que je ferais différemment

Si je recommençais de zéro aujourd'hui, je changerais deux choses :

1. Écrire le CLAUDE.md dès le jour 1. Sur mes premiers projets, je n'avais pas de fichier de contexte. Claude redécouvrait le projet à chaque session. Maintenant, le CLAUDE.md est le premier fichier que je crée — avant même le premier composant.

2. Tester le paiement plus tôt. J'avais tendance à construire toute l'interface avant d'intégrer Stripe. Erreur. Le paiement, c'est le cœur du business model. Si le flow de paiement ne marche pas ou est trop complexe, rien d'autre ne compte. Maintenant, Stripe est intégré dès la semaine 1.

Le conseil

L'IA ne te transforme pas en développeur. Elle te permet de construire sans en être un — à condition de comprendre ce que tu construis. Si tu ne comprends pas ce qu'est une API, une base de données, un composant React, Claude ne te sauvera pas. Tu vas copier du code sans savoir pourquoi il marche, et quand il cassera (et il cassera), tu seras perdu.

Mon avantage, ce n'est pas de savoir coder. C'est de comprendre les systèmes : comment les données circulent, comment les utilisateurs interagissent, comment les paiements fonctionnent. L'IA comble le gap entre comprendre et implémenter. Mais le comprendre, c'est toi qui dois l'apporter.

Si tu veux te lancer : apprends les bases. Comprends HTML, CSS, JavaScript, les requêtes HTTP, les bases de données relationnelles. Pas besoin de maîtriser — juste de comprendre. Ensuite, lance-toi avec Claude. Construis un truc simple. Casse-le. Répare-le. Recommence. C'est comme ça que j'ai appris.