Quelle infrastructure pour déployer des agents IA en production avec accès aux données d'entreprise ?

Il y a un moment précis dans chaque programme IA d'entreprise où la question passe de « est-ce que l'agent fonctionne ? » à « de quoi a-t-on besoin pour que ça tourne sur de vraies données corporate sans se faire virer ? » La réponse est un stack — huit couches, chacune avec un rôle précis, chacune non-négociable quand des données sensibles sont en jeu.

Cet article cartographie ce stack. Chaque section décrit ce que fait la couche, pourquoi l'accès aux données d'entreprise élève le niveau d'exigence, et quels composants concrets doivent être en place avant la première requête en production.

Ce que « accès aux données d'entreprise » signifie vraiment

Avant de lister l'infrastructure, définissons le problème. L'accès aux données d'entreprise implique typiquement au moins trois des éléments suivants :

• L'agent lit depuis des systèmes de référence : CRM, ERP, ticketing, code, documents, data warehouses.

• Les données sont multi-tenant ou contiennent des PII, données de santé, données financières ou secrets industriels.

• L'agent peut écrire — créer des tickets, mettre à jour des enregistrements, envoyer des messages au nom d'un utilisateur.

• L'accès est régi par des permissions par utilisateur qui varient d'un système à l'autre.

• Le déploiement est soumis à SOC 2, ISO 27001, RGPD, AI Act européen, ou une réglementation sectorielle.

Chacun de ces points ajoute des exigences sur l'infrastructure. Un assistant en lecture seule sur des docs publiques, c'est un stack. Un agent qui met à jour des fiches Salesforce au nom d'un commercial, en respectant les permissions réelles de ce commercial, c'est un tout autre stack.

Le stack de référence, de bout en bout

Huit couches, de la fondation au sommet : 1) Compute & réseau, 2) Model gateway, 3) Runtime d'agent, 4) Couche outils & intégrations, 5) Data plane, 6) Identité & accès, 7) Observabilité & évaluation, 8) Gouvernance & politiques. Lisez dans l'ordre — chaque couche supérieure suppose que les précédentes sont en place.

1. Compute et réseau

La couche de base est peu glamour mais définit ce qui est possible au-dessus.

Compute. Conteneurs ou fonctions serverless, orchestrés par Kubernetes, ECS, Cloud Run, Vercel Workflows ou équivalent. Les agents sont intermittents et long-running — il faut une plateforme qui gère les deux profils.

Réseau. Réseau privé par défaut. Le runtime de l'agent est dans un VPC sans ingress public sauf via votre API gateway applicatif. L'egress passe par un proxy contrôlé avec une allowlist de providers de modèles, services d'outils et sources de données.

Région. Pour les clients européens, attendez-vous à une exigence de déploiement EU-only sans egress de données vers les États-Unis. Choisissez un cloud et une région par géographie réglementée que vous servez.

Secrets. Un vrai gestionnaire de secrets — Vault, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault. Credentials à durée de vie courte, rotation automatisée, audit sur chaque récupération.

2. Model gateway

La pièce d'infrastructure la plus stratégique pour les agents d'entreprise. Le gateway se place entre chaque ligne de code agent et chaque provider de modèle.

Ce qu'il doit faire :

• Interface uniforme entre les providers (Anthropic, OpenAI, Google, Mistral, Cohere, AWS Bedrock, Azure AI Foundry, modèles self-hosted).

• Retries avec idempotence, fallback vers un provider secondaire en cas de panne.

• Clés API et quotas par tenant, exposés dans votre système de facturation.

• Prompt caching appliqué automatiquement sur le contexte stable.

• Logs structurés avec rédaction de PII au moment de l'écriture.

• Calcul de coût par appel, exposé comme métrique et comme ledger par tenant.

• Pinning régional pour qu'une requête d'un tenant EU ne fuite pas vers une région US.

Les options en 2026 vont de l'open source (LiteLLM, Portkey OSS) au managé (Portkey, Helicone, AWS Bedrock Gateway, Azure AI Foundry, o137 pour les déploiements européens), jusqu'aux builds internes pour les organisations avec des mandats de sécurité stricts.

3. Runtime d'agent (orchestration durable)

Les agents d'entreprise doivent survivre aux déploiements, pannes de nœuds et tâches longues. Le runtime est un moteur de workflow durable, pas un handler de requêtes.

• Temporal — le plus déployé à l'échelle entreprise, SDKs multi-langages, outillage opérationnel mature.

• Inngest — TypeScript-first, s'intègre bien aux plateformes serverless.

• Restate — plus récent, promesses durables et état SQL-backed, léger.

• AWS Step Functions — quand vous voulez rester dans AWS sans charge opérationnelle supplémentaire.

• LangGraph avec checkpoints persistés — si votre équipe est déjà dans l'écosystème LangChain.

Le runtime doit : persister chaque étape pour reprise après crash, imposer des budgets de steps (max steps, max tokens, max durée, max coût), émettre une trace complète de chaque transition d'état, supporter le replay pour le debug et l'évaluation, et fournir des contrôles de concurrence par tenant.

4. Couche outils et intégrations

C'est là que l'agent rencontre les systèmes d'entreprise — et là que la plupart des failles de sécurité prennent leur source.

Model Context Protocol (MCP). Un protocole uniforme pour exposer des outils à l'agent, avec découverte de capacités, schémas typés et sémantique d'auth cohérente. MCP est devenu le standard de facto fin 2025 pour l'interopérabilité d'outils cross-vendor.

Exécution sandboxée. Les outils tournent dans leurs propres processes ou conteneurs. Les outils d'exécution de code tournent dans des sandboxes éphémères — Modal, E2B, Daytona, ou des setups Firecracker internes.

Credentials scopés. L'agent ne détient jamais la session brute de l'utilisateur. Un service d'échange de tokens émet des credentials à durée de vie courte et scopés pour chaque appel d'outil — typiquement OAuth 2.0 token exchange (RFC 8693) ou workload identity federation.

Clés d'idempotence. Chaque outil à effet de bord accepte une clé d'idempotence pour que les retries ne dupliquent pas les écritures.

Log d'audit. Chaque appel d'outil enregistré avec l'identité de l'appelant, les permissions scopées, les entrées, sorties et résultat — immutable, conservé selon votre régime de conformité.

5. Data plane

La couche la plus difficile à bien construire. L'accès aux données d'entreprise se divise en trois sous-systèmes.

Retrieval

Une combinaison de recherche vectorielle et de recherche par mots-clés (retrieval hybride) sur une base de connaissances de documents, code, tickets et enregistrements structurés.

• Vector store. Qdrant, Pinecone, Weaviate, pgvector, Vespa. Isolation logique ou physique par tenant. Embeddings versionnés avec le modèle qui les a produits.

• Index keyword/BM25. OpenSearch, Elasticsearch, ou full-text Postgres. La recherche hybride surpasse systématiquement le vector-only sur du contenu d'entreprise.

• Pipeline d'indexation. Fiable, incrémental, avec capacité de backfill. Surveille les systèmes de référence (SharePoint, Confluence, Notion, GitHub, Jira, Salesforce) et reflète les changements dans un SLA documenté.

• Retrieval permission-aware. L'exigence la plus sous-estimée. Les chunks récupérés doivent respecter les permissions de l'utilisateur dans le système source. La solution : attacher les ACL à chaque chunk et filtrer au moment de la requête.

Mémoire

• Store dédié (Postgres, service de mémoire spécialisé) avec des chemins d'écriture explicites.

• TTL par utilisateur et par tenant.

• Historique auditable des écritures et suppressions.

• Support du droit à l'oubli qui se propage aux traces et au retrieval.

État de session

• Store rapide avec TTL (Redis, DynamoDB, Postgres avec TTL).

• Cloisonné par tenant.

• Chiffré au repos avec des clés par tenant pour les déploiements très sensibles.

6. Identité et accès

L'accès aux données d'entreprise tient ou tombe sur l'identité.

• SSO. SAML ou OIDC contre l'IdP du client (Okta, Entra ID, Google Workspace, Ping). Pas de logins standalone.

• Provisioning SCIM. Utilisateurs et groupes synchronisés depuis l'IdP pour que les permissions restent à jour.

• RBAC et ABAC. Rôles et attributs qui pilotent ce que chaque utilisateur peut faire et voir. Frameworks : Cedar, OPA, Oso.

• Authentification on-behalf-of. Quand l'agent appelle un outil, l'appel porte l'identité de l'utilisateur, pas un compte de service générique.

• Identité service-to-service. Les services internes s'authentifient entre eux avec workload identity (SPIFFE/SPIRE, IAM cloud-native, mTLS).

• Audit. Chaque authentification, décision d'autorisation et émission de credential on-behalf-of est loggée.

7. Observabilité et évaluation

Le niveau d'exigence entreprise est plus élevé que pour les agents grand public.

• Tracing distribué. OpenTelemetry avec les conventions sémantiques GenAI. Chaque span inclut modèle, tokens, coût, appels d'outils, tenant, utilisateur, version de l'agent.

• Logging structuré. Rédaction au moment de l'écriture. Logs séparés des traces pour des politiques de rétention différentes.

• Métriques. Métriques SRE standard plus agent-specific : coût par tâche réussie, score d'éval dans le temps, taux d'échec des outils, taux de prompt cache hit.

• Pipeline d'éval. Un set de test figé tourne en CI à chaque changement. Le trafic production est échantillonné et scoré.

• Replay. N'importe quelle trace passée peut être rejouée contre un nouveau modèle ou prompt.

• Intégration SIEM. Pour les industries réglementées, traces et logs d'audit envoyés vers le SIEM du client (Splunk, Sumo Logic, Microsoft Sentinel).

8. Gouvernance et politiques

La couche du sommet est celle qui rend le système lisible pour la conformité, le juridique et les achats.

• Policy as code. Règles sur ce que l'agent peut et ne peut pas faire — quelles données il accède, quelles actions nécessitent une approbation — exprimées dans un moteur de politiques (OPA, Cedar) et versionnées.

• Surface human-in-the-loop. Une inbox de décisions d'agent en attente pour les actions à haut risque, avec approve, reject et edit.

• Content safety. Classifieurs d'entrée et de sortie pour PII, secrets, patterns d'injection de prompt et contenu interdit.

• DPA et registre de sous-traitants. Chaque provider de modèle, vector database, vendor d'observabilité listé dans vos accords de sous-traitance.

• Runbook d'incident. Procédures documentées pour : détection d'injection de prompt, suspicion de fuite de données, panne de provider, dérapage de coûts, régression d'éval. Testé au moins deux fois par an.

Le stack minimum enterprise-ready

Si vous n'avez le temps et le budget que pour le minimum viable :

1. Compute déployé en VPC avec egress contrôlé

2. Model gateway avec clés par tenant, retries et rédaction de PII

3. Runtime de workflow durable avec budgets de steps

4. Couche outils style MCP avec schémas typés, sandboxing et credentials scopés

5. Retrieval permission-aware sur vos trois sources de données principales

6. SSO + SCIM + authentification on-behalf-of

7. Traces OpenTelemetry avec attribution par tenant + suite d'évals en CI

8. Moteur de politiques + human-in-the-loop pour les actions à haut risque + rétention des logs d'audit

Huit composants. Chacun est un vrai effort d'ingénierie, mais ensemble ils constituent ce qui rend un agent vendable à une entreprise.

Combien de temps pour mettre ça en place ?

Pour une équipe focalisée avec une expérience SaaS enterprise : trois à six mois de zéro au premier client enterprise en production, selon la maturité de la fondation existante (SSO, VPC, secrets, CI).

Pour une équipe qui construit tout de zéro : neuf à douze mois est réaliste. Sauter des couches pour comprimer le planning signifie généralement les reconstruire sous pression six mois plus tard, quand le premier client enterprise demande un rapport SOC 2.

Questions fréquentes

Peut-on déployer ce stack dans le VPC d'un client ?

Oui — et on vous le demandera. La plupart des procurements enterprise en 2026 attendent soit un SaaS multi-tenant avec preuves d'isolation solides, soit un déploiement single-tenant dans un compte cloud dédié, soit un déploiement dans le VPC du client. Concevez le stack pour que chaque couche puisse tourner dans l'environnement du client.

Comment respecter les permissions par utilisateur à travers plusieurs systèmes ?

Deux patterns courants. Le premier est le retrieval permission-aware : attacher l'ACL du système source à chaque chunk indexé et filtrer au moment de la requête. Le second est de requêter le système source via son API avec le token on-behalf-of de l'utilisateur, acceptant une latence plus élevée en échange de permissions toujours fraîches. La plupart des systèmes en production combinent les deux.

Faut-il une vector database dédiée ou Postgres + pgvector suffit ?

Pour la plupart des déploiements enterprise, Postgres + pgvector gère confortablement jusqu'à des dizaines de millions de vecteurs et simplifie drastiquement l'opérationnel (une seule base, un seul backup, un seul modèle de contrôle d'accès). Passez à un vector store dédié quand vous dépassez ses capacités ou quand vous avez besoin de fonctionnalités comme la réplication multi-tenant.

Comment MCP s'intègre dans ce stack ?

MCP standardise la couche outils et intégrations. Au lieu d'écrire des adaptateurs custom pour chaque système d'entreprise, vous consommez des serveurs MCP (fournis par les vendors ou construits en interne) avec un protocole uniforme. C'est désormais la manière standard d'exposer des outils d'entreprise aux agents.

En conclusion

L'accès aux données d'entreprise élève le niveau d'exigence à chaque couche du stack, pas seulement au niveau du modèle. L'agent qui est livré à un client du CAC 40 en 2026 est principalement de l'infrastructure : le modèle est une dépendance dans un système conçu pour l'identité, l'audit et l'isolation dès la première ligne de code. Construisez les huit couches correctement et la question cesse d'être « est-ce que l'agent est prêt pour la production » pour devenir « quel client enterprise on onboarde ensuite ».