Les Skills : la brique qui a changé nos workflows IA

Tu réexpliques à ton agent, pour la quinzième fois cette semaine, comment on structure un composant dans ce projet. Où vont les fichiers, comment on nomme les choses, quelle bibliothèque on utilise et laquelle est bannie.

Tu as déjà tout écrit. Dans un fichier de règles devenu illisible à force d’ajouts, ou dans un prompt que tu recopies. Et pourtant l’agent applique une convention sur trois.

Le problème n’est pas ce que tu as écrit : c’est quand il le lit.

TL;DR

• Une skill est une instruction chargée au moment où elle est pertinente, pas une règle permanente qui dilue le contexte.
• La différence avec un fichier de règles : les règles sont toujours présentes et perdent du poids à mesure que le contexte grossit. Une skill arrive au bon moment, entière.
• La différence avec un MCP : le MCP donne un accès (une capacité technique), la skill donne une méthode (un savoir-faire). Ce ne sont pas des concurrents.
• La vraie valeur : la capitalisation d’équipe. Une skill écrite une fois est appliquée par tout le monde, sur tous les projets.

Le problème que les skills résolvent

Un agent lit son contexte à chaque appel. Tout ce qui y est présent concurrence tout le reste.

Un fichier de règles projet qui grossit passe par trois stades, toujours les mêmes :

1. Utile. Vingt lignes, l’agent les suit.
2. Dilué. Deux cents lignes couvrant vingt situations, dont dix-neuf sans rapport avec la tâche en cours. L’agent en retient une partie.
3. Contre-productif. Cinq cents lignes qui coûtent des tokens à chaque appel, noient les règles importantes sous les cas particuliers, et créent des conflits d’instructions.

Le réflexe naturel (ajouter une règle à chaque fois qu’un problème survient) mène mécaniquement au stade 3.

Le principe des skills inverse la logique : au lieu de tout charger en permanence, on ne charge une instruction que quand la situation le justifie. Le contexte permanent reste minimal ; le détail arrive à la demande. Ce mécanisme de divulgation progressive est décrit dans la documentation Anthropic sur les Agent Skills : seule une courte description reste en contexte, et le contenu complet est lu quand la tâche correspond.

Une skill, un fichier de règles, un MCP : trois choses différentes

C’est la confusion la plus fréquente, et elle conduit à mal outiller son environnement.

	Fichier de règles	Skill	MCP
Nature	Instructions permanentes	Méthode chargée à la demande	Accès à un système externe
Présence en contexte	Toujours	Description seule, puis contenu si pertinent	Définition des outils exposés
Répond à	« Quelles sont les règles ici ? »	« Comment fait-on ça ici ? »	« À quoi ai-je accès ? »
Bon usage	Peu de règles, universelles au projet	Procédures, conventions, méthodes	Base de données, API, système de tickets
Symptôme de mauvais usage	Fichier de 500 lignes	Skill jamais déclenchée	Trop d’outils exposés, l’agent se perd

Skill et MCP ne s’opposent pas. Un MCP donne à l’agent la capacité de lire ta base de données ; une skill lui explique comment on écrit une requête correcte dans ce projet. L’un est une prise de courant, l’autre est le mode d’emploi.

En revanche, skill et hook s’opposent bel et bien. Une skill est une information (l’agent peut ne pas l’appliquer. Un hook est une contrainte) le code s’exécute toujours. La règle de partage est détaillée dans l’article sur les hooks et le déterminisme d’un agent : si l’infraction est rattrapable, c’est une skill ; sinon, c’est un hook.

Ce qui fait qu’une skill se déclenche (ou pas)

C’est le point qui décide de tout, et il est presque toujours sous-estimé : la description.

L’agent ne lit pas le contenu complet de toutes les skills disponibles. Il lit leurs descriptions, et décide laquelle est pertinente. Une skill excellente avec une description vague ne sera jamais déclenchée.

Une bonne description dit quand utiliser la skill, pas ce qu’elle contient :

• Faible : « Conventions de composants. »
• Bonne : « Créer ou modifier un composant d’interface : structure des dossiers, nommage, gestion de l’état, styles. Déclencher dès qu’un composant est créé, déplacé ou refactorisé. »

La seconde décrit des situations. C’est ce que l’agent doit reconnaître.

Le piège inverse : une description qui couvre trop de cas se déclenche tout le temps, et tu as recréé le fichier de règles permanent avec une étape de plus.

Ce qu’il faut mettre dans une skill

Le critère est simple : ce que seul quelqu’un de ton équipe peut savoir.

Ce qui a sa place :

• Les conventions propres au projet : arborescence, nommage, découpage.
• Les décisions d’architecture et leurs raisons, le « pourquoi » évite qu’un agent les contourne en croyant bien faire.
• Les procédures internes : comment on ajoute une migration, comment on déploie, comment on écrit un test dans ce projet.
• Les pièges connus : « cette bibliothèque a un comportement inattendu ici, voilà le contournement ».

Ce qui n’a pas sa place :

• Ce que le modèle sait déjà. Expliquer la syntaxe d’un langage courant est du gaspillage de contexte.
• Ce qui doit être garanti : c’est un hook.
• Ce qui change tous les jours, la skill sera périmée avant d’être utile.
• Un historique de projet. Une skill dit ce qu’il faut faire maintenant, pas ce qui s’est passé en mars.

L’effet composé : skills et boilerplate

Le vrai gain n’apparaît pas sur un projet, mais sur le cinquième.

Une skill bien écrite est transportable. Les conventions de test, la méthode de découpage en modules, la procédure de mise en production : rien de tout cela n’est spécifique à une application donnée. Ce qui était une explication répétée à chaque projet devient un actif réutilisable.

Combiné à un boilerplate, un squelette de projet à jour, testé, avec la stack déjà en place, l’effet est net : le démarrage d’un projet passe de plusieurs jours de configuration à une base fonctionnelle immédiate, avec les méthodes de l’équipe déjà chargées.

C’est aussi ce qui règle le point le plus pénible du travail avec un agent, identifié lors des tests en local : l’initialisation de projet est la phase où l’IA se plante le plus, parce qu’elle mêle commandes interactives et versions changeantes. Partir d’un boilerplate supprime la phase.

Et à l’échelle d’une équipe, l’intérêt devient organisationnel : des skills communes, versionnées avec le code, garantissent que trois développeurs travaillant avec trois agents produisent du code cohérent. Sans elles, chacun a son prompt, ses habitudes, et la base devient hétérogène, exactement ce que l’architecture modulaire en silos cherche à éviter côté structure.

Comment écrire une skill qui sert vraiment

1. Pars d’une répétition réelle. La bonne skill est celle qui répond à une explication que tu as déjà donnée trois fois. Pas une skill « au cas où ».

2. Écris-la comme pour un nouveau développeur compétent. Il connaît le métier, il ne connaît pas vos choix. Tu n’expliques pas le langage, tu expliques vos conventions.

3. Donne le pourquoi avec le quoi. « On ne met pas de logique métier dans les composants » est une règle qu’on contourne. « On ne met pas de logique métier dans les composants, parce qu’elle doit être testable sans rendu » est une règle qu’on comprend, donc qu’on applique.

4. Reste court. Une skill de dix pages ne sera pas appliquée intégralement. Si le sujet est vaste, découpe en plusieurs skills avec des déclencheurs distincts.

5. Teste le déclenchement. Lance une tâche qui devrait l’activer et vérifie qu’elle l’est. Si non, le problème est dans la description, pas dans le contenu.

6. Versionne-la avec le code. Une skill dans un dossier personnel meurt avec la machine. Dans le dépôt, elle vit avec le projet et se relit comme du code.

Checklist : mettre en place des skills utiles

• Mon fichier de règles permanent fait moins de cinquante lignes.
• Chaque skill correspond à une explication que j’ai déjà donnée plusieurs fois.
• Chaque description dit quand déclencher, avec des situations concrètes.
• Aucune skill ne réexplique ce que le modèle sait déjà.
• Les règles non négociables sont des hooks, pas des skills.
• Chaque décision d’architecture est accompagnée de sa raison.
• J’ai vérifié en conditions réelles que chaque skill se déclenche.
• Les skills sont versionnées dans le dépôt, partagées par l’équipe.
• Les skills transportables sont regroupées avec le boilerplate de démarrage.

FAQ

Combien de skills faut-il pour un projet ?

Moins qu’on ne l’imagine. Trois à cinq skills bien ciblées couvrent la majorité des besoins d’un projet : conventions de code, procédure de test, procédure de déploiement, et les pièges spécifiques de la stack. Au-delà d’une dizaine, le risque est que l’agent choisisse mal entre des skills aux périmètres qui se recouvrent, c’est le signe qu’il faut fusionner ou clarifier les déclencheurs.

Une skill remplace-t-elle la documentation du projet ?

Non, les deux publics sont différents. La documentation explique à un humain pourquoi le système est ainsi fait, avec son historique et ses alternatives écartées. Une skill dit à un agent quoi faire maintenant, en quelques paragraphes actionnables. Il y a un recouvrement utile (le « pourquoi » a sa place dans les deux) mais une documentation copiée telle quelle en skill est presque toujours trop longue et trop narrative.

Faut-il préférer une skill ou un MCP pour accéder à un outil interne ?

Ce n’est pas une alternative. Si l’agent doit interagir avec un système, lire une base, créer un ticket, appeler une API, il lui faut un accès, donc un MCP ou un outil dédié. Si l’agent doit savoir comment s’en servir correctement dans ton contexte, il lui faut une skill. Les deux ensemble donnent un agent capable et discipliné ; l’accès seul donne un agent qui fait n’importe quoi avec la bonne prise en main technique.

Comment savoir si une skill est réellement utilisée ?

En observant le comportement, pas en le supposant. Deux vérifications simples : lancer une tâche qui devrait la déclencher et regarder si l’agent la charge, et relire le code produit pour vérifier que les conventions décrites sont respectées. Une skill qui ne change rien au résultat est soit mal déclenchée, problème de description, soit redondante avec ce que le modèle faisait déjà spontanément.

Conclusion

Les skills ne rendent pas un agent plus intelligent. Elles font quelque chose de plus utile : elles lui donnent ton contexte, au moment où il en a besoin, sans polluer le reste.

Le basculement mental est simple : arrête d’écrire des règles permanentes et commence à écrire des méthodes déclenchables. Ton fichier de règles maigrit, ton contexte reste propre, et surtout, ce que tu écris une fois profite à tous les projets suivants.

Commence par la prochaine explication que tu donneras deux fois à ton agent. Écris-la une bonne fois, avec un déclencheur clair. C’est ta première skill.

Ce sujet est développé dans l’épisode Radio Vibe Code #7, consacré à l’état des lieux des outils et des pratiques.