Connecter votre ERP à un agent IA via MCP : Odoo, Sage, Dynamics

Pendant des années, connecter un outil d'intelligence artificielle à un ERP signifiait écrire des intégrations personnalisées, maintenir des API privées et accepter que toute mise à jour logicielle casse le connecteur. En 2024, Anthropic a publié le Model Context Protocol (MCP), un standard ouvert qui change la donne : au lieu d'intégrations point à point, l'agent IA se connecte à l'ERP via un serveur MCP qui expose des outils typés, et l'agent décide quand et comment les utiliser selon le contexte de la conversation. En 2025, Microsoft, Google, OpenAI et les principaux éditeurs d'ERP ont commencé à publier leurs propres serveurs MCP ou à annoncer leur feuille de route. En 2026, connecter Odoo, Sage ou Dynamics à un agent IA via MCP n'est plus une expérience de laboratoire : c'est un projet réalisable pour une PME disposant de ressources techniques normales.

Cet article explique ce qu'est le protocole MCP, pourquoi il simplifie l'intégration des ERP avec l'IA, comment il se déploie sur les trois systèmes les plus courants dans les PME espagnoles et quels cas d'usage offrent un retour réel dès le premier trimestre.

Qu'est-ce que MCP et pourquoi est-il important pour l'intégration ERP et IA

Le Model Context Protocol est un protocole client-serveur open source qui standardise la façon dont un grand modèle de langage (LLM) accède aux outils externes, aux fichiers et aux données structurées. Avant MCP, chaque fournisseur d'IA définissait son propre schéma de « tool calling » ; le développeur devait adapter le connecteur à chaque modèle. Avec MCP, le serveur déclare ses outils dans un format JSON standard, et tout client compatible (Claude, GPT-4o, Gemini, modèles open source avec support MCP) peut les utiliser sans modification.

Appliqué à un ERP, le serveur MCP agit comme une couche d'accès typée : il expose des opérations telles que get_commande, lister_factures_en_attente, mettre_a_jour_statut_bon_livraison ou creer_devis_client. L'agent IA appelle ces opérations de manière sécurisée, avec les autorisations définies par l'administrateur système. L'ERP ne « sait » pas qu'il y a une IA de l'autre côté ; il reçoit simplement des requêtes sur son API REST ou RPC comme s'il s'agissait de n'importe quelle autre intégration.

Différences clés par rapport à une intégration traditionnelle

Comment fonctionne le serveur MCP pour ERP : architecture de base

L'architecture comporte trois éléments : le client MCP (l'agent IA ou l'application qui l'héberge), le serveur MCP (un processus qui traduit les requêtes de l'agent en appels vers l'ERP) et l'ERP lui-même avec son API native.

Le serveur MCP peut s'exécuter sur le même réseau que l'ERP (on-premise ou cloud privé) ou être exposé en tant que microservice cloud avec authentification OAuth 2.0. La communication entre client et serveur MCP s'effectue via JSON-RPC sur HTTP/SSE (Server-Sent Events pour le streaming) ou via stdio lorsque le processus s'exécute localement. En production, la configuration habituelle est un endpoint HTTPS avec un token Bearer par tenant.

Flux d'une requête typique

1. L'utilisateur saisit : « Combien devons-nous au fournisseur García Logistique à la clôture du mois ? »
2. L'agent identifie qu'il a besoin des données du module comptes fournisseurs de l'ERP.
3. Il appelle l'outil obtenir_solde_fournisseur du serveur MCP avec le paramètre nom="García Logistique".
4. Le serveur MCP traduit cela en un appel API ERP (par exemple, GET /api/account.move?partner=García+Logistique&state=posted dans Odoo).
5. Le serveur MCP renvoie le résultat structuré à l'agent.
6. L'agent rédige la réponse en langage naturel, ajoute la ventilation par échéance et, s'il en a la permission, propose de lancer le paiement.

Le temps de réponse de bout en bout — incluant l'appel au LLM — est généralement compris entre 3 et 8 secondes pour les requêtes simples, et entre 10 et 20 secondes pour les requêtes qui enchaînent plusieurs outils. Si votre cas nécessite une réponse immédiate (par exemple, dans un canal vocal), l'architecture se complète par des caches de données précalculées.

Implémentation avec Odoo (versions 16 et 17)

Odoo est l'ERP open source le plus déployé dans les PME espagnoles. Depuis la version 16, il expose une API JSON-RPC stable et une API REST optionnelle qui prend en charge l'authentification par clé d'API par utilisateur. En 2025, la communauté a publié plusieurs serveurs MCP pour Odoo ; en 2026, Odoo S.A. a publié son propre serveur MCP officiel dans la version 17.1.

Étapes pour connecter Odoo à un agent IA

1. Générer une clé d'API pour l'utilisateur technique de l'agent (menu Paramètres → Utilisateurs → Clé d'API). Appliquer les permissions minimales : uniquement les modèles que l'agent doit lire ou écrire.
2. Déployer le serveur MCP Odoo : installer le package odoo-mcp-server (disponible sur PyPI ou en tant que module communautaire) sur un serveur accessible par l'agent. Configurer l'URL Odoo, la base de données et la clé d'API dans des variables d'environnement.
3. Déclarer les outils nécessaires dans le fichier de configuration du serveur : par exemple, activer sale.order, account.move, stock.picking et désactiver le reste pour réduire la surface d'attaque.
4. Connecter l'agent au serveur MCP : dans la configuration du client MCP (Claude Desktop, un bot Teams, un workflow n8n avec nœud MCP), ajouter l'URL du serveur et le token Bearer.
5. Tester avec des requêtes en lecture seule avant d'activer les outils d'écriture.

Avec Odoo 17, l'intégration MCP est suffisamment mature pour la production dans les modules ventes, achats, facturation et entrepôt. Le module de fabrication (MRP) nécessite un mapping supplémentaire car son modèle de données est plus complexe.

Implémentation avec Sage (Sage 50, Sage 200 et Sage X3)

L'écosystème Sage comporte trois niveaux avec des degrés d'ouverture d'API différents. Sage 50 propose une intégration via ODBC ou via l'API cloud (Sage Business Cloud API) avec authentification OAuth 2.0. Sage 200 dispose d'une API REST depuis la version 2021 R2, plus complète et adaptée au serveur MCP. Sage X3 dispose d'une API SOAP et d'une API REST (module Web Services) qui constitue la base recommandée pour MCP dans les déploiements enterprise.

En pratique, le schéma le plus courant dans les PME espagnoles utilisant Sage 200 consiste à déployer le serveur MCP sur le même serveur Windows où Sage s'exécute (en tant que service Windows ou conteneur Docker sur Windows Server 2022), et à le faire consommer par l'agent depuis le réseau d'entreprise. Pour un accès distant sécurisé, il est tunnelisé via un proxy HTTPS inverse avec certificat TLS.

Un point critique avec Sage : l'API REST de Sage 200 n'expose pas tous les champs nativement. Dans certains modules (comptabilité analytique, gestion de projets), le serveur MCP doit appeler directement des procédures stockées SQL Server, avec les risques de maintenance que cela implique. Il est conseillé de délimiter le périmètre avant de commencer.

Implémentation avec Microsoft Dynamics 365 Business Central

Business Central est l'ERP Microsoft le plus répandu dans les PME espagnoles de taille intermédiaire comptant entre 20 et 200 employés. Il dispose d'une API OData v4 complète, documentée sur Microsoft Learn, avec prise en charge native d'OAuth 2.0 via Microsoft Entra ID. En mars 2025, Microsoft a publié le dépôt officiel ms-business-central-mcp sur GitHub, avec des outils prédéfinis pour les ventes, la finance, l'inventaire et les projets.

L'avantage de Business Central pour cette architecture est que le serveur MCP peut s'exécuter en tant qu'Azure Function (sans serveur à maintenir) et hérite de l'identité du tenant Microsoft 365. Si vous avez déjà Copilot for Microsoft 365 actif, l'agent MCP peut coexister dans le même environnement Teams sans licence d'infrastructure supplémentaire.

L'accès en écriture dans Business Central nécessite des autorisations de profil spécifiques. Avant d'activer les outils d'écriture (création de commandes, approbation de factures), il est indispensable de revoir les flux d'approbation existants dans Business Central afin que l'agent ne les contourne pas involontairement. La configuration recommandée est que l'agent propose l'action et que l'utilisateur la confirme dans une deuxième étape, plutôt que d'exécuter directement.

Si vous souhaitez approfondir l'intégration d'agents IA avec votre ERP, notre équipe analyse d'abord l'état de l'API de votre version spécifique avant de s'engager sur un périmètre.

Cas d'usage avec un retour réel dans la PME

Tous les cas d'usage agent IA + ERP n'offrent pas le même retour. Voici ceux qui affichent les résultats les plus rapides dans des déploiements réels en 2025 et 2026 :

Consultation de l'état des commandes et des factures en langage naturel

L'équipe de service client ou commerciale peut demander directement : « Quelles commandes de Ferretería López attendent depuis plus de 5 jours sans être livrées ? » et obtenir la réponse sans entrer dans l'ERP. Cela réduit entre 4 et 8 minutes par requête dans les équipes qui traitent de nombreux appels de suivi.

Assistant achats et réapprovisionnement

L'agent consulte le stock minimum configuré, le stock actuel et le délai de livraison du fournisseur, et génère le brouillon de bon de commande. Le responsable achats révise et approuve. Ce flux est particulièrement utile dans les entreprises de plus de 500 références actives où la gestion manuelle des points de réapprovisionnement consomme plusieurs heures par semaine.

Analyse de rentabilité des clients ou des projets

En combinant le module facturation et le module coûts de l'ERP, l'agent peut répondre en quelques secondes : « Quelle est la marge brute réelle du projet 2025-047 après imputation des heures des trois derniers mois ? », sans que le contrôleur de gestion doive extraire les données vers Excel.

Automatisation des tâches administratives répétitives

Approuver des bons de livraison vérifiés par rapport à la commande d'origine, générer des factures récurrentes, mettre à jour les tarifs clients par segment : ce sont des tâches que l'agent peut exécuter en masse avec une supervision humaine ponctuelle, plutôt qu'un processus entièrement manuel.

Sécurité et contrôle d'accès : ce qui est indispensable

Le serveur MCP introduit un nouveau point d'accès à l'ERP. Avant de passer en production, vérifiez au moins ces quatre points :

• Principe du moindre privilège : l'utilisateur technique de l'agent dans l'ERP n'a d'autorisations que sur les modules et les champs dont il a besoin. Ne pas utiliser le compte administrateur.
• Audit des appels : le serveur MCP doit consigner chaque outil invoqué, qui l'a invoqué (utilisateur ou session de l'agent) et quels paramètres ont été transmis. De nombreux serveurs MCP open source ne l'implémentent pas par défaut ; il faut l'ajouter.
• Authentification du client MCP : le serveur ne doit pas être accessible sans token. En production, utiliser des tokens à durée de vie courte (TTL maximum de 24 heures) avec rotation automatique.
• Révision des outils d'écriture : avant d'activer tout outil qui modifie des données dans l'ERP, concevoir le flux de confirmation humaine. Un agent qui supprime des enregistrements ou approuve des factures sans supervision peut causer des dommages opérationnels réels.

Dans le contexte de l'AI Act européen, les agents qui prennent des décisions autonomes sur des données financières ou des données clients peuvent être classés comme systèmes d'IA à risque limité ou élevé selon l'usage. Bien que la plupart des cas décrits ici relèvent d'un risque limité ou minimal, il est conseillé de documenter les capacités de l'agent et les contrôles mis en place. Depuis Summum Consultoría, nous accompagnons l'évaluation des risques conformément à l'AI Act lorsque l'agent dispose d'une capacité de décision autonome.

Délais et effort d'implémentation typiques

Les fourchettes incluent le déploiement du serveur MCP, la configuration des outils, les tests d'intégration et la formation de l'équipe qui utilisera l'agent. Elles n'incluent pas le développement de l'agent à partir de zéro ni l'implémentation de l'ERP. Ces délais supposent que l'API de l'ERP est active et documentée dans l'installation du client.

Questions fréquentes

Ai-je besoin d'un ERP dans le cloud pour utiliser MCP, ou cela fonctionne-t-il aussi avec une installation locale ?

MCP fonctionne avec les deux modalités. Dans les installations on-premise, le serveur MCP est déployé sur le même réseau et l'agent IA y accède depuis l'intérieur du périmètre ou via un tunnel sécurisé. L'ERP n'a pas besoin d'être dans le cloud, bien que les installations cloud facilitent l'exposition de l'endpoint. Ce qui est nécessaire, c'est que l'ERP dispose d'une API accessible : REST, JSON-RPC ou OData. Si votre version de Sage ou Dynamics est ancienne et ne dispose pas d'une API moderne, c'est le premier point à résoudre.

L'agent IA peut-il modifier des données dans l'ERP ou seulement les lire ?

Il peut faire les deux, selon les permissions que vous configurez sur le serveur MCP et dans l'ERP lui-même. Dans la plupart des déploiements de première phase, seuls les outils de lecture sont activés pour gagner en confiance. Les outils d'écriture (créer des commandes, mettre à jour des enregistrements, approuver des factures) sont ajoutés dans une deuxième phase, toujours avec une étape de confirmation humaine avant l'exécution de l'action. Il n'est jamais recommandé de donner à l'agent une permission d'écriture sans mécanisme de supervision.

Que se passe-t-il avec les données de mes clients et fournisseurs que l'agent voit dans l'ERP ?

Le serveur MCP agit comme intermédiaire : les données ne sont pas stockées sur le serveur MCP au-delà du temps nécessaire pour répondre à la requête. Cependant, elles transitent bien par le modèle de langage qu'utilise l'agent. Si ce modèle est un service externe dans le cloud (comme l'API d'Anthropic ou Azure OpenAI), les données clients quittent votre périmètre. Pour éviter cela, deux options existent : (1) déployer un LLM propriétaire dans votre propre infrastructure, ou (2) utiliser l'anonymisation des données sur le serveur MCP avant de les envoyer au modèle. Dans les secteurs traitant des données sensibles (santé, finance, données de mineurs), cette décision a des implications directes au regard du RGPD.

MCP est-il compatible avec n8n ou Power Automate pour combiner l'agent avec d'autres flux de travail ?

Oui. Depuis fin 2024, n8n dispose d'un nœud client MCP qui permet d'invoquer des outils de n'importe quel serveur MCP au sein d'un workflow d'automatisation. Power Automate ne dispose pas encore d'un connecteur MCP natif, mais peut appeler le serveur MCP via le connecteur HTTP générique avec authentification Bearer. Dans les déploiements où n8n existe déjà, le connecter au serveur MCP de l'ERP est particulièrement efficace car l'agent peut être combiné avec des déclencheurs (une nouvelle commande dans l'ERP active le workflow) sans infrastructure supplémentaire. L'équipe d'automatisation n8n de Summum IA peut vous aider à concevoir ce type d'architecture hybride.