Un agent IA, ce n’est pas “juste un outil”. C’est un insider potentiel.
Microsoft pose le constat sans détour : dès qu’un agent IA a des permissions et un accès à des systèmes d’entreprise, tu dois le traiter comme un compte interne à risque. Pas besoin d’un pirate externe. Le risque existe déjà, “de l’intérieur” : l’agent agit avec des droits réels, sur tes données réelles, dans tes outils réels.
Le piège le plus courant : tu veux que “ça marche vite”, donc tu sur-provisionnes. Microsoft Entra le dit aussi : les agents sont souvent sur-autorisés au démarrage. Et mécaniquement, tu crées une surface d’incident.
Ce qui suit, c’est ton plan en 90 minutes pour cadrer un agent avant la moindre connexion à ton SI : droits (RBAC), identité non-humaine dédiée, logs exploitables, limites d’action, sandbox, et procédure d’arrêt. Du concret, orienté dirigeant : temps, coûts, risques, responsabilité.
Le but de ces 90 minutes
Tu veux pouvoir répondre en moins de 10 minutes à ces questions :
- Quel agent a fait l’action ?
- Quand et depuis quel environnement (test/prod) ?
- Avec quels droits ?
- Sur quelles données ?
- Quel humain l’a autorisé et en est responsable ?
- Comment je stoppe l’agent maintenant, sans débat ?
Si tu n’as pas ça, tu n’as pas de pilotage. Tu as un gadget branché sur ton SI.
Avant de démarrer : le cadre “agent = compte interne”
Prends une feuille (ou un doc) et écris cette règle :
Un agent IA = une identité interne non-humaine, avec des droits minimaux, des logs obligatoires, et un bouton stop.
Le NIST recommande explicitement une identité unique par agent et des précautions comparables à des utilisateurs privilégiés, parce qu’un agent peut accéder à plus d’outils et de données qu’un utilisateur standard.
Ajoute un deuxième rappel, très dirigeant :
Tu ne déploies pas un agent. Tu déploies un nouveau “collaborateur logiciel” qui clique à ta place, vite, et parfois mal.
Le plan en 90 minutes, minute par minute
0 à 10 min : fiche d’identité de l’agent (mission, périmètre, responsable)
Tu crées une fiche simple. Sans ça, tu ne sais même pas ce que tu sécurises.
- Nom de l’agent (unique et explicite) : “Agent relance factures” plutôt que “Agent IA”.
- Objectif business en une phrase : “Réduire le DSO en relançant les factures échues”.
- Périmètre : quels outils (ERP, CRM, Drive, email…), quelles équipes, quelles données.
- Niveau d’autonomie : lecture seule, proposition, exécution sous validation, exécution autonome.
- Owner humain : une personne nommée, pas “l’IT”.
- Critère d’arrêt : “si plus de X erreurs”, “si export massif”, “si coût tokens anormal”, etc.
Décision dirigeant : si personne n’assume l’ownership, l’agent ne passe pas la porte. Point.
10 à 30 min : cartographie des accès (RBAC) par action, pas par outil
Ne liste pas “Salesforce”, “SAP”, “Google Drive”. Liste ce que l’agent peut faire.
Tu fais un tableau en 3 colonnes : Action, Données touchées, Droit minimal.
- Lire une liste de factures échues : lecture seule sur l’objet “facture”.
- Rédiger un email de relance : écriture brouillon uniquement (pas envoi).
- Mettre à jour une note CRM : écriture limitée à un champ spécifique.
- Créer une tâche pour un commercial : autorisé, mais sur une file dédiée.
Règle : lecture seule par défaut. Écriture uniquement si le besoin business est prouvé et mesurable.
Microsoft recommande le moindre privilège et d’éviter les contextes “author-run” en production. Traduction terrain : tu n’exécutes pas l’agent avec le compte du créateur “parce que c’est plus simple”.
Décision dirigeant : chaque droit d’écriture a un coût risque. Donc chaque droit d’écriture doit avoir un gain clair.
30 à 45 min : identité non-humaine dédiée (NHI), jamais un compte “emprunté”
Tu crées une identité dédiée pour l’agent. Une par agent. Traçable. Révocable.
- Interdit : compte partagé “agent@”, mot de passe connu de plusieurs personnes.
- Interdit : utiliser le compte d’un humain (le DG, le DAF, le responsable IT) “le temps de tester”.
- Obligatoire : un compte technique/service principal/identité applicative selon ton stack, avec politique d’accès.
Pourquoi c’est non négociable : si l’agent agit avec le compte d’un humain, tu perds la non-répudiation. Tu ne sais plus qui a fait quoi. Et le jour où ça dérape, tu n’as pas d’audit propre.
Décision dirigeant : une identité dédiée te donne un levier simple. Tu peux couper l’agent sans couper un humain.
45 à 60 min : logs et audit exploitables (pas “on a des logs quelque part”)
Tu définis ce que tu veux retrouver dans les logs. Sinon, tu vas découvrir trop tard que tu ne logges pas les bonnes infos.
Minimum vital à exiger :
- Invocation : qui a déclenché l’agent (utilisateur, horaire, source).
- Actions outillées : chaque appel à un connecteur, une API, une action métier.
- Décisions de politique : autorisé/refusé, et pourquoi.
- Volume : nombre d’objets touchés, taille des exports, nombre d’emails, etc.
- Contexte d’identité : l’identité non-humaine utilisée, le rôle effectif.
Côté Microsoft, la journalisation d’audit devient un standard de gouvernance (exemple : événements d’audit via le pipeline Microsoft Purview Audit pour Copilot Studio). Peu importe ton outil : l’exigence dirigeant est la même. Tu veux une piste d’audit actionnable.
Décision dirigeant : sans logs exploitables, tu ne “déploies” pas, tu “espères”. Et l’espoir n’est pas une stratégie de sécurité agents IA entreprise.
60 à 75 min : limites d’action (garde-fous runtime)
Un agent, même bien configuré, peut partir en vrille. Pas par malveillance. Par ambiguïté, prompt mal compris, données inattendues, connecteur trop permissif.
Tu poses des garde-fous techniques et métiers :
- Allowlist de connecteurs et d’actions : l’agent n’a pas “internet + tout ton SI”.
- Plafonds : nombre d’actions par minute/heure/jour (emails, créations, modifications).
- Blocages par défaut sur actions sensibles : paiement, suppression, export massif, changement de RIB, modification de droits.
- Circuit d’approbation : pour les actions à impact, l’agent prépare, un humain valide.
- DLP : règles de fuite selon environnements (interdire partage externe, copie vers espaces non gérés).
Décision dirigeant : tu choisis ce que tu préfères. Un agent plus lent mais contrôlé, ou un agent “rapide” qui te crée un incident insider threat IA.
75 à 85 min : sandbox obligatoire (test isolé + promotion contrôlée)
Tu testes l’agent dans un environnement qui ressemble à la prod, mais qui ne peut pas faire de dégâts.
- Données de test réalistes (ou anonymisées si besoin).
- Permissions de test séparées de la prod.
- Connecteurs de test (bacs à sable) quand c’est possible.
- Prompts et configurations versionnés : tu sais ce qui change entre test et prod.
Le point dirigeant : la sandbox réduit le risque, mais elle réduit aussi le coût caché des agents. Parce qu’un agent qui casse la prod coûte toujours plus cher qu’un agent qui “rate” en test.
Si tu bosses déjà le sujet RGPD avant connexion, garde la continuité : IA agentique en entreprise : la checklist RGPD avant de connecter un agent à vos outils.
85 à 90 min : procédure d’arrêt (kill switch) + routine de revue
Tu écris noir sur blanc comment arrêter l’agent en 2 minutes.
- Qui peut l’arrêter (au moins 2 personnes).
- Comment : désactiver l’identité non-humaine, couper le connecteur, désactiver l’environnement, etc.
- Quand : seuils d’erreur, volume anormal, suspicion fuite, coût anormal.
- Quoi vérifier après arrêt : derniers logs, dernières actions, éventuels correctifs.
Ajoute une mini-routine : revue hebdo au début, puis mensuelle. 15 minutes. Un agent non revu devient un risque silencieux.
Ce que tu gagnes vraiment avec ce plan
- Temps : tu évites le ping-pong “on verra plus tard” quand l’agent est déjà branché partout.
- Coûts : moins d’incidents, moins de rollback, moins d’heures “pompiers”.
- Traçabilité : tu peux auditer. Tu peux expliquer. Tu peux trancher.
- Maîtrise : tu évites le sprawl. Et vu les projections Gartner sur l’explosion du nombre d’agents, l’inventaire et la gouvernance deviennent vite obligatoires si tu veux garder la main.
Si tu veux cadrer le déploiement au-delà de la sécurité pure (rythme, périmètre, ouverture progressive), garde ça sous le coude : Agents IA en entreprise : le plan “pilote contrôlé” en 21 jours (sans ouvrir les vannes).
Checklist décisionnelle dirigeant : ce que tu autorises, interdis, mesures
1) Ce que tu autorises (par défaut)
- Lecture sur des périmètres précis (données nécessaires, pas plus).
- Proposition plutôt qu’action : brouillons, recommandations, tickets à valider.
- Écriture limitée sur des champs non destructifs (notes, tags, statuts encadrés).
- Sandbox obligatoire avant prod.
- Identité dédiée par agent, révocable.
2) Ce que tu interdis (sans exception au démarrage)
- Utiliser un compte humain pour exécuter l’agent.
- Donner des droits “admin” “pour que ça marche”.
- Suppression de données, purge, actions irréversibles.
- Export massif et partage externe.
- Paiements, modifications bancaires, remboursements, avoirs automatiques.
- Absence de logs exploitables.
3) Ce que tu mesures (sinon tu pilotes à l’aveugle)
- Volume d’actions : créations, modifications, envois, exports.
- Taux d’erreur et types d’erreurs (auth, droits, données, logique).
- Données sensibles touchées (au moins par catégories).
- Coût : tokens, licences, appels API, surconsommation.
- Temps gagné réel (mesure avant/après sur un processus).
- Incidents évités ou incidents causés (même mineurs, tu journalises).
Pour la partie coûts et dérives de consommation, tu peux compléter avec : Budgets IA qui dérapent : piloter tokens, licences et dépassements sans bloquer tes équipes.
Le test final (30 secondes) : “si l’agent fait n’importe quoi, suis-je capable de prouver et d’arrêter ?”
Pose-toi ces 5 questions :
- Est-ce que je sais exactement quels droits l’agent a ?
- Est-ce que je peux voir exactement ce qu’il a fait dans des logs lisibles ?
- Est-ce que je peux couper l’agent sans couper un humain ?
- Est-ce que l’agent a été testé en sandbox avec les mêmes règles qu’en prod ?
- Est-ce que j’ai interdit les actions qui peuvent coûter très cher (argent, données, réputation) ?
Si tu as un “non”, tu ne branches pas. Tu corriges. C’est ça, traiter un agent comme un insider threat IA.
Prochaine action (simple) : fais la fiche et le RBAC avant la prochaine démo
Le move intelligent : tu fais ce plan avant la démo “waouh” où quelqu’un va demander “on peut le connecter à tout ?”.
Tu prends 90 minutes, tu produis 6 livrables légers : fiche agent, matrice d’actions RBAC, identité NHI, exigences logs, garde-fous runtime, kill switch.
Après ça, tu peux avancer vite. Mais propre. Et surtout, tu restes maître de ton SI.
