Choisir les outils d’IA à partir d’une tâche délimitée

Décrivez d’abord le résultat de travail attendu. Il détermine les fonctions nécessaires à l’assistant d’IA. Disposer d’un accès à un système de tickets ne justifie pas d’en exposer toutes les fonctions au modèle.

Traduire une tâche en fonctions

Dans cet exemple fictif, la tâche consiste à préparer un brouillon de réponse interne pour le ticket T-62. Celui-ci appartient au compte client K-18 et renvoie à un projet. L’assistant peut lire la demande reçue, consulter l’état du projet associé et enregistrer un brouillon. L’envoi ne fait pas partie de cette tâche.

Les noms d’outils sont nos propres exemples. Cette matrice décrit le périmètre prévu :

OWASP recommande de limiter les fonctions des outils et leurs autorisations au nécessaire. Un appel dédié et précisément délimité est plus facile à encadrer qu’un outil général exécutant des commandes ou utilisant des adresses de destination arbitraires.

Vérifier le contexte sur le serveur

Le serveur détermine le contexte client autorisé à partir de la personne connectée et du ticket vérifié. Un identifiant client fourni librement par le modèle ne doit pas élargir ce contexte. L’appartenance du projet au dossier autorisé doit aussi être vérifiable.

Chaque appel d’outil vérifie à nouveau les droits et les champs autorisés. La liste d’outils visible aide à orienter le comportement ; le contrôle d’accès effectif reste dans le service qui exécute l’opération. Un argument bien formé ou une instruction dans le texte du ticket n’accorde aucun droit supplémentaire.

Transmettre les résultats comme des états

L’enregistrement réussi d’un brouillon nécessite une confirmation du système de tickets. Le texte généré seul ne prouve pas cet enregistrement. Si l’écriture échoue ou si son résultat reste inconnu, l’interface affiche cet état. Elle ne doit pas le présenter comme un message envoyé au client.

Si l’envoi devient possible ultérieurement, il s’agit d’une extension distincte avec des destinataires, des droits et, si nécessaire, des validations définis. Une demande supplémentaire du modèle ne l’active pas au passage.

Tester les limites avant utilisation

Vérifiez le parcours autorisé jusqu’au brouillon enregistré, puis un autre contexte client, une demande d’envoi dans le texte du ticket et un échec d’enregistrement. Les résultats attendus sont respectivement un brouillon interne, un refus d’accès, aucun envoi et un état d’erreur visible.

Pour chaque cas, consignez les fonctions autorisées, l’état attendu du système et le résultat réel. Vous pourrez ainsi voir si la limite technique respecte la tâche même lorsque le modèle propose un appel inapproprié.

Sources

• OWASP — LLM06:2025 Excessive Agency