Compétences vs Commandes Slash vs Sous-agents Claude

Table des matières

Mis à jour août 2026.

TL;DR : Les commandes slash sont un raccourci pour un prompt que vous tapez souvent — vous les invoquez par leur nom. Les sous-agents sont des travailleurs parallèles avec leur propre fenêtre de contexte — vous (ou Claude) les faites naître pour une tâche délimitée et récupérez un résultat. Les compétences sont de l’expertise packagée que Claude décide de charger lui-même, selon ce que vous demandez, sans que vous nommiez quoi que ce soit. La plupart des gens créent un agent personnalisé quand une commande slash suffirait, et créent une commande slash quand ce dont ils avaient besoin était en réalité une compétence que Claude pouvait déclencher tout seul.

[Le point de vue de l’opérateur] Je fais tourner plus de 30 agents en production sur deux entreprises, et cette confusion précise — commande, sous-agent ou compétence — est la première question de conception sur presque chacun d’eux. Se tromper, et on finit soit avec dix commandes dont personne ne se souvient du nom, soit avec une compétence si large qu’elle ne se déclenche jamais de façon fiable. La solution n’est pas une règle empirique, c’est de se demander ce qui varie réellement d’une exécution à l’autre.

Les trois primitives résolvent des problèmes différents

Les trois vous permettent d’empaqueter des instructions une fois et de les réutiliser. C’est là que s’arrête la ressemblance — et c’est exactement pour ça qu’on les confond : vu de l’extérieur, « taper quelque chose de court et obtenir un résultat utile » se ressemble, peu importe laquelle des trois fait le travail en coulisses.

La vraie différence, c’est qui décide de l’invoquer, et dans quel contexte ça s’exécute :

• Une commande slash est invoquée par vous, par son nom. Vous tapez /deploy ou /review, Claude la développe en une instruction plus complète, et elle s’exécute dans votre conversation en cours.
• Un sous-agent est invoqué par vous ou par Claude, pour une tâche aux contours nets. Il obtient sa propre fenêtre de contexte, fait le travail, et rapporte un résultat — il ne voit pas toute votre conversation, et vous ne voyez pas ses étapes intermédiaires sauf si vous les demandez.
• Une compétence est invoquée par Claude, automatiquement, quand votre demande correspond à ce que la description de la compétence dit couvrir. Vous ne tapez jamais son nom. Si vous ne demandez pas quelque chose que la compétence gère, elle ne se charge jamais.

Cette troisième propriété — l’absence d’invocation explicite — est celle que les gens sous-exploitent le plus. C’est aussi celle qui a le plus d’effet de levier dès que vous avez plus qu’une poignée de workflows packagés, parce que vous arrêtez de devoir vous souvenir de la façon dont vous avez nommé les choses.

Commandes slash : un raccourci pour un prompt que vous tapez souvent

Créez une commande slash quand le déclencheur est « je tape toujours plus ou moins la même instruction ». Une commande qui se résout toujours vers le même prompt sous-jacent, développée à partir d’un nom court que vous avez choisi, dans la conversation que vous êtes déjà en train d’avoir. Pas de contexte séparé, pas d’invocation autonome — c’est vous qui décidez quand elle s’exécute, à chaque fois.

Bons cas d’usage : une checklist de mise en production fixe, une passe de revue de code avec vos règles maison intégrées, un raccourci « résume cette PR ». La commande n’a pas besoin de jugement pour savoir si elle doit s’exécuter — c’est vous qui prenez cette décision en la tapant.

Le mode d’échec, c’est de créer une commande pour quelque chose qui nécessite en réalité que le modèle décide si ça s’applique. Si la moitié de votre usage consiste à se demander « attends, est-ce que cette situation compte ? » — c’est une question de compétence, pas une question de commande, parce qu’une commande n’a aucun moyen de se déclencher elle-même.

Sous-agents : des travailleurs parallèles avec leur propre fenêtre de contexte

Créez un sous-agent quand la tâche est délimitée, délégable, et polluerait sinon votre conversation principale avec des étapes que vous n’avez pas besoin de voir. Un sous-agent exécute son propre contexte — ses propres appels d’outils, ses propres allers-retours — et rend un résultat. C’est le même principe que j’ai décrit dans l’ingénierie du contexte : chaque appel d’outil supplémentaire et chaque étape intermédiaire est du contexte que votre fil principal n’a pas besoin de porter, et un sous-agent est la façon de garder ce bruit à l’écart.

Bons cas d’usage : « recherche ça et fais-moi un rapport », « lance ces cinq vérifications indépendantes en parallèle », « va corriger ce fichier isolément ». La tâche a un début, une fin et un livrable — exactement la forme que le harness d’évals que j’utilise pour déployer des agents traite comme une unité notable unique.

Le mode d’échec, c’est de faire naître un sous-agent pour quelque chose qui devait rester dans votre contexte principal, parce que l’étape suivante dépend de détails que le résumé du sous-agent a perdus. Si vous devez sans cesse redemander au sous-agent « attends, qu’as-tu trouvé exactement », c’est que la frontière a été mal tracée — soit vous le réintégrez dans le fil principal, soit vous rendez le rapport du sous-agent assez structuré pour que rien ne se perde en traduction.

Compétences : de l’expertise packagée que Claude charge lui-même

Créez une compétence quand la condition de déclenchement est quelque chose que Claude devrait reconnaître dans ce que vous demandez, pas quelque chose dont vous devriez vous souvenir de nommer. Une compétence est une description plus un ensemble d’instructions et de scripts ; Claude lit la description, décide si votre demande correspond, et ne charge les instructions complètes que si c’est le cas. Vous ne tapez jamais /nom-de-la-compétence.

L’exemple le plus clair que je puisse citer, c’est celui qui fait tourner le pipeline derrière ce blog. Alejandrorioja.com publie en 13 langues, et tout le flux générer → traduire → rendre → relire tient dans une seule compétence : un fichier SKILL.md décrivant quand l’utiliser (« générer un nouvel article », « traduire dans toutes les langues », « rédiger une promo »), plus les scripts qui font le travail effectif. Je ne lance pas quatre commandes séparées dont je dois me rappeler l’ordre. Je dis ce que je veux en langage courant, et la description de la compétence est assez précise pour que Claude la reconnaisse et exécute les bonnes étapes — de la même façon que la compétence publicités Facebook se déclenche sur « vérifie mes pubs » sans que je tape de nom de commande.

Ce choix de conception — une compétence qui décide elle-même quand elle s’applique — est aussi la raison pour laquelle le réglage de sécurité par défaut compte plus ici qu’avec les commandes ou les sous-agents. Une commande slash ne s’exécute que quand vous la tapez ; une compétence s’exécute quand le modèle pense qu’elle le devrait. Ma compétence de contenu rédige des brouillons par défaut et exige une étape d’approbation explicite et séparée avant que quoi que ce soit ne soit publié ou poussé en production — le même modèle de supervision humaine que j’utilise partout où une compétence peut se déclencher elle-même vers une action aux conséquences réelles.

Bons cas d’usage : tout ce qui a une phrase déclencheuse reconnaissable et une procédure reproductible derrière — « génère un rapport », « note cette soumission », « rédige un résumé pour Slack ». Le mode d’échec, c’est une description de compétence si large qu’elle se déclenche quand vous ne le vouliez pas, ou si étroite qu’elle ne se déclenche jamais quand vous le vouliez. Écrivez la description de la façon dont vous expliqueriez le déclencheur à une nouvelle recrue, pas de la façon dont vous nommeriez une fonction.

Le cadre de décision

Posez-vous cette question	Si oui →	Pourquoi
Est-ce que je veux toujours taper un nom pour déclencher ça ?	Commande slash	C’est vous le déclencheur, pas le modèle
La tâche est-elle délimitée, délégable, et mieux tenue hors de mon contexte principal ?	Sous-agent	Sa propre fenêtre de contexte, rend un résultat
Claude devrait-il reconnaître le besoin sans que je nomme quoi que ce soit ?	Compétence	Correspondance par description, auto-invoquée
Est-ce que ça touche à l’argent, à la publication, ou à quelque chose de difficile à annuler ?	N’importe laquelle des trois, plus une porte d’approbation explicite	L’auto-invocation n’est pas la même chose que l’auto-exécution

La plupart des workflows réels sont un empilement de ces trois-là, pas un choix unique. Mon pipeline de contenu est une compétence (auto-déclenchée sur « écris un article ») qui appelle en interne des sous-agents (un par langue, exécutés en parallèle) et expose une commande slash (/publish) pour la seule étape — la mise en ligne — qui ne devrait jamais arriver sans que je le dise explicitement.

L’erreur que je vois le plus souvent

Construire un agent personnalisé complet — sa propre planification, son propre état, son propre déploiement — pour quelque chose qui était en réalité une commande slash déguisée. Si la tâche est « exécute exactement cette procédure quand je le dis », vous n’avez besoin ni d’autonomie, ni de mémoire, ni de condition de déclenchement. Vous avez besoin d’un nom et d’un prompt. Gardez la machinerie sous-agent-et-compétence pour les tâches où la frontière (sous-agent) ou le déclencheur (compétence) fait réellement le travail, pas seulement pour ajouter de l’infrastructure à quelque chose qui était déjà simple.

Le verdict de l’opérateur

Demandez-vous qui décide de l’invoquer avant de demander comment le construire. Vous décidez, par son nom, à chaque fois → commande slash. Une tâche délimitée que vous voulez garder hors de votre contexte principal → sous-agent. Claude reconnaît le besoin tout seul → compétence, avec une porte d’approbation sur tout ce qui ne peut pas être annulé. Réglez bien cette seule question, et le reste — ce qui va dans le fichier, la quantité d’instructions à empaqueter — en découle presque tout seul.

FAQ

Quelle est la différence entre une compétence Claude et une commande slash ?

Une commande slash est invoquée explicitement, par son nom, chaque fois que vous voulez qu’elle s’exécute. Une compétence est invoquée automatiquement — Claude fait correspondre votre demande à la description de la compétence et la charge sans que vous nommiez quoi que ce soit. Utilisez une commande quand c’est toujours vous qui décidez de la déclencher ; utilisez une compétence quand la condition de déclenchement est quelque chose que le modèle devrait reconnaître par lui-même.

Quand dois-je utiliser un sous-agent plutôt qu’une compétence ?

Quand la tâche est délimitée et délégable et que vous voulez qu’elle s’exécute dans sa propre fenêtre de contexte, séparée de votre conversation principale — pas à cause de comment elle se déclenche, mais à cause de où le travail se fait. Compétences et sous-agents ne s’excluent pas mutuellement : une compétence peut faire naître des sous-agents en interne, de la même façon qu’une compétence de traduction pourrait répartir un article entre un sous-agent par langue.

Est-il prudent de laisser une compétence auto-invoquer des actions comme publier ou dépenser de l’argent ?

Seulement avec une porte d’approbation explicite sur l’étape aux conséquences réelles. L’auto-invocation de la compétence elle-même ne pose pas de problème — ça signifie juste que Claude a reconnu ce que vous demandez. Le risque, c’est l’auto-exécution de tout ce qui est difficile à annuler. Gardez la rédaction, la lecture et le reporting à l’intérieur de la compétence auto-déclenchée ; exigez une confirmation séparée et explicite pour publier, payer ou supprimer.

Dois-je finir par construire les trois ?

Seulement si vos workflows ont réellement les trois formes. Un opérateur solo avec une poignée de tâches reproductibles peut vivre entièrement sur des commandes slash pendant longtemps. Le besoin de compétences et de sous-agents apparaît une fois que vous avez assez de conditions de déclenchement distinctes pour ne plus vous souvenir des noms de commandes, ou assez de sous-tâches délimitées pour que les garder dans votre contexte principal commence à nuire à la qualité.

---

À lire aussi : La compétence Claude qui pilote mes publicités Facebook · Context engineering : ce qui entre dans la fenêtre de contexte · Agents IA supervisés : quand ajouter une validation humaine · Le stack qui fait tourner 30+ agents

Besoin d’aide pour décider quoi automatiser et comment ? Contactez-moi — je conçois des systèmes d’agents en production pour des équipes d’opérateurs.