Appel d’outil invalide : faire refuser les arguments impossibles par l’application

L’agent propose de créer un devis avec une quantité écrite « 2 », une date impossible ou un prix total qu’il a lui-même choisi. Le JSON est lisible et les champs semblent professionnels. Si l’application transforme ces valeurs puis lance le connecteur, une erreur de génération devient un engagement métier : risque de prix imposé sans accord, puis reprise manuelle du devis. La frontière à contrôler se situe avant l’effet de l’outil, avec les règles du service réellement exposé.

En pratique, une proposition doit passer plusieurs décisions : décodage, schéma, objet admis, règles métier et autorisation de l’opération. Ces décisions ne se remplacent pas. Un identifiant bien formé peut désigner le mauvais client ; une quantité positive peut dépasser la disponibilité ; une date conforme au format peut ne pas convenir au processus.

Nous testons un schéma original et douze propositions écrites à la main sur un faux outil de devis. Le contrôle local utilise JSON Schema Draft 2020-12 et la bibliothèque jsonschema 4.23.0. Dix propositions sont refusées avant le handler, deux créent un objet fictif. Aucun modèle, ERP ou réseau n’est appelé ; les montants et conditions servent uniquement à cette recette défensive.

La conception d’agents IA sur mesure avec outils métier contrôlés commence par cette entrée applicative. Une solution IA reliée à vos opérations doit pouvoir expliquer quels arguments ont été proposés, lesquels ont été admis et pourquoi un effet a été refusé ou permis.

Pour qui contrôler les propositions d’un outil métier

Traiter la génération comme une entrée extérieure

Le sujet concerne une lecture ciblée, une création de brouillon, une qualification ou une modification confiée à un agent. L’application peut publier un schéma pour aider le modèle à produire les arguments attendus. Elle doit néanmoins vérifier la proposition reçue avant de la transmettre. Une instruction demandant de respecter les types améliore l’interaction ; elle ne constitue pas la validation de l’entrée du service.

Le contrat de mission d’un agent support décrit recherches, outils et sorties. La validation des arguments approfondit une frontière précise de ce contrat. Le bon outil avec une mauvaise référence peut produire un résultat tout aussi inacceptable qu’un outil exclu. L’adaptateur doit contrôler la demande reçue, y compris lorsqu’elle vient d’une autre interface que le modèle.

Fixer la capacité du devis fictif

Notre outil crée seulement un devis interne pour C-18 et P-18, dans deux brouillons admis. Il ne réserve aucune quantité, ne transmet aucun email et ne promet pas de livraison. La recette retient EUR, un prix de service fictif et une disponibilité simulée. Ces restrictions constituent les règles du cas ; elles ne décrivent pas tous les ERP ni la pratique commerciale d’un client.

Le serveur de test possède les références autorisées et les conditions de calcul. L’agent ne fournit pas un tenant, une permission ou une approbation dans ses arguments. Le contrat d’outil avec autorisation et preuve d’effet conserve cette responsabilité générale. Le petit contrôleur présenté ici en vérifie quelques entrées, sans remplacer un système complet d’habilitation.

Séparer décodage, schéma et règles applicatives

Ne pas lancer le handler pendant une réparation de format

Le décodage transforme un message en structure examinable. Une donnée malformée doit être arrêtée avant toute décision sur ses champs. Le schéma vérifie ensuite les propriétés déclarées. Le service examine enfin les références et les invariants métier. Chaque étape possède une sortie précise ; une exception de parsing ne devient pas une demande partiellement exécutée parce que certains champs semblent récupérables.

Les douze propositions de cette recette sont déjà du JSON décodable. Le test porte donc sur schéma et contrôles applicatifs, pas sur tous les défauts du parseur. Un produit doit également décider ses limites de taille, profondeur, encodage et clés dupliquées. Une normalisation silencieuse peut changer la valeur retenue ; la politique de décodage appartient au contrat, avec des tests propres au moteur utilisé.

Conserver la proposition et la décision de validation

L’entrée du validateur est l’objet proposé ; sa sortie contient soit des défauts, soit une structure admissible à l’étape suivante. La responsabilité de cette frontière appartient à l’application. La trace distingue argument reçu, transformation éventuellement permise et motif de refus. Elle ne doit pas certifier « modèle conforme » simplement parce que la réparation a produit un objet finalement accepté.

Le nom du défaut doit rester exploitable sans révéler de données privées. Une trace interne peut indiquer le chemin du champ et la règle violée. Une erreur publique peut rester plus générale pour un objet hors périmètre. Les équipes doivent pouvoir rapprocher un refus de sa demande, de la version de contrat et de la reprise, avec une journalisation proportionnée aux données traitées.

Schéma original : préparer un devis interne limité

Déclarer les propriétés réellement attendues

Le schéma exige brouillon, client, produit, quantité, devise et date. Le référentiel officiel JSON Schema sur les objets distingue propriétés déclarées, présence obligatoire et propriétés supplémentaires. Notre contrat ferme les champs supplémentaires : un total imposé ou un faux accord ne disparaît pas silencieusement avant exécution ; il provoque un refus visible de la proposition.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "additionalProperties": false,
  "required": ["draftId", "customerId", "productId",
               "quantity", "currency", "quoteDate"],
  "properties": {
    "draftId": {"type":"string","pattern":"^D-[0-9]+$"},
    "customerId": {"type":"string","pattern":"^C-[0-9]+$"},
    "productId": {"type":"string","pattern":"^P-[0-9]+$"},
    "quantity": {"type":"integer","minimum":1,"maximum":5},
    "currency": {"enum":["EUR"]},
    "quoteDate": {"type":"string","format":"date"}
  }
}

Ce schéma complet appartient au contrôleur local. Il n’est pas présenté comme le sous-ensemble accepté par un fournisseur de sorties structurées. Si le modèle et le serveur utilisent des profils différents, l’équipe documente cette différence et vérifie le contrat effectif des deux côtés. Une contrainte absente du profil fournisseur doit encore être appliquée dans l’application avant l’outil.

Relier les bornes aux décisions du service

Exemple concret : la quantité doit se situer de 1 à 5 dans le contrat fictif. Zéro est refusé par le minimum. Quatre respecte ces bornes mais peut échouer ensuite si seulement trois unités sont disponibles. Le schéma exprime une limite stable de la capacité, pas l’état instantané du stock. Modifier automatiquement son maximum à chaque consultation ne résout pas la concurrence au moment de l’action.

Le format d’identifiant vérifie une forme, sans consulter le logiciel. C-99 peut correspondre au motif attendu tout en restant exclu de la mission C-18. La forme ne prouve ni existence ni droit. Les bornes, devises et propriétés doivent être choisies selon la capacité exposée ; recopier celles d’un autre outil peut laisser passer une demande que le processus n’a jamais admise.

Activer et tester les formats réellement contrôlés

Ne pas supposer que format déclenche toujours un refus

La spécification JSON Schema Draft 2020-12 distingue annotation de format et assertion. Le mot-clé peut décrire une intention sans que toutes les implémentations valident sa sémantique par défaut. Déclarer une date dans le fichier ne suffit donc pas à conclure qu’une date impossible rencontrera un refus dans le moteur réellement utilisé.

Avec jsonschema 4.23.0 dans notre test, 2026-02-30 passe lorsque le validateur est créé sans FormatChecker. La même entrée est refusée lorsque ce contrôle est explicitement fourni. Ce résultat a été exécuté sur le schéma ci-dessus. Il vérifie un cas de date dans cette version ; il ne prouve pas la prise en charge de tous les formats possibles ou de toutes leurs dépendances.

Vérifier le sens métier après la forme de date

La documentation officielle du validateur Python utilisé précise la configuration des formats. Une date existante peut encore être interdite au processus : clôture passée, début postérieur à la fin ou période qui n’admet pas de création. Ces relations demandent des règles applicatives adaptées. Notre recette ne compare pas la date du devis à une horloge métier ni à une période comptable.

Le contrat doit également distinguer date civile et instant avec fuseau lorsque l’outil en a besoin. Une conversion locale vers UTC peut changer le jour interprété. La date du faux devis est simplement une valeur civile ; aucun délai d’expiration ne lui est attaché dans ce test. L’équipe garde les contrôles temporels non couverts comme réserves au lieu de les déduire du succès d’un seul format.

Refuser les conversions qui changent le sens de la demande

Distinguer chaîne, booléen et nombre

La quantité chaîne « 2 » et le booléen true sont refusés dans la recette. Les convertir d’abord en nombre peut masquer une erreur de contrat ou appliquer une convention du langage sans accord métier. Le produit peut décider d’une normalisation, mais elle doit être explicite, limitée et observée. La validation ne doit pas perdre la distinction entre ce que l’agent a proposé et ce que l’adaptateur a reconstruit.

Un défaut corrigeable peut retourner vers l’agent ou l’utilisateur avec la règle précise. L’application n’invente pas une quantité lorsque le champ est absent et ne choisit pas une devise pour satisfaire le schéma. Ces valeurs modifient la portée économique de la demande. La correction doit provenir d’une source ou d’une décision autorisée, puis repasser par les contrôles comme une nouvelle proposition.

Comprendre l’entier mathématique avant l’adaptation au langage

En Draft 2020-12, un nombre sans partie fractionnaire satisfait le type integer. Dans notre moteur, la valeur JSON 2.0 est admise, tandis que la chaîne "2" et le booléen sont refusés. Le test conserve ce résultat au lieu d’affirmer que la notation avec point doit toujours échouer. Un contrôle qui exige une forme lexicale différente doit être défini comme une exigence supplémentaire de son interface.

Après validation et contrôle des bornes, notre faux service normalise le nombre admis vers une quantité entière pour calculer le montant. Cette étape ne s’applique jamais à une chaîne ou un booléen refusé. Les questions de précision et d’unités restent spécifiques au logiciel : une quantité fractionnaire légitime pour un autre produit exigerait un autre contrat, avec sa représentation et ses règles de calcul.

Vérifier objet, disponibilité et montant côté service

Maintenir les références admises hors des arguments générés

Le contexte serveur fictif autorise C-18, P-18 et les brouillons D-18/D-19. Le contrôleur refuse C-99 ou P-99 après le schéma. Il ne cherche pas leur contenu pour expliquer le refus. Une application réelle doit appliquer session, tenant et permissions actuelles au service de données. Notre égalité sur quelques références démontre la politique réduite du test, pas une infrastructure complète d’autorisation.

La disponibilité simulée vaut trois unités. Une demande de quatre est refusée avant le handler, même si son JSON est valide. La revérification du contexte ERP avant écriture traite la fenêtre entre lecture et action. Ici, aucune concurrence n’est simulée ; l’état de test reste figé. Le contrôle ne doit pas être présenté comme une garantie de stock dans un système distribué.

Calculer les conditions économiques depuis la source autorisée

Cas concret : le prix fictif du service est 11 000 unités mineures EUR par unité, soit 110 EUR HT. Pour deux unités, le total vaut 22 000 unités mineures, soit 220 EUR HT. Le paramètre totalMinor ne fait pas partie du schéma : une proposition qui impose la valeur 1 est refusée, au lieu d’écraser le calcul de service. Le prix n’est donc pas accepté simplement parce qu’il apparaît dans un appel bien présenté.

Les taxes, remises et conversions de devise restent hors de cette recette. EUR est la seule valeur admise. Une autre capacité pourrait accepter un plafond utilisateur, à comparer au montant calculé plutôt qu’à utiliser comme prix. Cette distinction appartient au contrat métier. Les règles commerciales doivent provenir des sources compétentes et garder leur version, pas d’une justification produite par le modèle.

Douze propositions manuscrites et leurs verdicts

Provoquer les refus sans dépendre des sorties du modèle

V-01 à V-12 sont préparés pour exercer des branches précises. Les erreurs de schéma sont examinées avant les contrôles métier ; les arguments admis atteignent ensuite le faux handler. Les motifs ci-dessous appartiennent au contrôleur de démonstration. Ils ne promettent pas les mêmes codes ou le même ordre de refus dans un ERP, un protocole d’agent ou une API fournisseur.

Ajouter les combinaisons sans perdre les défauts unitaires

Un dossier peut contenir plusieurs défauts. Le contrôleur doit rester fermé même si son motif principal varie selon l’ordre de validation. Les tests unitaires négatifs isolent la cause ; les tests combinés exercent le parcours de reprise. La recette garde les deux lectures : exactitude du défaut annoncé et absence de dispatch pour toute proposition qui ne satisfait pas les conditions ouvertes.

Les douze cas ne couvrent pas longueur des identifiants, brouillon hors mission, bornes supérieures dépassées, tailles extrêmes ou tous les formats. Leurs assertions ne deviennent pas une couverture exhaustive parce qu’elles passent. Le jeu d’évaluation avec erreurs graves et cas rares aide à organiser ces ajouts et à documenter les familles encore absentes.

Observer le dispatch après les refus et les accords

Vérifier qu’aucun refus ne touche le faux service

La trace conserve le verdict et l’indicateur de passage au handler. Seuls V-11 et V-12 créent un objet dans le registre local. Les dix refus n’ajoutent aucun devis. Le cas utile prouve aussi que le contrôleur ne refuse pas systématiquement toutes les propositions. Un test réduit à compter les erreurs pourrait rester vert alors qu’un handler a été appelé avant le refus.

L’entrée du faux handler est une structure déjà contrôlée ; sa sortie contient brouillon, quantité, montant, devise et indicateurs sans réservation ni envoi. Sa responsabilité est limitée à enregistrer cet objet synthétique dans la simulation. Un produit doit en plus relier demande, autorisation, opération et résultat persistant. Le refus de format et la preuve d’effet sont des événements distincts du même parcours.

Distinguer devis créé et disponibilité engagée

Les deux devis portent chacun deux unités avec disponibilité observée de trois. Ils ne réservent rien ; leur coexistence ne prouve donc pas que quatre unités pourront être livrées. La simulation vérifie une admission selon un état figé, sans consommation de stock. Le service doit employer des verbes cohérents avec cette portée et garder les étapes de réservation ou engagement comme opérations différentes.

Une écriture distante dont la réponse est perdue demande également un rapprochement. Le contrôle des arguments peut être parfait et la reprise produire un doublon si elle relance sans vérifier l’effet antérieur. L’identité d’opération et la preuve persistante appartiennent au contrat d’exécution. Notre registre local ne simule ni coupure réseau ni idempotence concurrente et ne prétend pas résoudre cette autre frontière.

Rendre un refus corrigeable sans inventer une valeur

Retourner une contrainte utile au bon acteur

Une quantité manquante peut conduire à demander la quantité souhaitée. Une chaîne au mauvais type peut conduire à une nouvelle proposition structurée si la valeur provient déjà d’une source admise. Un client hors mission ne doit pas inviter l’agent à chercher un autre identifiant par ressemblance. Le motif de refus détermine la prochaine étape ; il ne donne pas une permission de contourner le périmètre.

Le service limite aussi les tentatives de correction. Un agent qui produit successivement des quantités ou clients différents pour trouver une entrée acceptée ne réalise pas une clarification légitime. La reprise doit conserver mission et intention, avec les sources de toute valeur changée. Le budget d’essai, le transfert humain et l’arrêt de boucle sont décidés selon les conséquences et la capacité d’exploitation.

Différencier correction de format et changement d’accord

Passer d’une quantité chaîne à un nombre conserve parfois le sens. Passer de quatre à deux unités change la demande commerciale. Le produit ne traite pas ces deux gestes comme la même réparation. Si le contexte ou la proposition change matériellement, l’accord doit être réexaminé dans le parcours approprié. Une correction destinée à rendre le JSON valide ne doit pas réduire le besoin de l’utilisateur sans lui montrer ce choix.

Le dossier métier IA avec états et exceptions organise ces reprises. L’état Refusé pour arguments ne devient pas Résolu avant la nouvelle décision et son effet. Les opérateurs retrouvent la demande originale, le défaut et la proposition corrigée, au lieu de découvrir seulement le dernier appel accepté.

Versionner le contrat entre modèle et application

Maintenir deux copies compatibles et vérifiées

Le schéma envoyé au modèle et celui exécuté par l’application peuvent diverger lors d’un déploiement. Un champ renommé, une devise ajoutée ou une propriété devenue obligatoire modifie l’entrée attendue. L’équipe conserve une version de contrat liée à la capacité ouverte et teste les propositions des versions encore admises. Une mise à jour de prompt ne doit pas élargir automatiquement les champs acceptés par le service.

La fermeture des propriétés supplémentaires impose également une politique de migration. Un ancien appel avec un champ retiré peut être rejeté, traduit par un adaptateur explicite ou orienté vers un autre contrat. Supprimer silencieusement les valeurs inconnues peut faire croire que la demande a été respectée alors qu’une partie significative a disparu. La décision dépend du sens métier du champ, pas seulement de sa compatibilité syntaxique.

Rejouer les cas utiles autant que les cas refusés

La recette garde un cas nominal et un cas de représentation numérique admise. Une évolution qui refuse tous les arguments est un défaut de service, même si elle ferme les cas négatifs. Le contrôle conserve résultats, version de bibliothèque, schéma et règles de contexte. Un changement de validateur exige de vérifier le comportement des formats et types réellement utilisés, sans se fier uniquement au numéro de version.

La supervision sépare erreurs de structure, refus de périmètre, refus métier et échecs d’effet. Une hausse de refus après déploiement peut venir d’un schéma incohérent avec le prompt ou d’un changement légitime des données. Elle ne démontre pas à elle seule une dégradation du modèle. Les traces doivent permettre d’attribuer la cause sans exposer systématiquement toutes les valeurs sensibles dans les tableaux d’exploitation.

Erreurs fréquentes de validation des arguments IA

Confondre description fournisseur et contrôle serveur

Le premier défaut est de publier un schéma à l’agent sans l’appliquer au handler. Le second est de considérer le succès d’une sortie structurée comme une preuve d’autorisation. Paradoxalement, un appel parfaitement conforme peut être plus facile à transmettre alors qu’il vise le mauvais objet. Le périmètre vient du contexte de confiance et les contrôles métier restent applicables après la forme.

Autre piège : accepter un montant généré parce qu’il respecte un type numérique. Le schéma peut en vérifier la forme sans connaître prix, remise ou condition applicable. Notre outil ne reçoit aucun montant final ; il le calcule depuis sa source fictive. Le contrat d’un autre processus peut différer, mais il doit conserver qui est autorisé à fixer la valeur et quelles preuves permettent de l’utiliser.

Tester une erreur annoncée sans vérifier l’absence d’effet

Un message de validation affiché après une création ne rend pas l’opération annulée. La recette instrumente donc le passage au service et ses objets. Elle n’observe pas seulement le statut de retour. Une erreur peut également être masquée par une valeur par défaut ajoutée trop tôt : la proposition originale paraît admise alors que le contrôleur n’a jamais exercé le refus attendu du champ manquant.

Enfin, une regex d’identifiant ne démontre pas l’existence ou les permissions. Un contrôle de disponibilité n’assure pas sa stabilité jusqu’à l’écriture. Ces distinctions doivent rester lisibles dans le dossier de lancement. Les développeurs peuvent alors attribuer le prochain essai à la bonne frontière, plutôt que multiplier des variantes de prompt pour compenser une règle que seul le service sait appliquer.

Plan d’action : fermer les défauts avant d’ouvrir l’outil

Écrire le contrat à partir de la capacité réelle

Choisissez une opération et les effets qu’elle peut obtenir. Le propriétaire métier définit valeurs et conditions ; l’application détermine ce qui vient de la session, des sources et des arguments. Construisez ensuite le schéma exécuté, avec les formats réellement activés et les règles qui restent hors schéma. Un champ ne devient pas fiable parce qu’il porte un nom familier dans le JSON.

1. Documenter les champs admis et ceux calculés par le service.
2. Associer chaque contrainte à un cas négatif et une décision de reprise.
3. Tester les arguments avant tout dispatch ou lecture hors périmètre.
4. Contrôler le registre d’effets après refus et admission.
5. Conserver les limites non couvertes avec les conditions d’ouverture.

Le jeu garde aussi plusieurs défauts simultanés, un cas nominal et les représentations admises. La trace doit montrer proposition, verdict et effet observé pour la version évaluée. La responsabilité d’exploitation inclut la compréhension des refus, leur volume et le transfert humain ; fermer une erreur technique sans offrir de reprise peut laisser la demande métier définitivement bloquée.

Relier la validation aux autres frontières de l’agent

Le contrat de mission de l’agent définit les capacités ouvertes. Le contrat d’exécution et de preuve d’effet relie permission, accord et résultat. Les arguments validés ne permettent pas de sauter ces étapes ; ils donnent seulement une proposition examinable dans le périmètre admis.

La recette intégrée ajoute le vrai connecteur, les droits actuels, la concurrence sur les conditions et les résultats inconnus. Les éditeurs et intégrateurs du logiciel qualifient l’interface réellement disponible et ses garanties. Une preuve locale sur un faux devis ne devient pas la promesse qu’un ERP possède une API ou une transaction adaptée. Les réserves doivent orienter le cadrage et la décision d’ouverture.

Conclusion : une entrée valide reste une proposition

Le JSON lisible, le schéma satisfait et la demande réalisable constituent des décisions distinctes. L’application garde les valeurs de confiance, applique les contraintes avant le handler et conserve la raison du refus. Une propriété de format, un identifiant régulier ou un nombre bien typé ne remplace pas une règle de mission, de droit ou de disponibilité.

Les douze propositions manuscrites vérifient ici dix refus et deux admissions sur un faux service. Le montant est calculé localement, la date impossible dépend du contrôle explicite, et 2.0 est traité comme un entier mathématique admis. Aucun modèle ni ERP n’est testé, aucune quantité n’est réservée. Les preuves d’intégration doivent compléter cette frontière avant un effet réel.

La conception d’agents IA métier avec outils et contrôles applicatifs relie schéma, mission, conditions et reprise. Le produit conserve une capacité utile tout en refusant les arguments qui modifieraient la demande, viseraient un objet exclu ou imposeraient une valeur sans autorité.

Pour connecter une IA sur mesure à votre outil de devis, Dawap vous accompagne dans la définition des arguments que le modèle propose et des valeurs que le service fournit. La recette inclut une référence hors périmètre, une quantité impossible et un montant ajouté dans la proposition. Elle vérifie le refus avant l’appel métier, puis compare les demandes admises au prix et aux conditions réellement fournis par votre logiciel.