Agents IA : le vrai sujet, ce sont les droits d'acces

Le mot “agent” a pris la place que le mot “chatbot” occupait hier : il rassure les vendeurs, inquiete les directions, et permet de rebaptiser beaucoup de scripts. Cette fois, pourtant, le bruit cache un vrai changement. Un chatbot repond. Un agent peut lire, choisir un outil, appeler une API, ecrire dans un CRM, envoyer un message, modifier une configuration ou ouvrir un ticket. La difference n’est pas philosophique. Elle tient dans un verbe : agir.

C’est pour cela que la discussion publique rate souvent le point dur. On demande si l’agent est intelligent, s’il raisonne, s’il planifie, s’il comprend le contexte. Ce sont des questions utiles, mais secondaires pour une PME. La premiere question devrait etre plus plate : avec quel compte se connecte-t-il ?

Un agent IA devient serieux le jour ou il recoit des droits. Avant cela, il est un collegue bavard qui peut se tromper. Apres cela, il devient une identite operationnelle qui transporte du risque.

Le risque n’est pas l’autonomie, c’est l’autorisation

L’autonomie impressionne parce qu’elle se voit. Un agent qui decompose une mission en etapes donne l’impression de travailler seul. Mais dans une entreprise, le risque ne vient pas seulement de la sequence d’etapes. Il vient de la surface que chaque etape peut toucher.

Un agent qui resume des PDF internes avec un acces en lecture a un risque borne : fuite de donnees, mauvaise synthese, confusion de contexte. C’est deja assez pour exiger des controles. Mais ce n’est pas le meme monde qu’un agent qui peut envoyer un email au nom du service commercial, creer une remise, changer une fiche fournisseur ou lancer une commande.

Le premier probleme releve de la qualite et de la confidentialite. Le second releve de l’autorite.

Gartner a propose en mai 2026 une lecture utile, parce qu’elle separe les agents par niveaux d’autonomie : observer, conseiller, agir avec approbation, agir de maniere autonome. Ce decoupage n’est pas parfait, mais il oblige a regarder le bon objet. Un agent “observe” peut rester legerement gouverne. Un agent qui “agit avec approbation” a deja besoin de traces, de tests de securite et de procedures d’incident. Un agent autonome doit avoir des garde-fous, une surveillance continue, un mecanisme d’arret et une responsabilite nommee.

La plupart des projets d’entreprise font l’inverse. Ils choisissent un outil, activent des connecteurs, puis cherchent apres coup une politique de gouvernance. C’est confortable au debut, parce que le prototype marche vite. C’est mauvais signe precisement pour cette raison.

Un agent est un compte non humain

Les entreprises connaissent deja ce probleme. Elles l’ont seulement oublie sous un vocabulaire plus moderne. Un agent IA qui agit dans un systeme n’est pas seulement une fonctionnalite : c’est un compte non humain, comme un service account, une integration SaaS ou un robot RPA.

La difference est que ce compte non humain prend des decisions probabilistes sur la base d’instructions en langage naturel, de documents parfois sales et d’un contexte qui peut etre manipule. Il faut donc lui appliquer au moins les memes questions qu’a une integration classique, puis quelques questions en plus.

Qui possede ce compte ? Quels droits exacts a-t-il ? Dans quels systemes ? Peut-il lire seulement, ou ecrire ? Peut-il agir au nom d’un humain ? Peut-il transmettre des donnees a un modele externe ? Ses actions sont-elles journalisees avec assez de detail pour comprendre ce qui s’est passe ? Peut-on le couper sans couper tout le service ?

Ces questions semblent administratives. Elles sont en realite l’architecture du projet.

Le NIST a lance en fevrier 2026 une initiative consacree aux standards d’agents IA, en mettant explicitement sur la table l’interoperabilite, la securite, l’identite et l’autorisation. Ce n’est pas un detail americain lointain. C’est le signal que les agents sortent de la demonstration produit pour entrer dans la plomberie des organisations.

Quand un organisme de standards parle d’identite et d’autorisation, il ne parle pas de “prompt engineering”. Il parle de qui a le droit de faire quoi, pour qui, dans quel systeme, avec quelle preuve.

Le mauvais raccourci : un agent, un super-compte

Le raccourci le plus tentant est aussi le plus dangereux : donner a l’agent un compte large “pour ne pas le bloquer”. C’est ainsi qu’on obtient des demonstrations fluides. C’est aussi ainsi qu’on fabrique des incidents incomprehensibles.

Un compte large masque les erreurs. Si l’agent modifie une fiche client, et que le compte utilise est celui d’un administrateur generique, on sait qu’une action a eu lieu. On ne sait pas toujours pourquoi elle a eu lieu, quelle instruction l’a declenchee, quel document a ete lu avant, quelle validation humaine a ete demandee, ni quelle version du workflow etait en service.

Dans un outil classique, c’est deja une mauvaise pratique. Avec un agent, c’est pire, car le chemin entre l’intention et l’action est plus long. Il peut passer par un prompt, une recherche, une selection d’outil, une reformulation, une permission implicite, puis un appel API. Sans journal utile, la reconstitution devient une seance de spiritisme informatique.

OWASP a publie un Top 10 des applications agentiques pour 2026. Les grandes categories de risque tournent autour d’idees tres concretes : detournement de l’objectif, mauvaise utilisation d’outils, abus d’identite et de privileges, vulnerabilites de chaine agentique, contexte ou memoire empoisonnes. On peut en discuter les mots. Le diagnostic est simple : lorsqu’un systeme peut planifier et utiliser des outils, la securite ne peut plus s’arreter au modele.

Elle doit descendre dans les droits.

L’approbation humaine n’est pas une gomme magique

Beaucoup d’organisations pensent regler le sujet avec une formule : “l’humain reste dans la boucle”. C’est parfois vrai. Mais l’expression cache deux situations tres differentes.

Dans la premiere, l’humain voit clairement ce que l’agent veut faire, pourquoi il veut le faire, quelles donnees ont ete utilisees et comment revenir en arriere. L’approbation est alors un controle.

Dans la seconde, l’humain recoit une notification vague, dans un outil ou il a deja dix autres validations a traiter. Il clique parce que le systeme a l’air sur de lui, parce que l’action semble routiniere, ou parce que refuser demande plus de temps que valider. L’approbation devient alors une signature de convenance. Elle protege surtout le tableau de bord.

Gartner le dit autrement : a partir du niveau “agir avec approbation”, la revue humaine n’est efficace que si elle reste un controle significatif. C’est la phrase la plus importante du sujet. Un bouton “valider” ne suffit pas. Il faut que la personne comprenne l’action, dispose des bons elements et puisse dire non sans bloquer tout le flux metier.

Le probleme n’est donc pas de mettre un humain partout. Le probleme est de savoir quelles actions meritent une validation, sous quelle forme, et avec quelle preuve.

Le monitoring arrive trop tard

Le rapport NIST de mars 2026 sur le monitoring des systemes IA deployee liste six familles de surveillance : fonctionnalite, operation, facteurs humains, securite, conformite, impacts a grande echelle. Cette taxonomie peut sembler lourde pour une PME. Elle a pourtant une vertu : elle rappelle que surveiller un agent ne signifie pas seulement regarder s’il repond vite.

Un agent peut fonctionner techniquement et echouer organisationnellement. Il peut repondre vite et trop largement. Il peut respecter son prompt et violer une regle interne. Il peut obtenir de bons scores de qualite, mais multiplier des actions que personne ne relit vraiment.

La surveillance utile commence donc avant la mise en production. Elle commence par choisir ce qu’on veut pouvoir expliquer apres incident.

Pour un agent qui lit des documents : quels documents a-t-il lus ? Pour un agent qui ecrit dans un CRM : quelle fiche, quel champ, quelle ancienne valeur, quelle nouvelle valeur ? Pour un agent qui envoie un email : quel brouillon, quelle validation, quel destinataire, quelle piece jointe ? Pour un agent qui appelle plusieurs outils : quelle sequence, quelle erreur, quel repli ?

Ce n’est pas glamour. C’est exactement le point. Une bonne architecture d’agent ressemble moins a une demo futuriste qu’a un journal de bord ennuyeux, exploitable un vendredi soir.

L’AI Act ajoute une pression de preuve

L’Europe ne regle pas tout par le droit, mais elle ajoute une contrainte utile : certaines obligations de transparence de l’AI Act arrivent en aout 2026, notamment sur l’identification de contenus generes par IA et certains contenus publies pour informer le public sur des sujets d’interet general. Pour une PME, ce n’est pas seulement une question de pictogramme ou de mention.

C’est une pression de preuve. Si un agent prepare, transforme ou publie un contenu, l’entreprise devra savoir dire ou l’IA est intervenue, qui a valide, et pourquoi le contenu final est acceptable. Plus l’agent agit pres d’un flux public, plus la trace compte.

La meme logique s’applique aux flux internes. Une facture modifiee, un ticket clos, un client relance, une fiche RH enrichie : ce ne sont pas des contenus publics, mais ce sont des actes d’entreprise. Si l’agent participe a l’acte, il faut une trace proportionnee.

Le mot “proportionnee” est important. Il ne s’agit pas d’installer un centre de controle pour resumer trois documents. Il s’agit d’arreter de traiter tous les agents comme s’ils avaient le meme poids.

Le minimum viable n’est pas un comite

La mauvaise reaction serait de creer un comite IA avant de creer une liste de droits. La gouvernance peut devenir une decoration tres vite : chartes, principes, ateliers, fichiers PowerPoint. Tout cela peut aider plus tard. Le premier socle est plus simple.

Un inventaire des agents en production ou en test. Pour chacun : proprietaire metier, proprietaire technique, systemes connectes, droits de lecture, droits d’ecriture, donnees sensibles accessibles, modele utilise, logs disponibles, mecanisme d’arret.

Des comptes separes. Pas de compte humain partage, pas de super-compte par commodite, pas de connecteur active “pour voir”. Un agent qui agit doit avoir une identite technique identifiable.

Des droits minimaux. Lire ce qui est necessaire. Ecrire seulement ce qui est necessaire. Interdire par defaut les actions irreversibles, les envois externes, les exports massifs et les changements de configuration.

Des validations qui veulent dire quelque chose. L’humain ne doit pas seulement voir “l’agent propose une action”. Il doit voir l’action exacte, la raison, les donnees utilisees et l’effet attendu.

Des journaux qu’on peut relire. Pas les pensees internes du modele, pas une illusion de transparence totale. Mais les entrees, les outils appeles, les sorties, les decisions humaines, les erreurs et les actions finales.

Un arret simple. Si un agent derape, on ne doit pas ouvrir trois tickets pour trouver qui peut couper son acces.

Ce minimum n’est pas spectaculaire. Il est plus utile qu’une strategie IA de cinquante pages.

La vraie maturite : refuser certains agents

Il y a une derniere consequence, moins vendable. Si l’on prend les droits au serieux, certains agents ne doivent pas exister tout de suite.

Pas parce que l’IA est trop faible. Parce que l’entreprise n’a pas encore les comptes separes, les logs, les validations ou le retour arriere. Beaucoup de projets “agentiques” echouent avant la technique : ils demandent a une organisation mal instrumentee de deleguer proprement.

Une PME qui ne sait pas deja qui peut modifier quoi dans son CRM ne devrait pas brancher un agent autonome sur ce CRM. Une direction qui ne distingue pas les droits de lecture et d’ecriture ne devrait pas parler d’orchestration multi-agent. Une equipe qui ne relit jamais ses journaux ne devrait pas vendre le monitoring comme garde-fou.

Ce n’est pas une position anti-agent. C’est l’inverse. Les agents utiles arriveront par les chemins les plus sobres : lecture bornee, conseil explicable, action approuvee, puis autonomie locale quand le reste tient. L’ordre compte.

Le sujet n’est donc pas de savoir si les agents IA vont transformer l’entreprise. Certains le feront. Le sujet est de savoir si l’entreprise sait leur donner une cle sans leur confier le trousseau.