Comment évaluer le risque d’un agent IA avant la production

10 mai 2026 · 10 min de lecture

L’évaluation du risque d’un agent IA doit avoir lieu avant son passage en production, pas après le premier incident, la première demande d’audit ou une escalade confuse.

Elle n’a pas besoin d’être lourde. Si le processus devient trop lourd, les équipes le contourneront. La version utile est une prise d’information structurée qui aide le produit, la conformité, la sécurité, l’architecture et les métiers à répondre à une question:

Que pourrait faire cet agent, qui serait affecté, et quels contrôles doivent être en place avant qu’il soit autorisé à fonctionner?

Cet article propose un modèle pratique d’évaluation pour les agents IA en entreprise. Il convient au moment où l’équipe a un cas d’usage réel, une architecture approximative et un chemin de mise en production, mais pas encore l’approbation finale.

Version courte

Avant la production, évaluez sept dimensions:

Le résultat doit être un niveau de risque court, une checklist de contrôles, des responsables nommés et des preuves réutilisables pour les revues sécurité, confidentialité, conformité et architecture.

Pourquoi l’évaluation du risque agent est différente

Les revues IA classiques se concentrent souvent sur le modèle, les données, l’usage prévu, la qualité des sorties, les biais, l’explicabilité et la confidentialité. Tout cela reste important.

Les agents ajoutent un risque opérationnel.

Un agent peut:

• Appeler des outils ou des API.
• Récupérer des documents ou des enregistrements de base de données.
• Utiliser des permissions déléguées.
• Stocker une mémoire.
• Exécuter des plans en plusieurs étapes.
• Fonctionner à partir de déclencheurs en arrière-plan.
• Envoyer des messages, modifier des dossiers, ouvrir des tickets, approuver des étapes de workflow ou déclencher des processus client, RH, finance, juridique, sécurité ou infrastructure.

L’évaluation ne peut donc pas s’arrêter à "la réponse est-elle exacte?" Elle doit aussi demander: "que peut faire le système avec cette réponse?"

Le modèle doit évaluer le comportement, pas l’étiquette. Un chatbot appelé agent peut être peu risqué. Un assistant de workflow avec accès aux outils peut être à risque élevé, même s’il utilise un modèle connu.

Étape 1: commencer par la prise d’information

La prise d’information définit les limites. Sans elle, le reste devient abstrait.

À capturer:

• Nom de l’agent et propriétaire métier.
• Objectif prévu.
• Utilisateurs principaux.
• Clients, employés, fournisseurs ou tiers affectés.
• Processus métier pris en charge.
• Canal de déploiement: site web, Teams, Slack, portail interne, API ou workflow en arrière-plan.
• Déclencheur de production: prompt utilisateur, création de ticket, arrivée d’e-mail, tâche planifiée, webhook ou événement de file.
• Portée du lancement: pilote, production interne, exposition client ou déploiement large.
• Responsable support et responsable incident.

Le point clé est la responsabilité. Si l’agent n’a pas de propriétaire métier, de chemin support et de responsable incident, il n’est pas prêt pour la production.

Étape 2: noter l’autonomie

L’autonomie mesure la capacité de l’agent à décider et agir sans qu’un humain pilote chaque étape.

Une échelle simple suffit souvent.

Questions:

• L’agent peut-il fonctionner sans message utilisateur?
• Peut-il effectuer plusieurs étapes avant de revenir à un humain?
• Peut-il choisir quel outil appeler?
• Peut-il décider qu’une tâche est terminée?
• Peut-il réessayer, escalader, déléguer ou changer de plan?
• Peut-il affecter un vrai dossier métier, une communication client, un paiement, une décision RH, un contrat, un contrôle de sécurité ou un paramètre d’infrastructure?

Une forte autonomie n’est pas automatiquement inacceptable. Elle exige toutefois des contrôles plus solides: limites claires, journalisation renforcée, approbation pour les actions sensibles, monitoring et capacité d’arrêt rapide.

Étape 3: noter l’accès aux outils

L’accès aux outils rend souvent le risque concret. Les outils incluent API, bases de données, navigateurs, e-mail, tickets, CRM, ERP, systèmes RH, automatisation de workflow, exécution de code, fichiers, paiements et outils de sécurité.

Pour chaque outil, capturez:

• Nom de l’outil.
• Objectif métier.
• Capacité de lecture ou d’écriture.
• Méthode d’authentification.
• Identité propre, compte de service ou permissions déléguées.
• Scopes et permissions.
• Limites de taux et d’usage.
• Si le modèle choisit les arguments d’outil.
• Si les sorties d’outil peuvent influencer des appels ultérieurs.
• Si une approbation est requise.

C’est ici qu’il faut appliquer le moindre privilège. Si l’agent a seulement besoin du statut de commande, ne lui donnez pas les remboursements. S’il doit seulement préparer un brouillon, ne le laissez pas envoyer le message.

Étape 4: noter la sensibilité des données

Les agents peuvent exposer des données directement, mais aussi indirectement en les résumant, transformant, combinant ou envoyant par un autre canal.

Demandez:

• Quelles sources de données l’agent peut-il consulter?
• Peut-il combiner plusieurs systèmes?
• Peut-il accéder à des données personnelles?
• Peut-il voir contrats confidentiels, dossiers employés, finances, code source, identifiants, journaux sécurité ou documents juridiques?
• Peut-il déplacer les données vers un canal moins protégé?
• Peut-il stocker les données en mémoire?
• Les règles de conservation et suppression sont-elles définies?
• La minimisation et la limitation de finalité sont-elles traitées?

Quand des données personnelles sont concernées, reliez l’évaluation à la revue confidentialité. En contexte européen, le RGPD est particulièrement pertinent pour la base légale, la minimisation, la sécurité, la gestion des violations et l’analyse d’impact si nécessaire.

Étape 5: définir la supervision humaine

La supervision humaine ne signifie pas qu’une personne est simplement proche du processus. Elle doit être assez précise pour changer le résultat.

Pour chaque action significative, définissez:

• Qui révise?
• Que voit cette personne?
• Quelle décision peut-elle prendre?
• Peut-elle rejeter, modifier, escalader ou mettre en pause?
• L’approbation est-elle journalisée?
• Les réviseurs comprennent-ils les limites de l’agent?
• Que se passe-t-il si le réviseur est indisponible?
• Un humain peut-il arrêter l’agent en cas de comportement anormal?

Une approbation doit être requise quand l’action est difficile à annuler, affecte des droits ou accès, modifie de l’argent, change un statut RH, envoie des communications externes, modifie des dossiers juridiques ou contractuels, change la posture sécurité ou touche la production.

Supervision faible:

Un humain est dans la boucle.

Supervision utile:

Un superviseur support doit approuver les remboursements au-dessus de CHF 100. L’écran d’approbation montre la demande client, la politique récupérée, le montant proposé, la raison, la commande source, les indicateurs de risque et l’ID de trace. L’approbation ou le rejet est journalisé avant l’appel à l’API de remboursement.

Ce niveau de précision tient en production.

Étape 6: noter l’impact métier

L’impact métier décrit ce qui arrive si l’agent échoue.

Considérez:

• L’agent se trompe.
• L’agent est trop confiant.
• L’agent suit une injection de prompt.
• L’agent appelle le bon outil avec de mauvais arguments.
• L’agent expose des données sensibles.
• L’agent saute une approbation requise.
• L’agent agit à grande échelle.
• L’agent échoue silencieusement.
• L’agent ne peut pas expliquer ce qui s’est passé.
• L’agent crée un enregistrement auquel les systèmes aval font confiance.

La question difficile est l’échelle. Un mauvais brouillon n’est pas 10 000 mauvais e-mails client. Une mauvaise recommandation n’est pas un déclencheur autonome qui se répète toutes les minutes.

Étape 7: attribuer le niveau final

Le niveau final doit rester simple.

Une approche pratique consiste à noter autonomie, accès aux outils, sensibilité des données et impact métier de 0 à 3, puis à utiliser le score le plus élevé et les signaux rouges.

Une formule aide, mais ne remplace pas le jugement. Un agent peu autonome avec accès à la paie mérite une revue forte. Un agent sans données sensibles mais capable de modifier des pare-feu n’est pas faible risque.

Checklist de passage en production

Avant lancement, exigez les preuves adaptées au niveau de risque.

Preuves minimales:

• Propriétaire métier et propriétaire technique.
• Prise d’information approuvée.
• Entrée d’inventaire.
• Matrice de permissions des outils.
• Classification des données et revue confidentialité si nécessaire.
• Design de supervision humaine.
• Plan de journalisation et traçabilité.
• Tests d’injection de prompt et de mauvais usage pour agents avec outils.
• Plan de monitoring et alerting.
• Responsable incident et chemin d’escalade.
• Date de revue et déclencheurs de réévaluation.

Pour les agents à risque élevé:

• Revue d’architecture.
• Acceptation explicite du risque.
• Tests des workflows d’approbation.
• Scénarios red team.
• Procédure de rollback ou kill switch.
• Change control pour prompts, outils, sources de retrieval et politiques.
• Règles de conservation des preuves.

Exemple: agent de remboursement support client

Un agent support peut lire l’historique de commande, résumer les messages client, vérifier la politique de remboursement et préparer des remboursements.

Niveau final: Élevé.

Contrôles requis:

• Outil de remboursement limité au minimum nécessaire.
• Seuil de montant.
• Approbation humaine au-dessus d’un montant défini.
• Blocage automatique des modèles inhabituels.
• Tests d’injection avec messages client et pièces jointes.
• Audit log pour demande, politique récupérée, décision proposée, approbation, appel d’outil et résultat final.
• Propriétaire support et chemin incident clairs.

Cet agent peut rester un bon candidat à la production. L’objectif n’est pas de bloquer les systèmes utiles, mais de rendre visibles les contrôles avant de toucher de vrais clients et de l’argent réel.

Exemple: assistant politique RH

Un assistant RH répond aux questions des employés à partir de documents approuvés. Il n’a pas d’outils d’écriture et ne consulte pas les dossiers individuels.

Niveau final: Faible à moyen, selon l’audience et les sujets.

Contrôles requis:

• Sources de connaissance approuvées.
• Propriétaire clair de la fraîcheur des politiques.
• Liens sources dans les réponses.
• Escalade pour questions emploi, juridique, avantages ou données personnelles sensibles.
• Journalisation d’usage.

Ce processus ne doit pas être identique à celui d’un agent finance autonome à fort impact. Une bonne gouvernance distingue les deux.

Base de référence

Ce modèle s’aligne avec plusieurs sources:

• NIST AI Risk Management Framework 1.0 pour la gouvernance, la cartographie, la mesure et la gestion contextuelles du risque IA.
• NIST AI RMF Generative AI Profile, NIST AI 600-1 pour les risques GenAI liés à la confidentialité, l’intégrité, la sécurité de l’information, la configuration humain-IA et la chaîne de valeur.
• OWASP Top 10 for LLM Applications 2025 pour l’injection de prompt, la divulgation d’informations sensibles, l’excessive agency et les risques applicatifs associés.
• OWASP Agentic AI - Threats and Mitigations pour la modélisation des menaces agentiques autour des outils, mémoire, identité et comportement agentique.
• EU AI Act, Regulation (EU) 2024/1689 pour les exigences des systèmes IA à haut risque: gestion des risques, documentation technique, logs, supervision humaine, exactitude, robustesse et cybersécurité.
• GDPR, Regulation (EU) 2016/679 pour le traitement de données personnelles, la sécurité, les violations et les analyses d’impact lorsque des données personnelles sont en jeu.

La leçon pratique est simple: l’évaluation d’un agent ne doit pas être une fiche modèle avec un nouveau titre. Elle doit relier les capacités réelles de l’agent à l’impact métier et aux contrôles de production.

Règle pratique

Si un agent ne peut que répondre, évaluez la qualité et l’accès aux données.

S’il peut agir, évaluez le chemin d’action.

S’il peut agir sans attendre un humain, évaluez le modèle opérationnel.

Et si personne ne peut expliquer qui possède l’agent, ce qu’il peut faire, ce qu’il a fait et comment l’arrêter, il n’est pas prêt pour la production.