Faut-il construire ou acheter un runtime MCP pour les agents IA d'entreprise en 2026 ?

Le goulet d’étranglement pour l’IA en entreprise a changé de nature. Vos équipes ont construit des agents. Ils fonctionnent dans des environnements mono-utilisateur sur LangChain ou Mastra. Le mur apparaît quand vous tentez de brancher ces agents sur des systèmes d’entreprise sécurisés, pour des milliers d’employés, sans créer de nouvelles failles de sécurité ni une charge de maintenance permanente.

En 2026, les directeurs engineering font face à un vrai choix architectural, et ce n’est pas la question d’écrire des serveurs MCP (Model Context Protocol) personnalisés. Ces serveurs sur mesure, c’est la façon de connecter vos agents aux systèmes internes propriétaires, quelle que soit la voie choisie. La vraie décision porte sur la couche runtime qui enveloppe ces serveurs : cycle de vie OAuth, coffre-fort de credentials, auth multi-utilisateurs, logique d’intersection de permissions, pipeline d’audit, application des politiques et observabilité. Vous pouvez construire cette couche vous-même sur LangChain ou Mastra, ou acheter un runtime MCP qui la livre clé en main.

La bonne réponse dépend de votre profil de déploiement. Dès que l’autorisation multi-utilisateurs, la gouvernance niveau audit ou l’observabilité des appels d’outils asynchrones entrent en jeu, le chemin du build génère des coûts croissants et une surface de risque qui s’élargit. Maintenir votre propre auth, votre coffre-fort de credentials et votre pipeline d’audit place chaque action d’agent dans votre rayon d’explosion sécurité. La décision penche vers l’achat d’un runtime.

TL;DR : construire ou acheter un runtime MCP

Un runtime MCP prend en charge ce que la plupart des équipes n’ont aucun intérêt à coder elles-mêmes : autorisation des agents, rotation des tokens OAuth, journalisation d’audit et application des politiques. Le runtime est la couche d’exécution, d’autorisation et de gouvernance où tournent les outils de votre agent (les serveurs MCP).

Si vous construisez votre propre runtime. Trois profils précis correspondent à ce choix : périmètre mono-utilisateur, infrastructure d’agents comme produit central, ou pipelines d’API entièrement internes. Vous conservez un contrôle total et assumez la responsabilité du cycle de vie OAuth, du coffre-fort de credentials, de la journalisation d’audit et de l’application des politiques. Chaque intégration devient un poste permanent dans votre roadmap engineering ; la maintenance de l’auth et des politiques ne tombe jamais à zéro.

Si vous achetez un runtime. C’est le choix par défaut pour la production multi-utilisateurs. Vous obtenez une gouvernance centralisée du cycle de vie alignée sur vos politiques existantes, une autorisation multi-utilisateurs avec gestion complète du cycle de vie OAuth, l’exécution des outils, et la possibilité de construire des outils propriétaires sans reconstruire la couche runtime.

Quatre points de bascule poussent à passer d’une couche runtime maison à une solution vendor :

• Franchir le seuil des trois intégrations, quand la maintenance des API commence à consommer des sprints dédiés.
• Introduire des actions déléguées par utilisateur, qui obligent les agents à exécuter des appels d’outils au nom d’utilisateurs humains identifiés, avec des permissions distinctes.
• Passer de tâches synchrones en lecture seule à des opérations asynchrones longues en lecture/écriture qui dépassent les timeouts standard des LLM.
• Avoir besoin de logs d’audit compatibles OpenTelemetry pour satisfaire les équipes conformité et sécurité.

L’état de l’infrastructure MCP : l’enfer de la config face au compromis du buy

Le Model Context Protocol a standardisé la façon dont les applications IA consomment du contexte et exécutent des outils, remplaçant les wrappers API sur mesure que les équipes écrivaient pour chaque feature LLM.

Adopter MCP introduit des défis architecturaux. Les équipes plateforme enterprise choisissent entre deux fardeaux opérationnels : le piège DIY de « l’enfer de la config », ou le compromis côté achat avec la cadence vendor et la dépendance à l’écosystème.

L’enfer de la config survient quand vous faites évoluer des serveurs MCP sur mesure. Les ingénieurs plateforme passent leur temps à éditer des configurations JSON pour re-mapper les schémas d’outils à chaque fois qu’un fournisseur SaaS déprécie un endpoint, à traquer les dérives de rotation de tokens quand un refresh OAuth expire et que la logique de retry maison ne gère pas le cas limite, et à traiter le travail manuel qu’imposent SOC 2 et RGPD (registres de schémas immuables, manifestes d’outils signés, middleware de masquage des PII dans les sorties d’outils). Quand vous construisez votre propre infrastructure, chaque connexion cassée, chaque token expiré et chaque patch de sécurité vous appartiennent.

Le runtime n’est pas un proxy supplémentaire devant vos outils. Dans une architecture agentique, l’agent est déjà le proxy. Il sert d’intermédiaire entre l’utilisateur et les systèmes aval, raisonne sur les outils à appeler et orchestre des workflows multi-étapes. Le runtime est la couche d’exécution où l’action choisie se concrétise réellement. C’est là que les credentials sont résolus, que la politique est appliquée et que l’appel est passé au nom d’un utilisateur précis.

Le runtime est la meilleure passerelle.

Les vrais compromis côté achat sont d’une autre nature. Vous acceptez les primitives de politique et le format d’observabilité du runtime comme forme de lock-in. Vous supportez la surcharge des vérifications d’autorisation par outil et de la résolution de tokens en juste-à-temps (une fraction de la latence d’inférence LLM et des API aval).

Le vrai choix en 2026 est une question de risque, pas de coût. Construisez votre propre couche runtime, et votre rayon d’explosion sécurité grandit à chaque intégration, chaque utilisateur, chaque changement de politique. Acheter un runtime transfère ce travail à un vendor qui a déjà été audité pour ça. Pour les déploiements enterprise, c’est le bon côté du compromis.

Quand construire son propre runtime

Construire sa propre couche runtime est le bon choix dans un ensemble restreint de scénarios. L’écosystème open source a suffisamment mûri pour que des équipes de platform engineering expérimentées puissent monter leur propre couche d’orchestration au-dessus des SDK Python ou TypeScript officiels du Model Context Protocol. Les SDK implémentent la spécification MCP sur JSON-RPC 2.0 et supportent à la fois stdio pour la communication entre processus locaux et Streamable HTTP pour l’exécution distante. Les équipes enveloppent les serveurs MCP dans des adaptateurs fournis par des frameworks comme LangChain ou Mastra pour que les agents puissent les invoquer directement, puis déploient sur Kubernetes avec des charts Helm personnalisés.

Les serveurs MCP eux-mêmes deviennent alors la partie facile. La couche runtime qui les enveloppe représente le vrai travail, et les cas où construire cette couche en interne fait sens sont rares.

Construisez votre propre runtime si votre périmètre est mono-utilisateur. L’OAuth par utilisateur, le coffre-fort de tokens et l’intersection de permissions sont les parties les plus difficiles de la couche runtime, et elles n’ont d’importance que dès lors qu’un deuxième humain entre dans la boucle. Un développeur solo qui connecte ses propres credentials à un seul agent n’en a pas besoin.

Construisez votre propre runtime si l’infrastructure d’agents est votre produit central. Une startup dont tout le produit est un agent de planification intelligent pour des utilisateurs finaux doit contrôler chaque couche du stack. Les ingénieurs doivent s’y investir pleinement, parce que c’est l’entreprise elle-même.

Construisez votre propre runtime si vous contrôlez chaque API du pipeline. Si vos agents n’agissent que sur des systèmes et sources de données que vous maîtrisez, sans connexion SaaS tierce, vous contournez entièrement le problème du cycle de vie OAuth, et l’argument pour acheter s’affaiblit.

Les déploiements air-gapped ne déclenchent pas un choix de build. C’est une question de mode de déploiement. Les runtimes auto-hébergés font tourner la couche runtime du fournisseur entièrement dans votre infrastructure, satisfaisant l’air-gap tout en héritant de l’authentification, de l’audit et de la gouvernance du runtime. Ne construisez votre propre couche runtime que si le déploiement interdit aussi les logiciels de fournisseurs tiers, ce qui s’applique typiquement aux environnements hautement classifiés.

En dehors de ces trois cas, construire son propre runtime est une mauvaise allocation du temps des ingénieurs seniors.

Au-delà des serveurs MCP eux-mêmes, vous devez construire des coffres-forts de tokens sécurisés pour gérer les cycles de vie OAuth de chaque utilisateur et service. Vous gérez les limites de débit et la pagination propres à chaque fournisseur. Vous architecturez des machines à états pour le débogage asynchrone quand un appel d’outil prend dix minutes. Vous patchez des serveurs personnalisés à chaque changement de schéma d’API en amont. Sautez ce travail, et vous obtenez des hallucinations d’agents et des échecs silencieux.

L’authentification et les politiques représentent une charge permanente, indépendante de la dérive des API. Les gens rejoignent et quittent l’entreprise. Les rôles changent. Les permissions sont révoquées. Les politiques se durcissent après un incident. Chaque événement doit traverser votre couche d’auth personnalisée en temps réel. C’est un coût ETP permanent, pas un problème à résoudre une fois pour toutes, et il ne diminue jamais à mesure que le déploiement grandit.

Quand acheter un runtime

Un runtime MCP déplace l’effort d’ingénierie de l’infrastructure vers le produit. Votre équipe opère au-dessus d’une couche d’exécution qui gère déjà l’auth, les coffres-forts, l’audit et les politiques, au lieu de construire chacun d’eux.

Un runtime vous offre quatre choses d’emblée.

Gouvernance centralisée du cycle de vie. Le runtime est le point d’application des politiques que votre organisation a déjà définies ailleurs (dans vos IdPs, vos outils de vente, vos systèmes de sécurité). Il mappe ces politiques existantes et les applique au niveau de la couche agent. Il ne vous demande pas de recréer des politiques d’accès dans un nouvel outil. Les administrateurs disposent d’un plan de contrôle unique pour gérer le comportement des agents, auditer l’exécution des outils et déployer les mises à jour en toute sécurité.

Autorisation post-prompt multi-utilisateurs. Chaque appel d’outil s’exécute avec les identifiants et permissions de l’utilisateur humain qui a demandé l’action. Le runtime gère le cycle de vie des tokens OAuth (stockage sécurisé, rafraîchissement, rotation) sans exposer les identifiants au LLM.

Un catalogue d’outils MCP préconstruits et versionnés, pour que vos agents accèdent à des milliers de systèmes d’entreprise dès le premier jour.

Une voie pour les outils propriétaires qui ne nécessite pas de reconstruire la couche runtime. Pour les serveurs MCP personnalisés d’un système interne, vous les écrivez sur le framework MCP open source du runtime et héritez gratuitement de l’auth, de l’audit et de la gouvernance. Si vous avez déjà des serveurs MCP personnalisés construits sans le framework, vous pouvez les connecter au runtime et bénéficier tout de même de l’auth, de l’audit, de la gouvernance et des hooks de politique pré/post-appel sans les réécrire.

Les ingénieurs plateforme passent de l’écriture de scripts d’intégration fragiles et du débogage de flux OAuth cassés à la gestion de politiques d’accès de haut niveau. Votre équipe définit quels agents peuvent accéder à quels outils, configure le filtrage de visibilité pour que chaque équipe ne voie que les intégrations autorisées, et surveille des tableaux de bord compatibles OpenTelemetry pour suivre le raisonnement des agents et la latence d’exécution des outils. Vous passez du temps sur la logique de l’agent, pas sur la plomberie.

Grille d’évaluation MCP entreprise : critères de décision build vs. buy

Huit dimensions séparent un prototype local d’un déploiement en production. La matrice note chaque axe en regard de ces critères.

Dimension d’évaluation	Couche runtime DIY (SDK open source)	Runtime MCP fournisseur
Contrôle & personnalisation	Absolu. Contrôle total sur les couches transport, l’état mémoire personnalisé et l’isolation matérielle sur mesure.	Élevé. Exécution d’outils standardisée avec hooks pour politiques personnalisées, mais accès limité à l’infrastructure sous-jacente.
Vitesse de mise en place	Semaines à mois. Nécessite de construire les couches d’auth, les coffres-forts de tokens et les pipelines de déploiement.	Heures à jours. Intégration directe avec les IdPs existants et accès immédiat aux catalogues d’outils préconstruits.
Charge de maintenance	Sévère. L’équipe gère toutes les mises à jour de schémas API, les dépréciations, la rotation des tokens et les correctifs de sécurité. La charge s’accumule à chaque intégration et chaque changement de politique.	Minimale. Le fournisseur absorbe la dérive des API, la gestion du cycle de vie des tokens et les correctifs. Votre équipe gère les politiques d’accès et la visibilité, pas l’infrastructure.
Autorisation multi-utilisateurs	Implémentation manuelle. Risque élevé d’injection de prompt et de fuite d’identifiants en cas d’erreur de conception.	Intégrée. Émission de tokens just-in-time automatisée, scopée par utilisateur et isolée du LLM.
Gouvernance du cycle de vie	Fragmentée. Nécessite un middleware de logs personnalisé, des intégrations SIEM disparates et un contrôle de version manuel.	Centralisée. Plan de contrôle unifié, logs d’audit natifs OpenTelemetry et prévention des MCP shadow.
Gestion des tâches asynchrones	Complexe. Nécessite de construire du polling externe, des dead-letter queues et des machines à états durables pour les timeouts.	Native. Exécution parallélisée, bascule automatique, relances intelligentes et récupération découplée des résultats.
Options de déploiement	Infinies. Déployez partout, y compris en environnement air-gapped hors ligne.	Cloud, auto-hébergé on-prem ou en cloud (offre entreprise fournisseur), hybride ou entièrement air-gapped. Le cloud nécessite une sortie réseau vers le plan de contrôle du fournisseur ; l’auto-hébergé fait tourner le runtime dans votre propre infrastructure.
Profil d’équipe idéal	Périmètre mono-utilisateur, l’infrastructure agent est votre produit principal, vous contrôlez chaque API du pipeline.	Production multi-utilisateurs, mix propriétaire + SaaS, équipes optimisant le time-to-value et la gouvernance de niveau audit.

Autorisation multi-utilisateurs en production

L’autorisation multi-utilisateurs est là où la plupart des projets d’agents en entreprise calent avant la production.

Un développeur qui teste en local passe ses clés API personnelles au système. En production, un agent sert des milliers d’utilisateurs avec des périmètres de permissions différents.

Si votre couche runtime repose sur un compte de service partagé ou transmet un bearer token à portée complète d’un utilisateur au contexte du LLM, vous avez créé un vecteur d’attaque. Une attaque par injection de prompt demande à l’agent d’utiliser ces permissions héritées pour exfiltrer des données ou supprimer des dépôts.

Les comptes de service partagés brisent aussi les exigences de piste d’audit : les systèmes ne peuvent pas distinguer une action d’un agent autonome d’une action dirigée par un humain.

Un runtime résout ce problème avec autorisation multi-utilisateur post-prompt. Le runtime applique une intersection de permissions à l’exécution :

Permissions de l’agent ∩ Permissions de l’utilisateur = Périmètre d’action effectif

L’agent ne peut exécuter une action que si la politique de rôle de l’agent et les permissions SaaS natives de l’utilisateur l’autorisent toutes les deux. Toute autre combinaison est refusée.

Exemple : un agent RH limité aux tâches de recrutement est invoqué par un employé disposant de privilèges admin dans Workday, y compris l’accès aux données de paie globales. Quand l’agent tente de lire la paie, le runtime évalue l’intersection au moment de l’appel et refuse la requête. L’utilisateur a l’autorité. Le périmètre restreint de l’agent bloque l’action.

Le runtime acquiert un token à portée étroite et en juste-à-temps pour exécuter l’action autorisée au nom de l’utilisateur. Les credentials n’atteignent jamais le client LLM, ce qui supprime l’injection de prompt comme vecteur direct de vol de credentials.

Gouvernance du cycle de vie et audit

Sans gouvernance centralisée, les déploiements d’agents en entreprise deviennent du shadow IT. Les développeurs lancent des serveurs MCP non officiels sur leurs machines locales ou sur des instances cloud non autorisées, connectant des LLM à des bases de données internes sans aucun contrôle.

Un runtime joue le rôle de point d’application central pour les politiques que votre organisation a déjà définies ailleurs. Il se connecte à vos IDP, vos outils commerciaux, vos systèmes de sécurité, et applique ce qui s’y trouve. Il ne vous demande pas de recréer des politiques d’accès dans un nouvel outil. Voyez le runtime comme le videur : il fait respecter les règles, il ne les écrit pas. Tous les outils et serveurs sont enregistrés dans un catalogue unique. Le filtrage de visibilité garantit qu’un agent RH ne voit que les outils RH, tandis qu’un agent de développement ne voit que les outils de dépôt.

Au-delà de l’application des règles existantes, le runtime expose des hooks pré- et post-appel d’outil pour une logique personnalisée. Les équipes conformité injectent leurs propres variables (état du workflow, fenêtres temporelles, volume de requêtes, données contextuelles sur l’utilisateur ou la session), et le runtime les traite comme des primitives d’application de premier rang aux côtés des politiques standard. Les conditions spécifiques à l’organisation sont câblées sans forker le runtime.

Le runtime génère des logs d’audit granulaires compatibles OpenTelemetry. Chaque action est tracée : quel utilisateur a invoqué l’agent, quel modèle LLM a généré l’appel d’outil, quels paramètres ont été transmis, et ce que l’API cible a retourné. Cette visibilité est un prérequis pour passer les audits de sécurité dans les secteurs réglementés.

Tâches asynchrones et longue durée

Les architectures LLM standard sont synchrones. Les endpoints d’inférence expirent en quelques minutes.

Les actions d’agents en entreprise (déclencher des builds de pipeline CI/CD, provisionner une infrastructure cloud ou interroger de grands entrepôts de données) peuvent s’exécuter pendant des dizaines de minutes, voire des heures.

Avec un runtime DIY, les ingénieurs plateforme construisent eux-mêmes l’infrastructure asynchrone : files d’attente, synchronisation d’état en mémoire externe, mécanismes de polling et files de lettres mortes pour les opérations échouées.

Un runtime prend en charge ce travail. Il supporte les dernières spécifications MCP Tasks, permettant aux agents de déclencher un processus longue durée, de recevoir immédiatement un identifiant de tâche, et d’interroger le résultat de façon asynchrone.

Le runtime gère l’exécution parallélisée, le routage de basculement en cas de défaillance d’un endpoint, et les nouvelles tentatives avec backoff. Le workflow de l’agent reste robuste sans que la couche applicative n’ait à gérer l’état.

Observabilité : traces OpenTelemetry de bout en bout

Le coût caché des stacks MCP DIY, c’est le débogage. Quand un agent rate un appel d’outil à 3h du matin, les ingénieurs plateforme assemblent manuellement les traces de l’exécution de l’agent, les logs de chaque serveur MCP, les logs de retry de chaque SDK provider, et la page de statut de chaque API SaaS cible. Aucune vue corrélée n’existe. Investiguer une action asynchrone échouée revient à faire des grep sur trois systèmes en parallèle et à reconstituer la séquence à la main.

Un runtime émet une seule trace OpenTelemetry qui porte toute la chaîne. Exemple d’arbre de spans pour une action d’agent (« planifier une réunion de suivi et envoyer le récapitulatif ») :

agent.run (root)                 user_id, session_id, agent_id
├─ llm.infer                     model, prompt_tokens, completion_tokens
├─ mcp.tool_call                 tool=google_calendar.create_event
│  ├─ mcp.authz                  policy_result=allow, user_scope=calendar.events.write
│  ├─ mcp.oauth.refresh          token_id, refresh_outcome=ok
│  └─ mcp.http.execute           target_host, status=200, latency_ms=412
├─ mcp.tool_call                 tool=gmail.send
│  ├─ mcp.authz                  policy_result=allow
│  ├─ mcp.retry                  attempt=2, reason=rate_limited
│  └─ mcp.http.execute           status=202, latency_ms=890
└─ llm.infer                     result synthesis

Exportez cette trace vers Honeycomb, Datadog ou votre SIEM, et vous pouvez répondre à « quel utilisateur, agent, outil, politique, token ou retry a causé l’échec ? » en une seule vue. Avec le DIY, vous y arrivez seulement si vous construisez vous-même la couche de corrélation de traces et la maintenez à mesure que les SDK, les formats de logs et les moteurs de politique évoluent. Cette maintenance est un coût direct sur votre stack DIY, qui disparaît quand vous adoptez un runtime qui émet nativement les traces agent-vers-outil.

Charge opérationnelle de la construction DIY

La charge opérationnelle d’une couche runtime DIY s’accumule à chaque intégration et à chaque changement de politique. Le développement initial est la plus petite partie du travail. L’essentiel de l’effort d’ingénierie arrive après le lancement : dépréciations d’API, changements de schéma, rotation des tokens OAuth, correctifs de sécurité, et le brassage des politiques d’auth qui grossit avec chaque utilisateur, chaque changement de rôle et chaque permission révoquée.

Un post-mortem de production sur des serveurs MCP personnalisés documente la chaîne de défaillances typique : dérive d’auth, état de session orphelin, retries fragiles, hallucinations silencieuses d’outils. Chaque défaillance mobilise des ingénieurs seniors pour diagnostiquer et corriger, selon un calendrier qui ne se compresse pas.

Les ingénieurs seniors qui construisent un runtime DIY passent leur temps sur des scripts de refresh OAuth et des correctifs de réponse aux incidents. Ceux qui utilisent un runtime passent leur temps sur la logique d’agent propriétaire et les workflows métier. Ces différences se cumulent à chaque équipe et à chaque trimestre.

Comment évaluer les vendors de runtime MCP en 2026

Choisir un runtime commence par sélectionner le bon vendor. Le marché de l’infrastructure MCP se divise en trois grandes catégories. Les gateways routent le trafic MCP. Les registries cataloguent les serveurs MCP. Les runtimes gèrent l’exécution, l’autorisation et la gouvernance. Les vendors couvrent différentes couches. La plupart en couvrent une. Certains en regroupent deux. La comparaison des gateways, runtimes et registries MCP indique où se positionnent les vendors sur ces trois catégories.

Dans la catégorie runtime, évaluez les vendors sur quatre capacités :

1. Gouvernance centralisée du cycle de vie. Le runtime applique-t-il les politiques que votre organisation a déjà définies ailleurs (IDP, outils commerciaux, systèmes de sécurité), ou vous demande-t-il de les recréer dans un nouvel outil ? Cherchez un plan de contrôle unique avec logs d’audit, contrôle de version et filtrage de visibilité sur chaque agent et chaque outil.
2. Autorisation post-prompt multi-utilisateur. Le runtime évalue-t-il les permissions par utilisateur et par action au moment de l’exécution, ou passe-t-il par un compte de service partagé ? L’OAuth par utilisateur, avec des identifiants isolés du LLM, c’est le niveau attendu.
3. Des outils optimisés pour les agents, avec une voie pour les outils propriétaires. Les outils traduisent-ils l’intention, ou sont-ils de simples wrappers d’API qui obligent l’agent à renseigner des IDs d’objets et des enums ? Le vendor propose-t-il un framework open-source pour construire des serveurs MCP personnalisés sur vos systèmes internes, en héritant de l’auth, de l’audit et de la gouvernance sans reconstruire la couche runtime ?
4. Hooks de politique personnalisés pour un accès contextuel. Votre équipe conformité peut-elle ajouter une logique propre à l’organisation (état du workflow, fenêtres temporelles, volume de requêtes, données contextuelles sur l’utilisateur ou la session) comme primitives d’application de premier ordre, sans forker le runtime ?

Comment Arcade.dev répond à chacun de ces points

Arcade est le runtime MCP. Il offre les quatre capacités en une seule couche pour les agents IA multi-utilisateurs à grande échelle.

Gouvernance du cycle de vie des agents. Arcade est le point d’application central des politiques que votre organisation a déjà définies. Il mappe et applique les politiques de vos IDPs, outils commerciaux et systèmes de sécurité, sans vous demander de recréer des politiques d’accès dans un nouvel outil. Un plan de contrôle unique pour chaque outil, agent et fournisseur d’auth. Gestion de version pour déployer les mises à jour d’outils en toute sécurité. Un registre partagé qui évite aux équipes de reconstruire l’existant. Filtrage de visibilité pour que les agents ne voient que les outils que leur utilisateur est autorisé à invoquer. Journaux d’audit granulaires, exportables via OpenTelemetry vers votre SIEM, qui tracent chaque action d’agent par utilisateur et par service. La certification SOC 2 Type 2 d’Arcade valide ces contrôles par un audit indépendant.

Autorisation des agents. Chaque requête MCP dans Arcade porte deux couches d’identité : une clé au niveau projet (quelle application fait la requête) et une identité au niveau utilisateur (au nom de qui l’action est exécutée). Arcade évalue dynamiquement l’intersection des permissions agent et utilisateur au moment du runtime pour prévenir l’escalade de privilèges. Il gère le cycle de vie OAuth complet (refresh, rotation, mismatch) avec des identifiants isolés du LLM, et s’intègre aux systèmes de gouvernance des identités d’entreprise existants comme Okta, Entra et SailPoint, pour appliquer des politiques déjà définies plutôt que de les dupliquer. C’est cette couche qui supprime l’injection de prompt comme vecteur de vol direct d’identifiants.

Outils optimisés pour les agents. Le catalogue de plus de 8 000 outils MCP optimisés pour les agents d’Arcade ne sont pas de simples wrappers d’API. Ils traduisent l’intention en langage naturel en appels API structurés : un agent chargé d’« envoyer ça à la Finance » n’a pas à halluciner la cible recipient_user_id. Le coût en tokens apparaît dans les benchmarks : pour des requêtes CRM identiques, les outils à niveau d’intention ont produit 100 fois moins de tokens en réponse qu’une approche par passthrough d’API brute, avec un output équivalent à 3,7 % d’une fenêtre de contexte 200K contre 373 %. À grande échelle, cette surcharge entraîne un débordement de la fenêtre de contexte dans les workflows multi-étapes et dégrade la précision des agents. Le runtime gère l’exécution parallélisée des outils, le failover et les nouvelles tentatives. Le Arcade MCP Framework vous permet de construire des outils propriétaires personnalisés qui s’intègrent au même plan de contrôle avec le même wrapping d’auth et de gouvernance.

Accès contextuel et politiques personnalisées. Au-delà de l’application des politiques déjà définies ailleurs dans votre organisation, Arcade expose des hooks pré- et post-appel d’outil pour une logique personnalisée. Les équipes conformité y injectent leurs propres variables (état du workflow, fenêtres temporelles, volume de requêtes, données contextuelles sur l’utilisateur ou la session), et le runtime les traite comme des primitives d’application de premier ordre. Les conditions propres à l’organisation se câblent sans forker le runtime.

Pour les entreprises avec des besoins mixtes (systèmes internes propriétaires et large couverture SaaS, auth multi-utilisateur et gouvernance, rapidité de livraison et sécurité), Arcade couvre l’ensemble sans imposer de lock-in écosystémique.

Recommandation finale

Pour la plupart des déploiements enterprise en 2026, achetez un runtime MCP. Le profil de déploiement détermine comment le runtime est déployé, pas s’il faut le déployer.

Uniquement propriétaire-interne. La sensibilité des données est le signal d’achat le plus fort, pas un déclencheur de build. Les systèmes legacy qui hébergent des données propriétaires sont précisément là où Arcade est sollicité. C’est là que la douleur opérationnelle est la plus vive et que les responsables sécurité et conformité ont la responsabilité la plus directe. Un pipeline OAuth personnalisé maintenu par une petite équipe, aucun responsable sécurité ne veut le défendre lors d’un audit réglementaire. Un runtime audité, certifié SOC 2 Type 2, ayant déjà passé un examen tiers, est beaucoup plus facile à justifier.

Schéma recommandé : construire des serveurs MCP personnalisés avec l’Arcade MCP Framework, les exécuter dans votre VPC ou on-prem, et créer une gateway MCP dans le runtime pour les connecter au plan de contrôle Arcade. Pour les environnements où même le plan de contrôle doit rester dans l’infrastructure client, exécutez le runtime en self-hosted. Les données restent dans votre périmètre. Le runtime gère l’auth, l’OBO, les identifiants vaultés, les journaux d’audit et la gouvernance.

Pour les déploiements entièrement air-gappés sans sortie réseau externe, exécutez un runtime self-hosted entièrement dans votre infrastructure. La couche runtime est identique à la version cloud ; seul le mode de déploiement change. Ne construisez votre propre runtime que si le déploiement interdit également les logiciels de vendors tiers.

SaaS dominant. Dès que votre workflow agentique doit toucher Google Workspace, Microsoft, Salesforce, GitHub ou Slack, vous achetez. Le runtime gère le cycle de vie OAuth, la dérive de schéma et la maintenance des outils pour des centaines d’APIs SaaS que votre équipe devrait sinon reconstruire. L’écart de sécurité est le plus important dans ce profil. Tout comme l’écart opérationnel.

Mixte (la majorité des entreprises). Les agents interrogent des bases de données internes propriétaires, synthétisent ces données et agissent dans des applications SaaS publiques. Les équipes aux besoins mixtes n’ont pas à choisir entre sécurité propriétaire et couverture SaaS. Adoptez un runtime MCP, comme Arcade.dev, pour la couverture SaaS, puis créez une gateway MCP dans le runtime pour connecter les serveurs MCP internes (ou les serveurs personnalisés construits avec le Arcade MCP Framework) au même plan de contrôle. Les deux surfaces héritent des mêmes contrôles de sécurité et d’audit, avec une autorisation multi-utilisateur qui enveloppe chaque action.

Si vous avez déjà construit des serveurs MCP sans l’Arcade Framework, vous n’avez pas à les réécrire. Connecter un serveur personnalisé existant à Arcade vous donne quand même l’auth, l’audit, la gouvernance et les hooks de politique pré- et post-appel du runtime, en plus de ce que vous avez déjà.

Récapitulatif

Profil de déploiement	Recommandation	Pattern
Propriétaire interne uniquement	Acheter un MCP runtime	Construisez des serveurs MCP personnalisés sur l’Arcade MCP Framework, faites-les tourner dans votre VPC ou on-prem, et créez une passerelle MCP dans le runtime pour les atteindre. Self-hosted pour les environnements où le plan de contrôle doit rester dans l’infrastructure client.
Totalement air-gapped (pas d’egress externe)	Acheter un MCP runtime, self-hosted	Faites tourner le runtime self-hosted d’un éditeur entièrement dans votre infrastructure. Ne construisez le vôtre que si le déploiement interdit aussi les logiciels tiers.
SaaS dominant	Acheter un MCP runtime	Adoptez le runtime directement. Il gère le cycle de vie OAuth, la dérive de schéma et la maintenance des outils pour des centaines d’APIs SaaS.
Mixte propriétaire + SaaS	Acheter un MCP runtime	Arcade pour la couverture SaaS. Une passerelle MCP créée dans le runtime relie les serveurs MCP internes (construits avec ou sans l’Arcade Framework) au même plan de contrôle.

Check-list de décision

Passez votre plan de déploiement en revue avec ces cinq questions :

1. Vos agents vont-ils servir plusieurs utilisateurs avec des périmètres de permissions différents ?
2. Avez-vous besoin de journaux de niveau audit reliant chaque appel d’outil à un utilisateur, un agent et un système cible précis ?
3. Certains de vos agents déclenchent-ils des actions asynchrones qui dépassent les timeouts standard des requêtes LLM ?
4. Vous connectez-vous à cinq APIs SaaS externes ou plus à l’échelle de l’organisation ?
5. Vos contraintes réglementaires sont-elles si strictes qu’aucun egress réseau externe n’est autorisé, même via une passerelle tournant dans votre propre réseau ?

Comment lire les réponses :

• « Oui » à l’une des cinq questions : achetez un MCP runtime.
• Sinon : vérifiez la compatibilité avec les trois cas de construction décrits dans « Quand construire son propre runtime » avant de vous lancer dans le DIY.

Conclusion

Les déploiements qui calent en 2026 échouent sur le risque : une auth impossible à auditer, des credentials qui traînent dans la fenêtre de contexte d’un LLM, et un rayon d’impact sécurité que personne dans la salle ne sait délimiter. Les données sensibles rehaussent encore la barre, c’est pourquoi les scénarios propriétaires appellent à acheter, pas à construire. Reconstruire des pipelines OAuth et des registres de schémas est un mauvais usage du temps des ingénieurs seniors, et la voie DIY cesse de produire des gains dès qu’un second utilisateur ou un audit réglementaire entre dans l’équation.

Le MCP runtime d’Arcade.dev offre la gouvernance du cycle de vie des agents, l’autorisation des agents et un catalogue d’outils optimisé pour les agents en une seule couche.

Prochaine étape : réservez un appel technique de découverte de 30 minutes avec l’équipe Arcade pour parcourir l’architecture d’autorisation multi-utilisateurs et les options de déploiement adaptées à votre environnement.

Ou démarrez dans le playground Arcade. Connectez un outil, exécutez une action limitée à un utilisateur, et observez comment le runtime gère OAuth, les politiques et l’audit dans une seule trace.

Foire aux questions

Quelle est la différence entre un serveur MCP et un MCP runtime ?

Un serveur MCP est un endpoint unique qui expose des outils. Un MCP runtime est la couche d’exécution qui héberge, sécurise et gouverne ces serveurs. Le runtime gère les complexités de production (autorisation multi-utilisateurs, load balancing, journalisation des audits) que les serveurs individuels ne couvrent pas.

Comment les MCP runtimes gèrent-ils les limites de débit et les tâches longues ?

Ils utilisent la spécification MCP Tasks asynchrone : un identifiant de tâche est renvoyé immédiatement pendant que le runtime gère le traitement en arrière-plan. Il prend en charge les limites de débit propres à chaque API, les retries avec backoff et les basculements de connexion. Votre agent interroge le résultat final sans gérer l’état d’exécution.

Pourquoi l’autorisation multi-utilisateurs est-elle si complexe pour les agents IA personnalisés ?

L’autorisation multi-utilisateurs exige une gestion des credentials dynamique et juste-à-temps pour bloquer les attaques par injection de prompt qui compromettent le compte complet d’un utilisateur. Les implémentations maison doivent orchestrer de manière sécurisée des flux de tokens « On-Behalf-Of » complexes, stocker les credentials hors de la fenêtre de contexte LLM, gérer une rotation stricte des refresh tokens et appliquer des politiques d’accès granulaires au moment de l’exécution.

Peut-on combiner des serveurs MCP personnalisés avec un MCP runtime ?

Oui. Serveurs MCP personnalisés et runtimes ne sont pas des alternatives. Dans les deux cas, vous construisez des serveurs MCP personnalisés pour vos systèmes internes propriétaires. La question est de savoir si vous construisez aussi la couche runtime qui les enveloppe. Les runtimes supportent les architectures hybrides : des serveurs personnalisés qui font tourner des outils propriétaires dans votre VPC se connectent au plan de contrôle du runtime via une passerelle ou un tunnel sécurisé. Cela gouverne les outils SaaS publics et les outils internes personnalisés via un plan de contrôle unique. Les serveurs construits sur le framework open source du runtime héritent automatiquement de l’auth et de l’audit. Les serveurs existants construits sans le framework se connectent au runtime et bénéficient quand même de ses hooks d’auth, d’audit et de politique, sans réécriture.

Quand faut-il construire sa propre couche runtime plutôt qu’acheter un MCP runtime ?

Construisez votre propre runtime si vous avez un périmètre mono-utilisateur sans besoin multi-utilisateurs, si l’infrastructure d’agents est votre produit principal, ou si vous contrôlez chaque API du pipeline sans SaaS tiers. Les données sensibles seules ne justifient pas de construire. Les déploiements air-gapped sont couverts par les runtimes self-hosted d’éditeurs qui les proposent. Dans tous les autres cas, achetez un runtime.

À partir de quand acheter un MCP runtime devient-il moins cher ?

Dès que vous gérez plusieurs intégrations et un OAuth multi-utilisateurs. Au-delà de trois intégrations, la maintenance et la sécurité dépassent le coût d’usage du runtime.

Les runtimes MCP exposent-ils des tokens OAuth ou des credentials au LLM ?

Non. Le runtime conserve les credentials dans un vault et émet des tokens à portée limitée, juste à temps pour l’exécution des outils, sans jamais placer de secrets dans le contexte du modèle.

Quelles fonctionnalités de sécurité et de conformité doit inclure un runtime MCP enterprise ?

Autorisation post-prompt, application du principe du moindre privilège, journaux d’audit immuables (compatibles OpenTelemetry), vaulting et rotation des secrets, contrôles admin sur l’accès et la visibilité des outils.

Qu’est-ce que l’autorisation « post-prompt » (on-behalf-of) pour les agents IA ?

L’autorisation post-prompt signifie que le runtime autorise et exécute chaque appel d’outil en utilisant les permissions de l’utilisateur demandeur au moment de l’exécution, plutôt qu’un compte de service partagé ou des tokens utilisateur injectés dans les prompts.

Quelle latence un runtime MCP introduit-il ?

Un léger overhead lié aux vérifications d’autorisation par outil et à la résolution de tokens juste à temps. Cet overhead reste une fraction de la latence d’inférence du LLM et des API SaaS en aval.

Un runtime MCP peut-il fonctionner dans un VPC privé ou un environnement hybride ?

Oui. La passerelle MCP du runtime permet aux serveurs MCP internes de tourner dans votre VPC pendant que la gouvernance et le routage restent centralisés. Le déploiement self-hosted fait tourner l’intégralité du runtime dans votre propre infrastructure.

Comment les runtimes MCP facilitent-ils l’audit logging et la réponse aux incidents ?

Ils enregistrent qui a demandé l’action, quel outil a été appelé, les paramètres, les résultats et les horaires. Tout est exportable vers un SIEM via OpenTelemetry pour la conformité et les investigations.

Comment les runtimes MCP gèrent-ils les changements d’API SaaS et la dérive de versions ?

Le fournisseur maintient les schémas d’outils et met à jour les intégrations de façon centralisée. Cela réduit les ruptures dues aux dépréciations et garantit des définitions d’outils cohérentes entre les agents.

Peut-on démarrer en DIY et migrer vers un runtime plus tard ?

Oui. Les équipes commencent en DIY pour les prototypes, puis migrent vers un runtime quand l’auth multi-utilisateur, la gouvernance et la charge opérationnelle deviennent des exigences de production.