Claude Skills vs instructions Copilot : le comparatif

GitHub Copilot compte plus d'utilisateurs que n'importe quel autre outil de code IA, donc son format de personnalisation est sans doute la pièce de configuration IA la plus largement déployée qui existe. Des millions de dépôts portent désormais un .github/copilot-instructions.md. Les skills Claude sont arrivés plus tard, se sont répandus vite, et résolvent un problème qui se recoupe partiellement, mais différemment. Si vous utilisez les deux outils, ou que vous décidez lequel mérite l'effort de configuration de votre équipe, les différences comptent plus que le marketing ne le suggère.

Nous faisons tourner SkillProof, où nous installons des skills Claude sur des machines vierges et les testons sur du vrai travail avant de les référencer, donc notre biais penche du côté des skills et nous le disons d'emblée. Nous avons aussi observé des centaines de fichiers d'instructions dans les deux formats réussir et échouer, et les modes d'échec se révèlent presque identiques. Ce comparatif essaie d'être juste envers les deux.

En bref

Les instructions personnalisées Copilot sont un contexte toujours actif pour le code. Les skills Claude sont une expertise à la demande pour n'importe quelle tâche. Les instructions gagnent sur la distribution en équipe et l'intégration IDE ; les skills gagnent sur la logique d'activation, les ressources embarquées, et tout ce qui n'est pas du code.

	Skills Claude	Instructions personnalisées Copilot
Mécanisme	SKILL.md avec un champ description ; Claude charge le corps quand une tâche correspond	.github/copilot-instructions.md appliqué à tout le dépôt, plus des fichiers *.instructions.md ciblés par des globs applyTo
Activation	Sémantique : le modèle fait correspondre votre requête à la description	Toujours actif (fichier du dépôt) ou correspondance de chemin (globs)
Portée	Toute tâche que Claude gère : code, documents, email, analyse	Code et surfaces Copilot : chat, revue de code, agent de codage
Portabilité	Un seul format sur Claude Code, claude.ai, desktop, API	Lié à Copilot ; support partiel variable selon l'IDE et la surface
Ressources embarquées	Scripts, modèles, fichiers de référence, chargés paresseusement	Texte markdown uniquement
Comportement en tokens	~100 tokens au repos par skill ; le corps complet se charge au déclenchement	Le fichier applicable entier s'attache à chaque requête
Écosystème	Des milliers de skills communautaires, majoritairement non testés	Surtout des fichiers privés par dépôt ; des listes émergent, non testées aussi

Si vous ne retenez qu'une phrase : les instructions décrivent votre base de code, les skills décrivent une capacité. Ce sont des rôles différents, et la plupart des équipes finissent par vouloir les deux. Pour les fondamentaux côté skills, notre guide complet des skills Claude couvre le format en profondeur. Les deux formats changent le comportement d'un modèle ; connecter un modèle à des données externes est un autre axe, couvert dans Claude Skills vs serveurs MCP.

Ce que sont vraiment les instructions personnalisées Copilot

Le cœur du système est un seul fichier : .github/copilot-instructions.md, versionné dans le dépôt. Copilot Chat le lit automatiquement et le préfixe aux requêtes de ce dépôt, dans VS Code, Visual Studio, les IDE JetBrains, et github.com. L'agent de codage le lit quand il travaille sur des tickets ; la revue de code Copilot le lit quand elle relit des pull requests. Un fichier markdown, et chaque surface Copilot qui touche au dépôt se comporte en conséquence.

En 2025, GitHub a étendu le format avec des fichiers d'instructions ciblés : .github/instructions/*.instructions.md, chacun avec un frontmatter qui cible des chemins de fichiers.

---
applyTo: "src/api/**/*.ts"
---

All API route handlers return the ApiResponse<T> envelope.
Never throw inside a handler; return err() with a typed error code.

Le glob fait exactement ce qu'il dit. Éditez un fichier sous src/api/, et ces instructions accompagnent la requête. Éditez un README, et elles ne le font pas. Il existe aussi des instructions personnelles, définies dans vos paramètres Copilot sur github.com, et des instructions d'organisation, que les administrateurs Business et Enterprise peuvent pousser à chaque membre.

Les forces ici méritent une lecture honnête, parce qu'elles sont réelles.

Les instructions sont natives du dépôt. Le fichier vit là où vit le code, et les changements passent par une revue de pull request comme n'importe quoi d'autre. Quand quelqu'un met à jour la convention de gestion d'erreurs, le diff est visible et toute l'équipe le récupère au pull. Rien dans l'écosystème Claude ne distribue la configuration d'équipe aussi proprement, sauf les skills au niveau projet dans .claude/skills/, qui empruntent la même astuce.

Le ciblage par glob est précis d'une façon que le déclenchement sémantique n'est pas. applyTo: "**/*.test.ts" se déclenche exactement sur ces fichiers, à chaque fois, sans aucune ambiguïté. Un skill Claude se déclenche quand le modèle décide que la description correspond, ce qui est flexible et occasionnellement faux. Pour des règles qui correspondent à des chemins de fichiers, le déterministe bat l'astucieux.

Et la portée est large. Le même fichier gouverne le chat en direct dans l'éditeur et les surfaces asynchrones où personne ne pilote : la revue de code et l'agent de codage. Cette intégration à la revue en particulier n'a pas d'équivalent direct côté skills.

Ce que les skills font que les instructions ne peuvent pas

La différence structurelle est l'activation. Un fichier d'instructions Copilot est toujours dans le prompt (ou mis en correspondance par chemin). Un skill repose sur disque pour un coût d'environ 100 tokens de métadonnées jusqu'à ce qu'une tâche corresponde vraiment à sa description, puis le corps complet se charge. C'est la divulgation progressive, et cela change ce que vous pouvez vous permettre d'écrire.

Un fichier d'instructions doit rester court parce que chaque ligne taxe chaque requête ; les conseils de GitHub eux-mêmes disent de rester bref, et les fichiers trop gonflés se diluent jusqu'à ce que le modèle commence à ignorer le milieu. Le corps d'un skill peut s'étendre sur des milliers de mots, plus des fichiers de référence qui ne se chargent que si nécessaire, parce que rien de tout cela ne coûte quoi que ce soit avant le moment où c'est pertinent. Notre skill de développement piloté par les tests testé porte toute une discipline red-green-refactor qu'il serait absurde d'injecter dans chaque requête ; en tant que skill, il s'active quand vous construisez une fonctionnalité et reste silencieux quand vous demandez ce que fait une regex.

Les skills embarquent aussi des choses qui ne sont pas de la prose. Un dossier de skill peut porter des scripts exécutables, des modèles de documents, des checklists, et des exemples travaillés ; le skill DOCX embarque du code qui manipule vraiment le XML de Word. Les instructions Copilot sont du texte markdown, point final. Vous pouvez décrire une procédure ; vous ne pouvez pas livrer l'outil qui l'exécute.

Puis il y a la frontière qui compte le plus pour les non-développeurs : les instructions Copilot s'arrêtent où le code s'arrête. Elles configurent un assistant de codage. Les skills Claude configurent Claude, que les gens utilisent pour des contrats, des tableurs, du cold email, des notes de réunion, et de l'analyse de données. Un skill comme Code Review Checklist recoupe le territoire Copilot, mais la moitié de notre catalogue n'a aucun équivalent Copilot même en théorie. Si votre usage de l'IA dépasse l'IDE, les fichiers d'instructions n'allaient jamais le couvrir.

Une note de format : les skills sont portables sur toutes les surfaces Claude. Le même dossier fonctionne dans Claude Code, se téléverse sur claude.ai, et s'attache aux requêtes API. Les instructions Copilot sont portables sur les surfaces Copilot, ce qui est plus étroit, même si la convergence lente de l'industrie vers AGENTS.md (que Copilot lit désormais aussi) commence à brouiller les frontières.

Ce que les instructions font que les skills ne peuvent pas

L'équité va dans les deux sens, et il y a trois tâches où les instructions Copilot sont simplement le meilleur outil.

Le contexte de revue de PR est le gros morceau. La revue de code Copilot tourne sur l'infrastructure de GitHub contre vos pull requests, et elle lit votre fichier d'instructions quand elle le fait. Écrivez « signale tout nouveau endpoint qui manque de limitation de débit » et le relecteur l'applique à chaque PR, de chaque contributeur, qu'il ait configuré quoi que ce soit localement ou non. Claude n'a pas d'équivalent hébergé qui récupère automatiquement vos skills à chaque pull request ; vous devriez le câbler vous-même via CI.

La politique à l'échelle de l'organisation est la deuxième. Un administrateur Copilot Enterprise peut définir des instructions qui atteignent chaque développeur de l'organisation sans qu'aucun d'eux n'installe quoi que ce soit. Les skills Claude s'installent par machine ou par dépôt. Pour une équipe plateforme qui essaie d'imposer « ne jamais suggérer le client d'authentification déprécié » à 400 ingénieurs, pousser depuis le sommet bat espérer que tout le monde clone les bons dotfiles.

Troisièmement, le comportement natif de l'IDE. Les instructions façonnent Copilot à l'intérieur de l'éditeur où les gens vivent déjà, sans outil séparé à adopter. La question de l'activation ne se pose jamais parce qu'il n'y a pas d'activation : le contexte est simplement là, à chaque requête. Pour des faits toujours vrais sur une base de code, toujours actif est le bon comportement, ce qui est la même raison pour laquelle Claude Code a CLAUDE.md à côté des skills. Nous avons fait l'argument parallèle dans Claude Skills vs règles Cursor : chaque outil finit par avoir besoin à la fois d'une couche toujours chargée et d'une couche à la demande, et les outils diffèrent surtout par quelle couche ils ont bien construite.

Convertir entre les deux formats

Les formats sont assez proches pour que la migration soit surtout de la réorganisation. Voici un bloc à forme réelle tiré d'un copilot-instructions.md :

## Error handling

- All service functions return Result<T, AppError>, never throw.
- Map external errors to AppError codes in the adapter layer only.
- Log with the request ID from context; never log raw error objects
  from third-party SDKs, they can contain tokens.
- New AppError codes go in errors/codes.ts with a doc comment.

En tant que skill, la même connaissance gagne une condition de déclenchement et de la place pour grandir :

---
name: error-handling-conventions
description: Applies our Result-based error handling conventions when
  writing or reviewing service code, adding error paths, or creating
  new AppError codes. Use when the user works on error handling,
  exceptions, or failure cases in the services layer.
---

# Error handling conventions

When writing or modifying service-layer code:

1. Service functions return Result<T, AppError>. Never throw from
   a service function. If you find existing code that throws,
   flag it, do not silently rewrite it.
2. Map external errors to AppError codes in the adapter layer only.
   If a service needs a new mapping, it belongs in the adapter.
3. Log with the request ID from context. Never log raw error
   objects from third-party SDKs; they can contain tokens.
4. New AppError codes go in errors/codes.ts with a doc comment
   explaining when the code fires.

For retry and timeout conventions, see [resilience.md](resilience.md).

Remarquez ce qui a changé. La description porte maintenant des phrases de déclenchement, la partie que les auteurs ratent le plus souvent ; une description vague ne se déclenche jamais. Le corps a gagné des contraintes négatives (« signale-le, ne le réécris pas silencieusement ») qu'un fichier toujours actif ne peut pas se permettre en tokens. Et la dernière ligne pointe vers un fichier de référence qui ne se charge que quand les tentatives de réessai deviennent pertinentes.

La direction inverse est un exercice de compression. Prenez le corps d'un skill, gardez les règles qui s'appliquent à chaque requête dans les chemins ciblés, coupez les procédures et les cas limites, et déposez le résultat dans un fichier ciblé :

---
applyTo: "src/services/**/*.ts"
---

Service functions return Result<T, AppError> and never throw.
Error mapping lives in the adapter layer. Log with the request ID;
never log raw third-party error objects.

Ce que vous perdez dans ce sens : le chargement conditionnel et le matériel de référence embarqué. Ce que vous gagnez : les règles gouvernent maintenant aussi la revue de code Copilot sur chaque PR qui touche src/services/. Aucun des deux échanges n'est faux. Ce sont des placements différents de la même connaissance.

Faire tourner Claude Code et Copilot côte à côte

Beaucoup d'équipes ne choisissent jamais, et la division du travail qui en émerge est assez cohérente pour être décrite.

Copilot gère la couche dans l'éditeur plus la revue de PR, configurée par des fichiers d'instructions qui décrivent la base de code. Claude Code gère la couche de session : fonctionnalités multi-fichiers, refactorisations, enquêtes de débogage, et le travail environnant comme les changelogs et les docs de migration, configuré par CLAUDE.md pour les faits du dépôt et les skills pour les capacités. Le recoupement est plus petit qu'il n'y paraît, parce que les outils se situent à des altitudes différentes. L'autocomplétion veut des règles courtes toujours vraies ; un agent qui exécute une tâche de 40 minutes veut des procédures.

La configuration pratique que nous voyons fonctionner : garder .github/copilot-instructions.md et CLAUDE.md comme des frères disant les mêmes choses dans le dialecte de chaque outil (certaines équipes génèrent les deux à partir d'un fichier source unique), utiliser les globs applyTo pour les règles de code ciblées par chemin, et utiliser les skills pour tout ce qui est procédural. Un skill Git Workflow qui fait tourner votre discipline de branches et de commits n'a pas d'expression utile en tant qu'instruction Copilot, et une règle « on utilise pnpm, pas npm » n'a rien à faire en tant que skill. Si vous construisez le côté Claude de tout ça depuis zéro, notre classement des meilleurs skills de code est trié par score testé.

La frontière n'est pas fixe non plus. Les équipes qui commencent avec Copilot pour les complétions ont tendance à confier de plus en plus de travail agentique à Claude Code avec le temps, non pas parce que les instructions échouent, mais parce qu'un outil de session avec des skills rapporte davantage sur les tâches longues. L'inverse arrive aussi : des équipes profondément installées dans Claude Code gardent Copilot quand même parce que l'intégration à la revue de PR est à ce point pratique. Traitez cette répartition comme un défaut, pas une doctrine.

Une mise en garde de nos tests : la duplication dérive. Quand le fichier Copilot dit que les services ne lèvent jamais d'exception et que le skill dit que les services peuvent en lever dans la couche adaptateur, vous obtenez deux assistants qui appliquent avec assurance des règles différentes. Celui qui possède la convention devrait posséder les deux fichiers dans la même PR.

Personne ne teste les fichiers d'instructions non plus

Voici la symétrie inconfortable. Nous avons construit SkillProof parce qu'environ la moitié des skills Claude communautaires que nous installons échouent dès le premier essai, un schéma documenté dans pourquoi la moitié des skills Claude ne fonctionnent pas. Les deux modes d'échec dominants sont des installations qui ne fonctionnent pas d'après les propres instructions du README, et des descriptions trop vagues pour jamais se déclencher.

Les instructions Copilot ont la même maladie avec des symptômes différents. Les listes awesome-copilot et les collections de fichiers d'instructions qui se répandent sur GitHub sont le même markdown non testé : des fichiers copiés depuis un article de blog dans .github/, jamais vérifiés contre un vrai comportement de modèle. Les modes d'échec se recoupent presque un pour un. Une description de skill vague signifie que le skill ne se déclenche jamais ; un fichier d'instructions trop gonflé signifie que les règles se diluent jusqu'à ce que le modèle les ignore. Un corps de skill qui reformule le comportement par défaut du modèle n'ajoute rien ; un fichier d'instructions plein de « écris du code propre et bien documenté » n'ajoute rien. Dans les deux écosystèmes, l'existence du fichier est confondue avec la fonction du fichier.

La différence est que l'échec d'un fichier d'instructions est plus silencieux. Un skill qui ne se déclenche jamais est au moins détectablement inerte. Un fichier d'instructions est toujours techniquement « appliqué », donc les équipes supposent qu'il fonctionne, et personne ne fait la comparaison avec-et-sans qui montrerait s'il change quoi que ce soit au résultat. Cette comparaison est exactement notre critère de sortie pour les skills, et c'est le test que nous suggérerions aussi pour votre fichier Copilot : prenez trois vraies tâches, exécutez-les avec et sans le fichier d'instructions, et comparez les résultats. Si vous ne pouvez pas dire lequel est lequel, vous avez payé des tokens pour un placebo.

FAQ

GitHub Copilot peut-il utiliser des skills Claude ?

Non. Les skills sont un format côté Claude lu par Claude Code, claude.ai, et l'API. Copilot ne peut pas charger un SKILL.md, même si Copilot propose des modèles Claude comme backend ; le modèle est interchangeable, la couche de configuration ne l'est pas. La connaissance à l'intérieur d'un skill se convertit en général en fichier d'instructions, moins le chargement conditionnel et les scripts embarqués éventuels.

Les skills Claude fonctionnent-ils avec des instructions de dépôt comme copilot-instructions.md ?

Ils coexistent sans conflit parce que chaque outil ne lit que ses propres fichiers. Claude Code ignore .github/copilot-instructions.md, et Copilot ignore .claude/skills/. Le risque n'est pas une collision, c'est la dérive : deux fichiers encodant la même convention finiront par diverger à moins d'être maintenus ensemble.

Lequel est meilleur pour imposer des standards de code d'équipe ?

Pour des règles qui correspondent à des chemins de fichiers et doivent atteindre chaque contributeur, les instructions Copilot avec des globs applyTo, parce qu'elles s'appliquent aussi à la revue de code Copilot sur les PR. Pour des standards procéduraux, comme comment exécuter une migration, les skills, parce qu'ils peuvent porter de longues procédures et ne les charger que quand c'est pertinent. La plupart des documents de standards contiennent les deux types et veulent être scindés en conséquence.

Les instructions Copilot sont-elles moins coûteuses en tokens que les skills ?

Généralement l'inverse. Un fichier d'instructions applicable s'attache à chaque requête, donc un fichier de 1 500 tokens coûte 1 500 tokens par interaction, qu'il soit pertinent ou non. Un skill coûte environ 100 tokens au repos et ne charge son corps que sur une correspondance. Toujours actif vaut le coût quand les règles s'appliquent vraiment à chaque requête, ce qui explique pourquoi les fichiers d'instructions courts battent les longs.

Dois-je convertir mon copilot-instructions.md en skills si je passe à Claude Code ?

Scindez-le plutôt que de le convertir. Les faits toujours vrais sur le dépôt, ses commandes de build et ses conventions, appartiennent à CLAUDE.md, qui en est l'analogue le plus proche. Les sections procédurales, tout ce qui se lit comme « en faisant X, suis ces étapes », appartiennent aux skills pour se charger à la demande. Une conversion directe produit en général soit un CLAUDE.md gonflé, soit des skills qui se déclenchent sur tout.