Outils statiques, MCP, A2A, Sandbox, Skills : anatomie de l'outillage agentique

Le MCP, l'A2A, les sandboxes d'agents, les Skills : en moins de deux ans, chaque grand fournisseur de modèles a publié sa propre brique d'outillage agentique. Beaucoup résolvent des problèmes qui se recoupent, et choisir le bon outil pour la tâche demande davantage qu'une simple comparaison de fonctionnalités.

Cet article parcourt une architecture cible illustrative qui réunit chaque composant : outils statiques (Static Tools), outils dynamiques (MCP), agents délégués (A2A), exécution en sandbox et Skills. Sont-ils réellement des alternatives les uns aux autres, ou bien des pièces d'un même système ? Nous les examinerons un à un et expliquerons : ce qu'ils sont, là où ils excellent et là où ils atteignent leurs limites, le tout illustré par des exemples concrets et des cas d'usage.

Figure 1 — Architecture cible illustrative réunissant les composants de l'outillage agentique.

TL;DR

• Un outil pour chaque besoin : Les outils statiques suffisent tant qu'un seul workflow appelle la fonction. Vous passez au MCP (outils dynamiques) dès qu'il faut mutualiser et sécuriser cet accès pour plusieurs consommateurs ou profils.

• Déléguer, ou simplement appeler : Réservez le protocole A2A aux cas où l'autre partie raisonne sur plusieurs étapes et détient son propre état. Si un seul appel bien décrit suffit, un serveur MCP fait le travail.

• Le sandbox, dernier recours assumé : Vous donnez carte blanche à l'agent dans un environnement isolé, au prix d'une vraie charge opérationnelle. On y vient quand l'agent doit décider lui-même comment naviguer, pas quand une fonction bien délimitée y parviendrait.

• Contexte à la demande : Les Skills sont le manuel d'instructions de l'agent : règles métier et procédures chargées au moment précis où elles sont nécessaires, sans alourdir la fenêtre de contexte.

• L'architecture cible : Ces technologies se complètent et s'empilent pour former un système dont l'équilibre repose sur deux axes : l'autonomie accordée à l'agent et la propriété (ownership) des capacités.

Un agent n'est qu'une boucle de texte

Retirez le battage médiatique et un « agent » n'est qu'un processus qui tourne quelque part : un script Python, un conteneur, une boucle de runtime. Ce qu'il fait est presque trompeusement simple. Il gère une fenêtre de contexte contenant son rôle, son historique et la liste des outils à sa disposition. À chaque message, le modèle lit ce texte et produit une réponse. C'est tout. En tant que tel, il n'a aucune capacité d'action intégrée sur le monde extérieur.

Pour agir au-delà de ce simple bloc de texte, il existe un unique passage obligé : le function calling (ou tool calling). L'agent formule une intention structurée que le système hôte intercepte pour exécuter du vrai code. Tout ce qu'il touche (une API, un serveur MCP, un autre agent, un sandbox) emprunte strictement cette même passerelle.

Puisque l'exécution elle-même passe toujours par ce même tuyau, le véritable défi de l'outillage agentique ne réside pas dans l'action, mais dans la façon dont on l'expose au LLM. Les vraies questions deviennent alors : comment va-t-on injecter la description de l'outil dans l'agent ? Et quel est l'impact de ce choix sur l'architecture ?

On commence par le plus simple : l'outil injecté dans l'agent

La forme la plus simple est d'injecter la description de l'outil directement dans le contexte de l'agent. C'est ce qu'on appelle un outil statique (Static Tool). L'agent le connaît dès le départ et sait exactement ce qu'il doit lui transmettre. Prenons un exemple.

Exemple : considérons une banque qui met à disposition un agent interne chargé de rédiger un rapport de profilage du risque de crédit. L'agent lui-même a l'interdiction légale de déterminer le risque de crédit, car cette étape doit rester un processus déterministe et auditable. Avec un outil statique, l'agent peut invoquer directement une fonction calculate_risk_score(), déléguant cette responsabilité à un calcul contrôlé et vérifiable tout en gérant l'interface conversationnelle autour de celui-ci.

L'agent reçoit dans sa fenêtre de contexte une description figée des outils dont il dispose. Lorsque l'agent l'invoque, le runtime interprète l'appel puis exécute la fonction ou la relaie vers une API externe.

Figure 2 — Le fonctionnement d'un outil statique

La simplicité qui devient la dette technique

Les outils statiques sont le bon choix pour les workflows fermés. Comme dans l'exemple du profilage du risque de crédit, il existe un processus clair que l'agent suit pour rédiger le rapport, enchaîné à un processus interne déterministe de profilage du risque. Dans ce cas, le workflow est indépendant du monde extérieur et directement impliqué dans le processus. Cela garde le système facile à raisonner, simple à déployer et exempt de complexité opérationnelle inutile.

Mais que se passe-t-il lorsqu'un workflow agentique complètement indépendant, ailleurs dans votre organisation, souhaite lui aussi appeler ce même score de risque ?

Centraliser la fonction sous forme d'API répond à la question de savoir où réside la logique. Elle ne répond pas à ce qu'il faut pour qu'un LLM l'appelle sans accroc. Chaque nouvel agent a toujours besoin de quelqu'un pour décrire la fonction, puis pour reprendre cette description à la main chaque fois qu'un paramètre change. Faites-le une fois, tout va bien. Faites-le pour chaque équipe, chaque framework, chaque agent qui veut le même outil, et vous reconstruisez le même adaptateur autour d'une fonction censée rester contrôlée et auditable.

C'est le point de bascule : au-delà d'un seul consommateur, le coût n'est pas d'héberger l'outil, mais de le re-décrire et de le re-sécuriser pour chaque modèle qui veut l'appeler.

La séparation entre l'agent et la définition de l'outil

Plutôt que d'intégrer les outils directement dans le code de l'agent, les outils dynamiques sont placés dans un environnement distinct, s'exécutant de manière indépendante (Dynamic Tools). Celui-ci réunit la logique de l'outil, la description de l'outil et les droits d'accès dans une seule interface standard.

Exemple : reprenons la fonction calculate_risk_score(). Placée derrière un serveur d'outils partagé, elle n'est plus décrite dans le code de chaque agent : l'agent de reporting réglementaire, le chatbot des conseillers et le prochain workflow que personne n'a encore imaginé interrogent tous la même définition, versionnée à un seul endroit.

L'intérêt apparaît surtout dans l'autre sens, pour des outils que la banque n'a jamais construits. Si ce même agent de reporting doit vérifier quelle version du modèle de risque est actuellement déployée, il n'a pas d'intégration GitHub à développer : GitHub expose son propre serveur MCP, l'agent s'y connecte, découvre les outils disponibles et les appelle. Ni description à maintenir, ni logique à implémenter côté banque.

Le MCP (Model Context Protocol) est le protocole d'outillage dynamique qui standardise la façon dont les agents découvrent et invoquent les outils. Un serveur MCP expose un catalogue d'outils disponibles, incluant leurs noms, leurs descriptions et les paramètres attendus. Ensuite, il écoute les requêtes d'invocation provenant des agents connectés. Lorsqu'un agent a besoin d'un outil, il interroge le serveur pour découvrir ce qui est disponible, puis envoie un appel structuré. Le serveur achemine la requête vers l'implémentation appropriée et renvoie le résultat.

Voyez-le comme une couche d'adaptateur universelle : au lieu que chaque agent code en dur ses propres intégrations d'outils, le MCP définit une interface partagée et interrogeable que tout agent compatible peut utiliser.

Figure 3 — Le protocole MCP

Le point de bascule : comptez vos consommateurs

Une manière pratique de trancher entre statique et dynamique est de vous poser une seule question :

« Avez-vous, ou vous attendez-vous à avoir, plus d'un profil de consommateur pour cette couche d'outils ? »

Ce « consommateur » peut recouvrir bien des réalités. En voici quelques exemples :

• Vous exposez des outils dynamiques dans le cadre de votre stratégie de distribution de produit, comme le fait GitHub. Avec le MCP, vous vous appuyez sur un standard pour intégrer vos produits au sein de produits d'IA tiers.

Mais en interne aussi, le cas du « plus d'un consommateur » peut se présenter :

• Plus d'un agent indépendant a besoin d'accéder au même outil. Dans ce cas, vous disposez d'un point central unique pour versionner la description.
• Les consommateurs de l'agent ont des profils différents avec des droits d'accès aux outils différents. Pensez à un chatbot utilisé par les employés de différentes divisions, chacun ayant besoin d'accéder à des données différentes. Tout comme une API, le MCP vous offre l'avantage de centraliser l'authentification et les droits d'accès.

A2A, le MCP pour des agents?

Au-delà des simples fonctions, un agent a parfois besoin de déléguer des tâches complètes à des sous-agents. Ces derniers peuvent lui être fournis de manière directe, agissant exactement comme des outils statiques liés à son contexte. Mais face au besoin de standardiser et d'externaliser ces connexions, une question naturelle émerge : existe-t-il un équivalent du MCP, mais pour les agents ?

Exemple : Salesforce le fait avec Agentforce. L'agent de relation client de la banque peut appeler un agent Salesforce Agentforce pour mettre à jour la fiche CRM d'un client, extraire l'historique de la relation ou déclencher un workflow de vente croisée, sans que la banque ait à construire ou à maintenir elle-même cette logique CRM. Salesforce possède l'agent, le versionne, le sécurise. L'orchestrateur de la banque se contente d'envoyer une Task. Avec cette approche, l'agent devient un actif et une composante du modèle économique.

Deux protocoles pas trop différents

Une manière d'y parvenir est le protocole A2A (Agent-to-Agent), qui suit une approche similaire au MCP. Dans l'A2A, chaque agent expose une Agent Card qui déclare le nom de l'agent, ses capacités, les formats d'entrée/sortie pris en charge et ses exigences d'authentification.

L'agent orchestrateur découvre le sous-agent via son Agent Card et lui envoie une Task. Le sous-agent traite la tâche et renvoie en flux (streaming) des mises à jour intermédiaires ainsi qu'un résultat final. La communication est entièrement découplée : l'orchestrateur n'a pas besoin de savoir comment le sous-agent est implémenté, sur quel framework il tourne, ni où il est déployé.

Figure 4 — Le protocole A2A

Le piège du « MCP pour agents »

« Plus d'un consommateur en aura-t-il besoin ? » : cette question relève du MCP. Pour l'A2A, la question centrale est différente :

L'autre partie raisonne-t-elle sur plusieurs étapes et détient-elle son propre état, ou bien un seul appel bien décrit suffirait-il ?

Prenons Salesforce Agentforce. Mettre à jour une fiche CRM peut impliquer plusieurs décisions que l'agent prend de lui-même : vérifier l'historique de la relation, décider si un workflow s'applique, séquencer les relances. La banque délègue donc une tâche plutôt que d'appeler une fonction. C'est ce qui justifie l'A2A : l'autonomie de l'autre côté, et non le simple fait que ce soit externe. Au lieu d'une valeur de retour, la Task obtient un cycle de vie: soumise, en cours, en attente d'entrée, terminée — avec une progression diffusée en flux à mesure. Un conflit surgit dans l'historique de la relation à mi-parcours ? Elle peut faire une pause et poser la question, au lieu de deviner ou d'échouer purement et simplement.

Si Agentforce n'exposait à la place qu'une seule action figée, par exemple « affecter la valeur Y au champ X », ce ne serait qu'un appel bien décrit, et cela n'aurait aucunement besoin de l'A2A. Dans ce cas, un serveur MCP ferait probablement aussi l'affaire.

Donner carte blanche à l'agent - Le Sandbox

Un sandbox fournit à un agent un environnement d'exécution entièrement isolé : un système de fichiers, un shell, des données montées et un accès contrôlé aux systèmes externes. C'est une capacité puissante précisément parce qu'elle ne contraint pas la manière dont l'agent atteint son objectif. L'agent peut lire des documents, exécuter des scripts, produire des artefacts et même faire tourner des services, le tout sans toucher à l'infrastructure environnante.

Exemple : calculate_risk_score() renvoie un score en zone grise, ni une approbation ni un refus nets. Un souscripteur a besoin de plus que le chiffre avant de décider, et il n'existe pas de liste de contrôle figée. Ce qu'il vaut la peine de vérifier dépend de ce qui est atypique dans ce dossier précis. Un agent en sandbox reçoit le dossier du demandeur et une connexion à la base de données des cas historiques. Il écrit ses propres requêtes au fur et à mesure : une combinaison inhabituelle de champs ici, une comparaison que personne n'avait pensé à préparer là, chacune façonnée par ce que la requête précédente a révélé. L'agent remet au souscripteur une synthèse.

Du point de vue de l'agent, un sandbox ne modifie pas fondamentalement son architecture. Toutes les instructions, tous les skills et tous les outils restent en place comme d'habitude. Le sandbox est exposé à l'agent comme un outil appelable, accompagné d'une description qui explique ses capacités. L'agent l'invoque via un appel de fonction standard chaque fois que la tâche l'exige, et le résultat est renvoyé dans le contexte de l'agent comme n'importe quelle autre réponse d'outil.

Figure 5 — Environnement d'exécution en sandbox. Source : OpenAI, « Sandboxes », OpenAI Platform Docs. © OpenAI. Tous droits réservés.

Le prix de la flexibilité : quand le Sandbox est-il vraiment justifié ?

Un sandbox introduit une réelle charge opérationnelle : l'environnement doit être provisionné, ses frontières définies, et l'ensemble du dispositif testé en même temps que l'agent lui-même. Ce coût n'est justifié que lorsque des alternatives plus déterministes ne peuvent véritablement pas faire le travail.

Avant de recourir à un sandbox, demandez-vous si les besoins d'accès de l'agent peuvent être satisfaits par un outil statique ou dynamique à la place. S'il lui suffit d'un accès en lecture à un ensemble précis de fichiers, un appel de fonction bien délimité y parvient sans la charge d'infrastructure. Le Sandbox mérite sa place lorsque l'agent a besoin de latitude pour décider lui-même comment naviguer dans les données, plutôt que d'un ensemble figé d'opérations préprogrammées.

Un second déclencheur est l'échelle du côté des outils, et non du côté de la tâche. Une fois qu'un agent est connecté à des dizaines de serveurs MCP, garder en contexte la définition complète de chaque outil peut coûter des dizaines de milliers de tokens avant même que le moindre vrai travail ne commence. Ici, le Sandbox permet à l'agent de parcourir les définitions d'outils sous forme de code sur un système de fichiers et d'appeler seulement ce dont il a besoin, au lieu de payer pour l'intégralité du catalogue à chaque tour.

Skills : Apprendre à l'agent comment réfléchir (et pas seulement agir)

Les Skills ne sont pas un outil au sens strict. En invoquer un n'est pas un appel de fonction régi par un schéma, à la manière d'un outil statique ou d'un outil MCP. Un skill est un dossier d'instructions, de scripts et de ressources que l'agent lit dans son propre contexte lorsque c'est pertinent. Plutôt que d'ajouter une nouvelle action appelable, un skill élargit ce que l'agent sait effectivement : des connaissances procédurales, des conventions de mise en forme ou un contexte organisationnel qu'il faudrait autrement réexpliquer à chaque prompt.

Exemple : l'agent de reporting du risque de crédit du tout premier exemple pourrait avoir besoin non seulement de calculate_risk_score(), mais aussi de la structure de rapport de la banque, de savoir quelles informations réglementaires s'appliquent à quelle catégorie de prêt, et du style maison qu'exige la conformité. Au lieu de garder tout cela en contexte à chaque conversation, on l'empaquette sous forme de skill credit-risk-report : un fichier SKILL.md contenant le modèle de rapport et les règles de divulgation, plus un pointeur indiquant à l'agent quel serveur MCP appeler pour le score lui-même. L'agent ne lit les instructions de reporting que lorsqu'on lui demande réellement de rédiger un rapport, et ne va chercher la définition de l'outil de scoring qu'à l'étape précise où elle est nécessaire.

Concrètement, un Skill est un dossier articulé autour d'un fichier SKILL.md (le mode d'emploi) et d'éventuels scripts ou modèles. Son efficacité repose sur un chargement progressif en trois temps :

• Amorce : Au démarrage, l'agent ne charge que le nom et la description du Skill, ce qui ne coûte qu'une poignée de tokens.

• Déclenchement : Si la requête de l'utilisateur correspond, l'agent ouvre le fichier SKILL.md pour assimiler les règles et le workflow.

• Exécution : L'agent suit la procédure, exécute des scripts (sans en charger le code source), ou invoque des outils externes (comme un serveur MCP).

En bref : un Skill ne remplace pas une fonction comme calculate_risk_score(). Il l'enveloppe de contexte métier au moment précis où c'est nécessaire, évitant ainsi de saturer inutilement la mémoire de l'agent le reste du temps.

Figure 6 — Chargement progressif d'un Skill. Source : Anthropic, « Agent Skills — Overview », Claude Docs. © Anthropic. Tous droits réservés.

Quand les utiliser : vaincre l'amnésie et l'obésité du contexte

Les Skills méritent leur place partout où les mêmes instructions se répètent d'un prompt à l'autre ou d'un agent à l'autre. Un format de rapport, un style maison, une liste de contrôle que personne ne veut ressaisir à chaque fois. Mais il existe un second cas, plus architectural : à mesure qu'un catalogue MCP grandit, les Skills deviennent un moyen peu coûteux de l'organiser. Plutôt qu'un agent ne garde en contexte en permanence la définition complète des outils de chaque serveur connecté, un skill peut se placer devant un serveur ou un outil MCP spécifique et rester quasiment gratuit jusqu'à ce qu'il soit nécessaire. Lorsque la tâche l'exige, le skill s'active, indique à l'agent quel outil utiliser et comment, et ce n'est qu'à ce moment-là que la définition de cet outil entre en contexte. À l'échelle d'une organisation faisant tourner de nombreux serveurs MCP, cela transforme «lequel de nos quarante outils me faut-il ?» en «lequel de nos cinq Skills s'applique ?».

Comment toutes les pièces s'articulent

Il est tentant de lire les sections précédentes comme un arbre de décision : répondez à quelques questions, aboutissez à un composant, terminé. Mais ce n'est pas à cela que ressemble une véritable architecture une fois en fonctionnement. On ne choisit pas tant entre ces couches qu'on ne les accumule, et la question la plus difficile est de savoir comment elles tiennent ensemble une fois qu'elles cohabitent toutes dans le même système.

Elles coexistent parce qu'elles ne sont pas des points sur une même ligne, mais des réponses selon différents axes qui s'appliquent simultanément. Un axe est l'autonomie : le degré de liberté accordé à ce qui se trouve à l'autre bout, depuis une fonction verrouillée jusqu'à un agent ou un sandbox laissé libre de trouver son propre chemin. Un autre est la propriété (ownership) : qui construit, versionne et sécurise la capacité, depuis du code dans votre propre runtime jusqu'à un service qu'un tiers exploite dans le cadre de son activité. Les Skills ne se situent sur aucun de ces axes : ils sont la couche au-dessus, le contexte qui décide quelle capacité mobiliser à un moment donné. Parce que les axes sont indépendants, une seule requête peut les traverser plusieurs à la fois en un seul tour : lire une procédure, appeler un outil statique pour une étape, et confier une tâche à un partenaire autonome pour la suivante.

Vu ainsi, l'architecture cible n'est pas un verdict d'un outil sur un autre, mais un gradient dans lequel une organisation grandit progressivement. On commence par une fonction dans une boucle et on ajoute des couches à mesure que les questions se compliquent : un deuxième consommateur, un partenaire autonome, une tâche qui a besoin de marge pour échouer. On aboutit à un système unique qui permet à un agent d'être déterministe là où il doit l'être et libre là où il peut se le permettre. Cet équilibre, au bout du compte, est toute la raison de donner des outils à un agent.