Tes Skills IA sont prisonniers : comment les rendre portables

#Le problème : tes compétences IA sont louées, pas possédées

Tu passes du temps à peaufiner tes instructions pour Claude. Un workflow de review de PR aux petits oignons, un format de commit précis, une procédure de déploiement détaillée. Ce travail a de la valeur. Mais où vit-il ?

Souvent, il est enfermé. Coincé dans la configuration d'un seul outil, dans un format propriétaire, dans un fichier que tu ne peux pas vraiment déplacer. Le jour où tu changes d'outil — ou simplement où ton équipe en utilise un autre — tu repars de zéro.

C'est ce qu'on appelle le vendor lock-in (la dépendance à un fournisseur) : ton savoir-faire est captif d'une plateforme. Tu ne le possèdes pas vraiment, tu le loues.

La bonne nouvelle : il existe une solution simple et concrète. Elle s'appelle Agent Skills, et c'est un standard ouvert. Dans ce guide, on va voir ce que c'est, pourquoi ça change tout, et comment écrire un Skill que tu possèdes pour de bon.

#C'est quoi un Skill, en une phrase

Un Skill est un dossier qui contient un fichier SKILL.md. Ce fichier décrit une compétence : un workflow, une expertise métier, une procédure. L'agent IA le découvre et le charge automatiquement quand il en a besoin.

Rien de magique : c'est du texte (Markdown) avec quelques métadonnées en en-tête. C'est précisément ce qui le rend portable — un fichier texte se déplace partout.

Le format Agent Skills a été créé par Anthropic puis publié comme standard ouvert. Concrètement, ça veut dire que personne ne le possède : n'importe quel outil peut le lire, et n'importe qui peut écrire un Skill sans demander la permission.

#Pourquoi le standard ouvert change tout

Le détail qui fait toute la différence : ce format n'est pas réservé à un seul outil. Plusieurs dizaines d'outils concurrents lisent désormais le même fichier SKILL.md, dans la même structure de dossier.

Ça veut dire qu'un Skill écrit une fois fonctionne dans plusieurs environnements sans réécriture. Tu écris ton workflow de review une seule fois, et il te suit d'un outil à l'autre.

32+

Outils compatibles

Champs obligatoires

Fichier SKILL.md

Permission à demander

Parmi les outils qui lisent le même format, on trouve aussi bien Claude Code que des CLI concurrents comme Gemini CLI, Codex CLI, ou des outils d'éditeurs comme JetBrains. Tu n'as pas besoin de les connaître tous : retiens juste l'idée. Un format, beaucoup d'outils.

C'est exactement la différence entre posséder ta compétence et la louer. Un Skill au format ouvert t'appartient. Tu le versionnes avec Git, tu le partages, tu le déplaces. Personne ne peut te le confisquer.

#Anatomie d'un SKILL.md

Le fichier se compose de deux parties : un frontmatter (les métadonnées, en en-tête) et le corps en Markdown (les instructions).

---
name: review-pr
description: Review une pull request en cherchant les bugs,
  les problèmes de sécurité et les écarts de style. À utiliser
  quand on demande une review de code ou avant un merge.
---

# Review de PR

Quand tu reviews une pull request, suis ces étapes :

1. Lis le diff complet avant de commenter.
2. Cherche d'abord les bugs de logique, puis la sécurité.
3. Signale les écarts par rapport au style du projet.
4. Termine par un résumé : bloquant, à corriger, ou OK.

Le frontmatter est délimité par les ---. Deux champs sont obligatoires :

name : un identifiant unique. En minuscules, avec des tirets à la place des espaces (exemple : review-pr).
description : une phrase claire qui dit ce que fait le Skill et quand l'utiliser. C'est ce texte que l'agent lit pour décider s'il doit charger le Skill.

Soigne ta description. C'est le seul élément que l'agent voit en permanence. Si elle est vague, le Skill ne sera jamais déclenché au bon moment. Écris-la comme un mode d'emploi : « fait X, à utiliser quand Y ».

Le corps en Markdown, lui, contient les instructions complètes. Pas de syntaxe spéciale : du Markdown normal, lisible par un humain comme par une machine.

#Le secret de la légèreté : le progressive disclosure

Une question légitime : si tu as 100 Skills, est-ce que l'agent charge 100 fichiers complets à chaque fois ? Non. Et c'est grâce au progressive disclosure (la divulgation progressive).

L'idée est simple : on ne charge le contenu détaillé que lorsqu'on en a besoin. Le système fonctionne par niveaux :

Les métadonnées (name + description) sont chargées au démarrage. C'est minuscule, quelques dizaines de mots par Skill.
Le corps du SKILL.md n'est chargé que lorsque l'agent juge le Skill pertinent pour la tâche en cours.
Les ressources annexes (fichiers, scripts, exemples) ne sont lues qu'à la demande, si le Skill les référence.

L'image mentale : une table des matières toujours visible, mais tu n'ouvres un chapitre que quand tu en as besoin. L'agent peut ainsi garder des centaines de Skills sous la main sans saturer son contexte.

#Posséder vs louer : la comparaison

Critère	Config propriétaire	Skill ouvert
Format	Spécifique à l'outil	SKILL.md standard
Portabilité	Bloqué sur 1 outil	32+ outils
Versionnable avec Git	Variable	Oui, c'est du texte
Partage en équipe	Difficile	Un simple dossier
Si tu changes d'outil	Tout réécrire	Rien à faire

#Mise en pratique : ton premier Skill portable

Passons à l'action. On va créer un Skill simple, étape par étape.

#Étape 1 — Crée le dossier

Un Skill, c'est un dossier qui porte son nom et contient un SKILL.md. Pour un usage local avec Claude Code :

mkdir -p .claude/skills/changelog

Le nom du dossier (changelog) doit correspondre au name que tu mettras dans le frontmatter.

#Étape 2 — Écris le SKILL.md

Crée le fichier .claude/skills/changelog/SKILL.md :

---
name: changelog
description: Génère une entrée de changelog à partir des commits
  récents. À utiliser quand on prépare une release ou qu'on
  demande de résumer les changements.
---

# Génération de changelog

Quand on te demande un changelog :

1. Récupère les commits depuis le dernier tag.
2. Regroupe-les par type : Ajouts, Corrections, Changements.
3. Reformule chaque ligne en langage clair pour un humain.
4. Ignore les commits techniques (merge, lint, formatage).

#Étape 3 — Vérifie le déclenchement

Recharge ton outil et invoque le Skill. Dans Claude Code, il devient une commande slash automatique : /changelog. L'agent peut aussi le déclencher seul si ta description correspond à la demande.

Si le Skill ne se déclenche jamais tout seul, le coupable est presque toujours la description : rends-la plus explicite sur le quand.

#Étape 4 — Rends-le portable et possède-le

C'est ici que tu prends possession de ton travail. Mets ton dossier de Skills sous contrôle de version :

git init
git add .claude/skills/
git commit -m "feat: ajoute le skill changelog"

À partir de là, ton Skill :

te suit dans n'importe quel outil compatible (copie le dossier, c'est tout) ;
se partage avec ton équipe via un simple git pull ;
vit dans ton dépôt, pas dans une plateforme que tu ne contrôles pas.

Range tes Skills dans un dépôt Git dédié (par exemple mes-skills). Tu construis ainsi ta propre bibliothèque de compétences, réutilisable partout, qui grandit avec toi et non avec un outil.

#Récapitulatif

Le message tient en quelques points :

Un Skill est un dossier avec un fichier SKILL.md : du Markdown plus deux métadonnées (name, description).
Le format Agent Skills est un standard ouvert lu par des dizaines d'outils. Tu écris une fois, ça marche partout.
Le progressive disclosure garde le tout léger : seules les métadonnées sont chargées en permanence.
Mettre tes Skills sous Git, c'est la différence entre posséder ton savoir-faire et le louer à une plateforme.

Tes compétences IA n'ont pas à rester prisonnières. Sors-les de leur cage : un fichier texte, un dépôt Git, et elles t'appartiennent pour de bon.