Vous me suivez depuis un certain temps, et j'ai commencé à mettre en place des workflows d'agent IA, pour le développement d'applications mobiles en kotlin, pour la rédaction d'articles, la création de tests unitaires sur un projet légacy et j'ai encore plein d'idées ...
Mais c'est en copiant des agents d'un workflow à un autre que je me suis dis, est ce qu'il y a moyen de mutualiser les ressources de chaque agents.
Et du coup les skills m'ont paru de suite évidente. Au lieu de décrire la compétence dans l'agent et donc de devoir le duppliquer dans x agents. Le mettre dans un skill. Et tous les agents utilisent ce même skill.
J'utilisais des skills du site skills.sh pour compléter les compétences de mes agents avec des connaissances externes comme dans matrix quand néo apprends les différentes formes de combat.
Je me suis donc mis à rechercher plus en profondeur sur les skills et je suis même arriver aux skills d'orchestration avancée (langchain).
Sans rentrer dans les détails je vais vous expliquer les avantages et les limites de claude pour l'utilisation de workflow d'agents IA.
Avant de continuer de lire la suite de l'article, je vous invite à vous inscrire à ma newsletter, pour connaître en avant première les futurs sujets traités chaque semaine.
Qu'est-ce qu'un skill dans un système multi-agents ?
Un skill est un format léger pour étendre les capacités des agents IA avec des connaissances spécialisées et des workflows. Concrètement, c'est un dossier contenant un fichier SKILL.md (metadata et instructions), accompagné optionnellement de scripts, références et assets que l'agent peut découvrir et utiliser à la demande.
La distinction fondamentale à comprendre : les skills représentent ce que l'agent sait, tandis que les tools représentent ce que l'agent fait. Si les tools étaient le moment où les agents ont appris à agir, les skills sont le moment où ils ont commencé à raisonner de manière cohérente.
| Aspect | Skills | Tools |
|---|---|---|
| Couche | Raisonnement interne | Actions externes |
| Rôle | Ce que l'agent sait | Ce que l'agent peut faire |
| Focus | Patterns de raisonnement, workflows cognitifs | Exécution, interaction environnement |
| Chargement | À la demande, ~100 tokens metadata | Toujours disponible |
Pensez aux skills comme des « manuels internes » que l'agent consulte selon le contexte, tandis que les tools sont ses « outils physiques » pour interagir avec le monde extérieur. Cette distinction posée, voyons pourquoi j'ai rapidement compris que les skills allaient bien au-delà du simple « DRY ».
Sept avantages architecturaux des skills (au-delà du DRY)
Quand j'ai commencé à structurer mes agents en skills, je cherchais simplement à éviter la duplication de code. Ce que j'ai découvert, c'est un pattern architectural complet. Selon Forrester, 75 % des entreprises échouent à construire des architectures agentiques seules. Les skills offrent une réponse structurelle à ce défi.
1. Encapsulation et abstraction
Un skill isole une capacité complexe derrière une interface simple. Dans mon projet, le skill french-typography (skill perso) encapsule quatre règles de typographie française (majuscules des titres, accents obligatoires, ponctuation, nombres) derrière une simple référence. L'agent qui rédige n'a pas besoin de connaître les détails d'implémentation : il charge le skill et applique les règles.
2. Versioning indépendant
Les skills évoluent indépendamment des agents et des modèles. Git-native par conception, ils permettent la traçabilité des changements, le rollback instantané et le feature branching pour les expérimentations. Dans mon cas, le skill mathieu-grenier-signature peut évoluer sans toucher à l'agent linkedin-teaser qui l'utilise.
3. Testabilité
Les skills isolés sont plus faciles à tester unitairement. La structure standardisée supporte un fichier test-cases.json pour l'évaluation automatisée et des datasets golden pour le benchmarking reproductible. Chaque mise à jour peut être validée par des tests de régression sans impacter le reste du système.
4. Composition dynamique
Les skills se découvrent et se chargent à la volée selon le contexte. C'est un pattern similaire aux microservices : composition plutôt que monolithe. Mon agent blog-writer charge french-typography uniquement quand le contenu est en français. Un même agent peut ainsi s'adapter à différents contextes sans modification de code.
5. Gestion des permissions et sécurité
Les politiques de sécurité s'appliquent au niveau du skill, pas de l'agent. Le principe du moindre privilège devient naturel : dans mon projet, windows-environment-check a accès aux ressources système, mais linkedin-post n'en a pas besoin et ne l'obtient pas. Cette granularité réduit la surface d'attaque.
6. Spécialisation métier
Les skills permettent de créer des bibliothèques métier réutilisables : comptabilité, RH, DevOps, ou dans mon cas, création de contenu. L'expertise se trouve encodée dans des fichiers version-contrôlés. Quand un expert quitte l'équipe, ses connaissances restent dans les skills. C'est de la préservation de savoir institutionnel.
7. Fallback et résilience
La logique de retry et de fallback s'encapsule dans chaque skill indépendamment. Le pattern circuit breaker devient applicable par skill, et un skill défaillant n'impacte pas les autres. Mon skill claude-usage-check illustre ce principe :
if command -v ccusage &> /dev/null; then
ccusage blocks --active --json
else
# Fallback sur le cache local
cat ~/.claude/scripts/statusline/data/usage-limits-cache.json 2>/dev/null || echo '{"status": "unknown"}'
fi
Ce skill continue de fonctionner même si l'outil principal ccusage est absent, grâce à un fallback sur le cache local. La résilience est intégrée dans la conception.
Agent d'orchestration avancé: LangGraph
LangGraph est un framework d'orchestration bas niveau développé par LangChain (python), conçu pour construire, gérer et déployer des agents à longue durée de vie et stateful. Il se distingue des approches classiques en permettant la création de graphes cycliques, souvent nécessaires pour les runtimes d'agents.
Architecture en graphe
Au cœur de LangGraph se trouve un système d'orchestration basé sur des DAG (Directed Acyclic Graphs). Les nœuds représentent des agents, fonctions ou points de décision, tandis que les arêtes dictent comment les données circulent entre eux. Latenode
LangGraph repose sur trois composants principaux :
1. State (État partagé) L'état est une structure de données partagée qui représente l'instantané actuel de votre application. AWS C'est la "mémoire de travail" du graphe.
2. Nodes (Nœuds) Les nœuds sont des fonctions Python qui encodent la logique de vos agents.
3. Edges (Arêtes) Les arêtes sont des fonctions Python qui déterminent quel nœud exécuter ensuite en fonction de l'état actuel. Elles peuvent être des branchements conditionnels ou des transitions fixes.
Comment utiliser l'agent d'orchestration LangGraph dans claude
Ton agent de session (Claude Code ou autre) agit comme le point d'entrée qui déclenche l'exécution du programme Python contenant le graphe LangGraph. Ensuite, c'est LangGraph qui prend le relais pour l'orchestration interne.
Ce que ça change par rapport à Claude natif :
| Aspect | Claude Code seul | Claude + LangGraph |
|---|---|---|
| Qui orchestre | Claude (via prompts) | LangGraph (code Python) |
| Cycles possibles | Non (limitation sous-agents) | Oui (natif) |
| État entre étapes | Contexte conversation | StateGraph explicite |
| Debugging | Logs texte | Traces visuelles, replay |
| Parallélisation | Manuelle | Send() natif |
L'ironie des coûts : Claude Pro vs API
Un point rarement abordé dans les discussions sur les frameworks multi-agents : le paradoxe économique. Vous payez un abonnement Claude Pro (~100 €/mois) qui inclut Claude Code avec un usage « illimité » dans certaines limites. Mais dès que vous voulez une orchestration plus sophistiquée avec LangGraph ou CrewAI, vous repassez sur l'API payante.
| Mode | Facturation | Contexte |
|---|---|---|
| Claude Pro (session) | ~100 €/mois, inclus | Claude Code, limites 5h |
| API Anthropic | Pay-per-token | Sonnet ~3 /Minput,15/Minput,15/M output |
| LangGraph/CrewAI | Passe par l'API | Cumulatif par appel |
Pourquoi cette situation ? Votre session Claude (via claude.ai ou Claude Code) n'est pas accessible programmatiquement. LangGraph utilise les intégrations LangChain qui font des appels HTTP à l'API :
from langchain_anthropic import ChatAnthropic
# Ceci appelle l'API Anthropic, PAS votre session Claude Pro
llm = ChatAnthropic(
model="claude-sonnet-4-20250514",
api_key="sk-ant-..." # Clé API requise
)
Un workflow multi-agents avec dix appels LLM par requête peut rapidement coûter cher. C'est une des raisons pour lesquelles beaucoup restent sur des workflows « plats » avec Claude Code malgré les limitations : Claude Code + Skills = inclus dans l'abonnement.
Des alternatives existent pour réduire les coûts si l'API devient nécessaire : Amazon Bedrock (parfois moins cher selon le volume), modèles mixtes (Haiku pour les tâches simples, Sonnet pour les décisions critiques), caching des réponses LLM, ou modèles open source via Ollama pour certains nœuds.
La limitation Claude Code qui force une meilleure architecture
Claude Code a une limitation importante : « Subagents cannot spawn other subagents. » Un sous-agent ne peut pas lancer d'autre sous-agent. Cette contrainte empêche les boucles infinies, mais interdit aussi les hiérarchies profondes d'agents.
Concrètement, cela signifie que l'orchestrateur doit gérer directement tous les agents. C'est le pattern « orchestrateur plat » :
Orchestrator → Agent 1
→ Agent 2
→ Agent 3
→ ...
Dans mon projet de création de contenu, cela donne cette structure :
content-orchestrator ├── [PRE-FLIGHT] @environment-monitor + @usage-monitor ├── [RESEARCH - PARALLEL] │ ├── @topic-researcher │ └── @seo-researcher ├── [PLANNING] @content-planner ├── [WRITING] @blog-writer (charge french-typography) ├── [REVIEW] @content-reviewer └── [LINKEDIN] @linkedin-teaser (charge linkedin-post + signature)
Comment les skills compensent cette limitation ? Au lieu d'imbriquer des agents, on imbrique des skills. La logique complexe réside dans les skills, pas dans les agents. Un agent peut charger plusieurs skills dynamiquement selon ses besoins. L'insight contre-intuitif : cette limitation m'a forcé à mieux structurer. Un orchestrateur plat avec des skills riches est plus facile à débugger qu'une hiérarchie profonde d'agents où les erreurs se propagent de façon imprévisible.
Conclusion
Ce qui a commencé comme une simple volonté d'éviter la duplication de code est devenu la colonne vertébrale de mon architecture multi-agents. Les skills ne sont pas un luxe technique : ils constituent un pattern architectural complet avec sept avantages majeurs (encapsulation, versioning, testabilité, composition, permissions, spécialisation, résilience).
La limitation de Claude Code qui interdit le nesting des sous-agents devient une force : elle pousse vers une architecture plate avec des skills riches, plus maintenable et plus facile à débugger. Et tout cela reste inclus dans un abonnement Claude, contrairement aux frameworks comme LangChain qui passent par l'API payante.
Mon conseil : Si vous débutez avec les agents IA, commencez par identifier une tâche répétitive. Encapsulez-la dans un skill. Vous découvrirez rapidement les autres avantages en chemin.
Qui suis je ?
Je suis Mathieu GRENIER, CTO d'Easystrat une startup de Montpellier, en France. Je manage une équipe d'une dizaine d'ingénieurs (Graphistes, IA, frontend, backend, devOps, AWS) en remote depuis le Japon.
J'ai aussi mon activité de freelance, où je conseille des entrepreneurs dans leurs projets d'application.
Avec mon expérience personnelle de plus de 15 ans en ESN, j'ai pu travailler pour un large panel d'entreprises de différentes tailles. Ma compréhension des problèmes métiers est une de mes grandes forces et permet à mes clients de pouvoir se projeter plus facilement.
L'essentiel de mon travail consiste à canaliser l'énergie des entrepreneurs sur l'essence même de leur projet.
La technologie, les méthodes, le management sont le cœur de mes compétences.
Vous pouvez me faire confiance sur ces points là.
Si vous voulez me parler d'un de vos projets, envoyez-moi un email avec vos disponibilités à : contact@mathieugrenier.fr
Tous les articles de ce blog sont écris par moi, même si je peux m'aider de l'IA pour illustrer mes propos. Mais jamais je ne fournis d'articles 100% IA.
Les limites de l'orchestration des workflows d'agents IA par claude