Changer de modèle exige aussi d’examiner son comportement

Un adaptateur de modèle commun peut simplifier la connexion technique. Il traduit, par exemple, les formats des fournisseurs en un protocole d’outil interne. La manière dont un appel arrive est alors définie. L’application doit encore vérifier si le nouveau modèle interprète correctement une requête échouée.

Même appel d’outil, suite différente

Dans cet exemple entièrement fictif, un assistant demande le statut d’un projet. Les deux variantes ne peuvent utiliser que l’outil de lecture prévu pour cela. Nom d’outil, argument et code d’erreur sont nos propres valeurs d’exemple, pas l’interface d’un fournisseur nommé.

Le tableau montre deux suites supposées de la même requête refusée. Il ne rapporte aucune observation sur des modèles réels.

L’adaptateur peut traduire les deux appels de manière identique. Pourtant, la seconde suite affirme un statut que l’outil n’a pas fourni. Dans l’exemple, l’accès a été bloqué ; la réponse inventée reste une erreur métier. Elle ne doit pas servir de preuve de réussite de la requête.

L’application conserve ses limites

OWASP recommande de limiter les pouvoirs des outils et de faire appliquer les autorisations dans les systèmes en aval. Après un changement de modèle, chaque requête doit toujours être vérifiée dans le contexte utilisateur approprié. Un argument syntaxiquement valide n’autorise ni l’accès ni le contournement d’un refus.

L’exemple exige une gestion claire des accès refusés, des données manquantes et des erreurs temporaires. Ces situations peuvent nécessiter des étapes suivantes différentes. Une erreur ne doit pas entraîner automatiquement une requête plus large ou des autorisations supplémentaires.

Ce que l’adaptateur facilite réellement

Une interface limitée et documentée peut réduire les modifications. Si le périmètre des outils, le modèle de données et le contrat d’erreurs sont stables, il peut suffire d’adapter la connexion propre au fournisseur et les instructions associées après le changement de modèle. Une reconstruction complète n’est alors pas nécessairement requise.

Dans un parcours qui affiche directement les données d’outil vérifiées sans produire de suite librement rédigée, le point de défaillance montré ici peut être réduit. Les autres contrôles d’entrée, d’autorisation et de résultat restent pertinents. Le parcours réellement utilisé est déterminant.

Évaluer le changement par le comportement

Microsoft décrit des comparaisons sur les mêmes cas avec une attention distincte aux erreurs individuelles. Incluez les refus d’outil et les résultats manquants. Consignez si une erreur produit une limitation correcte, une action ultérieure non autorisée ou une affirmation sans fondement.

Une connexion fonctionnelle est un élément utile de l’interchangeabilité. La mise en service dépend aussi du respect des limites et des décisions prévues par la nouvelle configuration dans le parcours applicatif.

Sources

• OWASP 2025 — Excessive Agency

• Microsoft — Evaluate models, prompts, and agents