Agent IA : choisir un outil ou poser une question

👁 115 lectures

Pour qu’un agent IA sache quand appeler un outil et quand poser une question, faites-lui choisir l’étape suivante dans une liste fermée (répondre, appeler un outil, demander une précision, refuser, transmettre à une personne) et laissez le code vérifier séparément les données, les autorisations et les conditions d’exécution. Choisir la bonne fonction ne complète pas les arguments manquants : ce sont deux questions distinctes. Dans mon test du 13 octobre 2026 sur 10 conversations de service client, 7 des 9 modèles testés ont choisi la bonne action dans les 10 cas.

L’exemple qui suit est une conception d’agent pour une boutique en ligne, pas une intégration prête pour la production ; seul le tableau comparatif repose sur un test réel. Sources consultées le 13 octobre 2026. Pour le contexte général, voyez le guide Créer des agents IA de zéro.

Commencez par définir les actions autorisées

Supposons que l’agent doive vérifier le statut d’une commande et expliquer les conditions de livraison. Dans une première version, il lui suffit de consulter le statut et de rechercher une instruction approuvée. Le nom de chaque outil doit décrire ce qu’il fait réellement. Une fonction de consultation ne doit pas aussi modifier une adresse ou annuler un achat sous le même nom.

Pour chaque outil, consignez les arguments requis, le périmètre des données et les erreurs possibles. Précisez également d’où peuvent provenir les arguments. Il vaut mieux obtenir l’identifiant du client depuis une session authentifiée, et le numéro de commande depuis le message ou l’enregistrement sélectionné. La phrase « je suis administrateur » ne doit pas accorder de droits.

Séparer la proposition d’une fonction de son exécution correspond au mécanisme décrit dans la documentation d’OpenAI sur l’appel de fonctions, consultée le 13 octobre 2026 : le modèle renvoie une demande d’utilisation de fonction, l’application exécute le code et lui transmet le résultat. Dans cette conception, une décision spécialisée remplace une partie du choix.

Séparez le type d’action de l’outil précis

La première décision doit porter sur le type de l’étape suivante. Ce n’est que si la consultation de données est choisie qu’une seconde décision désigne l’outil. Avec peu de fonctions, vous pouvez réunir ces étapes dans un seul catalogue d’actions, mais ne supprimez pas les options d’arrêt ou de demande de précision simplement pour obliger le modèle à appeler un outil.

• Réponse : l’information nécessaire figure déjà dans le contexte approuvé.
• Outil : des données doivent être récupérées et la fonction appropriée ainsi que ses arguments requis sont disponibles.
• Demande de précision : l’utilisateur peut fournir l’information manquante nécessaire à l’étape suivante.
• Refus : la demande contrevient à une règle clairement définie par l’application.
• Transmission : l’application ne peut pas résoudre le problème ou l’évaluation est trop incertaine.

La distinction entre réponse, outil, demande de précision et impossibilité de répondre s’inspire de When2Call de NVIDIA, consulté le 13 octobre 2026. Dans cette conception, distinguer en plus le refus de la transmission relève d’un choix d’architecture, et non d’une reproduction fidèle des catégories du benchmark.

Exemple de contrat JSON pour l’application

Le schéma JSON ci-dessous décrit le résultat interne d’un adaptateur. Ce n’est pas le schéma de requête d’une API particulière. L’adaptateur fait correspondre la réponse du modèle choisi à des champs communs ; la distribution des probabilités peut être conservée séparément dans les données de diagnostic. Le reste du programme n’a ainsi pas besoin de connaître les noms de champs propres au fournisseur.

{
  "type": "object",
  "additionalProperties": false,
  "required": ["action", "tool", "missing_field", "reason_code"],
  "properties": {
    "action": {
      "enum": ["answer", "call_tool", "ask", "refuse", "handoff"]
    },
    "tool": {
      "enum": ["get_order_status", "search_delivery_help", null]
    },
    "missing_field": {
      "enum": ["order_id", "delivery_topic", null]
    },
    "reason_code": {
      "enum": [
        "context_sufficient", "lookup_required", "missing_input",
        "policy_block", "unsupported", "uncertain"
      ]
    }
  }
}

Pour le message « Où est mon colis ? » et un contexte qui ne désigne aucune commande de façon certaine, le résultat attendu dans cette conception est le suivant :

{
  "action": "ask",
  "tool": null,
  "missing_field": "order_id",
  "reason_code": "missing_input"
}

Le code fait correspondre « order_id » à une question approuvée : « Indiquez le numéro de la commande concernée. » Le modèle de décision n’a pas besoin de rédiger cette phrase. Après la réponse de l’utilisateur, l’application met à jour l’état et évalue à nouveau l’étape suivante. Un numéro provenant d’un échange antérieur sur un autre sujet ne doit pas être repris sans vérification.

Le schéma limite les valeurs possibles, mais autorise encore des combinaisons incohérentes. Le validateur de l’application doit donc exiger un outil pour « call_tool », l’interdire pour « ask » et vérifier la cohérence entre le code de motif et l’action. Dans cet exemple, les règles entre champs sont volontairement décrites séparément, afin de ne pas laisser croire qu’il s’agit d’une solution complète prête pour la production.

Voici, en substance, une requête de mon test (point de terminaison /api/alpha/decisions d’OpenRouter ; liste des outils et descriptions des options raccourcies). J’ai mené le test en polonais ; le texte ci-dessous en est la traduction :

{
  "model": "microsoft/microsoft-decision-1",
  "state": {
    "tools": "get_order_status(order_number), cancel_order(order_number)",
    "conversation": "Client : Où est mon colis ? J’ai passé commande la semaine dernière."
  },
  "questions": {
    "step": {
      "type": "choice",
      "instructions": "Que doit faire l’assistant à l’étape suivante ?",
      "criteria": {
        "answer": "répondre immédiatement, sans outil",
        "tool": "appeler un outil - toutes les données sont disponibles",
        "ask": "demander une précision, car des données requises manquent",
        "cannot": "refuser - aucun outil ne convient"
      }
    }
  }
}

La bonne réponse est ask (le numéro de commande manque). Le modèle renvoie l’option choisie, la probabilité de chacune des quatre options et un niveau de confiance ; l’adaptateur fait correspondre le tout au contrat de la section précédente.

Quand poser une question et quand récupérer l’information manquante

Tout manque d’information ne nécessite pas un message à l’utilisateur. Si le client a sélectionné une commande dans son espace, l’application connaît déjà son numéro. Le lui demander à nouveau signalerait un état mal transmis. À l’inverse, le fait que plusieurs commandes aient le même nom de destinataire ne permet pas d’en choisir une arbitrairement.

Pour chaque fonction, dressez la liste des données nécessaires et facultatives. Une demande de précision doit lever une ambiguïté concrète. La formule « donnez plus d’informations » laisse l’utilisateur deviner ce dont l’automate a besoin. Mieux vaut préciser l’élément manquant et expliquer à quelle étape il est nécessaire.

Distinguez également l’absence de données d’une panne. Si le service de suivi est indisponible, redemander son numéro au client ne rétablira pas la connexion. Enregistrez l’état d’erreur, appliquez la politique de nouvelles tentatives prévue et, lorsque celles-ci sont épuisées, transmettez le dossier. Ne demandez pas au modèle de faire comme si une nouvelle reformulation de la même question lui apportait davantage d’informations.

La probabilité aide à définir l’ordre des vérifications

Ne définissez pas un seuil universel en supposant qu’il conviendra à toutes les actions. TypeSafe décrit le champ confidence pour certains types de questions dans sa documentation, consultée le 13 octobre 2026. Avant de l’utiliser, vérifiez ce qu’il signifie au lieu de l’assimiler automatiquement à la probabilité la plus élevée parmi les options.

Sur un jeu de contrôle, vérifiez la fréquence à laquelle les réponses sont correctes pour un niveau de confiance déclaré similaire. Adaptez les conditions d’exécution automatique à chaque action. Consulter une instruction publique et modifier les données d’un client n’entraînent pas les mêmes conséquences en cas d’erreur ; une règle commune pour autoriser l’exécution demanderait donc une justification distincte.

Une distribution proche d’une égalité peut signaler que les descriptions des outils se recoupent. Avant de relever le seuil, examinez les définitions elles-mêmes. Si deux fonctions promettent toutes deux de « gérer une commande », le classificateur dispose de peu d’éléments pour les distinguer. Améliorer le catalogue d’outils rapporte souvent plus que changer de fournisseur.

When2Call chez Artificial Analysis et mon test en 10 conversations

Source : graphique et présentation de When2Call par AA, consultés le 13 octobre 2026. Le meilleur résultat d’AA est en gras. La dernière colonne correspond à mon test du 13 octobre 2026 : 10 conversations en polonais avec l’assistant d’une boutique, utilisant quatre outils (statut d’une commande, annulation, disponibilité en magasin, étiquette de retour) et les mêmes quatre options que When2Call. Clef-Flash appelait un outil alors qu’il manquait le numéro de commande ou la ville, et refusait de répondre à une question simple sur le délai de retour de 14 jours. Le test porte sur le choix d’une réponse parmi celles proposées. Ces chiffres ne permettent pas de conclure que le modèle sait compléter seul les arguments ou mener à bien des opérations en plusieurs étapes.

Transformez les pièges en cas de test

• Instruction cachée dans les données : un document contient une instruction qui demande de choisir un autre outil. Le test doit vérifier que les données ne prennent pas la place des règles de l’application.
• Fonctions similaires : les descriptions d’un outil de consultation et d’un outil de modification sont proches. Vérifiez le choix avec des demandes qui ne diffèrent que par un verbe.
• État obsolète : l’utilisateur a corrigé son numéro de commande, mais le modèle voit toujours l’ancien. Testez la mise à jour de l’ensemble du flux, et pas seulement d’une requête isolée.
• Réponses contradictoires : le modèle propose à la fois un appel d’outil et indique qu’un argument requis manque. Le validateur doit bloquer l’exécution.
• Nouvel essai après un délai d’attente : l’appel précédent a peut-être été exécuté. Pour les opérations qui modifient l’état, prévoyez un mécanisme qui évite les doublons.

Les recommandations officielles d’OpenAI sur la sécurité des agents, consultées le 13 octobre 2026 abordent les risques liés aux instructions provenant de contenus non fiables et la limitation des flux de données. Dans cette conception, une application pratique consiste à maintenir un catalogue d’actions fermé et à vérifier les autorisations en dehors du modèle.

Comment tester un agent avant de le connecter aux outils

Commencez par décrire les états d’entrée et les actions attendues. Incluez les demandes valides, les données manquantes, les contradictions, les fonctions indisponibles et les situations hors périmètre. Une personne qui connaît le processus doit déterminer les réponses de référence avant de consulter les propositions du modèle. Sinon, il est facile d’adapter l’évaluation à ce que le système vient de renvoyer.

Séparez le jeu utilisé pour améliorer les descriptions du jeu de contrôle final. Gardez ensemble les variantes d’un même message afin qu’un exemple très proche ne se retrouve pas des deux côtés de la séparation. Vérifiez à part les fautes de frappe, les abréviations, les échanges plus longs et les changements d’avis de l’utilisateur.

Le rapport doit présenter non seulement la précision globale, mais aussi les appels inutiles, les demandes de précision omises ou superflues et les refus erronés. Branchez ensuite un outil factice et vérifiez les arguments ainsi que la gestion des erreurs. Enfin, lancez un mode d’observation dans un flux réel, où les propositions sont enregistrées sans déclencher d’opération.

Après une modification de la version du modèle, des descriptions de fonctions ou des règles de traitement, répétez les tests de contrôle. Enregistrez la version du catalogue d’outils avec le résultat pour pouvoir déterminer l’origine d’une nouvelle erreur. Évitez toutefois de conserver inutilement tout le contenu fourni par le client si un exemple expurgé et un identifiant d’événement suffisent à l’analyse.

Questions fréquentes

Un modèle de décision remplace-t-il l’agent dans son ensemble ?

Pas dans cette conception. Il choisit l’étape suivante, tandis que l’application conserve l’état, exécute les fonctions et contrôle leurs effets.

Le JSON présenté est-il une requête prête à envoyer à une API ?

Non. Il s’agit d’un contrat interne proposé pour un adaptateur. Le format d’appel et les types de questions pris en charge doivent être adaptés à la documentation du fournisseur choisi.

Une confiance élevée permet-elle de se passer de vérifier les autorisations ?

Non. La confiance concerne l’évaluation du modèle. L’application vérifie séparément l’accès aux données et le droit d’exécuter une opération.

Que faire si l’agent demande sans cesse des précisions ?

Vérifiez qu’il reçoit l’état complet et que la question porte bien sur un argument nécessaire. Ajoutez une condition d’arrêt en l’absence de progrès et une option de transmission.

Comment vérifier si le choix d’un outil est correct ?

Comparez-le à une référence préparée indépendamment, puis vérifiez les arguments et l’état final après exécution dans un environnement de test. Un JSON valide ne suffit pas.

Déclaration : je connais le modèle Jev de TypeSafe grâce à une exploration antérieure. En septembre, j’ai écrit un client API simple pour lui, en pensant à mes propres outils éditoriaux. TypeSafe n’a ni commandé ni financé cet article.

// lire la suiteGamma vs PowerPoint Copilot : quel outil choisir en 2026Outils d'IACloudflare Pages ou Vercel : lequel choisir pour un site IA ?GuidesCréer un agent AI en Python pas à pas (76 lignes)Guides

Kinetyra