Outils d’agents IA : tool calling, schémas, permissions, MCP

Un outil, c’est une API : design d’abord (sinon l’agent devient fragile)

Le modèle est brillant. Mais il ne connaît pas votre SI.

Donc il a besoin d’outils.

Et c’est là que beaucoup de projets se plantent : ils “branchent” des APIs existantes sans les rendre agent-friendly.

Résultat :

• schémas ambigus,
• erreurs illisibles,
• actions non idempotentes,
• permissions trop larges,
• et debugging impossible.

Un outil “agent-ready” est un produit. Il a un design.

Tool calling : le contrat (schéma) est votre garde-fou

Les fournisseurs documentent le tool calling / function calling.

OpenAI documente un guide dédié à la fonction d’appel d’outils (schémas, parameters).¹ Anthropic documente la “tool use” (outils) dans son écosystème.²

La leçon : vous ne voulez pas que le modèle “improvise” une structure. Vous voulez qu’il respecte un contrat.

Nommer l’outil : la microdécision qui a un gros impact

Un agent choisit un outil comme un humain choisit un bouton.

Donc :

• create_ticket est lisible,
• doAction est une dette.

La description doit être courte et précise. Pas un roman.

Schémas stricts : obligatoire si l’outil peut faire du dommage

Schéma simple (exemple) :

{
  "type": "object",
  "properties": {
    "client_request_id": { "type": "string" },
    "customer_id": { "type": "string" },
    "amount_eur": { "type": "number" }
  },
  "required": ["client_request_id", "customer_id", "amount_eur"]
}

Vous remarquez la présence de client_request_id. Ce n’est pas décoratif.

Read tools vs write tools : deux vitesses, deux politiques

Tous les outils ne se valent pas.

En agentic, j’aime séparer :

• read tools (lecture) : recherche, récupération, lookup,
• write tools (écriture) : création, modification, suppression, paiement.

Pourquoi ?

Parce que le niveau de risque est différent.

Un read tool “mauvais” donne une réponse moins bonne. Un write tool “mauvais” crée un incident.

Donc vous n’appliquez pas les mêmes règles :

• read tools : plus permissifs, mais tracés,
• write tools : stricts, idempotents, et souvent derrière validation.

Output schema : l’outil doit répondre en structure, pas en littérature

Un agent a besoin de réponses utilisables.

Donc un outil renvoie :

• un statut (ok, needs_input, error),
• des champs structurés,
• et éventuellement un message humain (pour logs).

Mauvais exemple :

• “Ticket created successfully.” (et après ? quel ID ? quel statut ?)

Bon exemple :

{
  "status": "ok",
  "ticket_id": "TCK-19381",
  "url": "https://...",
  "warnings": []
}

Le LLM n’est pas fait pour parser des phrases. Il est fait pour raisonner sur des structures.

Idempotence : le mot qui évite les doublons (et les incidents)

Un agent retry.

Pas parce qu’il est idiot. Parce qu’Internet tombe, les APIs répondent 500, et le monde est imparfait.

Donc si votre outil n’est pas idempotent :

• vous créez des tickets en double,
• vous envoyez deux emails,
• vous déclenchez deux actions.

Idempotence = “rejouer n’ajoute pas de dégâts”.

Pattern classique :

• l’agent génère un client_request_id,
• l’API déduplique par cette clé,
• et renvoie toujours le même résultat pour la même clé.

Actions critiques : le “two-step commit” (préparer → valider → exécuter)

Pour les write tools sensibles, un pattern simple et robuste :

1. prepare : l’agent produit un payload d’action (structuré)
2. validate : un humain ou un validateur automatique approuve
3. execute : l’outil exécute avec idempotence

Exemple : remboursement.

L’agent peut :

• calculer un montant,
• proposer une justification,
• et préparer une action.

Mais l’exécution n’arrive qu’après validation.

Ce pattern évite deux extrêmes :

• “l’agent ne fait rien” (trop peur),
• “l’agent fait tout” (trop de risque).

Erreurs : vous devez aider l’agent à échouer correctement

Un humain lit une erreur et comprend. Un agent lit une erreur et… peut paniquer (ou inventer).

Donc vous structurez vos erreurs.

Bon pattern :

• code stable (INVALID_INPUT, PERMISSION_DENIED, RATE_LIMITED),
• message humain (pour logs),
• détails machine (pour debug),
• et actions recommandées (retry, ask user, escalate).

Mauvais pattern :

“Error: something went wrong.”

Oui. On avait deviné.

Timeouts, retries, circuit breakers

Votre agent doit savoir :

• quand retry,
• quand abandonner,
• quand escalader.

Sinon, il boucle. Et vous payez une facture “token” pour un agent qui tourne en rond.

Record/replay : tester un agent sans casser votre SI

Les outils sont aussi une surface de test.

Si vous testez un agent en prod, vous allez :

• créer des tickets de test,
• polluer des données,
• et perdre la confiance des équipes.

Pattern simple :

1. en staging, vous enregistrez des réponses d’outils (record) sur des cas typiques,
2. en test, vous rejouez ces réponses (replay) pour rendre l’exécution stable,
3. vous évaluez la logique agentique (tool selection, paramètres, validations).

Le bénéfice : vous testez “comme en prod”, sans toucher la prod.

Et si votre outil ne peut pas être stubé, c’est souvent un signal : le contrat est trop flou.

Permissions : un agent n’est pas un super-utilisateur

La sécurité agentic commence ici.

Principe :

• chaque agent a un rôle,
• chaque rôle a un scope,
• chaque scope a une liste d’outils autorisés,
• et certains outils nécessitent une validation.

On en parle plus en détail dans : Sécurité des agents IA.

Séparer exécution et secrets

Le LLM ne doit jamais recevoir :

• une clé API brute,
• un token admin,
• un cookie d’auth.

Le runtime gère les secrets. Le modèle demande une action.

Tokens éphémères : déléguer sans donner les clés de la maison

Un pattern sûr est d’éviter les tokens “long-lived” dans les services d’agents.

Vous préférez :

• des tokens courts (TTL),
• émis pour une action précise,
• avec un scope limité,
• et traçables.

En clair : l’agent demande “je dois créer un ticket”. Le runtime obtient un token “create_ticket” valable quelques minutes. Puis il l’oublie.

Ça réduit l’impact :

• d’une fuite,
• d’un log trop bavard,
• ou d’un serveur compromis.

“Dry-run” : le garde-fou simple

Pour des actions critiques, un pattern très rentable :

1. l’agent propose une action (payload),
2. un validateur (ou un humain) approuve,
3. seulement ensuite l’outil exécute.

Ça réduit les incidents. Et ça améliore la confiance.

MCP : standardiser les outils (et arrêter de recoder 200 intégrations)

MCP (Model Context Protocol) est une spécification pour connecter modèles/agents à des outils via des serveurs MCP.³

L’intérêt :

• un protocole standard,
• des serveurs réutilisables,
• des outils branchables sans réinventer.

Vous le voyez mentionné dans des stacks agentiques (ex. Claude Agent SDK met en avant MCP).⁴

Comment penser MCP (version terrain)

Un serveur MCP est comme un “microservice d’outils”.

Il expose :

• des tool definitions,
• des appels,
• parfois du contexte,
• et un modèle d’auth.

Donc vous le traitez comme un système :

• versionné,
• monitoré,
• sécurisé.

Déploiement MCP : dev/staging/prod (et pourquoi c’est non négociable)

Un serveur MCP en prod doit être :

• isolé de dev (credentials, données),
• monitoré (latence, erreurs, débit),
• et mis à jour avec une procédure (pas “on push direct”).

Deux raisons :

1. les tools sont des capacités d’action,
2. et MCP rend l’ajout d’outils facile.

Donc vous mettez :

• une revue (nouvel outil = PR),
• une validation (tests + sécurité),
• et un rollout contrôlé.

MCP et catalogue d’outils : éviter “l’app store sauvage”

MCP facilite le “plug”. Ça donne envie d’ajouter des outils comme on installe des extensions.

Mais un outil, ce n’est pas un plugin de navigateur. C’est un accès à vos systèmes.

Donc vous tenez un catalogue :

• qui possède l’outil,
• quel scope,
• quel logging,
• quelle politique de rétention,
• et quel plan de rollback.

Sécurité MCP : supply chain, authentification, et outils dangereux

Le site MCP publie des recommandations de sécurité (“Security best practices”).⁵

Ce n’est pas un détail.

Parce que MCP rend facile :

• l’ajout d’un nouveau tool,
• l’ajout d’un nouveau serveur,
• l’ajout d’une nouvelle capacité.

Et chaque “facile” est aussi un “facile à mal configurer”.

Risque #1 : descriptions d’outils qui deviennent des instructions

Un outil a une description. Un modèle lit cette description.

Donc une description malveillante peut tenter de guider le comportement (“ignore les règles”).

Mitigations :

• valider et signer les manifests,
• contrôler la provenance des serveurs,
• et isoler les environnements.

Risque #2 : outils trop puissants

Un outil qui peut :

• lire tout un drive,
• modifier tout un CRM,
• exfiltrer des documents,

est un outil dangereux.

La question n’est pas “peut-on le brancher ?”. La question est “dans quel scope, et avec quel audit ?”.

Risque #3 : serveur MCP non authentifié

Un serveur MCP doit être authentifié et autorisé.

Sinon, vous avez un endpoint d’action.

Et un endpoint d’action non authentifié, c’est… vous voyez l’idée.

Checklist : catalogue d’outils “agent-ready”

Voici une checklist que j’utilise. Elle évite 80% des “agents fragiles”.

Exemples d’outils “bien découpés” (et pourquoi ça aide)

Un bon catalogue d’outils ressemble à un set de LEGO. Des briques simples, combinables.

Exemples typiques :

• search_docs (read) : recherche dans une base documentaire (avec filtres RBAC).
• get_customer (read) : récupère un client par ID (champ whitelist).
• extract_fields (read) : extraction structurée d’un document (OCR/parsing).
• create_ticket (write) : crée un ticket (idempotent).
• send_email (write) : envoie un email (souvent derrière validation).
• schedule_meeting (write) : propose et confirme un créneau (avec confirmation).
• validate_payload (validator) : vérifie schéma + règles métier.
• log_event (obs) : journalise un événement corrélé (trace_id).

Ce découpage a un effet direct sur la fiabilité :

• l’agent choisit mieux (outils plus spécifiques),
• vous testez mieux (briques isolées),
• vous gouvernez mieux (permissions par brique),
• et vous débuggez mieux (tool calls lisibles).

Anti-patterns : les outils qui rendent un agent fragile

Si vous voulez gagner du temps, évitez ces patterns.

1) L’outil “fourre-tout”

Un outil qui fait :

• recherche,
• création,
• modification,
• notification,

dans le même endpoint, est un outil qui rend l’agent confus.

Le modèle doit choisir une action. Pas un buffet.

2) Paramètres “texte libre” pour des actions sensibles

Exemple :

• action: "refund customer 123" (texte libre)

Ça marche… jusqu’à l’ambiguïté.

Pour une action sensible, vous voulez :

• des champs explicités,
• des enums,
• et des required.

3) Outils qui renvoient des phrases

Si votre outil renvoie :

• “Ok c’est fait.”

Vous avez perdu l’information :

• quel ID,
• quel statut,
• quel lien,
• quel warning.

Donc l’agent ne peut pas enchaîner proprement.

4) Side effects cachés

Un outil “get_customer” qui met à jour un champ “last_seen”. Un outil “search_docs” qui envoie un event externe.

Les side effects cachés sont des bombes à retardement : ils cassent les tests et surprennent les équipes.

Au final, la fiabilité d’un agent dépend souvent plus de ses outils que de son modèle.

Si vos outils sont clairs, idempotents, et bien gouvernés, l’agent devient stable. Si vos outils sont ambigus, l’agent devient “créatif” au mauvais endroit.

Et la créativité sur un endpoint “paiement” n’est pas un trait de personnalité. C’est un incident.

Commencez petit, instrumentez, puis élargissez le catalogue avec des preuves, pas des intuitions. Vos ops vous remercieront. Et vous dormirez mieux. En prod, ça compte.

FAQ