Ne construis pas des agents, construis des skills (la lecon qu'Anthropic donne en 16 minutes)
Deux ingenieurs Anthropic expliquent pourquoi les skills battent les agents custom. Resume, analyse et lecons pratiques du talk de Barry Zhang et Mahesh Murag.
Il y a un talk de 16 minutes qui vaut plus que des mois de tatonnements sur les agents IA. Barry Zhang et Mahesh Murag, deux ingenieurs Anthropic qui ont construit le systeme de Skills de Claude, posent un constat simple : on construit des agents la ou on devrait construire des skills.
Pas du marketing. Pas du hype. Des lecons concretes de gens qui buildent pour de vrai.
Voici ce qu’ils disent, pourquoi c’est important, et ce que ca change pour toi.
Le probleme : les agents sont intelligents mais incompetents
Barry Zhang pose une analogie qui tue. Tu dois faire ta declaration d’impots. Tu as le choix entre :
- Mahesh : QI de 300, genie mathematique, mais n’a jamais vu un formulaire fiscal de sa vie
- Barry : fiscaliste avec 15 ans d’experience
Tu choisis Barry a chaque fois. Et c’est exactement le probleme des agents IA aujourd’hui.
Les LLM ont le raisonnement. Ils ont la connectivite (MCP, outils, API). Mais ils n’ont pas l’expertise metier. Ils ne savent pas comment TON equipe fait les choses. Ils ne connaissent pas TES conventions. Ils ne retiennent pas ce qu’ils ont appris hier.
Resultat : tu passes ton temps a repeter les memes instructions, a corriger les memes erreurs, et a reconstruire des agents from scratch a chaque nouveau domaine.
La solution : les skills, pas les agents
Un skill, c’est quoi concretement ? C’est un dossier de fichiers qui package du savoir-faire procedurale. Markdown, scripts, assets, metadata. C’est tout.
Pas un framework complexe. Pas une API. Un dossier que n’importe qui peut creer, versionner avec Git, et partager.
La difference fondamentale avec un agent custom :
| Agent custom | Skill | |
|---|---|---|
| Cout | 500k$ par domaine | 10-20% d’un agent custom |
| Qui le cree | Ingenieurs IA | N’importe qui (meme non-tech) |
| Reutilisable | Non, couple a l’infra | Oui, portable partout |
| Maintenance | Rebuild complet si ca change | Update le fichier |
| Scalabilite | 1 agent = 1 domaine | 1 agent + N skills = N domaines |
L’architecture en 3 couches
Les speakers decrivent un stack emergent en 3 couches :
1. La boucle agent : Gere le contexte et le flux de tokens. C’est le “cerveau” generique.
2. L’environnement d’execution : Acces au systeme de fichiers et execution de code. C’est les “mains”.
3. La connectivite externe : Les serveurs MCP qui connectent aux outils et donnees. C’est les “sens”.
Et les skills ? C’est la couche application. Des centaines ou des milliers de skills disponibles pour un seul agent, charges en contexte uniquement quand ils sont necessaires.
C’est exactement l’analogie avec l’histoire de l’informatique :
- Modeles = Processeurs : Puissants mais limites seuls
- Runtime agent = Systeme d’exploitation : Orchestre les ressources
- Skills = Applications : La ou des millions de personnes resolvent des problemes concrets
Le concept cle : progressive disclosure
C’est la ou le design devient malin. Un skill n’est pas charge en entier dans le contexte de l’agent. Le systeme utilise le progressive disclosure :
- D’abord, seule la metadata du skill est visible (nom, description, quand l’utiliser)
- L’agent decide s’il a besoin de ce skill pour la tache en cours
- S’il en a besoin, le contenu complet (scripts, instructions) est charge
Resultat : le context window reste leger meme avec des centaines de skills disponibles. L’agent ne charge que ce dont il a besoin, quand il en a besoin.
Le code comme interface universelle
L’autre insight majeur du talk : le code est l’interface universelle pour l’execution des agents.
Donne a un LLM un acces au systeme de fichiers et l’execution de code, et une seule boucle agent peut tout gerer : analyse de donnees, appels API, automatisation, sans builds custom pour chaque cas d’usage.
Les scripts dans les skills sont auto-documentes, modifiables, et degradent beaucoup moins que des instructions statiques. Un script Python qui formate un slide sera reutilise a l’identique 100 fois. Une instruction en langage naturel sera reinterpretee differemment a chaque fois.
L’exemple concret : le formatage de slides
Barry raconte un cas reel. Claude ecrivait a chaque fois le meme script Python pour formater des slides. A chaque nouvelle session, il recrivait tout from scratch. Meme resultat, meme effort, zero memoire.
La solution : creer un skill qui stocke le script. Maintenant, Claude charge le skill, execute le script existant, et passe a la suite. Coherent, efficace, zero redundance.
C’est ca, la puissance des skills : transformer les patterns repetitifs en savoir-faire reutilisable.
L’ecosysteme qui emerge
En 5 semaines apres le lancement, des milliers de skills ont ete crees. Trois categories emergent :
Skills fondamentaux : Capacites generales ou specifiques a un domaine. Manipulation de documents, recherche scientifique, bioinformatique.
Skills partenaires : Des entreprises qui integrent leurs produits. Browserbase pour l’automatisation web, Notion pour la comprehension de workspace.
Skills entreprise : Specifiques a une organisation. Les Fortune 100 les utilisent comme playbooks organisationnels. Les equipes de productivite dev standardisent les conventions de code.
Et le plus surprenant : des non-techniques creent des skills. Finance, juridique, recrutement, comptabilite. Un skill peut etre aussi simple qu’un fichier SKILL.md bien ecrit.
Ce que ca change pour les builders
1. Arrete de reconstruire des agents
Si tu as 5 agents custom pour 5 domaines differents, tu as 5 bases de code a maintenir. Avec l’approche skills, tu as 1 agent generique + 5 skills. La maintenance est divisee par 5.
2. Package ton expertise, pas ton infra
La valeur n’est pas dans la boucle agent (tout le monde utilise la meme). La valeur est dans l’expertise metier que tu packages en skills. C’est ton moat.
3. Fais contribuer les non-techniques
Tes experts metier connaissent les process mieux que n’importe quel ingenieur IA. Donne-leur un template de skill et laisse-les packager leur savoir-faire. C’est 10x plus efficace que de faire traduire leur expertise par un dev.
4. Pense composabilite
Un skill seul resout un probleme. Plusieurs skills composes resolvent un workflow. L’agent orchestre, les skills executent. C’est la meme logique que les microservices, mais pour l’expertise.
5. Laisse l’agent generer ses propres skills
Le vision long terme d’Anthropic : Claude cree et raffine ses propres skills au fil du temps. Jour 1, il est generique. Jour 30, il connait ton projet, tes conventions, tes patterns. La connaissance s’accumule, pas dans un prompt qui grossit, mais dans des skills qui se raffinent.
Mon take
Ce talk confirme ce qu’on vit au quotidien avec Claude Code. Les skills (commandes custom, sub-agents specialises, fichiers CLAUDE.md) sont ce qui fait la difference entre un dev qui “utilise Claude” et un dev qui multiplie sa productivite par 10 avec Claude.
L’erreur que font la plupart des devs : ils pensent “agent” quand ils devraient penser “skill”. Ils construisent des systemes complexes quand ils devraient packager du savoir-faire simple.
Le talk dure 16 minutes. C’est le meilleur investissement de temps que tu feras cette semaine si tu bosses avec des agents IA.
Resume et analyse du talk “Don’t Build Agents, Build Skills Instead” de Barry Zhang et Mahesh Murag (Anthropic), presente a l’AI Engineering Code Summit. Voir la video.
Pierre Rondeau
Développeur et indie builder. Je construis des produits et automatisations avec l'IA. Créateur de Claude Hub.
LinkedIn