Jusqu’ici, Copilot intervenait surtout comme assistant de revue : il lisait les modifications, signalait des problèmes possibles et formulait des remarques. GitHub lui donne désormais un rôle plus formel. Dans une préversion publique annoncée le 1er septembre, un administrateur peut autoriser Copilot à approuver une pull request et décider que cette approbation compte parmi celles exigées avant la fusion.
La fonction est désactivée par défaut. Son activation peut être encadrée au niveau de l’entreprise, de l’organisation et du dépôt, puis limitée à certains chemins de fichiers.
Ce changement mérite donc d’être regardé autrement qu’une simple amélioration de Copilot code review. Dès lors qu’une approbation de Copilot peut satisfaire une règle de protection de branche, l’IA participe directement au mécanisme qui autorise l’entrée du code dans la branche principale.
Ce que GitHub autorise désormais
Chaque revue Copilot comprend maintenant une appréciation indiquant si la modification paraît prête à être approuvée. Cette appréciation reste informative : seule, elle ne satisfait aucune exigence de fusion.
Lorsque l’option d’approbation est activée, Copilot peut en revanche déposer une véritable approbation. GitHub peut alors la compter parmi les approbations obligatoires définies par le dépôt.
La décision est hiérarchisée. Au niveau de l’entreprise, la fonction peut rester bloquée ou être ouverte à certaines organisations. Une organisation peut ensuite l’autoriser partout, sur une sélection de dépôts ou laisser chaque dépôt décider. Enfin, l’administrateur du dépôt choisit si Copilot peut approuver et si cette approbation a effectivement une valeur dans les règles de fusion.
L’intérêt de ce mécanisme est précisément que l’activation de la revue Copilot ne suffit pas à lui donner automatiquement un pouvoir d’approbation.
Les chemins de fichiers définissent où l’approbation a du poids
GitHub permet de limiter les approbations Copilot à certaines parties du dépôt. Un administrateur peut définir jusqu’à 15 motifs de fichiers. Pour qu’une approbation soit prise en compte dans les règles de fusion, tous les fichiers modifiés doivent correspondre à l’un des motifs autorisés.
Cette granularité permet de traiter différemment les zones du code selon leur niveau de risque. Une équipe peut, par exemple, accepter une approbation Copilot pour de la documentation générée, certaines configurations ou des composants de maintenance, tout en conservant une revue humaine obligatoire pour l’authentification, les paiements, l’infrastructure ou les contrôles de sécurité.
Ce réglage n’est donc pas une simple préférence de l’outil : il détermine dans quelles parties du dépôt l’avis de Copilot peut réellement contribuer à autoriser une fusion.
Une modification du code annule l’approbation précédente
GitHub applique aussi une règle de fraîcheur. Si de nouveaux commits sont ajoutés après l’approbation de Copilot, celle-ci est annulée. Une nouvelle revue doit être demandée pour l’état actuel du code.
Le principe est le même que pour une revue humaine devenue obsolète après une modification. L’important n’est pas qu’une pull request ait été approuvée à un moment donné, mais que la version actuellement proposée ait bien fait l’objet de la revue correspondante.
Dans les équipes où la revue est relancée automatiquement après chaque push, cette logique peut devenir une barrière continue. Elle ne remplace toutefois pas la question du niveau d’assurance attendu : plus la chaîne revue, approbation et fusion est automatisée, plus il devient important de conserver une vérification indépendante pour les composants sensibles.
Une approbation obligatoire ne signifie plus forcément la même chose
La documentation de GitHub reste prudente sur les capacités de Copilot. Elle précise que l’outil peut manquer certains problèmes, qu’il peut se tromper et que ses observations doivent être vérifiées et complétées par une revue humaine.
Dans le même temps, GitHub permet désormais à une organisation de faire compter l’approbation de Copilot dans les règles obligatoires avant fusion.
C’est là que le modèle de contrôle change. Une règle telle que « une approbation requise » sert souvent de raccourci pour garantir qu’un autre regard a été porté sur la modification. Si cette approbation peut être fournie par Copilot, la règle reste satisfaite techniquement, mais elle ne garantit plus à elle seule le même type d’examen indépendant.
Pour la gouvernance, il devient donc nécessaire de savoir qui a approuvé, et pas seulement combien d’approbations ont été enregistrées.
La question est encore plus sensible lorsque le code lui-même a été produit par un autre agent d’IA. Une chaîne dans laquelle un agent écrit la modification et Copilot l’approuve sans intervention humaine peut conduire à une autorisation entièrement automatisée.
Donner à Copilot un périmètre explicite
Une approche plus solide consiste à considérer Copilot comme un relecteur automatisé doté de droits limités.
Un dépôt peut, par exemple, autoriser Copilot à commenter sans pouvoir approuver, lui permettre d’approuver sans que cette approbation compte pour la fusion, ou accepter son approbation uniquement sur certains dépôts et chemins à faible risque.
Pour les zones sensibles, une barrière indépendante peut rester obligatoire : approbation d’un autre développeur, intervention d’un propriétaire de code via CODEOWNERS, ou contrôle technique distinct que Copilot ne peut pas satisfaire seul.
Les équipes devraient également préciser quand une nouvelle revue doit être déclenchée, quelles traces sont conservées pour l’audit et si une modification générée par une IA peut être approuvée sans intervention humaine.
Une préversion à traiter comme telle
Les approbations Copilot sont encore en préversion publique et GitHub indique que la fonction peut évoluer. Les entreprises ont donc intérêt à éviter d’inscrire trop vite ce comportement dans des politiques difficiles à modifier.
La direction prise par GitHub est néanmoins claire : Copilot ne se contente plus d’éclairer la décision de revue. Avec l’autorisation des administrateurs, il peut désormais participer au mécanisme formel qui permet au code d’être fusionné.
La bonne question n’est donc plus seulement de savoir si Copilot sait approuver une pull request, mais de définir précisément où cette approbation doit avoir de l’autorité et quelles garanties indépendantes doivent rester obligatoires.