Un skill, tous les agents

Blog · 5 min de lecture

Plus personne n'utilise exactement un seul agent IA. Vous écrivez du code avec un outil, vous le relisez avec un autre, et vous êtes probablement à un mauvais après-midi d'en essayer un troisième parce qu'un collègue ne jure que par lui. C'est très bien — c'est le signe d'un marché sain. Ce qui l'est moins, c'est l'effet sur les instructions que vous avez soigneusement écrites pour l'un d'eux.

Imaginons que vous ayez écrit un skill vraiment réussi : une check-list de revue de code, un guide d'intervention en cas d'incident, une charte maison sur la façon dont votre équipe veut voir rédigés les messages de commit. Si ce skill n'existe que sous forme de bloc de texte collé dans les réglages d'un outil, il est devenu, en pratique, that tool's skill. L'utiliser ailleurs suppose de le retaper, et le retaper garantit qu'il divergera — une correction ici, un ajustement là, jusqu'à ce que « le skill » soit en réalité trois skills légèrement différentes qui partagent une origine commune.

L'instruction ne devrait pas se soucier de qui la lit

C'est un problème résolu dans toutes les autres couches du logiciel. Une fonction bien écrite ne se soucie pas de qui l'appelle. Une API bien conçue ne se soucie pas de savoir si le client est un navigateur ou un script. Les instructions que vous donnez à un agent IA sont, fonctionnellement, une API de comportement — rien ne justifie qu'elles soient plus étroitement liées à Claude, ChatGPT ou Codex qu'un point d'accès REST ne l'est à un navigateur particulier.

Ce qui rend la chose possible aujourd'hui, c'est que les clients eux-mêmes ont convergé vers une manière commune de récupérer outils et contexte : MCP. Tout client qui le parle peut demander à un serveur « quelles skills as-tu ? » puis « donne-moi celui-ci », sans que le serveur ait à savoir quel agent précis l'interroge. C'est sur cette jointure que vit un skill portable — non pas un plugin conçu pour un outil, mais du contenu servi via un protocole que plusieurs outils parlent déjà.

Ce qui change quand le skill devient la source de vérité

Rangez le skill à un seul endroit, et chaque client devient un lecteur plutôt qu'une copie. Corrigez une fois un défaut dans la check-list de revue, et le prochain agent qui la charge — quel qu'il soit — bénéficie de la correction. Personne n'a à se souvenir laquelle de trois copies collées est la bonne, puisqu'il n'y en a qu'une.

La portabilité n'est pas un confort pour un skill. C'est la différence entre une instruction que l'on maintient et une que l'on réécrit sans cesse.

C'est toute l'idée de Skilnu : les skills vivent dans un registre, servies via MCP, pour que Claude, ChatGPT, Codex — ou ce que vous utiliserez l'an prochain — chargent toutes la même, dans sa version du jour, et non celui que quelqu'un a pensé à mettre à jour.

Essayez

Si vous préférez la mécanique à l'argumentaire, le tutoriel Use one skill in Claude, ChatGPT, and Codex montre comment connecter un seul skill aux trois en quelques minutes.