Agents avec outils : concevoir les autorisations, la mémoire et la reprise après échec sans perdre le contrôle

Du chatbot à l’agent : une autonomie située, pas une confiance aveugle

Un agent n’est pas simplement un assistant qui répond dans une conversation. Pour le concevoir utilement, on peut le définir comme la combinaison d’un modèle qui interprète une tâche, d’un état d’exécution, d’un accès à des outils, d’une politique qui délimite les décisions autorisées et d’une boucle qui observe les résultats puis décide de l’étape suivante. Il peut consulter une base de données, ouvrir un ticket, rechercher une information, mettre à jour un enregistrement ou appeler une API. La différence importante n’est pas que le modèle « raisonne », mais que le système peut affecter d’autres systèmes au-delà de la fenêtre de discussion.

Cette distinction impose de déplacer la question initiale. Il vaut mieux ne pas commencer par « quel modèle obtient les meilleurs résultats ? », mais par « que peut faire ce système, avec quelle identité, sur quelles ressources et à quelle condition ? ». La capacité d’un modèle peut aider à accomplir une tâche, mais elle ne remplace ni les limites d’autorisation, ni la validation du résultat, ni la supervision. Cette conclusion vaut aussi lors de la lecture d’analyses de GPT‑6 Astra, Claude Opus 5 ou Gemini 3.8 Flash : une capacité déclarée ou mesurée plus élevée n’élimine pas le besoin de contrôles opérationnels.

Toutes les tâches n’exigent pas un agent autonome. Un flux fixe, composé d’étapes prévisibles et de peu d’exceptions, peut être mieux traité par une automatisation conventionnelle ou par un workflow où le modèle se limite à classifier ou à rédiger une proposition. L’autonomie supplémentaire doit être justifiée par la variabilité de la tâche et par la capacité à contenir ses effets. Comme règle initiale, une action externe doit être plus restreinte qu’une consultation, et une modification difficile à annuler doit exiger davantage de preuves et de supervision qu’une action réversible.

La carte d’entrée recommandée pour la page mère est « Agents : conception, évaluation et supervision ». Cette page doit présenter ce guide comme un cadre d’architecture et de décision, et non comme une recette universelle ou une comparaison de fournisseurs.

Avant de connecter un outil : classer l’impact de chaque action

Un outil ne doit pas être activé parce qu’il semble utile dans une démonstration. Il doit disposer d’une fiche d’action : objectif, systèmes affectés, données reçues, identité utilisée, opérations autorisées, limites de volume, effet réversible ou irréversible, dépendance externe et responsable humain. Cette fiche rend visible une distinction souvent masquée : « consulter des commandes » et « annuler des commandes » peuvent utiliser la même API, mais ne représentent pas le même risque.

La classification peut combiner quatre axes. L’impact estime le dommage si l’action est erronée ; la réversibilité détermine s’il est possible de l’annuler sans danger ; la portée mesure combien de comptes, d’enregistrements ou de systèmes peuvent être affectés ; la sensibilité évalue les données ou secrets exposés. Un cinquième axe pratique est l’ambiguïté : si la demande admet plusieurs interprétations raisonnables, l’action ne devrait pas être exécutée de manière autonome, même si elle est techniquement possible.

Les communications externes méritent une catégorie propre. Envoyer un courriel à un client, publier une réponse ou créer un incident peut être réversible techniquement, sans l’être nécessairement sur les plans de la réputation, du contrat ou de la vie privée. Il en va de même pour les changements en production : disposer d’une opération de retour arrière ne rend pas un déploiement incorrect inoffensif. Dans ces cas, la conception doit prévoir une revue du contenu, du destinataire, de la portée et du moment d’exécution.

Dans le premier tiers de l’implémentation, il est utile de relier cette classification au guide sur les « actions irréversibles et approbations » lorsqu’il sera publié. L’objectif est que l’approbation ne soit pas un geste générique de confirmation, mais une décision informée portant sur une action précise, ses paramètres et ses conséquences possibles.

Autorisations de moindre privilège : des contrôles qui ne dépendent pas du texte du modèle

Le moindre privilège consiste à accorder uniquement les droits nécessaires à une tâche définie, pendant la durée nécessaire et sur les ressources nécessaires. Pour les agents, cela impose d’aller au-delà d’un jeton générique doté d’un accès étendu. Une crédential qui permet de lire, modifier et supprimer toutes les ressources transforme une sortie erronée, une instruction manipulée ou une défaillance d’intégration en incident de grande ampleur.

Une pratique robuste consiste à séparer les identités par outil, environnement et finalité. L’agent de support ne devrait pas employer la même identité que le processus de déploiement, et une identité de test ne devrait pas accéder à la production. Les identifiants à durée de vie limitée réduisent la fenêtre d’exposition, mais ne corrigent pas à eux seuls une autorisation excessive : des périmètres d’accès précis, des quotas, des restrictions réseau et une validation côté serveur sont également nécessaires.

L’outil doit vérifier l’autorisation de manière déterministe. Il vaut mieux exposer des opérations concrètes — par exemple, créer un brouillon de réponse pour un dossier attribué — qu’une interface générique autorisant l’exécution de requêtes ou de commandes arbitraires. Lorsque le système utilise des listes de ressources autorisées, des montants maximaux ou des rôles, ces limites doivent être appliquées hors du contexte que le modèle peut modifier. Les instructions du prompt peuvent orienter ; elles ne constituent pas une frontière de sécurité suffisante.

Les connecteurs doivent traiter tout contenu reçu depuis des pages, documents, courriels, tickets et réponses d’outils comme des données potentiellement non fiables. Le fait qu’un texte contienne un ordre ne lui confère aucune autorité. La politique d’action, l’identité de service et le validateur de paramètres doivent prévaloir sur toute instruction découverte pendant la tâche.

Cette section doit renvoyer, lorsqu’il existera, à « données sensibles et identifiants ». Pour les équipes qui traitent des données personnelles, la minimisation implique aussi d’éviter de transmettre à l’outil davantage d’attributs que nécessaire pour accomplir l’action, et de définir qui peut accéder aux journaux produits.

Quand exiger un humain dans la boucle

La revue humaine est plus utile lorsqu’elle intervient à un point de décision défini. Demander une confirmation pour chaque consultation à faible risque ralentit le travail et favorise les approbations mécaniques ; ne pas en demander pour des actions importantes transfère la charge de détection de l’erreur à ceux qui en subissent les effets. La conception doit fixer des seuils explicites et fournir à la personne chargée de la revue les informations nécessaires à sa décision.

Une approbation devrait présenter l’action prévue, les paramètres finaux, les systèmes affectés, l’identité qui l’exécutera, la justification générée par l’agent et l’effet d’une approbation ou d’un refus. Si l’action dépend de faits incertains, l’interface doit également afficher cette incertitude au lieu de présenter une recommandation comme s’il s’agissait d’une vérification. Approuver une intention abstraite, telle que « résoudre le dossier », est moins sûr qu’approuver une opération délimitée, telle que « envoyer ce brouillon à ce destinataire ».

Les suppressions, paiements ou engagements économiques, changements de production, communications externes, modifications d’autorisations, traitements de catégories particulièrement sensibles et opérations dont la demande est ambiguë devraient, comme point de départ, passer par une revue humaine. L’organisation peut ajouter des seuils de montant, de nombre d’enregistrements ou de gravité opérationnelle. Ces seuils relèvent de la politique interne : aucun chiffre universel ne rend une action sûre.

La supervision humaine ne doit pas non plus être comprise comme une excuse pour négliger le système. La personne chargée de la revue a besoin d’une autorité réelle pour refuser, corriger et escalader ; d’une formation sur le processus ; et d’une charge de travail qui permette une vraie revue. Si elle reçoit des centaines de demandes presque identiques, le contrôle peut devenir une formalité.

Une mémoire utile sans conservation indéfinie

La mémoire peut améliorer la continuité d’une tâche, mais elle accroît aussi la surface de risque pour la vie privée, le risque d’employer des informations obsolètes et la difficulté à corriger les erreurs. Il convient de distinguer au moins le contexte de session, l’état opérationnel d’une tâche, les préférences persistantes autorisées, les connaissances récupérées depuis des sources documentaires et les journaux d’audit. Ces catégories remplissent des finalités différentes et ne devraient pas partager automatiquement la même durée de conservation ni les mêmes autorisations.

Le contexte de session sert à maintenir la cohérence pendant une interaction et expire généralement à sa fin ou après un délai bref. L’état opérationnel conserve les informations nécessaires pour reprendre un travail, comme une référence de dossier ou un point de contrôle. Les préférences persistantes nécessitent une finalité claire, une provenance connue et un mécanisme de consultation et de correction. Les connaissances récupérées doivent conserver leur origine, leur version et leur date afin que le système puisse détecter si la source a été remplacée ou invalidée.

La provenance est aussi importante que le contenu. Si une mémoire provient d’un utilisateur, d’un système métier ou d’une inférence de l’agent lui-même, le système devrait les distinguer. Une inférence non vérifiée — par exemple une priorité ou une préférence déduite — ne doit pas être traitée comme une donnée confirmée. De plus, une mémoire persistante ne devrait pas devenir un moyen de conserver des secrets, des données non pertinentes ou des instructions introduites par un contenu externe.

Avant de stocker une information, il faut répondre à quatre questions : quelle finalité précise couvre-t-elle, qui peut la lire, quand expire-t-elle et comment est-elle invalidée ? Le futur guide sur la « mémoire, conservation et expiration » pourra approfondir ces politiques. Dans le cadre européen, si la mémoire contient des données personnelles, sa conception doit être évaluée au regard des obligations applicables de protection des données ; ce guide ne remplace pas l’analyse juridique et ne détermine pas à lui seul la base légale d’un traitement.

Concevoir pour l’échec : arrêter, vérifier et reprendre

Les défaillances d’outils, de réseaux et de dépendances externes sont normales. Les réponses incomplètes, délais d’attente et états ambigus le sont également : un appel peut être arrivé au système destinataire même si l’agent n’a pas reçu de confirmation. Une conception robuste ne suppose pas qu’« effectuer une nouvelle tentative » est toujours sûr. Elle doit d’abord savoir quelle opération a été tentée, quel résultat a été confirmé et quelles opérations peuvent être répétées sans modifier l’effet final.

La sémantique HTTP distingue les opérations idempotentes, dont l’effet prévu est identique après une ou plusieurs requêtes identiques, de celles qui ne le sont pas. Cette distinction aide à concevoir les nouvelles tentatives, mais n’élimine pas le besoin de vérifier l’état métier. Une requête techniquement idempotente peut encore avoir des conséquences imprévues si ses paramètres sont incorrects. Pour les opérations de création, de paiement ou d’envoi, une clé d’idempotence et une consultation de l’état avant une nouvelle tentative sont généralement plus appropriées que la répétition aveugle de l’appel.

L’agent a besoin de conditions d’arrêt. Il faut fixer un nombre limité de tentatives, des délais d’attente, un budget d’appels et des critères d’escalade. Après le dépassement d’un seuil, le dossier doit rejoindre une file de revue avec le contexte minimal nécessaire : action prévue, identifiant de corrélation, réponses reçues et étapes déjà réalisées. Réessayer indéfiniment peut amplifier un incident externe ou générer des actions dupliquées.

Toute action importante devrait comporter un point de contrôle avant son effet irréversible et, lorsque cela est possible, un plan de compensation. Une compensation n’équivaut pas toujours à une annulation parfaite : rembourser un montant n’efface pas une communication déjà envoyée, et restaurer un enregistrement ne supprime pas une éventuelle divulgation. La documentation de reprise doit déclarer explicitement ces limites.

Observabilité et audit sans collecter de données inutiles

L’observabilité permet de reconstruire ce qui s’est produit ; elle n’exige pas de conserver sans limite chaque donnée échangée. Pour une action importante, le journal devrait associer la demande initiale, la politique appliquée, les outils choisis, les paramètres autorisés ou une représentation protégée de ceux-ci, l’identité d’exécution, le résultat, les tentatives et l’intervention humaine. Les identifiants de corrélation permettent de suivre un dossier entre composants sans recopier le contenu complet dans tous les journaux.

Les journaux doivent être protégés comme un actif sensible. S’ils comprennent des prompts, réponses, documents ou paramètres, ils peuvent contenir des données personnelles, des secrets ou des instructions non fiables. Ils nécessitent donc des contrôles d’accès, une conservation définie, une séparation des environnements et des mécanismes empêchant les modifications silencieuses. Il est également utile de distinguer le journal opérationnel destiné à détecter les défaillances du journal d’audit destiné à enquêter sur une décision ; ils peuvent exiger des niveaux de détail et d’accès différents.

Une bonne reconstruction sépare les faits de l’interprétation. Il doit être possible de savoir quelle donnée un outil a renvoyée, quelle règle a bloqué ou autorisé une opération et quelle recommandation le modèle a formulée. Il n’est pas raisonnable de promettre une explication complète de chaque comportement du modèle, mais il est possible d’enregistrer la chaîne des décisions programmatiques et les artefacts opérationnels qui déterminent si une action a été exécutée.

La minimisation n’est pas seulement une obligation de confidentialité ; elle améliore la sécurité et l’utilité des journaux. Un journal excessif rend les signaux pertinents plus difficiles à trouver et élargit l’ensemble des données exposées en cas d’accès indu.

Évaluer avant le déploiement : tâche, autorisations et reprise

L’évaluation doit reproduire l’environnement de décision, et non mesurer seulement la qualité d’une réponse textuelle. Un plan minimal combine des tâches représentatives, des cas limites, des erreurs d’outils, des demandes ambiguës, des tentatives d’introduction d’instructions à partir d’un contenu externe et des vérifications d’autorisation. Le critère de réussite doit inclure l’accomplissement correct d’une tâche autorisée, mais aussi le refus d’une action interdite, l’arrêt face à l’incertitude et l’escalade lorsqu’elle est nécessaire.

Les benchmarks sont utiles pour comparer certaines capacités dans des conditions définies. Terminal-Bench évalue la résolution de tâches dans des environnements de terminal isolés, tandis qu’OSWorld rassemble des tâches sur des applications web et de bureau dans des environnements réels d’évaluation. Ces mesures peuvent apporter des signaux sur les performances d’un agent dans ces tâches, mais elles ne certifient pas que son identité dispose des bonnes autorisations, qu’il protège les données d’une organisation ou qu’il se rétablit de manière sûre dans une intégration donnée.

Lorsqu’ils sont disponibles, des liens vers Terminal-Bench et OSWorld doivent donc préciser que les benchmarks ne remplacent pas les tests dans son propre environnement. Les tests internes nécessitent des comptes d’essai, des données synthétiques ou convenablement contrôlées, la simulation des dépendances et des cas de reprise. Ils doivent aussi vérifier qu’un refus d’autorisation ne déclenche pas des chemins alternatifs plus permissifs.

Un cadre de gestion des risques peut aider à attribuer les responsabilités, documenter les décisions et réexaminer les contrôles tout au long du cycle de vie. Il ne remplace pas la spécification technique de chaque autorisation. Les preuves de test, les incidents et les changements d’outils doivent alimenter des révisions périodiques de la matrice d’autonomie.

Modèle final : décider du niveau d’autonomie

La décision d’autonomie doit pouvoir être révisée comme une politique, et ne pas rester implicite dans un prompt. Pour chaque outil et chaque action, documentez la catégorie de risque, les données concernées, l’autorisation précise, l’identité, les limites, le besoin d’approbation, la stratégie de reprise, les journaux et le responsable. Si l’un de ces éléments n’est pas défini, l’autonomie attribuée est probablement prématurée.

Un point de départ raisonnable consiste à utiliser quatre niveaux. Le niveau lecture seule permet de consulter des ressources autorisées. Le niveau proposition avec approbation permet d’enquêter et de préparer une action, mais réserve son exécution à une personne. Le niveau exécution limitée autorise des opérations réversibles et délimitées par des règles déterministes. Le niveau exécution autonome est réservé aux actions à faible impact, de portée réduite, avec une annulation ou compensation connue, une supervision disponible et des preuves de tests suffisantes.

La matrice ne doit pas être permanente. Un incident, un changement de fournisseur, un nouvel outil, l’élargissement des données accessibles ou une modification de la politique métier justifient sa révision. De même, un agent peut débuter en mode proposition et ne gagner de l’autonomie qu’après avoir démontré un comportement fiable dans un périmètre mesuré. Réduire l’autonomie après une anomalie est une réponse de contrôle, non un échec du projet.

Comme prochaine étape éditoriale, la conclusion peut renvoyer à « décider s’il faut automatiser un flux ». La question décisive n’est pas de savoir si un agent peut accomplir une tâche, mais si l’organisation peut délimiter, observer et rétablir ses effets avec un niveau de risque acceptable.

Portée et incertitudes

Ce guide présente un cadre technique et opérationnel fondé sur les sources institutionnelles, la documentation technique et les guides de construction d’agents fournis. Ses recommandations d’architecture ne garantissent pas à elles seules la sécurité d’un cas d’usage et ne remplacent ni les tests, ni l’analyse des menaces, ni l’examen de la confidentialité, ni les contrôles sectoriels, ni un conseil juridique.

L’application du Règlement général sur la protection des données dépend des circonstances du traitement, des rôles des parties et d’autres exigences applicables. En particulier, ce guide ne détermine pas si un cas donné relève des règles concernant les décisions individuelles fondées exclusivement sur un traitement automatisé, ni quelles garanties supplémentaires sont requises. Il ne couvre pas non plus les obligations nationales, professionnelles, financières, sanitaires ou contractuelles susceptibles d’être pertinentes.

Les caractéristiques des outils, modèles, API et benchmarks évoluent rapidement. Avant le déploiement, l’équipe doit confirmer la version évaluée, le comportement des intégrations, les autorisations effectives et les conditions d’exécution. Les preuves obtenues dans un environnement de test ne doivent pas être extrapolées automatiquement à la production.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.