Le 1er septembre 2026, GitHub a annoncé en préversion publique que Copilot Code Review pouvait non seulement indiquer qu’une pull request lui semblait prête, mais aussi soumettre une approbation comptant dans les règles de fusion lorsqu’un administrateur active cette capacité. La fonction est désactivée par défaut et configurable aux niveaux entreprise, organisation et dépôt, avec une restriction possible par chemins de fichiers. Cette évolution peut accélérer les changements routiniers ; elle modifie surtout la frontière de confiance de la chaîne de livraison.
À retenir : l’avis d’un agent peut compléter une revue, mais il ne doit jamais devenir l’unique contrôle d’une modification sensible, ni approuver un changement produit par la même chaîne sans validation indépendante. La branche protégée, les tests, CODEOWNERS, la séparation des rôles et la traçabilité restent les garde-fous principaux.
1. Distinguer évaluation et approbation
GitHub introduit deux comportements différents. Toutes les revues Copilot peuvent inclure une évaluation indiquant si la pull request paraît prête à être approuvée. Cette indication apparaît dans le commentaire de synthèse mais ne satisfait pas les exigences de fusion.
Lorsque l’option est activée, Copilot peut soumettre une véritable approbation. Celle-ci peut compter dans le nombre d’approbations exigé par la règle de protection. Si de nouveaux commits sont poussés après l’approbation, GitHub indique qu’elle est révoquée comme celle d’un reviewer humain et qu’une nouvelle revue doit être demandée.
Cette distinction doit rester visible dans l’interface et dans les procédures. Un développeur ne doit pas confondre « le modèle n’a pas trouvé de problème bloquant » avec « le changement est autorisé à entrer en production ». La première phrase décrit un signal. La seconde engage une responsabilité et participe à une décision de contrôle.
Dans un premier temps, l’évaluation non comptabilisée peut être activée largement pour mesurer la pertinence du signal. L’approbation effective doit rester limitée aux dépôts et chemins dont le risque a été évalué.
2. Pourquoi l’approbation est un pouvoir, pas un commentaire
Une revue de code produit des remarques. Une approbation modifie l’état de la pull request et peut débloquer une fusion automatique. Elle constitue donc un appel d’outil à conséquence, comparable à l’ajout d’un label de déploiement ou à la validation d’un changement d’infrastructure.
La question centrale n’est pas « Copilot sait-il détecter des défauts ? ». Elle est : dans quelles conditions son jugement peut-il remplacer une partie du contrôle obligatoire ? Un reviewer humain connaît parfois l’objectif métier, l’historique du composant, une contrainte client ou une dépendance opérationnelle qui n’apparaît pas dans le diff.
Le modèle peut également être influencé par le contenu du dépôt : commentaires, documentation, noms de fichiers ou instructions intégrées. Même lorsque la plateforme applique des protections, les données analysées restent une entrée non fiable. Une règle importante ne doit pas dépendre uniquement d’un système probabiliste qui lit le changement qu’il doit autoriser.
Il faut enfin considérer les défaillances corrélées. Si le même fournisseur, le même modèle ou la même instruction génère le code puis l’approuve, les deux étapes peuvent partager les mêmes angles morts. Multiplier les agents ne crée pas automatiquement de l’indépendance.
3. Préserver la séparation des responsabilités
Le principe minimal est le suivant : un changement ne doit pas être créé et approuvé par la même identité logique sans autre contrôle indépendant. Si Copilot ou un agent ouvre la pull request, son approbation ne doit pas suffire à la fusion.
Cette règle peut être appliquée par provenance. Ajoutez aux pull requests un attribut indiquant si le changement est humain, assisté ou généré par un agent. Les règles de fusion exigent alors une validation humaine pour les contributions agentiques, même si une revue Copilot est présente.
Pour les changements humains simples, Copilot peut fournir une approbation complémentaire. L’organisation peut décider qu’elle compte comme l’une de deux approbations, mais pas comme la dernière approbation sur un composant critique. Un CODEOWNER demeure responsable du périmètre.
Séparez également les configurations. Le compte qui gère les règles d’approbation ne doit pas être modifiable par le workflow évalué. Les changements de paramètres d’entreprise, de protection de branche et de fichiers de politique passent par un groupe restreint et une revue humaine.
Enfin, l’identité de Copilot doit être explicite dans l’historique. Une approbation automatisée ne doit pas apparaître comme celle d’un membre d’équipe. L’audit doit permettre de retrouver le modèle, la version de la fonction, la date, les commits examinés et les contrôles disponibles au moment de la décision.
4. Définir les chemins que l’IA ne peut pas approuver seule
GitHub permet aux administrateurs de choisir les chemins que Copilot est autorisé à approuver. Cette capacité doit être utilisée comme une liste positive : l’approbation n’est valable que sur les zones explicitement considérées comme peu risquées.
Peuvent entrer dans un premier périmètre des modifications documentaires, exemples, traductions, tests sans changement de production, dépendances de développement ou correctifs répétitifs dans un composant bien couvert. Même dans ces zones, les tests et les limites de volume restent nécessaires.
Excluez au minimum :
- fichiers de secrets, identités et permissions ;
- workflows CI/CD, scripts de déploiement et infrastructure ;
- migrations de base de données et schémas ;
- code d’authentification, paiement, chiffrement ou contrôle d’accès ;
- politiques de sécurité, CODEOWNERS et protections ;
- dépendances de production et fichiers de verrouillage lorsque leur impact n’est pas analysé ;
- code réglementé ou soumis à une validation contractuelle ;
- modifications massives, générées ou difficiles à relire.
La sensibilité ne dépend pas seulement du chemin. Une documentation peut contenir une commande opérationnelle dangereuse ; un test peut désactiver une assertion. Ajoutez des règles sur la taille du diff, le type de fichier, les permissions modifiées et la présence de marqueurs de risque.
Les chemins doivent être révisés à chaque évolution d’architecture. Un dossier autrefois statique peut devenir une source de configuration active.
5. Renforcer les protections de branche et la CI
L’approbation Copilot ne doit pas contourner les contrôles existants. Exigez une branche à jour, des statuts CI obligatoires, l’absence de conversation non résolue, la signature des commits lorsque la politique le prévoit et la révocation des approbations après modification.
Les tests doivent couvrir plus que la syntaxe. Ajoutez analyse statique, dépendances, secrets, migrations, contrats d’API, permissions et tests de sécurité adaptés au composant. Une revue IA peut commenter une intention ; la CI fournit des preuves reproductibles.
Utilisez un merge queue pour éviter qu’une approbation valide un état différent de celui réellement intégré. La file rejoue les contrôles sur la combinaison finale des changements et limite les conflits entre pull requests approuvées séparément.
Pour les dépôts à fort impact, exigez un environnement de préproduction ou une validation de déploiement distincte. Le code peut être correct localement et produire un effet inattendu sur les données, la configuration ou l’observabilité.
Ne donnez pas à l’agent la capacité de modifier les tests obligatoires dans le même parcours qu’il approuve. Lorsqu’un changement touche la CI, la politique ou les jeux d’évaluation, une revue humaine spécifique s’impose.
6. Évaluer la qualité de la revue avant l’activation
Commencez par observer les évaluations non comptabilisées. Sur plusieurs semaines, comparez le jugement de Copilot au résultat des reviewers humains, aux incidents après fusion et aux retours de production.
Construisez un jeu de pull requests historiques comprenant des défauts connus : bug logique, contrôle d’accès manquant, migration risquée, concurrence, rupture de compatibilité, fuite de donnée, test affaibli et changement documentaire légitime. Mesurez ce que Copilot détecte, ce qu’il laisse passer et ce qu’il bloque à tort.
Les métriques utiles sont le rappel sur les défauts critiques, le taux de faux sentiment de sécurité, le nombre de commentaires actionnables, le temps de revue et le taux de désaccord humain. Un taux global d’accord peut être élevé tout en masquant les rares erreurs les plus graves.
Testez aussi la robustesse : instruction contradictoire dans le dépôt, diff très volumineux, code généré, renommage massif, sous-module et fichier binaire. Vérifiez que le système s’abstient lorsque le contexte est incomplet ou la pull request hors de son périmètre.
Rejouez l’évaluation après chaque changement important de modèle ou de fonctionnalité. Une préversion publique évolue ; un résultat obtenu en septembre 2026 ne garantit pas le même comportement plusieurs mois plus tard.
7. Déployer par paliers et prévoir le retour arrière
Le premier palier est informatif : Copilot commente et publie son évaluation, sans compter dans les règles. Le deuxième autorise l’approbation sur un dépôt de faible risque, mais exige toujours une approbation humaine. Le troisième permet à l’approbation de satisfaire une règle uniquement pour une liste de chemins et de changements très limitée.
N’activez pas globalement au niveau entreprise avant d’avoir observé le comportement par type de dépôt. Utilisez la hiérarchie des paramètres pour laisser les organisations ou dépôts rejoindre le pilote explicitement.
Définissez des seuils d’arrêt : défaut critique non détecté, taux de faux positifs trop élevé, divergence avec les reviewers, changement non documenté de comportement ou incident après fusion. La désactivation doit être immédiate et ne pas nécessiter de modifier chaque dépôt individuellement.
Conservez l’historique des décisions. Lorsqu’une équipe élargit les chemins autorisés, elle fournit les résultats d’évaluation et le propriétaire du risque. L’autorisation expire automatiquement si elle n’est pas revue.
Après le déploiement, échantillonnez des pull requests approuvées par Copilot et réalisez une revue a posteriori. L’absence d’incident visible ne prouve pas l’absence de défaut ; le contrôle continu évite que la fonction devienne un automatisme oublié.
8. Une politique de référence pour les organisations
Une politique simple peut être formulée ainsi :
- l’évaluation Copilot est un signal consultatif par défaut ;
- l’approbation effective est désactivée au niveau entreprise, sauf délégation explicite ;
- seuls les dépôts inscrits au pilote peuvent l’activer ;
- les chemins autorisés sont définis positivement ;
- les contributions agentiques exigent toujours une approbation humaine ;
- les fichiers sensibles et changements de politique sont exclus ;
- les statuts CI et CODEOWNERS restent obligatoires ;
- tout nouveau commit révoque la décision et déclenche une nouvelle revue ;
- le comportement est évalué et audité périodiquement ;
- un mécanisme central permet la désactivation immédiate.
Cette politique doit être accompagnée d’exemples, car les équipes doivent comprendre ce qui constitue un changement simple ou sensible. Elle doit également préciser que l’approbation technique ne remplace pas la validation produit, juridique ou sécurité requise par certains projets.
Le retour d’expérience sur Asana et l’utilisation de Codex pour une migration de dette technique rappelle l’importance d’une forte couverture de tests et d’une revue humaine de chaque modification, même lorsque les agents accélèrent considérablement le travail.
Conclusion
La possibilité pour Copilot d’approuver une pull request peut réduire la latence des changements routiniers, mais elle confère à un système probabiliste un rôle dans la décision de fusion. Ce rôle doit être traité comme une délégation de pouvoir et non comme un simple commentaire enrichi.
Le cadre robuste repose sur des chemins autorisés, une séparation entre auteur et approbateur, des protections de branche, une CI indépendante, des CODEOWNERS, des évaluations locales et un déploiement progressif. Partitech accompagne les équipes dans la conception de ces politiques, l’automatisation GitHub et l’intégration des agents de développement sans affaiblir la maîtrise de la livraison.
Références vérifiées le 3 septembre 2026
- GitHub — « Copilot code review can now approve pull requests », 1er septembre 2026 : https://github.blog/changelog/2026-09-01-copilot-code-review-can-now-approve-pull-requests/
- GitHub Documentation — protection des branches et règles de pull request : https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository
- GitHub Documentation — CODEOWNERS : https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners