De l'issue GitHub à la pull request avec un agent

Une bonne issue est fondamentalement un prompt – avec du contexte et des critères d'acceptation, elle devient une pull request propre et vérifiable.

Le déroulement de base

Un workflow d'agent typique se déroule ainsi : une issue GitHub décrit une tâche, un agent (par ex. via @claude dans un commentaire, ou un pipeline CI) lit l'issue, travaille sur sa propre branche, produit des modifications de code et ouvre finalement une pull request – pour une vérification humaine, pas pour une fusion automatique.

Une bonne issue est un bon prompt

Les mêmes règles qui valent pour un bon prompt valent pour une bonne issue : un contexte clair (quel fichier, quel comportement, pourquoi), des critères d'acceptation concrets et, si possible, un exemple du comportement attendu. Une issue vague mène à une PR vague, souvent inutilisable – que ce soit un humain ou un agent qui la réalise.

Pourquoi une branche propre est importante

L'agent ne travaille jamais directement sur la branche principale, mais sur sa propre branche de fonctionnalité. Cela garde les modifications isolées, vérifiables et – si quelque chose tourne mal – annulables sans conséquence, sans toucher à la branche principale.

La revue humaine reste la porte d'entrée

La pull request est le point de contrôle décisif : un humain vérifie le diff, la description et les résultats de la CI avant la fusion. Les vérifications CI (tests, linting, build) s'exécutent automatiquement comme filet de sécurité supplémentaire, mais ne remplacent pas le jugement humain sur la pertinence de la modification.

EXEMPLE

Issue : « Bug : /api/users renvoie 500 au lieu d'une liste vide quand le champ de recherche est vide. Contexte : routes/users.js, ligne 42. Critère d'acceptation : GET /api/users?q= renvoie [] avec le statut 200, le test existant tests/users.test.js reste vert. » Commentaire dans l'issue : @claude merci de réaliser cela → L'agent travaille sur la branche fix/empty-search, ouvre la PR "Fix: empty search returns [] instead of 500 (Closes #123)"

🛠️ EXERCICE — À TOI DE JOUER

Écris une issue GitHub complète, exploitable par un agent, pour un petit correctif de bug, et fais-la réaliser.

Choisis un petit bug clairement délimité, ou un détail mineur, dans un de tes propres dépôts.
Rédige une issue avec le fichier/la fonction concerné(e), le comportement défaillant actuel, le comportement cible et au moins un critère d'acceptation concret.
Fais proposer la réalisation par un agent (par ex. Claude Code ou l'intégration GitHub) sur sa propre branche, et fais-lui ouvrir une pull request.
Vérifie la PR comme le ferait un relecteur : titre, description, diff, lien avec l'issue.

✅ AUTO-VÉRIFICATION

☐ Ton issue contenait-elle les quatre éléments (contexte, comportement défaillant, comportement cible, critère d'acceptation) ?
☐ L'agent a-t-il pu réaliser la tâche sans question de clarification, ou des informations manquaient-elles ?

QUIZ RAPIDE

Qu'est-ce qui fait d'une issue GitHub un « bon prompt » pour un agent de code ?