Concepts

Claude Code et Pulse : qui fait quoi

Claude Code est l'assistant de programmation d'Anthropic : vous lui parlez en français, il lit et écrit les fichiers de votre projet. Pulse est une méthode qui s'ajoute à Claude Code. Elle lui donne des commandes qui commencent par /pulse:, un ordre de travail, des modèles de documents et des protections.

Claude Code écrit le code ; Pulse veille à ce qu'il écrive le bon code, dans le bon ordre, en vous demandant votre avis aux moments qui comptent. Vous décidez, Pulse organise, Claude Code exécute.

Exemple : vous tapez /pulse:init carnet-reservations. Pulse prépare le dossier du Salon Lila, puis vous indique la prochaine étape conseillée.

• Où l'utiliser : la façon conseillée est VS Code avec l'extension Claude Code. Le terminal et Claude Desktop fonctionnent aussi (voir les prérequis).
• Dans votre projet : CLAUDE.md, les règles du projet que Claude Code lit à chaque session.
• Commande : /pulse:init pour démarrer, /pulse:status pour savoir où vous en êtes.

De l'idée au code : le chemin

Pulse avance du plus général au plus précis. Chaque document s'appuie sur le précédent : l'IA ne devine jamais ce que vous voulez, elle le lit. Vous validez chaque document avant de passer au suivant.

Le brief

Le brief raconte votre idée avec des mots simples, comme une histoire : qui a besoin de quoi, et pourquoi. On y note aussi les personnes concernées, ce qui coince aujourd'hui et les questions encore ouvertes. C'est le point de départ de tout le reste.

Exemple : « Le Salon Lila a besoin d'un carnet de réservations en ligne pour que ses clientes réservent sans téléphoner. Aujourd'hui, la coiffeuse répond au téléphone entre deux coupes et oublie parfois de noter un rendez-vous. »

• Dans votre projet : docs/brief.md, et les mots de votre métier dans aidd_docs/memory/glossary.md.
• Commande : /pulse:brainstorm, un entretien où Pulse vous pose des questions.

Le PRD et la première version

Le PRD est le document de besoin produit. Il fixe la vision, les utilisateurs, des objectifs mesurables, et surtout ce que contiendra la première version : la plus petite appli réellement utilisable par de vrais utilisateurs. Sur Internet, on l'appelle souvent MVP.

Chaque fonctionnalité est rangée dans l'une des quatre catégories :

Le PRD se termine par une phrase vérifiable : « La première version est prête quand une cliente réserve un créneau libre et que la coiffeuse le voit dans son carnet du jour. »

• Dans votre projet : docs/prd.md.
• Commande : /pulse:prd.

La user story et ses groupes

Une user story décrit un besoin du point de vue de la personne qui utilisera l'appli. Elle suit toujours la même phrase : « En tant que… je souhaite… afin de… ». Chacune porte un numéro : US-001, US-002…

Ses critères d'acceptation disent comment vérifier qu'elle est bien réalisée. Ils s'écrivent en trois temps : Étant donné la situation de départ, lorsque la personne fait quelque chose, alors voici ce qu'elle voit. Il y en a 2 à 4, dont au moins un cas d'erreur ou un cas limite.

Exemple : US-001 « En tant que cliente, je souhaite choisir un créneau libre afin de réserver ma coupe sans téléphoner. » Un critère : « Étant donné le créneau de mardi 14 h déjà pris, lorsque Inès le choisit, alors on lui propose les créneaux voisins. »

Les user stories sont rangées en groupes, un par grand besoin : « Gérer les rendez-vous », « Prévenir les clientes ». Sur GitHub ou ailleurs, un groupe s'appelle parfois epic.

• Dans votre projet : la liste complète dans docs/user-stories.md, et une fiche par user story dans aidd_docs/tasks/<groupe>/US-001-<nom>.md.
• Commande : /pulse:us.

La spec

La spec décrit précisément ce qu'une user story doit permettre : les écrans, les informations, les règles, et ce qui se passe exemple par exemple. Elle dit ce que vous voulez obtenir, sans parler de la façon de le construire. Une user story a une seule spec.

Une fois validée, la spec est verrouillée : elle ne bouge plus. Un changement de besoin devient une nouvelle user story.

Exemple : pour US-001, la spec liste deux écrans (les créneaux libres de la semaine, la confirmation), une règle (« un créneau se réserve une seule fois ») et une phrase de fin : « terminé quand une cliente réserve un créneau libre et le voit confirmé ».

• Dans votre projet : aidd_docs/tasks/<groupe>/SPEC-US-001-<nom>.md.
• Commande : /pulse:spec.

Le plan et ses tâches

Le plan décide comment construire ce que la spec demande. Puis il découpe le travail en petites tâches numérotées : T1, T2, T3… Chaque tâche livre une seule chose que vous pouvez voir et tester en quelques minutes. Les numéros se suivent dans tout le projet.

Le plan sert aussi de tableau de suivi : [ ] à faire, [~] en cours, [x] terminé.

Avant de vous le montrer, Pulse le fait vérifier par un outil : chaque critère de la user story doit avoir sa tâche, chaque test prévu par la spec sa place, et les tâches doivent s'enchaîner sans boucle. Le plan reste « à valider » jusqu'à votre accord.

Exemple : le plan d'US-001 contient « T1 – Afficher la page des créneaux, encore vide », « T2 – Réserver un créneau et le voir confirmé », « T3 – Refuser un créneau déjà pris ».

• Dans votre projet : aidd_docs/tasks/<groupe>/PLAN-SPEC-US-001-<nom>.md, et le carnet de route avec les commandes à copier dans docs/guide/.
• Commande : /pulse:plan.

La réalisation, tâche par tâche

Chaque tâche passe par quatre temps, toujours dans le même ordre : réaliser (l'IA écrit le code), relire (des assistants qui ne l'ont pas écrit l'examinent et l'essaient), tester (vous vérifiez vous-même, avec les étapes que Pulse vous donne), enregistrer (la tâche devient une version de votre projet). Ensuite seulement, on passe à la tâche suivante.

Avancer par petites tâches a deux avantages : l'IA se trompe moins, et vous gardez le contrôle. Si une tâche pose problème, on revient sur elle seule.

En rythme rapide (celui de /pulse:nouveau), les tâches s'enchaînent sans relecture une à une : toute la user story est relue et essayée en une seule fois, à la fin, puis vous la testez avec une seule fiche. Pour aller plus loin, /pulse:spirc version prépare avec vous les specs et les plans de toute la première version, puis les réalise à la suite : vous revenez pour les questions mises de côté et les tests.

Exemple : T2 est réalisée ; la relecture signale qu'on peut réserver une date passée ; Pulse corrige ; vous réservez mardi 14 h dans votre navigateur et voyez la confirmation ; la tâche est enregistrée.

• Dans votre projet : le code lui-même, la case de la tâche cochée dans le plan, et un rapport de relecture par tâche (en rythme rapide, un seul pour toute la user story) dans aidd_docs/tasks/<groupe>/revues/.
• Commandes : /pulse:implement (réaliser), /pulse:review (relire), /pulse:commit (enregistrer), ou tout d'un coup avec /pulse:spirc.

Laisser Pulse travailler seul

Une réalisation peut durer plusieurs heures. En mode autonome (-a), en rythme rapide (celui où Pulse enchaîne toute la user story avant de vous la faire tester ; l'autre, le rythme complet, vous fait tester chaque tâche) ou pour plusieurs user stories à la suite, Pulse enchaîne les tâches sans vous attendre. Au lancement, il vous le dit : vous pouvez faire autre chose et revenir pour décider et tester.

• Les questions en attente. Une question sur votre besoin, une priorité, le périmètre, la sécurité ou un coût, ou une action à faire à la main, n'arrête que la tâche concernée et celles qui en dépendent. Pulse la note dans le plan (section « Questions en attente »), met la tâche « en pause : votre décision » et continue avec les autres. Quand plus rien ne peut avancer, ou à la fin, il vous pose toutes les questions ensemble, puis reprend les tâches en pause avec vos réponses. Le travail déjà commencé sur la tâche est mis de côté avec Git (rangé à part, sans rien perdre), puis remis en place.
• Les choix faits par Pulse. Un petit choix qui se défait facilement (un nom, l'ordre de deux boutons, le texte d'un message) est tranché par Pulse, qui l'écrit en une ligne dans le plan (section « Choix faits par Pulse »). Au test groupé (votre test de toute la user story, une fois les tâches faites), la liste vient en premier : pour chaque choix, vous le gardez ou vous le changez. Dans le doute, Pulse pose la question.
• Où on en est. /pulse:status dit à tout moment où en est la réalisation et combien de questions vous attendent. Après une pause, un redémarrage ou un résumé automatique de la conversation, Pulse relit l'état dans le plan et non dans son souvenir.
• Des vérifications sans vous. Quand un assistant rend la main, Pulse contrôle les fichiers qu'il vient d'écrire : règles du projet, clés secrètes, contrôles automatiques rapides. Seul ce qu'il a écrit compte : une erreur déjà présente ailleurs, ou une modification que vous avez faite vous-même, ne le bloque pas. Si quelque chose ne va pas, l'assistant corrige avant de continuer, deux fois au plus ; après, Pulse vous dit franchement ce qui reste à corriger. En rythme complet, toute la suite de tests sans navigateur (ceux qui n'ouvrent pas votre site dans une fenêtre, donc rapides) tourne aussi avant l'enregistrement de chaque tâche. Les tests qui ouvrent votre site dans un navigateur, plus longs, tournent une fois, quand la user story est finie.
• Des captures comme preuves. Pour chaque critère visible, la vérification garde une capture d'écran (avant et après une correction), sur votre ordinateur seulement et jamais dans Git. Elles sont effacées quand la user story est terminée et envoyée.
• Une notification. Pendant une réalisation, Pulse peut afficher une notification du bureau quand il vous attend : des questions, un test à faire, un accord à donner (voir l'encadré ci-dessous).
• La limite d'utilisation. Quand votre abonnement atteint sa limite, Claude Code peut reprendre tout seul à la remise à zéro. Avant de partir en autonome, Pulse vérifie que cette reprise automatique est active (réglage « Continuer automatiquement à la limite d'utilisation ») et vous explique comment l'activer sinon (voir l'encadré ci-dessous).

• Dans votre projet : les sections « Questions en attente » et « Choix faits par Pulse » du plan, les captures dans aidd_docs/captures/ (ignorées par Git), et un petit fichier de suivi de la réalisation, aidd_docs/tasks/realisation.json, effacé à la fin.
• Commandes : /pulse:spirc avec -a, -f ou plusieurs user stories, /pulse:status pour suivre.

La version enregistrée et l'historique

Une version enregistrée est une photo datée de votre projet, avec une légende. Toutes ces photos, mises bout à bout, forment l'historique. Vous pouvez toujours revenir à une photo précédente sans rien perdre. C'est le logiciel Git qui garde cet historique ; une version enregistrée s'appelle un commit.

Pulse fait une version par sujet : une tâche du plan, une mise à jour de la mémoire, une correction. Avant chaque enregistrement, il vérifie qu'aucune clé secrète ne part avec.

Exemple : « feat(T2): permet de réserver un créneau libre ». Le lendemain, si T3 a cassé quelque chose, vous revenez à la version de T2.

• Dans votre projet : le dossier caché .git, géré par Git. Vous n'avez pas à l'ouvrir.
• Commandes : /pulse:commit pour enregistrer, /pulse:annuler pour revenir en arrière.

Le dépôt en ligne

Le dépôt en ligne est une copie de votre projet sur un site comme GitHub. Il sert de sauvegarde, et c'est de là que part la mise en ligne de votre appli. Chaque envoi y recopie vos nouvelles versions ; en anglais, on dit push.

Pulse le crée toujours privé : vous seul y avez accès. Chaque envoi passe par votre accord.

Exemple : le projet du Salon Lila est rangé sur GitHub sous le nom carnet-reservations. Si votre ordinateur tombe en panne, rien n'est perdu.

• Dans votre projet : l'adresse du dépôt, notée dans la section « Adresses » de CLAUDE.md.
• Commandes : /pulse:init le propose après le premier enregistrement ; /pulse:deploy le crée s'il manque encore.

La version parallèle et le dossier à part

Une version parallèle est une copie du projet où l'on avance sans toucher à la version principale, celle que le site publie. Git l'appelle une branche. Quand le travail est prêt, une proposition sur le site du dépôt demande de rassembler la version parallèle dans la version principale ; sur GitHub, elle s'appelle pull request. Vous la relisez, puis vous l'acceptez.

Le dossier à part va plus loin : c'est un deuxième dossier du projet, sur sa propre version parallèle. Deux sessions de Claude Code peuvent ainsi avancer en même temps, chacune sur sa user story, sans se gêner. Son nom anglais : worktree.

Exemple : pendant qu'une session réalise US-001, une deuxième session avance sur US-003 (le rappel par e-mail) dans un dossier à part. Chaque user story est rassemblée dans la version principale une fois terminée. Dans une série (/pulse:spirc version), Pulse peut aussi, avec votre accord, faire avancer lui-même deux user stories indépendantes en même temps, chacune dans son dossier à part.

• Dans votre projet : les dossiers à part sont rangés dans .claude/worktrees/.
• Commandes : /pulse:pr pour la version parallèle et sa proposition ; /pulse:implement et /pulse:spirc proposent le dossier à part quand une autre session travaille déjà sur le projet.

Les contrôles automatiques

Les contrôles automatiques sont un contrôle qualité qui tourne tout seul sur le site de votre dépôt. À chaque envoi, il vérifie que les clés restent hors du code, que les tests passent et que l'appli se construit. Une coche verte dit que tout va bien ; une croix rouge vous prévient avant que l'erreur n'arrive sur le site. Sur GitHub, on parle de CI.

Les tests automatiques en font partie : de petits programmes qui vérifient que l'appli fait ce que la spec demande. À chaque changement, ils préviennent si quelque chose casse.

Les règles du projet peuvent en faire partie aussi : une habitude notée dans la mémoire (« les montants s'écrivent en centimes ») peut porter un contrôle ; un enregistrement qui ne la respecte pas est alors refusé, avec la règle citée.

Exemple : une modification casse la réservation d'un créneau. Le test « un créneau se réserve une seule fois » échoue, la croix rouge apparaît, et le problème est corrigé avant la mise en ligne.

• Dans votre projet : scripts/verifier.js et le fichier des contrôles, par exemple dans .github/workflows/.
• Commandes : /pulse:cicd pour les contrôles, /pulse:test pour les tests.

La mise en ligne et l'hébergeur

Mettre en ligne, c'est rendre votre appli accessible à tous, à une adresse web. L'hébergeur est le service qui la fait tourner sur ses ordinateurs, jour et nuit (par exemple Vercel). Une fois relié à votre dépôt en ligne, il met le site à jour tout seul à chaque envoi sur la version principale, en quelques minutes.

Avant chaque envoi, Pulse vérifie que tout est enregistré et que les tests passent. Après la publication, il prouve que le site répond vraiment.

Exemple : à la fin d'US-002, la première version est complète. Le carnet du Salon Lila est publié, et la coiffeuse partage l'adresse avec ses clientes.

• Dans votre projet : l'hébergeur choisi et la façon de revenir en arrière dans docs/technical.md ; l'adresse du site dans CLAUDE.md.
• Commandes : /pulse:tech choisit l'hébergeur, /pulse:deploy met en ligne.

Les clés secrètes et le fichier .env

Une clé secrète (clé d'accès à un service, mot de passe, adresse de base de données) permet d'agir à votre place. Elle se range dans un fichier à part, nommé .env, qui reste sur votre ordinateur : il n'est jamais enregistré dans l'historique ni envoyé sur le dépôt. Votre hébergeur reçoit sa propre copie des clés.

Vous collez vous-même chaque valeur dans .env, depuis votre éditeur. L'IA travaille avec les noms des clés, jamais avec leurs valeurs, et Pulse l'empêche de lire ce fichier. Si une clé apparaît dans la conversation, on la change.

Exemple : pour envoyer le rappel la veille, l'appli a besoin du mot de passe du service d'e-mails. Il va dans .env sous un nom comme SMTP_PASSWORD ; le modèle .env.example garde le nom, sans la valeur.

• Dans votre projet : .env (vos valeurs, gardé secret), .env.example (les noms seulement), docs/secrets.md (la liste des clés et leurs dates, jamais leurs valeurs).
• Commande : /pulse:secrets.

La mémoire du projet

D'une conversation à l'autre, l'IA oublie tout. La mémoire du projet lui rappelle, à chaque nouvelle session, vos choix, les mots de votre métier et les pièges déjà rencontrés. Ce sont quelques fichiers courts, écrits en français, rangés dans votre projet et enregistrés avec lui.

Au démarrage de chaque session, Claude Code relit CLAUDE.md, où Pulse a recopié la mémoire. Pulse vous montre chaque ajout avant de l'écrire.

Exemple : la mémoire note que le salon dit « prestation » et jamais « service », et que les rendez-vous durent 30 minutes. La semaine suivante, Claude Code s'en souvient sans que vous le répétiez.

• Dans votre projet : aidd_docs/memory/ (project.md pour la vision et les choix, technical.md pour les outils, glossary.md pour les mots du métier), recopiée dans CLAUDE.md.
• Commande : /pulse:memory.

Les garde-fous

Les garde-fous sont des protections que Pulse ajoute à Claude Code. Avant chaque action, ils regardent ce que l'IA s'apprête à faire. Une action dangereuse est refusée ; une action qui jette du travail ou touche au site en ligne attend votre accord. Dans les deux cas, Pulse vous dit pourquoi et propose une autre façon de faire.

Ils restent actifs même si vous avez désactivé les demandes d'autorisation de Claude Code.

Exemple : pour vérifier la clé du service d'e-mails, l'IA voudrait ouvrir .env. Le garde-fou refuse et rappelle l'autre chemin : pulse-aidd secrets verifier contrôle la clé sans jamais afficher sa valeur.

• Dans votre projet : rien à installer, les garde-fous viennent avec Pulse. /pulse:init ajoute une seconde protection dans .claude/settings.json et un contrôle des clés avant chaque enregistrement.
• Dans vos autres projets : les garde-fous restent silencieux. Ils reconnaissent un projet Pulse à son fichier CLAUDE.md, créé par /pulse:init.
• Commande : aucune ; ils veillent pendant toutes les commandes.

Les assistants, des relecteurs indépendants

Pour certaines étapes, Pulse confie le travail à des assistants spécialisés : des IA séparées, chacune avec un seul rôle et ses propres consignes. L'un réalise la tâche, un autre relit le code, un autre lance l'appli et essaie chaque critère, un autre écrit les tests.

Ceux qui relisent n'ont pas écrit le code : comme un regard extérieur, ils repèrent les oublis que l'auteur ne voit plus. Votre propre test vient ensuite confirmer.

Exemple : après T2, un assistant relit le code et signale qu'une date passée est acceptée ; un autre ouvre l'appli et réserve mardi 14 h pour vérifier la confirmation.

Chaque assistant lit seulement ce qui sert à sa tâche. Celui qui écrit le code reçoit les règles qui concernent ses fichiers, et toujours celles de la sécurité dès qu'il touche au serveur ou aux données. Celui qui relit reçoit leurs listes de contrôle. Moins de lecture, c'est moins de calcul pour le même résultat : sur une user story mesurée, la réalisation complète a coûté de 15 à 25 % de moins et pris un quart de temps en moins, avec les mêmes tâches faites et les mêmes tests réussis. Votre abonnement atteint aussi moins vite sa limite d'utilisation.

• Dans votre projet : leurs rapports de relecture, dans aidd_docs/tasks/<groupe>/revues/.
• Commandes : /pulse:review, /pulse:spirc, /pulse:security.

Le pack Next.js et ses recettes

Pulse ne dépend d'aucun outil en particulier. Un pack ajoute le savoir-faire d'un ensemble d'outils précis. Le pack Next.js (pulse-next) sert à construire une appli web avec des comptes et des données, hébergée chez Vercel, avec une base de données chez Neon. Il apporte un projet de départ déjà vérifié et des conseils pour écrire un code juste du premier coup.

Ses recettes sont des fonctions courantes prêtes à l'emploi, vérifiées chaque semaine : la connexion, une liste filtrée, l'envoi d'e-mails, le paiement, le référencement… Les specs et les plans s'appuient dessus.

Exemple : pour US-002, la coiffeuse doit se connecter pour voir son carnet du jour. Le plan suit la recette connexion ; le rappel la veille suivra la recette email.

• Dans votre projet : la ligne « Pack de pile Pulse : next » dans docs/technical.md.
• Commande : /pulse:tech le propose quand il convient à votre projet. Le tutoriel « prêt pour de vrais clients » l'utilise de bout en bout.