Copilot cloud agent : de l'issue à la PR sans perdre le contrôle
Le bon workflow Copilot cloud agent commence avant l'assignation. Une issue trop floue donne une PR floue. Voici comment cadrer la tâche, limiter le scope et relire.
Durée
10 min
Niveau
Intermédiaire
Outils
GitHub Copilot · Cloud agent · GitHub Issues
Assigner une issue à un agent est facile.
Obtenir une PR relisable, c’est autre chose. Le cloud agent peut rechercher dans le repo, planifier, modifier le code et ouvrir une PR. Mais il ne devine pas tes frontières produit, ton niveau de risque, ni ce que tu considères comme “fini”.
La qualité commence dans l’issue.
1. Écris l’issue comme un contrat
Une bonne issue pour agent contient :
- le problème observé;
- le résultat attendu;
- les fichiers ou zones probables;
- ce qui est hors scope;
- le test ou la preuve attendue;
- l’interdiction de merger directement.
Exemple :
## Objectif
Ajouter l'état vide sur /ai-coding quand aucun tutoriel n'est publié.
## Contraintes
- Ne pas changer la collection Astro.
- Ne pas toucher au header.
- Garder la version EN cohérente.
## Acceptation
- bun run build passe.
- Une capture ou description du rendu est ajoutée dans la PR.
Le but n’est pas de micro-manager. Le but est de retirer les ambiguïtés chères.
2. Découpe les issues trop larges
Mauvais sujet : “améliorer l’UX du blog”.
Bon sujet : “limiter le fil du jour à huit articles et ajouter un lien Voir tous”.
Le cloud agent est plus utile sur une unité de travail vérifiable. Dès que tu mets trois décisions produit dans la même issue, tu transformes la review en enquête.
3. Review de PR : regarde d’abord le hors-scope
Avant de lire le code ligne par ligne, vérifie :
- fichiers modifiés;
- dépendances ajoutées;
- migrations;
- changements de config;
- routes touchées;
- tests supprimés ou ignorés.
Si la PR sort du contrat, demande une itération avant de relire le détail. C’est plus rapide que commenter quinze lignes.
4. Le commentaire qui marche
Quand l’agent se trompe, réponds comme à un dev :
La PR part hors scope en modifiant le header.
Reviens au contrat initial :
- seulement /ai-coding
- pas de changement design global
- garde les tests/build
Explique ensuite ce que tu as retiré.
Plus le feedback est opérationnel, moins la deuxième passe dérive.
Sources
Aller plus loin