Applications web avec Claude Code ou Codex : de l'architecture au déploiement sécurisé

Objectifs pratiques

À la fin de cette leçon (20 minutes), vous aurez un fichier PRD.md d'une page pour votre application de commerce local. Ce fichier est la première brique vers votre objectif : une application web payante, sécurisée et déployée. Sans lui, Claude Code ou Codex produit une application générique. Il consomme aussi des tokens à corriger ce qui n'était pas demandé.

Pourquoi c'est utile pour votre objectif

Un PRD (Product Requirements Document) est un cahier des charges court. Il répond à trois questions : pour qui, pour quel problème, et quoi construire en premier. Pour un projet business, il évite de construire 20 fonctionnalités que personne ne paie. Pour l'IA, c'est un contexte stable que vous pourrez réutiliser dans CLAUDE.md (leçon suivante). Un prompt précis demande moins d'allers-retours, donc moins de tokens dépensés.

Méthode pas à pas

1. Choisissez 1 utilisateur cible précis. Évitez « les commerçants ». Écrivez par exemple : « Gérante d'une boutique de vêtements de quartier, 1 à 3 employés, vend via WhatsApp, utilise le Mobile Money. »
2. Décrivez 1 problème, en une phrase mesurable. Exemple : « Elle perd des commandes parce que les messages WhatsApp se mélangent et qu'elle n'a pas de catalogue à jour. »
3. Listez 5 fonctionnalités maximum. Pensez en actions de l'utilisateur : voir le catalogue, passer commande, payer, gérer les produits, suivre les commandes.
4. Classez chacune en MoSCoW.

• Must : sans elle, le produit ne sert à rien.
• Should : importante, mais le lancement reste possible sans elle.
• Could : agréable, à faire si le temps le permet.
• Gardez 2 à 3 Must au maximum. Votre MVP (version minimale à lancer) = les Must.

1. Écrivez 3 non-objectifs. Ce sont les choses que vous refusez explicitement de faire dans cette version. Exemple : application mobile native, multi-boutiques, système de livraison.
2. Relisez avec le test de l'IA. Collez le PRD dans Claude Code ou Codex et demandez : « Résume ce PRD en 5 lignes et liste les ambiguïtés. » Corrigez ce qui est flou.

Exemple concret

```

Utilisateur : gérante de boutique de quartier, vend via WhatsApp. Problème : commandes perdues, pas de catalogue à jour.

Fonctionnalités :

1. Catalogue public de produits (Must)
2. Commande avec nom et téléphone (Must)
3. Paiement Mobile Money ou carte en mode test (Must)
4. Espace admin pour ajouter des produits (Should)
5. Notification WhatsApp de nouvelle commande (Could)

Non-objectifs :

• Pas d'application mobile native
• Pas de multi-boutiques
• Pas de gestion de livraison

```

Ce PRD tient en 15 lignes. L'IA ne construira ni marketplace, ni système de livraison. Chaque Must correspond à un module futur du parcours.

Erreurs à éviter

• Utilisateur trop large (« tout le monde ») : l'IA fait un produit générique.
• Tout classer en Must : vous perdez la notion de MVP.
• Oublier les non-objectifs : l'IA ajoute des fonctionnalités de sa propre initiative, ce qui coûte des tokens et de la dette technique.
• Écrire un PRD de 10 pages : un document long consomme du contexte à chaque session. Une page suffit.
• Coder avant de relire : aucune ligne de code tant que le PRD n'est pas validé.

À faire maintenant

Créez un fichier PRD.md avec les rubriques : Utilisateur cible, Problème, Fonctionnalités MoSCoW (5), Non-objectifs (3). Faites-le résumer par l'IA, corrigez les ambiguïtés, puis notez dans votre journal : date, durée, et une phrase sur ce que vous avez décidé de ne PAS faire.

Pourquoi cet exercice vous rapproche de votre objectif

Avant d'écrire la moindre ligne de code avec Claude Code ou Codex, il faut savoir qui paiera, combien et pourquoi. Les objectifs de ce parcours sont de formuler une idée rentable, de définir un MVP et d'intégrer un paiement. Pour cela, vous avez besoin d'une preuve que quelqu'un est prêt à payer. Cet exercice transforme une intuition en une fiche d'une page. Elle guidera le cahier des charges (PRD.md) et évitera de gaspiller des tokens à générer des fonctionnalités que personne n'achètera. Chaque prompt inutile coûte du contexte et de l'argent. Un MVP bien choisi en consomme beaucoup moins.

Durée estimée : 3 sessions de 20 minutes (60 minutes au total).

Contexte

Le fil rouge du parcours est une application web pour un commerce local : catalogue, commande par WhatsApp, et paiement par abonnement ou achat unique. Dans de nombreux pays francophones d'Afrique, le Mobile Money est le moyen de paiement dominant. Stripe n'est pas disponible partout. Votre offre doit donc être pensée pour un paiement que vos clients utilisent réellement. Vous pourrez passer par un agrégateur Mobile Money (à vérifier selon votre pays).

Étapes

Session 1 : préparer 3 entretiens (20 min)

1. Choisissez un type de commerçant (boutique de vêtements, restaurant, salon de coiffure, vendeur de produits agricoles, etc.).
2. Rédigez 4 questions ouvertes, sans parler de votre solution :

• Comment recevez-vous vos commandes aujourd'hui ?
• Quel est votre plus gros problème à ce moment-là ?
• Qu'avez-vous déjà essayé pour le résoudre ?
• Combien dépensez-vous déjà chaque mois pour cela (data, outils, commissions) ?

1. Identifiez 3 personnes à interroger. Si vous ne pouvez pas, simulez 3 profils différents et notez clairement « simulé » dans la fiche.

Session 2 : mener les 3 entretiens (20 min)

1. Posez vos questions et notez les réponses mot pour mot.
2. À la fin, proposez une fourchette de prix : « Si un outil réglait ce problème, 2 000, 5 000 ou 10 000 FCFA par mois, lequel serait raisonnable ? » Adaptez les montants à votre marché.
3. Notez aussi la préférence : paiement mensuel, ou achat unique ?

Session 3 : rédiger la fiche et l'ajouter au PRD (20 min)

1. Créez validation-offre.md d'une page avec ces sections : Problème principal, Cible, Offre, Prix, Type d'offre (abonnement ou achat unique) et sa justification, Preuves (les 3 retours), Décision MVP (une fonctionnalité unique à lancer).
2. Ajoutez dans PRD.md une ligne qui référence la fiche, par exemple : « Validation de l'offre : voir validation-offre.md ».
3. Facultatif : demandez à Claude Code ou Codex de relire la fiche et de signaler les incohérences. Utilisez un prompt court et précis pour économiser des tokens.

Exemple concret

Une vendeuse de pagnes dit qu'elle perd des commandes dans les messages WhatsApp. Deux autres commerçants confirment un problème proche. Ils accepteraient 3 000 à 5 000 FCFA par mois. Vous choisissez un abonnement à 4 000 FCFA par mois pour un catalogue en ligne avec bouton de commande WhatsApp.

Erreurs à éviter

• Présenter votre solution avant d'avoir écouté le problème.
• Interroger uniquement des amis qui diront oui par politesse.
• Choisir un prix sans l'appuyer sur un retour.
• Viser 10 fonctionnalités au lieu d'une version minimale.
• Ignorer le moyen de paiement réellement utilisé par la cible.

Livrables et critères de réussite

• 3 retours de cibles sont notés (réels ou simulés, signalés comme tels).
• Un prix et un type d'offre sont choisis et justifiés.
• La fiche validation-offre.md est référencée dans PRD.md.
• Notez dans votre journal : date, durée, ce que vous avez appris.

Objectifs pratiques

À la fin de cette leçon de 20 minutes, vous aurez un fichier ARCHITECTURE.md committé dans votre dépôt. Il décrit les 5 composants de votre application et le trajet complet d'une commande client. C'est la première étape concrète vers votre objectif : guider Claude Code ou Codex avec une vraie structure, au lieu de lui demander « fais-moi une appli » et de brûler des tokens en corrections.

Pourquoi c'est utile pour votre objectif

Une IA qui code sans plan invente son architecture à chaque session. Résultat : des fichiers mal placés, du code dupliqué, des allers-retours coûteux en tokens. Un fichier d'architecture de 40 lignes, relu en début de session, remplace des dizaines de messages d'explication. Il vous permet aussi de justifier chaque choix technique et de vérifier que le code généré respecte le plan. C'est la base du cahier des charges, du back-end, du paiement et du déploiement des prochaines leçons.

Les 5 composants en une phrase chacun

• Front-end : ce que l'utilisateur voit et touche dans son navigateur (pages, formulaires, boutons).
• Back-end : le programme sur un serveur qui applique les règles (qui a le droit, quel prix, quel stock) et ne fait confiance à personne.
• Base de données : la mémoire durable (utilisateurs, produits, commandes).
• API : le contrat de communication entre front-end et back-end, par exemple POST /api/orders. Elle définit ce qu'on envoie et ce qu'on reçoit.
• Hébergement : l'endroit où tout tourne en ligne, accessible 24h/24 via une adresse web.

Méthode pas à pas

1. Rappelez votre fil rouge. Écrivez en une ligne votre application. Exemple : un catalogue pour un commerce local avec commande et paiement.
2. Créez le fichier ARCHITECTURE.md à la racine du dépôt.
3. Nommez les 5 composants et, pour chacun, écrivez : son rôle, la technologie envisagée (ou « à décider »), et pourquoi ce choix en une phrase.
4. Dessinez le schéma texte avec des flèches ASCII : Navigateur (front-end) → API → Back-end → Base de données, plus l'hébergement qui contient le tout.
5. Décrivez le trajet d'une commande en au moins 5 étapes numérotées, de l'action du client jusqu'à l'affichage de la confirmation.
6. Faites relire par l'IA avec un prompt court : « Relis ARCHITECTURE.md. Liste les incohérences ou étapes manquantes, sans modifier le fichier. » Corrigez vous-même.
7. Committez : git add ARCHITECTURE.md puis git commit -m "docs: architecture initiale".

Exemple concret

Voici un extrait pour une boutique locale :

`` Navigateur (front-end) | POST /api/orders {produit, quantité} v API (contrat) --> Back-end (valide, calcule le prix) | v Base de données (table orders) Hébergement : tout est servi depuis une URL publique ``

Trajet d'une commande :

1. Le client clique sur « Commander » dans le front-end.
2. Le front-end envoie POST /api/orders avec le produit et la quantité.
3. Le back-end vérifie que l'utilisateur est connecté et que les données sont valides.
4. Le back-end recalcule le prix depuis la base de données (jamais depuis le navigateur).
5. Le back-end enregistre la commande avec le statut « en attente de paiement ».
6. L'API renvoie l'identifiant de la commande.
7. Le front-end affiche la confirmation.

Erreurs à éviter

• Écrire « base de données » sans dire ce qu'elle stocke. Listez au moins 3 types de données.
• Mettre la logique de prix dans le front-end. Un utilisateur peut la modifier ; le back-end doit toujours recalculer.
• Confondre API et back-end. L'API est l'interface, le back-end est le code qui travaille derrière.
• Laisser l'IA remplir le fichier sans relecture. Vous devez pouvoir expliquer chaque ligne.
• Choisir 10 technologies. Une seule stack simple suffit pour un débutant.

À faire maintenant

Produisez ARCHITECTURE.md avec : les 5 composants et leur rôle, le schéma texte, le trajet d'une commande en 5 étapes minimum, puis committez-le. Notez dans votre journal la preuve : le hash du commit.

Objectifs pratiques

Dans cette leçon, vous allez rédiger 5 fiches de décision d'architecture (front-end, back-end, base de données, authentification, paiement). Chaque fiche contient : l'option retenue, 2 alternatives, la raison du choix et le moment où changer. Ces fiches sont la dernière étape avant le fichier mémoire de l'IA et avant la première ligne de code. Elles vous rapprochent de votre objectif : concevoir une architecture que vous savez justifier devant un client ou un associé, et donner à Claude Code ou Codex des consignes précises qui consomment moins de tokens.

Pourquoi c'est utile pour votre objectif

Un débutant qui demande à l'IA « choisis la meilleure techno » obtient une réponse différente à chaque session. Résultat : le code change de direction, les fichiers se multiplient et les tokens partent dans des corrections. Une fiche de décision fige le choix une fois pour toutes. Vous la collez ensuite dans le fichier mémoire du projet (CLAUDE.md), et l'IA n'a plus à réfléchir à la stack. C'est aussi un argument business : vous montrez que chaque choix répond à un besoin, un budget et un pays.

Méthode pas à pas

1. Créez un modèle de fiche. Cinq lignes : Décision / Option retenue / Alternatives (2) / Pourquoi (1 à 2 phrases) / Quand changer (un critère mesurable).
2. Partez de votre cahier des charges MVP. Notez les 3 fonctionnalités prioritaires. Chaque choix doit servir l'une d'elles.
3. Retenez une stack unique pour débutant. Suggestion de la recherche : Next.js + Tailwind pour le front, PostgreSQL via Supabase pour les données. Une seule stack évite la surcharge d'outils.
4. Rédigez les fiches front, back et base. Pour chacune, nommez 2 alternatives réelles et expliquez pourquoi vous ne les prenez pas maintenant.
5. Rédigez la fiche authentification. Choisissez une solution existante plutôt que d'écrire vous-même la gestion des mots de passe. Citez 2 alternatives.
6. Rédigez la fiche paiement selon votre pays. Vérifiez d'abord si Stripe est disponible pour votre pays. Sinon, envisagez un agrégateur Mobile Money (CinetPay, PayDunya, FedaPay, KKiaPay : à vérifier avant de choisir). Pour apprendre le schéma (initier, rediriger, webhook, vérifier côté serveur, livrer), Stripe en mode test peut servir de terrain d'entraînement.
7. Écrivez un critère de changement chiffré. Exemple : « Je change de base si je dépasse 500 Mo de données » ou « si plus de 50 % de mes clients ne peuvent pas payer ».
8. Faites relire par l'IA, sans qu'elle réécrive. Demandez-lui : « Trouve les incohérences entre ces 5 fiches. Ne propose pas de code. » Cela coûte peu de tokens.

Exemple concret

Projet : application de commande pour un commerce local, avec paiement Mobile Money.

Fiche paiement

• Option retenue : agrégateur Mobile Money local.
• Alternatives : Stripe (limité selon les pays), paiement à la livraison confirmé par WhatsApp.
• Pourquoi : les clients paient surtout par Mobile Money.
• Quand changer : si plus de 30 % des clients sont à l'international, ajouter Stripe.

Fiche base de données

• Option retenue : PostgreSQL via Supabase.
• Alternatives : SQLite (simple mais limité en ligne), Firebase (modèle de données différent).
• Pourquoi : données relationnelles (clients, commandes, produits) et authentification intégrée.
• Quand changer : si les coûts ou les limites du plan gratuit bloquent le lancement.

Erreurs à éviter

• Écrire « c'est le plus populaire » comme seule raison.
• Citer des alternatives bidon pour remplir la fiche.
• Oublier le critère de changement : sans lui, la fiche n'est qu'une opinion.
• Choisir le paiement sans vérifier la disponibilité dans votre pays.
• Demander à l'IA de décider à votre place sans lui donner votre cahier des charges.
• Multiplier les outils : une seule stack principale suffit au MVP.

À faire maintenant

Livrable : un document de 5 fiches, collé dans votre fichier mémoire du projet. Prenez 20 minutes : 2 minutes pour relire votre cahier des charges, 12 minutes pour rédiger, 4 minutes pour faire vérifier les incohérences par l'IA, 2 minutes pour noter dans votre journal le temps passé et les tokens utilisés.

Objectifs pratiques

À la fin de cette leçon de 20 minutes, vous aurez installé Claude Code ou Codex, lancé une première session dans un dossier de projet vide et activé le mode permission avec validation. Vous saurez aussi expliquer ce que l'agent peut lire, modifier et exécuter. C'est la première brique de votre objectif : construire, sécuriser et déployer une application web payante avec l'IA, sans perdre le contrôle ni gaspiller de tokens.

Pourquoi c'est utile pour votre objectif

Un chatbot vous répond avec du texte, et c'est vous qui copiez le code. Un agent, lui, agit directement sur votre machine : il lit vos fichiers, les modifie et lance des commandes. Cette puissance est ce qui vous fera avancer vite. Mais elle impose des réflexes de sécurité dès le départ : ne jamais donner à l'agent un accès libre à vos secrets, et valider chaque action sensible. Comprendre la différence vous évite aussi de gaspiller des tokens : un agent qui explore tout un dossier consomme beaucoup plus de contexte qu'un simple échange de chat.

Les trois idées à retenir

• La boucle agentique : l'agent réfléchit, agit (lit un fichier, écrit du code, lance une commande), observe le résultat, puis recommence jusqu'à finir ou à bloquer.
• Les permissions : l'outil demande votre accord avant de modifier un fichier ou d'exécuter une commande. C'est votre filet de sécurité.
• Agent vs chatbot : le chatbot produit du texte dans une fenêtre. L'agent agit dans votre dossier de projet et peut vérifier son propre travail, par exemple en lançant un test.

Méthode pas à pas

1. Choisissez un outil. Claude Code ou Codex. Consultez la documentation officielle de l'outil choisi pour connaître l'abonnement requis et les prérequis, car les offres changent. Choisissez-en un seul pour tout le parcours.
2. Installez-le en suivant la procédure officielle pour votre système (Windows, macOS ou Linux). Vérifiez l'installation en lançant la commande de version dans le terminal.
3. Créez un dossier vide, par exemple mon-app-test, et ouvrez le terminal à l'intérieur de ce dossier. L'agent ne doit travailler que dans ce dossier.
4. Lancez l'outil dans ce dossier et connectez votre compte quand il le demande.
5. Activez le mode avec validation. Gardez le mode par défaut qui demande confirmation avant d'écrire un fichier ou d'exécuter une commande. N'activez jamais l'approbation automatique totale à ce stade.
6. Posez la même tâche deux fois. D'abord dans un chat classique : « Écris une page HTML d'accueil pour une boutique de pagnes, avec un titre et un bouton WhatsApp. » Ensuite, la même demande à l'agent dans votre dossier.
7. Observez et notez. Pendant que l'agent travaille, regardez ce qu'il propose de lire, de créer ou de lancer, et ce que vous devez valider.
8. Écrivez 3 différences dans votre journal de progression.

Exemple concret

Vous demandez au chatbot la page d'accueil. Il vous donne du code : vous créez le fichier vous-même, l'ouvrez et corrigez vos erreurs. Avec l'agent, il propose de créer index.html : vous voyez la demande, vous acceptez, et le fichier apparaît dans le dossier. Vous pouvez ensuite lui demander de vérifier le rendu ou de corriger une faute. Trois différences possibles : l'agent écrit lui-même les fichiers, il demande des permissions, il peut observer le résultat et se corriger.

Erreurs à éviter

• Lancer l'agent dans un dossier personnel très large (Documents, Bureau) : il pourrait voir des fichiers sensibles.
• Accepter toutes les validations sans lire : prenez 5 secondes pour comprendre chaque commande.
• Désactiver les permissions par confort.
• Garder une longue session pour plusieurs tâches : le contexte se remplit et les tokens se gaspillent. Règle : 1 session = 1 tâche.
• Installer les deux outils en parallèle et s'éparpiller.

À faire maintenant

Livrable : une entrée de journal « Jour 1 » contenant (a) le nom de l'outil choisi, (b) une capture ou une ligne montrant qu'il répond dans le terminal du projet, (c) la confirmation que le mode validation est actif, (d) 3 différences chat/agent en une phrase chacune. Vérifiez chaque critère avant de clôturer la session.

Pourquoi cet exercice\n\nUne IA de code n'a aucune mémoire entre deux sessions. Sans fichier mémoire, vous répétez votre stack et vos règles à chaque fois, ce qui consomme des tokens et produit des dérives (mauvais framework, clé secrète commitée). Un fichier CLAUDE.md (Claude Code) ou AGENTS.md (Codex) court est lu à chaque session : il guide l'IA et réduit les erreurs. Il sert directement vos objectifs : prompts fiables, sécurité dès le départ, économie de tokens et projet cohérent jusqu'au déploiement et au paiement.\n\n

Contexte\n\nVotre fil rouge est une petite application web pour un commerce local : catalogue, commande, abonnement ou paiement. Vous n'avez pas encore besoin de code abouti. Il vous faut un dépôt (même presque vide) et la décision de stack prise dans votre architecture du module 1.\n\n

Durée estimée\n\n20 minutes : 2 min de reprise, 12 min d'action, 4 min de vérification, 2 min de journal.\n\n

Étapes\n\n

1. Préparer le dépôt (3 min)\n\nCréez un dossier de projet et initialisez Git avec git init. Ajoutez un fichier .gitignore contenant au minimum .env, node_modules et les dossiers de build.\n\n

2. Générer un premier modèle (3 min)\n\nLancez Claude Code dans le dossier puis tapez /init. Avec Codex, demandez de créer un AGENTS.md décrivant le projet. Lisez le résultat sans le valider tel quel : il est souvent trop long.\n\n

3. Réduire à 25 lignes maximum (6 min)\n\nGardez uniquement ce que l'IA ne peut pas deviner :\n\n- Projet : 1 à 2 lignes (but, utilisateurs cibles).\n- Stack : front-end, back-end, base de données, paiement, hébergement.\n- Commandes : dev, build, test (exactes, copiables).\n- Règles « ne jamais » : au moins 3, idéalement 5.\n- Index : une ligne pointant vers les fichiers détaillés, par exemple docs/cahier-des-charges.md et docs/architecture.md, au lieu de tout recopier.\n\n

4. Vérifier (4 min)\n\nComptez les lignes avec wc -l CLAUDE.md. Ouvrez une nouvelle session et demandez : « Résume les règles du projet et donne la commande de test. » Si la réponse est exacte, le fichier fonctionne.\n\n

5. Journal (2 min)\n\nNotez la date, le nombre de lignes, ce que vous avez supprimé et pourquoi, puis faites un commit : git commit -m \"docs: add project memory file\".\n\n

Exemple de règles « ne jamais »\n\n- Ne jamais committer de clé, mot de passe ou fichier .env.\n- Ne jamais installer une dépendance sans me demander et la justifier.\n- Ne jamais valider un paiement côté navigateur : uniquement côté serveur, via webhook.\n- Ne jamais modifier plus de fichiers que la tâche demandée.\n- Ne jamais dire « terminé » sans avoir lancé les tests.\n\n

Erreurs à éviter\n\n- Garder le fichier généré de 100 lignes : il gaspille des tokens à chaque session.\n- Écrire des généralités (« code propre ») au lieu de commandes précises.\n- Oublier les commandes de test : l'IA ne peut alors pas vérifier son travail.\n- Y placer de vraies clés secrètes.\n\n

Livrable et critères de réussite\n\nLe fichier CLAUDE.md ou AGENTS.md est à la racine du dépôt, commité. Il respecte ces critères :\n\n- 25 lignes ou moins.\n- Les commandes build, test et dev sont présentes.\n- Au moins 3 règles « ne jamais » figurent dans le fichier.\n- Un test dans une nouvelle session confirme que l'IA applique les règles.\n\n

Pour aller plus loin\n\nChaque fois que l'IA fait une erreur répétée, ajoutez une règle en une ligne, et supprimez une ligne obsolète pour rester sous 25 lignes.

Objectifs pratiques

À la fin de cette leçon, vous saurez écrire un prompt en 5 blocs (contexte, objectif, contraintes, vérification, format), décider quand passer en plan mode et exiger une preuve que le code fonctionne. C'est la compétence qui vous permet de générer du code fiable avec Claude Code ou Codex, et de ne pas gaspiller de tokens en corrections successives.

Pourquoi c'est utile pour votre objectif

Votre but est de livrer une application web complète, sécurisée et payante, avec une routine de 20 minutes par jour. Un prompt vague produit du code approximatif, puis des allers-retours coûteux en tokens. Un prompt précis, terminé par une commande de vérification, donne un résultat contrôlable en une seule session. Le principe du parcours : un code n'est pas « fini » tant qu'il n'est pas « vérifié ».

Les 5 blocs du prompt

1. Contexte : le projet, la stack, l'état actuel. Exemple : « Application de commande pour un commerce local, Next.js, dossier vide. »
2. Objectif : une seule tâche, mesurable. Exemple : « Créer la structure de dossiers et une page d'accueil. »
3. Contraintes : ce qu'il ne faut pas faire. Exemple : « Aucune dépendance en plus, aucun secret dans le code, ne touche pas à d'autres fichiers. »
4. Vérification : la commande à lancer et le résultat à montrer. Exemple : « Lance npm run build puis colle la sortie. »
5. Format : la forme de la réponse. Exemple : « Liste des fichiers créés, puis un résumé en 3 lignes. »

Méthode pas à pas : plan mode

1. Posez-vous la question : « Puis-je décrire le diff en une phrase ? » Si oui, demandez directement le code, sans plan. Si non, utilisez le plan mode.
2. Activez le plan mode (dans Claude Code, Shift+Tab pour changer de mode). L'IA explore et propose un plan sans modifier de fichier.
3. Relisez le plan : fichiers touchés, ordre des étapes, éléments hors périmètre. Corrigez-le en une phrase si nécessaire.
4. Validez, laissez l'IA coder, puis exigez la vérification (build, test, capture).
5. Faites un commit si la preuve est bonne. Utilisez /clear avant la tâche suivante : 1 session = 1 tâche = 1 commit.

Exemple concret

Prompt faible : « Crée-moi une app de commande. » Le résultat est imprévisible et la correction coûte cher.

Prompt en 5 blocs :

« Contexte : app web de commande pour une boutique locale, Next.js, dépôt vide. Objectif : créer la structure initiale (pages, composants, dossier lib) et une page d'accueil. Contraintes : pas de nouvelle bibliothèque, un fichier .env.example sans vraie clé, .env dans .gitignore. Vérification : lance npm run build et montre la sortie finale. Format : arborescence, puis 3 lignes de résumé. »

Ce prompt est assez large pour justifier le plan mode : vous relisez le plan avant toute écriture de fichier.

Erreurs à éviter

• Mélanger plusieurs tâches dans un seul prompt.
• Oublier le bloc vérification : l'IA dit « c'est fait » sans preuve.
• Utiliser le plan mode pour un changement d'une ligne, ce qui consomme des tokens pour rien.
• Valider un plan sans le lire.
• Laisser traîner une longue conversation : le contexte se remplit et la qualité baisse. Faites /clear entre les tâches.

À faire maintenant

Écrivez 3 prompts en 5 blocs pour créer la structure initiale de votre projet, par exemple : 1) l'arborescence et le .gitignore, 2) la page d'accueil, 3) la configuration des variables d'environnement. Chacun se termine par une commande de vérification et le résultat à montrer. Exécutez-en un en plan mode et relisez le plan. Notez-les dans votre prompt-book.

Objectifs pratiques

Dans cette leçon, vous allez apprendre 6 réflexes pour consommer moins de tokens avec Claude Code ou Codex. Vous tiendrez aussi un journal de consommation. C'est utile pour votre objectif : construire une application web complète avec un budget maîtrisé, en 20 minutes par jour. Vous aurez un livrable à la fin : un journal de 3 lignes et la liste écrite de vos 6 réflexes.

Pourquoi c'est utile pour votre objectif

Un assistant de code relit une grande partie de la conversation à chaque échange. Plus la session s'allonge, plus le contexte se remplit. La documentation officielle de Claude Code indique que la performance baisse quand la fenêtre de contexte se remplit. Une session trop longue vous coûte donc deux fois : plus de tokens consommés et des réponses moins fiables. Pour un projet business (front-end, back-end, paiement, sécurité), ces économies s'accumulent sur des dizaines de sessions.

Les concepts à maîtriser

• Fenêtre de contexte : la mémoire de travail de l'IA. Elle contient vos messages, ses réponses, les fichiers lus et les sorties de commandes.
• /clear : efface la conversation pour repartir d'un contexte vide.
• /context : affiche la part de la fenêtre déjà utilisée (à vérifier dans votre version de l'outil).
• Modèle par défaut ou avancé : prenez le modèle standard (par exemple Sonnet) pour la plupart des tâches. Gardez le modèle avancé (par exemple Opus) pour les cas difficiles, comme une architecture ou un bug complexe. Vérifiez les noms de modèles dans votre outil.
• 1 session = 1 tâche = 1 commit : vous terminez une tâche précise, vous la vérifiez, vous l'enregistrez avec git, puis vous repartez à zéro.

Méthode pas à pas : les 6 réflexes

1. Une tâche par session. Exemple : « Créer la page de connexion » seule, sans y ajouter le paiement.
2. /clear entre deux tâches. Après un commit, tapez /clear avant de commencer la suite.
3. Surveillez /context. Consultez-le au début, au milieu et quand les réponses deviennent floues.
4. Choisissez le bon modèle. Utilisez le modèle standard par défaut. Passez au modèle avancé seulement après un échec répété.
5. Écrivez un prompt précis. Indiquez le fichier, le résultat attendu et la vérification. Exemple : « Dans login.html, ajoute la validation de l'email. Lance le test et montre-moi le résultat. »
6. Gardez un fichier mémoire court. Un CLAUDE.md de 15 à 30 lignes (stack, commandes, règles) évite de réexpliquer le projet à chaque session.

Pour le journal, notez après chaque session : la date, la tâche, le modèle, le pourcentage de contexte utilisé selon /context, et le résultat (vérifié ou non).

Exemple concret

Tâche : ajouter un formulaire de contact à une page de commerce local.

• Session A, sans /clear : vous enchaînez la tâche après 40 minutes de discussion sur d'autres sujets. /context montre un taux élevé, par exemple 70 %. L'IA oublie une consigne.
• Session B, avec /clear : vous videz le contexte, vous donnez un prompt précis, et /context affiche un taux bas, par exemple 15 %. Le résultat est correct dès le premier essai.

Ces chiffres sont des illustrations : relevez les vôtres.

Erreurs à éviter

• Garder une seule session ouverte toute la journée.
• Utiliser le modèle le plus puissant pour des tâches simples.
• Écrire des prompts vagues comme « améliore mon site », qui provoquent des allers-retours coûteux.
• Mettre dans le fichier mémoire un texte trop long qui remplit le contexte dès le départ.
• Ne jamais consulter /context et ne rien mesurer.

À faire maintenant

1. Choisissez une petite tâche (par exemple un bouton ou un formulaire).
2. Réalisez-la dans une session longue sans /clear et notez le contexte.
3. Faites /clear, refaites une tâche équivalente avec un prompt précis, puis notez le contexte.
4. Consultez /context au moins une fois.
5. Rédigez votre journal de 3 lignes et vos 6 réflexes, chacun avec un exemple.

Pourquoi cet exercice est essentiel

Avant d'écrire la moindre ligne de code avec Claude Code ou Codex, vous devez pouvoir tracer chaque changement et protéger vos clés secrètes. Une clé de paiement ou de base de données envoyée par erreur sur un dépôt public peut être utilisée par n'importe qui en quelques minutes. Avec Git, chaque tâche confiée à l'IA devient un commit que vous pouvez relire ou annuler. C'est aussi un moyen d'économiser des tokens : si l'IA se trompe, vous revenez au dernier commit sain au lieu de tout régénérer. Cet exercice pose la règle « 1 tâche = 1 commit » et la sécurité dès le jour 1. Il prépare directement les objectifs de sécurisation, de déploiement et de livraison d'un projet publiable.

Durée estimée

20 minutes : 2 min de reprise, 12 min d'action, 4 min de vérification, 2 min de journal.

Contexte

Vous avez déjà (ou allez créer) dans le dossier de votre projet : un cahier des charges MVP (PRD.md), un document d'architecture (ARCHITECTURE.md) et un fichier mémoire (CLAUDE.md, ou AGENTS.md pour Codex). Si l'un manque, écrivez-en une version courte de 5 à 10 lignes avant de continuer.

Étapes

Étape 1 : initialiser Git

Dans un terminal, placez-vous dans le dossier du projet, puis lancez git init. Configurez votre identité Git avec git config user.name et git config user.email. Utilisez un pseudonyme professionnel plutôt que des données personnelles sensibles.

Étape 2 : créer le .gitignore AVANT tout commit

Créez un fichier .gitignore contenant au minimum :

`` .env .env.* !.env.example node_modules/ . DS_Store ``

L'ordre compte : si un fichier secret est commité une fois, il reste dans l'historique même après suppression.

Étape 3 : créer .env et .env.example

Créez .env pour vos vraies valeurs locales (il restera privé). Créez ensuite .env.example avec les mêmes noms de variables, mais sans aucune valeur réelle, par exemple DATABASE_URL=, JWT_SECRET=, PAYMENT_SECRET_KEY= et PAYMENT_WEBHOOK_SECRET=. Ce fichier documente ce dont l'application a besoin sans rien révéler.

Étape 4 : faire 3 commits atomiques

Un commit atomique contient un seul changement logique. Faites-les un par un avec git add ciblé, jamais git add . à l'aveugle :

1. git add PRD.md .gitignore .env.example puis git commit -m "docs: ajoute le cahier des charges MVP"
2. git add ARCHITECTURE.md puis git commit -m "docs: ajoute l'architecture"
3. git add CLAUDE.md (ou AGENTS.md) puis git commit -m "docs: ajoute le fichier mémoire de l'IA"

Étape 5 : vérifier

Lancez git log --oneline (3 commits attendus), git ls-files (.env ne doit pas apparaître) et git check-ignore -v .env (doit confirmer que le fichier est ignoré). Vérifiez aussi git status : l'arbre doit être propre.

Exemple concret

Un projet de commande pour un commerce local contient PRD.md, ARCHITECTURE.md, CLAUDE.md, .gitignore, .env.example et un .env ignoré. Résultat de git log --oneline : trois lignes, chacune commençant par docs:.

Erreurs à éviter

• Faire git add . avant d'avoir créé le .gitignore.
• Mettre de vraies valeurs dans .env.example.
• Un seul gros commit « premier commit » qui mélange tout.
• Si un secret a été commité : considérez-le comme compromis, régénérez-le chez le fournisseur, puis nettoyez l'historique.
• Demander à l'IA de lire .env : ne lui collez jamais vos vraies clés dans un prompt.

Livrables attendus

• Un dépôt Git local avec 3 commits atomiques.
• Un .gitignore qui exclut .env.
• Un .env.example sans valeur réelle.
• Une capture ou copie des sorties de git log --oneline et git ls-files.
• Une ligne dans votre journal de progression : date, durée, difficulté rencontrée.

Critères de réussite

• Aucun fichier .env n'est suivi par Git.
• 3 commits atomiques apparaissent dans l'historique.
• Un .env.example sans valeurs réelles existe.

Action immédiate

Ouvrez votre terminal maintenant et exécutez l'étape 1. Si vous bloquez, demandez à Claude Code ou Codex d'expliquer chaque commande avant de l'exécuter, en un prompt court pour limiter les tokens.