Arrête de construire des agents IA — Construis des skills à la place
J'ai passé trois mois l'année dernière à construire un agent IA personnalisé à partir de zéro. Des centaines de lignes de system prompts. Des définitions de tools soigneusement ajustées. De la logique de retry, de la gestion d'erreurs, des règles de formatage de sortie — tout le package. Ça marchait à merveille pour un workflow spécifique. Puis le client m'a demandé d'ajouter un deuxième workflow, et j'ai réalisé que j'avais construit un chef-d'œuvre incapable de grandir.
L'agent savait faire exactement une seule chose très bien. En ajouter une deuxième signifiait réécrire la moitié de l'architecture. En ajouter une troisième aurait signifié tout recommencer.
Ça te dit quelque chose ? Si tu as construit un agent IA quelconque cette année, tu as probablement touché ce mur. Ton agent est brillant pour sa tâche d'origine et complètement impuissant dès que tu le pousses en dehors de sa voie. J'appelais ça le « piège du spécialiste brillant » — et je n'arrivais pas à trouver comment le contourner jusqu'à ce que je voie Barry et Mahes présenter quelque chose qui a tout reconfiguré dans ma façon de penser le développement d'agents.
Ils n'ont pas construit un meilleur agent. Ils ont construit une meilleure façon d'enseigner aux agents. Et la différence entre ces deux idées, c'est l'écart entre là où la plupart des développeurs sont bloqués et là où tout ce domaine se dirige.
Pourquoi ton agent brillant est en réalité plutôt bête
Voici une expérience de pensée qui a changé ma façon d'aborder l'architecture des agents.
Prends la personne la plus intelligente que tu connais. Donne-lui une tâche qu'elle n'a jamais rencontrée — disons, remplir une déclaration d'impôt sur les sociétés en Allemagne, ou effectuer un traitement de canal. Son intelligence brute est toujours là. Sa capacité de raisonnement n'a pas changé. Mais elle va échouer de façon spectaculaire parce que l'intelligence sans connaissance procédurale, c'est juste de l'énergie potentielle sans endroit où aller.
C'est exactement ce qui se passe avec les agents IA en ce moment. Claude, GPT-4, Gemini — ces modèles sont des raisonneurs extraordinairement capables. Mais quand tu les déploies comme agents, tu lâches essentiellement un génie dans un poste qu'il ne connaît pas en lui disant « débrouille-toi ». Parfois ça marche. Souvent non. Et même quand ils réussissent, la qualité est inconsistante parce qu'ils raisonnent à partir des principes fondamentaux à chaque fois au lieu d'appliquer des procédures apprises.
Le développement d'agents traditionnel essaie de résoudre ça en bourrant tout dans le system prompt. Tu écris paragraphe après paragraphe d'instructions : « Quand l'utilisateur demande X, vérifie d'abord Y, puis formate la sortie en Z, et s'il y a une erreur, fais W. » J'ai écrit des system prompts qui étaient littéralement plus longs que le code qu'ils contrôlaient.
Le problème, ce n'est pas que cette approche ne marche pas. Elle marche — pour un agent qui fait une chose. Le problème, c'est qu'aucune de ces connaissances n'est transférable. Construis un deuxième agent pour une tâche différente et tu repars de zéro. Chaque instruction, chaque cas limite, chaque leçon durement acquise sur la gestion des échecs — verrouillée dans un seul fichier de prompt, invisible pour tout le reste de ton système.
Barry et Mahes ont articulé ce que je ressentais sans pouvoir le nommer : les agents ont de l'intelligence et des capacités, mais ils manquent d'expertise organisée. Ce sont des généralistes brillants capables de raisonner sur n'importe quoi mais qui n'ont rien maîtrisé. Et la solution n'est pas de construire des agents plus intelligents — c'est de donner aux agents un moyen d'acquérir, stocker et partager leur expertise.
Cette solution, ce sont les skills. Et l'architecture derrière est plus astucieuse qu'elle n'y paraît au premier abord.
Ce que sont vraiment les skills d'agents (et pourquoi ce ne sont pas juste des prompts améliorés)
Quand j'ai entendu « agent skills » pour la première fois, j'ai supposé que c'était un rebranding de templates de prompts. Ce n'est pas le cas. La différence est structurelle, et elle compte.
Un skill, c'est un dossier. C'est tout au niveau le plus basique — un répertoire contenant des fichiers qui encodent du savoir procédural. Mais la composition spécifique de ces fichiers, c'est là que le design devient intéressant :
Scripts (tools) : Du code exécutable qui donne à l'agent de nouvelles capacités. Un skill pour le web scraping pourrait inclure un script Python qui gère l'authentification, la pagination et le rate limiting. L'agent n'a pas besoin de comprendre comment scraper — il appelle le script.
Instructions en Markdown : Du savoir procédural écrit en langage naturel. Quand utiliser le skill, dans quel ordre effectuer les étapes, quels cas limites surveiller, comment formater les sorties. C'est là que vit l'expertise métier.
Assets : Fichiers de configuration, templates, données de référence, exemples de sorties — tout ce dont le skill a besoin pour faire son travail de manière consistante.
Voici le choix de design qui fait fonctionner cette architecture : la divulgation progressive. Quand Claude Code charge tes skills, il ne les envoie pas tous dans la fenêtre de contexte d'un coup. Il ne voit que les métadonnées — le nom du skill, une brève description et les conditions de déclenchement. Le contenu complet du skill ne se charge que quand l'agent en a réellement besoin.
Pourquoi c'est important ? La gestion de la fenêtre de contexte est la contrainte la plus importante dans les systèmes d'agents. Chaque token dépensé pour des instructions que tu n'utilises pas actuellement est un token volé au raisonnement sur la tâche en cours. La divulgation progressive signifie que tu peux avoir cinquante skills installés sans payer le coût de contexte pour les cinquante simultanément. L'agent voit un menu de capacités et ne tire la recette pertinente que quand il commence à cuisiner.
J'ai testé ça avec ma propre configuration. J'ai des skills pour le front-end design, l'audit SEO, la génération de contenu, l'analyse de sécurité et l'automatisation de déploiement. Claude Code me montre la liste quand je demande quels skills sont disponibles. Mais quand je dis « redesigne cette page », seul le contenu complet du skill de front-end design est chargé. Mon skill SEO reste tranquillement en arrière-plan, prêt mais sans consommer de tokens.
Compare ça avec l'approche du system prompt monolithique. Avec tout dans un seul prompt, tu paies le coût de contexte pour chaque capacité, que tu l'utilises ou non. C'est comme transporter tous les outils du magasin de bricolage dans tes poches au lieu d'aller au bon rayon quand tu en as besoin.
Mais la structure basée sur des dossiers débloque quelque chose d'encore plus important que l'efficacité du contexte — et c'est la partie que la plupart des gens n'ont pas encore captée.
Le vrai coup de maître : les skills sont du logiciel, pas des prompts
Parce que les skills sont juste des dossiers avec des fichiers, ils héritent de toutes les propriétés du logiciel qu'on sait déjà gérer.
Contrôle de version. Mets ton dossier de skills dans un dépôt Git et tu as un historique complet. Qui a changé quoi, quand, pourquoi. Reviens à la version de mardi dernier parce que la nouvelle a introduit un bug. Crée une branche pour un skill pour tester des modifications sans affecter la version principale. C'est du fondamental pour le logiciel, mais révolutionnaire pour le prompt engineering, qui a traditionnellement été « édite le prompt, espère que ça marche, prie pour te souvenir de ce que tu as changé. »
Partage et collaboration. Zippe un dossier de skill, envoie-le à un collègue, et il a exactement ta capacité. Pas de « copie ce prompt et ajuste-le pour ta config. » Pas de « assure-toi de changer aussi la config du modèle. » Le skill est autonome. Tout ce dont il a besoin est dans le dossier.
Composabilité. C'est le point crucial. Plusieurs skills peuvent coexister et se compléter mutuellement. Mon skill de front-end design gère les changements visuels. Mon skill SEO gère l'optimisation. Quand je demande à Claude de « redesigner cette page et corriger le SEO », les deux skills s'activent. Ils n'entrent pas en conflit parce que chacun opère dans son propre domaine avec ses propres instructions.
Je traite les skills comme des microservices pour le savoir des agents. Chaque skill a une responsabilité unique, une interface propre et aucune dépendance cachée envers d'autres skills. Quand j'ai besoin d'une nouvelle capacité, je ne modifie pas un skill existant — j'en crée un nouveau. Quand un skill devient obsolète, je supprime le dossier. Pas de refactoring nécessaire.
Cette analogie des microservices va plus loin que prévu. Dans le logiciel traditionnel, les microservices communiquent via des APIs. Dans l'architecture des skills, les skills communiquent à travers le raisonnement de l'agent — le modèle agit comme la couche d'orchestration, décidant quels skills invoquer et comment combiner leurs sorties. C'est une inversion élégante du schéma habituel.
Et l'écosystème qui se développe autour de ce concept avance plus vite que ce que j'anticipais. Laisse-moi te montrer ce qui existe réellement.
Les trois couches de l'écosystème de skills
Cinq semaines après le lancement, des milliers de skills existent déjà. Ils se répartissent en trois catégories qui révèlent beaucoup sur la direction de cette technologie.
Couche 1 : Skills fondamentaux. Ce sont des capacités génériques qui rendent les agents meilleurs dans les tâches courantes. Édition de documents, synthèse de recherche scientifique, analyse de données, revue de code. Vois ça comme la bibliothèque standard — les skills que la plupart des agents devraient probablement avoir installés. Le skill de front-end design que j'utilise a plus de 100 000 installations. Le skill d'audit SEO en a environ 19 000. Ces chiffres te disent quelque chose sur la demande.
Couche 2 : Skills tiers. C'est là que ça devient intéressant. Des entreprises construisent des skills pour leurs propres produits. Browserbase a créé un skill d'automatisation web qui permet à Claude de naviguer et interagir avec des pages web via leur infrastructure. Notion a construit un skill d'intégration workspace. Ce ne sont pas des skills génériques — ils sont construits spécifiquement par les équipes qui connaissent le mieux leurs outils.
Ce que je trouve convaincant dans les skills tiers, c'est l'alignement des incitations. Browserbase veut que les développeurs utilisent leur plateforme. Construire un skill Claude Code qui rend leur plateforme facile à utiliser est une distribution brillante. Le skill devient l'interface utilisateur, et Claude devient l'utilisateur. Je m'attends à ce que chaque outil développeur majeur livre un skill Claude Code dans les douze prochains mois.
Couche 3 : Skills entreprise. C'est la couche dont personne ne parle publiquement mais où se trouve le vrai argent. Les entreprises du Fortune 100 construisent des skills internes qui encodent leurs workflows spécifiques, bonnes pratiques, exigences de conformité et savoir institutionnel.
Imagine une société de services financiers qui construit un skill encodant ses procédures spécifiques d'évaluation des risques. Chaque analyste utilisant Claude Code accède au même savoir procédural — les mêmes checklists, les mêmes références réglementaires, les mêmes exigences de formatage. Les nouvelles recrues montent en compétence plus vite parce que le skill porte l'expertise qui ne vivait auparavant que dans la tête des employés seniors.
J'ai commencé à faire ça pour mes propres clients. Quand je livre un projet, j'inclus un dossier de skill qui encode les procédures de maintenance du projet. Comment déployer. Comment lancer les tests. Quelles sont les conventions de nommage. Où se trouvent les fichiers de configuration. L'équipe du client n'a pas besoin de mémoriser ma documentation — elle demande à Claude, et le skill fournit la réponse avec les commandes exactes à exécuter.
C'est de la gestion de savoir procédural dans sa forme la plus pure. Et ça résout un problème que j'ai vu des organisations affronter pendant toute ma carrière : comment préserver le savoir institutionnel quand les gens partent ?
Construire ton premier skill : le guide pratique
Assez de théorie. Voici comment construire un skill concrètement. Je vais te montrer comment j'en ai créé un le mois dernier — un skill de vérification de déploiement qui vérifie si un déploiement a réussi et signale les éventuels problèmes.
Étape 1 : Crée la structure de dossiers.
deployment-check/
├── skill.md
├── tools/
│ └── verify-deployment.sh
└── examples/
└── sample-output.md
Le fichier skill.md est le cerveau. Il contient les conditions de déclenchement, les instructions et le contexte :
# Deployment Verification Skill
## Trigger
Activate when the user asks to verify, check, or validate
a deployment, or after any deploy command completes.
## Instructions
1. Run the verify-deployment.sh script with the target URL
2. Check HTTP status codes for all critical endpoints
3. Verify SSL certificate validity
4. Compare response times against baseline
5. Check for error patterns in response bodies
6. Generate a summary report with pass/fail status
## Edge Cases
- If the site returns 503, wait 30 seconds and retry once
- If SSL check fails, note whether the cert is expired
or misconfigured
- If response times exceed 2x baseline, flag as warning
not failure
Étape 2 : Écris le script tool.
#!/bin/bash
# verify-deployment.sh
# Checks critical health indicators for a deployed site
TARGET_URL=$1
echo "## Deployment Verification Report"
echo "Target: $TARGET_URL"
echo "Timestamp: $(date -u +%Y-%m-%dT%H:%M:%SZ)"
echo ""
# Check HTTP status
STATUS=$(curl -s -o /dev/null -w "%{http_code}" "$TARGET_URL")
echo "### HTTP Status: $STATUS"
# Check SSL
SSL_EXPIRY=$(echo | openssl s_client -connect \
"${TARGET_URL#https://}:443" 2>/dev/null | \
openssl x509 -noout -enddate 2>/dev/null)
echo "### SSL: $SSL_EXPIRY"
# Check response time
RESPONSE_TIME=$(curl -s -o /dev/null \
-w "%{time_total}" "$TARGET_URL")
echo "### Response Time: ${RESPONSE_TIME}s"
Étape 3 : Teste-le.
Installe le skill dans ton environnement Claude Code et lance-le :
Verify the deployment at https://mysite.com
Claude détecte le déclencheur du skill, charge les instructions complètes, exécute le script de vérification et formate la sortie selon les instructions du skill. La première fois que j'ai lancé ça, il a détecté un certificat SSL qui expirait dans trois jours — quelque chose que j'aurais raté jusqu'à ce que les utilisateurs commencent à voir des avertissements dans leur navigateur.
Conseil pro : Commence tes skills simplement. Ma première version de ce skill était juste les instructions en markdown sans script — Claude exécutait les commandes curl lui-même en se basant sur les instructions procédurales. J'ai ajouté le script plus tard quand j'ai voulu un formatage de sortie plus consistant. Tu n'as pas besoin de sur-ingénierer tes skills dès le premier jour. Laisse-les évoluer en fonction de l'utilisation réelle.
L'architecture derrière le rideau : Skills + MCP
Une pièce de ce puzzle que je ne comprenais pas initialement, c'était comment les skills se rapportent aux serveurs MCP. Ils semblaient redondants — les deux étendent ce que Claude peut faire, alors quelle est la différence ?
Après avoir travaillé extensivement avec les deux, voici le modèle mental qui a fait tilt pour moi.
Les serveurs MCP (Model Context Protocol) gèrent la connectivité. C'est la plomberie qui permet à Claude de communiquer avec des systèmes externes — bases de données, APIs, systèmes de fichiers, services tiers. Un serveur MCP pour GitHub permet à Claude de lire des dépôts, créer des issues et ouvrir des pull requests. Un serveur MCP pour Slack permet à Claude d'envoyer des messages et de lire des canaux.
Les skills gèrent l'expertise. C'est le savoir qui dit à Claude quoi faire avec ces connexions et comment bien le faire.
Vois ça comme une cuisine. Les serveurs MCP sont les appareils — la cuisinière, le four, le mixeur. Les skills sont les recettes. Avoir une cuisinière ne fait pas de toi un chef. Avoir une recette ne cuisine pas le repas. Tu as besoin des deux.
En pratique, ça signifie que les skills dépendent souvent de serveurs MCP. Mon skill de vérification de déploiement utilise des commandes curl qui s'exécutent via l'accès shell de Claude. Une version plus sophistiquée pourrait utiliser un serveur MCP pour l'infrastructure cloud afin de vérifier la santé des conteneurs, valider les configurations du load balancer et interroger les APIs de monitoring. Le skill fournit le savoir procédural (« vérifie ces cinq choses dans cet ordre »), et les serveurs MCP fournissent les connexions (« voici comment atteindre l'API du load balancer »).
Cette architecture combinée tourne déjà en production dans des entreprises des services financiers et des sciences de la vie. Les skills encodent les procédures de conformité et les workflows d'analyse. Les serveurs MCP se connectent aux bases de données internes, aux APIs réglementaires et aux outils de reporting. L'agent orchestre le tout en se basant sur les instructions du skill.
Je pense que c'est l'architecture qui définira la prochaine génération de déploiements IA en entreprise. Pas des agents monolithiques avec tout intégré en dur, mais des agents légers avec de riches bibliothèques de skills et une large connectivité MCP.
Ce que la plupart des gens comprennent mal dans ce changement
Laisse-moi répondre à quelques idées que je vois constamment dans les discussions sur les skills d'agents.
« Les skills, c'est juste du prompt engineering avec des étapes en plus. » Non. Le prompt engineering, c'est écrire des instructions. Les skills, c'est packager de l'expertise dans une unité réutilisable, versionnable, partageable et composable. Ce packaging est tout l'intérêt. La différence entre une recette griffonnée sur une serviette et un livre de cuisine publié, ce n'est pas le contenu — c'est le format, la découvrabilité et la fiabilité. Même principe ici.
« Je n'ai pas besoin de skills parce que mon agent marche bien. » Ton agent marche bien pour ce qu'il fait actuellement. Les skills concernent ce qui vient ensuite. Quand ton boss demande à ton agent de gérer un nouveau workflow, tu réécris le system prompt ? Tu crées un deuxième agent ? Tu construis un routeur pour dispatcher entre les agents ? Les skills te permettent de simplement ajouter un dossier. La simplicité opérationnelle, c'est la fonctionnalité.
« Les non-techniques ne peuvent pas construire de skills. » Celle-là est en train d'être réfutée en temps réel. Le format d'instructions basé sur le markdown signifie que quiconque sait écrire des procédures claires peut créer un skill. J'ai vu une coordinatrice de recrutement — zéro background en développement — construire un skill qui standardise la façon dont Claude filtre les CV selon les critères spécifiques de son entreprise. Les scripts « tool » sont optionnels pour les skills qui n'ont pas besoin d'automatisation. Beaucoup de skills sont du pur savoir procédural en markdown, et ils fonctionnent étonnamment bien.
La seule critique avec laquelle je suis d'accord : le testing et l'évaluation des skills sont encore immatures. Quand tu écris du code, tu as des suites de tests, des linters, des vérificateurs de types. Quand tu écris un skill, comment tu vérifies qu'il fonctionne correctement ? Comment tu mesures si la version 2 est meilleure que la version 1 ? L'équipe derrière les skills a reconnu cette lacune et l'a listée comme priorité pour le développement futur. En attendant que ces outils existent, je teste mes skills à l'ancienne — je les essaie sur des tâches réelles et j'itère en fonction des résultats.
Ce qui se passe quand les agents construisent leurs propres skills
C'est là que ma réflexion devient spéculative — mais ancrée dans ce que j'observe déjà.
Claude Code peut créer des skills de manière autonome. Quand tu travailles avec Claude et qu'il découvre une procédure utile, il peut l'écrire comme un skill pour une utilisation future. J'ai vu ça arriver par accident. J'étais en train de débugger un problème de déploiement, guidant Claude à travers mon processus de diagnostic étape par étape. Après avoir résolu le problème, Claude m'a demandé si je voulais qu'il sauvegarde la procédure de diagnostic comme skill. J'ai dit oui. Maintenant, chaque fois que je rencontre un problème similaire, Claude connaît déjà les étapes de diagnostic.
C'est de l'apprentissage transférable rendu tangible. L'agent a vécu une situation, en a extrait le savoir procédural et l'a stocké dans un format qui persiste au-delà de la session en cours. Les conversations futures — même les futures versions de Claude — peuvent accéder à ce savoir instantanément.
L'analogie avec l'histoire de l'informatique est frappante et je ne pense pas que ce soit un hasard. Les modèles sont des processeurs — de la puissance de calcul brute. Les runtimes d'agents sont des systèmes d'exploitation — gérant les ressources et les processus autour du processeur. Les skills sont des applications — le logiciel qui résout les vrais problèmes et encode l'expertise réelle.
On assiste essentiellement au développement de la couche applicative de l'IA en temps réel. Et tout comme le développement logiciel s'est démocratisé au fil des décennies — du langage assembleur aux outils no-code — la création de skills est déjà sur cette trajectoire. Aujourd'hui, ça demande de comprendre les structures de dossiers et la syntaxe markdown. Demain, ça ne nécessitera probablement rien de plus que de montrer à un agent comment faire quelque chose et de dire « retiens ça. »
Tes douze prochaines heures
Voici ce que je veux que tu fasses avant demain. Choisis un workflow que tu fais de manière répétitive — ça peut être des vérifications de déploiement, des revues de code, du formatage de données, des procédures d'onboarding client, n'importe quoi que tu fais plus de deux fois par mois.
Écris-le comme un skill. Crée un dossier avec un fichier skill.md. Décris la condition de déclenchement. Liste les étapes. Note les cas limites. Tu n'as pas besoin de scripts tool pour ton premier skill. Juste le savoir procédural en markdown.
Installe-le et essaie-le.
Je te garantis que deux choses vont se passer. Premièrement, tu seras surpris de voir à quel point Claude suit la procédure — mieux que la plupart des humains qui suivent de la documentation écrite, honnêtement. Deuxièmement, tu penseras immédiatement à cinq autres workflows que tu veux convertir en skills.
C'est cette deuxième réaction qui est importante. Elle signifie que tu as arrêté de penser aux agents IA comme des produits que tu construis et que tu as commencé à les voir comme des plateformes que tu étends. Et ce changement de pensée — de construire des agents à construire des skills — c'est la différence entre se battre contre le plafond de complexité et le traverser.
L'agent que j'ai passé trois mois à construire l'année dernière ? Je l'ai reconstruit en sept skills. Chacun m'a pris moins d'une journée. Ensemble, ils font tout ce que l'agent original faisait, plus trois choses qu'il ne pouvait pas faire. Et quand le client demandera une nouvelle capacité le mois prochain, j'ajouterai un huitième skill au lieu de tout recommencer.
Ce n'est pas une amélioration incrémentale. C'est une façon fondamentalement différente de construire.
Travaillons ensemble
Tu cherches à construire des systèmes IA, automatiser des workflows ou faire évoluer ton infrastructure tech ? Je serais ravi de t'aider.
- Fiverr (builds & intégrations sur mesure) : fiverr.com/s/EgxYmWD
- Portfolio : mejba.me
- Ramlit Limited (solutions entreprise) : ramlit.com
- ColorPark (design & branding) : colorpark.io
- xCyberSecurity (services de sécurité) : xcybersecurity.io
