Agents IA : la performance commence par les limites

L’autonomie utile d’un agent dépend de ses permissions, de sa traçabilité et de la place du contrôle humain.

Une voiture de course n’est pas rapide parce qu’on lui retire toutes les barrières.

Sur un circuit, on sait qui conduit. On connaît la piste. Il y a des drapeaux, une télémétrie, une voie des stands, une équipe qui surveille ce qui se passe et la possibilité d’arrêter la voiture si quelque chose ne va pas.

Personne ne trouverait sérieux de remplacer tout ça par une seule consigne :

« Elle est performante, laissez-la faire. »

Avec les agents IA, on est parfois étonnamment proche de cette logique.

Un agent IA ne se contente plus de répondre

Il faut déjà distinguer deux choses.

Quand vous demandez à une IA de rédiger un mail, d’analyser un document ou de vous proposer un tableau, elle produit quelque chose. Vous regardez le résultat. Puis vous décidez quoi en faire.

Un agent peut aller plus loin.

Il peut lire une boîte mail, consulter un CRM, chercher un document, modifier une donnée, déclencher un processus, appeler un autre outil et continuer son travail sans revenir vers vous à chaque étape.

C’est justement ce qui le rend intéressant.

Et c’est aussi ce qui change complètement la question de départ.

La question n’est plus seulement : « Est-ce que l’IA répond correctement ? »

Il faut maintenant se demander : qu’a-t-elle réellement le droit de faire ?

Le 27 août 2026, le NIST américain a publié un texte consacré précisément à ce problème. Son constat est assez simple : les premiers déploiements d’agents reproduisent de vieilles mauvaises habitudes informatiques, notamment le partage d’identifiants, les clés d’accès permanentes et les autorisations beaucoup trop larges.

Avec un collaborateur, ces pratiques sont déjà discutables.

Avec un système capable d’enchaîner des actions à vitesse machine, elles deviennent beaucoup plus intéressantes à regarder de près.

Donner son propre badge à l’agent

Prenons quelque chose de très banal.

Vous voulez automatiser le traitement de certaines demandes clients.

L’agent doit lire les nouveaux mails, retrouver la fiche du client dans votre CRM, consulter quelques informations, préparer une réponse et éventuellement mettre à jour le dossier.

Techniquement, la solution la plus rapide est tentante : on lui donne l’accès à votre compte.

Ça marche.

C’est même souvent comme ça qu’un prototype démarre.

Mais ensuite, impossible de distinguer proprement ce que vous avez fait de ce que l’agent a fait. Et puisque l’agent utilise vos droits, il peut potentiellement accéder à beaucoup plus de choses que ce dont il a réellement besoin.

Le NIST recommande au contraire de considérer les agents comme des identités à part entière, avec leurs propres identifiants et leurs propres autorisations.

L’analogie avec la course fonctionne assez bien ici.

Le pilote a un badge. Le mécanicien aussi. L’ingénieur de piste aussi.

Ils travaillent tous pour la même équipe, mais personne ne distribue une clé universelle permettant d’ouvrir le camion, le stand, le coffre des pièces, la direction de course et toutes les voitures du plateau.

En informatique, on appelle notamment cela le principe du moindre privilège.

Pour un projet IA, je préfère une formulation plus simple :

donnez à l’agent exactement ce dont il a besoin pour son travail. Pas les clés du bâtiment.

Et si cet accès contient des données personnelles, la permission technique ne règle pas tout. Il faut aussi définir pourquoi ces données sont utilisées, limiter ce qui est réellement nécessaire, protéger l’accès et prévoir une durée de conservation cohérente. Le RGPD ne disparaît pas parce que l’utilisateur du CRM est devenu un agent.

Un prototype peut aller vite. Ses permissions ne devraient pas rester un prototype.

C’est un piège assez classique.

On construit une première version.

Pour gagner du temps, on utilise une clé API générale ou un compte existant.

On teste.

Ça fonctionne.

On améliore deux ou trois choses.

Puis le prototype devient un outil utilisé tous les jours.

Six mois plus tard, la clé de test est toujours là et l’agent possède des droits qui n’ont jamais été réellement examinés.

Le NIST souligne justement le problème des clés API et jetons d’accès statiques ou très longs. Ils sont pratiques pour commencer, mais ils augmentent les risques lorsqu’ils circulent entre plusieurs outils, fichiers ou systèmes.

Dans un atelier, on peut monter rapidement une pièce provisoire pour valider une idée.

On ne prend pas forcément le départ des 24 Heures avec cette pièce sans jamais revenir dessus.

Pour un outil IA, la phase prototype doit fonctionner de la même manière.

Certaines concessions sont acceptables pour tester.

Elles doivent être identifiées comme telles.

La télémétrie compte autant que le moteur

Le 1er septembre, l’OWASP GenAI Security Project a publié son Agent Control Standard.

L’idée centrale mérite d’être retenue même sans être spécialiste de cybersécurité : un agent utilisé en entreprise doit pouvoir être inspecté, tracé et contrôlé pendant son fonctionnement. Il faut savoir ce qu’il est, ce qu’il peut consulter, ce qu’il a fait et être capable d’intervenir sur son comportement.

Ça paraît évident.

Dans les faits, beaucoup d’automatisations sont encore construites avec une logique assez différente :

si tout fonctionne, personne ne regarde vraiment.

Puis un jour, une donnée est modifiée au mauvais endroit et commence l’enquête.

Quel outil a fait ça ?

Avec quel compte ?

À quelle heure ?

Sur quelle instruction ?

Qu’est-ce qui s’est passé juste avant ?

Impossible à dire proprement.

Sur une voiture de course, on mesure énormément de choses alors que le pilote est déjà extrêmement compétent.

Pas parce qu’on ne lui fait pas confiance.

Parce qu’une équipe sérieuse ne pilote pas uniquement au ressenti.

Un agent IA mérite la même discipline.

Et le bouton « demander confirmation » ne règle pas tout

La réponse facile consiste à demander une validation humaine avant chaque action importante.

Sur le papier, c’est rassurant.

Dans la vraie vie, si l’agent vous demande quinze fois par jour :

« Autorisez-vous cette action ? »

puis :

« Autorisez-vous l’accès à ce document ? »

puis :

« Voulez-vous continuer ? »

vous allez finir par cliquer sur oui sans lire.

Le NIST décrit précisément ce risque de fatigue de consentement. À force de demander une validation humaine sur chaque étape, le contrôle peut devenir purement mécanique.

Le rôle de l’humain reste essentiel.

Encore faut-il le placer au bon endroit.

Je préfère qu’une personne valide une décision réellement sensible plutôt qu’elle passe sa journée à lever des barrières que le système aurait dû savoir gérer seul.

Sur le circuit, le mur des stands ne demande pas au pilote la permission pour chaque changement de vitesse.

Il intervient sur les décisions qui comptent.

Avant de construire l’agent, dessinez sa piste

C’est probablement la partie la moins spectaculaire d’un projet.

Et pourtant, c’est celle que je trouve la plus intéressante.

Avant de connecter l’agent à vos outils, prenez une feuille.

Écrivez ce qu’il doit pouvoir lire.

Puis ce qu’il doit pouvoir créer ou modifier.

Notez ce qui nécessite réellement une validation humaine.

Décidez aussi ce qu’il ne doit jamais pouvoir faire seul.

Enfin, prévoyez comment vous retrouverez l’historique d’une action s’il y a un problème.

Vous venez déjà de faire une grosse partie du travail de conception.

Pas une ligne de code.

Pas un prompt miracle.

Juste les limites de la piste.

Plus autonome ne veut pas forcément dire meilleur

On va probablement voir de plus en plus d’outils capables de travailler longtemps sans intervention humaine.

C’est intéressant.

Mais je ne pense pas que le meilleur projet soit celui où l’on réussit à enlever l’humain du processus le plus vite possible.

Le bon niveau d’autonomie dépend du travail.

Un agent qui classe des documents peut fonctionner avec beaucoup de liberté.

Un agent qui prépare une commande fournisseur demande déjà davantage de contrôle.

S’il peut engager une dépense, modifier un contrat ou supprimer des données, je regarde encore les choses autrement.

L’autonomie n’est donc pas un objectif en soi.

C’est un réglage.

Exactement comme on ne règle pas une voiture uniquement pour obtenir la vitesse maximale en ligne droite.

Il faut encore pouvoir prendre le virage suivant.

Chez IALEMANS, c’est aussi comme ça que je veux aborder les agents et les outils IA : partir du travail qu’ils doivent réellement accomplir, leur donner les accès nécessaires, garder une trace de ce qu’ils font et mettre l’humain là où son jugement apporte quelque chose.

Ensuite, on peut accélérer.

Pas avant.

Sources vérifiées

• NIST, 27 août 2026

• OWASP Agent Control Standard, 1er septembre 2026

• CNIL, IA : définir une finalité et limiter les usages