MCP, API, connecteur ou n8n : quelle architecture choisir avec ChatGPT ?

Le vrai problème n'est pas MCP, mais le choix de l'architecture

Une entreprise qui veut exploiter ses données depuis ChatGPT rencontre rapidement plusieurs options : utiliser une app déjà disponible, appeler directement une API, construire un serveur MCP, orchestrer des workflows avec n8n ou développer une application spécifique. Le risque est de choisir la technologie avant d'avoir défini le besoin.

Avant de parler d'outil, il faut distinguer quatre fonctions :

• accéder à une donnée : retrouver un client, un solde, une commande ou un indicateur ;
• exécuter une action métier : créer une tâche, modifier une opportunité, déposer une demande ;
• orchestrer un processus : enchaîner plusieurs systèmes, conditions et contrôles ;
• automatiser un traitement : déclencher une opération selon un horaire ou un événement, sans question utilisateur.

Un serveur MCP peut être pertinent pour le premier ou le deuxième besoin, n8n pour le troisième ou le quatrième, et une API peut être utilisée dans presque toutes ces architectures. Les opposer systématiquement conduit donc souvent à poser la mauvaise question.

MCP : à quoi sert réellement le protocole ?

Le Model Context Protocol (MCP) est un standard ouvert permettant à une application IA d'accéder de manière standardisée à des capacités externes. Un serveur MCP peut notamment exposer des outils, des ressources et, selon les usages, des prompts à un client compatible.

Le protocole standardise donc la manière dont une application IA découvre et appelle des capacités. Il ne définit pas à lui seul la logique métier, la qualité des données ni la politique de sécurité de l'entreprise.

La spécification MCP actuelle a fortement évolué en 2026, notamment vers un cœur de protocole sans état côté HTTP. Pour un projet métier, ce détail d'implémentation compte lors du développement du serveur, mais il ne change pas la question fonctionnelle : quelles capacités faut-il réellement exposer au modèle ?

Ce que MCP ne remplace pas

Ajouter MCP ne transforme pas automatiquement un système existant en architecture fiable. Le protocole apporte une interface standardisée, mais les responsabilités métier restent ailleurs.

En pratique, MCP est une couche d'intégration. Une architecture robuste conserve généralement les règles critiques dans un service métier, une API ou une application testable, plutôt que de les déplacer dans les instructions données au modèle.

MCP ou API : faut-il vraiment choisir ?

Pas nécessairement. Une API et MCP interviennent souvent à des niveaux différents. L'API expose une fonction ou des données du système métier ; MCP rend cette capacité accessible de manière standardisée à une application IA.

Quand appeler directement une API ?

Un appel API direct est souvent suffisant lorsque la fonction est connue à l'avance, que le traitement est déterministe et que l'application contrôle précisément les paramètres transmis et le résultat attendu.

Quand ajouter MCP devant l'API ?

MCP devient intéressant lorsque l'utilisateur formule une demande en langage naturel et que l'application IA doit choisir parmi plusieurs capacités disponibles. Le serveur MCP constitue alors une façade adaptée au modèle, tandis que l'API continue d'assurer l'accès au système métier.

App ChatGPT existante ou intégration MCP personnalisée ?

Si une app ChatGPT existante couvre déjà le besoin, elle constitue généralement le point de départ le plus simple. OpenAI permet également de créer des apps personnalisées basées sur MCP pour relier ChatGPT à des outils et données internes.

L'Apps SDK d'OpenAI repose sur MCP et permet de construire des expériences personnalisées dans ChatGPT. Les fonctions disponibles, notamment les actions d'écriture, dépendent toutefois du type d'espace de travail, des autorisations et des capacités proposées au moment du déploiement.

Autre contrainte concrète : ChatGPT se connecte à des serveurs MCP distants. Un serveur uniquement disponible sur un poste local ou un réseau privé nécessite donc une solution d'accès adaptée, par exemple le mécanisme de tunnel sécurisé proposé par OpenAI pour les environnements compatibles.

MCP et n8n : des rôles différents, parfois complémentaires

Présenter MCP et n8n comme deux concurrents conduit aujourd'hui à une comparaison artificielle. n8n est un outil d'automatisation de workflows, capable de déclencher des traitements selon un horaire ou un événement, mais il sait également exposer ou consommer des capacités MCP.

Cas 1 : n8n seul pour un processus automatisé

Exemple : chaque matin, détecter les commandes en retard et notifier le responsable concerné. Il n'y a pas besoin d'une conversation pour déclencher le processus.

Cas 2 : MCP pour une interaction à la demande

Exemple : « Quel est le statut de la commande 4582 ? ». L'utilisateur interroge ChatGPT ; une capacité MCP appelle ensuite le service ou l'API appropriée pour produire la réponse.

Cas 3 : MCP + n8n

n8n dispose aujourd'hui de composants MCP côté serveur et côté client. Il peut donc exposer certains workflows à un client MCP ou, inversement, utiliser des outils fournis par un serveur MCP externe. Le choix porte alors sur la responsabilité de chaque couche, pas sur un duel « MCP contre n8n ».

Quand une application ou un script dédié reste préférable

Toutes les intégrations impliquant un LLM n'ont pas besoin d'être pilotées par un LLM. Une application, un service backend ou un script reste souvent préférable lorsque le comportement doit être strictement prévisible.

• logique métier critique ou fortement réglementée ;
• forte volumétrie ou contraintes de performance ;
• calculs complexes nécessitant des tests reproductibles ;
• transactions sensibles avec contrôles stricts ;
• interface métier dédiée ;
• workflow dont toutes les étapes sont connues et déterministes.

Une application dédiée peut d'ailleurs utiliser l'API OpenAI et des serveurs MCP distants sans imposer l'interface ChatGPT à ses utilisateurs. L'architecture devient alors : application métier → modèle → outils MCP/API → système d'information.

Cas concret : ChatGPT + MCP + Eurécia

Prenons un besoin RH simple : permettre à un utilisateur autorisé de poser une question dans ChatGPT sur les données gérées dans Eurécia, sans demander au modèle de connaître ni de reproduire toute la logique du logiciel RH.

Le serveur MCP expose uniquement les capacités utiles au modèle. Le service métier applique les validations nécessaires avant d'appeler l'API Eurécia. L'authentification, les permissions, la journalisation et la gestion des erreurs traversent l'ensemble de la chaîne.

Cette séparation évite de transformer ChatGPT en nouvelle source de vérité. Les données restent dans le système métier, et l'IA devient une interface supplémentaire pour y accéder de manière contrôlée.

Voir le cas détaillé : architecture ChatGPT + MCP appliquée à Eurécia.

Fiabilité, permissions et sécurité : le vrai sujet

Le choix entre MCP, API ou n8n est secondaire si l'architecture ne répond pas correctement aux questions de données, de droits et de traçabilité. C'est particulièrement vrai dès qu'une IA peut agir sur un système métier.

Conserver une source de vérité identifiable

Le CRM, l'ERP ou l'application métier doit rester la source de référence lorsqu'elle porte la donnée métier. Une réponse produite par ChatGPT ne doit pas devenir une copie concurrente de cette donnée.

Contrôler la fraîcheur des données

Une documentation stable peut être synchronisée ou indexée. Un stock disponible, un solde client ou l'état d'une commande nécessite généralement une interrogation suffisamment récente du système de référence.

Séparer authentification et autorisation

Savoir qui est l'utilisateur ne suffit pas. Il faut encore vérifier s'il a le droit de lire la donnée ou d'effectuer l'action demandée. Cette vérification doit rester dans une couche contrôlée et ne pas dépendre d'une simple instruction textuelle donnée au modèle.

Séparer lecture et écriture

« Quel est le statut de cette facture ? » et « Valide cette facture » ne présentent pas le même niveau de risque. Les outils de lecture et d'écriture doivent pouvoir être distingués, autorisés séparément et, lorsque nécessaire, soumis à une confirmation ou une validation humaine.

Tracer les appels et les erreurs

Une architecture exploitable en production doit permettre de retrouver qui a demandé quoi, quel outil a été appelé, avec quel résultat et quelle erreur éventuelle. n8n, les services backend et les systèmes métier ont chacun leur rôle dans cette observabilité.

Limiter les outils exposés

Exposer toutes les fonctions d'un ERP « au cas où » n'améliore pas le système. Cela augmente la surface de risque, la complexité de sélection des outils et les possibilités d'erreur. Le principe du moindre privilège reste une règle saine, y compris lorsque l'interface est conversationnelle.

Grille de décision : quelle architecture choisir ?

Il n'existe pas une architecture universelle. La bonne première option dépend surtout de la nature du besoin.

Cette grille donne un point de départ, pas une recette automatique. Deux entreprises utilisant le même ERP peuvent avoir besoin d'architectures différentes selon leurs droits, leurs volumes, leur réseau et le niveau de criticité des actions.

Quatre architectures types selon le besoin métier

Outil métier : interroger une application à la demande

Pour consulter des informations métier en langage naturel, une architecture ChatGPT → MCP → service métier → API permet de conserver l'application métier comme source de vérité tout en exposant uniquement les opérations nécessaires. Ce schéma peut s'appliquer à un ERP, un CRM, un logiciel de maintenance, un outil RH ou toute autre application disposant d'une interface exploitable.

CRM : rechercher et synthétiser les informations commerciales

Un serveur MCP peut proposer des outils comme « rechercher un compte », « récupérer les opportunités ouvertes » ou « obtenir les dernières interactions ». Une action de modification du CRM doit être traitée séparément et avec des droits plus stricts qu'une simple lecture.

Finance : préparer les données avant l'analyse

Il n'est pas toujours souhaitable que ChatGPT interroge directement l'ERP financier. Un workflow n8n ou un processus ETL peut d'abord consolider les données dans une base de reporting, puis MCP ou une API expose uniquement les indicateurs nécessaires à l'analyse.

ERP : distinguer consultation et opération

Lire l'état d'une commande ou rechercher une référence peut être exposé comme capacité de lecture. Modifier une commande, valider un paiement ou créer un mouvement de stock impose des contrôles supplémentaires. Le même protocole peut transporter les deux usages ; l'architecture de sécurité ne doit pas pour autant les considérer comme équivalents.

Les mauvaises utilisations de MCP

MCP apporte une vraie valeur quand il répond à un problème d'intégration avec une application IA. Il devient une couche inutile lorsqu'il est ajouté uniquement parce que le protocole est disponible.

• Utiliser MCP pour une simple tâche planifiée alors qu'un workflow n8n ou un job suffit.
• Exposer un catalogue énorme d'outils au lieu de présenter quelques capacités compréhensibles et contrôlées.
• Confondre MCP avec un système de permissions et oublier les droits applicatifs réels.
• Donner au modèle un accès direct à une base de production sans couche métier ni validation.
• Mélanger lecture et écriture dans des outils trop génériques.
• Construire un serveur MCP sur mesure lorsqu'une app existante couvre correctement le besoin.
• Déplacer la logique critique dans le prompt au lieu de la conserver dans du code testable.