L'erreur du jour zéro : donner à l'agent le compte de Marta
Presque tous les agents que nous avons vus arriver en production ont commencé pareil : quelqu'un avait besoin que la chose lise les mails et écrive dans le CRM, et la voie rapide était de reprendre les identifiants d'une personne qui avait déjà les accès. Marta, aux opérations. Ça marche le premier jour. L'ennui arrive le deuxième, et il n'est pas technique : à partir de là, plus personne dans l'entreprise ne sait répondre à deux questions élémentaires. Qui a fait ce changement, Marta ou l'agent. Et que peut toucher exactement cette chose.
La réponse à la seconde est toujours la même et toujours inconfortable : tout ce que Marta peut toucher. Dix ans d'ancienneté, trois changements de service, et les droits accumulés de chacun. L'agent n'a pas hérité d'une tâche ; il a hérité d'une carrière entière. Et contrairement à Marta, il n'a aucun jugement qui lui dise que le dossier de la paie ne s'ouvre pas, même si quelque chose dans le contexte le lui demande très poliment.
L'OWASP a mis un nom là-dessus en décembre 2025, en publiant son Top 10 des applications agentiques. La catégorie ASI03 s'appelle Identity & Privilege Abuse et la décrit exactement ainsi : des identifiants hérités ou fuités qui laissent l'agent opérer bien au-delà de son périmètre prévu. Ce n'est pas une hypothèse de laboratoire — la liste a été bâtie sur des incidents réels de la première génération d'adoptants.
La matrice à quatre colonnes qu’on remplit avant de brancher quoi que ce soit
La conception des droits d'un agent tient dans un tableau qui se remplit en quarante minutes de réunion, et qu'il faut remplir avant de créer le premier identifiant. Pas après : après, quelque chose tourne déjà et personne ne veut être celui qui casse. Quatre colonnes de droits, un système par ligne.
| Système | Ce qu’il LIT | Ce qu’il ÉCRIT | Ce qu’il EXÉCUTE | Ce qu’il ne touche jamais |
|---|---|---|---|---|
| CRM | Opportunités ouvertes de son portefeuille | Notes et prochaine étape | Rien | Montant, étape de clôture, suppression de fiches |
| Messagerie | Boîte d’un alias qui lui est propre | Brouillons dans un dossier de relecture | Rien | Envoyer sans relecture, transférer hors du domaine |
| ERP / facturation | Statut des commandes | Rien | Rien | Tout le reste |
| Stockage | Dossier du projet | Sous-dossier de sorties | Rien | Paie, juridique, dossiers de direction |
La colonne dont tout le monde discute est la troisième, exécuter, et c'est celle qui compte le plus. Lire est réversible. Écrire l'est en général, avec un historique correct. Exécuter — déclencher un paiement, envoyer un mail à un client, clore un ticket, supprimer — ne l'est presque jamais. Règle pratique : une action entre dans la colonne exécuter seulement si quelqu'un sait décrire en une phrase comment on la défait. Si la phrase n'existe pas, l'action reste à « propose et attend ».
Et la quatrième colonne, ce qu'il ne touche jamais, n'est pas décorative. C'est la seule qu'on écrit en positif dès le départ, et la seule qui survit aux changements de périmètre : dans six mois, quand quelqu'un voudra « élargir un peu ses droits pour qu'il fasse aussi ça », c'est elle qui oblige à avoir la conversation au lieu de la régler d'un clic dans la console.
Une identité à lui : l'agent n'est pas le plugin de quelqu'un
Un compte de service, ce n'est pas de la bureaucratie de sécurité. C'est ce qui rend possibles les trois choses suivantes, et sans lui aucune ne l'est.
- Audit. Le journal dit « agent-ventes-01 » et pas « marta.g ». Quand quelque chose cloche, l'enquête dure dix minutes au lieu d'un après-midi à demander aux gens si c'était eux.
- Révocation propre. On coupe l'agent sans empêcher une personne de travailler, et on désactive une personne sans couper l'agent. Évident — jusqu'au jour où l'identifiant est partagé et où vous ne pouvez faire ni l'un ni l'autre.
- Périmètre réel. Vous ne pouvez lui donner moins de droits qu'à un humain que s'il a un compte distinct de celui de l'humain. Avec un identifiant partagé, le « moindre privilège » est une intention, pas une configuration.
L'objection habituelle est le coût : dans beaucoup d'outils SaaS, un compte de plus, ce sont trente ou cinquante euros par mois. Objection légitime, et qui a une bonne réponse presque partout : comptes de service, d'intégration ou d'API, non facturés au siège utilisateur. La mauvaise réponse — celle qu'on prend par défaut quand personne ne pose la question — c'est de partager le compte de Marta pour économiser quarante euros et de se retrouver sans audit, sans révocation et sans périmètre. Quand on branche un agent sur un CRM précis, la conversation devient très concrète : connecter un agent IA à votre CRM descend au niveau des objets, des champs et de la synchronisation.
Périmètre par tâche, pas par personne
Le modèle mental hérité de l'IAM, c'est le rôle : « commercial », « support », « administration ». Il marche avec des humains parce qu'un humain fait beaucoup de choses et que son jugement comble les trous. Avec un agent, le rôle est bien trop large : l'agent fait une chose et n'a aucun jugement pour combler quoi que ce soit.
Donc le droit se taille à la tâche. Pas « accès au support », mais « lire les tickets ouverts de la file facturation et écrire une réponse en brouillon ». Tout ce qui déborde de cette phrase déborde de l'identifiant. C'est plus de travail de configuration au départ, et en échange la question « qu'est-ce que ce truc peut faire ? » a une réponse écrite au lieu d'une enquête.
Un effet secondaire compense le travail : quand le périmètre est une tâche et non un rôle, élargir l'agent impose un changement de droits explicite, et ce changement laisse une trace. L'agent qui grossit sans que personne ne le remarque est celui qui a démarré sur un rôle large. Et quand plusieurs agents grossissent déjà tout seuls, le problème n'est plus de la conception mais du sauvetage : c'est le sujet de mettre un frein aux agents IA hors de contrôle.
Contre l'injection de prompt, le droit que vous n'avez pas donné
L'injection de prompt, c'est la voie par laquelle un contenu que l'agent lit — une page, un mail, un document, un ticket — lui glisse des instructions qui ne viennent pas de vous. Et l'état de l'art, dit par ceux qui construisent les modèles, c'est que ce n'est pas résolu. En novembre 2025, Anthropic a publié ses résultats de robustesse en navigation avec Claude Opus 4.5, accompagnés d'une phrase à lire lentement : un taux de succès de 1 % face à un attaquant adaptatif reste un risque réel, aucun agent de navigateur n'est immunisé, et les données sont publiées pour montrer un progrès, pas pour clore le sujet.
D'où la seule conclusion pratique qui tienne : vous ne pouvez pas empêcher qu'on manipule l'agent ; vous pouvez décider de ce dont un agent manipulé est capable. La défense n'habite pas dans le prompt système — c'est précisément ce que l'attaquant attaque. Elle habite dans l'identifiant, que l'attaquant ne peut pas atteindre depuis le contenu.
Traduit dans la matrice ci-dessus : chaque droit de la colonne « exécute » est une capacité dont hérite un attaquant qui réussit à glisser une instruction. Un agent qui lit et propose seulement, une fois injecté, produit une proposition bizarre que quelqu'un écarte. Le même agent avec le droit d'envoi produit un mail déjà parti. Ce n'est pas le modèle qui a fait la différence. C'est une case que quelqu'un a choisi de ne pas cocher.
Le bouton de révocation à tester AVANT de démarrer
Tout le monde suppose pouvoir couper son agent. Très peu l'ont vérifié. Et le moment de vérifier n'est pas quand l'agent fait quelque chose de bizarre un vendredi après-midi : c'est avant la première exécution réelle, à froid, avec du temps et sans nerfs.
Le test est court. On lance une tâche normale, on révoque l'identifiant en cours de route, et on regarde trois choses : combien de temps il faut vraiment pour que ça cesse d'avoir un effet — les jetons en cours et les sessions ouvertes ne meurent pas toujours avec le bouton —, dans quel état reste le travail à moitié fait, et si quelqu'un s'aperçoit que c'est arrivé. Puis on réaccorde et on vérifie que ça redémarre. Une demi-heure.
- Qui peut l'appuyer. Au moins deux personnes, et l'une d'elles ne peut pas être celle qui a construit l'agent. Si le bouton dépend d'une seule personne, il n'y a pas de bouton : il y a un coup de téléphone.
- Où il est. Écrit, avec le lien exact vers la console et le nom exact de l'identifiant. Le chercher à chaud, c'est la moitié du temps de réaction.
- Ce qui se passe ensuite. Par quoi on remplace le travail de l'agent pendant la coupure. Si la réponse est « rien », couper a un coût que quelqu'un hésitera à payer, et cette hésitation est ce qui fait durer les incidents.
Ce même dispositif — qui répond, où c'est écrit, par quoi on remplace — soutient n'importe quelle automatisation en production, pas seulement les agents ; il est développé dans qui répond quand une automatisation tombe. Et si ce que vous cherchez, c'est la carte complète des risques avant de décider quoi que ce soit, le catalogue est dans les risques des agents IA qu'on ne voit pas en démo.
Ce que vous faites cette semaine
- Remplissez la matrice à quatre colonnes pour l'agent le plus proche de la production. Un système par ligne. Quarante minutes avec celui qui connaît le processus, pas celui qui connaît l'outil.
- Créez l'identifiant propre de l'agent avant de le brancher à quoi que ce soit. Si votre outil facture au siège, demandez un compte de service ou d'API avant de vous résigner au partage.
- Réduisez le périmètre du rôle à la tâche : lisez la description de l'agent à voix haute et retirez de l'identifiant tout ce qui n'apparaît pas dans cette phrase.
- Appliquez le test de la case à chaque droit d'écriture et d'exécution. Ce qui vous met mal à l'aise redescend à « propose, un humain confirme ».
- Testez la révocation à froid, avec deux personnes qui savent l'appuyer, et notez où est le bouton et par quoi on remplace le travail.
Aucune de ces cinq étapes n'exige de choisir une plateforme, un modèle ou un fournisseur. Elles se font avant, et une seule fois. Ce que vous décidez ici plafonne les dégâts de tout ce qui suivra — et vous permettra de dire oui, plus tard, à des choses qui aujourd'hui vous donneraient le vertige. Car les droits définissent ce que l'agent peut toucher ; la liberté qu'on lui laisse pour s'en servir est la décision suivante, et elle ne s'accorde pas d'un coup : on gravit les cinq échelons de l'autonomie preuves en main — cas vus, taux de correction humaine et réversibilité de l'action.
Nous montons la partie que personne ne veut monter : identités de service, périmètres à la tâche, révocation testée et le registre de qui a fait quoi. C'est l'infrastructure IA d'entreprise sur laquelle s'appuie ensuite n'importe quel agent qui travaille vraiment. Nous ne vendons pas le droit d'accès. Nous facturons le fait qu'il soit le bon.