GitHub rend la revue de code Copilot gérable par les API REST et GraphQL et son aperçu plus compact : paramètres d'entreprise, d'organisation et de dépôt lisibles et modifiables, mais les points d'accès d'entreprise et d'organisation refusent GitHub Apps et jetons à granularité fine, et effort maximal, facturation et approbations restent hors API

Le 6 novembre 2026, GitHub a publié une entrée de journal des modifications intitulée Copilot code review: API management and review overview updates (revue de code Copilot : gestion par API et mises à jour de l'aperçu de revue). Elle dit que les paramètres de la revue de code Copilot peuvent désormais être gérés par les API REST et GraphQL, de la politique d'entreprise jusqu'à chaque dépôt, et que le commentaire d'aperçu que Copilot publie sur une demande de tirage est maintenant plus compact. L'entrée précise que les mises à jour sont disponibles pour les offres Copilot Pro, Pro+, Max, Business et Enterprise. Elle ne dit pas si une partie est en préversion et n'indique aucun changement de prix. C'est un journal de modifications du fournisseur, et nous n'avons pas testé les points d'accès.

Avant ce changement, l'API REST permettait déjà de demander une revue, de choisir son niveau d'effort et de relire des informations. L'entrée ajoute trois choses. D'abord, des champs d'attribution explicites identifient les revues et les commentaires de Copilot. Ensuite, une réponse indique l'effort de revue utilisé, quand cette métadonnée est disponible. Enfin, elle liste les compétences, serveurs MCP et instructions personnalisées que Copilot a signalés comme sources d'un commentaire. L'expression « signalés comme » compte : ces champs décrivent ce que Copilot dit avoir utilisé, et l'entrée ne prétend pas offrir de moyen de le vérifier. Pour les équipes qui auditent les commentaires de revue produits par l'IA, ces champs aident à distinguer la production de Copilot des commentaires humains et à voir ce qui a façonné un constat.

La partie sur les paramètres suit les trois niveaux d'administration de GitHub. Les administrateurs d'entreprise peuvent activer ou désactiver la revue de code pour toutes les organisations, ou laisser le choix aux administrateurs d'organisation. Les administrateurs d'organisation peuvent gérer l'activation, l'effort de revue par défaut et la configuration des exécuteurs, mais ne peuvent pas passer outre un paramètre géré par l'entreprise. Les administrateurs de dépôt peuvent gérer l'effort de revue et l'utilisation par les revues d'instructions personnalisées et d'outils MCP. L'API REST accepte les mêmes niveaux d'effort que l'interface web, et les réponses sur les paramètres listent les niveaux disponibles pour l'appelant. Dans la documentation de GitHub, les niveaux sont Lite, une revue standard, Balanced, qui examine plus en profondeur la logique complexe, le code sensible pour la sécurité et les changements entre services et qui est la valeur par défaut intégrée, et Max, qui emploie plusieurs modèles à raisonnement poussé pour la revue la plus intensive.

L'entrée contient un avertissement d'authentification facile à manquer. Les points d'accès de paramètres d'entreprise et d'organisation, y compris celui des exécuteurs d'organisation, ne prennent pas en charge les GitHub Apps ni les jetons d'accès personnels à granularité fine. Les points d'accès de paramètres de dépôt prennent en charge les deux, avec l'autorisation Administration en lecture pour lire les paramètres et en écriture pour les modifier. Les jetons d'accès personnels classiques exigent un accès d'administrateur du dépôt. Une automatisation construite comme GitHub App peut donc gérer des dépôts mais pas la politique d'organisation ou d'entreprise. La documentation précise aussi que d'autres paramètres de la page de configuration, comme l'effort de revue maximal, la facturation et les approbations, ne sont pas disponibles par l'API.

Le commentaire d'aperçu de revue change aussi. Les nouveaux aperçus regroupent les constats en haut. L'effort de revue utilisé et les éventuelles enquêtes passent dans un pied de page compact. Les fichiers ignorés et ceux exclus pour des raisons de contenu partagent une section appelée Files not reviewed, avec les noms de fichiers et des motifs reliés par des liens. Les sections vides sont omises, et les longues listes affichent un compteur de dépassement. Un pouce vers le bas sur un aperçu permet maintenant d'ajouter un motif, comme une évaluation d'approbation avec laquelle on n'est pas d'accord, un commentaire trop verbeux ou des constats incorrects ou tatillons.

Parmi les autres améliorations : les crédits d'IA consommés sont affichés dans les sessions d'agent de revue de code Copilot ; la règle de dépôt Automatically request Copilot code review accepte une liste de contournement, de sorte que les acteurs exemptés ne reçoivent pas de revue automatique ; lors des revues suivantes d'une même demande de tirage, les constats sans rapport avec les changements récents sont repliés puis masqués ; et les revues d'effort Balanced utilisent maintenant trois modèles de relecture, un autre modèle combinant leurs constats. Les corrections conservent les paramètres de facturation et de préversion quand on désactive puis réactive la revue de code, relancent une fois une revue échouée ou expirée et basculent vers un autre modèle éligible quand le modèle préféré est indisponible, permettent de nouveau à GitHub Actions, Dependabot et aux applications de l'organisation de demander des revues sur les demandes de tirage créées par des robots quand le paramètre qui bloque les revues demandées avec une licence Copilot externe est activé et que l'organisation paie, et suppriment les faux rapports d'échec juste après le début d'une revue.

La documentation de GitHub ajoute une règle sur les revues automatiques. Une demande de tirage peut y être éligible par plusieurs sources indépendantes, à savoir les paramètres de l'utilisateur, les ensembles de règles du dépôt et ceux de l'organisation. Ils sont évalués séparément, Copilot ne publie toujours qu'une seule revue, et les paramètres d'un utilisateur ne peuvent pas désactiver les revues sur push ou sur brouillon qu'un ensemble de règles a activées.

Notre lecture : ce qui est utile pour les administrateurs, c'est la politique en tant que code. Les équipes peuvent maintenant scripter les paramètres d'entreprise, d'organisation et de dépôt et attribuer les commentaires, au lieu de cliquer de page en page. Les limites sont claires. La règle d'authentification empêche l'automatisation par GitHub App pour les deux niveaux supérieurs, des contrôles clés restent hors de l'API, les champs de sources sont déclarés par Copilot lui-même, et l'entrée ne donne aucun chiffre sur la qualité des revues. Il vaut mieux tester d'abord les points d'accès sur un petit dépôt.