Revue de code par Copilot : écrire des instructions qu'il suit vraiment

Copilot peut relire une pull request et commenter le code. Sans consigne, il applique des critères généraux. Avec des fichiers d'instructions placés dans le dépôt, il vérifie ce qui compte pour votre équipe. Le tutoriel publié par GitHub explique comment les écrire, et où se trouvent les limites.

Trois types de fichiers

• .github/copilot-instructions.md : les règles valables pour tout le dépôt.
• .github/instructions/*.instructions.md : des règles limitées à certains chemins.
• AGENTS.md à la racine : des instructions d'agent au niveau du dépôt, que la revue lit aussi.

Les fichiers par chemin commencent par un en-tête qui indique leur périmètre :

---
applyTo: "**/*.py"
---

Les règles Python ne s'appliquent alors qu'aux fichiers Python. C'est le moyen conseillé pour éviter que des consignes de langage débordent sur des fichiers sans rapport.

La structure recommandée

GitHub propose un plan simple pour chaque fichier : un titre, l'objectif, les conventions de nommage, le style de code avec un exemple, la gestion des erreurs, la sécurité, les tests, les performances. La forme compte autant que le fond :

• des titres et des listes à puces plutôt que de longs paragraphes ;
• des consignes courtes, à l'impératif ;
• des exemples de code qui montrent la mauvaise et la bonne façon de faire.

Deux repères chiffrés figurent dans le tutoriel : commencer avec 10 à 20 instructions précises, et ne pas dépasser environ 1 000 lignes par fichier, seuil au-delà duquel la qualité des réponses peut baisser.

Ce que les instructions ne peuvent pas faire

C'est la partie la plus utile du document. La revue de code de Copilot ne tient pas compte des consignes qui cherchent à :

• changer la mise en forme de ses commentaires ;
• modifier le commentaire de synthèse de la pull request ;
• lui faire bloquer une fusion ou produire un journal des modifications ;
• lui faire suivre un lien externe : il faut recopier le contenu utile dans le fichier ;
• améliorer sa qualité par des formules vagues, du type « ne rate aucun problème ».

Tester sur la branche elle-même

Un détail pratique : Copilot lit les instructions sur la branche qui contient les modifications, pas sur la branche de destination. On peut donc modifier un fichier d'instructions et constater l'effet dans la même pull request.

La méthode conseillée tient en quatre temps : ouvrir une pull request, demander une revue à Copilot, noter les consignes suivies et celles ignorées, puis ajouter ou corriger les instructions une par une ou par petits groupes.

Si des consignes sont ignorées, le tutoriel suggère de raccourcir le fichier, de préciser les formulations et de supprimer les contradictions. Il prévient aussi qu'une part de variation d'une revue à l'autre est normale.

Les limites

Le tutoriel ne donne aucune mesure d'efficacité : rien n'indique quelle part des consignes est suivie en pratique. La variation reconnue par GitHub signifie qu'une règle écrite n'est pas une règle garantie. Et comme les instructions sont lues sur la branche de travail, la personne qui ouvre la pull request peut les modifier : un point à surveiller si vous comptez sur elles pour un contrôle de sécurité.

Notre lecture

Pour une petite équipe, l'exercice vaut une heure de travail : un fichier général court, centré sur la sécurité et les erreurs que vous corrigez déjà à la main en relecture, puis un fichier par langage principal. Tout ce qui peut être vérifié mécaniquement, comme le formatage ou les conventions de nommage, reste mieux servi par un linter. La revue par IA complète la relecture humaine et les contrôles automatiques ; d'après la documentation elle-même, elle ne sait pas bloquer une fusion.