Une plateforme IA d’entreprise est le socle partagé qui permet à plusieurs produits d’utiliser des modèles de langage sans que chacun ne résolve à nouveau la sécurité, l’ancrage des réponses, le contrôle et la qualité. Elle comporte cinq couches : une passerelle IA pour l’accès aux modèles, une recherche qui cite ses sources, une couche d’actions contrôlée pour les agents, l’évaluation et l’observabilité, et enfin l’identité avec le multi-tenant et la conformité. Ce guide décrit chaque couche, l’ordre pour les construire et les erreurs qui coûtent le plus cher.

Pourquoi une plateforme plutôt qu’une intégration par produit

La première fonctionnalité IA d’une entreprise est souvent une intégration directe avec un fournisseur de modèles, et elle fonctionne. La deuxième et la troisième la copient. À la cinquième, il existe cinq façons de choisir un modèle, cinq façons de traiter les données personnelles, cinq réponses à « d’où viennent les réponses ? » et aucun endroit où changer quoi que ce soit.

Une plateforme transforme ces décisions de choix produit en choix de plateforme. Les produits dépendent d’un contrat réduit et stable. L’organisation dispose d’un endroit unique pour appliquer la politique, observer l’usage et améliorer la qualité, et un changement de modèle cesse d’être un projet.

Couche 1 : la passerelle IA

Chaque appel à un modèle de fondation passe par un service unique. La passerelle impose la résidence des données (par exemple des profils d’inférence limités à l’UE sur Amazon Bedrock), filtre les données personnelles avec des garde-fous et route chaque capacité vers un modèle concret, de sorte que les produits demandent « résumer » ou « extraire » au lieu de nommer un modèle. Une politique au niveau du compte couvre le trafic qui contourne la passerelle. Le détail est dans le guide de la passerelle IA.

Couche 2 : une recherche qui cite ses sources

La génération augmentée par recherche ne gagne la confiance que si les réponses portent des citations et que le système s’abstient quand il n’en a pas. Gardez la recherche derrière une API que la plateforme maîtrise, faites de la recherche hybride avec reranking, stockez les embeddings à côté des données relationnelles (PostgreSQL avec pgvector est un bon choix par défaut) et assurez l’isolation des tenants dans la base avec Row-Level Security. Le contrat et ses limites sont traités dans le guide RAG.

Couche 3 : des actions d’agents sous contrôle

Lire présente peu de risques ; écrire, si. Faites passer toutes les actions des agents par un serveur d’actions MCP unique, avec des manifestes d’outils versionnés, une validation humaine de chaque écriture, l’idempotence et les préconditions, et un journal de décisions en append-only. L’agent ne détient aucun droit propre : il agit avec les droits de l’utilisateur à l’origine de la demande. Voir le guide des actions d’agents.

Couche 4 : évaluation et observabilité

Une application à base de modèles de langage change dès qu’un prompt, un modèle ou un réglage de recherche change. La qualité doit donc être mesurée à chaque changement : jeux de référence, contrôles d’évaluation en CI et traces des appels en production qui alimentent les jeux. La méthode est décrite dans le guide de l’évaluation.

Couche 5 : identité, multi-tenant et conformité

L’identité relie les couches entre elles. Les utilisateurs s’authentifient une fois, la plateforme échange leur jeton contre des jetons restreints en aval, les workloads utilisent des identités cloud de courte durée et les tenants sont isolés dans la couche de données. La conformité se conçoit dès le départ au lieu d’être auditée après coup : résidence des données, minimisation, effacement et transparence pour le RGPD, et obligations de l’AI Act qui s’appliquent au cas d’usage.

L’ordre pour la construire

Commencez par la passerelle : elle est petite, elle supprime le plus de travail dupliqué et elle fournit des données d’usage. Ajoutez ensuite la recherche, car la plupart des premiers cas d’usage demandent des réponses ancrées. Mettez l’évaluation en place avant la livraison du troisième produit, pas après le premier incident. Introduisez les actions d’agents en dernier, et seulement une fois l’identité et le journal de décisions en place, car un agent capable d’écrire sans eux est ce qu’il y a de plus risqué à déployer.

Erreurs à éviter

  • Une plateforme que personne n’a demandée. Construisez d’abord la couche dont un vrai produit a besoin, puis généralisez.
  • Une passerelle qui devient un goulot d’étranglement. Gardez son contrat réduit et stable, et rendez-la hautement disponible.
  • Une politique seulement dans les prompts. Appliquez les règles dans le code et l’infrastructure (contrôles de citations, politiques de base de données, contrôles au niveau du compte), car on peut contourner un prompt.
  • Pas d’évaluation avant que quelque chose casse. Sans jeu de référence, chaque amélioration est une opinion.
  • Des agents avec leurs propres privilèges. Un agent ne doit jamais pouvoir faire ce que l’utilisateur ne peut pas faire.

En pratique

Sur la plateforme partagée et multi-tenant d’ENSO, j’ai conçu ces couches ensemble : une passerelle IA centrale sur Amazon Bedrock, un RAG sur Aurora PostgreSQL avec pgvector derrière une API de recherche maîtrisée, des actions d’agents via un serveur d’actions MCP unique avec validation humaine, des contrôles d’évaluation en CI et l’identité via Keycloak et OAuth2 Token Exchange. La plateforme alimente quatre capacités produit. Le cas complet est dans l’étude de cas ENSO, et les services qui s’y rattachent sont décrits sur la page plateforme LLM d’entreprise.

Compromis et limites

Une plateforme est un investissement qui paie avec le deuxième et le troisième produit, pas avec le premier. Elle ajoute des services à exploiter et une équipe ou un rôle pour les porter. Un produit unique avec un modèle unique n’en a peut-être pas encore besoin. La centralisation concentre aussi le risque : la passerelle et l’API de recherche doivent être fiables, et il leur faut un responsable qui suive les besoins des produits qui en dépendent.