Combien de fois faut-il reconstruire un produit avant de comprendre ce qui casse vraiment ? En avril 2026, Forrester a envoyé les questionnaires formels de son évaluation du marché agent control plane : 40 % des acheteurs enterprise ont déjà des appels d’offres qui demandent explicitement cette couche. Pendant ce temps, des équipes produit reconstruisent leur SaaS IA pour la troisième ou quatrième fois, en changeant de modèle LLM, en réécrivant leurs system prompts. Certains migrent vers Anthropic ou vers Gemini 2.5 en cours de route. Le chantier recommence et les mêmes points cassent aux mêmes endroits.
La couche de contrôle, ce plan de supervision centralisé qui inventorie et gouverne les agents, est absente de la plupart des architectures SaaS IA. Les équipes connaissent le problème. Elles pensent y revenir une fois l’urgent réglé, ce qui n’arrive presque jamais.
Pourquoi les SaaS IA se reconstruisent en boucle
Un produit IA arrive en prod. Les premiers clients signent. Puis une mise en contexte folle entre tenants, un agent qui boucle sur lui-même et vide le budget token en 20 minutes, un log introuvable quand un output part en vrille. L’équipe patche. Quelques mois plus tard, même incident, autre workflow.
GPT-5 ne résout pas l’absence de traçabilité. Claude Opus 4.7 ne règle pas l’isolation des contextes entre clients. Ce que OneReach.ai documente dans son analyse des systèmes agentiques enterprise est précis : la mise à l’échelle d’un produit IA casse systématiquement aux mêmes quatre points, l’auditabilité (aucun log des décisions agent), la multi-tenancy (fuite de contexte entre comptes clients), l’observabilité (les hallucinations ne se débuggent pas) et le coût (les boucles d’orchestration drainent les tokens). Ces quatre points n’ont pas de correctif au niveau du modèle.
Ce que les équipes reconstruisent à chaque itération
Le pattern est documentable. La version 1 est un wrapper autour d’un LLM avec un system prompt long. La version 2 ajoute du RAG pour réduire les hallucinations. La version 3 découpe en agents spécialisés avec tool use. La version 4 tente de gérer l’orchestration entre agents. À partir de la version 5, l’équipe reconstruit l’infrastructure de gouvernance qu’elle aurait dû poser en version 1.
Chaque itération contient la précédente. Le modèle change, les prompts changent, parfois l’architecture d’orchestration change. Ce qui reste fixe : l’absence d’un plan de contrôle qui saurait dire, à tout instant, quel agent tourne pour quel tenant, avec quel contexte, à quel coût, avec quelle latence et quel résultat traçable.
79 % des 47 vendors interrogés par Forrester en février 2026 reconnaissent l’agent control plane comme une catégorie produit distincte. 92 % ont nommé un product manager ou une équipe dédiée à la gouvernance agent. Le marché reconnaît le problème. Les architectures SaaS le découvrent souvent trop tard.
Les 7 raisons qui font qu’on reconstruit au lieu de contrôler
- Agrandir le context window comme rustine : ça résout l’hallucination à court terme mais crée une fuite de contexte entre tenants dès qu’on mutualise l’infrastructure. Sans isolation au niveau du plan de contrôle, chaque extension de contexte est un risque de contamination.
- Le fine-tuning comme réponse au prompt engineering : fine-tuner un modèle sur les données d’un client pour compenser des system prompts incohérents. La cause réelle est la gouvernance des prompts à l’échelle. La qualité du modèle de base est rarement en cause.
- Changer de modèle comme si c’était une migration : passer d’un modèle à un autre pour fuir une limitation (coût, latence) sans résoudre l’absence d’observabilité. Le nouveau modèle rencontre les mêmes angles morts.
- L’orchestration ad hoc : chaîner des agents avec des scripts maison plutôt qu’un framework doté d’une couche de traçabilité. Résultat : des boucles indéboguables en prod.
- La multi-tenancy ajoutée après coup : construire d’abord pour un client, puis tenter d’isoler les contextes au niveau applicatif. L’isolation au niveau du plan de contrôle est structurellement plus robuste et moins coûteuse à maintenir.
- Ignorer le FinOps IA : 98 % des équipes gèrent désormais la dépense IA selon le State of FinOps 2026, contre 63 % en 2025. Les équipes qui ne pilotent pas le token cost par agent et par tenant découvrent trop tard que l’orchestration représente la moitié de leur marge.
- Déployer des agents sans identité portable : Forrester identifie trois lacunes standards qui empêchent d’opérationnaliser un control plane, l’instrumentation incomplète, l’absence d’identité portable des agents et l’absence de schémas de gouvernance cross-plane. Sans identité agent, la traçabilité est une fiction.
La couche de contrôle : ce qu’elle fait concrètement
Un agent control plane centralise la supervision des agents distribués d’une organisation : lesquels tournent, pour quels tenants et à quel coût. AWS Bedrock Agent, Azure AI Foundry et Google Vertex AI Agent Builder proposent des implémentations au niveau infrastructure. La couche de contrôle est avant tout une décision architecturale. Aucun service cloud ne s’y substitue.
En pratique, elle répond à quatre questions que l’architecture SaaS IA sans control plane ne peut pas poser : quel agent a pris quelle décision, pour quel compte client, à quel coût et avec quelle politique de rollback si l’output est erroné ? Ces questions relèvent de la prod quotidienne, bien avant tout audit de compliance.
Les équipes les plus avancées externalisent la couche d’exécution chez des vendors SaaS (sécurité et SLA) et internalisent les agents qui pilotent les workflows, selon le modèle documenté par Duperrin en mars 2026. Tracer cette frontière suppose un plan de contrôle qui la matérialise.
Avant de dire que c’est de la théorie
L’objection classique : tout ça suppose une maturité d’organisation que la plupart des équipes n’ont pas. C’est vrai pour les équipes qui déploient leur premier agent. Pour celles qui en sont à leur cinquième reconstruction, c’est une question de coût d’opportunité. Chaque refacto sans couche de contrôle reproduit exactement les mêmes dettes techniques, avec un périmètre plus grand et un impact client plus fort.
Surtout, MCP (Model Context Protocol) ne règle pas tout. MCP standardise l’interface entre agents et outils ; il ne couvre ni la gouvernance inter-agents ni l’isolation des tenants. Le pilotage du token cost à l’échelle est un angle mort que MCP n’est pas conçu pour traiter.
Comment poser la couche de contrôle sans reconstruire une septième fois
Un control plane peut s’ajouter comme couche transversale à une architecture existante. Il ne suppose pas une refacto complète mais il suppose trois contraintes que l’on accepte ou que l’on reporte à la prochaine reconstruction.
Chaque agent a besoin d’une identité traçable : un identifiant stable et un contexte d’exécution isolé par tenant. Les logs structurés complètent cette base, rattachés à l’identifiant en temps réel. Les politiques de coût et de rollback doivent être déclarées au niveau du plan de contrôle. Les éparpiller dans le code de chaque agent garantit qu’elles seront ignorées. Et les métriques d’observabilité doivent être segmentées par tenant : l’agrégation masque les problèmes réels. Une p99 de latence saine sur l’ensemble des tenants peut cacher un seul client enterprise à 3 secondes de temps de réponse, comme l’illustre précisément l’infrastructure AWS Prescriptive Guidance sur l’IA multi-tenant.
Le marché formalisé par Forrester va produire des outils d’évaluation et des critères comparatifs dans les 12 à 24 prochains mois. Les équipes qui auront instrumenté leur architecture avant ce point pourront évaluer et adopter ces outils. Celles qui ne l’auront pas fait se retrouveront à poser l’infrastructure en urgence, sous contrainte de prod.
Ce que les équipes SaaS IA vont devoir décider
Le SaaS IA se reconfigure autour de la couche d’orchestration. Les vendors qui contrôlent cette couche définissent la nouvelle unité de valeur, ce que LeMagIT résumait en 2025 comme la « géopolitique du logiciel » agentique. Pour un éditeur SaaS, la question centrale est désormais : à qui appartient la couche de contrôle de mes agents en prod ?
Si cette couche appartient à AWS, Azure ou Google, l’éditeur devient un tenant de l’infrastructure de son infrastructure. Si elle est internalisée, elle représente un investissement de développement significatif mais aussi un levier de différenciation durable sur l’isolation des tenants et la traçabilité.
Avant que Forrester publie son évaluation comparative des vendors, les équipes qui auront instrumenté leur architecture sauront répondre à cette question : combien de tokens leurs agents ont-ils consommés ce mois-ci, pour quel client, pour quel workflow. Les autres recommenceront depuis le début.
