GitHub vient de faire ce que peu d'éditeurs osent faire : reconnaître publiquement qu'une fonctionnalité phare imposait quelque chose que personne n'avait vraiment demandé. Depuis le 7 août 2026, activer Code Quality sur un dépôt ne force plus Copilot à se désigner automatiquement relecteur de vos pull requests. Un revirement net, moins de trois semaines après le passage en disponibilité générale de la fonctionnalité.
Un ruleset imposé sans le dire
Retour en arrière rapide. Le 20 juillet 2026, GitHub Code Quality passait en disponibilité générale. La promesse : une analyse continue de la qualité du code, intégrée nativement au flux de pull requests, sans configuration lourde. Sur le papier, une bonne nouvelle pour les équipes qui jonglaient jusque-là avec des outils tiers de linting et d'analyse statique.
Sauf qu'en activant Code Quality, GitHub créait dans l'ombre un ruleset nommé Code Quality Copilot review for default branch, appliqué automatiquement à la branche par défaut du dépôt. Ce ruleset activait trois comportements à la fois : demander une revue Copilot sur chaque nouvelle pull request, redemander une revue à chaque nouveau push, et exiger une revue même sur les pull requests encore en brouillon.
Concrètement, un développeur qui activait une fonctionnalité d'analyse de qualité de code se retrouvait, sans l'avoir explicitement choisi, avec un bot IA commentant systématiquement son travail, y compris sur des brouillons qu'il n'avait pas encore jugés prêts à être lus.
Le retour de bâton des utilisateurs
La réaction de la communauté n'a pas traîné. Sur les forums de discussion GitHub, le message revenait sans cesse sous une forme ou une autre : ajouter un relecteur devrait rester un choix, pas un effet de bord d'une fonctionnalité qu'on active pour tout autre chose. Le problème n'était pas tant la qualité des revues Copilot que le fait qu'elles s'imposaient sans consentement explicite, noyées dans l'activation d'une fonctionnalité qui n'avait, au départ, rien à voir avec la revue de pull requests.
GitHub a réagi vite. Depuis le 7 août, les trois réglages du ruleset ont été désactivés par défaut pour les nouvelles activations de Code Quality, et désactivés rétroactivement sur les dépôts qui avaient déjà le ruleset en place. La fonctionnalité d'analyse de qualité continue de tourner normalement ; c'est uniquement l'auto-désignation de Copilot comme relecteur qui disparaît du comportement par défaut.
Point important : Copilot code review en tant que tel n'a pas changé ni été dégradé. Rien n'empêche une équipe de le réactiver volontairement, au niveau du dépôt ou de l'organisation, en configurant elle-même un ruleset avec l'option Automatically request Copilot code review. La différence, c'est que ce sera désormais un choix assumé plutôt qu'un défaut caché.
Un GA en même temps, presque passé inaperçu
Fait notable : ce recul coïncide, jour pour jour, avec le passage en disponibilité générale d'une autre fonctionnalité liée, les niveaux d'effort de la revue de code Copilot. Cette option permet de calibrer la profondeur d'analyse que Copilot applique à une pull request donnée, du survol rapide à l'examen approfondi, plutôt que de subir un seul mode de revue uniforme quel que soit l'enjeu du changement.
Le contraste est parlant. D'un côté, GitHub retire un automatisme non désiré. De l'autre, il donne plus de contrôle granulaire à ceux qui utilisent Copilot code review délibérément. Le fil conducteur, c'est une même logique : laisser la main aux équipes plutôt que d'imposer un comportement par défaut homogène, qu'il s'agisse d'activer la revue ou de doser son intensité.
Je trouve ce genre de correction plus intéressant que la fonctionnalité elle-même. On parle beaucoup des lancements d'agents IA autonomes, moins des reculs quand l'automatisation dépasse ce que les utilisateurs sont prêts à accepter sans y avoir consenti. Un éditeur qui revient sur un défaut mal perçu en moins de trois semaines, c'est un signal que le retour utilisateur pèse encore face à la pression d'embarquer de l'IA partout par défaut.
Ce que ça change concrètement pour les équipes
Pour les dépôts qui avaient déjà Code Quality activé avec le ruleset automatique, aucune action n'est nécessaire : les trois réglages ont été coupés automatiquement, sans perte de l'analyse de qualité elle-même. Pour les équipes qui souhaitaient au contraire garder Copilot comme relecteur systématique, il faut désormais configurer explicitement le ruleset au niveau souhaité, avec les niveaux d'effort adaptés à chaque branche ou type de pull request si besoin.
Pour un DSI ou un lead technique qui gère plusieurs dépôts sous organisation GitHub, c'est le bon moment pour vérifier l'état réel des rulesets actifs : certains dépôts peuvent avoir gardé une configuration héritée de la période où le comportement automatique existait, notamment si des exceptions ont été ajoutées manuellement entre le 20 juillet et le 7 août.
Ce qu'il faut retenir
Ce revirement de GitHub illustre une tension de fond dans l'intégration de l'IA aux outils de développement : entre l'envie d'embarquer des agents partout par défaut pour maximiser l'adoption, et le besoin des équipes de garder la main sur ce qui touche à leur flux de revue de code. GitHub a tranché en faveur du second, au moins pour cette fonctionnalité précise.
À surveiller dans les prochaines semaines : si d'autres fonctionnalités GitHub liées à Copilot suivent la même logique de découplage entre activation d'un outil et embarquement automatique de l'IA en tâche de fond.
