GitHub ouvre la gestion de Copilot Code Review par API à trois niveaux

Lorsque l’entreprise compte des dizaines d’organisations et des centaines de dépôts, configurer manuellement les revues par IA tourne vite à la loterie. Dans un projet, Copilot examine chaque pull request ; dans un autre, il est désactivé ; dans un troisième, il utilise un serveur MCP dont l’équipe de sécurité ignore tout. GitHub vient combler cette lacune : les paramètres de Copilot Code Review peuvent désormais être gérés via les API REST et GraphQL à trois niveaux — entreprise, organisation et dépôt individuel.

L’intérêt pratique est simple : la politique de revue peut être stockée sous forme de code, contrôlée automatiquement et déployée d’un seul coup dans tout l’environnement. La mise à jour est disponible avec les offres Copilot Pro, Pro+, Max, Business et Enterprise.

Fonctionnement de la hiérarchie des paramètres

L’administrateur de l’entreprise décide si Copilot Code Review est autorisé dans toutes les organisations ou si chacune peut choisir elle-même. Lorsqu’un paramètre est imposé au niveau supérieur, il ne peut pas être remplacé à un niveau inférieur.

Au niveau de l’organisation, il est possible d’activer les revues, de définir le niveau d’analyse par défaut et de gérer la configuration du runner. L’administrateur du dépôt dispose d’un éventail plus restreint de commandes : il choisit le niveau d’analyse et autorise ou interdit l’utilisation d’instructions personnalisées et d’outils MCP.

Imaginons une entreprise comptant cinquante dépôts. Le service de sécurité interdit les serveurs MCP externes, l’équipe plateforme active par défaut un mode de revue équilibré et les responsables des services critiques optent pour une analyse plus approfondie. Auparavant, il fallait maintenir ce dispositif au moyen de l’interface et de consignes internes. Il est maintenant possible de le décrire dans un script, de comparer l’état souhaité à l’état réel et de corriger les écarts via l’API.

Ce que l’API permet désormais d’obtenir

GitHub a ajouté des champs explicites permettant de distinguer les revues et commentaires de Copilot des messages publiés par des humains ou d’autres applications. L’API peut également renvoyer le niveau d’analyse utilisé et préciser les compétences, serveurs MCP et instructions personnalisées que Copilot a désignés comme sources d’une remarque donnée.

C’est plus important qu’il n’y paraît. Une équipe peut collecter automatiquement les remarques issues des revues par IA, calculer la part des recommandations acceptées et enquêter sur un commentaire litigieux : provenait-il du modèle standard, d’une instruction interne ou d’un outil connecté ? Les sessions de l’agent indiquent désormais aussi le nombre de crédits d’IA consommés, ce qui permet de mettre en regard le coût d’une analyse et son utilité.

La synthèse de la revue est également devenue plus compacte. Les fichiers ignorés ou exclus sont regroupés dans une même section avec le motif de leur exclusion, les blocs vides sont masqués et les longues listes sont repliées. Lorsqu’il attribue une évaluation négative, l’utilisateur peut en préciser la raison : conclusion erronée, verbosité excessive ou remarque tatillonne.

Limites et conclusion pratique

L’API comporte un détail gênant. Les points de terminaison des paramètres d’entreprise et d’organisation, y compris celui de la configuration du runner, ne prennent pas en charge les GitHub Apps ni les jetons personnels à autorisations granulaires. Pour gérer un dépôt, les deux options conviennent : la lecture nécessite l’autorisation Administration: read et la modification, Administration: write. Un jeton personnel classique doit disposer d’un accès administratif au dépôt.

GitHub a également corrigé plusieurs problèmes opérationnels : une revue qui échoue ou reste bloquée est automatiquement relancée une fois et, si le modèle sélectionné est indisponible, le système peut basculer vers un autre modèle approprié. Les paramètres de facturation et des fonctionnalités en préversion sont conservés après la désactivation puis la réactivation des revues.

Pour l’équipe plateforme, l’étape suivante est évidente : exporter les paramètres actuels via l’API, définir une politique de référence et intégrer la détection des écarts au dispositif existant de gouvernance GitHub. Il ne faut toutefois pas accorder immédiatement au script des droits d’écriture. Commencez par un audit en lecture seule, vérifiez séparément l’héritage des politiques, puis automatisez les modifications. L’API rend Copilot Code Review administrable, mais la qualité de ses remarques doit toujours être mesurée sur vos propres dépôts.