La taxonomie des risques des agents IA : 12 risques que chaque entreprise doit suivre

19 avril 2026 · 11 min de lecture

Les agents IA ont besoin d'une taxonomie des risques pour une raison simple :
ils ne produisent pas seulement du texte. Ils peuvent utiliser des outils,
acceder a des donnees, memoriser du contexte, appeler des API, deleguer du
travail et declencher des processus metier.

La question de gouvernance passe donc de :

La sortie du modele est-elle acceptable ?

A :

Qu'est-ce que l'agent etait autorise a faire, qu'a-t-il reellement fait,
quel controle a echoue, qui a approuve le risque, et pouvons-nous le prouver ?

Cet article commence par une taxonomie pratique en 12 risques. Il l'elargit
ensuite en une vue d'entreprise plus complete, organisee autour du controle
d'acces, du mauvais usage des outils, de la gouvernance, de la confidentialite,
de la qualite des sorties, du comportement des agents, et de la fiabilite.

Le point essentiel est la discipline des sources. Certains risques proviennent
directement de cadres, lois, reglements ou standards reconnus. D'autres sont des
indicateurs issus de la recherche en securite, de la litterature sur la securite
de l'IA ou de schemas d'incidents. Ils sont utiles, mais ne doivent pas etre
presentes comme des obligations juridiques lorsqu'aucune loi, reglementation ou
norme ne le dit explicitement.

Version courte

Toute entreprise qui deploie des agents IA devrait suivre ces 12 risques :

Cette liste est volontairement pratique. C'est la checklist qu'un responsable
metier, un responsable securite, une equipe conformite ou un architecte IA peut
utiliser avant la production.

Mais la taxonomie complete de l'entreprise est plus large.

La taxonomie d'entreprise elargie

Une taxonomie plus complete regroupe les risques de l'IA agentique en sept
domaines.

Cette structure correspond mieux a la maniere dont les entreprises gouvernent
reellement les systemes. Les equipes securite reconnaissent le controle d'acces
et le mauvais usage des outils. Les equipes privacy reconnaissent l'exposition
et la retention des donnees. Les equipes conformite reconnaissent la
responsabilite et les preuves. Les equipes engineering reconnaissent la
fiabilite et l'observabilite.

La taxonomie n'est pas utile parce qu'elle cree des cases parfaites. Elle est
utile parce qu'elle permet de poser la meme question operationnelle :

Quel controle metier echoue si cet agent se comporte mal ?

Sources de reference

La taxonomie ci-dessous s'appuie sur ces sources :

• OWASP Agentic AI - Threats and Mitigations, Version 1.1, decembre 2025. C'est la source directe la plus forte pour les menaces propres aux agents : memory poisoning, tool misuse, goal manipulation, untraceability, identity compromise, risques multi-agents et human manipulation. Le guide actuel liste T1-T17 ; certains resumes plus anciens parlent encore de T1-T15.
• OWASP Top 10 for Large Language Model Applications 2025, notamment Prompt Injection, Sensitive Information Disclosure, Supply Chain Vulnerabilities, Excessive Agency, Overreliance et Unbounded Consumption.
• NIST AI Risk Management Framework 1.0, qui structure la gouvernance des risques IA autour de Govern, Map, Measure et Manage.
• NIST AI RMF Generative AI Profile, NIST AI 600-1, qui nomme des risques comme confabulation, harmful bias, data privacy, information integrity, human-AI configuration et integration de composants dans la chaine de valeur.
• MITRE ATLAS, base de connaissances sur les tactiques et techniques adverses contre les systemes actives par l'IA.
• EU AI Act, Regulation (EU) 2024/1689, notamment les exigences relatives aux systemes a haut risque : gestion des risques, gouvernance des donnees, documentation technique, journalisation, transparence, supervision humaine, exactitude, robustesse, cybersecurite, suivi post-marche et obligations des deployeurs.
• GDPR, Regulation (EU) 2016/679, notamment les articles 5, 32, 33 et 35 lorsque des agents traitent des donnees personnelles.
• ISO/IEC 42001:2023, standard de systeme de management de l'IA, utile pour la gouvernance, les responsabilites, les politiques, la gestion des risques et l'amelioration continue.
• NIST Cybersecurity Framework 2.0, notamment les resultats Govern et Protect pour l'identite, l'acces, la supply chain, le monitoring et la gestion des risques.

Lorsque cet article mentionne des sujets frontier comme l'autoreplication, la
resistance a l'arret ou l'acquisition autonome de ressources, il faut les
traiter comme des indicateurs systemiques issus de la recherche en securite de
l'IA et d'evaluations de systemes avances, sauf si votre systeme concret possede
effectivement ces capacites.

1. Risque d'autonomie

Le risque d'autonomie est le risque qu'un agent agisse sans supervision humaine
suffisante pour le niveau d'impact.

C'est la difference centrale entre un assistant IA et un agent IA. Un chatbot
peut donner une mauvaise reponse. Un agent de workflow autonome peut donner une
mauvaise reponse et agir dessus.

A suivre :

• L'agent peut-il agir a partir d'un declencheur ou d'un evenement de fond ?
• Peut-il realiser des taches multi-etapes sans approbation etape par etape ?
• Peut-il affecter des clients, employes, donnees financieres, contrats,
  infrastructure, securite ou processus reglementes ?
• Un humain peut-il interrompre, mettre en pause, annuler ou inverser l'action ?

Sources :

• L'EU AI Act exige une supervision humaine pour les systemes IA a haut risque a
  l'article 14.
• Le NIST AI RMF demande aux organisations de gouverner, cartographier, mesurer
  et gerer les risques IA dans leur contexte.
• OWASP Agentic AI traite l'autonomie, la planification, les comportements
  desalignes et la surcharge du human-in-the-loop comme des schemas de menace.

2. Risque lie aux outils

Le risque lie aux outils est le risque qu'un agent utilise mal des outils
internes ou externes.

Les outils incluent API, bases de donnees, navigateurs, email, execution de code,
actions CRM, automatisations de workflow, systemes de tickets, fichiers,
paiements et outils de securite.

A suivre :

• Quels outils l'agent peut-il appeler ?
• Les appels sont-ils en lecture seule ou peuvent-ils ecrire ?
• Le modele peut-il choisir les parametres d'outil ?
• La sortie d'un outil peut-elle devenir un nouveau contexte d'instruction ?
• Les outils a fort impact sont-ils soumis a une politique et a une approbation humaine ?

Sources :

• OWASP Agentic AI inclut directement le mauvais usage des outils, les attaques
  par execution de code et les abus de protocoles inter-agents.
• OWASP LLM Top 10 inclut Excessive Agency et Insecure Output Handling.
• NIST CSF 2.0 fournit le vocabulaire de controle pour acces, protection,
  detection, reponse et reprise.

3. Risque de permissions

Le risque de permissions est le risque que l'agent puisse acceder a plus de
choses, ou faire plus d'actions, qu'il ne le devrait.

Les agents utilisent souvent des permissions heritees, des scopes OAuth
delegues, des comptes de service, des identites de connecteurs ou des
permissions de plateforme. Cela cree un risque classique de controle d'acces
dans une forme nouvelle.

A suivre :

• L'agent utilise-t-il une identite nommee ?
• A-t-il un acces de moindre privilege ?
• Utilise-t-il des identifiants partages ou des comptes de service larges ?
• Peut-il effectuer des actions que l'utilisateur demandeur ne pourrait pas faire directement ?
• Peut-il franchir des frontieres de tenants, departements, environnements ou confiance ?

Les menaces specifiques incluent privilege escalation, credential theft et
confused deputy.

Sources :

• OWASP Agentic AI couvre identity compromise, spoofing, confused deputy et
  risques d'autorisation.
• NIST CSF PR.AA couvre la gestion d'identite, l'authentification et le controle d'acces.
• L'article 32 du GDPR est pertinent lorsque des permissions excessives exposent des donnees personnelles.

4. Risque de prompt injection

Le risque de prompt injection est le risque que l'agent suive des instructions
malveillantes, cachees, contradictoires ou non fiables.

Pour les agents, la prompt injection est plus dangereuse qu'une mauvaise reponse
parce que l'agent peut transformer l'instruction malveillante en action.

A suivre :

• L'agent lit-il des emails, pages web, tickets, PDF, documents ou messages de
  chat non fiables ?
• Les documents recuperes sont-ils melanges au meme contexte que les instructions systeme ?
• Un utilisateur, client, fournisseur ou attaquant peut-il influencer les arguments d'outil ?
• Les appels d'outils sont-ils contraints par une politique hors du modele ?

Sources :

• OWASP LLM Top 10 liste Prompt Injection comme risque central des applications LLM.
• OWASP Agentic AI l'etend vers tool misuse, goal manipulation et agent-communication poisoning.
• Beaucoup d'avertissements sur la prompt injection viennent de la recherche en
  securite et de retours terrain. Traitez-les comme preuve de risque, pas comme
  obligation legale en soi.

5. Risque de memoire

Le risque de memoire est le risque qu'un agent stocke, divulgue, empoisonne ou
reutilise le contexte de maniere inappropriee.

La memoire rend les agents plus utiles. Elle cree aussi une couche persistante
que les attaquants et les accidents peuvent exploiter.

A suivre :

• Que l'agent memorise-t-il ?
• Qui peut ecrire en memoire ?
• Qui peut lire la memoire ?
• La memoire peut-elle influencer l'usage futur des outils ?
• La memoire est-elle supprimee lorsque la finalite initiale expire ?
• Les informations sensibles sont-elles filtrees avant stockage ?

Les menaces specifiques incluent memory poisoning et fuite a long terme de
contexte personnel, confidentiel ou privilegie.

Sources :

• OWASP Agentic AI inclut Memory Poisoning comme menace nommee.
• NIST AI 600-1 couvre les risques de data privacy et information integrity.
• Les articles 5 et 32 du GDPR s'appliquent lorsque des donnees personnelles
  sont stockees, conservees ou reutilisees.

6. Risque d'exposition des donnees

Le risque d'exposition des donnees est le risque que l'agent recupere, revele,
resume, transforme ou transmette des donnees sensibles de maniere non sure.

L'agent ne fuit pas forcement une table de base de donnees directement. Il peut
resumer les parties sensibles dans un message de chat, un brouillon d'email, un
ticket support, un fichier exporte ou un payload API.

A suivre :

• A quelles sources de donnees l'agent peut-il acceder ?
• Quelles donnees peut-il combiner ?
• Peut-il deplacer des donnees vers des canaux moins proteges ?
• Peut-il envoyer des donnees a des outils tiers ou utilisateurs externes ?
• Donnees personnelles, identifiants, contrats, code source, donnees RH,
  donnees financieres ou logs de securite sont-ils concernes ?

Sources :

• OWASP LLM Top 10 inclut Sensitive Information Disclosure.
• OWASP Agentic AI inclut des scenarios d'exfiltration via outils, agents
  rogue et systemes multi-agents.
• Les articles 5, 32 et 33 du GDPR s'appliquent lorsque des donnees personnelles
  sont traitees ou violees.
• L'article 10 de l'EU AI Act s'applique a la gouvernance des donnees pour les
  systemes IA a haut risque.

7. Risque de planification

Le risque de planification est le risque qu'un agent cree un plan multi-etapes
defaillant, localement raisonnable mais globalement mauvais.

Ce n'est pas seulement une hallucination. Un plan peut etre compose d'etapes
individuellement plausibles tout en violant une politique, oubliant une
dependance, creant des couts, surchargeant une equipe ou declenchant le mauvais
processus.

A suivre :

• L'agent peut-il decomposer des objectifs en sous-objectifs ?
• Peut-il reviser ses plans selon des resultats intermediaires ?
• Optimise-t-il l'execution de la tache au-dessus des politiques, de la securite,
  du budget ou des contraintes metier ?
• Les plans sont-ils revus avant execution a fort impact ?

Sources :

• OWASP Agentic AI inclut intent breaking, goal manipulation et comportements
  desalignes ou trompeurs.
• NIST AI 600-1 couvre confabulation, information integrity et human-AI configuration.
• Les articles 9, 13 et 14 de l'EU AI Act comptent pour les systemes a haut
  risque car la gestion des risques, la transparence et la supervision humaine
  doivent etre concues dans le systeme.

8. Risque de delegation

Le risque de delegation est le risque que l'agent transmette du travail a
d'autres agents, taches, outils ou workflows sans controle clair.

Les systemes multi-agents rendent la responsabilite plus difficile. Un agent
coordinateur peut creer une tache, un agent specialiste appeler un outil, un
autre resumer le resultat et un quatrieme communiquer avec l'utilisateur.

A suivre :

• Quels agents peuvent communiquer ?
• Les identites d'agents sont-elles authentifiees ?
• Les messages sont-ils signes, scopes, journalises et filtres ?
• Un agent peut-il pousser un autre agent au-dela de son autorite ?
• Qui possede le workflow de bout en bout ?

Sources :

• OWASP Agentic AI inclut agent communication poisoning, rogue agents in
  multi-agent systems, human attacks on multi-agent systems et insecure
  inter-agent protocol abuse.
• L'article 25 de l'EU AI Act est pertinent pour les responsabilites dans la chaine de valeur IA.
• ISO/IEC 42001 est pertinent pour les responsabilites de management system et les controles de cycle de vie.

9. Risque d'observabilite

Le risque d'observabilite est le risque que l'organisation ne puisse pas
reconstruire ce qui s'est passe.

Pour les agents, les logs de sortie finale ne suffisent pas. Il faut la trace
operationnelle : declencheur, utilisateur, version d'instruction, retrievals,
appels d'outils, arguments, decisions de politique, approbations, sorties,
actions, erreurs, retries et handoffs.

A suivre :

• Les repondants incident peuvent-ils reconstruire toute l'execution ?
• Les appels d'outils et arguments sont-ils journalises ?
• Les approbations sont-elles enregistrees ?
• Les refus de politique sont-ils enregistres ?
• Le comportement anormal peut-il etre detecte ?
• Existe-t-il un kill switch ou une procedure de pause ?

Sources :

• OWASP Agentic AI inclut Repudiation and Untraceability.
• L'EU AI Act inclut journalisation, documentation technique, monitoring, suivi
  post-marche et actions correctives pour les systemes a haut risque.
• NIST AI RMF et NIST CSF soutiennent mesure, monitoring, reponse et reprise
  comme fonctions de gestion des risques.

10. Risque de responsabilite

Le risque de responsabilite est le risque que personne ne possede clairement les
decisions, approbations, operations, incidents ou remediations.

Ce risque est facile a manquer car un agent se situe entre plusieurs equipes.
Le produit possede le cas d'usage. L'IT possede le connecteur. La securite
possede le controle d'acces. Le juridique possede la politique. Un fournisseur
possede la plateforme. Le metier possede le resultat.

A suivre :

• Qui est le business owner ?
• Qui est le technical owner ?
• Qui approuve la mise en production ?
• Qui approuve les categories d'action a fort impact ?
• Qui traite les incidents ?
• Qui accepte le risque residuel ?

Sources :

• Les articles 16-27 de l'EU AI Act definissent les responsabilites entre
  provider, importer, distributor, deployer et autres roles de la chaine de valeur.
• ISO/IEC 42001 exige responsabilite de management system et amelioration continue.
• La fonction Govern du NIST AI RMF met l'accent sur roles, politiques,
  processus et supervision.

11. Risque de conformite

Le risque de conformite est le risque que l'agent viole des exigences legales,
reglementaires, contractuelles, sectorielles ou internes.

Ce n'est pas seulement une question d'AI Act. Selon le cas d'usage, le risque
agent peut toucher privacy, droit du travail, services financiers, sante,
protection des consommateurs, cybersecurite, contrats, retention des documents,
reglementation sectorielle et politiques internes.

A suivre :

• Le cas d'usage est-il a haut risque ou reglemente ?
• L'agent traite-t-il des donnees personnelles ?
• Affecte-t-il des droits, acces, emploi, credit, education, sante, securite ou
  resultats juridiques ?
• Existe-t-il une documentation pour gestion des risques, tests, monitoring,
  supervision humaine et reponse aux incidents ?
• Les obligations de transparence sont-elles respectees ?

Sources :

• Les articles 9-15, 17-20, 26-27 et 50 de l'EU AI Act sont particulierement
  pertinents pour les systemes a haut risque et la transparence.
• Les articles 5, 32, 33 et 35 du GDPR comptent lorsque des donnees personnelles sont impliquees.
• ISO/IEC 42001 et NIST AI RMF fournissent des structures de gouvernance et de preuve.

12. Risque de processus metier

Le risque de processus metier est le risque que l'agent cause un dommage
operationnel direct.

C'est ici que la gouvernance des agents devient concrete. Une mauvaise reponse
est un probleme. Une mauvaise reponse qui ferme un dossier client, approuve un
remboursement, modifie un dossier employe, change une infrastructure, envoie un
email a un regulateur ou met a jour un workflow juridique en est un autre.

A suivre :

• Quel processus l'agent peut-il affecter ?
• L'action peut-elle etre annulee ?
• L'agent peut-il agir a grande echelle ?
• Peut-il agir hors heures ouvrables ?
• Peut-il influencer des humains qui prennent des decisions consequentes ?
• Le processus a-t-il des controles existants que l'agent contourne ?

Sources :

• OWASP Agentic AI inclut human manipulation, overwhelming the human in the loop,
  misaligned behavior et tool misuse.
• NIST AI 600-1 couvre human-AI configuration, confabulation, harmful bias et information integrity.
• Les articles 14 et 26 de l'EU AI Act comptent lorsque l'agent fait partie d'un
  deploiement a haut risque et que supervision humaine ou obligations de deployeur s'appliquent.

Menaces specifiques a inclure dans le registre

Les 12 risques sont le langage simple de l'entreprise. Un registre des risques
doit aussi suivre la classe de menace plus specifique.

Ce que les entreprises doivent suivre

Le geste pratique consiste a suivre les deux elements :

1. La classe de menace.
2. Le controle metier qui echoue.

Par exemple :

• "Prompt injection" est une classe de menace.
• "L'agent de support client peut emettre des remboursements sans validation de
  politique" est un controle metier defaillant.

Cette deuxieme phrase rend la taxonomie operationnelle.

Au minimum, chaque entree du registre doit capturer :

• Nom et proprietaire de l'agent
• Processus metier
• Niveau d'agent et niveau d'autonomie
• Outils, sources de donnees, memoires et agents delegues
• Domaine de risque et classe de menace specifique
• Source de reference
• Scenario de menace
• Controle manquant ou defaillant
• Scores de probabilite, impact, autonomie, sensibilite des donnees, criticite
  des outils et manque d'observabilite
• Points d'approbation humaine requis
• Emplacement des preuves
• Proprietaire du risque residuel
• Declencheur de revue et prochaine date de revue

Surveiller les indicateurs systemiques

La plupart des agents d'entreprise actuels n'ont pas une autonomie frontier.
Certains indicateurs systemiques meritent pourtant d'etre suivis car ils montrent
quand un agent de workflow ordinaire derive vers une categorie plus dangereuse.

Surveillez :

• Poursuite d'objectif non intentionnelle
• Escalade de privilege non autorisee
• Acquisition autonome de ressources
• Tentatives de conserver l'acces ou de resister a l'arret
• Autoreplication ou creation non autorisee d'agents
• Boucles de desinformation multi-agents
• Tempetes de retries, appels d'outils repetes, pics de couts ou epuisement de quotas
• Nouvelles voies inattendues d'exfiltration de donnees

Ces indicateurs ne viennent pas tous d'un seul cadre juridique. Il vaut mieux les
comprendre comme des signaux de risque issus de la recherche en securite de l'IA,
des tests adversariaux et des evaluations d'agents avances. S'ils apparaissent
dans un vrai systeme d'entreprise, ils doivent declencher une revue immediate.

La regle pratique

Ne vous arretez pas a "cet agent a un risque d'autonomie" ou "cet agent a un
risque de prompt injection".

Ecrivez la version operationnelle :

Cet agent peut lire des emails fournisseurs, extraire des changements de
contrat et router des approbations. Un email fournisseur malveillant pourrait
injecter des instructions qui poussent l'agent a mal classer un changement de
contrat et a contourner la revue juridique.

Maintenant, vous pouvez le gouverner.

Vous pouvez assigner un proprietaire. Vous pouvez exiger un controle. Vous
pouvez tester la defaillance. Vous pouvez journaliser les preuves. Vous pouvez
decider si le risque residuel est acceptable.

C'est a cela que sert une taxonomie des risques des agents.

Ressource pratique

Le framework GitHub compagnon inclut :

• AI Agent Risk Taxonomy
• Risk Scoring Model
• Risk Register Template CSV

Utilisez la taxonomie pour nommer le risque. Utilisez le registre pour assigner
la responsabilite. Utilisez le modele de scoring pour decider quels controles
doivent exister avant la production.