L’écosystème des agents souffre d’un problème de terminologie qui masque un vrai choix architectural.« Tools » et « skills » sont utilisés indifféremment dans les présentations marketing et les conférences, mais ils représentent des approches fondamentalement différentes pour étendre les capacités des agents. Comprendre cette distinction, c’est la différence entre des agents qui fonctionnent en démo et des agents qui tiennent en production.
Mais voici la vérité gênante qui se perd dans les débats sémantiques : du point de vue de l’agent, tout se résume à des tools. Skills, toolkits, fonctions, serveurs MCP : tout finit comme des options présentées au modèle avec une description et un moyen de les invoquer. La distinction compte pour la façon dont vous organisez et construisez vos capacités. Elle compte bien moins que de savoir si ces capacités peuvent réellement s’exécuter de façon sécurisée en production.
La distinction fondamentale : exécution versus expertise
Un tool est une fonction exécutable avec des entrées, des sorties et des effets de bord définis. Quand un agent appelle un tool, quelque chose se passe dans le monde réel : une base de données est interrogée, une API est appelée, un fichier est écrit. Les tools sont les mains de l’agent : ils font des choses.
Un skill est une expertise packagée qui façonne la façon dont un agent pense et aborde les problèmes. Les skills n’exécutent pas de code directement ; ils fournissent du contexte, des instructions, des connaissances métier et des patterns comportementaux qui rendent les agents plus efficaces sur des tâches spécifiques. Les skills sont la formation de l’agent : ils savent des choses.
Cette distinction détermine votre architecture, votre modèle de déploiement, votre surface de sécurité, et en fin de compte si votre agent peut accomplir un travail utile.
Comment les grands acteurs définissent ces concepts
Anthropic trace la ligne la plus nette entre tools et skills. Leur Model Context Protocol (MCP) gère les tools, des fonctions exécutables exposées via une architecture client-serveur utilisant JSON-RPC 2.0. Séparément, leur fonctionnalité Agent Skills propose ce qu’ils décrivent comme des « ressources composables pour Claude, transformant des agents généralistes en agents spécialisés ». Les skills sont organisés sous forme de dossiers contenant instructions, templates, scripts et matériaux de référence que les agents découvrent et chargent dynamiquement. Point crucial : les skills étendent les capacités de Claude sans l’overhead protocolaire de MCP, se comportant essentiellement comme des prompts sophistiqués avec des fichiers associés.
OpenAI n’utilise pas formellement la terminologie « skills ». Leur paradigme est entièrement basé sur les tools. Le function calling permet aux modèles de générer des arguments structurés correspondant aux schémas définis par les développeurs, et leur évolution de « functions » vers « tools » (décembre 2023) signalait l’intention de supporter plusieurs types de capacités au-delà des simples fonctions appelables. L’Agents SDK fournit orchestration, handoffs et guardrails, mais l’unité de capacité reste le tool.
LangChain utilise une hiérarchie à trois niveaux : les tools sont des fonctions que les agents peuvent invoquer ; les toolkits sont des collections de tools liés à un objectif commun ; et les agents combinent des LLM avec des tools dans des boucles de raisonnement. Comme OpenAI, LangChain ne distingue pas formellement skills et tools. L’interface bind_tools fonctionne de manière identique entre les fournisseurs, traitant tout comme des fonctions appelables quelle que soit la complexité sous-jacente.
| Fournisseur
|
Concept « Tool »
|
Concept « Skill »
| | | |
|
Anthropic
|
MCP tools (exécutables, basés sur protocole)
|
Agent Skills (packages d’expertise basés sur des prompts)
| |
OpenAI
|
Functions/tools (exécutables, définis par schéma)
|
Non formellement distingué
| |
LangChain
|
Tools + Toolkits (exécutables, indépendants du fournisseur)
|
Non formellement distingué
|
Pourquoi cette distinction compte vraiment
Le débat tools versus skills renvoie à une question architecturale plus profonde : où réside l’intelligence de l’agent ?
Dans une architecture centrée sur les tools, l’agent est relativement générique. L’intelligence vient de tools bien conçus avec des interfaces claires. Le rôle de l’agent est la sélection et l’orchestration des tools. C’est le modèle OpenAI et LangChain : donner de bons tools à un modèle capable et le laisser trouver comment les utiliser.
Dans une architecture centrée sur les skills, l’intelligence est intégrée à l’agent lui-même via des connaissances spécialisées et des patterns comportementaux. Les tools deviennent des utilitaires plus simples ; l’agent sait comment aborder les problèmes dans des domaines spécifiques. C’est le modèle Agent Skills d’Anthropic : l’agent porte une expertise, pas seulement des capacités.
Les implications pratiques sont significatives :
L’économie des tokens favorise les skills. L’équipe engineering d’Anthropic a découvert qu’un seul serveur MCP GitHub peut exposer plus de quatre-vingt-dix tools, consommant plus de 50 000 tokens de schémas JSON avant même que le modèle commence à raisonner. Les skills, basés sur des prompts, peuvent encoder l’expertise métier sans l’overhead des schémas. Leur approche « Code Execution with MCP » a réduit un workflow de 150 000 tokens à environ 2 000 tokens en demandant aux agents d’écrire du code pour appeler les tools plutôt que de charger toutes les définitions en amont.
Les surfaces d’attaque diffèrent radicalement. Les tools exigent authentification, autorisation et un périmètre soigneusement délimité sur ce que les agents peuvent faire. Le chercheur en sécurité Simon Willison a identifié des vulnérabilités MCP fondamentales, notamment les rug pulls (tools modifiant leurs définitions après installation) et le tool shadowing (serveurs malveillants interceptant les appels vers des serveurs de confiance). Les skills, basés sur des prompts, n’ont pas la même surface d’attaque, mais ils ne peuvent pas non plus faire quoi que ce soit sans tools pour exécuter. Et c’est là le nœud du problème : à terme, tout agent utile doit s’authentifier auprès de services externes et effectuer de vraies actions. Le vocabulaire que vous utilisez pour décrire les capacités importe moins que de savoir si vous avez résolu le problème d’authentification.
La portabilité varie. Les MCP tools sont théoriquement portables sur tout hôte compatible MCP. Les skills sont actuellement spécifiques à Anthropic. Si vous construisez des agents multi-modèles ou souhaitez une flexibilité fournisseur, les tools offrent une interface plus standardisée.
La dimension des tools locaux
Orthogonale au débat skills-versus-tools, la question est de savoir où les tools s’exécutent. Les tools locaux tournent sur la même machine que l’agent (ou dans l’environnement de l’utilisateur), tandis que les tools distants tournent sur des serveurs externes accessibles via des appels réseau.
Les serveurs MCP locaux utilisant le transport standard input/output maintiennent les données sur l’appareil avec une latence minimale, permettant le fonctionnement hors ligne et évitant les dépendances réseau. Les serveurs distants permettent un déploiement sans configuration et un accès partagé entre équipes, mais introduisent de la latence et exigent une authentification OAuth 2.1 correcte.
C’est plus important que la plupart des équipes ne le réalisent. Les tools locaux peuvent accéder au système de fichiers de l’utilisateur, aux variables d’environnement et aux services locaux. Les tools distants nécessitent un partage de données explicite. Les implications en matière de sécurité et de confidentialité jouent dans les deux sens. Les tools locaux ont plus d’accès mais moins d’exposition ; les tools distants sont plus contenus mais exigent de faire confiance à l’opérateur du serveur.
C’est ici que le débat skills-versus-tools révèle ses limites : que vous appeliez quelque chose un « skill » ou un « tool », s’il doit toucher Gmail, Slack, Salesforce ou tout autre service authentifié, vous faites face à la même complexité OAuth. Quatre-vingt-dix-neuf pour cent des serveurs MCP sont aujourd’hui construits pour un usage mono-utilisateur. Dès que vous avez besoin de plusieurs utilisateurs finaux s’authentifiant sur leurs propres comptes (exigence de base pour tout SaaS en production), les débats terminologiques deviennent hors sujet. Ce qui compte, c’est une infrastructure qui gère l’auth correctement.
Ce que les équipes en production ont appris
Les équipes qui livrent réellement des agents ont convergé vers quelques enseignements contre-intuitifs :
La conception des tools prime sur leur nombre. Les agents de coding performants utilisent souvent moins de dix tools. La tentation d’exposer toutes les capacités possibles se retourne contre vous : les modèles se perdent, les budgets de tokens explosent, les taux d’erreur grimpent. L’équipe engineering d’Anthropic a constaté qu’imposer des chemins de fichiers absolus éliminait toute une classe d’erreurs qui affectait les agents utilisant des chemins relatifs après des changements de répertoire. Les petites décisions d’interface s’accumulent.
Les skills comblent les lacunes que les tools ne peuvent pas. Quand Monte Carlo a construit des agents en production, ils ont découvert que les ingénieurs et les data scientists devaient coopérer étroitement, en journalisant et en marquant chaque appel LLM pour tracer quelles tâches d’agent causaient des problèmes. Le « skill » ici n’était pas un tool. C’était une connaissance organisationnelle sur les patterns de débogage, les heuristiques métier et les modes de défaillance. Ce type d’expertise ne rentre pas proprement dans une signature de fonction.
Le piège de la complexité des frameworks est bien réel. Cognition (Devin) met explicitement en garde contre les architectures multi-agents : « En 2025, faire tourner plusieurs agents en collaboration ne produit que des systèmes fragiles. » Leur recommandation : des agents mono-thread avec compression de contexte. Les implémentations les plus réussies n’utilisent pas de frameworks complexes. Elles construisent avec des patterns simples et composables.
L’autorisation est le tueur de production. C’est la leçon qui ne reçoit pas assez d’attention. Les équipes passent des mois à construire une logique d’agent sophistiquée, à concevoir soigneusement les interfaces de tools, à débattre des architectures skills versus tools. Et puis elles se heurtent à un mur au moment de livrer. L’agent ne peut pas vraiment faire quoi que ce soit, parce que se connecter à de vrais services avec de vraies credentials utilisateur est un problème d’une toute autre nature. Environ 70 % des projets IA n’atteignent pas la production, et la complexité de l’autorisation en est une cause principale. C’est particulièrement vrai pour les environnements à enjeux élevés, comme l’intégration de l’IA dans les workflows de production qui exigent un scoping granulaire strict avant que les agents puissent accéder aux tools de production en toute sécurité.
Un cadre pour choisir
Quand faut-il investir dans les tools, les skills, ou les deux ?
Investissez dans les tools quand :
- Vos agents doivent agir dans le monde (APIs, bases de données, systèmes de fichiers)
- Vous souhaitez des capacités qui fonctionnent sur différents modèles et frameworks
- La capacité est bien définie avec des entrées et sorties claires
- Vous avez besoin de pistes d’audit et de contrôle d’accès sur ce que les agents peuvent faire
Investissez dans les skills quand :
- Vous avez besoin d’une expertise métier qui façonne comment les agents abordent les problèmes
- L’efficacité en tokens est importante (tools complexes avec de nombreuses options)
- Vous construisez spécifiquement sur Claude et pouvez utiliser les Agent Skills
- La connaissance porte sur le jugement et l’approche, pas seulement l’exécution
Investissez dans les deux quand :
- Vous construisez des systèmes de production où les agents ont besoin à la fois d’expertise et de capacités d’action
- Dans des domaines où savoir quoi faire (skill) est aussi important que le faire (tool)
- Vous voulez que les skills guident la sélection et les patterns d’utilisation des tools
Mais quelle que soit la voie choisie, investissez dans une infrastructure d’authentification en premier. L’architecture skill/tool la plus élégante est inutile si votre agent ne peut pas accéder de façon sécurisée aux services dont il a besoin pour agir.
Ce qu’il faut vraiment retenir
La distinction skills-versus-tools n’est pas un concours. C’est la reconnaissance que les capacités d’un agent viennent de deux sources différentes : ce que les agents peuvent faire (tools) et ce que les agents savent (skills).
La confusion que l’industrie entretient entre ces concepts masque un vrai choix architectural. Les équipes qui traitent tout comme des tools finissent avec des fenêtres de contexte gonflées, des modèles perdus et des intégrations fragiles. Les équipes qui investissent uniquement dans les skills finissent avec des agents qui raisonnent brillamment mais ne peuvent rien faire concrètement.
Les équipes qui s’en sortent réfléchissent soigneusement à quelles capacités appartiennent à quelle couche. Elles maintiennent un nombre de tools réduit et des interfaces propres. Elles encodent l’expertise métier dans les skills plutôt que d’espérer que les modèles le déduiront des descriptions de tools. Et elles reconnaissent que les guerres de protocoles (MCP versus function calling versus ce qui vient ensuite) comptent moins que la question fondamentale de savoir où réside l’intelligence dans leur architecture d’agent.
Mais du point de vue du modèle, tout ce que vous lui donnez n’est qu’une option à choisir. Que vous appeliez ça un skill, un tool, une fonction ou un serveur MCP, l’agent voit une description et un moyen de l’invoquer. La taxonomie compte pour votre modèle mental et l’organisation du code. Elle ne change pas ce que l’agent perçoit.
Ce qui change réellement la capacité de l’agent à être utile, c’est s’il peut effectivement exécuter. Et c’est un problème d’infrastructure, pas de terminologie.
Où s’inscrit Arcade.dev
Chez Arcade, nous avons pris une position délibérément simple sur le débat skills-versus-tools : tout est des tools.
Non pas parce que les distinctions architecturales n’existent pas, mais parce que du point de vue de l’agent, tout finit comme une option à sélectionner et invoquer. Le vrai défi n’est pas de décider comment nommer vos capacités. C’est de les faire fonctionner en production avec de vrais utilisateurs, de vraies credentials et de vraies exigences de sécurité.
C’est pourquoi nous avons conçu Arcade comme un runtime centré sur l’authentification. Nous gérons l’OAuth pour plus de 100 services (Gmail, Slack, GitHub, Salesforce et bien d’autres) afin que votre agent puisse prendre de vraies actions sans que vous ayez à construire une gestion complexe des credentials. Les tokens ne transitent jamais par le LLM. L’autorisation se fait en juste-à-temps avec un scoping au moindre privilège, une exigence critique pour construire des assistants IA sécurisés prêts pour la production. Que vous exposiez vos capacités via MCP, LangChain, le SDK d’OpenAI ou des appels API directs, la couche d’auth fonctionne de la même façon.
L’équipe fondatrice a passé sa carrière sur l’identité et l’infrastructure. Quand nous avons commencé à construire nos propres agents, nous avons heurté le même mur que tout le monde : l’agent était intelligent, les tools bien conçus, mais se connecter aux services de façon sécurisée était un problème d’une toute autre nature. Alors nous avons construit la couche runtime que nous aurions voulu trouver.
Notre position sur le débat skills-versus-tools : arrêtez de débattre et commencez à livrer. Utilisez l’abstraction qui fait sens pour votre domaine. Appelez les choses comme vous voulez. Mais investissez dans une infrastructure qui permet à votre agent de prendre des actions de façon sécurisée, à l’échelle, avec une authentification utilisateur correcte.
C’est ce qui fait la différence entre une démo et un produit.
