appel d’outils

En profondeur

Le circuit tient en quatre temps, toujours les mêmes. Le harnais décrit d’abord les outils disponibles dans le contexte : un nom, un rôle, des paramètres attendus. Le modèle, quand il juge un appel pertinent, produit une demande dans un format convenu plutôt qu’une réponse en langue courante. Le harnais reconnaît cette demande, la valide, exécute l’action, puis réinjecte le résultat dans le contexte et relance le modèle, qui reprend là où il s’était arrêté. Rien de tout cela ne sort du texte : le modèle n’a aucun accès direct au système d’information.

Un appel d’outils n’est pas une garantie d’exactitude. Le modèle choisit sur la foi d’un nom et de quelques lignes de description, et il remplit les paramètres comme il remplit le reste : par plausibilité. Un identifiant absent de votre demande sera donc parfois inventé, avec le même aplomb qu’une hallucination ordinaire, et deux outils aux périmètres qui se chevauchent produisent des choix erratiques. La validation par le harnais n’est pas un détail de mise en œuvre mais la condition du dispositif : elle décide si l’appel est recevable avant qu’il produise le moindre effet.

Le point sensible est l’enchaînement. Dès qu’un résultat d’outil revient dans le contexte, il devient du texte lu par le modèle, au même titre qu’une consigne : un document rapporté ou une page consultée peuvent donc contenir des instructions qui déclenchent l’appel suivant. Un système qui lit du contenu extérieur et dispose d’outils capables d’écrire, d’envoyer ou de payer réunit toutes les conditions d’un détournement, sans qu’aucune faille technique soit nécessaire. La réponse tient moins au modèle qu’à l’architecture : séparer ce qui lit de ce qui agit, réduire les droits de chaque outil au strict nécessaire, faire confirmer l’irréversible, et garder la trace de chaque appel.