Les agents d’intelligence artificielle ne se contentent plus de rédiger un texte ou de résumer un document. Ils peuvent rechercher une information, interroger une base, créer un ticket, modifier un fichier, déclencher un processus et recommencer jusqu’à atteindre un objectif. Cette autonomie promet des gains réels, mais elle change la nature du risque : une erreur ne reste plus forcément dans une réponse affichée à l’écran. Elle peut devenir une action exécutée dans le système d’information.
Microsoft a présenté le 27 juillet 2026 son projet Perception, un système de défense agentique conçu pour « percevoir, raisonner et agir » à la vitesse des machines tout en maintenant les humains aux commandes. La publication est consacrée à la cybersécurité, mais elle formule une question que toute entreprise doit se poser avant de brancher un agent à ses outils : quelles informations peut-il voir, quelles décisions peut-il préparer et quelles actions peut-il réellement exécuter ?
La bonne approche n’est ni de refuser toute autonomie, ni de donner à l’agent les mêmes droits qu’à un collaborateur expérimenté. Elle consiste à construire une autonomie graduée, observable et réversible.
1. Donner à chaque agent une identité propre
Un agent ne devrait jamais agir avec le compte personnel d’un salarié, encore moins avec un compte administrateur partagé. Il lui faut une identité technique distincte, rattachée à un propriétaire métier et à une finalité précise.
Cette identité permet de répondre à des questions simples : qui a autorisé l’agent ? À quel processus appartient-il ? Quels outils peut-il appeler ? Quand son accès expire-t-il ? Qui peut le désactiver ? Sans identité dédiée, les journaux confondent les actions humaines et automatiques. Lors d’un incident, l’entreprise perd du temps à reconstruire ce qui s’est passé.
Le principe du moindre privilège doit être appliqué littéralement. Un agent chargé de préparer un brouillon n’a pas besoin du droit de publier. Un agent qui classe des demandes n’a pas besoin de supprimer des dossiers. Un agent qui vérifie des factures peut lire des montants sans pouvoir modifier les coordonnées bancaires d’un fournisseur.
La première mesure concrète consiste donc à créer un inventaire des agents avec, pour chacun, son propriétaire, ses droits, ses sources de données et sa date de révision.
2. Séparer la recommandation de l’exécution
Tous les actes ne présentent pas le même risque. Chercher une information publique, proposer un classement et envoyer un paiement sont trois niveaux très différents.
Une grille simple peut distinguer :
- les actions en lecture seule ;
- les propositions soumises à validation ;
- les actions réversibles dans un périmètre borné ;
- les actions sensibles ou irréversibles.
Pour les deux premiers niveaux, l’automatisation peut être large. Pour les suivants, elle doit intégrer une approbation humaine, un plafond, un délai ou une règle d’arrêt. La validation ne doit pas devenir une formalité aveugle : l’écran d’approbation doit montrer l’action exacte, la cible, la donnée utilisée et l’effet attendu.
Un agent qui prépare dix mises à jour de fiches peut, par exemple, produire un aperçu des différences avant application. Un agent de communication peut créer un brouillon complet, mais la publication externe reste conditionnée à un contrôle du canal, du texte, de l’illustration et des liens.
Cette séparation protège l’entreprise sans supprimer le bénéfice de vitesse : la machine rassemble et prépare, l’humain arbitre ce qui engage réellement l’organisation.
3. Construire un contexte fiable plutôt qu’un accès illimité
Microsoft insiste sur l’importance du contexte de sécurité : les agents ont besoin d’une représentation cohérente des actifs, des identités, des relations et des risques. Dans une entreprise, le même principe vaut pour les agents métiers.
Ouvrir indistinctement une messagerie, un disque partagé et un CRM n’est pas une stratégie de contexte. C’est une extension massive de la surface d’exposition. Il faut fournir à l’agent les données nécessaires à la tâche, avec une provenance identifiable et une durée de conservation définie.
Avant le déploiement, trois contrôles sont utiles :
- vérifier que les sources sont à jour et autorisées ;
- réduire les données au périmètre réellement utile ;
- marquer les informations dont l’agent ne doit jamais provoquer la diffusion.
Le cadre de gestion des risques liés à l’IA du NIST rappelle que la confiance doit être intégrée à la conception, au développement, à l’utilisation et à l’évaluation des systèmes. La qualité du contexte fait partie de cette conception. Un agent très performant alimenté par une base obsolète produira rapidement des décisions obsolètes.
4. Journaliser l’intention, les données et l’action
Un journal technique qui indique seulement qu’une API a répondu « 200 OK » ne suffit pas. Pour comprendre une action agentique, il faut conserver une chaîne de preuve plus lisible :
- l’objectif reçu ;
- les données ou documents consultés ;
- le modèle et la version utilisés ;
- la règle ayant autorisé l’action ;
- l’appel effectué ;
- le résultat obtenu ;
- l’éventuelle validation humaine.
Il ne s’agit pas d’enregistrer sans discernement toutes les données personnelles. Le journal doit rester proportionné, protégé et limité dans le temps. Mais il doit permettre de distinguer une mauvaise instruction, une source erronée, un raisonnement fragile et une défaillance du connecteur.
Cette traçabilité sert aussi à l’amélioration. Elle révèle les tâches pour lesquelles l’agent apporte un vrai gain, celles qui génèrent trop de reprises et celles qui ne devraient pas être automatisées.
5. Prévoir le mode dégradé et le bouton d’arrêt
Un agent connecté à plusieurs systèmes peut multiplier une erreur. L’entreprise doit donc décider à l’avance ce qui se passe si une source devient indisponible, si les réponses divergent, si le coût s’emballe ou si le volume d’actions dépasse la normale.
Le mode dégradé peut être très simple : passer en lecture seule, transformer toutes les actions en brouillons, limiter le nombre d’opérations par heure ou suspendre un connecteur. L’arrêt doit pouvoir être déclenché par une personne identifiée sans dépendre de l’équipe qui a développé l’agent.
Il faut également tester la restauration. « Nous pouvons annuler » n’est pas une garantie tant qu’un exercice n’a pas montré comment retrouver les éléments touchés et revenir à l’état précédent.
Un pilote utile mesure davantage que la qualité des réponses
Un essai d’agent ne devrait pas être évalué uniquement sur la pertinence de ses textes. Les indicateurs importants comprennent aussi le taux d’actions annulées, les validations refusées, les écarts de droits, les données inutiles consultées, les reprises humaines et le temps nécessaire pour expliquer une décision.
Microsoft présente une architecture multimodèle qui sélectionne les capacités selon la qualité, la fiabilité, la latence et le coût. Pour une entreprise, cette logique est plus saine que l’idée d’un modèle unique chargé de tout. Une tâche documentaire, une analyse de sécurité et une rédaction commerciale ne réclament pas nécessairement le même système, ni le même niveau de dépense.
Le geste à effectuer cette semaine est concret : choisissez un agent déjà utilisé ou envisagé, puis dessinez sa chaîne complète — identité, données, outils, droits, validation, journal et arrêt. Si l’une de ces cases reste vide, l’agent n’est pas encore prêt à agir seul dans les outils métiers.
