Skills vs Sous-agents Claude : Un guide empirique

La distinction entre une skill et un sous-agent Claude est une source de confusion fréquente. Les développeurs qui utilisent Claude Code se demandent souvent s'il faut encapsuler une logique sous forme de skill réutilisable ou de sous-agent plus complexe et isolé. La documentation offre des conseils théoriques, mais la théorie se heurte souvent à la réalité. Cet article propose une réponse empirique à la question claude skills vs subagents.

Chez SkillProof, notre unique objectif est de tester les skills de Claude Code sur des tâches réelles. Pour ce faire de manière fiable, notre harnais de test exécute chaque skill candidate au sein d'un sous-agent dédié, afin qu'une exécution ne puisse pas contaminer la suivante. Cela nous offre un point de vue pratique, bien qu'il soit important de préciser ce que nos données prouvent et ne prouvent pas. Nous disposons des enregistrements d'exécution pour 2090 skills, ce qui nous en apprend beaucoup sur la manière dont les skills échouent — il ne s'agit pas d'une comparaison contrôlée de la même tâche réalisée des deux manières. La différence entre skill et agent Claude présentée ci-dessous est notre interprétation de ces échecs, et nous présenterons les chiffres derrière chaque affirmation pour que vous puissiez juger du raisonnement par vous-même.

Définition des termes : Skill vs Sous-agent

Avant d'analyser les données, il est important d'établir des définitions claires. Bien qu'ils puissent paraître similaires, les skills et les sous-agents servent des objectifs fondamentalement différents et opèrent à des niveaux d'abstraction distincts.

Une skill est une recette. C'est un ensemble d'instructions et d'outils spécifiques et réutilisables qui augmentent les capacités du modèle de base pour une tâche bien définie. Une skill est définie dans un fichier SKILL.md et est conçue pour être appelée par l'agent principal afin d'effectuer une action discrète. Elle opère dans le contexte de l'agent principal et est idéale pour les opérations atomiques, comme le formatage de code, la génération d'un type de fichier spécifique ou l'application d'un style maison. Considérez-la comme une fiche de recette que vous donnez à un cuisinier qui sait déjà cuisiner.

Un sous-agent est un agent de travail entièrement distinct. C'est une instance indépendante du modèle, lancée par un agent principal pour gérer une tâche volumineuse, complexe ou spécialisée. Un sous-agent possède son propre contexte, son propre prompt système, et peut gérer son propre état au cours d'un flux de travail en plusieurs étapes. L'agent principal délègue un objectif de haut niveau au sous-agent, qui travaille ensuite de manière autonome pour l'atteindre. Ne le voyez pas comme une fonction, mais comme un service distinct que vous appelez via une API.

Ce tableau résume les différences fondamentales :

Caractéristique	Skill	Sous-agent
Analogie	Une recette spécifique	Un chef spécialisé
Portée	Tâche atomique, à objectif unique	Flux de travail complexe, en plusieurs étapes
État	Sans état	Propre fenêtre de contexte pour l'exécution ; renvoie un résumé et ne conserve rien ensuite
Contexte	Partage le contexte avec l'agent principal	Contexte isolé et indépendant
Complexité	Un répertoire : `SKILL.md` plus des scripts et fichiers de référence optionnels chargés à la demande	Un fichier markdown avec un frontmatter YAML dans `.claude/agents/` — prompt système, liste d'outils autorisés, modèle
Idéal pour	Outillage, application de format	Tâches autonomes, rôles spécialisés

Comment notre harnais de test révèle la différence

Notez que le véritable axe de différence dans ce tableau est l'isolation du contexte, et non la taille du code. Les deux sont rédigés en markdown simple ; seul l'un d'eux obtient sa propre fenêtre.

Notre méthodologie de test s'appuie sur cette distinction. Comme l'explique notre page de méthodologie, un agent exécute le test, pas une personne : le même agent produit une référence sans skill et une tentative guidée par la skill pour la même tâche réelle, puis évalue si le résultat est nettement meilleur que celui de Claude sans la skill. Nous exécutons chacun de ces tests dans son propre sous-agent afin que l'exécution d'une skill ne puisse pas influencer celle d'une autre.

Cette configuration impose une frontière claire. Le sous-agent reçoit un objectif unique : exécuter la tâche en utilisant la skill fournie. En observant ce processus des milliers de fois, nous voyons exactement où l'abstraction de la skill excelle et où elle échoue.

Les statistiques de notre catalogue sont révélatrices. Sur les 2090 skills testées à ce jour :

1291 (62%) réussissent nos benchmarks. Elles s'installent, se déclenchent sur les prompts qu'elles prétendent gérer, et surpassent la référence sans skill sur une tâche réelle.
697 nécessitent une configuration. Selon notre méthodologie, une configuration signifie que la skill a besoin de paramétrage, d'une skill compagnon ou d'une intégration connectée pour fonctionner. En parcourant les notes de test de ces 697 skills, les blocages sont majoritairement liés à l'accès : 229 mentionnent une CLI ou un binaire externe, 171 une clé API ou des identifiants, 169 un compte ou un forfait payant, 136 un serveur ou une intégration MCP.
102 obtiennent un score INFÉRIEUR à Claude seul. Elles n'ont pas réussi à battre la référence sans skill — certaines parce qu'elles ne pouvaient pas s'exécuter du tout (une CLI manquante, une dépendance morte, un exemple qui plante), d'autres parce qu'elles se sont exécutées et ont laissé un résultat pire que celui de Claude seul.

En toute honnêteté, cette répartition en dit moins sur l'architecture que ce que l'on pourrait espérer. La catégorie 'configuration' est principalement une histoire d'identifiants et de binaires manquants, ce qui est orthogonal à la question de savoir si une tâche relève d'une skill ou d'un sous-agent. C'est dans les échecs que se trouve la véritable leçon d'architecture, et nous y reviendrons ci-dessous.

Quand utiliser une skill : Le modèle de la recette

D'après les 1291 skills réussies de notre répertoire, une tendance claire se dégage. Les skills performantes sont ciblées, sans état et déterministes. Ce sont des outils, pas des penseurs.

Voici les cas d'usage idéaux pour une skill :

Tâches atomiques et répétables : Une skill excelle dans les tâches qui ont une entrée claire et une sortie prévisible. Pensez aux choses pour lesquelles vous écririez normalement un petit script. audit-export, une skill réussie de notre catégorie productivité, en est un bon exemple : fournissez-lui un rapport d'audit en markdown et elle produit un CSV prêt à être importé dans Jira, Linear, Teamwork ou Monday. Lors de notre test, elle a transformé un rapport de cinq observations en lignes valides avec des dates d'échéance de phase correctes et des modèles de tickets multi-lignes entre guillemets. Un seul travail, bien fait.
Apprendre à Claude à utiliser un accès qu'il possède déjà : C'est la distinction que les gens comprennent le plus souvent à l'envers, alors soyez prudent ici : une skill n'accorde pas de nouvel accès. Elle ne peut pas atteindre votre instance Postgres ou appeler une API tierce par elle-même — c'est à cela que servent les serveurs MCP, et nous avons couvert cette division dans Claude Skills vs MCP. Ce qu'une skill fait, c'est apprendre à Claude à utiliser une capacité qu'il possède déjà, de manière efficace et cohérente. Si une CLI est déjà dans votre PATH, une skill est le bon endroit pour encoder la manière dont votre équipe l'invoque.
Sortie contrainte et formatage : Lorsque vous avez besoin que la sortie se conforme à une structure rigide, une skill est le bon choix. git-workflow, dans notre catégorie codage, en est un exemple fonctionnel : lorsqu'on lui a demandé de l'aide avant d'ouvrir une PR à partir d'une branche à un commit nommée my-fix avec le message de commit "fixed stuff", la skill a identifié les violations de convention spécifiques et a produit des remplacements conformes. Le fichier SKILL.md contient des instructions strictes sur la forme, que le modèle suit de manière fiable car la tâche est restreinte.

Les caractéristiques d'une skill bien conçue, telles qu'observées dans nos exemples les mieux notés, incluent un SKILL.md concis, une définition claire de tous les outils inclus, et l'absence de logique de branchement complexe. Les instructions doivent guider le modèle, et non tenter de le programmer par la prose.

Quand utiliser un sous-agent : Le modèle du spécialiste

Si une skill est une recette, un sous-agent est un spécialiste que vous engagez pour un travail complexe. La décision claude code subagent or skill devient plus claire lorsque la tâche nécessite de la mémoire, de l'itération ou une persona distincte.

Nos données sur les skills en échec ou à configuration complexe montrent quand un développeur aurait dû choisir une architecture de sous-agent dès le départ.

Voici les cas d'usage idéaux pour un sous-agent :

Flux de travail complexes en plusieurs étapes : Toute tâche nécessitant une séquence d'étapes dépendantes est un travail pour un sous-agent. Par exemple : « Rechercher la performance de divers algorithmes de tri pour des données presque triées, rédiger un résumé des résultats, puis générer le code Python implémentant le plus efficace. » Ce flux de travail exige le maintien du contexte (la recherche) à travers plusieurs étapes (résumé, codage). La nature sans état d'une skill rend cela presque impossible à réaliser de manière fiable.
Tâches nécessitant une isolation ou une persona différente : Parfois, une tâche requiert un état d'esprit complètement différent de celui de l'agent principal. Un exemple classique est un agent « réviseur de code ». Vous pourriez vouloir que cet agent soit critique, méticuleux et concentré uniquement sur la qualité du code. Tenter d'obtenir cette persona d'un assistant généraliste via une skill est inefficace et peu fiable. Il est beaucoup plus efficace de lancer un sous-agent avec un prompt système adapté à cette persona critique.
Travail de longue durée que vous ne voulez pas dans votre contexte : Une skill n'est pas du tout un appel — rien n'est invoqué et rien ne retourne. Claude lit le SKILL.md dans son propre contexte et suit les instructions lui-même, à l'intérieur de la boucle principale. Il n'y a pas d'agent de travail distinct à qui confier une longue tâche. Les sous-agents sont le mécanisme pour cela, et depuis Claude Code v2.1.198, ils s'exécutent en arrière-plan par défaut, le premier plan étant réservé aux cas où le résultat est nécessaire immédiatement. Une mise en garde à formuler clairement : pour une simple attente — interroger un point de terminaison, surveiller la fin d'une compilation — une tâche shell en arrière-plan est moins chère et plus simple que de créer un agent. Optez pour un sous-agent lorsque le travail nécessite du jugement, pas seulement de la patience.

La zone grise : Pourquoi 102 skills sont pires que rien

Les données les plus éclairantes proviennent de nos échecs — et elles ne disent pas ce que nous attendions. Nous sommes partis du principe que les 102 échecs seraient des skills s'efforçant d'agir comme des sous-agents : des fichiers SKILL.md surchargés, des branchements alambiqués, des processus avec état entassés dans une recette. En examinant les notes de test des 102, seuls cinq mentionnent la longueur ou le gonflement des tokens. Cette théorie est donc largement fausse, et il est important de le dire plutôt que de l'abandonner discrètement.

Ce qui se décompose en réalité en deux groupes. Le plus grand est l'échec de dépendance : 30 des 102 citent une CLI ou un binaire manquant, 22 un compte payant, 19 un serveur MCP manquant, 10 une clé API absente. skill-builder est représentatif — chaque appel d'outil dépend d'un serveur MCP distinct qui n'est pas inclus ou connecté automatiquement, et la skill ne mentionne jamais ce prérequis, si bien qu'une approche manuelle simple la surpasse. Ce sont des échecs de packaging, pas des échecs d'architecture.

Le second groupe est plus discret et plus instructif : des skills qui s'installent proprement, se déclenchent correctement, et ne produisent tout simplement rien de mieux que la référence. api-design-principles en est le cas le plus clair. Nous avons testé une tâche de conception REST — un service de favoris avec des points de terminaison, du versionnement, de la pagination et des exemples JSON — avec et sans la skill. Les deux branches ont produit un travail correct et comparable. aeon et arbor ont abouti au même résultat. C'est là que la question skill versus sous-agent prend tout son sens : ces skills ont tenté d'encoder tout un processus de raisonnement en prose, et le modèle était déjà capable de ce raisonnement. La skill a ajouté des mots sans ajouter de capacité.

C'est la leçon d'architecture honnête. Non pas « les longues skills échouent », mais : si ce que vous écrivez est une procédure que le modèle suit déjà avec compétence, une skill n'ajoute rien — et si la procédure a véritablement besoin de son propre contexte, d'une persona ou de nombreuses étapes dépendantes, la prose dans un SKILL.md n'est pas le bon conteneur. La réponse à la question de savoir quand utiliser une skill ou un sous-agent dans Claude Code est la suivante : si votre tâche ressemble à un programme, construisez-la comme un sous-agent ; si elle ressemble à une note de service pour un collègue compétent qui connaît déjà le travail, elle n'a peut-être pas besoin d'exister du tout.

Une heuristique pratique

Choisir entre une skill et un sous-agent ne doit pas être un débat académique. Nos données de test suggèrent une heuristique simple et pratique :

La tâche est-elle un appel de fonction ou un programme ?

Si votre tâche peut être modélisée comme un unique appel de fonction—elle prend une entrée claire et produit une sortie discrète sans avoir besoin de se souvenir des interactions passées—c'est une skill.
Si votre tâche nécessite un état, une mémoire interne, plusieurs étapes ou un contexte spécialisé pour s'exécuter—en d'autres termes, si elle se comporte comme un programme autonome—elle devrait être un sous-agent.

En respectant cette distinction, les développeurs peuvent créer des solutions plus robustes, fiables et efficaces avec Claude Code. Commencez par l'abstraction la plus simple qui fonctionne. Une skill bien définie est puissante. Mais sachez reconnaître les signes d'une complexité croissante et soyez prêt à passer à une architecture de sous-agent lorsque la tâche l'exige.

Lectures complémentaires : si vous avez décidé que la tâche doit être confiée à un agent de travail isolé, notre guide des sous-agents Claude Code explique comment en définir un et ce qu'il peut réellement voir. Et si vous hésitez encore entre un nouvel accès et de meilleures instructions, Claude Skills vs MCP trace cette ligne correctement — c'est la source de confusion la plus courante.

Si vous avez besoin d'outils fiables et pré-validés pour des tâches de développement courantes, nous avons benchmarké plus d'un millier de skills réussies. Vous pouvez parcourir par fonction dans les skills de codage et les skills de document, ou acquérir un pack de dix skills testées pour un rôle spécifique pour 10 $ — la boîte à outils du développeur est la plus adaptée au travail décrit ici.

Skills vs Sous-agents Claude : Lequel choisir ?