Les organisations avec lesquelles RSA collabore — banques, administrations publiques, secteur de la défense, infrastructures critiques — avancent prudemment en matière d’agents d’IA. Cette prudence est souvent interprétée comme une résistance au changement. Ce n’est pas le cas. Il s’agit d’un choix mûrement réfléchi. Dans ces secteurs, un échec n’est pas simplement un contretemps. Un échec, c’est un paiement bloqué, un traitement retardé, une panne du réseau électrique.
Pour environ 70% Dans les secteurs à haute sécurité, la sécurité et la confidentialité constituent les principaux obstacles à l'adoption des agents. Il ne s'agit pas d'une peur de la nouveauté, mais d'une perception juste des enjeux.
Historiquement, les logiciels utilisés par les banques, les administrations et toutes les entreprises reposaient sur un principe simple : ces solutions font essentiellement ce qu'on leur demande de faire, et rien de plus. La semaine prochaine, lors de la conférence sur l'IA à San Francisco, j'expliquerai en quoi les agents remettent en cause ce principe.
Les agents peuvent faire ce que vous leur demandez de faire. Mais ils peuvent aussi aller bien au-delà. Cela engendre de nouveaux risques auxquels la plupart des secteurs hautement sécurisés ne sont pas préparés.
L’un des mythes qui freine la mise en place de presque tous les programmes d’agents en phase de démarrage est que la résidence des données équivaut à la souveraineté. La résidence répond à une seule question : où se trouvent les données au repos ? Il suffit de les conserver dans la bonne région, dans le bon cloud et dans le cadre du bon contrat pour respecter les exigences de résidence.
Les agents ne respectent pas cette limite, car ils ne travaillent pas avec des données au repos. Ils les récupèrent, les analysent et agissent en conséquence — de manière indépendante et dynamique. Un modèle hébergé dans une juridiction analyse les données clients provenant d’une autre. Les champs sensibles se retrouvent dans des invites, la mémoire, les journaux et les représentations qui résident en dehors de votre système d’enregistrement. Les données ont été déplacées, et la juridiction de résidence n’a jamais eu son mot à dire sur ce mouvement. C’est là que la souveraineté est réellement compromise.
Nous choisissons des agents pour leur autonomie. Ils agissent sans attendre qu'on leur donne des instructions, et cela a une réelle valeur — en fait, c'est justement l'essentiel.
Mais l'autonomie va de pair avec l'autorité. Un agent capable d'agir en votre nom peut effectuer des virements, accorder des accès, modifier des données ou faire appel à un autre système. La fonctionnalité que vous avez acquise représente désormais le risque que vous encourez.
C'est l'une des raisons pour lesquelles les secteurs fortement réglementés ont raison de faire preuve de prudence quant à la mise en place de services automatisés. En effet, lorsqu'ils le font, ils ne se contentent pas de déployer un outil : ils délèguent un pouvoir. Or, la plupart des organisations n'ont pas bien cerné l'étendue de ce qu'elles ont cédé.
Au cours de cette session, je décompose le problème en quatre points clés. Ceux-ci vont au-delà de la perspective habituelle axée sur les données et l’infrastructure, car un agent ne se limite pas aux données :
Décision : qui contrôle l'issue, à l'heure actuelle ?
Un agent doté d'une autorité et de compétences étendues peut autoriser une action aux conséquences importantes sans intervention humaine. Les chaînes de délégation sont rompues, et il est impossible de prouver qu'une action remonte à une personne responsable. Un contrôle qui existe sur le papier mais qui échoue sous la pression de la latence fonctionne selon le principe « fail open » plutôt que « fail safe ».
Données : que peut l'agent savoir, manipuler et transporter ?
Au-delà de la résidence, il s'agit d'une question de lignée : pouvez-vous expliquer ce que l'agent a vu et ce qu'il a utilisé pour prendre une décision a posteriori ? Une injection rapide peut transformer un document compromis en une instruction d'exfiltration. Sans classification ni minimisation au moment de l'action, les données sensibles circulent sans contrôle.
Infrastructure : où fonctionne-t-elle, et sous quel contrôle ?
Un environnement partagé et multi-locataires n'offre aucune garantie d'isolation juridictionnelle ou physique. L'inférence hébergée dans le cloud peut réintroduire discrètement la même vulnérabilité qu'une organisation pensait avoir résolue grâce au stockage sur site. Les environnements classifiés ne peuvent en aucun cas appeler les API des modèles hébergés, ce qui donne naissance à des solutions de contournement clandestines.
Écosystème : sur quoi d'autre l'agent peut-il exercer une influence, ou par quoi peut-il agir ?
Les agents s'intègrent à des outils et serveurs tiers qui n'ont fait l'objet d'aucune vérification ni d'aucun enregistrement. Un seul outil en aval compromis peut agir en exploitant les privilèges déjà accordés à votre agent. Les agents des partenaires et des fournisseurs héritent de ces accès par transitivité, et il n'existe aucun point central permettant d'appliquer ou de contrôler la conformité aux politiques au sein d'une chaîne d'agents qui s'appellent les uns les autres.
Déployez un agent et vous pourrez les utiliser tous les quatre simultanément, que vous les ayez ou non définis dans votre périmètre.
Les garde-fous au niveau des invites et des modèles sont de nature probabiliste. Ils réduisent la probabilité d’un résultat indésirable ; ils ne fournissent aucune garantie. Les secteurs réglementés ne peuvent pas vérifier ce qui “ n’a probablement pas eu lieu ”. Une mesure de sécurité peut détecter un schéma indésirable connu, mais elle ne permet pas de vérifier l'identité d'un agent, l'endroit où il s'exécute ni ce qu'il est autorisé à faire dans le cadre d'une action inédite.
Une haute assurance implique d’ancrer chaque action dans l’identité. Un agent doit disposer d’une identité vérifiable et d’une autorité délimitée et démontrable, afin que chaque action puisse être rattachée à un acteur connu, à une autorisation connue et à une chaîne vérifiable. L’identité est le point d’ancrage sur lequel reposent les trois autres points de contrôle : contrôler la décision, régir les données, vérifier l’infrastructure et encadrer l’écosystème, le tout par rapport à un acteur que l’on peut réellement identifier. Si l’identité est mal gérée, les trois autres points ne sont que des conjectures.
Avant de laisser un agent agir, vous devriez être en mesure de répondre aux questions suivantes : Qui a autorisé cette action ? Où a-t-elle été exécutée ? À quelles données a-t-elle accès ? Pouvez-vous le prouver ?
Si ces réponses sont claires, cohérentes et vérifiables, vous pouvez avancer rapidement dans le domaine de l’IA tout en réussissant l’audit. Si ce n’est pas le cas, vous ne régissez pas les agents : vous vous contentez d’espérer. La souveraineté est une attitude, pas un certificat. Elle est continue et vérifiable, car les agents agissent en permanence, et un contrôle que vous ne pouvez pas prouver à la demande n’est pas un contrôle.
La souveraineté agentique est la capacité à conserver un contrôle vérifiable sur ce qu’un agent d’IA autonome décide, touche, sur quoi il fonctionne et par quoi il agit — de manière continue et de manière à répondre aux exigences des audits. Contrairement à la souveraineté des données, qui porte sur le lieu où se trouvent les données réside, la souveraineté agentique concerne l'autorité en mouvement : chaque décision prise par un agent fait que et chaque action qu’elle entreprend en votre nom.
Non. La « résidence des données » détermine l'endroit où les données sont stockées au repos. Les agents d'IA traitent les données en mouvement : ils les collectent, les analysent et agissent en conséquence de manière dynamique, souvent au-delà des frontières juridictionnelles et en dehors du système d'enregistrement. La résidence des données ne dit rien de ce mouvement, et c'est précisément là que la souveraineté s'effondre.
En effet, les conséquences d'un échec sont graves — un paiement bloqué, un traitement retardé, une perturbation du réseau — et ne se limitent pas à un simple désagrément. La sécurité et la confidentialité constituent le principal obstacle à l'adoption cité par environ 70% d'organisations soumises à des exigences de sécurité élevées. Cette prudence traduit une bonne compréhension des enjeux, et non une résistance au changement.
Décision (qui contrôle le résultat et si un être humain en est responsable), Données (ce que l'agent peut savoir, stocker, et si leur provenance est traçable), Infrastructure (où il fonctionne et sous quel contrôle), et Écosystème (quels autres outils et agents il peut influencer ou par l'intermédiaire desquels il peut agir). Chaque déploiement d’agent opère simultanément sur ces quatre axes.
Les mesures de sécurité au niveau des invites et des modèles sont de nature probabiliste. Elles réduisent la probabilité d’un résultat indésirable, mais n’offrent aucune garantie, et les secteurs réglementés ne peuvent pas vérifier si un événement “ ne s’est probablement pas produit ”. Une mesure de sécurité peut signaler un schéma indésirable connu, mais ne peut pas attester de l’identité, de l’environnement et de l’autorité d’un agent dans le cadre d’une action inédite.
Une haute fiabilité signifie que chaque action d’un agent repose sur une identité vérifiable et sur une autorité délimitée et démontrable, de sorte qu’elle peut être rattachée à un acteur connu, à une autorisation connue et à une chaîne vérifiable. L’identité est le point d’ancrage ; le contrôle des décisions, des données, de l’infrastructure et de l’écosystème dépend entièrement de la capacité à identifier l’acteur à l’origine d’une action.
Troisièmement : qui a autorisé cela ? Où cela s'est-il exécuté ? Pouvez-vous le prouver ? Si vous êtes capable de répondre à ces trois questions à tout moment et sans hésitation, vous pouvez agir rapidement tout en réussissant l'audit. Si vous n'y parvenez pas, cela signifie que vous ne contrôlez pas l'agent : vous lui faites simplement confiance.
Inclus