Agents IA autonomes dans le SI : une ETI industrielle européenne face au vide juridique et technique qui l'entoure

Agents IA autonomes dans le SI : une ETI industrielle européenne face au vide juridique et technique qui l'entoure

Au printemps 2025, une ETI industrielle de 800 salariés — fabricant de composants mécaniques de précision implanté en Europe centrale, client historique d'une suite collaborative américaine — a décidé de franchir un cap. Après une phase pilote conduite par son équipe IT, elle a commencé à déployer des agents IA capables d'agir de façon semi-autonome : planification de commandes fournisseurs, traitement de demandes internes RH, extraction et synthèse de données techniques issues de la GMAO. Douze mois plus tard, son DSI tire un bilan que l'on pourrait qualifier de lucide.

L'expérience n'a pas échoué. Mais elle a révélé quelque chose que ni les brochures commerciales ni les architectures Zero Trust existantes n'avaient anticipé : un agent IA autonome n'est pas un utilisateur. Ce n'est pas non plus une application. C'est une entité hybride, capable d'initier des actions, de traverser des périmètres, de consommer des API, de stocker des états intermédiaires — et de le faire sans qu'un humain valide chaque geste.

Ce que le Zero Trust ne couvre pas encore

Le modèle Zero Trust, dont l'ETI avait posé les fondations entre 2022 et 2024 — segmentation réseau, vérification continue des identités, politique de moindre privilège — repose sur un postulat central : il y a toujours un humain derrière une action. Ou du moins une application dont le périmètre est connu, stable, auditable.

Les agents IA cassent ce postulat. Lors du pilote, l'équipe IT a constaté que certains agents, déployés via une plateforme d'orchestration tierce hébergée hors UE, généraient des appels API vers des services internes selon une logique que les outils de supervision existants peinaient à qualifier. Non pas parce que ces appels étaient malveillants — ils ne l'étaient pas — mais parce qu'ils sortaient du cadre comportemental attendu. Un agent chargé de consolider des données de stock pouvait, selon le contexte de sa session, solliciter des endpoints que l'équipe n'avait pas explicitement ouverts dans la politique IAM. Pas une faille. Plutôt une zone grise fonctionnelle que le Zero Trust classique n'avait pas été conçu pour adresser.

La question posée concrètement au RSSI était simple : comment attribuer une identité stable, auditée, révocable à une entité qui n'est ni un compte utilisateur ni un service applicatif au sens traditionnel ?

Le problème de la provenance des modèles

C'est là que la dimension souverainiste du sujet cesse d'être rhétorique pour devenir opérationnelle.

Les agents déployés dans l'ETI s'appuyaient, pour leur couche de raisonnement, sur des modèles de fondation accessibles via API — hébergés hors du territoire européen, soumis à des conditions d'utilisation régies par le droit américain. Chaque requête envoyée par un agent pour « décider » d'une action contenait potentiellement des fragments de données internes : références fournisseurs, libellés de pièces, contenus de tickets RH anonymisés mais reconnaissables.

L'ETI n'avait pas réalisé, au moment du pilote, que l'agent n'était pas simplement un outil d'automatisation local. C'était un pipeline de traitement dont une partie critique — l'inférence — se déroulait dans une infrastructure que l'entreprise ne contrôlait pas, ne pouvait pas auditer, et dont elle ne maîtrisait pas les sous-traitants.

Le RGPD posait déjà une contrainte connue. L'AI Act européen, applicable depuis début 2026, en posait une nouvelle, moins bien comprise des équipes IT : pour certaines catégories d'usages autonomes à impact sur les décisions RH ou opérationnelles, la traçabilité du système d'IA — y compris de l'infrastructure d'inférence — devient une exigence de conformité, pas une option d'architecture.

C'est ce point qui a conduit le DSI à stopper le déploiement en production pendant plusieurs semaines, le temps de requalifier l'architecture.

Ce que l'équipe IT a dû réapprendre

Concrètement, la reconfiguration a porté sur trois axes — non pas comme une liste de solutions, mais comme une réorientation de posture.

Premier axe : l'identité des agents. L'équipe a dû créer un référentiel spécifique pour les entités non-humaines autonomes. Chaque agent s'est vu attribuer une identité machine distincte, avec des droits bornés dans le temps, révocables à la demande, traçés dans le SIEM. Ce travail, qui semble technique, a en réalité exigé une conversation entre l'IT, le métier et le DPO : qui est responsable de ce que fait un agent ? Qui valide l'extension de ses droits ? La réponse n'était pas dans les outils. Elle était dans la gouvernance.

Deuxième axe : la localisation de l'inférence. L'ETI a exploré — sans le mettre en œuvre immédiatement — le remplacement partiel du modèle d'inférence distant par une solution déployable sur son infrastructure hébergée en Europe. Elle a identifié des acteurs proposant des modèles optimisés pour un déploiement on-premise ou sur cloud souverain européen. Le critère n'était pas la performance brute du modèle, mais la capacité à garantir que les données traitées par l'agent ne quittent pas un périmètre contractuellement et juridiquement maîtrisé. À la date de rédaction, ce chantier est en cours : l'ETI n'a pas encore arrêté son choix, mais le cahier des charges exclut explicitement les fournisseurs dont l'infrastructure principale est soumise au Cloud Act américain.

Troisième axe : la supervision comportementale des agents. L'équipe IT a dû admettre que ses outils de monitoring existants — conçus pour surveiller des flux réseau et des comportements utilisateurs — étaient mal adaptés à la surveillance d'agents IA. Un agent peut produire un comportement « normal » selon les métriques réseau tout en prenant des décisions fonctionnellement aberrantes. La supervision a dû intégrer une couche sémantique : pas seulement « cet agent a appelé telle API », mais « cet agent a pris telle décision dans tel contexte, et cette décision est-elle cohérente avec sa mission définie ? ». C'est un domaine encore largement ouvert, où les solutions disponibles sur le marché européen restent peu matures.

Ce que ce cas dit aux équipes IT en 2026

Ce retour terrain ne doit pas être lu comme un argument contre les agents IA. L'ETI concernée a maintenu son projet. Les gains de productivité sur les processus pilotés restent réels et mesurables.

Mais il dit quelque chose d'important sur la nature du travail des équipes IT en 2026 : la frontière entre sécurité, conformité et souveraineté des données est en train de se resserrer autour des décisions d'architecture que les DSI et RSSI prennent aujourd'hui. Un choix de plateforme d'orchestration d'agents IA n'est plus un choix technique parmi d'autres. C'est un choix qui engage la maîtrise du SI pour plusieurs années, dans un contexte réglementaire européen qui va continuer à se préciser.

Le modèle Zero Trust reste pertinent. Mais il a été pensé pour un SI dont les acteurs étaient connus, typés, stables. Les agents IA autonomes introduisent une dynamique que les architectures de sécurité européennes doivent maintenant absorber — non pas en ajoutant une couche de plus, mais en revisitant le postulat de base : qui agit dans mon système, et au nom de qui ?

Cette question, les acteurs américains dominants ont déjà leur réponse — intégrée dans leurs plateformes, packagée dans leurs licences, gouvernée par leur droit. La réponse européenne, elle, reste à construire. Et c'est précisément là que se joue la marge de manœuvre des DSI qui veulent encore en avoir une.