Vérifier ce que font les agents d’IA : permissions, points de validation et niveaux de risque

Ces dernières années, la plupart des efforts dédiés à l’IA générative ont porté sur la formulation de questions plus pertinentes. À mesure que les modèles acquièrent la capacité d’appeler des outils et de modifier des systèmes réels, une autre compétence devient plus importante : vérifier ce que l’IA a réellement fait. Cet article explique pourquoi une action erronée constitue un type de défaillance différent d’une réponse incorrecte, et vous propose un cadre pratique pour définir les permissions, intégrer une validation humaine et adapter l’autonomie au niveau de risque lors de la création ou de l’adoption d’agents.

Des systèmes qui répondent aux systèmes qui agissent

Les premiers assistants de conversation étaient passifs. Vous posiez une question, le modèle répondait, et c’était à vous de décider de la suite. Un agent modifie cette répartition des tâches. Étant donné un objectif, il peut interpréter la demande, planifier des étapes, appeler des outils, entreprendre des actions, examiner les résultats et continuer sans attendre votre intervention entre chaque étape.

La différence est la plus évidente avec une demande banale. Si vous demandez à un chatbot comment organiser un ensemble de dossiers en désordre, vous obtiendrez des conseils que vous pouvez suivre ou ignorer. Si vous donnez à un agent l’autorisation d’organiser ces dossiers, il pourra examiner les répertoires, renommer et déplacer des fichiers, créer de nouveaux dossiers, mettre à jour les données et supprimer ce qu’il considère comme des doublons. Un chatbot propose une action ; un agent la met en œuvre. Cet écart simple explique pourquoi la fiabilité doit être repensée lorsque des agents interviennent.

Pourquoi une action erronée coûte plus cher qu’une réponse fausse

Lorsqu’un modèle vous fournit des informations erronées, vous avez plusieurs occasions de le détecter. Vous pouvez remarquer qu’il y a quelque chose d’anormal, rechercher à nouveau, comparer avec une autre source ou simplement ignorer la réponse. L’être humain se trouve entre la sortie du système et toute conséquence qui en découle.

Dans un pipeline autonome, ce buffer disparaît. Le flux ci-dessous montre la forme typique : l’agent lit quelque chose, prend une décision, appelle un autre système, change d’état et passe à l’étape suivante. Notez qu’aucun élément de la chaîne ne s’arrête pour une révision.

Reads information
↓
Makes a decision
↓
Calls another system
↓
Changes something
↓
Continues automatically

Une erreur dans la première étape se propage à toutes les étapes suivantes. Une entrée mal interprétée entraîne une décision erronée, qui à son tour génère une appel API incorrect, ce qui conduit à un enregistrement modifié que les étapes ultérieures considèrent comme la vérité absolue. C’est pourquoi la question pertinente passe de savoir à quel point un modèle est capable à savoir dans quelle mesure on peut lui permettre d’agir en toute sécurité.

Principe du moindre privilège : définir ce que l’agent peut modifier

Réfléchissez à la manière dont vous intégreriez un nouvel employé. Dès le premier jour, vous ne lui accorderiez pas un accès illimité aux bases de données de production, aux fichiers clients, aux systèmes financiers, au code source et au pipeline de déploiement. Vous lui donneriez uniquement les droits nécessaires à ses fonctions et élargiriez progressivement ces accès au fur et à mesure que la confiance se développe.

Les agents méritent le même traitement. Accordez-leur uniquement l’accès nécessaire à une tâche, et séparez autant que possible les droits de lecture de ceux d’écriture :

• Un agent qui lit des documents n’a pas besoin de permission pour les supprimer.
• Un agent qui analyse du code source n’a pas besoin de permission pour déployer des versions en production.
• Un agent qui rédige des e-mails n’a pas besoin de permission pour les envoyer.

La règle est simple : un agent n’a accès qu’aux fonctionnalités indispensables à l’exécution de sa tâche. En pratique, cela signifie généralement l’utilisation d’outils spécifiquement conçus pour un but précis et de identifiants temporaires, plutôt qu’un jeton polyvalent, afin que les erreurs potentielles commises par un agent confus soient limitées par la conception même du système et non par son jugement.

Approbation humaine pour les actions importantes

L’un des modèles les plus efficaces est également l’un des plus simples : permettre à l’agent d’exécuter le travail, mais exiger qu’une personne approuve les actions ayant des conséquences importantes avant leur mise en œuvre. La séquence présentée ci-dessous divise le processus en une phase de préparation gérée par l’agent et une phase d’exécution qui ne commence qu’après que quelqu’un ait examiné et approuvé le changement proposé.

AI identifies issue
↓
AI proposes solution
↓
AI prepares changes
↓
Human reviews
↓
Human approves
↓
System executes

Tout ne doit pas nécessiter une approbation, sinon les examinateurs commenceront à approuver par réflexe. La synthèse de cent documents peut être effectuée sans surveillance en toute sécurité. Les exigences doivent augmenter fortement pour des actions de ce type :

• transférer de l’argent
• supprimer des données en production
• publier quelque chose publiquement
• déployer du logiciel
• modifier les permissions de sécurité
• contacter des clients

Si vous mettez en œuvre ce modèle, nos guides sur les agents contrôlés par approbation avec les interruptions et points de vérification de LangGraph ainsi que sur l’état, l’approbation et l’idempotence pour les agents d’action couvrent les mécanismes correspondants.

La vérification en tant que compétence essentielle

L’ingénierie des prompts, et plus récemment l’ingénierie du contexte, reçoivent la majeure partie de l’attention. La vérification mérite autant d’attention : pouvez-vous déterminer si le résultat est réellement correct ?

Cela dépend des connaissances sectorielles. Un développeur doit être capable d’analyser de manière critique le code généré. Un professionnel des finances a besoin d’une expertise suffisante pour remettre en question les calculs générés. Un chercheur doit vérifier que les sources citées existent et déterminer ce qui est affirmé. Un designer doit juger si un layout généré résout réellement le problème. L’IA peut accélérer considérablement l’exécution, mais une exécution rapide sans vérification signifie le plus souvent commettre des erreurs plus rapidement.

Adapter l’autonomie au risque

Poser la question sous la forme « L’IA peut-elle être fiable ? » avec une réponse oui ou non est peu utile. La confiance doit être accordée tâche par tâche, en fonction du risque de défaillance. Un modèle simple à trois niveaux constitue un bon point de départ.

Risque faible : laisser fonctionner

La rédaction de synthèses de notes de réunion en est un bon exemple. Les conséquences d’une erreur sont mineures et faciles à détecter, ce qui justifie un haut degré d’autonomie.

Risque moyen : automatiser, puis vérifier

Modifier une fonctionnalité logicielle constitue un cas typique de niveau intermédiaire. L’agent peut effectuer la modification, mais des tests automatisés et une revue de code doivent confirmer le résultat avant que celle-ci ne soit déployée.

Risque élevé : autorisation explicite requise

Une demande de transfert d’argent vers un compte relève de cette catégorie. Une autorisation humaine stricte doit être obligatoire, quel que soit le degré de confiance perçu chez l’agent.

Le principe se généralise : la vérification doit être proportionnelle au coût d’une erreur.

Plus d’autonomie ne signifie pas automatiquement mieux

Il est tentant de penser que l’agent le plus autonome est aussi le meilleur. Une question plus pertinente est de déterminer quel niveau d’autonomie convient à cette tâche en particulier. Les niveaux utiles forment une échelle :

• seulement suggérer
• préparer le travail pour qu’un autre l’exécute
• exécuter après confirmation

Fonctionne entièrement de manière automatique

Les systèmes bien conçus placent chaque fonctionnalité à l’échelon approprié plutôt que de tout regrouper en haut.

Questions à se poser avant de connecter un outil

Les développeurs ne se contentent plus de relier les modèles à une simple zone de texte. Les agents sont de plus en plus connectés à un large éventail de systèmes, tels que ceux listés ci-dessous.

APIs
Databases
Browsers
File systems
Cloud infrastructure
Development tools
Business applications
External services

Chaque intégration ajoute une fonctionnalité et, avec elle, une nouvelle façon d’échouer. En plus de vous demander si l’agent peut accomplir la tâche, examinez ces questions pour chaque outil que vous mettez à disposition :

• Quels données et systèmes peut-il atteindre ?
• Lequel d’entre eux peut-il modifier ?
• S’il échoue en cours de tâche, quel état reste-il ?
• Existe-t-il un moyen d’annuler ce qu’il a fait ?
• Qui approuve les opérations sensibles ?
• Toute action est-elle enregistrée de manière à pouvoir être auditée ultérieurement ?
• Comment l’arrêter rapidement ?

Ces réponses peuvent être tout aussi importantes que le modèle choisi. Une règle pratique consiste à veiller à ce qu’aucune action irréversible et non enregistrée ne puisse être exécutée sans l’intervention humaine.

L’alphabétisation en IA inclut désormais l’alphabétisation des risques

Savoir comment obtenir des résultats à l’aide d’un outil d’IA ne suffit plus ; il faut également comprendre où il peut échouer. Ce n’est pas une raison de craindre, mais plutôt ce qui distingue un utilisateur compétent d’un utilisateur négligent. Un utilisateur mature se demande non seulement si l’IA peut faire quelque chose, mais aussi s’il convient qu’elle le fasse sans supervision.

Jugement humain, exécution par machine

Les agents permettent à une seule personne d’assumer des tâches qui nécessitaient auparavant toute une équipe, que ce soit en matière de recherche, d’analyse, de codage, de création de contenu, d’automatisation, de traitement de données ou d’opérations. Cette capacité supplémentaire s’accompagne de responsabilités accrues. Une répartition du travail efficace se présente comme suit :

• Les humains définissent l’intention.
• L’agent s’occupe de l’exécution.
• Le système environnant impose des limites.
• Les humains vérifient les résultats importants.

Points clés

• La première vague de l’IA générative visait à communiquer avec des machines ; l’ère des agents consiste à leur déléguer des tâches, et cette délégation repose sur la confiance, les limites, la vérification et la responsabilité.
• Les erreurs dans les pipelines autonomes s’accumulent, il faut donc concevoir des systèmes permettant de les contenir : privilèges limités, actions réversibles et journaux complets.
• Accordez l’approbation humaine aux actions à conséquences importantes et difficiles à annuler, et laissez les tâches à faible risque fonctionner sans surveillance afin que les revues restent pertinentes.
• La question fondamentale évolue de ce que l’IA peut faire à ce que vous devriez lui permettre de faire seule, et y répondre correctement devient une compétence essentielle en ingénierie.

Lectures complémentaires

• Agents gérés par des portes d’approbation dans LangGraph : interrupt(), points de contrôle et stockage — Construisez pas à pas un agent LangGraph : un graphe ReAct explicite, une approbation humaine via interrupt(), ainsi qu’un mémoire inter-thread avec un stockage, pour aboutir à un assistant qui demande d’abord l’approbation.