Contexte
Le programme GenAI d’ENSO repose sur une plateforme IA partagée et multi-tenant. Elle alimente quatre capacités produit : un assistant de correction des déclarations de paie, l’OCR des feuilles de temps, des assistants intégrés aux produits et un agent autonome de relance de documents. Je suis l’architecte principal. J’ai rédigé l’Architecture Design Document et je pilote son application au sein des équipes via des revues d’architecture, des ADR et des contrôles de conformité.
Problème
Une plateforme IA partagée doit trancher une bonne fois pour toutes, pour tous les produits qui s’y appuient, les mêmes questions : comment les modèles sont accédés, comment les réponses sont fondées sur des sources, ce qu’un agent IA a le droit de faire, comment la qualité est protégée contre les régressions et comment la réglementation est respectée. L’architecture ci-dessous y répond au niveau de la plateforme.
Décisions d’architecture
Une passerelle unique vers les modèles
Tous les accès aux modèles passent par une passerelle IA centrale, chemin d’accès unique à Amazon Bedrock. Elle impose des profils d’inférence limités à l’UE à l’échelle de l’organisation via une service control policy (SCP), applique Bedrock Guardrails pour le filtrage des PII et route les requêtes vers les modèles afin d’isoler les produits des évolutions du cycle de vie des modèles.
Compromis : la passerelle est un composant de plus à exploiter et un chemin unique à garder hautement disponible. En échange, la résidence des données, le filtrage et les changements de modèles sont gouvernés en un seul endroit plutôt que dans chaque produit.
Un RAG qui cite ses sources ou s’abstient
Le RAG s’appuie sur Aurora PostgreSQL avec pgvector, des index HNSW et une recherche hybride avec reranking, derrière une API de recherche que la plateforme maîtrise. Une politique de citations stricte s’applique : chaque réponse cite ses sources ou s’abstient de répondre. L’isolation des tenants est assurée dans la base par Row-Level Security, et non dans le code applicatif.
Compromis : maîtriser l’API de recherche et pousser l’isolation dans PostgreSQL lie la conception à un seul moteur de base de données. Cela rend les garanties testables au niveau des données et offre à chaque produit un contrat de recherche unique.
Des actions d’agents derrière un serveur d’actions MCP unique
Les agents n’agissent sur les systèmes métier que via un serveur d’actions MCP (Model Context Protocol) unique. Les manifestes d’outils sont versionnés, toute écriture exige une validation humaine et les actions portent des contrôles d’idempotence et de préconditions. Un journal de décisions en append-only rend chaque décision de l’IA rejouable, avec un export WORM vers S3 Object Lock.
Compromis : la validation humaine de chaque écriture ralentit par conception les flux totalement autonomes. C’est un choix délibéré : les écritures restent contrôlables, et le journal de décisions permet de rejouer et d’auditer n’importe quel résultat.
Une identité sans élévation de privilèges
L’IA hérite des droits de l’utilisateur à l’origine de la requête via OAuth2 Token Exchange (Keycloak, OIDC), et les workloads utilisent des identités IRSA sur Kubernetes. L’IA peut faire ce que l’utilisateur peut faire, jamais plus.
Compromis : comme les droits suivent l’utilisateur, la portée d’un agent n’est jamais plus large que celle de cet utilisateur. Cela supprime toute une classe de risques d’élévation de privilèges, au prix d’un peu de confort.
Une boucle qualité et observabilité
Des contrôles DeepEval sur jeux de référence bloquent les régressions en CI. Langfuse est auto-hébergé dans le VPC sur EKS pour les traces, les prompts et les retours en ligne. La livraison suit une approche GitOps avec des dark releases pilotées par feature flags.
Compromis : les jeux de référence demandent un travail de curation et auto-héberger Langfuse implique de l’exploiter. En contrepartie, les changements de prompts et de modèles suivent le même pipeline contrôlé que le code, et les données de traces restent dans le VPC.
Une frontière de protocole entre TypeScript et C#
La plateforme est une architecture hybride TypeScript et C# : le runtime d’agents Mastra et les SDK MCP officiels, avec la couture entre les langages placée sur la frontière du protocole MCP. Des tests de contrat et un dépôt de schémas partagé protègent cette couture.
Compromis : deux langages ajoutent de l’outillage et des compétences à maintenir. Placer la couture sur une frontière de protocole garde chaque côté déployable et testable indépendamment, et les tests de contrat détectent tôt les dérives.
RGPD et AI Act dès la conception
La conception garde les données dans l’UE, minimise les données traitées, coordonne le droit à l’effacement entre vecteurs, traces et journaux d’audit, et rend l’usage de l’IA transparent pour les utilisateurs finaux.
Compromis : l’effacement doit atteindre chaque base qui contient des données dérivées, ce qui demande plus de travail que la suppression des données sources. Le concevoir dès le départ coûte moins cher que de le rajouter après coup.
Résultats
Quatre capacités produit tournent sur une plateforme partagée et gouvernée. L’architecture est décrite dans l’Architecture Design Document, et des revues d’architecture, des ADR et des contrôles de conformité l’appliquent au sein des équipes.
Stack
- Amazon Bedrock
- Aurora PostgreSQL
- pgvector
- EKS
- Keycloak
- MCP
- Mastra
- TypeScript
- C#
- DeepEval
- Langfuse