IA agentique : trois architectures sous la loupe, une seule vraiment sous contrôle européen

# IA agentique : trois architectures sous la loupe, une seule vraiment sous contrôle européen

En 2026, l'IA agentique n'est plus un sujet de veille : c'est une réalité opérationnelle. Des agents autonomes pilotent des workflows RH, déclenchent des actions dans vos ERP, lisent vos contrats, arbitrent des escalades. La question n'est plus « faut-il y aller ? » mais « dans quelle architecture vos données circulent-elles — et vers où ? »

Pour un DSI européen, ce n'est pas une question d'innovation. C'est une question de contrôle. Parce qu'un agent IA, par définition, agit. Il appelle des API, lit des fichiers, envoie des requêtes. Chaque action est un vecteur de fuite potentielle si l'architecture n'a pas été pensée avec rigueur.

Ce comparatif examine trois approches architecturales concrètes — non trois produits, mais trois logiques de déploiement — sur quatre critères techniques : localisation du traitement, gouvernance des accès, réversibilité, et surface d'exposition réglementaire.

Les trois architectures en présence

Architecture A — Agent cloud natif US (modèle dominant actuel)

L'agent est hébergé et exécuté sur l'infrastructure de l'acteur américain. Le modèle LLM, l'orchestrateur, les connecteurs et les logs d'activité résident tous dans des datacenters sous juridiction américaine ou soumis au Cloud Act. L'entreprise cliente configure des permissions, mais ne maîtrise pas où les données transitent lors de l'inférence.

Architecture B — Agent hybride avec enclave souveraine

L'orchestration agentique est déployée sur une infrastructure européenne certifiée (SecNumCloud ou équivalent national), mais le modèle LLM sous-jacent peut rester un modèle américain accessible via API. Les données métier ne quittent pas le périmètre européen : seules des requêtes anonymisées ou synthétiques sont envoyées vers le modèle externe.

Architecture C — Stack agentique entièrement sur site ou cloud souverain

L'agent, le modèle, l'orchestrateur et les connecteurs sont déployés dans un environnement entièrement maîtrisé : on-premise ou cloud souverain européen. Aucune dépendance à une API externe pour l'inférence. Le modèle est open-weight, affiné en interne ou par un prestataire européen.

Critère 1 — Localisation réelle du traitement

| Critère | Architecture A | Architecture B | Architecture C |

|---|---|---|---|

| Localisation du modèle | Datacenter US / Cloud Act | API externe, données locales | On-premise / cloud souverain EU |

| Données métier lors de l'inférence | Envoyées vers serveurs US | Anonymisées avant envoi | Ne quittent pas le SI |

| Logs d'activité agentique | Hébergés chez l'éditeur US | Hébergés en EU | Sous contrôle total |

| Garantie contractuelle de non-rétention | Clause à vérifier contrat par contrat | Partielle | Totale |

Ce que ça change concrètement : En architecture A, chaque prompt envoyé par l'agent — y compris ceux contenant des extraits de contrats, des données RH ou des éléments financiers — transite par une infrastructure soumise au Cloud Act. Même si l'éditeur américain garantit contractuellement la non-rétention des données, cette garantie reste inopposable à une injonction fédérale américaine. Pour les secteurs sous RGPD strict, NIS2 ou réglementation sectorielle (banque, santé, défense), c'est un risque juridique documenté, pas hypothétique.

L'architecture B réduit cette surface sans l'éliminer : si le modèle US reçoit des fragments de données, même pseudonymisés, la chaîne de responsabilité reste complexe à auditer.

L'architecture C est la seule qui ferme structurellement ce vecteur.

Critère 2 — Gouvernance des accès et des permissions agentiques

Un agent IA n'est pas passif. Il dispose de permissions pour agir : lire des fichiers, déclencher des workflows, appeler des API internes. La gouvernance de ces permissions est un sujet de sécurité à part entière — distinct de la gouvernance des données.

| Critère | Architecture A | Architecture B | Architecture C |

|---|---|---|---|

| Définition des permissions agentiques | Interface éditeur, policies propriétaires | Interface éditeur + règles locales | Définie et auditée en interne |

| Audit des actions de l'agent | Logs partiels accessibles, format propriétaire | Logs exportables en EU | Logs complets, format ouvert |

| Révocation d'accès en cas d'incident | Dépend du SLA éditeur | Mixte | Immédiate, sans dépendance tierce |

| Intégration avec IAM existant (LDAP, AD) | Variable selon éditeur | Partielle | Native |

Ce que ça change concrètement : En architecture A, la politique de permissions de l'agent est définie dans l'interface propriétaire de l'éditeur américain. Si celui-ci modifie son modèle de permissions suite à une mise à jour — ce qui s'est produit plusieurs fois en 2025 avec des acteurs majeurs —, votre RSSI doit reconfigurer l'ensemble des accès en suivant une logique qu'il ne contrôle pas. C'est un vecteur de glissement silencieux des droits.

L'architecture C permet d'intégrer la gouvernance agentique directement dans le référentiel IAM existant de l'entreprise. L'agent devient un acteur du SI comme un autre, soumis aux mêmes politiques d'accès, auditables avec les mêmes outils.

Critère 3 — Réversibilité et portabilité

Le verrouillage sur l'IA agentique est plus profond que sur un SaaS classique. Un agent s'intègre dans les processus métier, crée des dépendances fonctionnelles, génère des historiques d'actions. Sortir d'un fournisseur agentique en 2026, c'est potentiellement reconfigurer des dizaines de workflows.

| Critère | Architecture A | Architecture B | Architecture C |

|---|---|---|---|

| Format des workflows agentiques | Propriétaire | Semi-ouvert (selon éditeur) | Standard ouvert (OpenAI function calling spec, MCP, etc.) |

| Portabilité des historiques d'actions | Dépendante de l'API éditeur | Exportable partiellement | Complète |

| Dépendance au modèle spécifique | Forte (fine-tuning éditeur) | Moyenne | Faible (modèle substituable) |

| Coût de migration estimé | Élevé | Modéré | Faible |

Ce que ça change concrètement : L'un des acteurs américains dominants sur l'IA agentique en entreprise a introduit en 2025 un format d'orchestration propriétaire qui rend les workflows non portables vers d'autres environnements sans réécriture complète. C'est le même mécanisme que le vendor lock-in applicatif des années 2000 — mais appliqué à de la logique métier automatisée. Le MCP (Model Context Protocol), poussé comme standard ouvert, est une réponse partielle, mais son adoption reste inégale selon les éditeurs.

L'architecture C, construite sur des standards ouverts et des modèles open-weight, préserve la capacité à changer de modèle, d'orchestrateur ou d'infrastructure sans tout reconstruire.

Critère 4 — Surface d'exposition réglementaire

L'IA Act européen, entré en application progressive depuis 2025, impose des exigences de traçabilité, d'explicabilité et de registre des systèmes d'IA pour les cas d'usage à risque. Les agents autonomes agissant sur des décisions RH, financières ou contractuelles entrent dans les catégories à risque élevé.

| Critère | Architecture A | Architecture B | Architecture C |

|---|---|---|---|

| Traçabilité des décisions agentiques | Dépend de l'éditeur | Partielle, exportable | Complète, auditée en interne |

| Documentation technique requise par l'IA Act | À fournir par l'éditeur US (délais variables) | Partagée | Sous contrôle total |

| Registre des systèmes d'IA | Difficile à alimenter sans accès logs | Possible | Native |

| Responsabilité en cas de décision erronée | Ambiguïté contractuelle | Clarifiée partiellement | Clairement interne |

Ce que ça change concrètement : Si votre agent agentique prend une décision de refus de crédit, de sélection de fournisseur ou d'escalade RH, vous êtes responsable devant la réglementation européenne — pas l'éditeur américain. Or, en architecture A, obtenir la traçabilité complète de la chaîne de décision de l'agent pour un audit réglementaire nécessite de passer par l'API de l'éditeur, selon son calendrier et ses formats. Plusieurs entreprises européennes ont découvert cette réalité lors des premiers contrôles IA Act en 2025.

Ce que le DSI doit arbitrer

L'architecture A reste la plus rapide à déployer et la plus riche fonctionnellement à court terme. C'est précisément pour cela qu'elle est dangereuse : elle crée une dépendance profonde avant que les équipes techniques aient eu le temps d'en mesurer les implications.

L'architecture B est le compromis pragmatique pour les organisations qui ne peuvent pas encore déployer une stack entièrement souveraine : elle réduit la surface d'exposition sans renoncer aux capacités des grands modèles. Mais elle exige une ingénierie sérieuse de l'anonymisation — et une vigilance constante sur les évolutions contractuelles de l'API externe.

L'architecture C est la seule qui garantit la maîtrise complète. Elle exige un investissement en compétences internes ou en prestataires européens spécialisés, et un modèle open-weight suffisamment performant pour le cas d'usage visé. En 2026, cette condition est de plus en plus souvent remplie pour les usages métier courants.

Le vrai risque n'est pas de choisir la mauvaise architecture aujourd'hui. C'est de déployer des agents en architecture A sans l'avoir choisi consciemment — et de se retrouver dans deux ans avec des processus métier entiers dépendants d'une infrastructure sur laquelle vous n'avez aucun levier.