SKILL.md, le roi du Shadow AI

Le concept des Agent Skills est génial

Commençons par le dire clairement : les Agent Skills sont une excellente idée.

Lancé par Anthropic fin 2025, le format est élégant : un dossier auto-contenu avec un fichier SKILL.md au format Markdown, du YAML frontmatter, et éventuellement des scripts ou des références. Quand un agent rencontre une tâche, il découvre les skills pertinents et charge uniquement les instructions nécessaires, ce qui maintient le contexte léger et adaptable.

Le principe de progressive disclosure est particulièrement astucieux : seul le strict nécessaire est injecté dans la fenêtre de contexte au moment où c’est utile. C’est efficace, c’est modulaire, c’est lisible par un humain comme par une machine. La promesse est forte : encapsuler un savoir-faire métier de façon durable, plutôt que de le diluer dans des prompts éphémères.

Bref, sur le plan technique, le format SKILL.md est une réussite.

Mais voilà : ce qui fait sa force est aussi en train de faire sa fragilité. Pas le format lui-même, mais l’architecture organisationnelle dans laquelle il est déployé aujourd’hui.

Le vrai problème : un format sans gouvernance

Pour comprendre, il faut regarder où vivent réellement les skills dans la majorité des déploiements actuels :

• Dans un dossier skills/ sur le poste d’un développeur
• Dans un dépôt GitHub personnel, parfois public
• Dans ~/.claude/skills/, partagés entre projets sans inventaire
• Dans des marketplaces communautaires sans contrôle interne
• Dans un dossier partagé Drive ou Notion, copié-collé entre collègues

Autrement dit : chaque skill est créé, modifié, partagé et exécuté hors de tout cadre d’entreprise.

Pendant ce temps, dans la même entreprise :

• Le baromètre Privacy 2026 montre que 80 % des organisations n’ont pas de vision claire de leurs usages IA.
• Le Cloud and Threat Report 2026 indique que 47 % des utilisateurs d’IA générative passent encore par des comptes personnels.
• Selon les analyses sectorielles, 38 % des employés partagent des informations sensibles avec des plateformes d’IA sans validation.

Le Shadow AI était déjà un problème majeur avec ChatGPT et Claude utilisés via comptes perso. Avec les Agent Skills, on entre dans une nouvelle dimension : ce n’est plus seulement de la donnée qui sort, c’est du savoir-faire métier qui est encapsulé, versionné, partagé, et totalement invisible pour la DSI.

Pourquoi le format SKILL.md aggrave le Shadow AI

1. Le couplage fort avec le LLM ou l’agent

Un skill, dans son architecture actuelle, est collé à son moteur d’exécution. Un skill Anthropic est conçu pour Claude. Un skill OpenAI est conçu pour GPT. Un skill Copilot Studio vit dans l’écosystème Microsoft.

Conséquence pratique : pour utiliser un skill, il faut adopter (et souvent payer) le LLM correspondant. Chaque équipe métier qui découvre une bibliothèque de skills intéressante embarque avec elle un nouveau fournisseur, un nouveau modèle économique, un nouveau contrat de traitement de données. La DSI découvre l’engagement après coup.

C’est le scénario classique du Shadow IT, mais avec un facteur multiplicateur : un skill n’est pas un outil isolé, c’est un bloc de capacité métier qui crée immédiatement de la dépendance opérationnelle.

2. Aucune notion d’organisation

Un skill ne sait pas à quelle entreprise il appartient, à quel département, à quelle fonction. Il n’a pas de propriétaire identifié, pas de consommateur déclaré, pas d’unité organisationnelle de rattachement.

Résultat :

• Pas de cartographie possible : impossible de répondre à la question « combien de skills tournent dans mon entreprise ? »
• Pas de mutualisation : trois équipes peuvent créer trois skills quasi-identiques pour la même tâche.
• Pas de cycle de vie : qui maintient un skill quand son auteur quitte l’entreprise ?
• Pas d’audit : impossible de produire la liste des systèmes IA déployés exigée par l’AI Act.

L’article 4 de l’AI Act européen impose une « culture suffisante en matière d’IA » à l’ensemble des collaborateurs exposés à ces outils. Difficile à appliquer quand vous ne savez même pas quels skills sont en circulation.

3. Pas de permissions, pas de propriété, pas de traçabilité

Un fichier SKILL.md ne porte aucune notion de :

• Qui peut le créer.
• Qui peut le consommer.
• Qui est responsable de sa qualité et de sa conformité.
• Quels usages doivent être journalisés.

C’est un format de partage, pas un format de gouvernance. Et c’est précisément ce qui en fait, paradoxalement, le format idéal pour le Shadow AI : facile à créer, facile à distribuer, impossible à tracer à l’échelle de l’entreprise.

4. La duplication et la dérive

Sans catalogue centralisé, le savoir-faire métier se dilue dans une infinité de copies divergentes. Le skill « génération de rapport client » existe en sept versions, chacune avec sa propre interprétation des règles, ses propres données d’entreprise codées en dur, ses propres bugs.

Lorsque l’audit RGPD arrive, lorsque l’AI Act demande de documenter le système d’IA utilisé pour une décision automatisée, lorsqu’un client demande à exercer son droit à l’effacement, personne n’est capable de répondre.

Ce n’est pas un bug, c’est une couche manquante

Il faut être juste avec Anthropic : le format SKILL.md n’a jamais prétendu être une plateforme de gouvernance. C’en est un excellent, mais ce n’est qu’un format. Le problème, c’est qu’aucune couche d’organisation ne vient s’ajouter au-dessus, et que la communauté traite ce vide comme s’il n’existait pas.

Le parallèle est instructif. Le code source ne se gouverne pas tout seul : il a fallu inventer Git, puis GitHub, puis les revues de pull request, puis les pipelines CI/CD, puis les politiques de branche. La donnée ne se gouverne pas toute seule : il a fallu inventer les data catalogs, les data contracts, les data products. Les skills aussi ont besoin de leur couche d’orchestration.

Une piste : capturer les initiatives avec un framework comme skilder

C’est précisément l’angle d’approche d’un framework comme skilder. L’idée n’est pas de remplacer le format SKILL.md (qui reste excellent), mais d’ajouter par-dessus une couche d’organisation, de propriété et de coordination.

Le concept clé : le Rôle

Un Rôle est une collection de skills nommée et thématique, qui correspond à une fonction ou une persona identifiée dans l’entreprise. Au lieu de laisser flotter les skills en vrac, on les regroupe par usage métier :

• Un Rôle « Pre-Sales » réunit les skills utiles pour gérer les objections, mobiliser la veille concurrentielle, accompagner un prospect dans le cycle de vente.
• Un Rôle « Legal Assistant » réunit les skills d’analyse de contrats, de veille réglementaire, de rédaction d’avenants.
• Un Rôle « DevOps » réunit les skills de déploiement, de monitoring, de réponse incident.

Quand un collaborateur (ou un agent) endosse le Rôle « Pre-Sales », il accède d’un coup à l’ensemble cohérent des capacités validées pour cette fonction. Ni plus, ni moins.

Pourquoi ça change tout

Ce mécanisme apparemment simple résout plusieurs problèmes structurels du Shadow AI :

1. Il capture les initiatives plutôt que de les interdire. Un commercial qui a bricolé son propre skill peut le proposer à l’intégration dans le Rôle « Sales ». L’initiative individuelle devient un actif d’entreprise au lieu de rester dans l’ombre.
2. Il rend la cartographie triviale. La question « quels skills tournent dans mon entreprise ? » devient simplement « quels Rôles avons-nous, et quels skills y a-t-il dedans ? ». Le catalogue est centralisé, versionné, audité.
3. Il introduit une propriété explicite. Chaque skill a un propriétaire et des consommateurs déclarés. La maintenance, la qualité, la conformité ont un nom et un visage.
4. Il découple le savoir-faire du moteur d’exécution. Avec une approche compatible MCP, le même skill peut être consommé par Claude, par Copilot, par un agent maison, sans réécriture. Fini le vendor lock-in implicite.
5. Il rend la sélection de contexte intelligente. Au lieu de charger toute la bibliothèque dans la fenêtre de contexte, l’agent ne charge que les skills du Rôle actif. Économie de tokens, baisse des hallucinations, performances accrues.
6. Il offre une alternative crédible au Shadow AI. Le problème central du Shadow AI n’est pas que les collaborateurs sont mal intentionnés. C’est qu’ils ont besoin de productivité et que les outils officiels arrivent trop tard. Donner aux équipes une plateforme où elles peuvent créer, partager et consommer des skills validés, dans le cadre de l’entreprise, c’est offrir la fluidité du shadow avec les garanties de l’officiel.

L’architecture conceptuelle

L’idée tient en quelques lignes :

Workspace (frontière entreprise)
└── Rôles (fonctions / personas métier)
    └── Skills (unités de capacité, compatibles SKILL.md)
        ├── Instructions
        ├── Outils MCP (agnostiques au LLM)
        ├── Références (documents markdown)
        └── Scripts (Python, exécutés en sandbox)

Le format SKILL.md est préservé. Un skill Anthropic standard peut être importé tel quel. Mais il est désormais rattaché à un workspace, organisé en Rôles, exposé via un protocole agent-agnostique (MCP), tracé, versionné, et soumis à des permissions explicites.

Ce que ça implique pour les DSI et les responsables IA

Si vous portez aujourd’hui un sujet de gouvernance IA en entreprise, voici la question concrète à se poser : pouvez-vous, ce matin, lister tous les fichiers SKILL.md qui circulent dans votre organisation ?

Si la réponse est non (et statistiquement elle l’est dans 80 % des cas), alors il ne suffit plus de produire une charte ou d’interdire ChatGPT. La couche manquante est structurelle :

1. Cartographier l’existant. Les skills déjà créés dans les dépôts Git, les ~/.claude/, les marketplaces. C’est l’équivalent IA du registre des traitements RGPD.
2. Centraliser la création. Un seul endroit où on déclare, versionne et publie un skill, avec un propriétaire et un consommateur identifiés.
3. Structurer par Rôle, pas par technologie. Penser Rôles avant de penser modèles. Un commercial n’a pas besoin de savoir s’il utilise Claude ou GPT. Il a besoin du Rôle « Sales ».
4. Découpler du LLM. Choisir une couche d’abstraction (MCP est aujourd’hui le standard de fait) qui permet de changer de modèle sans réécrire les skills.
5. Officialiser la création de skills internes. Le Shadow AI prospère quand le canal officiel est plus lent que le canal sauvage. Si créer un skill validé prend 48 heures avec un propriétaire identifié, plus personne n’ira en bricoler un dans son coin.

Conclusion

Le format SKILL.md n’est pas le problème. C’est même probablement l’un des meilleurs formats d’encapsulation de savoir-faire IA qu’on ait vus émerger ces deux dernières années.

Mais un format n’est pas une plateforme. Et tant que l’écosystème continuera à traiter les skills comme on traitait les scripts shell en 2005 (partagés à la main, sans propriétaire, sans catalogue, sans cycle de vie), alors le standard SKILL.md restera, malgré lui, le roi du Shadow AI : le format le plus pratique, le plus partageable et le plus invisible que les entreprises aient jamais laissé entrer dans leurs systèmes.

La bonne nouvelle, c’est que la solution n’est pas de remplacer le format. C’est d’ajouter au-dessus la couche d’organisation qui lui manque. Des Rôles pour structurer les usages métier. Un workspace pour délimiter l’entreprise. Une compatibilité MCP pour éviter le vendor lock-in. Un catalogue pour rendre visible ce qui circule.

Le Shadow AI n’est pas un signal qu’il faut interdire l’IA. C’est un signal qu’il faut lui donner enfin un cadre où elle peut s’épanouir sans se cacher.

---

Vous voulez cartographier les skills déjà en circulation dans votre organisation, ou structurer leur adoption autour de rôles métier clairs ? C’est exactement le problème que skilder résout.