La bonne façon d’utiliser les compétences : 5 réflexions après la publication par Anthropic de sa méthodologie interne
TechFlow SélectionTechFlow Sélection
La bonne façon d’utiliser les compétences : 5 réflexions après la publication par Anthropic de sa méthodologie interne
Beaucoup de personnes utilisent Skill, mais ne le comprennent pas nécessairement vraiment.
Dédié à des analyses Web3 approfondiesAuteur : Ai Chan, spécialiste des produits IA
J’ai lu un billet de blog rédigé par l’équipe d’Anthropic intitulé « Lessons from building Claude Code: How we use skills ». Il s’agit probablement de la synthèse pratique la plus approfondie sur les « skills » que j’aie lue à ce jour.
Le concept de « skill » n’est pas en soi complexe, mais le concevoir et le mettre en œuvre efficacement s’avère bien plus difficile qu’il n’y paraît.
Je me souviens que, lorsque les « skills » ont commencé à faire leur apparition, tout le monde adorait créer des « skills » dédiés aux styles rédactionnels ou à l’écriture. L’idée était qu’en injectant simplement son propre style d’écriture dans un modèle, celui-ci produirait systématiquement des textes conformes à ce style.
Or, après avoir moi-même testé diverses approches, j’ai constaté que cela fonctionnait rarement comme prévu.
En effet, un « skill » relatif au style peut facilement contenir plusieurs milliers, voire des dizaines de milliers de caractères. Dès lors, le chargement d’un tel « skill » consomme une part substantielle du contexte disponible. Ce surcroît de contexte finit par altérer les capacités de raisonnement du modèle.
On observe alors fréquemment le scénario suivant : le style est effectivement reproduit, mais le contenu devient superficiel et les capacités d’analyse se dégradent.
Un autre cas courant se présente ainsi :
Lors de la rédaction d’un « skill », beaucoup insèrent des instructions pas à pas détaillées : « Étape 1 : faire ceci ; Étape 2 : faire cela ; Étape 3 : procéder ainsi… ». Or, lors de l’exécution, on constate que le modèle ne suit pas toujours ces étapes de façon stable.
Ce n’est qu’au fil du temps que j’ai compris que ces tâches répétitives sont souvent mieux formalisées sous forme de scripts plutôt que d’instructions longues et détaillées.
Après lecture de cet article d’Anthropic, ma principale prise de conscience est la suivante : si de nombreuses personnes utilisent bel et bien des « skills », peu d’entre elles en comprennent véritablement la nature profonde.
Un « skill » repose fondamentalement sur de l’ingénierie de contexte. Déterminer quand intégrer une connaissance directement dans un « skill », quand la structurer sous forme de références, quand la transformer en script exécutable, ou encore quand utiliser des « gotchas » pour contraindre le comportement du modèle — toutes ces décisions reposent sur une expérience accumulée.
Une fois que l’on a saisi les principes fondamentaux de fonctionnement des « skills », on réalise que les meilleurs d’entre eux ne cherchent pas à résoudre des problèmes liés aux prompts, mais bien à optimiser la gestion du contexte, à capitaliser sur l’expérience acquise et à favoriser la réutilisation des capacités.
Pour ceux qui souhaitent approfondir l’étude des « skills », je recommande vivement deux articles :
https://claude.com/blog/lessons-from-building-claude-code-how-we-use-skills
#01 Évitez le verbiage inutile
Un « skill » vise essentiellement à formaliser les « savoir-faire implicites » propres à une organisation. Il ne doit donc pas répéter des connaissances générales déjà intégrées au modèle. Ce qui a véritablement de la valeur, ce sont précisément les informations que le modèle ignore totalement.
Au sein d’Anthropic, on insiste régulièrement sur le fait que le cœur d’un « skill » réside dans la documentation des « gotchas » — c’est-à-dire des erreurs ou pièges fréquents.
Par exemple :
1. Cette table ne doit pas être triée selon le champ created_at ;
2. Un code de réponse HTTP 200 renvoyé par l’environnement staging ne signifie pas nécessairement que l’opération a réussi ;
3. Les identifiants request_id et trace_id désignent en réalité la même entité.
Ces informations résident typiquement dans l’expérience concrète des employés. Gardez donc toujours à l’esprit la nature fondamentale d’un « skill ».
Un « skill » = la mise par écrit de l’expérience des experts.
Grâce aux « skills », on transforme des savoir-faire dispersés dans les esprits de différents individus en connaissances organisées et réutilisables.
#02 Un « skill » est avant tout de l’ingénierie de contexte
Il s’agit sans doute là de l’une des idées les plus profondes développées par Anthropic.
Un « skill » n’est pas un simple fichier Markdown, mais un dossier complet. Pour ceux qui ont déjà utilisé des « skills », cette affirmation peut sembler évidente.
Pourtant, après y avoir réfléchi à plusieurs reprises ces derniers jours, j’ai progressivement pris conscience que ce choix de structure en dossier illustre précisément la philosophie de l’ingénierie de contexte.
Reconsidérons la structure type d’un « skill » :
skill/
├── SKILL.md
├── references/ &
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
