Agent Skills, le dossier qui apprend vos procédures à l'IA

Vous avez entendu parler des skills, ou compétences d'agent, et vous ne savez pas encore si c'est une mode de plus. Voici la version utile pour décider : ce que c'est, en quoi ça diffère de ce qu'on appelle un agent, pourquoi ça fait baisser un coût que vous payez déjà, et le seul point sur lequel je vous demande de ne rien laisser passer. À la fin, vous saurez quoi demander à l'équipe qui en installe.

Une skill, c'est quoi concrètement ?

Un dossier. Rien de plus : un fichier d'instructions écrit en Markdown, et parfois quelques scripts ou documents de référence à côté. Le fichier s'ouvre sur deux informations obligatoires, un nom et une description qui dit ce que fait la skill et quand s'en servir. Le reste est de la procédure rédigée en langage courant, comme vous l'écririez pour un nouvel arrivant. Un DSI peut me répondre que c'est juste du Markdown, et sur le fichier il a raison.

Ce qui fait la différence, c'est le moment du chargement. L'agent ne garde en mémoire que le nom et la description de chaque skill, quelques dizaines de mots. Quand une demande correspond, il ouvre le dossier et lit la procédure complète. C'est ce mécanisme, pas le format du fichier, qui rend la chose intéressante : votre savoir-faire est disponible partout, et il ne pèse rien tant qu'il ne sert pas.

Quelle différence avec MCP, un prompt système ou un agent ?

Les trois ne sont pas au même niveau, et les confondre coûte cher. La formule de l'éditeur tient en une ligne : « expliquer comment faire, c'est une skill ; accéder à quelque chose, c'est MCP ». Autrement dit, MCP branche l'agent sur vos outils et lui donne des mains, la skill lui donne votre méthode de maison. La version francophone dit la même chose : les outils permettent de faire, les compétences permettent de savoir bien faire. C'est une grille de lecture, pas une définition normalisée.

• Un outil : une fonction unique exposée au modèle, avec ses paramètres d'entrée.
• Un serveur MCP : la couche de connexion qui expose les outils et les données d'un système externe.
• Un prompt système : une consigne permanente, valable pour toute la conversation, donc payée à chaque appel même quand elle ne sert à rien.
• Une skill : une procédure chargée à la demande, qui n'ouvre aucun accès et ne pèse rien tant qu'une demande ne la déclenche pas.
• Un agent : la boucle qui décide, appelle les outils et se corrige, avec son propre contexte et son propre budget.

Pourquoi ça fait baisser un coût réel ?

Parce que le contexte se paie à chaque appel, qu'il serve ou non. Un agent branché sur dix serveurs d'outils charge la description de chacun avant d'avoir commencé, et il sature souvent son contexte avant la première action utile. Le connecteur GitHub officiel consomme à lui seul des dizaines de milliers de tokens, c'est un constat public depuis fin 2025. Une skill non déclenchée coûte quelques dizaines de tokens.

Reformuler une partie de ces intégrations en skills est donc un chantier d'optimisation mesurable : on compte les tokens de contexte avant, on les compte après, et on vérifie que le déclenchement reste correct. Je ne publie pas de gain moyen, faute d'une mesure avant et après que je puisse vous produire. Les chiffres qui circulent viennent de relevés isolés, non reproduits.

• La règle : on ne charge la procédure complète qu'au moment où la demande la réclame, jamais par défaut.
• La mesure : tokens de contexte avant et après, et taux de déclenchement correct sur des demandes représentatives.
• La limite : l'API d'Anthropic plafonne aujourd'hui à vingt skills par requête, et la sélection se dégrade souvent quand la bibliothèque grossit.

Qu'est-ce qui peut mal tourner ?

Beaucoup de choses, et c'est le point noir du sujet. Une skill est du texte que l'agent traite comme une consigne de confiance, plus parfois des scripts exécutés avec les droits de l'utilisateur. Une instruction malveillante glissée dans le fichier, y compris dans un commentaire invisible à la lecture, devient une injection de prompt persistante. La spécification ne prévoit ni signature, ni bac à sable par défaut. L'étude la plus large publiée début 2026 sur les registres publics de skills trouve environ une skill sur quatre porteuse d'au moins une faille, une autre monte à plus d'une sur trois, et celles qui embarquent des scripts sont deux fois plus souvent vulnérables.

• D'où viennent les fichiers : un dossier installé en une commande depuis un registre public n'a été relu par personne.
• Ce que le dossier contient : un fichier d'instructions seul reste du texte, un script joint est une exécution de code sur le poste.
• La nuance honnête : ces chiffres portent sur des registres publics grand public, pas sur un déploiement maîtrisé en entreprise.
• Ce qui existe déjà : un champ expérimental limite les outils accessibles, et certaines implémentations isolent l'exécution. La spécification ne le garantit pas.

Qui contrôle ce format, au juste ?

Un seul éditeur, et c'est la réserve qui compte. Côté adoption, le format publié en décembre 2025 est déjà lu par des dizaines de produits, d'après la vitrine que l'éditeur en tient, dont plusieurs concurrents directs, et quand des concurrents directs convergent, c'est rarement un feu de paille. Côté gouvernance, la comparaison avec MCP tourne à l'inverse. MCP a été confié à une fondation neutre fin 2025, la spécification des skills reste pilotée par son auteur : c'est un standard ouvert par la licence, pas neutre par la gouvernance. La portabilité s'arrête au format, car une skill qui suppose un environnement d'exécution précis ne se comporte pas pareil ailleurs. Le dépôt de spécification a moins de neuf mois. C'est une brique que j'assemble en mission, pas une norme installée de longue date.

Comment savoir si c'est bien fait, sans ouvrir un fichier ?

Vous n'avez pas besoin d'ouvrir un seul fichier. Vous avez besoin de quatre questions, et les réponses suffisent le plus souvent à savoir si l'équipe tient un dispositif ou une collection de dossiers. Aucune de ces questions n'est de moi : la grille de revue est publiée gratuitement par l'éditeur, et je ne fais que l'appliquer.

• La provenance : un dépôt interne relu, ou un registre public installé en une commande.
• Qui les relit : l'auteur d'une skill ne peut pas en être le seul relecteur, comme pour n'importe quel code.
• Sont-elles épinglées en version : une mise à jour silencieuse change la consigne que suit votre agent.
• Sont-elles évaluées avant la prod : trois à cinq demandes représentatives par skill, rejouées comme on mesure un agent.

Un outil donne des mains à l'agent. Une skill lui donne la méthode. Sans relecture, elle lui donne aussi les consignes de quelqu'un d'autre.

La vraie question n'est donc pas de savoir s'il faut adopter les skills, mais lesquelles de vos procédures méritent d'en devenir une, et qui les relit avant qu'un agent les suive. Si vos équipes en installent déjà et que personne n'en tient la liste, un premier échange suffit à en dresser l'inventaire, sans engagement : parlons-en.