Table des matières
Tu as installé Claude Code. Tu as compris les bases. Maintenant, on construit quelque chose de vrai.
Pas un todo-list. Pas un compteur de clics. Un vrai projet que tu vas utiliser.
On va créer un lead magnet avec gate social : une page où les visiteurs peuvent télécharger tes ressources (templates, scripts, guides), mais seulement après avoir suivi tes réseaux.
Ce qu'on va construire :
- Une page publique avec tes ressources
- Vérification réelle : LinkedIn, YouTube, Newsletter
- Téléchargement débloqué uniquement si les 3 conditions sont remplies
Ce qu'on ne fait PAS dans cet article :
Le déploiement. On fait tourner en local. Et crois-moi, c'est seulement la moitié du travail, parce que ce qui marche en dev ne marche pas toujours en prod. On verra ça dans un prochain article.
Le code de la vérification OAuth non plus. C'est le point dur du projet, et il mérite son propre article. Ce que tu trouves ici, c'est la méthode pour mener un premier projet de bout en bout avec Claude Code : cadrer, challenger, découper, avancer sans tout casser. Le lead magnet n'est que le prétexte, et la méthode marche sur n'importe quel autre projet.
Prérequis : Claude Code installé (voir le guide d'installation)
Phase 1 : Planification
C'est là que 80% des débutants se plantent. Ils ouvrent Claude Code et tapent direct "fais-moi un site".
Résultat : Claude part dans une direction, tu corriges, il repart ailleurs, tu perds 2 heures, et tu finis avec un truc bancal que tu comprends pas.
→ C'est une des six erreurs que je raconte en détail ici
La règle : plus tu planifies, moins tu galères.
Étape 1 : Définir le besoin en une phrase
Avant d'ouvrir Claude Code, écris ce que tu veux. Une phrase. Pas trois paragraphes.
"Je veux une page où les visiteurs peuvent télécharger mes ressources gratuites, mais seulement s'ils sont abonnés à ma newsletter, mon YouTube et mon LinkedIn."
C'est clair. C'est précis. Claude va comprendre.
→ Des prompts imprécis. Si toi tu sais pas ce que tu veux, Claude va inventer. Et ça sera pas ce que tu voulais.
Étape 2 : Lister les fonctionnalités (scope minimal)
Maintenant, découpe. Qu'est-ce qui est vraiment nécessaire pour une V1 ?
Inclus :
- Page publique avec liste des ressources
- Connexion OAuth (LinkedIn, YouTube, Google pour la newsletter)
- Vérification réelle des abonnements
- Bouton téléchargement conditionnel
- Stockage des fichiers
Exclus (pour l'instant) :
- Interface admin pour ajouter des ressources
- Dashboard analytics
- Système de commentaires
- Multi-langue
→ Vouloir tout faire d'un coup. J'ai voulu faire un chat avec WebSocket pour mon premier projet. J'aurais dû faire un simple formulaire.
Le scope minimal, c'est ce qui te permet de valider l'idée. Le reste, tu l'ajoutes après.
Étape 3 : Initialiser le projet et Git
Avant même de demander quoi que ce soit à Claude, on pose les fondations.
mkdir lead-magnet
cd lead-magnet
git initTu peux aussi simplement demander à Claude Code de le faire, il initialise le dépôt et commite tout seul au fil du projet. C'est même comme ça que je travaille aujourd'hui : je ne tape plus une commande Git de la journée.
Ce qui change, c'est ton rôle. Tu ne fais plus les commits, tu vérifies qu'ils sont sains. Deux réflexes suffisent : regarder ce qui est parti dans le dépôt (git log --oneline et git status) et t'assurer qu'aucun fichier sensible ne s'y trouve, un .env en tête. Claude commite ce qu'il voit, il ne sait pas ce qui doit rester chez toi.
→ Pas de Git, pas de doc. J'ai dû wipe un VPS entier parce que j'avais pas Git. Le filet de sécurité se pose toujours en premier, que ce soit toi ou Claude qui le tende. Si Git reste un mot flou pour toi, j'explique les quelques notions qui suffisent quand on vibecode, sans le cours complet.
Étape 4 : Utiliser le mode plan de Claude Code
Maintenant on ouvre Claude Code. Mais on ne lui dit pas "code-moi ça". On lui demande un plan.
claudePremier prompt :
Je veux créer un lead magnet avec gate social. Les visiteurs doivent pouvoir télécharger mes ressources gratuites (scripts, templates) seulement s'ils :
1. Sont abonnés à ma chaîne YouTube
2. Me suivent sur LinkedIn
3. Sont inscrits à ma newsletter
La vérification doit être réelle (OAuth + API), pas juste des checkboxes.
Fais-moi d'abord un plan détaillé avant de coder. Je veux valider chaque étape.
Claude va te sortir un plan. Quelque chose comme :
- Setup Next.js + Supabase
- Configurer OAuth (Google, LinkedIn, YouTube)
- Créer la base de données (users, resources, downloads)
- Page d'accueil avec liste des ressources
- Logique de vérification des abonnements
- Composant de téléchargement conditionnel
- Stockage des fichiers avec Supabase Storage
Ne dis pas "OK" tout de suite.
Étape 5 : Challenger le plan
C'est là que tu évites les catastrophes. Pose des questions.
"Pour la vérification LinkedIn, c'est quoi la méthode exacte ? L'API LinkedIn est restrictive, comment tu comptes faire ?"
"Le stockage des fichiers, c'est sécurisé ? Un utilisateur peut pas deviner l'URL et télécharger sans vérification ?"
"C'est quoi l'ordre des priorités ? Si je dois couper quelque chose, c'est quoi le minimum viable ?"
→ Ne pas comprendre ce qu'on fait. Claude est fort, mais il a pas le même contexte que toi. Il peut proposer une solution techniquement correcte mais inadaptée à ton cas.
Une fois que le plan te convient, là tu valides :
"OK, le plan me va. On commence par l'étape 1."
Aller plus loin que le mode plan
Le mode plan est le minimum vital, et il suffit largement pour un premier projet. Mais sur un projet plus gros, cette phase peut se pousser beaucoup plus loin.
Des méthodes complètes existent pour ça, BMAD, PRP ou SpecKit : au lieu d'un échange libre, tu déroules un cadrage en plusieurs rôles qui produit des spécifications avant la moindre ligne de code. C'est plus long, parfois plusieurs heures, et c'est du temps que tu ne passeras pas à rattraper une architecture bancale.
De mon côté, j'ai fini par enfermer cette phase dans une commande, pour ne plus dépendre de ma discipline du jour. Je détaille tout le workflow ici : les quatre piliers de contexte, et les cinq commandes qui enchaînent le cadrage, le découpage en tâches et l'implémentation.
Pour ton premier projet, reste sur le mode plan. Tu y reviendras quand un projet commencera à te dépasser, et c'est le bon moment pour ça.
Phase 2 : Implémentation
Le plan est validé. Maintenant on code. Mais pas n'importe comment.
Étape 6 : Une étape à la fois
Claude va commencer à générer du code. Reste là. Ne pars pas faire autre chose.
Regarde ce qu'il fait. Si tu vois quelque chose de bizarre, interromps-le :
"Attends, pourquoi tu utilises cette lib ? Y'a pas plus simple ?"
À chaque étape terminée, teste avant de passer à la suite.
npm run devContrairement à Git, le test est la partie que je garde pour moi. Cliquer soi-même dans son app, c'est le seul moment où tu vois vraiment ce que tu as construit, et c'est là que tu repères ce qu'aucun code ne t'aurait signalé.
Cela dit, quand la vérification devient répétitive, Claude peut piloter le navigateur et faire le parcours à ta place : ouvrir la page, remplir le formulaire, cliquer, et te dire ce qu'il a obtenu. Pratique pour lui faire retester dix fois un tunnel de connexion. Ça ne remplace pas ton coup d'oeil, ça t'évite de refaire à la main ce que tu as déjà validé une fois.
→ Ne pas tester assez vite. J'ai déjà eu des projets où tout semblait marcher, et à la fin rien ne fonctionnait ensemble. Teste au fur et à mesure.
Étape 7 : Gérer les blocages
Tu vas forcément avoir des erreurs. C'est normal.
Quand ça arrive :
- Copie l'erreur exacte
- Donne-la à Claude avec le contexte
- Laisse-le corriger
Si Claude tourne en rond (il propose la même solution 3 fois), c'est qu'il manque d'info. Donne-lui plus de contexte :
"Voici le fichier complet [colle le fichier]. L'erreur arrive quand je fais [action précise]."
Étape 8 : Commit régulier
À chaque fonctionnalité qui marche, un commit. Si tu laisses Claude s'en charger, il le fera avec un message propre du genre :
git commit -m "feat: ajout connexion OAuth YouTube"Comme ça, si Claude casse quelque chose dans l'étape suivante, tu peux revenir en arrière. Ton travail à toi, c'est de jeter un oeil à l'historique de temps en temps : un commit qui embarque trente fichiers d'un coup est le signe qu'on a avancé trop loin sans regarder.
Étape 9 : Le résultat en local
Après quelques heures (ou sessions), tu as ton lead magnet qui tourne.
npm run devMais attention. Ce que tu vois là, c'est la version dev. Sur ta machine. Avec tes variables d'environnement.
Déployer en prod, c'est une autre histoire. Les URLs changent, les tokens expirent, les CORS bloquent, les cookies se comportent différemment. J'y ai consacré un article entier, avec la checklist des six points à vérifier avant chaque mise en ligne, parce que c'est là que j'ai perdu le plus de soirées.
Ce qu'on a appris
- Planifier avant de coder : le mode plan de Claude Code existe pour une raison
- Scope minimal : coupe tout ce qui n'est pas essentiel pour la V1
- Git dès le début : Claude s'en charge, ton rôle est de vérifier ce qui part dans le dépôt
- Challenger Claude : il propose, tu valides (ou tu refuses)
- Tester au fur et à mesure : à la main d'abord, et en déléguant à Claude ce qui se répète
- Local ≠ Prod : ce qui marche ici ne marchera pas forcément là-bas
La suite
Dans l'article suivant, on déploie ce projet. Et crois-moi, c'est là que les vrais problèmes commencent.
Tu veux aller plus vite ?
Dans mon accompagnement, je te donne mes rules + mon template GitHub. Claude connaît déjà ta stack, t'as même pas besoin de lui dire quoi utiliser. Tu te concentres sur ton produit, pas sur la config.
Besoin d’un coup de main pour cette partie technique ?
Je sais que parfois, même bien expliqué, un workflow reste intimidant.
Si tu préfères qu’on le mette en place ensemble, contacte-moi : je suis freelance en automatisation, et je peux t’aider à passer de “je devrais le faire” à “c’est déjà en place”.
Sinon, continue de piocher dans les ressources du site, elles sont faites pour ça ✌️
Commentaires