La méthode : cadrer, découper, exiger des preuves

Le piège : tout demander d’un coup

« Fais-moi une plateforme de formations avec paiement. » Claude va produire quelque chose. Ça aura l’air fini. Et tu n’auras aucun moyen de savoir ce qui marche vraiment.

La documentation officielle de Claude Code le dit sans détour : Claude s’arrête quand le travail a l’air terminé. S’il n’a aucune vérification à lancer, c’est toi qui deviens la vérification. Chaque erreur attend que tu la remarques.

Ma méthode tient en trois gestes, qui tournent en boucle.

1. Cadrer : écrire ce que Claude relit à chaque session

Claude Code lit un fichier CLAUDE.md au début de chaque session. C’est la mémoire du projet. J’y mets ce qui ne doit jamais se renégocier (bien l’écrire est tout le sujet de la formation CLAUDE.md : ne plus jamais tout réexpliquer).

Voici trois règles réelles du CLAUDE.md de ce site (extrait raccourci) :

- **Une seule règle d'accès** : `src/lib/acces.ts` (`deciderAcces`). Jamais de condition d'accès
  écrite ailleurs.
- **Les prix viennent de Stripe** (clés de recherche `linedev_formation_mensuel` / `_annuel`),
  jamais d'un chiffre écrit dans le site.
- **Un accès ne s'ouvre que sur une information relue chez Stripe** (webhook signé, ou session
  relue au retour de paiement). Chaque paiement est traité une fois (`evenements-stripe`).

Regarde leur forme. Chacune se vérifie : on peut chercher dans le code une condition d’accès écrite ailleurs, ou un prix tapé en dur. C’est ce que recommande la documentation : des instructions assez concrètes pour être vérifiées. « Écris du code propre » ne se vérifie pas.

2. Découper : une étape, un résultat vérifiable

Au lieu d’une demande géante, une suite d’étapes. Chacune s’appuie sur la précédente et se vérifie seule. Pour ce site, le découpage ressemble à ceci :

1. Le modèle de données : les collections en base.
2. La connexion par code e-mail.
3. La règle d’accès, avec ses tests.
4. Le paiement Stripe et le webhook (l’appel que Stripe envoie au site quand un paiement aboutit).
5. Les e-mails, l’espace élève, les pages légales.
6. Le parcours complet, joué dans un navigateur.
7. Le script de mise en ligne.

Pour les étapes qui touchent plusieurs fichiers, Claude Code a un mode plan. Appuie sur Shift+Tab jusqu’à voir « plan mode on » dans la barre d’état : Claude lit le code et propose un plan, sans modifier ton code tant que tu ne l’as pas approuvé. Pour une seule demande, tu peux aussi la commencer par /plan. Tu relis, tu corriges, puis tu le laisses coder.

3. Prouver : pas de « c’est fait » sans preuve

Pour ce projet, trois preuves comptent. Leurs commandes sont écrites dans le CLAUDE.md (commentaires raccourcis ici) :

pnpm exec tsc --noEmit   # types
pnpm test:int            # tests unitaires
pnpm test:e2e            # parcours complet dans un navigateur invisible

tsc est le vérificateur de TypeScript : il signale chaque type faux sans rien produire (--noEmit). Le dernier test confie le parcours à Playwright, un outil qui pilote un vrai navigateur.

La documentation de Claude Code insiste sur ce point : demande à Claude de montrer la preuve plutôt que d’affirmer que ça marche. La sortie des tests, la commande lancée et son résultat. Relire une preuve est plus rapide que refaire la vérification toi-même.

En fin de journée, voici ce que disait la section « État » du CLAUDE.md :

Vérifié : tsc propre, tests unitaires, parcours de bout en bout Playwright vert.

Et dans la même section, une ligne « Connu » qui dit ce qui ne marche pas encore. Une preuve honnête dit aussi ce qui reste à faire.

La mémoire du projet : l’état tenu à jour

Ce CLAUDE.md finit par une section « État », datée. Elle dit ce qui est fait, ce qui dépend de moi (compléter les pages légales, créer les clés Stripe de test) et ce qui est connu mais pas réglé.

La session suivante repart de là, sans que j’aie à tout réexpliquer. Et quand plusieurs sessions travaillent sur le même projet, elles lisent toutes le même état.

Ce que la suite t’apporte

Tu as la vue d’ensemble. La suite de la formation entre dans chaque geste, sur le vrai code.

• Le cahier des charges avec Claude : ce que je lui donne (un parcours, des contraintes), ce qu’il me rend (trois documents), et comment le faire t’interroger pour trouver les trous.
• Le choix de la pile : pourquoi Payload, Next.js et SQLite ici, comment démarrer d’un modèle officiel, et le piège des versions récentes que Claude connaît mal.
• La règle d’accès unique : une fonction pure, ses tests, et comment, dans la décision d’accès, la suppression de l’essai gratuit s’est réduite à une ligne.
• Le paiement Stripe : webhook signé, paiement traité une seule fois, session relue chez Stripe.
• Le vrai navigateur : le test qui joue l’élève de bout en bout, en lisant le vrai code reçu par e-mail.
• La mise en ligne : le script qui sauvegarde, migre, démarre et contrôle, puis ce que je surveille.

Chaque leçon payante se termine par une section « À toi » : les demandes et les commandes prêtes à copier dans ton projet.