Tool calling en production : ce que personne ne vous dit

Le tool calling est la primitive la plus importante pour construire des produits IA utiles. C’est aussi celle dont les démos cachent le mieux les aspérités.

Ces derniers mois, j’ai branché des agents sur des flux produits réels — paiements, planification, récupération de connaissances. Voici les quatre choses que j’aurais aimé que quelqu’un me dise dès le premier jour.

1. Le modèle appellera des outils que vous n’avez pas définis

Même avec des schémas JSON stricts, un modèle fine-tuné sur des milliers d’autres surfaces d’outils va parfois en halluciner un des vôtres. Le parsing défensif n’est pas optionnel.

function safeParseTool(call: ToolCall) {
  if (!KNOWN_TOOLS.has(call.name)) {
    return { ok: false, error: "unknown_tool" } as const;
  }
  return { ok: true, payload: call };
}

Si vous ne validez pas, votre agent va finir par appeler search_emails sur un système qui n’a jamais eu accès aux emails. Puis il se bloque — ou pire, il hallucine un résultat.

2. La latence s’accumule vite

Une chaîne simple — planifier → appeler l’outil → réfléchir → répondre — atteint facilement quatre aller-retours LLM. À 800 ms chacun, vous êtes à 3,2 secondes avant que l’utilisateur voit quoi que ce soit. Deux optimisations à fort impact :

• Streamer la réponse finale, même quand les étapes d’outils étaient séquentielles. L’utilisateur commence à lire immédiatement.
• Exécution parallèle des outils quand le modèle émet plusieurs appels d’outils en un seul tour. La plupart des SDK le supportent nativement ; beaucoup d’implémentations ne l’utilisent pas.

3. L’idempotence compte plus que vous ne le croyez

Les agents réessaient. Les réseaux tombent. Le modèle lui-même décide parfois de « vérifier » en appelant le même outil deux fois. Si votre create_invoice n’est pas idempotente, vous allez facturer quelqu’un deux fois un mauvais jour.

Passez une idempotency_key déterministe dérivée de l’ID du tour de conversation — pas des arguments de l’outil, parce que le modèle va les paraphraser entre les tentatives.

4. L’observabilité, c’est là que tout se joue

La différence entre un agent que vous pouvez livrer et un que vous ne pouvez pas, c’est votre capacité à répondre à : « qu’est-ce que le modèle a fait à 14h32 hier, et pourquoi ? »

Le minimum que je livre maintenant avec chaque agent :

• Trace complète par tour (prompt, appels d’outils, résultats, output final) conservée 30 jours.
• Coût en tokens + latence par tour, tracés dans le temps.
• Un endpoint « replay » qui réexécute un tour stocké contre un modèle différent.

Ce dernier point, c’est ce qui vous permet de changer de modèle sans prier.

---

La différence entre une démo qui impressionne et un produit qui résiste au contact avec les utilisateurs se joue presque toujours ici — pas dans le choix du modèle, pas dans le prompt. Dans le parsing défensif, les clés d’idempotence, les traces.