Workflows concrets avec Claude Code

Ta fonctionnalité est finie, les tests passent, le diff est propre - et pourtant tu restes une heure à relire ton propre code avant d'oser ouvrir la Pull Request. Ensuite tu écris la documentation à la main. Puis les tests. Puis le message de commit. C'est exactement là que le vent tourne : l'essentiel du travail d'un développeur n'est pas d'écrire du code neuf, mais de relire, documenter, tester et migrer du code qui existe déjà. Ce sont des corvées de quart de nuit - répétitives, indispensables, et parfaitement automatisables. Dans cette leçon je te confie sept manoeuvres que j'utilise vraiment à bord, de la plus simple à la plus musclée, et chacune tient en une commande ou en un petit script. Deux précisions avant de larguer les amarres. D'abord, toutes les commandes ci-dessous fonctionnent avec le Claude Code d'aujourd'hui, pas avec celui des vieux tutoriels. Ensuite, je garde les consignes en anglais dans les exemples, parce que c'est ce que tu croiseras dans la plupart des scripts partagés en ligne - Claude comprend le français tout aussi bien, alors choisis la langue que tu préfères.

Manoeuvre 1 : la revue de code

Commençons par la corvée la plus fréquente : faire relire un fichier. Deux briques à connaître avant de taper quoi que ce soit. La première est le drapeau -p, pour print : il lance Claude Code, lui pose une seule question, affiche la réponse dans le terminal et rend la main. Pas de session, pas de dialogue - une commande, une réponse. La seconde est le caractère @ : à l'intérieur de ta consigne, @chemin/vers/fichier dit à Claude d'aller lire ce fichier lui-même. Tu ne colles jamais le contenu à la main, tu donnes seulement l'adresse, comme un point sur une carte marine. Et rien ne t'empêche d'en citer plusieurs dans la même phrase.

1# Revue d'un seul fichier
2claude -p "Review @src/auth.ts for bugs and security issues"
3
4# Comparaison de deux versions
5claude -p "Compare @src/old-api.ts and @src/new-api.ts and suggest improvements"

Ce qui vient de se passer : Claude a ouvert les fichiers cités, les a lus en entier, et t'a renvoyé une analyse en texte brut dans le terminal. Ce qui n'a pas changé, et c'est le point important : tes fichiers. Le mode -p lit et répond, mais par défaut, il n'enregistre rien de lui-même : dans ce mode, personne ne peut approuver une modification de fichier, donc Claude Code refuse les écritures tant que tu ne les autorises pas par un drapeau - je te le montrerai quand on arrivera à la documentation. Tu peux donc lancer ces commandes sur n'importe quel dépôt sans le moindre risque, même au beau milieu d'un travail non commité. Retiens aussi que la sortie est du texte ordinaire : elle peut être gardée dans un fichier avec une redirection >, ou envoyée à une autre commande.

Le tuyau : donner à Claude ce que Git voit

Un fichier entier, c'est souvent trop. Ce que tu veux relire avant un commit, ce n'est pas tout auth.ts, ce sont les douze lignes que tu viens de toucher. Git sait déjà les extraire, et le terminal sait faire circuler l'information d'une commande vers une autre : c'est le tuyau, la barre verticale |. Elle prend ce que la commande de gauche affiche et le verse directement dans l'entrée de la commande de droite. Claude Code accepte ce flux : tout ce qui arrive par le tuyau vient s'ajouter à ta consigne. Quant à git diff, elle affiche les modifications qui ne sont pas encore enregistrées. Ensemble, les deux donnent la relecture la plus utile de ta journée.

1# Relire les changements avant le commit
2git diff | claude -p "Review these changes before commit"
3
4# Le diff, avec une consigne plus simple
5git diff | claude -p "Summarize these changes"

L'ordre des trois morceaux n'est pas décoratif : la source d'abord, le tuyau ensuite, Claude en dernier. Écrit dans l'autre sens, l'enchaînement ne veut plus rien dire, puisque Claude n'aurait rien à lire au moment où il démarre. Note aussi ce qui n'existe pas ici : aucun drapeau --diff, aucune option magique du côté de Claude. Le tuyau est un mécanisme du terminal, pas une fonctionnalité de Claude Code, et c'est justement ce qui le rend si puissant : il marche avec n'importe quelle commande capable d'écrire du texte. Ma recommandation de capitaine : pour tout ce qui sort de Git, prends toujours le tuyau, et garde @ pour les fichiers que tu désignes toi-même.

Le même tuyau se branche sur d'autres sorties de Git, et c'est là qu'il devient un vrai outil de quart. git show HEAD affiche le dernier commit enregistré, message et modifications comprises : parfait pour l'autopsie d'un commit qui vient de casser la compilation. git diff main...HEAD compare ta branche entière à main, c'est-à-dire tout ce que ta Pull Request va proposer, et pas seulement ton dernier pas. Les trois points comptent : ils demandent à Git de partir du moment où ta branche a quitté main, pour ne pas te noyer sous les commits arrivés sur main pendant que tu naviguais ailleurs.

1# Analyser le dernier commit
2git show HEAD | claude -p "Analyze this commit and find bugs"
3
4# Comparer toute la branche avec main
5git diff main...HEAD | claude -p "Find potential bugs in this diff"

Dans les deux cas la structure est identique - source Git, tuyau, claude -p avec la question - et seule la source change. C'est le même geste appliqué à un périmètre différent : un commit, puis une branche complète. Rien n'est écrit sur le disque, rien n'est poussé, rien n'est commité : tu obtiens un avis, pas une action. Et comme la sortie reste du texte, tu peux la conserver pour plus tard avec une redirection, par exemple > revue.md, puis la relire tranquillement pendant que la compilation tourne. C'est ma routine du matin sur un projet que je ne connais pas encore : un diff de branche, une question, un fichier de notes.

Relire une Pull Request entière

Le diff te donne les lignes, mais une Pull Request, c'est aussi un titre, une description, des commentaires et un historique. Pour l'attaquer dans son ensemble, il faut passer en session interactive : tu tapes claude sans rien d'autre, et tu obtiens une conversation qui reste ouverte. Dans cette session, les commandes qui commencent par une barre oblique ne sont pas des messages adressés à Claude, ce sont des ordres directs adressés à l'outil. Celle qui nous intéresse ici s'appelle /code-review (/review en version courte, c'est le même ordre). Sans argument, elle passe en revue les commits de ta branche et les changements non commités ; avec le numéro d'une Pull Request, elle va chercher elle-même son contenu, au lieu d'attendre que tu le colles dans la conversation :

1/code-review 42

Une seule ligne, et pourtant c'est la commande que j'utilise le plus souvent avant de valider le travail d'un équipier. Retiens bien la distinction, parce qu'on la confond vite : claude -p se tape dans le terminal, tandis que /code-review se tape à l'intérieur d'une session déjà ouverte. Ce sont deux mondes différents, et une commande de session ne fonctionnera jamais directement dans ton shell. Là aussi, rien n'est modifié : /code-review produit des remarques (sauf si tu ajoutes --fix, qui applique tout de suite les correctifs), et c'est toi qui décides ensuite d'approuver, de demander des corrections ou de refermer la PR.

Manoeuvre 2 : la documentation

Personne n'aime écrire un README, et c'est bien pour ça que la plupart mentent au bout de trois mois. Deuxième manoeuvre, donc : laisser Claude lire le code et rédiger la documentation à partir de ce qui existe vraiment. Ici, une propriété change tout par rapport aux exemples précédents. Claude Code sait non seulement lire tes fichiers, mais aussi en écrire. Tu n'as donc besoin ni d'une option de sortie particulière, ni d'une redirection : il te suffit d'indiquer, dans ta phrase, où le résultat doit atterrir. Remarque au passage que j'ai laissé tomber le -p : sans lui, la session reste ouverte et tu peux enchaîner les corrections à chaud.

1# Un README construit sur le code du projet
2claude "Read the code in src/ and write a professional README.md
3  with a project description, install steps and usage examples"
4
5# La doc d'une API, sur la base d'un seul fichier
6claude "Generate API documentation in Markdown from @src/api.ts
7  and save it to docs/API.md"

La différence entre ces deux commandes est instructive. La première ne cite aucun fichier : Claude explore le dossier src/ tout seul, décide lesquels comptent et en tire une description. La seconde vise @src/api.ts et impose la destination. Dans les deux cas, tu vois passer chaque changement dans la conversation : en mode manuel (Manual), Claude Code te demande ton accord avant de créer ou de modifier un fichier, et en mode auto, celui dans lequel les versions récentes démarrent une session dans le terminal, les modifications de fichiers dans le projet sont acceptées sans demander, et le classificateur ne contrôle que les actions plus risquées. Ce qui n'a pas bougé, en revanche : ton code source. Générer de la documentation ne réécrit pas les fonctions documentées, et c'est exactement ce que l'on veut - la carte se met à jour, la côte reste où elle est.

Tant que tu documentes un fichier, la commande suffit. Le jour où tu voudras régénérer toute la documentation du projet avant une livraison, tu ne vas pas retaper trois consignes de mémoire : tu les enfermes dans un script. Un script bash, c'est un simple fichier texte qui contient des commandes exécutées de haut en bas. Sa première ligne, #!/bin/bash, indique au système quel interpréteur employer ; les lignes qui commencent par un dièse sont des commentaires, ignorés à l'exécution ; et echo affiche un message pour que tu saches où en est le navire. Appelons celui-ci generate-docs.sh. Sous Windows, lance ce genre de script dans Git Bash ou dans WSL, car PowerShell ne comprend pas la syntaxe de bash.

1#!/bin/bash
2# generate-docs.sh
3
4echo "Documentation en cours..."
5
6# La doc de l'API
7claude -p "Read src/api/ and generate complete API documentation:
8  endpoints, request and response types, usage examples, error codes.
9  Save the result to docs/API.md" --permission-mode acceptEdits
10
11# La doc des composants
12claude -p "Read src/components/ and document every component:
13  purpose, props interface, code example.
14  Save the result to docs/COMPONENTS.md" --permission-mode acceptEdits
15
16# Le README du projet
17claude -p "Read the whole src/ folder and write README.md:
18  description, install steps, quick start, project structure.
19  Keep it readable for beginners" --permission-mode acceptEdits
20
21echo "C'est fait."

Trois consignes, trois fichiers de documentation, un seul lancement avec bash generate-docs.sh. Remarque que le -p est revenu : dans un script, personne n'est là pour répondre à des questions, donc on veut le mode non interactif qui traite la demande et rend la main. La nouveauté, c'est le drapeau --permission-mode acceptEdits : en mode -p, personne ne peut cliquer pour autoriser une écriture, donc sans lui, par défaut, Claude lirait le code mais ne créerait aucun fichier. Le mode acceptEdits l'autorise à créer et à modifier des fichiers sans demander, alors ne lance ce script que dans un dépôt où toutes les modifications sont déjà commitées. L'autre solution consiste à demander seulement le contenu et à le rediriger vers le fichier : claude -p "..." > docs/API.md. Ce qui n'a pas changé par rapport à la version manuelle, c'est la formulation des consignes elles-mêmes. Un script n'est pas une nouvelle syntaxe à apprendre, c'est la mémoire de tes bonnes commandes. Si le fichier refuse de démarrer, c'est presque toujours qu'il n'est pas exécutable, et chmod +x generate-docs.sh règle l'affaire une fois pour toutes.

Manoeuvre 3 : les tests

Du code sans test, c'est un navire sans cloison étanche : tout va bien jusqu'à la première voie d'eau. Troisième manoeuvre : faire écrire les tests. Jest est le lanceur de tests le plus répandu de l'écosystème JavaScript. React Testing Library est la bibliothèque qui permet de tester un composant React comme le ferait un utilisateur, en cherchant du texte à l'écran plutôt qu'en fouillant l'intérieur du composant. Dans ta consigne, dis toujours trois choses : quel fichier tester, ce que tu veux couvrir - en particulier les cas limites et la gestion des erreurs - et où enregistrer le résultat.

1# Tests pour un module utilitaire
2claude "Write Jest tests for @src/utils.ts, cover edge cases
3  and error handling, and save them to src/utils.test.ts"
4
5# Tests pour un composant React
6claude "Write React Testing Library tests for @src/components/Button.tsx
7  and save them to src/components/Button.test.tsx"

Tu obtiens un fichier de test complet, écrit dans la convention du projet : mêmes imports, mêmes noms de blocs, même style. Une mise en garde de capitaine, tout de même. Un test généré ne prouve rien tant que tu ne l'as pas exécuté. Lance-le, vérifie qu'il passe, puis casse volontairement la fonction testée pour voir si le test tombe. Un test qui reste vert quoi qu'il arrive est pire qu'une absence de test, parce qu'il donne confiance sans rien garantir. Ce qui n'a pas changé ici : src/utils.ts n'est pas touché, seul le fichier de test vient au monde.

Un fichier à la fois, c'est bien pour démarrer ; sur un projet en mer depuis deux ans, il te faut un filet dérivant. Voici les quatre outils qu'emploie le script suivant. find src -name "*.ts" parcourt le dossier et remonte tous les fichiers TypeScript, tandis que ! -name "*.test.ts" écarte ceux qui sont déjà des tests. La boucle for ... do ... done répète le même traitement pour chaque fichier trouvé, en le rangeant à chaque tour dans la variable FILE. L'expression ${FILE%.ts} coupe la fin du nom, le suffixe .ts, pour que je puisse recoller .test.ts à la place. Enfin [ -f "$TEST_FILE" ] demande si ce fichier existe déjà, et continue saute au tour suivant sans rien faire.

1#!/bin/bash
2# generate-tests.sh
3
4# Tous les fichiers TypeScript du projet, sauf les tests
5for FILE in $(find src -name "*.ts" ! -name "*.test.ts"); do
6
7  # Le nom du fichier de test attendu
8  TEST_FILE="${FILE%.ts}.test.ts"
9
10  # On saute les fichiers qui ont un test
11  if [ -f "$TEST_FILE" ]; then
12    continue
13  fi
14
15  echo "Test manquant pour : $FILE"
16
17  claude -p "Write complete Jest tests for @$FILE.
18    Cover every exported function, edge cases and error handling.
19    Follow the Arrange-Act-Assert pattern.
20    Return only the test code, without Markdown fences." > "$TEST_FILE"
21done

Déroulé du script : pour chaque fichier de src/, il calcule le nom du test correspondant, vérifie s'il existe, et n'appelle Claude que dans le cas contraire. La réponse de Claude arrive dans le fichier par la redirection > "$TEST_FILE", car en mode -p, par défaut, Claude n'enregistre pas lui-même le fichier. Le second détail à retenir est ce @$FILE glissé dans la consigne : le terminal remplace la variable par le chemin réel avant même que Claude ne voie la phrase, si bien que la référence @ pointe sur le bon fichier à chaque tour de boucle. Ce qui ne change pas : les tests que tu as écrits à la main. Le script les détecte et passe son chemin, donc tu peux le relancer autant de fois que tu veux sans écraser ton travail - une propriété précieuse dès qu'un script s'adresse à une intelligence artificielle.

Manoeuvre 4 : migrations et refactoring

Quatrième manoeuvre, celle qui fait gagner des semaines : la migration. Convertir un fichier JavaScript en TypeScript, moderniser un vieux composant React, remplacer une bibliothèque abandonnée - ce sont des transformations mécaniques mais interminables, exactement le genre de travail où l'attention humaine s'effondre au dixième fichier. La recette tient en deux ingrédients : le fichier visé, avec @, et une consigne qui dit ce qui doit changer et surtout ce qui doit rester identique. Cette seconde partie est la plus importante, car sans elle une conversion a vite fait de simplifier un comportement au passage.

1# JavaScript vers TypeScript
2claude "Convert @src/legacy.js to TypeScript: add types and interfaces,
3  keep the behaviour exactly the same"
4
5# Un vieux composant vers du React moderne
6claude "Refactor @src/old-component.jsx into a modern React function
7  component with hooks"

Pour un fichier isolé, cette commande suffit et tu vois le résultat immédiatement. Pour une migration qui touche trente fichiers, change de tactique et demande d'abord un plan. Claude Code possède un mode planification dans lequel il analyse le terrain, propose une marche à suivre et attend ton feu vert avant de modifier quoi que ce soit - tu le découvriras en détail dans le prochain exercice. Ma recommandation de capitaine : au-delà de trois fichiers, passe systématiquement par le plan. Relire une stratégie de dix lignes coûte une minute, relire trente fichiers réécrits d'un seul coup te coûte une soirée entière.

Manoeuvre 5 : Claude à l'intérieur de tes scripts

Cinquième manoeuvre, et ma préférée : les messages de commit. Tu connais le résultat d'une soirée pressée - fix, fix2, vraiment fix. Comme claude -p renvoie du texte brut, ce texte peut être capturé dans une variable et réutilisé par le reste du script. Quatre éléments de bash à connaître avant de lire ce qui suit. La construction $(commande) exécute la commande et se remplace par sa sortie, ce qui permet de ranger un résultat dans une variable. git diff --cached montre uniquement ce que tu as ajouté à la zone de staging avec git add. Le test [ -z "$DIFF" ] demande si la variable est vide, et exit 1 interrompt le script sur un code d'erreur. Enfin read -p pose une question et range la réponse dans REPLY, que l'on compare ensuite avec [[ $REPLY =~ ^[Yy]$ ]], autrement dit : la réponse commence-t-elle par y ou par Y.

1#!/bin/bash
2# smart-commit.sh
3
4# Ce qui attend dans le staging
5DIFF=$(git diff --cached)
6
7if [ -z "$DIFF" ]; then
8  echo "Rien dans le staging. Lance d'abord : git add <fichiers>"
9  exit 1
10fi
11
12# Le diff part dans le tuyau, le message revient
13MESSAGE=$(echo "$DIFF" | claude -p "Write a commit message in
14  Conventional Commits format (type: description).
15  Return ONLY the message, nothing else.")
16
17echo "Message pour ce commit :"
18echo "$MESSAGE"
19echo
20
21read -p "On garde ce message ? (y/n) " -n 1 -r
22echo
23
24if [[ $REPLY =~ ^[Yy]$ ]]; then
25  git commit -m "$MESSAGE"
26  echo "Commit fait."
27else
28  echo "Abandon."
29fi

Suis le fil, il se lit comme une manoeuvre en quatre temps. Le diff du staging entre dans la variable DIFF ; si elle est vide, le script s'arrête proprement avec un message utile plutôt que d'appeler Claude pour rien ; sinon le diff traverse le tuyau jusqu'à claude -p, et la réponse est capturée dans MESSAGE ; enfin le script te montre la proposition, attend ton accord, et ne commite que si tu réponds y. Ce qui n'a pas changé, et ne devrait jamais changer : rien n'est commité dans ton dos. La confirmation humaine reste au milieu de la chaîne, et je te conseille de garder cette règle dans tous tes scripts - l'automatisation propose, le marin décide.

Température, effort et modèle : ce que tu règles, ce que tu ne règles pas

Un mot sur quelques réglages dont tu as sûrement entendu parler, parce que beaucoup de vieux tutoriels racontent n'importe quoi à leur sujet. La température est un paramètre d'échantillonnage des modèles de langage : basse, elle donne des réponses plus reproductibles, haute, des réponses plus variées. Dans Claude Code, tu ne peux pas la régler - il n'existe ni drapeau --temperature ni drapeau --max-tokens - et les modèles Claude les plus récents ne l'acceptent même plus via l'API (ils n'admettent que la valeur par défaut, 1.0). Si un tutoriel te fait taper claude --temperature 0.2, il date d'une autre époque. Le vrai bouton de réglage, à côté du modèle, c'est le niveau d'effort : il décide combien de temps le modèle réfléchit à chaque étape. Tu le règles avec le drapeau --effort au démarrage ou avec la commande /effort dans une session, avec les valeurs low, medium, high, xhigh et max. Un effort faible est plus rapide et moins cher sur les tâches simples, un effort élevé donne un raisonnement plus profond sur les tâches difficiles :

1# Question simple : effort faible
2claude --effort low -p "Explain what git rebase does"
3
4# Probleme difficile : effort eleve
5claude --effort high "Find the cause of the memory leak in @src/server.ts"

Le choix du modèle est tout autant entre tes mains, et il change vraiment la donne. Quatre familles cohabitent, de la plus légère à la plus puissante. Haiku est le canot : le plus rapide et le plus économique, taillé pour les questions courtes, comme déchiffrer un message d'erreur ou expliquer une commande. Sonnet est le navire de ligne, l'équilibre entre vitesse et profondeur, bon pour le travail de tous les jours et pour la revue de code. Opus est le vaisseau amiral, solide sur un raisonnement long et modèle par défaut de la plupart des forfaits. Fable est le galion des plus longues expéditions : le plus puissant, mais plus lent et plus cher, pour des migrations et des refontes de projet entier qui durent des heures. Tu sélectionnes le modèle avec le drapeau --model en ligne de commande, ou avec la commande /model à l'intérieur d'une session.

1# Question rapide : Haiku, le plus rapide
2claude --model haiku -p "What does this TypeScript error mean?"
3
4# Revue de code : Sonnet, le bon compromis
5git diff | claude --model sonnet -p "Review these changes"
6
7# Refactoring complexe : Opus
8claude --model opus "Refactor @src/legacy-cart.js and modernise it"

Un réflexe simple pour t'y retrouver : plus la tâche demande de raisonnement, plus tu montes en gamme ; plus elle est brève et répétitive, plus tu redescends. Ma recommandation : pour les tâches simples et répétitives, passe à Sonnet ou à Haiku, et garde Opus et Fable pour les tâches qui demandent vraiment du raisonnement, parce que faire passer tout ton travail par le plus gros modèle coûte plus cher et prend plus de temps sans rien apporter sur les questions simples. Méfie-toi enfin des identifiants de modèles figés que traînent les vieux scripts, du genre claude-3-sonnet-20240229 : ces versions vieillissent et finissent par disparaître, alors que les noms courts haiku, sonnet, opus et fable te donnent toujours le modèle courant de la famille.

Manoeuvre 6 : la revue automatique en CI/CD

Sixième manoeuvre : confier la première relecture à la machine, pour que l'équipage humain n'ouvre la Pull Request qu'une fois les évidences déjà signalées. GitHub Actions est le système d'automatisation de GitHub : tu déposes un fichier YAML dans .github/workflows/, et GitHub exécute ce qu'il contient à chaque événement que tu déclares. La ligne on: pull_request signifie donc à chaque Pull Request ouverte ou mise à jour. Un job est une suite d'étapes qui tournent sur une machine neuve, et chaque step fait une seule chose, soit en réutilisant une action toute faite avec uses, soit en lançant des commandes avec run. La clé d'API ne s'écrit jamais dans le fichier : elle dort dans les secrets du dépôt et n'est injectée qu'au moment voulu par env. Dernier ingrédient, celui qui compte vraiment pour l'automatisation : le drapeau --output-format json demande à Claude Code de répondre dans un format structuré, exploitable par un programme, au lieu du texte destiné à un lecteur humain.

1# .github/workflows/claude-review.yml
2name: Claude Code Review
3
4on:
5  pull_request:
6    branches: [ main ]
7
8jobs:
9  review:
10    runs-on: ubuntu-latest
11    permissions:
12      contents: read
13      pull-requests: write
14    steps:
15      - uses: actions/checkout@v4
16        with:
17          fetch-depth: 0
18
19      - name: Setup Node.js
20        uses: actions/setup-node@v4
21        with:
22          node-version: '22'
23
24      - name: Install Claude Code
25        run: npm install -g @anthropic-ai/claude-code
26
27      - name: Review changed files
28        env:
29          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
30        run: |
31          git diff origin/main...HEAD | \
32            claude -p "Review these changes for bugs and security. Be brief." \
33            --output-format json > review.json
34
35      - name: Post review as a PR comment
36        uses: actions/github-script@v7
37        with:
38          script: |
39            const fs = require('fs');
40            const data = JSON.parse(fs.readFileSync('review.json', 'utf8'));
41            github.rest.issues.createComment({
42              issue_number: context.issue.number,
43              owner: context.repo.owner,
44              repo: context.repo.repo,
45              body: data.result
46            });

Relis l'enchaînement des étapes, il raconte une histoire dont aucun chapitre ne peut changer de place : on récupère le code, on installe Claude Code, on passe en revue les fichiers modifiés, et seulement ensuite on publie le résultat en commentaire de la Pull Request. On ne relit pas un code qu'on n'a pas récupéré, et on ne commente pas une revue qui n'existe pas encore. Deux détails valent le détour. La ligne fetch-depth: 0 réclame l'historique complet du dépôt, sans quoi la comparaison avec main n'aurait rien à se mettre sous la dent. Et review.json n'est pas du texte pour toi : c'est le fichier structuré que l'étape suivante ouvre pour en extraire le champ result avant de le poster. Ce qui n'a pas changé : le robot commente, il ne fusionne rien et ne bloque personne.

Manoeuvre 7 : la session en binôme

Septième et dernière manoeuvre, la plus difficile à montrer par écrit parce que c'est une conversation. Lance claude sans consigne : tu ouvres une session interactive, et Claude garde en mémoire tout ce que vous vous êtes dit. Tu décris une intention, il écrit directement dans les fichiers ; tu demandes une amélioration, il modifie ce qu'il vient d'écrire ; tu demandes des tests, il crée le fichier de tests. Le rythme est celui d'un binôme : de petites étapes, une vérification à chaque fois, et jamais dix demandes empilées d'un coup. Dans le bloc suivant, les lignes qui commencent par un chevron sont ce que tu tapes, et celles entre crochets ce que Claude fait en retour.

1# Ouvre la session interactive
2claude
3
4# Puis, dans la session :
5# > I am building a login system. Start with the login function
6# >   in @src/auth/login.ts
7# > [Claude writes the code straight into the file]
8# > Now add password hashing
9# > [Claude updates the same file]
10# > Add rate limiting to block brute force attempts
11# > [Claude adds the protection]
12# > Write tests for all of this
13# > [Claude creates the test file]

Quatre demandes, quatre modifications, et à aucun moment tu n'as ouvert l'éditeur toi-même. Ce qui n'a pas changé entre deux messages, c'est le contexte : Claude se souvient du fichier de connexion, de la façon dont il l'a écrit et des choix déjà faits, ce qui t'évite de tout réexpliquer à chaque tour. Ce confort a un revers. Au bout d'une longue session, le contexte se charge de vieilleries qui n'ont plus rien à voir avec la tâche en cours, et la conversation perd en précision. Deux commandes la remettent d'aplomb : /clear repart d'une page blanche, idéal quand tu changes complètement de sujet, tandis que /compact conserve un résumé de la conversation et poursuit sur cette base, ce que tu veux quand la tâche continue mais que l'histoire s'allonge.

Récapitulatif

Revue de code - claude -p "Review @fichier", ou git diff | claude -p "...", et /code-review <numéro de PR> pour une Pull Request entière Documentation - demande à Claude de lire le code et d'écrire lui-même le fichier Tests - claude "Write Jest tests for @fichier and save them to ..." Migrations - le fichier avec @, et le mode planification dès que le chantier grossit Scripts - claude -p en mode non interactif, le tuyau | en entrée, une variable pour la sortie CI/CD - claude -p --output-format json dans GitHub Actions Binôme - session interactive, /clear et /compact pour tenir le contexte Modèles et effort - haiku pour aller vite, sonnet au quotidien, opus et fable pour les gros chantiers ; --effort règle le temps de réflexion du modèle

Dans le prochain exercice, on met le cap sur le mode planification et les sous-agents, et tu verras que nous n'avons encore longé que la côte. On se retrouve là-bas !

Retiens surtout ceci : Claude Code ne remplace pas le marin à la barre, il tient les cordages pendant que tu gardes le cap - et un équipage qui automatise ses corvées de quart arrive toujours au port avant les autres.

1#!/bin/bash
2# Revue de code avec Claude Code
3# Usage : ./code-review.sh
4
5echo "Revue des changements en staging..."
6
7# Récupère les changements en staging et envoie-les à Claude par un pipe.
8# Le mode -p (--print) affiche la réponse puis rend la main.
9git diff --cached | claude -p "Passe ces changements en revue pour trouver :
10  - les erreurs de logique
11  - les failles de sécurité
12  - les problèmes de performance
13  - les entorses aux bonnes pratiques
14
15  Sois concis. Ne signale que les vrais problèmes."
16
17echo ""
18echo "Revue terminée. Corrige les erreurs avant le commit."
19
20# Tu peux aussi désigner un fichier précis avec @ au lieu du pipe :
21#   claude -p "Passe @src/auth.ts en revue pour la sécurité"
22
23# Ou, dans une session, passer en revue la Pull Request numéro 42
24# (/code-review seul vérifie les changements de ta branche) :
25#   /code-review 42