Le multi-provider SaaS

Série stratégie IA d'entreprise — 3/5

Prenons le cas d'une entreprise d'environ 600 salariés, filiale d'un grand groupe. La DSI vit depuis quelques mois un phénomène connu de toutes celles qui ont déployé un mono-provider avant elle. Les demandes remontent, dispersées, chacune raisonnable prise isolément.

L'équipe marketing a testé Claude sur un cas de rédaction longue et trouve le résultat meilleur que Gemini sur ce format précis. Les développeurs formulent la même demande, mais pour la revue de code, où leur benchmark interne donne aussi l'avantage à Claude. Le support voudrait pouvoir router certaines conversations client vers ChatGPT, dont la latence et le prix conviennent mieux à leur volumétrie quotidienne. L'équipe data pose la question de Mistral, pour des raisons de souveraineté sur les traitements sensibles et pour un coût par token plus tenable sur les jobs par lots.

Le juridique arrive avec une exigence d'un autre ordre : deux fournisseurs de la liste sont exclus par les conditions contractuelles d'un client important, et il faut pouvoir en garantir l'exclusion technique. Le RSSI, sollicité sur un audit, demande des logs granulaires par utilisateur avec traçabilité des prompts sensibles. La finance veut piloter les tokens par département et poser des seuils budgétaires par équipe.

Chaque demande est parfaitement légitime. Le mono-provider en place ne peut en satisfaire aucune.

Trois forces qui s'additionnent

Ce point d'inflexion n'a rien d'exceptionnel. Il apparaît dans la plupart des organisations d'une certaine taille à mesure que la maturité IA en interne progresse, généralement entre le douzième et le vingt-quatrième mois après le déploiement initial.

Trois forces s'additionnent. Les cas d'usage métier se différencient à mesure que les équipes vont plus loin dans leurs expérimentations, et cette différenciation fait émerger des besoins qui ne se traitent plus par un modèle unique. Les contraintes de gouvernance, tolérables tant que l'usage restait bureautique standard, deviennent explicites dès qu'apparaissent des données sensibles ou des cas d'usage à impact client. La finance, enfin, cesse de considérer l'IA comme une expérimentation à budget global pour la traiter comme une infrastructure à piloter par département.

Le besoin qui naît de cette conjonction est très précis. Une couche technique capable de router entre plusieurs modèles selon le cas d'usage, avec des connecteurs métier prêts à l'emploi, une gouvernance intégrée et une capacité de pilotage financier granulaire. Une couche que l'entreprise, dans la plupart des cas, ne veut pas et ne peut pas construire elle-même. La DSI n'a pas d'équipe plateforme IA dédiée, les compétences sont rares et coûteuses sur le marché, et le délai de mise en production d'une construction interne dépasse largement la fenêtre de tolérance des métiers.

Cette configuration précise est la raison d'être de la deuxième famille.

La proposition du multi-provider SaaS

Un multi-provider SaaS offre un point d'entrée unique vers plusieurs modèles, avec des connecteurs métier natifs qui absorbent la complexité d'intégration (Slack, Google Drive, Notion, HubSpot, Snowflake, Confluence sont les plus courants), une interface de production stable, une gouvernance intégrée et une console d'administration avec journalisation d'usage. L'entreprise achète directement la couche qu'il aurait sinon fallu construire.

Trois acteurs illustrent aujourd'hui les positionnements distincts que cette famille peut prendre.

Dust vient de l'école Stripe et OpenAI par ses fondateurs. Son positionnement porte un nom qu'elle défend systématiquement : le multiplayer AI. La proposition s'organise autour d'un espace commun où humains et agents travaillent avec les mêmes documents, les mêmes conversations, les mêmes notifications, là où le reste de la famille pense d'abord l'assistant individuel. Une adresse email dédiée peut être associée à un agent Dust, exactement comme on ferait avec un collègue. Cette philosophie explique la profondeur des agents personnalisables et la qualité du partage inter-équipes, qui distinguent Dust dans la famille. Des organisations comme Doctolib (plusieurs milliers de salariés), Alan, Clay ou Persona ont déployé la plateforme à l'échelle de plusieurs départements simultanés. La limite qui se dessine à l'usage tient au catalogue de connecteurs, qui reste dépendant de la roadmap Dust, et à un pricing par siège qui grimpe rapidement au-delà de quelques milliers d'utilisateurs.

Langdock est un enfant du marché DACH (Allemagne, Autriche, Suisse). Née à Berlin, la plateforme a construit son adoption sur un positionnement GDPR-first et déploiement de masse pour grandes organisations industrielles. Sa proposition tient dans la capacité à mettre l'IA entre les mains de tous les employés d'un grand groupe, avec la conformité assumée dès le premier jour. Sur la sophistication agentique, Dust va plus loin. Merck déclare plus de 25 000 utilisateurs sur Langdock, dont plus de 14 000 actifs mensuels. La plateforme a résolu le problème de déploiement à l'échelle industrielle chez un groupe pharmaceutique européen soumis à des contraintes réglementaires lourdes, ce qui reste rare dans la famille. Sa limite tient à une agilité produit moins forte sur la construction d'agents complexes, et à un focus qui reste plus orienté productivité et adoption que création agentique poussée.

Gemini Enterprise Agent Platform est le pari de Google Cloud, annoncé le 23 avril 2026 à Google Cloud Next, en succession de Vertex AI dont il absorbe les fonctions. Le positionnement se joue sur la gouvernance, avec un argument commercial explicite : combler le gap OutSystems (96 % des entreprises font tourner des agents en production, 12 % seulement disent pouvoir les gouverner) évoqué dans le premier article de cette série. Trois éléments structurent l'offre. Un accès à plus de 200 modèles via Model Garden, y compris des modèles tiers, ce qui rend le catalogue plus ouvert que le nom Gemini ne le suggère. Des primitives de gouvernance natives, dont Agent Identity, Agent Gateway et un audit trail complet. Le tout s'adosse à l'écosystème Google Cloud, ce qui pèse pour les entreprises qui y sont déjà. La limite structurelle est que l'entreprise entre dans cet écosystème pour son infrastructure IA, ce qui déplace le lock-in du modèle vers la couche cloud. Ce déplacement est un élément à intégrer au calcul stratégique, sans jugement de valeur associé.

D'autres acteurs occupent des positions voisines. Microsoft Agent 365 avec Copilot Studio dans l'écosystème M365, AWS Bedrock AgentCore pour les organisations très cloud AWS, Salesforce Agentforce 360 pour les fonctions commerciales, ServiceNow AI Agents pour l'ITSM, Notion Custom Agents pour la productivité documentaire. La famille se densifie rapidement et se segmente par écosystème d'origine.

Le profil en cinq axes

Appliqué à la grille en cinq axes posée dans l'article 1, le multi-provider SaaS dessine un profil très différent de celui du mono-provider bundlé.

L'agilité et la gouvernance sont clairement achetées. L'entreprise cliente accède à plusieurs modèles selon les cas d'usage, avec la possibilité d'arbitrer entre eux dans une même interface. Elle obtient simultanément une gouvernance native de qualité, avec identités, journalisation et politiques d'usage granulaires. Ce double gain constitue la promesse commerciale de la famille.

Le coût total de possession et la résilience deviennent les deux points sensibles. Le coût par siège, tenable à petite ou moyenne échelle, se pose autrement dès que l'organisation dépasse quelques milliers d'utilisateurs. La résilience dépend structurellement de l'éditeur SaaS choisi : sa capacité à maintenir le service, à intégrer les nouveaux modèles au rythme du marché, à ne pas modifier son pricing d'année en année. Le lock-in s'est déplacé du modèle vers la plateforme, ce qui prolonge un constat déjà posé ailleurs : la performance du modèle est rarement le vrai sujet.

L'expérience utilisateur, enfin, occupe une position intermédiaire. L'interface est cohérente et professionnelle, l'adoption reste correcte, mais elle n'atteint pas la fluidité native du mono-provider bundlé, où l'IA vit à l'intérieur de la suite bureautique que le salarié utilise déjà.

Les points sensibles à l'usage

Quatre points sensibles apparaissent à l'usage réel du SaaS multi-provider, sans qu'aucun ne remette en cause la valeur de fond de la famille.

Le pricing par siège à l'échelle vient en premier. Un tarif autour de 25 ou 30 euros par utilisateur reste absorbé sans difficulté sur 500 sièges. À 5 000 ou 10 000 utilisateurs, la ligne budgétaire devient significative, et la question de la portabilité des agents construits sur la plateforme se pose autrement. Une DSI qui a construit 300 agents Dust ou Langdock sur trois ans doit savoir que la migration hors de la plateforme sera un projet en soi.

Vient ensuite le catalogue de modèles. Les SaaS multi-provider intègrent les modèles qu'ils choisissent, à leur rythme. Un modèle sorti chez OpenAI en semaine 1 peut n'être disponible dans Dust qu'en semaine 4 ou 8, le temps que l'intégration soit testée et stabilisée. Ce délai reste acceptable pour la plupart des cas d'usage, moins pour les équipes techniques qui construisent des cas d'usage différenciants et veulent tester rapidement les dernières évolutions.

Le périmètre des données constitue le troisième point. Les données de l'entreprise transitent par le SaaS, quel qu'il soit. Chaque acteur pose ses garanties contractuelles et techniques (exclusion du training, chiffrement au repos et en transit, hébergement régional, certifications), mais l'entreprise cliente accepte structurellement que ses données passent par un tiers. Pour les secteurs les plus sensibles, dont la défense, une partie de la santé et certains cas de la finance, ce constat peut être disqualifiant.

La question de la souveraineté ferme la liste, et prend son importance selon le contexte. Dust et Langdock hébergent en Europe et sont soumis au RGPD par nature. Gemini Enterprise Agent Platform appartient à un hyperscaler américain, avec les questions de Cloud Act et de juridiction extraterritoriale associées. Microsoft Agent 365, AWS Bedrock, Salesforce Agentforce se retrouvent dans la même situation. Ce critère devient déterminant pour les organismes publics, les industriels DACH avec exigences de conformité fortes, la finance et la santé européennes. Il reste un paramètre parmi d'autres pour beaucoup d'organisations, à peser selon le contexte réglementaire et sectoriel.

Le bon choix, pour quel profil

La deuxième famille est le bon choix architectural pour un profil d'organisation qui se dessine assez précisément.

Une entreprise mid-market ou grande, entre 500 et plusieurs dizaines de milliers de salariés, avec une DSI structurée et une équipe applicative solide, mais sans équipe plateforme IA dédiée à temps plein. Ses cas d'usage IA sont transverses (marketing, support, RH, opérations, finance) plutôt qu'ultra-différenciants métier. Le contexte réglementaire va de modéré, avec des contrôles standards, à fort dans la santé, la finance ou le secteur public européen, et la gouvernance intégrée du SaaS y devient un vrai gain de temps sur la conformité. Reste un volume d'usage stable et prévisible sur 2 à 3 ans, sans explosion de scale attendue à court terme.

Ces critères recoupent une partie importante du marché européen mid-market, ce qui explique la traction rapide observée chez Dust, Langdock et Gemini Enterprise sur les douze derniers mois.

La question du basculement vers le multi-provider construit en interne se pose au-delà de ce périmètre. Quand l'échelle rend le pricing SaaS moins tenable, quand les cas d'usage deviennent suffisamment spécialisés pour justifier une construction dédiée, ou quand la souveraineté sur les données interdit toute forme d'externalisation, c'est là que l'équation change.

La couche est chez l'éditeur

Le fil rouge de la série reste vrai à cette étape. La couche d'abstraction existe. Dans le multi-provider SaaS, elle est chez un éditeur spécialisé qui l'a construite pour l'entreprise cliente. Cette famille se différencie sur deux plans. Face au mono-provider bundlé, elle conserve l'agilité multi-modèles et une gouvernance plus fine. Face au multi-provider construit en interne, elle épargne à l'entreprise la construction de la couche, avec les compétences, les coûts et le délai qu'implique une telle construction.

À suivre : le multi-provider construit en interne, avec OpenRouter, LiteLLM et les gateways maison. Article 4 : acheter ou construire, la comparaison frontale.