De bout en bout : de l'issue à la pull request mergée

Un ingénieur junior qui prend un ticket, écrit un correctif et ouvre une pull request propre sans supervision a de la valeur. Claude Code peut exécuter exactement cette boucle, et la compétence dont vous avez besoin n'est pas le « prompting » mais l'orchestration d'un workflow de développement discipliné où l'IA tape et où vous restez le point de contrôle.

Cette leçon suit une issue réaliste, de son ouverture à son merge. Nous utiliserons Claude Code, l'agent de code en terminal d'Anthropic, ainsi que son intégration GitHub. La mécanique se généralise, mais c'est la discipline qui compte.

Le setup : accès GitHub depuis Claude Code

Claude Code lit et écrit dans votre repo local. Pour boucler jusqu'à GitHub (issues, PR, reviews), vous le connectez à votre remote.

Le chemin le plus propre est le CLI GitHub (gh), que Claude Code peut appeler directement comme un outil. Authentifiez-vous une fois :

gh auth login
cd ~/projects/checkout-service
claude

Claude Code peut désormais lancer gh issue view, gh pr create et compagnie à votre place. Il existe aussi une app GitHub officielle, @claude, que vous installez sur un repo pour mentionner Claude dans les commentaires d'issues et de PR et obtenir sa réponse directement dans GitHub. Voir la documentation Claude Code GitHub Actions pour cette variante côté serveur. Dans cette leçon, nous pilotons tout depuis le terminal pour que vous puissiez observer chaque étape.

Nouveau terme : un managed agent est un agent hébergé par Anthropic qui tourne dans le cloud plutôt que sur votre portable. La boucle Claude Code locale que nous faisons ici a la même forme, elle tourne simplement sur votre machine, où vous pouvez l'interrompre.

Étape 1 : prendre l'issue, et faire reformuler Claude

Commencez par charger l'issue dans le contexte. Ne la collez pas. Laissez Claude la récupérer, pour que l'agent porte l'étape de récupération.

> Read issue #214 with gh. Summarize the bug, the expected
  behavior, and what files you'd likely touch. Don't write code yet.

Claude lance gh issue view 214, la lit et répond avec un plan. Cette reformulation est votre premier checkpoint. Si l'issue dit « les remises s'appliquent deux fois sur les clients récurrents » et que le résumé de Claude parle d'arrondi de TVA, vous avez intercepté une mauvaise lecture avant qu'une seule ligne ne change.

C'est l'endroit le moins coûteux pour corriger la trajectoire. Prenez-y du temps.

Étape 2 : hygiène de branche avant tout code

Une branche propre par issue n'est pas négociable. Cela cadre votre diff, rend la review possible, et vous permet d'abandonner le travail à faible coût si l'approche est mauvaise.

Énoncez la convention explicitement à Claude la première fois :

> Create a branch off main named fix/214-double-discount.
  We branch from updated main, one branch per issue, never commit
  to main directly.

Mieux : encodez-la une fois pour ne jamais la retaper. Claude Code lit un fichier CLAUDE.md à la racine du repo comme instructions permanentes pour chaque session. Mettez-y les règles de votre équipe.

## Workflow rules
- Branch from updated `main`, one branch per issue.
- Branch names: `fix/<issue>-<slug>` or `feat/<issue>-<slug>`.
- Never commit to `main`. Never force-push shared branches.
- Keep diffs small. If a change exceeds ~150 lines, stop and ask.
- Every behavior change ships with a test.

Nouveau terme : CLAUDE.md est un simple fichier Markdown que Claude Code charge automatiquement comme contexte projet. Voyez-le comme le README que l'agent respecte vraiment. C'est le fichier à plus fort effet de levier dans un repo agentique.

La règle « arrarrL'Annual Recurring Revenue (ARR) est le revenu normalisé et prévisible qu'une entreprise par abonnement attend de ses contrats actifs sur une année.Voir la définition complète →ête-toi et demande si le diff dépasse ~150 lignes » compte plus qu'il n'y paraît. Les petits diffs ne sont pas une préférence de style ; ce sont les seuls diffs qu'un humain peut réellement relire. Une PR de 600 lignes générée par IA, c'est un tampon automatique qui n'attend que d'arriver.

Étape 3 : implémenter, avec les tests comme contrat

Laissez maintenant Claude travailler. Le geste clé est de faire des tests la spécification, pas de la prose.

> Reproduce #214 with a failing test first, then make it pass.
  Run the suite after each change. Show me the failing test before
  you fix anything.

C'est du développement piloté par les tests, et c'est le garde-fou le plus efficace pour du code écrit par IA. Le test qui échoue prouve que Claude a compris le bug. Le test qui passe prouve que le correctif fonctionne. Vous relisez un comportement, pas une impressionimpressionLe nombre total de fois qu'une publicité ou un contenu est affiché, indépendamment des clics. Chaque affichage compte pour une impression, même auprès de la même personne.Voir la définition complète →.

Claude va typiquement :

1. Écrire un test qui reproduit le bug de double remise et le voir échouer.
2. Modifier la logique de remise.
3. Relancer la suite jusqu'au vert.
4. Rapporter ce qu'il a changé et pourquoi.

Regardez la boucle tourner. Si Claude commence à modifier des fichiers sans rapport ou à « améliorer » des choses que vous n'avez pas demandées, interrompez-le (Esc) et resserrez le périmètre. Le scope creep, c'est ainsi que de petits diffs deviennent irrelisables.

Étape 4 : relire le diff vous-même, en local

Avant que quoi que ce soit n'atteigne GitHub, lisez le diff. C'est le point de contrôle humain, et c'est la partie de la boucle que vous ne devez jamais déléguer.

> Show me the full diff with git diff. Walk me through each hunk.

Puis lisez-le vraiment. Vous cherchez trois choses :

• Justesse : le changement fait-il ce que l'issue demandait, et rien d'autre ?
• Périmètre : y a-t-il des modifications en douce ? Un bloc d'imports reformaté, une variable renommée dans une fonction non touchée, un commentaire supprimé qui avait son importance ?
• Tests : le nouveau test est-il significatif, ou vérifie-t-il une évidence ?

Claude est bon pour produire du code plausible. Plausible n'est pas juste. La review du diff est là où vous convertissez « ça a l'air bon » en « c'est bon ». Si vous ne comprenez pas un hunk, demandez à Claude de l'expliquer, puis décidez vous-même si l'explication tient.

Étape 5 : commiter et ouvrir la PR

Une fois le diff validé par votre review, commitez avec un message qui référence l'issue, puis ouvrez la PR.

> Commit with a conventional message referencing #214. Then open
  a PR against main. In the body: a one-line summary, what changed,
  how it was tested, and "Closes #214".

La ligne Closes #214 fait un vrai travail : GitHub fermera automatiquement l'issue au merge de la PR. Claude écrit un corps de ce type :

## Summary
Returning customers no longer receive the loyalty discount twice.

## Changes
- `discount.py`: guard against re-applying loyalty tier in
  `apply_discounts()` when one is already present.
- Added regression test `test_loyalty_applied_once`.

## Testing
Full suite green (142 passed). New test fails on `main`, passes here.

Closes #214

Notez que le corps explique le *pourquoi* et la vérification, pas seulement le *quoi*. Le diff montre déjà ce qui a changé. Une bonne description de PR dit au relecteur quoi vérifier.

Étape 6 : la PR est une seconde surface de review, servez-vous en

La pull request n'est pas une formalité. C'est là que les coéquipiers et la CI donnent leur avis, et vous devez la traiter comme un second point de contrôle indépendant.

Si vous avez installé l'app GitHub @claude, vous pouvez demander une passe de review IA directement dans la PR :

@claude review this PR for edge cases around discount stacking and
suggest any missing test cases.

Claude poste des commentaires de review sur le diff. C'est réellement utile comme *seconde paire d'yeux*, mais résistez à la tentation de laisser le modèle qui a écrit le code l'approuver aussi. Une review IA de code IA attrape les problèmes mécaniques (erreurs d'indice, nulls non gérés, branches de test manquantes). Elle n'attrape pas « toute cette approche est mauvaise pour notre domaine ». Ce jugement reste humain.

Laissez tourner la CI. Si le pipelinepipelineL'ensemble des opportunités commerciales actives réparties selon les étapes du processus de vente, avec leur valeur potentielle cumulée et leur probabilité de conclusion.Voir la définition complète → est rouge, renvoyez l'échec en entrée :

> CI failed on the lint stage. Pull the logs with gh run view,
  fix the issue, and push to the same branch.

Claude corrige et push. La PR se met à jour en place. C'est le rythme réaliste : implémenter, relire, CI, corriger, répéter, tout sur une seule branche resserrée.

Étape 7 : merger, et nettoyer

Quand le diff est approuvé et la CI verte, mergez. Préférez un squash merge pour que l'historique d'itérations désordonné de la branche se réduise à un commit propre sur main.

> Squash-merge the PR with gh, delete the remote branch, then
  switch local back to main and pull.

gh pr merge 214 --squash --delete-branch
git checkout main
git pull

L'issue #214 se ferme automatiquement grâce à la ligne Closes #214. Votre main local est à jour. La branche de feature a disparu, en local comme en remote. Vous êtes prêt pour le ticket suivant, sans état résiduel.

Ce nettoyage final est le pendant de l'hygiène de branche. Les branches obsolètes s'accumulent vite quand un agent peut en crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →éererLe rapport entre les interactions (likes, commentaires, partages) et le reach d'un contenu, utilisé pour mesurer la réaction de l'audience au regard du nombre de personnes touchées.Voir la définition complète → en quelques secondes. Faites de la suppression une partie du merge, pas une corvée pour plus tard.

Pourquoi cette boucle tient sous pression

Avec un agent de code performant, la tentation est de supprimer les checkpoints : un prompt géant, un diff géant, un merge. Ça marche en démo et ça échoue en production, parce que le mode d'échec du code LLMLLMUn Large Language Model est un système d'IA entraîné sur d'énormes volumes de texte pour prédire et générer du langage, ce qui permet de rédiger, résumer ou répondre à des questions.Voir la définition complète → n'est pas « cassé et évident » mais « plausible et subtilement faux ».

La boucle que vous venez d'exécuter résiste à cet échec par la structure, pas par la confiance :

• La reformulation de l'issue attrape les malentendus avant le code.
• La règle du petit diff garde le changement relisable.
• Le test qui échoue puis passe rend la justesse vérifiable, pas supposée.
• La review humaine du diff est le point de contrôle que le modèle ne peut pas franchir seul.

Encodez tout cela dans CLAUDE.md et cela s'applique automatiquement à chaque session. La discipline devient une infrastructure au lieu d'une affaire de volonté.

Pour les patterns d'automatisation plus poussés (exécuter cette boucle sans surveillance en CI, agents multi-étapes, outils personnalisés via MCPMCPUn standard ouvert qui permet aux assistants IA de se connecter aux outils et données de l'entreprise de façon cohérente et gouvernée, sans intégration sur mesure à chaque fois.Voir la définition complète →), la documentation du Claude Agent SDK est l'étape suivante. Mais le non-supervisé est une destination, pas un point de départ. Gagnez-le en exécutant la boucle supervisée jusqu'à faire confiance à chaque checkpoint.

Points clés

• Mettez vos règles de workflow dans `CLAUDE.md`, y compris le nommage des branches, la règle d'interdiction de commit direct sur main, et une limite dure de taille de diff qui force Claude à s'arrêter et à demander. Les instructions permanentes valent mieux qu'un prompt par session.
• Faites des tests le contrat. Demandez à Claude d'écrire un test qui échoue et reproduit l'issue *avant* de la corriger. Vous relisez alors un comportement vérifiable, pas du code d'apparence plausible.
• Gardez les diffs suffisamment petits pour être réellement lus. Un diff qu'un humain ne peut pas relire est un diff qu'un humain ne peut pas approuver. Coupez le scope creep dès que vous le voyez.
• La review humaine du diff est le point de contrôle non négociable. Laissez Claude (ou @claude) faire une seconde passe sur les problèmes mécaniques, mais ne laissez jamais le modèle qui a écrit le code être celui qui l'approuve.
• Faites du nettoyage de branche une partie du merge. Squash-merge, suppression de la branche, pull de main, pour démarrer chaque ticket d'un état propre.