Les agents IA ont besoin d'une quarantaine

Les agents IA arrivent avec une promesse simple : ne plus seulement repondre, mais faire. Chercher dans un dossier, appeler une API, ouvrir un ticket, preparer une relance, classer une demande, remplir un formulaire, comparer des pieces, proposer une action suivante. C’est precisement ce glissement qui change la nature du risque.

Un chatbot se trompe dans une fenetre. Un agent peut se tromper dans un systeme.

La difference parait fine dans les demonstrations commerciales. Elle est enorme en architecture. Des que l’IA recoit des outils, de la memoire, des droits et un objectif, elle cesse d’etre un simple generateur de texte. Elle devient un acteur logiciel imparfait, souvent mal delimite, capable de transformer une erreur de comprehension en action durable.

Le mot agent cache une pile

Le guide publie par CISA, NSA, ACSC, le Centre canadien pour la cybersecurite, NCSC-NZ et NCSC-UK insiste sur un point que les entreprises devraient lire lentement : un systeme agentique ne se resume pas au modele. Il contient le modele, mais aussi des outils externes, des sources de donnees, une memoire, un planificateur et parfois d’autres sous-agents.

Autrement dit, le sujet n’est pas seulement “quel modele choisit-on ?” Le sujet devient : quel environnement lui donne-t-on ?

Cette pile explique pourquoi les vieux reflexes de securite ne suffisent pas toujours. On sait deja limiter un utilisateur, une application ou une cle API. On sait moins bien limiter un systeme qui interprete une intention, decompose une tache, appelle plusieurs composants et peut changer de chemin en cours d’execution.

Un agent n’a pas besoin d’etre malveillant pour devenir dangereux. Il suffit qu’il comprenne mal l’objectif, qu’il fasse confiance a une source empoisonnee, qu’il reutilise une instruction cachee dans un document, qu’il agisse avec trop de droits ou qu’il ne sache pas quand s’arreter.

La quarantaine devrait etre le premier environnement

Le mot quarantaine est volontairement bas. Il evite le lyrisme de l’innovation. Un agent qui n’a jamais ete observe ne devrait pas entrer directement dans un SI reel. Il devrait passer par un perimetre ferme, avec donnees de test ou donnees masquees, permissions minimales, outils factices quand c’est possible, plafonds d’actions, traces completes et validation humaine.

C’est moins spectaculaire qu’un pilote branche au CRM, a la messagerie et a l’ERP en une apres-midi. C’est aussi beaucoup plus sain.

La quarantaine sert a regarder trois choses. D’abord, ce que l’agent fait quand tout se passe bien. Ensuite, ce qu’il fait quand une instruction est incomplete, contradictoire ou malveillante. Enfin, ce qu’il fait quand l’outil appele repond mal, lentement, trop largement ou pas du tout.

La plupart des risques apparaissent dans ces bords. Pas dans la demo lineaire. Dans la demo, l’utilisateur donne une demande propre et l’agent accomplit une sequence propre. Dans la production, une piece jointe contient du bruit, un champ manque, un nom ressemble a un autre, un email precedent donne une instruction hostile, un connecteur tombe, un client repond dans une langue inattendue.

Un agent utile doit savoir echouer proprement. La quarantaine est le lieu ou l’on regarde s’il en est capable.

Les droits larges sont la paresse du prototype

Le guide des agences cyber recommande de ne pas accorder aux agents des acces larges ou non restreints, surtout vers les donnees sensibles et les systemes critiques. Cela devrait etre une evidence. Dans les prototypes, c’est souvent la premiere chose que l’on oublie.

On donne un compte de service puissant parce que c’est plus rapide. On ouvre toute une boite mail parce que filtrer prend du temps. On branche tout le dossier client parce que le cas d’usage n’est pas encore clair. On autorise l’ecriture parce que la lecture seule ne fait pas assez “agent”. Puis on appelle cela un pilote.

Ce n’est pas un pilote. C’est une absence de modele de permissions.

Un agent devrait recevoir moins de droits qu’un humain, pas plus. Un humain voit le contexte social, comprend parfois l’absurde, hesite, appelle un collegue, se souvient d’un client sensible. L’agent, lui, optimise une tache dans les limites qu’on lui a donnees. Si ces limites sont trop larges, la responsabilite revient a l’architecture, pas a l’agent.

Le minimum raisonnable tient en quelques regles. Lecture avant ecriture. Donnees non sensibles avant donnees sensibles. Un outil avant cinq. Une famille d’actions avant tout le processus. Validation humaine avant action externe. Journalisation avant autonomie.

Le journal vaut plus que la reponse

La sortie visible d’un agent est souvent un email, une note, un ticket ou une synthese. Pour l’entreprise, le vrai livrable devrait etre le journal.

Qu’a lu l’agent ? Quel outil a-t-il appele ? Quelle instruction a-t-il suivie ? Quelle donnee a ete ignoree ? A quel moment a-t-il demande confirmation ? Pourquoi a-t-il choisi cette action et pas une autre ? Quelle version du modele etait utilisee ? Quel utilisateur a declenche la sequence ?

Sans ce journal, l’agent devient une boite noire qui fabrique des consequences. Avec ce journal, il reste imparfait, mais discutable.

Le rapport du NIST sur les reponses a sa demande d’information montre que les acteurs consultes voient les agents IA comme un nouveau probleme de securite, meme si beaucoup de principes cyber restent pertinents. C’est exactement le point : les fondamentaux ne disparaissent pas, mais ils doivent etre adaptes a une forme logicielle qui raisonne, planifie et agit.

L’audit d’un agent ne devrait donc pas commencer apres l’incident. Il devrait etre dans le design. Si l’on ne peut pas expliquer une action, la rejouer ou l’arreter, l’agent est trop autonome pour son niveau de maturite.

Le prompt injection devient un probleme d’action

Dans un chatbot, une injection de prompt peut produire une mauvaise reponse. Dans un agent, elle peut devenir une mauvaise action. C’est le changement le plus sous-estime.

Un document lu par l’agent peut contenir une instruction cachee. Une page web peut lui demander d’ignorer ses regles. Un email peut tenter de le pousser a transmettre une piece jointe, modifier une priorite ou appeler un outil. L’agent ne lit pas seulement de l’information. Il lit parfois des ordres deguises en information.

OWASP documente depuis plusieurs mois ce deplacement vers les risques propres aux applications agentiques : detournement d’objectif, abus d’outils, privileges mal limites, divulgation de donnees, confiance excessive dans l’autonomie. Le vocabulaire est encore en train de se stabiliser, mais la direction est claire. Plus le systeme agit, plus l’attaque vise l’action.

La reponse ne peut pas etre seulement “ameliorer le prompt systeme”. Il faut separer les canaux. Une instruction utilisateur n’a pas le meme statut qu’un document lu. Une page externe n’a pas le meme statut qu’une regle interne. Une donnee recuperee n’a pas le meme statut qu’une commande autorisee.

Le bon design traite les entrees comme des objets suspects, pas comme une conversation continue et innocente.

Les agents ne remplacent pas le nettoyage

Le guide international recommande aussi de regarder tout le spectre des solutions pour les taches repetitives, y compris la reduction ou la suppression de processus de faible valeur. C’est peut-etre la phrase la plus importante pour une PME.

Un agent IA est souvent vendu comme reponse a un flux complique. Mais certains flux ne meritent pas d’etre automatises. Ils meritent d’etre supprimes, simplifies ou deplaces. Si trois validations existent parce que personne ne fait confiance a la donnee source, un agent qui accelere la validation ne regle pas le probleme. Si un formulaire est incomprehensible, l’agent qui le remplit plus vite conserve l’incomprehension. Si une boite mail sert de systeme de tickets par defaut, l’agent ajoute une couche intelligente sur une mauvaise architecture.

La paresse utile consiste parfois a ne pas deployer l’agent. Un formulaire plus court, une regle metier plus nette, une integration classique ou une suppression d’etape peuvent battre une orchestration IA.

Ce n’est pas anti-innovation. C’est de l’hygiene.

La bonne premiere tache est petite

Une entreprise qui veut tester un agent devrait commencer par une tache assez utile pour apprendre, mais pas assez sensible pour casser quelque chose d’important.

Par exemple : classer des demandes entrantes dans un bac de test, preparer un brouillon de reponse sans l’envoyer, rapprocher deux listes non sensibles, proposer une priorite avec justification, verifier qu’une procedure contient les pieces attendues, produire un rapport d’anomalies sans ecriture dans l’outil metier.

Ces cas paraissent modestes. Ils permettent pourtant de mesurer les questions essentielles : taux d’erreur, faux positifs, temps gagne, erreurs dangereuses, qualite du journal, clarte de la reprise humaine, cout d’exploitation.

Si l’agent echoue sur un petit perimetre, l’entreprise a appris sans dommage. S’il reussit, elle peut ajouter une permission, puis une autre. L’autonomie devient une progression, pas un saut.

Ce que l’on devrait refuser

Il faut refuser l’agent qui demande tous les acces avant d’avoir prouve une seule tache. Refuser le pilote sans journal. Refuser l’ecriture directe dans un systeme critique. Refuser le connecteur qui ne sait pas limiter finement les droits. Refuser la memoire persistante sans politique de retention. Refuser la demonstration qui ne montre jamais l’echec.

Il faut aussi refuser le vocabulaire trop large. “Agent commercial”, “agent RH”, “agent finance” ne disent rien. Une architecture saine nomme l’action : lire tel dossier, proposer telle classification, remplir tel brouillon, ouvrir tel ticket, alerter telle personne, jamais faire “la finance”.

L’International AI Safety Report 2026 rappelle que les systemes d’IA generale progressent vite et que les techniques de mitigation existent, mais restent elles-memes un domaine actif. C’est un contrepoint utile : il ne faut pas transformer chaque agent de bureau en risque existentiel. Il faut simplement admettre que la securite n’est pas une case apres coup.

La maturite est plus ordinaire. Un agent a un perimetre. Il a des droits. Il a des journaux. Il a des tests. Il a un bouton d’arret. Il a des echecs connus. Il a une personne responsable.

La porte avant l’autonomie

Les agents IA ne demandent pas aux entreprises de choisir entre peur et enthousiasme. Ils leur demandent de redevenir precises.

Que peut faire ce systeme ? Avec quelles donnees ? Pour quel utilisateur ? Sous quel plafond ? Avec quelle trace ? Qui valide ? Qui arrete ? Qui relit les erreurs ? Quelle action restera toujours humaine ?

Ces questions ne ralentissent pas un bon projet. Elles l’empechent de se raconter des histoires.

Un agent que l’on ne sait pas isoler ne devrait pas etre branche. Un agent que l’on ne sait pas journaliser ne devrait pas agir. Un agent que l’on ne sait pas limiter ne devrait pas recevoir de droits. Ce n’est pas une doctrine lourde. C’est le seuil minimal avant de laisser un logiciel imparfait toucher au monde.

La quarantaine n’est pas une punition. C’est la porte d’entree de l’autonomie.