Agent Skills - personnaliser l’IA selon votre workflow

 (anthropic.com)
17 points par GN⁺ 2025-10-17 | 4 commentaires | Partager sur WhatsApp
  • Les Agent Skills d’Anthropic permettent d’étendre l’expertise de l’IA en fonction du flux de travail de l’utilisateur
  • Un Skill est un composant sous forme de dossier contenant des instructions, des scripts et des ressources, que Claude ne charge qu’au moment où la tâche l’exige
  • Ils apportent des capacités spécialisées pour des domaines de travail précis, comme la création de fichiers Excel et PowerPoint ou le respect d’un guide de marque
  • Les utilisateurs comme les développeurs peuvent créer eux-mêmes des Skills afin de les utiliser dans l’application Claude, Claude Code et l’API
  • Des fonctions de déploiement et d’administration à l’échelle de l’entreprise sont également prévues, ce qui en fera une base pour construire des workflows IA sur mesure

Vue d’ensemble des Skills et principe de fonctionnement

  • Grâce à la fonctionnalité Agent Skills, Claude peut utiliser des compétences personnalisées pour mieux exécuter des tâches spécifiques
  • Les Skills sont fournis sous forme de dossiers contenant des instructions, scripts et ressources, et Claude n’y accède que lorsqu’une tâche pertinente l’exige
  • Cette fonctionnalité permet d’exploiter Claude de manière bien plus puissante pour divers travaux spécialisés, comme la gestion de documents Excel ou le respect des chartes de marque d’une organisation
  • Les utilisateurs peuvent créer des Skills personnalisés afin de les utiliser de façon globale dans l’application Claude, Claude Code, l’API, etc.

Fonctionnement des Skills

  • Pendant l’exécution d’une tâche, Claude analyse tous les Skills disponibles via un algorithme afin d’identifier le plus pertinent
  • Lorsqu’un Skill correspond, Claude ne charge que le minimum d’informations et de fichiers nécessaires, ce qui préserve la rapidité tout en assurant des capacités d’exécution spécialisées
  • Caractéristiques des Skills
    • Composabilité : plusieurs Skills peuvent être utilisés ensemble comme une pile, et Claude ajuste automatiquement ceux qui sont nécessaires
    • Portabilité : ils sont rédigés dans le même format et peuvent être utilisés dans toute la gamme de produits Claude
    • Efficacité : seules les fonctions nécessaires sont chargées au moment opportun
    • Puissance : ils peuvent aussi inclure du code exécutable (p. ex. Python, Shell), ce qui permet de tirer parti de l’efficacité de la programmation traditionnelle
  • Les Skills sont conçus comme des supports d’onboarding personnalisés qui empaquettent l’expertise d’une organisation pour la transmettre à Claude, afin qu’il joue le rôle d’expert dans un domaine donné

Intégration avec les produits Claude

Claude Apps

  • Les utilisateurs Pro, Max, Team et Enterprise peuvent tous utiliser la fonctionnalité Skills
  • Divers Skills d’exemple sont fournis par défaut pour des usages généraux comme la rédaction de documents, et il est aussi possible de les personnaliser
  • Lorsque l’utilisateur saisit une tâche, Claude charge automatiquement le Skill approprié, et il est possible d’observer le fonctionnement du Skill même dans la chaîne de pensée
  • Le Skill skill-creator facilite la création de Skills grâce à un accompagnement conversationnel : questions sur le workflow, génération de l’arborescence de dossiers, formatage automatique de SKILL.md, bundling des ressources, etc.
  • Pour Team/Enterprise, un administrateur doit activer la fonctionnalité à l’échelle de l’organisation
  • Disponible depuis la page de paramètres

Claude Developer Platform (API)

  • Les requêtes Messages API et le nouvel endpoint /v1/skills permettent le versioning et le contrôle opérationnel des Skills personnalisés
  • L’utilisation des Skills nécessite la fonctionnalité bêta Code Execution Tool, qui fournit un environnement sécurisé d’exécution de code
  • Les Skills fournis par Anthropic permettent de créer et modifier des documents Excel, PowerPoint, Word et PDF à un niveau expert
  • Les développeurs peuvent créer des Skills personnalisés adaptés à leurs workflows spécifiques et étendre librement les usages de Claude
  • Claude Console permet de créer, consulter et mettre à niveau facilement les versions de Skills
  • Des ressources complémentaires sont disponibles dans la documentation et sur Anthropic Academy

Exemples d’usage chez les partenaires

  • Box : conversion automatique de contenus stockés en documents PowerPoint, Excel et Word, avec prise en charge d’une documentation automatisée conforme aux standards de l’organisation
  • Notion : transformation de questions complexes en actions immédiatement exécutables, avec réduction de l’effort d’ajustement des prompts
  • Canva : personnalisation des agents via les Skills pour automatiser la conception et produire du contenu de haute qualité à l’échelle des équipes
  • Rakuten : automatisation des processus financiers et comptables grâce aux Skills, traitement unifié de plusieurs feuilles de calcul et réduction du temps de génération des rapports de 1 jour à 1 heure

Intégration avec Claude Code

  • Claude Code prend en charge l’installation de Skills afin d’étendre l’expertise et les workflows des équipes
    • via le plugin marketplace anthropics/skills ou en ajoutant directement un dossier dans ~/.claude/skills
  • Des fonctions de partage et de collaboration entre équipes sont proposées via l’intégration aux systèmes de gestion de versions
  • Le Claude Agent SDK permet également de développer des agents personnalisés

Pour commencer

Feuille de route et points d’attention

  • À l’avenir, Anthropic prévoit de simplifier la création de Skills et de renforcer les fonctions de déploiement à l’échelle des organisations
  • Comme les Skills permettent à Claude d’exécuter du code, il ne faut utiliser que des Skills provenant de sources fiables
  • Il convient également de prêter attention à la protection des données et au maintien de la sécurité ; pour plus de détails, voir la documentation d’information

À lire aussi

4 commentaires

 
ahwjdekf 2025-10-21

On peut cuire une pomme de terre au four, la faire bouillir, la faire sauter, la mijoter, la réduire en purée...
 
ahwjdekf 2025-10-21

À chaque fois, on leur colle toutes sortes de noms ronflants. Au final, ça a toujours le même goût de patate.
 
GN⁺ 2025-10-17
Réactions sur Hacker News

  • On dirait qu’on va voir émerger pas mal de confusion conceptuelle autour de ChatGPT, Claude et autres, comme on l’a déjà vécu dans le développement frontend : maintenant on se retrouve avec une avalanche de notions comme outils, fonctions, skills, agents, sous-agents, commandes, apps, etc., et par-dessus ce chaos on voit se multiplier toutes sortes de frameworks « vibe »

    • Il ne faut pas non plus oublier les fonctionnalités liées à MCP. Oui, c’est bien le chaos, mais en dessous il y a quand même des concepts de base faciles à apprendre. Même quand de nouvelles fonctionnalités s’ajoutent, on peut les intégrer facilement à son modèle mental, ou même les ignorer complètement et fabriquer directement ses propres outils. Le modèle mental fondamental, c’est de faire tourner un LLM en boucle, de continuer à stocker l’historique de ce qui a été fait dans la session (= le contexte), et de lui permettre d’appeler des outils comme la lecture de fichiers, l’écriture, l’appel à bash, etc. On appelle aussi ça une « boucle d’agent », et on peut l’implémenter en une centaine de lignes de Python. Je recommande vraiment à tout développeur intéressé par les LLM d’en construire un lui-même. La première fois, ça ouvre vraiment les yeux. Une fois qu’on a créé soi-même un agent simple, même si un nouvel outil sort, on peut facilement expliquer comment il fonctionne du point de vue de l’implémentation. Par exemple, Claude Skills, c’est grosso modo : 1) plusieurs fichiers d’instructions pour le LLM 2) au démarrage, on parcourt seulement les skills disponibles et on ne met dans le contexte du LLM que de courtes descriptions 3) on explique au LLM comment utiliser les skills, et dans Claude on utilise l’outil bash 4) au moment d’utiliser réellement un skill, on fait « call bash » pour lire le fichier et exécuter le travail. Bien sûr, j’omets ici des détails importants comme la gestion des permissions, mais la structure de base, c’est ça
    • J’ai l’impression que l’écosystème devient maintenant tellement complexe qu’il pourrait s’effondrer sous son propre poids. Tout système ou toute plateforme dispose d’une sorte de budget total de complexité que les gens peuvent garder en tête au quotidien, et la manière dont on dépense ce budget est particulièrement importante. Quand le fournisseur d’une plateforme ajoute une nouvelle complexité, il la retranche de la valeur qu’on peut construire au-dessus. En ce moment, les fournisseurs ajoutent de la complexité à tout-va pour se différencier, mais au final ça ne fait qu’élever des barrières pour les clients qu’ils devraient justement attirer, tout en réduisant la vraie valeur qu’on peut bâtir sur la plateforme elle-même. Déjà maintenant, on a l’impression que des concepts très proches et redondants consomment ce nouveau budget de complexité sans apporter grand-chose en fonctionnalités réelles. En interne, on peut se convaincre à tort que « ce genre de fonctionnalité rendra l’apprentissage plus facile », alors qu’en pratique on risque de faire sortir autant de gens qu’on en attire, avec un bilan finalement peu favorable
    • Comme il s’agit d’une technologie entièrement nouvelle, il reste encore énormément de zones inconnues. C’était un problème similaire quand il fallait choisir des outils cloud ou des bibliothèques Python. C’est aussi pour ça que tout le monde n’est pas un early adopter. Il y a un coût mental réel à essayer de suivre tout ça
    • La boucle centrale est simple, mais le moindre framework qui permet d’expérimenter librement avec ces concepts impératifs a une vraie valeur. J’ai bien aimé pouvoir brancher directement Beads dans le framework, continuer à l’utiliser si ça marche bien et le retirer sinon. Ça vaut aussi le coup de regarder quelque chose comme toolkami
    • « Metastasizing » décrit vraiment bien le phénomène : ça s’accumule sans fin au-dessus des concepts existants

  • Je viens justement d’écrire un billet sur les skills : « Claude Skills est vraiment génial, c’est peut-être un changement encore plus important que MCP » lien vers l’article

    • Vous pensez qu’il y a un recouvrement entre Skills et AGENTS.md ? VSCode a aussi récemment introduit à titre expérimental une fonctionnalité de AGENTS.md imbriqués, donc c’est moins formalisé mais le concept semble partiellement se recouper lien vers la mise à jour de VSCode
    • Les skills ressemblent moins à une fonctionnalité qui devrait entrer dans une spécification rigide qu’à un design pattern, voire à une astuce de prompt engineering. En pratique, on pouvait déjà faire ça à l’intérieur de MCP. Moi, j’utilisais quelque chose du genre : « avant de commencer quoi que ce soit, cherche dans le skills MCP et lis les guides pertinents »
    • Je me demande à quel moment il faut distinguer un besoin de skill d’un besoin de construire carrément un projet

  • J’ai l’impression que la capacité de ce genre de système à bien résoudre des problèmes dépend surtout des résumés écrits dans les skills. Les humains, à mesure qu’ils accumulent de l’expérience, finissent par savoir quand utiliser telle ou telle compétence, alors que Claude repart à chaque fois en lisant à peine quelques explications de départ

    • Contrairement à l’humain, qui devient un utilisateur compétent grâce à l’expérience, un LLM ne peut au fond qu’imiter. C’est pourquoi Richard Sutton considère que les LLM n’évolueront pas jusqu’à l’AGI. Selon Sutton, l’AGI viendra de l’apprentissage par renforcement, tandis qu’un LLM (réseau neuronal) ne peut faire qu’imiter. Un LLM n’a pas le socle cognitif des objectifs et des conséquences de ses actions ; dans un LLM, un « skill » ressemble donc plutôt à un manuel de référence. Ce n’est pas de la même nature qu’une « compétence » qu’on peut appliquer de façon répétée pour développer un travail, un instrument ou une solution vidéo de Sutton
    • Au fond, c’est un problème de fenêtre de contexte. L’humain garde en mémoire, même imparfaitement, un contexte extrêmement large, mais quand on passe plus de 10 000 heures à maîtriser un domaine donné, on retient bien cette « technique » et on oublie le reste. Les LLM, eux, peuvent stocker et rappeler de manière fiable un contexte programmatique, mais il est beaucoup trop coûteux en temps et en argent de tout repasser en revue. Donc les Skills — ou plus précisément l’insertion de contexte — servent à ajuster manuellement les priorités de sortie. Même les modes de réflexion d’un LLM reviennent finalement à une réorganisation du contexte. Ce n’est peut-être pas vraiment « repartir de zéro à chaque fois ». Vu sous cet angle, l’usage des outils devient beaucoup plus simple
    • Je me demande si le fait que les LLM doivent repartir avec un nouveau point de départ à chaque fois n’est pas lié à l’infrastructure multi-tenant. Il est naturel qu’OpenAI ou Anthropic veuillent réutiliser serveurs et mémoire entre plusieurs utilisateurs. Je me demande s’il serait possible d’avoir une configuration « personnelle » en single-tenant, où le LLM se souviendrait de toutes les conversations passées
    • L’essentiel, pour accumuler richement des connaissances et des outils dans un LLM, c’est de lui faire remarquer quoi utiliser et à quel moment, et pour l’instant c’est quasiment une zone impossible
    • La plupart des expériences sont des informations générales, pas des éléments liés à un projet ou à une conversation. Un LLM devrait pouvoir démarrer avec ce type de connaissance, puis mémoriser et interroger séparément les informations spécifiques à un projet. Les humains consultent l’information à une vitesse incroyable, mais même si le LLM est plus lent, il peut quand même s’y référer presque en temps réel

  • C’est assez amusant que les « skills » de Claude ne fonctionnent vraiment bien que si les développeurs écrivent et maintiennent une vraie documentation. Beaucoup de développeurs ne gèrent déjà pas correctement la documentation du code lui-même, alors la documentation pour LLM semble encore plus difficile. Ça a peut-être du sens pour une petite minorité de développeurs avec un système de fichiers très bien rangé et une forte tolérance au risque, mais si quelqu’un est déjà aussi organisé, ne vaudrait-il pas mieux confier ces tâches ingrates à un junior dans une logique de formation plutôt qu’à un LLM ? De toute façon, il faudra quand même tout relire à la fin. Et comme la fenêtre de contexte est limitée, il est difficile de reproduire une vraie sensation de « compétence intériorisée » comme chez un humain. Si en plus on entraîne un LLM dédié, on finit par se retrouver lié à ce LLM à vie. Tout ça rend cette hypothèse du « scénario idéal où toutes les étoiles s’alignent à l’intérieur de l’organisation » assez amusante

    • Le fait qu’un LLM ait besoin de documentation développeur et de diverses infrastructures pour développeurs pros résumées dans cet article est en réalité une motivation très utile. Ça aide même à convaincre la direction
    • Les LLM récompensent davantage les développeurs qui écrivent bien, donc c’est peut-être aussi une raison pour laquelle certains développeurs n’aiment pas les LLM
    • Moi aussi je suis venu lire les commentaires, et on dirait que vous êtes le seul à avoir relevé ce point de vue. Au fond, les « Skills », c’est simplement de la documentation détaillée, et en pratique on a rarement écrit ce genre de documents pour chaque projet. Ce serait bien si les skills LLM amenaient vraiment tous les développeurs à écrire une documentation très détaillée, mais ça me paraît peu probable

  • Je me demande comment les sub agents, MCP, skills, etc. vont interagir ; j’ai l’impression qu’il y a pas mal de redondance. L’idée d’ajouter des capacités supplémentaires à Claude via une montée en gamme de la spécification ne me dérange pas, mais en pratique, quelle que soit l’approche, on finit tous plus ou moins au même niveau pour implémenter des fonctionnalités d’agent. Avant, avec MCP, il fallait du JSON, alors que dans Claude on peut juste déposer du Markdown dans des fichiers/dossiers, avec en plus des entrées multimodales, donc l’UX semble nettement meilleure

    • Claude Skills ressemble simplement aux prompts MCP spécification MCP prompts. Je ne vois pas vraiment pourquoi il fallait inventer un nouveau concept. Dans l’interface de chat, je comprends l’argument marketing, mais dans Claude Code ? Il y a déjà CLAUDE.md, donc ça laisse perplexe
    • Je trouve que les trois se complètent plutôt bien. MCP sert à encapsuler une API pour qu’un agent LLM puisse l’utiliser ; Skills sert à transmettre à l’agent, uniquement quand il en a besoin, des instructions supplémentaires d’une manière efficace du point de vue du contexte ; certaines de ces instructions peuvent aussi expliquer comment utiliser MCP. Les sub-agents, eux, constituent encore un autre pattern de gestion du contexte : l’agent principal envoie une mission à l’agent secondaire, qui peut utiliser au besoin skills et MCP pour économiser des tokens

  • Ce genre de fonctionnalités reste assez rafraîchissant. Dans mon projet, j’ai créé un sous-dossier bin/claude pour y mettre les scripts générés par Claude et autres éléments du même genre, puis j’ai bien documenté cet emplacement dans claude.md pour l’aider dans la recherche d’outils. En pratique, les performances étaient plutôt bonnes. En réalité, ce qu’il faudrait surtout, c’est un helper de gestion du contexte — du genre « lancer Claude avec cet ensemble de MCP, puis basculer vers cet autre ensemble de MCP » — mais pour l’instant je gère séparément un sous-répertoire (profil) par projet, et je lance claude une fois dans chacun. Dans cette structure, bin/claude joue bien son rôle : Claude comprend tout de suite comment analyser un dataset BigQuery donné ou où se trouvent les fichiers d’authentification. Je n’aurais jamais pensé utiliser le système de fichiers pour gérer des profils, et pourtant c’est finalement ce que je fais

    • Quand vous parlez de « helper de gestion du contexte », je me demande si ce n’est pas précisément ce que sont les sub agents

  • Je ne comprends pas pourquoi, dans ce type de démonstration, ils utilisent des exemples aussi simplistes que retourner ou recadrer une photo de chien, alors qu’il existe bien de meilleurs exemples d’usage convaincant des skills

    • Sur la page développeur, il y a un bien meilleur exemple de traitement de PDF documentation du skill PDF. En pratique, j’utilisais déjà dans Claude Code des fichiers Markdown de guide d’utilisation avec un tag @, donc le fait que ce soit maintenant automatisé est encore mieux
    • L’article Wikipédia "The purpose of a system is what it does" mérite qu’on s’y arrête un instant
    • Les deux problèmes que j’ai eus ce matin dans Claude à propos de la génération de fichiers .xlsx avaient tous deux leur solution dans cette documentation exemple de skill Excel
    • L’exemple de la photo de chien est finalement pensé comme une référence simple destinée au grand public

  • On a l’impression que l’adoption de Claude-skills se propage à une vitesse folle. Mardi, j’ai complètement accroché à l’article de présentation de « Superpowers » article de présentation, et j’ai aussi bien rangé les outils que j’avais déjà créés pour les emballer sous forme de skills que l’agent peut utiliser. Les retours sur l’open source deli-gator sont les bienvenus

    • La délégation à un agent est vraiment séduisante. Avec Linear, le contexte des issues est souvent beaucoup trop chargé : par exemple, je voudrais seulement la description de l’issue et le dernier commentaire, mais le MCP Linear récupère tous les commentaires et pollue le contexte

  • Vendredi dernier, j’avais révélé par erreur l’existence de Claude Skills un peu trop tôt, donc je suis content que ce soit enfin officiel billet de blog lié

    • « Si on démarre une nouvelle instance de Claude et qu’on lui demande de zipper l’intégralité du dossier /mnt/skills, ça marche vraiment ». Le fait que ce genre de hack soit désormais une réalité est à la fois fascinant et inquiétant. J’espère juste qu’il n’a pas accès à tout le système de fichiers ou aux binaires ; si jamais il peut aussi faire du SSH...
    • Le blog de Jesse est vraiment très actif en ce moment, merci à lui

  • Il y a tellement de choses — skills, plugins, marketplaces, connecteurs, add-ons, etc. — que ça devient difficile de suivre

    • À mon avis, pas besoin de suivre tout ça. Un peu comme les « best practices » en prompt engineering, ce ne sont que des solutions temporaires pour contourner des limitations passagères ; inutile d’y investir du temps jusqu’à ce que les performances réellement nécessaires soient intégrées directement dans les modèles de base. Dans quelques mois, beaucoup de ces choses auront disparu, donc ça ne vaut la peine de s’y intéresser que si on a un besoin urgent de performance
    • Il faut quand même comprendre pourquoi ils font ça. Du point de vue de l’entreprise, il faut bien produire quelque chose, alors même que le produit principal n’a pas encore tenu la promesse de « l’ère du chômage de masse ». C’est un signal envoyé moins aux utilisateurs qu’aux investisseurs : « on ne fait pas que payer les salaires des chercheurs sans rien faire, on fabrique aussi toutes sortes de produits et on fait tourner des données ». Ils ont en plus une base géante pour faire de l’A/B testing
    • Du point de vue de l’utilisateur, plus les fonctionnalités propriétaires des fournisseurs se multiplient, plus il y a de choses à apprendre et à configurer, et plus le vendor lock-in s’aggrave ; au final, c’est plutôt perdant. Mais pour les fournisseurs de modèles, continuer à sortir ce genre de fonctionnalités est aussi une manière de préserver la différenciation produit. Sans cela, ce qu’ils fabriquent deviendrait simplement une commodité
    • J’imagine que l’ajout de fonctionnalités va continuer jusqu’à ce que l’ambiance dans les équipes retombe
    • En réalité, je ne trouve pas ça si compliqué. Les plugins couvrent les commandes, les MCP, les subagents, et maintenant les Skills. Une marketplace, c’est simplement un endroit qui regroupe ce type de plugins