Copilot corrige 25 alertes à la fois, sans preuve publique de fiabilité
Depuis le 9 septembre 2026, GitHub permet de confier à Copilot jusqu’à 25 alertes standard de Code Quality affichées sur une même page. Selon l’annonce officielle du lancement, l’agent travaille dans une branche, valide ses propres changements, puis ouvre une pull request que l’utilisateur doit examiner et fusionner.
La fonction est disponible dans les dépôts où GitHub Code Quality est activé sur GitHub Team ou GitHub Enterprise Cloud et nécessite une licence Copilot pour déléguer la remédiation. Elle automatise la préparation d’un lot de modifications, pas leur approbation : l’analyse indépendante de The Expectancy relève l’absence de taux public de réussite, d’acceptation par les réviseurs ou de régression, ainsi que l’absence de coût fixe publié pour un lot de 25 alertes.
Une sélection groupée aboutit à une pull request
Le parcours commence dans la liste des résultats standard de Code Quality. L’utilisateur sélectionne entre une et 25 alertes visibles sur la page, puis choisit « Assign to Copilot ». Cette commande remplace l’ancienne action « Generate fix » appliquée individuellement aux résultats.
Copilot réalise ensuite les modifications dans une branche distincte de la branche par défaut. La validation exécutée par l’agent constitue une étape du flux, mais aucun protocole commun à tous les dépôts n’est défini publiquement : les vérifications utiles dépendent des tests, des scripts et de la configuration réellement accessibles dans chaque projet.
Le résultat prend la forme d’un diff inspectable dans une pull request. Il n’est ni approuvé ni fusionné automatiquement par cette fonction. Les protections du dépôt, les contrôles d’intégration continue et les approbations exigées peuvent donc encore bloquer la fusion ou conduire un réviseur à demander des modifications.
Les offres compatibles cumulent plusieurs postes de coût
La documentation de GitHub Code Quality réserve le produit à GitHub Team et GitHub Enterprise Cloud. Elle distingue la licence fondée sur les contributeurs actifs, les crédits d’IA consommés par certaines analyses et corrections, ainsi que les minutes GitHub Actions employées par les analyses CodeQL lorsque les exécuteurs ne sont pas auto-hébergés.
Les correctifs automatiques proposés directement par Code Quality et la délégation d’un travail de remédiation à Copilot ne répondent pas exactement aux mêmes conditions. La délégation facultative à l’agent exige une licence Copilot, tandis que l’affectation du lot consomme des crédits d’IA. La correction groupée reprend par ailleurs la politique d’entreprise déjà appliquée à Code Quality, sans réglage séparé propre aux lots.
Le plafond de 25 alertes ne représente pas une unité tarifaire. En l’absence de prix fixe par lot, le nombre de résultats sélectionnés ne permet pas à lui seul de prévoir les crédits consommés. Une équipe doit distinguer le coût de la génération, celui d’éventuelles relances et les ressources d’intégration continue mobilisées par la pull request.
Un lot plus large exige une revue cohérente
Une pull request unique peut faciliter l’examen de défauts liés, mais elle augmente aussi le nombre d’interactions possibles entre les changements. Plusieurs corrections apparemment séparées peuvent toucher une fonction commune, un contrat d’API, un fichier de configuration ou les mêmes tests. La disparition des alertes ne suffit donc pas à établir que leur combinaison préserve le comportement attendu.
La limite de 25 est un maximum technique, et non une taille recommandée pour chaque dépôt. Pour conserver une modification compréhensible, le regroupement peut suivre un composant, une règle de détection ou une zone fonctionnelle commune. Mélanger des défauts sans relation rend au contraire plus difficile l’identification du changement responsable lorsqu’un contrôle échoue.
La revue d’une proposition groupée peut vérifier :
- qu’une modification identifiable répond à chaque alerte sélectionnée ;
- que le diff ne contient pas de changement périphérique sans rapport avec le lot ;
- que les tests couvrent les fichiers, les interfaces et les cas limites touchés ;
- que les corrections interdépendantes restent compatibles lorsqu’elles sont exécutées ensemble ;
- que les contrôles de qualité et les conditions de fusion du dépôt sont satisfaits ;
- que les crédits consommés, les relances et les reprises humaines sont suivis pour le lot.
La validation de l’agent et l’approbation humaine ne mesurent pas la même chose. La première indique qu’une procédure automatisée a été exécutée ; la seconde détermine si ces contrôles étaient adaptés au dépôt, si les conventions du projet sont respectées et si le risque fonctionnel est acceptable.
La capacité est établie, pas la qualité des correctifs
Le lancement établit le périmètre du flux : une sélection plafonnée, une branche de travail, une validation effectuée par l’agent et une pull request remise aux responsables du dépôt. Il ne démontre pas que toutes les alertes d’un lot seront résolues correctement, ni qu’un lot sera plus efficace que plusieurs corrections séparées.
Aucune mesure agrégée n’accompagne la mise à disposition : ni proportion de lots entièrement corrigés, ni taux de fusion sans reprise, ni fréquence des régressions. Il manque aussi des données reliant le nombre d’alertes au temps de revue et aux crédits consommés. Le verbe « corriger » désigne ainsi la tâche confiée à Copilot et la production de changements proposés, non une garantie sur leur fiabilité.
À ce stade, le garde-fou observable reste la pull request soumise aux contrôles du dépôt et à une décision humaine avant fusion. L’évaluation de la fonction dépendra de données encore absentes sur les correctifs effectivement fusionnés, les reprises demandées, les défauts introduits, le temps consacré à la revue et le coût réel des lots.
À lire aussi:
Abonnez-vous à notre newsletter
Recevez directement les dernières actualités sur le Web3, l’IA et les cryptomonnaies.