Le 22 octobre 2026, Anthropic a annoncé le don d'Agent Skills à l'Agentic AI Foundation (AAIF), une fondation placée sous la Linux Foundation et cofondée par Anthropic, Block et OpenAI. Anthropic lui avait déjà confié le Model Context Protocol. Si tu débutes avec ces notions, le guide complet pour apprendre Claude pose les bases ; ici, on va à l'essentiel : que change cette annonce, et est-ce que SKILL.md mérite que tu y mettes du temps maintenant.
Ce qui a été annoncé, et ce qui reste à vérifier
Les faits d'abord, tels que l'annonce officielle d'Anthropic les donne. Le standard Agent Skills a été publié en décembre 2025. Selon Anthropic, il compte aujourd'hui 1 million de skills publiés et près de 280 millions d'installations. Plus de 70 plateformes d'agents l'ont intégré ; l'annonce n'en nomme que quatre : ChatGPT, Cursor, GitHub Copilot et VS Code.
Ce qui passe à la fondation : le nom et le logo Agent Skills, l'organisation GitHub et le domaine agentskills.io. Le standard est maintenu par des ingénieurs d'Anthropic, de Google, d'OpenAI et d'autres, à titre individuel. La feuille de route proposée prévoit des versions numérotées, un processus de proposition formel et un guide de sécurité.
Ce que l'annonce ne dit pas compte autant : aucun changement de produit ni de prix pour l'utilisateur final. Anthropic précise aussi que tu peux continuer à utiliser le standard ou y contribuer sans rejoindre l'AAIF. Et les chiffres d'adoption (1 million, 280 millions, 70 plateformes) viennent d'Anthropic elle-même, pas d'une mesure indépendante. Retiens la gouvernance neutre et la spécification publique comme des faits ; traite l'ampleur de l'adoption comme une déclaration de l'éditeur.
Rappel express : un skill est un dossier qui contient un fichier SKILL.md, avec éventuellement des scripts ou des fichiers de référence. Le fichier apprend à un agent une tâche ou un domaine précis.
Anatomie d'un SKILL.md : ce que contient vraiment le fichier
Prenons un cas qu'un indépendant francophone répète toutes les semaines : mettre en forme un compte rendu de réunion. Voici un skill complet, dans un dossier nommé compte-rendu-reunion (le nom du dossier est en minuscules avec tirets et correspond au nom du skill) :
---
name: compte-rendu-reunion
description: Transforme des notes brutes de réunion en compte rendu structuré (décisions, actions avec responsable et échéance, points ouverts). À utiliser quand l'utilisateur colle des notes de réunion, un transcript ou demande un compte rendu ou un relevé de décisions.
---
# Compte rendu de réunion
## Procédure
1. Repère les décisions prises, même formulées implicitement.
2. Liste les actions : un verbe, un responsable, une échéance. Si l'échéance manque, écris "à confirmer" au lieu d'en inventer une.
3. Isole les points ouverts qui n'ont pas été tranchés.
4. Rédige en français, phrases courtes, sans jargon interne.
## Format de sortie
- Titre : date et sujet
- Décisions (liste)
- Actions (tableau : action, responsable, échéance)
- Points ouverts (liste)
## Exemple
Entrée : "On part sur le devis V2, Marie l'envoie jeudi, reste à voir le budget pub"
Sortie : décision = devis V2 retenu ; action = envoyer le devis V2, Marie, jeudi ; point ouvert = budget pub.
Trois éléments font tout le travail. Le frontmatter (entre les deux lignes de tirets) porte le name et la description. Le corps contient la procédure et le format attendu. L'exemple d'entrée et de sortie ancre le comportement mieux que dix lignes d'explications.
Le champ qui compte le plus est la description. C'est elle que l'agent lit pour décider si le skill est pertinent dans la conversation en cours. Une description floue comme « aide pour les réunions » ne déclenche rien de fiable. Celle de l'exemple dit quoi faire et quand le faire, avec des mots que tu tapes réellement (« notes », « transcript », « compte rendu »).
Le principe de divulgation progressive découle de là : le modèle charge d'abord seulement le nom et la description de chaque skill, et ne va lire le détail (procédure, scripts, fichiers de référence) que si la description correspond à la tâche. Tu peux donc avoir beaucoup de skills sans gonfler le contexte à chaque message. Si tu veux voir comment les skills s'intègrent dans une session de travail, l'article sur la commande /skill-doctor de Claude Code est un complément utile pour gérer tes skills dans Claude Code.
Pourquoi un standard ouvert change le calcul pour vous
Un skill en SKILL.md est un fichier texte. Tu peux le mettre dans Git, voir précisément ce qui a changé entre deux versions, le relire sans outil particulier, le copier dans un autre dépôt. Aucune de ces propriétés n'est vraie pour des instructions collées dans l'interface d'un SaaS, où l'historique est opaque et l'export, quand il existe, est un copier-coller manuel.
Le coût de ressaisie est le vrai sujet. Quand tes consignes vivent dans un projet, un GPT ou un prompt système collé dans un outil, changer d'outil veut dire tout réécrire, et tu t'en rends compte au pire moment : quand un prix change ou qu'une fonctionnalité disparaît. Google en donne un exemple concret : il remplace les Gems de Gemini par des Skills qui acceptent l'import de fichiers SKILL.md, avec une fin des Gems programmée dès novembre 2026 pour les comptes personnels. Le détail est dans l'article sur le remplacement des Gems par les Skills. Des consignes écrites en texte portable se déplacent plus facilement que des instructions enfermées dans l'interface d'un outil.
Ce qui est portable aujourd'hui, c'est le fichier et sa structure. Ce qui ne l'est pas forcément, c'est tout ce qui dépend de l'implémentation de chaque outil : l'exécution de scripts, les permissions, les outils disponibles. Un skill écrit pour Claude ne fonctionnera pas à l'identique ailleurs si ses instructions s'appuient sur un outil que l'autre plateforme n'a pas. Formule donc le bénéfice avec prudence : rien ne t'enferme, ce qui n'est pas la même chose que « ça marchera partout sans retouche ».
Le fait que la spécification soit gérée par une fondation avec des mainteneurs de plusieurs éditeurs réduit un risque précis : qu'un seul acteur change le format du jour au lendemain. Il ne garantit pas que chaque outil l'implémentera complètement. Pour mesurer l'état de l'écosystème côté packaging, tu peux aussi lire l'article sur le standard Agent Plugins, un autre format ouvert qui empaquette skills et serveurs MCP.
Skills, MCP, prompts système : où ranger quoi
La confusion la plus fréquente consiste à vouloir tout mettre au même endroit. Les trois mécanismes répondent à des questions différentes : le MCP répond à « à quoi l'agent a-t-il accès ? », le skill à « comment fait-on cette tâche chez nous ? », le prompt système à « quel rôle joue-t-il dans cette conversation ? ».
Un exemple unique qui traverse les trois : un agent de relance client pour une petite agence.
- MCP : un connecteur donne à l'agent la lecture de ton CRM (liste des devis envoyés sans réponse depuis plus de 10 jours, historique des échanges). Sans accès, il n'a rien à relancer. Les serveurs MCP sont la couche qui fournit ce lien aux outils.
- Skill : un fichier
relance-devisdécrit ta méthode : combien de relances maximum, quel ton à la première (une question simple) et à la troisième (une porte de sortie polie), quoi mentionner du devis d'origine, quand ne pas relancer. C'est du savoir-faire, réutilisable dans n'importe quelle conversation. - Prompt système : « Tu es l'assistant commercial de l'agence, tu rédiges des brouillons que je valide avant envoi. » Ça fixe le rôle et la règle de validation, pas la méthode.
Si tu mets la méthode de relance dans le prompt système, elle est chargée à chaque message, y compris quand tu parles d'autre chose. Si tu la mets dans un skill, elle n'est lue que lorsque la tâche s'y prête. Si tu mets l'accès au CRM dans un skill, tu n'as rien fait : un fichier texte ne se connecte à rien. Pour aller plus loin sur la couche d'accès et l'orchestration, le pilier automatisation avec Claude et MCP déroule les cas concrets, et l'API Anthropic reste la porte d'entrée si tu intègres tout cela dans un produit.
Convertir vos instructions actuelles en skill, pas à pas
Voici une procédure à suivre sur un seul workflow, pas sur tout ton historique. Compte 30 à 45 minutes pour le premier.
- Choisis un workflow que tu répètes déjà au moins une fois par semaine : compte rendu, devis, post LinkedIn, réponse à un type de demande client. La récurrence est le seul critère qui compte.
- Récupère tes instructions existantes : le prompt que tu recolles, les consignes d'un projet Claude, les messages où tu as corrigé la sortie (ces corrections sont de l'or : elles disent ce que le modèle fait mal par défaut).
- Un skill par tâche. Si ton prompt fait à la fois des comptes rendus et des mails de relance, coupe en deux dossiers.
- Écris la description comme un déclencheur : verbe d'action, type d'entrée, phrases que tu tapes vraiment. Relis-la en te demandant : si je lis seulement cette ligne, est-ce que je saurais quand ce skill s'applique ?
- Ajoute un exemple d'entrée et de sortie attendue, court et réel, tiré d'un cas passé (anonymisé si besoin).
- Teste sur trois cas, dont un cas limite : notes très courtes, notes contradictoires, entrée dans une langue mixte. Note ce qui casse et ajuste le fichier, pas le test.
- Versionne dans Git avec un message clair. Quand tu modifies une consigne, tu pourras revenir en arrière.
Les erreurs qui reviennent le plus souvent. La description trop vague : le skill n'est jamais déclenché et tu conclus à tort que « ça ne marche pas ». Le skill fourre-tout de 800 lignes : il charge beaucoup de texte pour une tâche qui en demande peu, et les consignes se contredisent entre elles. Les instructions qui se contredisent entre le skill et le prompt système : l'un demande le tutoiement, l'autre le vouvoiement, et le résultat varie d'une exécution à l'autre. Dans ce cas, décide d'une règle et garde-la à un seul endroit.
Faut-il tout migrer maintenant ? Les limites à connaître
Non. Le standard est jeune, la spécification est encore en train de recevoir son processus de gouvernance formel, et la compatibilité réelle entre outils reste à tester au cas par cas. Annoncer 70 plateformes intégrées ne dit pas lesquelles gèrent les scripts, les fichiers de référence volumineux ou les permissions de la même façon.
Ma recommandation : migre les deux ou trois workflows à plus forte récurrence, ceux que tu as déjà recollés dix fois, et laisse le reste. Pour une consigne que tu utilises une fois par trimestre, le gain ne justifiera jamais le temps passé. Un bon critère : si tu peux nommer le workflow sans réfléchir, il mérite un skill.
Un point de vigilance sur la sécurité. Un skill peut référencer des scripts exécutables. Installer un skill trouvé en ligne, c'est potentiellement faire exécuter du code que tu n'as pas écrit. Relis le SKILL.md et chaque script avant d'installer un skill tiers, comme tu relirais une dépendance avant de l'ajouter à un projet. Un guide de sécurité figure dans la feuille de route proposée pour le standard : en attendant, la relecture manuelle reste ta meilleure protection.
Si tu veux aller du skill isolé au produit complet (une application avec ses skills, ses connexions MCP et son déploiement), c'est le terrain de la formation : Construire votre produit IA en 5 semaines. Sinon, commence par un seul fichier SKILL.md cette semaine, sur ton workflow le plus répétitif, et vois à l'usage s'il tient la route avant d'en écrire un deuxième.