Depuis le 23 juillet, GitHub teste une nouvelle couche de contrôle pour les agents capables de modifier des issues. Au lieu de laisser une automatisation ajouter des labels, assigner quelqu’un ou fermer un ticket sans explication, la plateforme peut désormais afficher sa justification, estimer son niveau de confiance et attendre une validation humaine.
Ce n’est pas la fonctionnalité la plus spectaculaire de la semaine. C’est pourtant une évolution assez importante : les agents ne sont plus seulement des assistants qui proposent du texte ou du code. Ils commencent à agir directement sur l’état d’un projet.
## Ce que GitHub vient d’ajouter
La préversion publique concerne les automatisations de Copilot cloud agent, les GitHub Agentic Workflows ainsi que les intégrations utilisant les API REST ou GraphQL de la plateforme.
Pour le moment, le système encadre cinq catégories d’actions sur les issues :
- l’ajout ou la modification de labels ;
- le remplissage de champs ;
- le changement de type ;
- l’assignation à un utilisateur ou à un agent ;
- la fermeture d’une issue.
Chaque action compatible peut maintenant recevoir une justification enregistrée dans l’historique. GitHub lui associe également un niveau de confiance faible, moyen ou élevé. Selon le seuil configuré dans le dépôt, la modification est appliquée immédiatement ou conservée sous forme de suggestion à accepter ou refuser depuis l’interface de l’issue. Quatre niveaux d’automatisation sont proposés, du contrôle intégral à l’application presque automatique.
Le réglage par défaut, baptisé Cautious, applique les actions considérées comme très fiables et place les autres en attente. Une recherche has:suggestions permet de retrouver les issues qui nécessitent encore une décision humaine.
## Pourquoi un score de confiance ne suffit pas
Afficher « confiance élevée » donne une indication utile, mais ce n’est pas une preuve. GitHub décrit actuellement trois catégories qualitatives, pas une probabilité calibrée permettant d’affirmer qu’une action est correcte dans 95 % des cas.
Le score sert surtout à organiser le travail humain. Sur un dépôt recevant beaucoup de tickets, un agent peut traiter les cas simples et laisser remonter les ambiguïtés : bug ou demande de fonctionnalité, doublon probable, assignation incertaine, ticket incomplet.
La justification est probablement plus intéressante que le score lui-même. Un label ajouté sans contexte oblige à relire toute l’issue. Une justification courte permet de vérifier rapidement si l’agent s’est appuyé sur les bons éléments. Elle crée aussi une trace exploitable lorsque l’automatisation se trompe régulièrement sur un type de demande.
Autrement dit, le système ne supprime pas la revue. Il essaie de la concentrer là où elle apporte réellement quelque chose.
## Le piège : confondre validation et sécurité
GitHub insiste sur une limite importante : les approbations sont une commodité de workflow, pas une barrière de sécurité. Un agent disposant déjà de la permission de modifier une issue peut appliquer directement une action, notamment via les API, au lieu de la soumettre comme suggestion.
La vraie protection reste donc le périmètre des permissions. Une automatisation de tri n’a normalement pas besoin de pousser du code, d’accéder à des secrets ou de déclencher n’importe quel workflow. La documentation recommande de n’activer que les outils nécessaires et précise que les automatisations sont limitées à un seul dépôt.
Il faut également penser aux entrées non fiables. Une issue est du texte fourni par un utilisateur, donc potentiellement une tentative d’injection de prompt. Par défaut, les automatisations ignorent les événements provenant d’utilisateurs sans accès en écriture. Ce choix réduit le risque, mais limite aussi l’intérêt du tri automatique pour un dépôt public recevant des contributions externes.
## Ce que je testerais sur un petit projet
Pour un portfolio, une API personnelle ou un outil auto-hébergé, je commencerais avec une automatisation très limitée : proposer un type et quelques labels lors de la création d’une issue, sans fermeture automatique ni assignation.
Le bon ordre me semble être :
- commencer en contrôle intégral ;
- observer les justifications et les erreurs ;
- stabiliser les catégories et les instructions du dépôt ;
- autoriser uniquement les actions répétitives à forte confiance ;
- conserver une validation humaine pour tout ce qui modifie réellement le planning ou ferme une demande.
Le point intéressant n’est finalement pas que l’agent puisse trier des tickets. C’est que GitHub Issues commence à intégrer un modèle de délégation plus réaliste : autonomie limitée, explication visible et reprise en main possible. C’est moins magique qu’un agent totalement autonome, mais beaucoup plus proche de ce qu’on peut laisser tourner sur un vrai projet.
## Pour aller plus loin
- Annonce de la préversion publique
- Documentation sur les justifications, niveaux de confiance et approbations
- Fonctionnement des automatisations Copilot
- Risques et protections du Copilot cloud agent
Veille rédigée avec l'aide d'une IA — sources vérifiées et liées ci-dessus.