Dot.Blog

Copilot code review peut désormais exploiter des fichiers SKILL.md et des serveurs MCP en disponibilité générale. Cette évolution paraît pratique. Elle introduit surtout une nouvelle supply chain : celle du contexte qui influence la décision.

Introduction

Une revue de code automatisée était autrefois relativement simple à décrire. Un moteur analysait un diff, appliquait un ensemble de règles connues, puis produisait des diagnostics. Même lorsqu’un outil restait imparfait, son périmètre technique était identifiable : version du moteur, jeu de règles, configuration du dépôt et code analysé.

L’arrivée des grands modèles a déjà rendu cette chaîne moins déterministe. L’ajout de skills et de connexions MCP change encore davantage sa nature. La revue ne dépend plus seulement du diff et du modèle. Elle dépend aussi de fichiers d’instructions, de services externes, d’identités, de secrets, de catalogues de données et de politiques d’accès.

GitHub annonce que Copilot code review peut désormais charger des skills depuis .github/skills/**/SKILL.md et interroger des serveurs MCP configurés pour le dépôt. Les appels MCP sont limités en lecture seule et les commentaires peuvent indiquer qu’un skill ou un contexte MCP a été utilisé.

Ces garde-fous sont utiles. Ils ne suffisent pas. Le problème principal n’est pas uniquement ce que l’agent peut modifier. C’est ce qu’il peut lire, croire et utiliser pour produire une recommandation qui influencera un humain.

Ce qui change réellement

Un fichier SKILL.md peut fournir des conventions, une méthode de revue, des critères métiers ou des instructions propres à un dépôt. Un serveur MCP peut apporter des tickets, de la documentation, un catalogue de services ou d’autres informations externes.

La revue devient donc une fonction de plusieurs entrées :

    modèle
  + diff
  + historique visible
  + instructions globales
  + SKILL.md
  + contexte MCP
  + politiques GitHub
  + paramètres de session

Cette équation n’est pas mathématique, mais elle décrit correctement le problème d’architecture. Deux revues du même diff peuvent diverger si l’une des dépendances change. Une modification documentaire dans un skill peut avoir autant d’effet qu’une nouvelle version d’un analyseur. Une panne ou une donnée périmée dans un service MCP peut modifier l’interprétation d’une pull request.

Le contexte devient donc une dépendance de production.

Le mode lecture seule ne résout qu’une partie du problème

GitHub limite les appels MCP de Copilot code review à des opérations en lecture seule. C’est une décision saine : une revue ne devrait pas modifier silencieusement un ticket, un dépôt ou un service externe.

Mais « lecture seule » ne signifie pas « sans risque ».

Un outil de lecture peut exposer des informations auxquelles le workflow de revue ne devrait pas accéder. Il peut fournir des données erronées, obsolètes ou volontairement manipulées. Il peut également augmenter fortement le volume de contexte et diluer les instructions importantes.

Les risques principaux sont les suivants :

La frontière de sécurité ne peut donc pas être résumée au verbe HTTP ou à l’absence d’écriture.

SKILL.md doit être traité comme du code

Un skill n’est pas une simple note destinée à l’équipe. Il modifie le comportement d’un système de décision. Il doit donc suivre un cycle de vie explicite.

Versionner et relire

Le fichier doit être versionné, revu par des propriétaires identifiés et associé à une justification. Une modification telle que « ignorer les avertissements de performance pour les composants legacy » peut sembler anodine, mais elle change la politique de revue.

Tester sur un corpus connu

Une équipe devrait conserver un jeu de pull requests représentatives :

• défaut de sécurité connu ;
• violation architecturale ;
• régression de performance ;
• faux positif classique ;
• changement acceptable mais atypique ;
• code généré ;
• migration technique volumineuse.

Chaque version du skill doit être exécutée sur ce corpus. L’objectif n’est pas d’obtenir une réponse textuelle identique (ce qui serait irréaliste), mais de vérifier des propriétés mesurables : détection attendue, absence de blocage abusif, qualité des justifications et stabilité générale.

Définir un contrat

Un skill utile devrait préciser :

• son objectif ;
• son périmètre ;
• ce qu’il ne doit pas faire ;
• les sources autorisées ;
• les catégories de diagnostics attendues ;
• la conduite à tenir en cas d’information manquante ;
• les limites connues ;
• sa version.

Par exemple :

Vérifier le respect des frontières de la Clean Architecture.

# Interdictions
- Ne pas recommander une nouvelle dépendance sans justification.
- Ne pas présenter une convention interne comme une règle du framework.
- Ne pas bloquer une pull request sur une préférence de style.

# Mode dégradé
Si le catalogue d’architecture MCP est indisponible, signaler que la vérification métier n’a pas pu être effectuée.

Ce contrat ne rend pas le modèle déterministe. Il rend les attentes auditables.

MCP introduit une gestion d’identités

Une connexion MCP n’est pas seulement une URL. Elle suppose une identité, des permissions, un secret, une politique de rotation et un périmètre de données.

La bonne question n’est pas : « Le serveur est-il en lecture seule ? » La bonne question est : « Que peut lire exactement l’identité utilisée par la revue, dans quel contexte, avec quelle traçabilité et pendant combien de temps ? »

Pour un dépôt donné, l’identité devrait disposer du minimum nécessaire. Une revue d’un service de facturation n’a probablement pas besoin de lire l’intégralité des tickets RH, des incidents de production ou des documents commerciaux.

Les secrets doivent être séparés des fichiers de configuration, rotatifs et révocables. Les journaux doivent permettre d’identifier quel serveur a été interrogé, avec quel outil, à quel moment et pour quelle pull request.

La provenance visible est nécessaire, mais insuffisante

GitHub indique désormais lorsqu’un commentaire a été produit avec l’aide d’un skill ou d’un contexte MCP. C’est un progrès important : l’utilisateur sait qu’un élément externe a influencé la revue.

Mais l’attribution ne répond pas à toutes les questions :

• quelle version du skill a été utilisée ?
• quel outil MCP précis a été appelé ?
• quelles données ont été retournées ?
• quelles informations ont été ignorées ?
• la réponse aurait-elle été différente sans cette source ?
• le contexte a-t-il été tronqué ?

Une provenance utile doit permettre de reproduire ou au moins d’expliquer l’exécution. L’étiquette « généré avec MCP » est comparable à « compilé avec des dépendances » : elle indique une catégorie, pas la composition exacte.

À terme, les organisations auront besoin d’un manifeste de contexte agentique : versions des skills, serveurs, outils autorisés, identités, modèles, paramètres et politiques appliquées.

Mesurer avant de généraliser

L’éditeur affirme que ces mécanismes permettent d’intégrer les standards et outils internes dans chaque revue. C’est plausible. Ce n’est pas une preuve de valeur.

Une expérimentation sérieuse doit mesurer au minimum :

Il faut également comparer la solution à une référence : analyse statique, règles de dépôt, tests architecturaux ou revue humaine ciblée. Sans comparaison, l’équipe ne sait pas si elle a amélioré la qualité ou simplement ajouté du texte.

Concevoir un mode dégradé

Un système de revue connecté à plusieurs services finira par rencontrer une panne. La question n’est pas de savoir si cela arrivera, mais comment la revue se comportera.

Trois stratégies sont possibles :

1. Échec fermé : la revue est bloquée si une source essentielle manque.
2. Échec ouvert : la revue continue sans signaler l’absence.
3. Dégradation explicite : la revue continue, mais indique les contrôles non effectués.

La troisième stratégie est généralement la plus exploitable pour une revue assistée. Elle évite de bloquer toutes les pull requests tout en empêchant l’illusion d’une vérification complète.

Un commentaire synthétique peut suffire :

Le catalogue d’architecture n’a pas pu être interrogé. Les règles de dépendances métier n’ont pas été vérifiées. Les autres contrôles ont été exécutés.

Cette transparence est plus importante qu’un score global trompeur.

Une architecture minimale de gouvernance

Une mise en production raisonnable devrait comporter :

• un dépôt ou répertoire dédié aux skills ;
• des propriétaires et revues obligatoires ;
• une validation syntaxique et des tests de comportement ;
• un inventaire des serveurs MCP ;
• des identités à privilèges minimaux ;
• une rotation des secrets ;
• une journalisation des appels ;
• des seuils de coût et de latence ;
• un mode dégradé documenté ;
• une procédure de désactivation rapide ;
• un tableau de bord de qualité.

Cette architecture peut sembler lourde pour une fonctionnalité de revue. C’est précisément le point : dès qu’un outil influence régulièrement les décisions de fusion, il entre dans la chaîne de production.

Prise de position

Les skills et MCP peuvent rendre une revue plus pertinente parce qu’ils apportent le contexte absent du modèle. Mais ils déplacent le problème. L’équipe ne gère plus seulement un modèle imparfait ; elle gère un système distribué de contexte imparfait.

Le bénéfice potentiel est réel : règles métier plus précises, meilleure connaissance du dépôt, liens avec les tickets et les catalogues internes. Le risque est tout aussi réel : permissions trop larges, contexte hostile, dépendances indisponibles et résultats impossibles à reproduire.

La bonne approche n’est donc ni le rejet, ni l’activation généralisée.

Il faut commencer par un périmètre étroit, un corpus de tests, une identité minimale, des sources maîtrisées et des mesures. Un skill doit être traité comme une règle d’analyse. Un serveur MCP doit être traité comme une dépendance externe. Une revue agentique doit être traitée comme un composant de production.

Conclusion

La disponibilité générale des skills et MCP dans Copilot code review marque une évolution importante. Le système de revue peut désormais intégrer des connaissances et outils propres à l’organisation. Mais cette puissance rend la configuration beaucoup plus critique.

Le fichier SKILL.md, le serveur MCP, son identité, ses données et ses versions forment ensemble une supply chain de contexte. Tant que cette chaîne n’est pas testée, observée et gouvernée, la qualité apparente de la revue peut masquer une fragilité architecturale.

La question utile n’est pas : « Copilot comprend-il mieux notre code ? » La question utile est : « Pouvons-nous expliquer, reproduire et sécuriser le contexte qui lui permet de le juger ? »

Stay Tuned !