Une intégration robuste sépare l'interface présentée au modèle, les règles d'autorisation, l'exécution durable et le système qui reste propriétaire de la donnée.
Une équipe autonome ne devrait pas être connectée aux systèmes métier par un mécanisme unique choisi pour sa nouveauté. Une API directe convient à une opération étroite et stable. Un workflow d'intégration convient à un processus long, multi-étapes ou soumis à reprise. MCP devient utile lorsqu'il faut présenter au modèle un catalogue d'outils cohérent et réutilisable. Dans beaucoup d'entreprises, la bonne architecture combine ces trois niveaux au lieu de les mettre en concurrence.
La frontière déterminante ne se situe pas entre ancien et nouveau protocole. Elle sépare l'intention de l'agent de l'effet métier. Le modèle peut demander « créer un dossier fournisseur », mais l'entreprise doit encore authentifier le demandeur, vérifier le mandat de l'équipe, valider les données, appliquer une éventuelle approbation, gérer les doublons et confirmer l'identifiant créé dans le système propriétaire. Le connecteur transporte la demande. Le contrat d'intégration détermine qui garantit chacune de ces étapes.
Le protocole d'outil et le contrat métier ne résolvent pas le même problème
Une API décrit des opérations offertes par un système ou un service. Une fonction outillée peut en masquer les détails et présenter au modèle un schéma d'entrée plus simple. Le Model Context Protocol, dans sa révision stable du 18 juin 2025, standardise notamment l'exposition de ressources, de prompts et d'outils aux applications qui utilisent des modèles. Sa spécification décrit les outils comme des fonctions exécutables que le modèle peut découvrir et appeler.
Cette standardisation résout un vrai problème de portabilité. Une équipe autonome peut consommer des outils décrits selon la même grammaire, même si leurs implémentations sous-jacentes diffèrent. Les schémas d'entrée et de sortie rendent l'appel plus explicite, et la négociation de capacités permet au client et au serveur de savoir quelles fonctions sont disponibles. MCP ne définit toutefois pas la règle métier qui décide si une remise commerciale est acceptable, si un fournisseur peut être activé ou si une écriture comptable peut être passée.
Le contrat métier contient ces invariants. Il précise l'identité au nom de laquelle l'action est réalisée, les préconditions, le système propriétaire, les validations nécessaires, l'effet attendu, la stratégie de reprise et la preuve à conserver. Une intégration reste fiable quand ces règles s'appliquent quel que soit le modèle, le canal conversationnel ou le protocole utilisé pour présenter l'outil. Si elles résident seulement dans une description destinée au modèle, elles deviennent des conseils que l'agent peut mal interpréter au lieu de contrôles exécutables.
Trois patterns avec des responsabilités différentes
Le choix devient plus simple lorsque les options sont comparées selon la nature de l'effet, et non selon la facilité de la première démonstration. Une API directe réduit les intermédiaires, mais transfère au service appelant la gestion de l'authentification, des erreurs et de la reprise. Une plateforme d'intégration ou un moteur de workflow rend les étapes et les transformations explicites. MCP normalise l'interface orientée agent, sans devenir automatiquement le moteur transactionnel situé derrière chaque outil.
| Critère | API directe ou fonction | Workflow ou iPaaS | Serveur MCP |
|---|---|---|---|
| Problème principal | Appeler une opération précise | Orchestrer un processus et ses reprises | Exposer outils et contexte à des modèles |
| Chemin d'exécution | Court et codé dans le service | Étapes, branches, délais et erreurs visibles | Choisi par l'hôte ou le modèle parmi les outils exposés |
| Transformation de données | Développée sur mesure | Mappages et connecteurs centralisés | Limitée au contrat de chaque outil ou déléguée en aval |
| Processus de longue durée | À construire explicitement | Adapté aux attentes, événements et relances | Ne remplace pas un moteur durable |
| Approbation humaine | Contrôle spécifique à développer | Étape métier explicite | Politique d'approbation possible avant l'appel |
| Réutilisation par plusieurs agents | Bibliothèque ou service partagé | Point d'entrée métier partagé | Interface standardisée et découvrable |
| Propriété de la transaction | Service appelant et API cible | Workflow et système propriétaire | Doit rester attribuée à un composant en aval |
| Meilleur contexte | Opération stable, faible nombre de systèmes | Coordination multi-systèmes et effet important | Portefeuille d'outils agentiques évolutif |
Une API directe est souvent le meilleur choix pour une lecture ciblée ou une commande courte dont le contrat est déjà mature. Rechercher un produit par identifiant, calculer un tarif avec un service propriétaire ou déposer un document dans un espace précis ne nécessite pas forcément un orchestrateur supplémentaire. La simplicité reste un avantage si le client limite les paramètres, utilise une identité dédiée, traite les codes d'erreur et vérifie la réponse.
Un workflow devient préférable lorsque l'opération comporte plusieurs engagements. L'onboarding d'un fournisseur peut attendre un document, interroger un registre, faire valider un risque puis créer des objets dans plusieurs systèmes. La documentation Google Cloud distingue l'intégration d'applications, utile pour mapper et échanger des données métier, de l'orchestration de services, utile pour rendre une séquence explicite et observable. Elle montre aussi que les deux mécanismes peuvent être combinés. Cette séparation reflète une responsabilité, pas une préférence de fournisseur.
MCP apporte le plus de valeur lorsque plusieurs agents, modèles ou applications doivent découvrir un même portefeuille de capacités. Un serveur peut publier un outil préparer_dossier_fournisseur avec un schéma stable, alors que son implémentation déclenche un workflow existant. Le modèle n'a pas besoin de connaître les étapes internes, et l'équipe d'intégration peut modifier un connecteur sans changer l'intention proposée à l'agent. MCP devient ainsi une façade orientée agent, tandis que le workflow reste le propriétaire de l'exécution durable.
Une séquence fiable attribue chaque contrôle
Le risque apparaît quand les couches sont empilées sans préciser leurs responsabilités. Un appel peut alors être autorisé par l'hôte agentique, puis exécuté avec un compte technique trop puissant, sans qu'aucun composant ne vérifie le périmètre métier. Le diagramme suivant attribue chaque décision à un acteur et conserve le système métier comme source de vérité sur l'effet final.
Schéma Atlensia : MCP ou une fonction outillée porte l'intention de l'agent, tandis que l'autorisation, la reprise et la confirmation de l'effet restent attribuées à des composants identifiables.
La séquence commence par une intention structurée, et non par des identifiants techniques transmis au modèle. La couche de politique relie l'identité de l'équipe, son rôle, l'organisation concernée et l'action demandée. Elle peut réduire le catalogue visible avant même que le modèle choisisse un outil. La documentation MCP de l'OpenAI Agents SDK illustre ce principe avec des filtres statiques ou dynamiques et des politiques d'approbation, mais ce sont des capacités d'implémentation à configurer, pas une protection automatique.
Le workflow reçoit ensuite une commande métier qui peut être rendue idempotente, c'est-à-dire qu'une nouvelle tentative ne crée pas un second effet. Il valide les données, transforme les formats et ouvre une approbation si le niveau de conséquence l'exige. Le système propriétaire réalise finalement l'écriture et retourne son propre identifiant. Un message « succès » produit par le modèle ou le connecteur ne suffit pas : la confirmation doit provenir du système qui détient réellement l'objet.
En cas d'échec, la responsabilité reste également lisible. Une erreur de schéma revient à la préparation de la demande. Un refus de politique s'arrête avant tout accès aval. Une indisponibilité temporaire peut être reprise par le workflow sans demander au modèle d'improviser une stratégie. Une contradiction métier ou un refus humain renvoie un statut explicite à l'équipe autonome, qui peut demander une précision ou transférer le dossier avec son contexte.
Trois identités doivent rester distinctes
Une intégration agentique implique au moins l'identité de la personne ou du processus à l'origine de la demande, l'identité de travail de l'équipe autonome et l'identité technique utilisée auprès du système cible. Les confondre produit soit un accès trop large, soit une traçabilité trompeuse. Le système doit pouvoir dire qui a demandé, quel rôle autonome a agi, quelle politique a autorisé et quel compte a exécuté.
La spécification d'autorisation MCP du 18 juin 2025 impose aux serveurs HTTP protégés de valider que les jetons leur sont destinés. Elle interdit aussi le transfert inchangé du jeton reçu vers un service aval, car ce comportement peut créer un problème de délégation confuse. Un serveur MCP qui appelle un CRM ou un ERP doit donc utiliser un jeton aval distinct et adapté à cette ressource. Le protocole fournit un cadre d'autorisation, mais l'entreprise doit encore définir les portées, les comptes techniques et la correspondance entre l'identité de travail et les droits métier.
Cette distinction permet d'éviter deux raccourcis. Le premier consiste à donner au serveur MCP un compte administrateur parce qu'il dessert plusieurs outils. Le second consiste à reproduire les droits complets de l'utilisateur dans chaque appel, même lorsque le rôle de l'équipe autonome est plus étroit. Une politique correcte calcule l'intersection entre le mandat, le contexte et l'opération. Elle n'accorde pas automatiquement le droit le plus large disponible dans la chaîne.
Choisir par scénario, puis combiner sans dupliquer les règles
Pour une équipe de support qui consulte l'état d'une commande, une API de lecture bornée peut suffire. La fonction accepte un identifiant, vérifie le périmètre du client et retourne quelques champs. MCP devient intéressant si ce même outil doit être partagé entre plusieurs assistants ou si le catalogue évolue souvent. Ajouter un workflow complet n'apporte de valeur que si la lecture déclenche ensuite des étapes, des délais ou une coordination avec d'autres systèmes.
Pour un remboursement, le centre de gravité change. La décision dépend du montant, du motif, de l'historique et d'une politique. L'effet peut nécessiter une validation, plusieurs écritures et une compensation si l'une échoue. Le modèle peut rassembler les faits et proposer une action via un outil MCP, mais un workflow doit contrôler la transaction. L'API du système financier reste l'exécutant final, et son identifiant sert de preuve.
Pour une recherche documentaire, l'effet reste en lecture et la variété des sources domine. MCP peut alors fournir une interface cohérente vers plusieurs dépôts, avec des outils filtrés selon le rôle. Une plateforme d'intégration reste utile si les formats doivent être synchronisés ou si des événements alimentent un index, mais elle n'est pas nécessaire à chaque requête. Le meilleur pattern suit la forme du travail plutôt qu'une règle d'architecture uniforme.
La mise en oeuvre devrait commencer par un seul effet métier. Il faut écrire son contrat indépendamment du canal : entrée minimale, préconditions, autorité, approbation, résultat, erreur, reprise et preuve. L'équipe peut ensuite choisir la façade agentique et le moteur d'exécution. Cette méthode évite de réimplémenter les règles dans une description MCP, un prompt, un workflow et une API. Une règle critique doit avoir un propriétaire exécutable unique, même si plusieurs couches l'observent et la tracent.
Conclusion
API directe, workflow d'intégration et MCP ne sont pas trois générations successives d'une même technologie. L'API réalise une opération, le workflow coordonne un processus et MCP présente des capacités aux modèles selon une interface standard. Le choix dépend donc de la stabilité de l'appel, de la durée de l'effet, du nombre de systèmes, du besoin de reprise et du nombre d'agents qui doivent réutiliser la capacité.
Pour Atlensia, la combinaison la plus robuste consiste souvent à exposer une intention métier étroite à l'équipe autonome, à filtrer l'outil selon son mandat, puis à confier les transactions importantes à un workflow gouverné. Le système propriétaire confirme l'effet et fournit la preuve. Avant de connecter un nouveau système, la prochaine étape utile n'est pas de choisir un protocole. C'est d'écrire le contrat du premier effet métier et d'attribuer clairement chaque contrôle.
Sources primaires et références
Atlensia, présentation de l'Operating Layer et des équipes autonomes
Model Context Protocol, vue d'ensemble des primitives serveur, révision du 18 juin 2025
Model Context Protocol, spécification des outils, révision du 18 juin 2025
Model Context Protocol, spécification d'autorisation, révision du 18 juin 2025
OpenAI Agents SDK, documentation MCP, filtrage d'outils et approbations
Google Cloud, choisir entre Application Integration et Workflows, août 2026
Microsoft Learn, création de connecteurs personnalisés Power Platform