Copilot peut approuver une pull request, mais l’option reste désactivée
GitHub a lancé le 1er septembre 2026, en aperçu public, la possibilité pour Copilot code review d’approuver formellement une pull request. Cette approbation peut satisfaire une exigence de fusion, mais la fonction reste désactivée par défaut, un lancement également documenté par l’analyse de Start Debugging.
La réponse à la question centrale est donc conditionnelle : une approbation formelle de Copilot peut compter dans les règles de fusion, mais son évaluation favorable ordinaire ne compte pas. Pour que la première ait un effet, les paramètres de l’entreprise, de l’organisation et du dépôt doivent tous l’autoriser.
L’évaluation favorable ne vaut pas approbation
Chaque revue de Copilot contient une évaluation dans son commentaire récapitulatif. Elle exprime si le service considère la pull request prête à être approuvée et accompagne les remarques détaillées sur le code, mais ne modifie pas à elle seule l’état des exigences de fusion.
Seule une revue formelle portant l’état d’approbation peut satisfaire la règle correspondante. Le changelog officiel de GitHub distingue explicitement cette approbation comptabilisée de l’évaluation informative affichée dans chaque revue.
La nuance produit un effet concret lorsqu’un ruleset n’exige qu’une approbation. Si l’autorité nécessaire a été accordée à Copilot, son approbation peut remplir ce seuil sans qu’une approbation humaine supplémentaire soit mécaniquement requise. L’affichage d’un simple avis favorable, en revanche, ne débloque jamais la fusion.
La permission descend de l’entreprise jusqu’au dépôt
Les trois niveaux d’administration forment une chaîne de délégation, et non trois interrupteurs indépendants. Une autorisation refusée au niveau supérieur ne peut pas être rétablie par un administrateur situé plus bas.
- Entreprise : les approbations peuvent être désactivées partout, ouvertes à certaines organisations ou laissées à la décision de celles-ci. La désactivation générale constitue le réglage par défaut.
- Organisation : elles peuvent compter dans tous les dépôts, uniquement dans une sélection, rester au choix des administrateurs de dépôt ou être interdites dans toute l’organisation.
- Dépôt : un réglage autorise Copilot à soumettre une revue d’approbation et un autre permet à cette approbation de satisfaire les exigences de fusion. Des motifs de chemins peuvent limiter les pull requests admissibles.
La documentation de configuration de GitHub précise que le dépôt accepte jusqu’à 15 motifs de fichiers et que tous les fichiers modifiés doivent correspondre à au moins l’un d’eux pour que l’approbation soit comptée. Elle distingue également l’autorisation d’approuver, la comptabilisation pour la fusion et l’option de relancer automatiquement la revue après chaque nouveau push.
La matrice se lit donc de haut en bas : l’entreprise détermine quelles organisations disposent de cette faculté ; l’organisation choisit les dépôts concernés ou délègue la décision ; le dépôt règle enfin l’émission de l’approbation, sa valeur dans les exigences de fusion et les chemins couverts. Une équipe peut ainsi conserver les évaluations informatives de Copilot sans lui confier le pouvoir de débloquer une fusion.
Un nouveau commit annule l’approbation précédente
L’approbation de Copilot ne reste pas attachée indéfiniment à la pull request. Lorsqu’un nouveau commit est ajouté après son examen, l’approbation est révoquée comme celle d’un réviseur humain et une nouvelle revue doit être demandée sur la version courante.
Cette révocation empêche une validation accordée sur un ancien diff de continuer à satisfaire la règle après une modification. Elle ne garantit toutefois pas que Copilot relancera spontanément son analyse : la revue des nouveaux pushes doit être activée dans le ruleset de branche, faute de quoi un membre de l’équipe devra demander une nouvelle revue.
Deux mécanismes doivent donc être distingués. Les paramètres d’approbation déterminent si Copilot possède une autorité reconnue dans la décision de fusion ; la revue après chaque push détermine si cette décision porte bien sur le dernier état du code.
La politique de branche doit suivre le niveau de risque
L’aperçu public apporte des contrôles techniques, mais ne définit pas la politique de gouvernance d’une équipe. Une approche proportionnée consiste à réserver l’approbation comptabilisée aux branches et chemins où une erreur est facilement détectable et réversible, tout en maintenant une décision humaine explicite sur les composants sensibles.
- Pour la documentation, les fichiers générés ou d’autres changements à faible impact, Copilot peut être autorisé sur une liste étroite de chemins.
- Pour le code applicatif courant, plusieurs approbations peuvent être exigées afin que celle de Copilot ne suffise pas seule. Le seuil doit être choisi en tenant compte du fait que l’approbation automatisée occupe une place dans le total.
- Pour l’authentification, les paiements, les secrets, l’infrastructure de production ou les contrôles de sécurité, une politique prudente consiste à exclure ces chemins de l’approbation comptabilisée et à exiger l’intervention d’un humain ou des propriétaires du code.
Il s’agit d’une recommandation de gouvernance, non d’une mesure de la qualité générale des revues de Copilot. Les tests obligatoires, les analyses de sécurité et les vérifications de déploiement restent des contrôles distincts : une approbation, qu’elle provienne d’un humain ou de Copilot, ne démontre pas leur réussite.
Au 7 septembre 2026, la capacité reste en aperçu public et désactivée par défaut. Copilot peut donc satisfaire une règle d’approbation, mais seulement dans le périmètre ouvert par les trois niveaux administratifs, pour des fichiers admissibles et sur la version effectivement examinée ; GitHub n’a pas encore indiqué quand cette fonction sortira de l’aperçu.
À lire aussi:
Abonnez-vous à notre newsletter
Recevez directement les dernières actualités sur le Web3, l’IA et les cryptomonnaies.