Le vrai risque d’un agent IA, ce n’est pas ce qu’il pense. C’est ce qu’il fait.
Un agent IA qui se trompe dans un résumé, c’est énervant. Un agent IA qui envoie 300 emails, modifie des fiches clients, valide des avoirs ou déclenche un paiement, c’est un incident. Et l’incident arrive rarement à cause d’un “mauvais prompt”. Il arrive parce que tu as donné trop de droits, trop tôt, sans traçabilité, sans filet, sans bouton stop.
La tendance est claire: on ne parle plus de “faire un POC”. On parle de gouvernance des agents IA: droits, traçabilité, contrôle des actions, et coût. Les plateformes d’agents industrialisent justement ce qui manquait avant: journaux d’actions, “approvals”, garde-fous, traces d’exécution. Tant mieux. Mais ça ne remplace pas une règle simple côté direction: l’autonomie n’est pas un bouton On/Off. C’est un contrat.
Je te donne ici une grille de gouvernance ultra praticable: 3 niveaux d’autonomie. Tu peux t’en servir dès aujourd’hui pour décider ce qu’un agent a le droit de faire, avec quels accès, quel contrôle, et comment tu coupes si ça dérape.
La grille “3 niveaux d’autonomie” (simple, mais pas simpliste)
Objectif: éviter le syndrome “on connecte tout, on verra après”. Chaque agent a un niveau. Et ce niveau dicte tout le reste: permissions, logs, environnement de test, escalade, kill switch.
Niveau 1: Lecture et rapport (zéro action)
Définition: l’agent lit des infos et produit un résultat, mais ne touche à rien. Pas d’écriture. Pas d’envoi. Pas de modification.
Exemples:
- Lire des tickets support et sortir un rapport hebdo: motifs, temps de réponse, irritants.
- Scanner un CRM et détecter les leads dormants.
- Analyser une boîte mail et classer les demandes (sans répondre).
Pourquoi c’est utile: tu récupères déjà du temps de pilotage. Et le risque est bas, parce que l’agent n’a pas la main sur tes systèmes.
Niveau 2: Proposition + validation humaine (l’agent prépare, l’humain décide)
Définition: l’agent peut préparer une action, mais il ne l’exécute pas sans un feu vert humain explicite.
Exemples:
- Rédiger une réponse support et la mettre en “brouillon” pour validation.
- Préparer une relance d’impayé, mais ne pas l’envoyer.
- Proposer une mise à jour CRM, mais attendre une approbation.
Pourquoi c’est le niveau le plus rentable au départ: tu automatises 80% de l’effort (collecte, synthèse, rédaction, mise en forme), tout en gardant le contrôle du risque.
Niveau 3: Action autonome (l’agent exécute)
Définition: l’agent peut déclencher des actions dans tes outils, sans validation humaine à chaque fois.
Exemples:
- Rembourser un client sur des cas simples et bornés.
- Mettre à jour un dossier dans l’ERP.
- Répondre automatiquement à certains tickets niveau 1.
Ce niveau n’est pas “interdit”. Il est “conditionnel”. Il faut des garde-fous stricts, sinon tu crées une bombe à retardement: accès trop larges, prompt injection, boucle d’actions, fuite de données, coûts qui explosent.
Comment choisir le niveau: une décision de dirigeant, pas une décision “tech”
Tu choisis le niveau en fonction de l’impact business et du risque. Pas en fonction de la hype.
Le test rapide: impact, réversibilité, exposition
- Impact: si l’action peut coûter de l’argent, casser une relation client, ou créer un risque légal, tu montes les contrôles.
- Réversibilité: si tu peux annuler facilement, c’est plus simple. Si c’est irréversible (paiement, suppression, envoi massif), tu verrouilles.
- Exposition: si l’agent touche à des données sensibles (RH, santé, juridique, finance) ou à des systèmes critiques (ERP, paiement), tu limites l’autonomie.
Règle terrain: tu ne commences jamais au niveau 3. Tu prouves d’abord la valeur au niveau 1, puis 2. Le niveau 3 arrive quand tu as les métriques, les logs, et les garde-fous.
Le “contrat d’autonomie”: ce que tu dois écrire noir sur blanc
Un agent sans contrat, c’est une zone grise. Et une zone grise en entreprise, ça finit en incident, puis en “on coupe tout”. Le contrat d’autonomie tient en une page. Il contient 6 blocs.
1) Périmètre: ce que l’agent fait, et surtout ce qu’il ne fait pas
- Mission: “traiter les demandes support niveau 1 sur X produits”.
- Hors périmètre: “pas de remboursement”, “pas de modification d’adresse”, “pas de traitement RGPD”, “pas de conseils juridiques”.
- Canaux: email, chat, back-office, etc.
Tu veux du binaire. Pas de flou. Le flou, l’agent le remplit. Et il le remplit mal.
2) Permissions: moindre privilège, par outil, par action
Ici on parle de contrôle accès IA, pas de “prompt”. Les droits font la différence entre un agent utile et un agent dangereux.
- Lecture seule par défaut.
- Écriture seulement sur des objets précis (ex: “créer brouillon email”, pas “envoyer email”).
- Scopes API minimaux (pas un token admin “au cas où”).
- Comptes dédiés pour les agents, jamais les comptes perso des employés.
- Séparation des environnements: dev/test/prod, avec clés séparées.
Si tu veux cadrer ça proprement, lis aussi: “Agents IA et cybersécurité : contrôle des accès (NHI) avant ton premier agent” https://jimmymanin.com/blog/agents-ia-et-cybersecurite-controle-des-acces-nhi-avant-ton-premier-agent
3) Journaux d’activité: tu dois pouvoir répondre à “qui a fait quoi, quand, pourquoi”
Sans logs exploitables, tu es aveugle. Et quand ça dérape, tu ne peux même pas reconstruire la chaîne.
Ton minimum viable de gouvernance agents IA côté traçabilité:
- ID de corrélation par exécution (une “session” agent).
- Journal des actions: appels outils, API, fichiers touchés, messages envoyés, modifications.
- Entrées et sorties utiles pour audit (en respectant confidentialité et minimisation).
- Conservation: durée, accès, centralisation (SIEM ou logs centralisés).
- Alerting: seuils de volume, erreurs répétées, comportements anormaux.
Important: certaines politiques de confidentialité (ex: “zero data retention”) peuvent limiter la traçabilité côté fournisseur. Donc tu dois prévoir des logs côté SI: proxy, passerelle API, journaux applicatifs.
4) Environnement de test: tu ne testes pas en prod (non, même “vite fait”)
Erreur classique: connecter l’agent à la prod pour “voir”. Mauvaise idée. Tu veux un bac à sable avec des données réalistes, mais non sensibles.
- Sandbox CRM/Helpdesk si possible.
- Données de test (ou masquées): noms fictifs, emails internes, montants simulés.
- Connecteurs limités: pas de paiement, pas d’envoi externe, pas de suppression.
- Scénarios d’attaque: prompt injection dans un ticket, pièces jointes bizarres, demande hors périmètre.
Tu veux voir comment l’agent réagit quand on le pousse dans ses retranchements. Parce que tes clients (ou un attaquant) le feront.
5) Règles d’escalade: quand l’agent s’arrête et passe la main
Le meilleur agent, c’est celui qui sait dire “stop”. Les règles d’escalade doivent être mécaniques, pas “au feeling”.
Exemples de déclencheurs:
- Confiance insuffisante (score interne, ou règles: pas d’info fiable dans la base).
- Motifs sensibles: remboursement, litige, juridique, RGPD, santé, sécurité.
- Client à haute valeur (tag CRM): toujours validation humaine.
- Montant: au-delà de X euros, validation obligatoire.
- Ambiguïté: le client mélange plusieurs sujets, ou demande une exception.
6) Kill switch: le bouton rouge, technique (pas un “process”)
Le “kill switch” organisationnel (“on appelle Paul pour couper l’agent”) ne suffit pas. Tu veux un arrêt immédiat.
- Désactivation du connecteur ou de la clé API de l’agent.
- Blocage des actions à risque (envoi externe, paiement, suppression).
- Rate limit agressif si l’agent boucle.
- Mode dégradé: repasser automatiquement en niveau 2 ou niveau 1.
Sur le sujet “agent qui part trop loin”, tu peux aussi lire: https://jimmymanin.com/blog/agent-ia-autonome-le-garde-fou-anti-debordement-a-poser-avant-quil-pirate-un-site
Le modèle complet: ton agent a un niveau, et chaque niveau impose ses contrôles
Niveau 1: checklist gouvernance (lecture/rapport)
- Accès: lecture seule, sur un périmètre data défini.
- Données sensibles: masquage (emails, IBAN, santé, etc.) si possible.
- Logs: consultations, exports, requêtes.
- Escalade: si données manquantes ou sujet sensible, flag pour humain.
Niveau 2: checklist gouvernance (proposition + validation)
- Accès: lecture + écriture limitée (brouillons, suggestions, tickets en “à valider”).
- Workflow d’approbation: une action = un humain valide, avec preuve.
- Logs: proposition, qui a validé, et ce qui a été envoyé/exécuté.
- UI: l’humain voit la source (extraits ticket, éléments CRM) avant de valider.
- Garde-fous: interdiction de certains mots, montants, actions.
Niveau 3: checklist gouvernance (action autonome)
Si tu veux du niveau 3, tu signes pour des contraintes supplémentaires. Sinon, tu joues.
- Permissions ultra réduites: action autonome uniquement sur des “micro-actions” bornées.
- Plafonds: montants max, volume max, nombre d’actions par heure/jour.
- Double contrôle sur tout ce qui est financier, légal, RH, suppression, envoi massif.
- Monitoring: alertes en temps réel, pas un rapport en fin de semaine.
- Rollback prévu: comment annuler, corriger, restaurer.
- Kill switch testé (oui, testé).
Exemple concret: un agent support client (du niveau 1 au niveau 3, sans se mentir)
Cas typique en PME: beaucoup de demandes répétitives, peu de temps, et un risque réputation si l’agent répond n’importe quoi.
Étape 1: niveau 1 (2 semaines) “Lire et reporter”
Mission: lire les tickets, classer les motifs, mesurer les temps de réponse, détecter les tickets “à risque”.
Accès: helpdesk en lecture seule.
Livrables:
- Top 10 motifs.
- Tickets avec mots-clés sensibles (“remboursement”, “DGCCRF”, “plainte”, “fraude”).
- Propositions d’articles FAQ à créer.
Gain dirigeant: tu vois où part le temps. Tu priorises. Tu n’as pris aucun risque d’action.
Étape 2: niveau 2 (2 à 6 semaines) “Proposer et faire valider”
Mission: générer une réponse proposée pour chaque ticket niveau 1, avec sources internes (FAQ, politiques, historique client), et créer un brouillon.
Règles:
- Si ticket contient un motif sensible, escalade directe.
- Si client VIP, validation obligatoire par un responsable.
- Si l’agent n’a pas la source, il pose des questions au lieu d’inventer.
Contrôle: un humain clique “envoyer”. Et tu logges: suggestion de l’agent, validation, envoi.
Gain: tu accélères sans lâcher la barre. C’est souvent là que tu t’arrêtes, parce que le ROI est déjà bon.
Étape 3: niveau 3 (après stabilité) “Action autonome sur un couloir ultra étroit”
Tu n’ouvres pas tout. Tu crées un couloir.
Couloir d’autonomie (exemple):
- Seulement les tickets “Où est ma facture ?” ou “Comment réinitialiser mon mot de passe ?”.
- Seulement si le client est authentifié.
- Seulement si l’action est réversible (envoi d’un lien, renvoi d’un PDF déjà existant).
- Jamais de geste commercial sans validation.
Plafonds:
- Max X réponses autonomes par heure.
- Stop automatique si taux d’erreur ou de réouverture dépasse Y%.
Kill switch: si l’agent part en boucle ou si un motif sensible apparaît, il repasse en niveau 2.
Si tu veux creuser le support en mode “petite équipe”, tu as aussi: https://jimmymanin.com/blog/support-client-ia-gere-ton-niveau-1-quand-tu-es-seul-ou-presque
Ce que tu gagnes avec cette gouvernance (et ce que tu évites)
- Temps: tu automatises par paliers, sans blocage politique interne (“l’IA est dangereuse”).
- Marge: tu réduis le coût par ticket, par relance, par opération répétitive.
- Risque: tu limites l’“agency” excessive, le vrai carburant des incidents (actions non prévues).
- Confidentialité: tu maîtrises ce qui sort, ce qui est loggé, et qui a accès à quoi.
- Conformité: supervision humaine réelle quand nécessaire, traçabilité, procédures de correction. C’est exactement l’esprit des exigences de supervision et de réduction des risques qu’on voit dans les cadres type NIST et dans la logique de l’AI Act.
Plan d’action 60 minutes: poser ton modèle “3 niveaux” sur un agent réel
Prends un agent que tu veux lancer (support, facturation, relance, qualification). Et fais ça, maintenant.
- 1) Écris la mission en 3 lignes + la liste “interdit” (hors périmètre).
- 2) Choisis le niveau (1, 2 ou 3). Si tu hésites, c’est niveau 2.
- 3) Liste les outils touchés (CRM, email, helpdesk, ERP) et décide: lecture seule, brouillon, ou action.
- 4) Définis 5 règles d’escalade (mots-clés, montant, VIP, ambiguïté, absence de source).
- 5) Décide où sont les logs et qui les lit (au moins hebdo au départ).
- 6) Mets un kill switch technique: désactivation clé/connector + plafonds de volume.
- 7) Planifie un test en sandbox avec 20 scénarios, dont 5 scénarios “hostiles”.
Si tu fais juste ça, tu es déjà au-dessus de la majorité des entreprises qui “branchent un agent” et croisent les doigts. Et tu peux continuer à automatiser sans transformer ton SI en casino.
