Workflows avancés

Les chapitres précédents ont donné les outils. Celui-ci donne les manières de s’en servir : cinq façons de travailler qui font la différence entre un usage anecdotique et un vrai gain de rendement.

Toutes reposent sur le même principe, posé au chapitre 23 : donner à Claude un critère de réussite qu’il peut vérifier lui-même.

Piloter par les tests#

C’est le workflow le plus rentable, et pour une raison structurelle : un test qui échoue est un critère objectif sur lequel Claude peut boucler seul.

Sans critère, il s’arrête quand le code lui paraît correct. Avec un test rouge, il s’arrête quand le test passe. Ce n’est pas la même chose.

> On travaille en TDD. Trois étapes, tu t'arrêtes après chacune.

Étape 1 : écris un test qui reproduit le bug décrit ci-dessous. Le test
doit ÉCHOUER pour la bonne raison. Lance-le et montre-moi la sortie
d'échec. N'écris aucun code de production.

Bug : quand une commande contient un article en rupture, le paiement
est débité mais la commande reste au statut « en attente ».

Étape 2 : après ma validation, corrige le code jusqu'à ce que le test
passe. Ne modifie pas le test.

Étape 3 : lance `npm run verify` en entier et montre-moi qu'aucune
autre chose n'est cassée.

Trois détails font tout le travail.

« Doit échouer pour la bonne raison ». Un test qui échoue sur une erreur de compilation ne prouve rien.

« N’écris aucun code de production ». Sans cette phrase, l’étape 1 et l’étape 2 fusionnent, et vous perdez le point de contrôle.

« Ne modifie pas le test ». C’est la consigne indispensable. Sans elle, un test récalcitrant finit ajusté jusqu’à passer — et vous avez un test qui valide le bug.

Les migrations mécaniques#

Renommer une API dans deux cents fichiers, changer un format d’import, remplacer une bibliothèque. La tentation est de tout demander d’un coup. Le résultat est une dérive : le fichier 150 n’est pas traité comme le fichier 1.

La méthode qui marche a quatre temps.

1. Un fichier, choisi difficile. Pas le plus simple : celui qui contient un cas particulier.

2. Le motif, écrit.

> La migration de ce fichier me convient.

Écris maintenant le motif de transformation sous forme de règles
explicites : ce qui est remplacé par quoi, dans quels cas, et les cas
particuliers que tu as rencontrés.

Écris-le dans MIGRATION.md. C'est ce document qui pilotera les 199
fichiers restants, il doit se suffire à lui-même.

3. Un lot, avec vérification.

> Applique MIGRATION.md aux dix fichiers suivants : [liste].

Après chaque fichier, lance `npm run verify` sur le périmètre concerné.

Si un fichier ne rentre pas dans le motif, NE L'ADAPTE PAS : laisse-le
tel quel, note-le dans MIGRATION.md sous « cas non couverts », et
continue avec le suivant.

4. Le reste, puis les exceptions.

La consigne de l’étape 3 est celle qui sauve la migration. Sans elle, Claude adapte le motif au cas particulier, et le motif adapté s’applique aux suivants — vous obtenez deux cents fichiers migrés de cent façons différentes.

Les cas non couverts se traitent ensuite, à la main ou en petits groupes. Ils sont généralement peu nombreux, et ce sont exactement ceux qui méritaient votre attention.

Déboguer par bissection#

L’erreur courante est de décrire le symptôme et de demander une correction. Vous obtenez une hypothèse plausible, appliquée avec confiance, qui traite parfois le bon problème.

La méthode qui marche impose la localisation avant l’explication.

> Symptôme : [description précise, avec les étapes de reproduction].

Ne propose aucune correction pour l'instant.

1. Écris le plus petit cas de reproduction possible. Lance-le, montre
   la sortie.
2. Localise par bissection : où le comportement diverge-t-il de
   l'attendu ? Instrumente si nécessaire, montre-moi les valeurs
   observées à chaque étape.
3. Quand tu as localisé, dis-moi exactement quelle ligne produit le
   mauvais résultat, et avec quelles valeurs d'entrée.
4. Alors seulement : pourquoi cette ligne est-elle fausse, et depuis
   quand — regarde `git log -S` sur la portion concernée.

Je validerai avant toute correction.

L’étape 4 est celle que personne ne demande, et c’est souvent la plus instructive : git log -S sur une chaîne de caractères montre quand elle est apparue, dans quel commit, avec quel message. Cela transforme un bug en histoire, et l’histoire explique généralement le bug.

La revue#

Une revue par Claude est utile à trois conditions.

Un contexte propre. Une revue dans la conversation qui a produit le code est complaisante : le modèle a déjà « pris parti ». Faites-la dans une session neuve, ou dans un sous-agent — chapitre 26.

Une consigne de couverture, pas de sévérité. Une consigne du type « ne signale que ce qui est important » est suivie à la lettre, et les modèles récents filtrent alors beaucoup : vous perdez en rappel ce que vous gagnez en précision.

Une seconde passe pour trier.

> Revue de ce diff.

Signale TOUT ce que tu trouves, y compris ce dont tu n'es pas sûr et
ce qui te paraît mineur. Ne filtre pas selon l'importance : une autre
passe s'en chargera.

Pour chaque point : fichier, ligne, ce qui cloche, un scénario concret
où ça casse, ton niveau de confiance, et ta gravité estimée.

Un point que tu ne peux pas illustrer par un scénario concret est
probablement une préférence de style : range-le dans une section à
part.

Puis, dans une seconde demande, faites trier par gravité et par confiance. Vous obtenez une revue à la fois exhaustive et lisible — ce qu’une seule passe ne donne jamais.

Travailler en parallèle#

Trois sessions dans le même dossier se marchent dessus : elles modifient les mêmes fichiers et voient les modifications des autres.

La bonne réponse est le worktree git : un répertoire de travail distinct, sur une branche distincte, dans le même dépôt.

git worktree add ../projet-refactor refactor/paiements
git worktree add ../projet-bug fix/pagination

cd ../projet-refactor && claude   # une session
cd ../projet-bug      && claude   # une autre, indépendante

Chaque session a son répertoire, sa branche, son contexte. Rien ne se mélange, et l’historique reste propre.

Quelques règles d’usage.

Un worktree par tâche, jeté après la fusion. git worktree remove ../projet-bug.

Des dépendances installées par worktree si votre écosystème le demande — c’est le principal coût de la méthode.

Pas plus de trois ou quatre à la fois. Au-delà, c’est vous qui devenez le goulot : superviser quatre sessions demande plus d’attention que d’en faire une soi-même.

Enchaîner avec git#

Claude Code lit l’historique, écrit des messages de commit, prépare des pull requests. Deux réglages rendent cela sain.

Les commits se demandent, jamais ne s’automatisent. Un commit automatique après chaque modification produit un historique illisible.

Le message vient du diff, pas de la conversation.

> Prépare un commit.

Lis le diff mis en scène, pas notre conversation. Le message doit
décrire ce que le code fait maintenant, pas ce que nous avons essayé.

Format : une ligne de résumé de moins de 72 caractères, une ligne
vide, puis le pourquoi — pas le comment, que le diff montre déjà.

Si le diff contient deux changements sans rapport, dis-le-moi : il
faudrait deux commits.

La dernière consigne attrape le commit fourre-tout, qui est le principal défaut d’un historique produit à la chaîne.

> passe en mode plan

Inventorie l'usage de [bibliothèque] dans ce projet :
- la liste des fonctions utilisées, avec le nombre d'occurrences
- pour chacune, s'il existe un équivalent direct dans [nouvelle], un
  équivalent avec adaptation, ou aucun
- les fichiers qui utilisent les cas sans équivalent

Écris le résultat dans MIGRATION.md. Ne modifie aucun fichier.

> Applique MIGRATION.md aux fichiers listés dans la section « cas
  directs », par lots de vingt.

Après chaque lot : `npm run verify`. Si un lot échoue, arrête-toi et
montre-moi l'échec — ne corrige pas de ton propre chef.

Si un fichier ne rentre pas dans le motif, laisse-le tel quel et
ajoute-le à la section « à traiter à la main ».

Ce qu’il faut retenir#