Connecter son ERP à l'IA avec le MCP : l'exemple Divalto

La plupart des assistants IA déployés en entreprise souffrent du même handicap : ils sont brillants pour rédiger un mail ou résumer un compte rendu, mais totalement aveugles dès qu'il s'agit de répondre à une question métier précise. Combien de palettes du produit référence A4521 sont disponibles à l'entrepôt de Vénissieux ? Quel est l'encours du client Bernard Industries ce matin ? Où en est la commande 2026-04417 expédiée la semaine dernière ? Ces réponses vivent dans l'ERP, et tant que l'IA n'y accède pas, elle reste un gadget conversationnel. Le Model Context Protocol, le MCP, change radicalement la donne en offrant une manière standardisée, sécurisée et auditable de connecter un assistant IA aux données et aux actions de votre système de gestion. Dans cet article, l'équipe de Made in AI, agence IA à Lyon spécialisée dans l'audit, la formation Qualiopi et les solutions IA pour PME et ETI industrielles d'Auvergne-Rhône-Alpes, vous explique en détail comment connecter un ERP à l'IA via le MCP, avec un exemple concret et fil rouge sur Divalto, puis une déclinaison vers SAP, Sage, Cegid, les ERP maison, le CRM et la GED.

Le vrai problème : des assistants IA déconnectés de vos données métier

Depuis l'arrivée des grands modèles de langage dans les usages professionnels, beaucoup d'entreprises de la région lyonnaise ont testé un assistant IA. Le constat est presque toujours le même : l'outil impressionne sur des tâches génériques, puis déçoit dès qu'on lui demande quelque chose d'ancré dans la réalité de l'entreprise. La raison est structurelle, pas anecdotique.

Un modèle entraîné sur le passé, pas sur votre stock d'aujourd'hui

Un modèle de langage est figé au moment de son entraînement. Il ne connaît ni vos clients, ni vos tarifs négociés, ni votre niveau de stock, ni l'état d'avancement de vos ordres de fabrication. Lui poser une question sur la commande d'un client revient à demander à quelqu'un qui n'a jamais mis les pieds dans votre entreprise de deviner une donnée qu'il n'a jamais vue. Au mieux, il refuse de répondre. Au pire, il invente une réponse plausible mais fausse, ce que l'on appelle une hallucination, et c'est précisément ce qui ruine la confiance des utilisateurs métier.

Le copier-coller manuel ne passe pas à l'échelle

La parade improvisée consiste à copier-coller des extraits de l'ERP dans la fenêtre de chat. Cela fonctionne pour une demande ponctuelle, mais c'est ingérable au quotidien : l'utilisateur doit savoir où trouver la donnée, l'extraire proprement, la coller, vérifier qu'elle est à jour. On déplace le travail au lieu de le supprimer. Et l'on prend le risque d'exposer des données sensibles dans un outil grand public non maîtrisé. Pour une PME industrielle qui traite des centaines de commandes par semaine, cette approche n'a aucun avenir.

Les silos applicatifs aggravent la cécité

Dans une entreprise type d'Auvergne-Rhône-Alpes, la donnée utile est éclatée : l'ERP gère commandes, stocks et facturation, le CRM gère la relation commerciale, la GED archive devis et contrats, un fichier de production suit les ordres de fabrication. Un assistant IA réellement utile doit pouvoir traverser ces silos pour répondre à une question simple comme : ce client a-t-il un litige en cours qui justifie de bloquer sa nouvelle commande ? Sans connexion structurée, c'est impossible.

Le coût caché de la friction informationnelle

Derrière ces difficultés se cache un coût rarement chiffré : la friction informationnelle. Combien de fois par jour un assistant ADV interrompt-il sa tâche pour aller chercher une donnée dans Divalto ? Combien de minutes un commercial passe-t-il à reconstituer l'historique d'un client avant un rendez-vous ? Combien d'erreurs de délai sont commises faute d'avoir vérifié le stock en temps réel ? Mises bout à bout, ces micro-pertes représentent souvent plusieurs heures par semaine et par collaborateur. Dans une PME industrielle de cinquante personnes, cela se compte en équivalents temps plein. L'enjeu d'une connexion ERP vers IA n'est donc pas un gadget technologique, mais une question de productivité et de qualité de service mesurable.

Pourquoi les solutions génériques ne suffisent pas

On pourrait penser qu'un chatbot d'entreprise sur étagère règle le problème. En pratique, ces solutions génériques ignorent la singularité de vos données et de vos processus. Elles ne connaissent pas la structure de votre catalogue, vos règles de tarification, vos circuits de validation, vos dépôts. Elles ne savent pas qu'une commande passe par sept statuts dans votre Divalto, ni que tel client bénéficie d'une remise contractuelle particulière. La valeur naît précisément de l'ancrage dans votre réalité métier, et cet ancrage exige une connexion structurée plutôt qu'un outil prêt à l'emploi qui resterait à la surface.

Qu'est-ce que le MCP, le Model Context Protocol ?

Le Model Context Protocol, abrégé MCP, est un protocole ouvert qui standardise la façon dont une application d'IA se connecte à des sources de données et à des outils externes. Pensez-le comme un port universel entre les assistants IA et le monde extérieur : au lieu de redévelopper une intégration sur mesure pour chaque modèle et chaque source, on parle une langue commune. C'est conceptuellement comparable à ce qu'a été le port USB pour les périphériques informatiques, ou une prise normalisée pour les appareils électriques.

Une architecture client / serveur simple à comprendre

Le MCP repose sur deux rôles. D'un côté, le client MCP est intégré à l'application qui héberge l'assistant IA : ce peut être un agent conversationnel interne, un outil comme Claude, ou un agent développé sur mesure. De l'autre, le serveur MCP est un petit programme qui se place devant une ressource, par exemple votre ERP Divalto, et qui expose à l'IA ce qu'elle a le droit de faire. Le client formule des demandes, le serveur les exécute contre le système réel et renvoie un résultat structuré. L'IA ne touche jamais directement la base de données : elle passe toujours par ce serveur, qui agit comme un sas contrôlé.

Trois briques exposées : outils, ressources, invites

Un serveur MCP peut exposer trois types d'éléments. Les outils sont des actions exécutables, par exemple chercher une commande ou créer un devis. Les ressources sont des données consultables, comme une fiche client ou un catalogue produit. Les invites sont des modèles de tâches préformatés que l'on peut proposer à l'utilisateur. Dans le cadre d'une connexion ERP, ce sont surtout les outils et les ressources qui nous intéressent : ce sont eux qui matérialisent ce que l'IA peut lire et ce qu'elle peut faire.

La découverte d'actions : l'IA apprend ce qu'elle peut faire

Un point clé du MCP est la découverte dynamique. Quand le client se connecte au serveur, ce dernier lui décrit la liste des outils disponibles, avec pour chacun un nom, une description en langage naturel et la liste des paramètres attendus. L'IA n'a donc pas besoin d'être préprogrammée pour connaître votre ERP : elle interroge le serveur, comprend qu'un outil chercher_commande existe, qu'il attend un numéro ou un nom de client, et qu'il renvoie un statut, une date et un montant. Cette auto-description est ce qui rend le système souple : ajouter une capacité côté serveur la rend immédiatement utilisable par l'IA, sans réentraînement.

Pourquoi un standard plutôt qu'une intégration sur mesure

Avant le MCP, connecter un assistant IA à un système métier supposait de développer un connecteur spécifique, propre à chaque couple modèle et application. Si l'entreprise changeait de modèle ou ajoutait une source de données, il fallait souvent tout recommencer. Le MCP brise cette logique : en parlant une langue commune, n'importe quel client compatible peut se brancher sur n'importe quel serveur compatible. Concrètement, le serveur MCP que l'on construit aujourd'hui pour votre Divalto restera exploitable demain par un autre agent ou un autre modèle, sans reconstruction. Pour une PME, c'est une garantie de pérennité de l'investissement, là où les intégrations propriétaires deviennent vite des impasses coûteuses.

Comment fonctionne concrètement une requête MCP

Pour démystifier le protocole, suivons le trajet d'une question métier, de la phrase tapée par l'utilisateur jusqu'à la réponse affichée. Cette mécanique est invisible pour l'utilisateur final, mais la comprendre aide à cadrer un projet et à dialoguer avec un intégrateur.

De la question en langage naturel à l'appel d'outil

1. L'utilisateur écrit : où en est la commande de Bernard Industries passée mardi ?
2. L'assistant IA interprète l'intention et identifie qu'un outil chercher_commande exposé par le serveur MCP correspond au besoin.
3. Le client MCP envoie au serveur une requête structurée précisant l'outil et ses paramètres, par exemple le nom du client et une fourchette de dates.
4. Le serveur MCP traduit cette demande en une requête vers l'ERP, via son API ou sa base, en respectant le périmètre de droits autorisé.
5. L'ERP renvoie les données brutes, que le serveur met en forme et restitue au client.
6. L'assistant IA reformule le résultat en une réponse claire, citant le statut, la date d'expédition et le numéro de suivi.

Lecture et écriture : deux niveaux de risque distincts

Tous les outils MCP ne se valent pas en termes de risque. Un outil de lecture, qui consulte un stock ou un historique, ne modifie rien : dans le pire des cas, il affiche une donnée à laquelle l'utilisateur n'aurait pas dû accéder, ce qui se règle par les droits. Un outil d'écriture, qui crée un devis ou modifie une fiche, agit sur le système : une erreur a des conséquences réelles. Cette distinction structure toute la démarche d'intégration que nous recommandons chez Made in AI, et nous y reviendrons : on commence toujours par la lecture seule.

Le rôle du serveur comme garde-fou

Le serveur MCP n'est pas un simple tuyau. C'est l'endroit où l'on impose les règles : quels outils sont exposés, à qui, avec quelles limites. C'est lui qui vérifie qu'un utilisateur du service achats ne peut pas déclencher une action réservée à la comptabilité, qui plafonne le nombre de lignes renvoyées, qui journalise chaque appel. Bien conçu, le serveur transforme un accès potentiellement dangereux en un accès cadré, traçable et réversible.

Enchaîner plusieurs outils pour une seule demande

La puissance du dispositif apparaît quand une seule question mobilise plusieurs outils en cascade. Prenons la demande : ce client peut-il être livré la semaine prochaine pour 300 pièces ? L'agent IA va d'abord appeler verifier_stock, constater qu'il manque 80 pièces, puis appeler un outil de consultation des commandes fournisseurs pour vérifier une réception attendue, enfin croiser avec le carnet de production. En quelques appels orchestrés, il construit une réponse argumentée qu'aucun outil unique ne pourrait fournir. C'est exactement le type de raisonnement multi-étapes qu'un agent IA bien conçu, par exemple développé avec Claude Code, sait piloter de façon fiable, à condition que chaque outil sous-jacent soit clairement défini et borné.

L'architecture d'une connexion ERP vers IA

Au-delà du protocole, il faut comprendre l'architecture d'ensemble d'une connexion entre un ERP et un assistant IA. Cette vue d'ensemble est indispensable pour estimer un projet et anticiper les questions de sécurité et d'hébergement.

Les couches de l'architecture

• La couche de présentation : l'interface où l'utilisateur dialogue, qu'il s'agisse d'un chat intégré à votre intranet, d'un canal Teams ou Slack, ou d'une application dédiée.
• La couche d'orchestration : l'agent IA qui interprète les demandes, décide quels outils appeler et enchaîne plusieurs appels si nécessaire.
• La couche de connexion : le ou les serveurs MCP qui exposent les capacités des systèmes métier.
• La couche d'intégration : les API, connecteurs et requêtes qui relient les serveurs MCP aux ERP, CRM et GED.
• La couche source : l'ERP lui-même, sa base de données et ses règles de gestion, qui restent la référence unique de vérité.

Où héberger le serveur MCP

La question de l'hébergement est centrale pour une entreprise française soucieuse de souveraineté. Le serveur MCP peut tourner sur vos propres serveurs, dans votre data center, ou chez un hébergeur cloud localisé dans l'Union européenne. Pour une PME ou ETI industrielle lyonnaise, nous privilégions souvent un déploiement au plus près de l'ERP, dans le réseau de l'entreprise, afin que les données métier ne transitent pas inutilement par des services externes. Le modèle de langage peut, lui, être appelé via une API maîtrisée ou, pour les besoins les plus sensibles, déployé en environnement dédié.

La place de RAG et de l'automatisation

Le MCP se combine très bien avec d'autres briques que nous déployons chez Made in AI. Le RAG, la génération augmentée par récupération, sert à exploiter des documents non structurés : procédures, fiches techniques, contrats archivés dans la GED. Là où le MCP interroge des données structurées et actionnables, le RAG retrouve la bonne information dans un corpus documentaire. L'automatisation avec n8n permet d'orchestrer des flux déclenchés par l'IA, par exemple envoyer une alerte ou créer une tâche après qu'un agent a détecté un stock critique. Et un agent IA, éventuellement bâti avec Claude Code pour la partie développement, peut enchaîner ces capacités pour traiter un processus de bout en bout.

L'exemple Divalto en détail

Divalto est un ERP français très répandu dans l'industrie, le négoce et les services, particulièrement présent dans le tissu de PME et d'ETI d'Auvergne-Rhône-Alpes. Sa richesse fonctionnelle, qui couvre les ventes, les achats, les stocks, la production et la relation client, en fait un excellent candidat pour une connexion IA via MCP. Voyons concrètement, cas par cas, ce qu'un serveur MCP Divalto peut apporter au quotidien des équipes.

Retrouver une commande en langage naturel

Premier cas d'usage, le plus immédiat. Un commercial ou un assistant ADV demande : retrouve la dernière commande de la société Mécanique du Rhône. Le serveur MCP expose un outil chercher_commande qui accepte un nom de client, un numéro de commande ou une plage de dates. L'IA appelle cet outil, récupère la commande, son statut, ses lignes, son montant et sa date de livraison prévue, puis répond en une phrase claire. Plus besoin de naviguer dans plusieurs écrans Divalto : la donnée vient à l'utilisateur, et non l'inverse.

Vérifier un stock en temps réel

Deuxième cas : la disponibilité produit. La question est : a-t-on assez de référence VIS-INOX-8 pour honorer une commande de 500 pièces ? Un outil verifier_stock interroge les niveaux de stock par dépôt dans Divalto, tient compte des quantités déjà réservées et renvoie le disponible réel. L'IA peut même croiser cette information avec les commandes fournisseurs en cours pour indiquer une date de réapprovisionnement. Pour un atelier qui prend des engagements de délai au téléphone, cette réactivité change la qualité du service client.

Sortir un historique client consolidé

Troisième cas : la vision 360 du client. Avant un rendez-vous, un commercial demande un historique de la société Plasturgie Beaujolaise. Le serveur MCP combine plusieurs lectures dans Divalto : chiffre d'affaires sur douze mois, dernières commandes, encours, retards de paiement éventuels, produits les plus achetés. L'IA synthétise le tout en une fiche de préparation. C'est un gain de temps considérable, et cela évite l'erreur classique de se présenter chez un client en litige sans le savoir.

Pré-remplir un devis et créer une fiche

Quatrième et cinquième cas, qui basculent vers l'écriture. À partir d'une demande comme prépare un devis pour Mécanique du Rhône avec 200 VIS-INOX-8 au tarif habituel, un outil prereremplir_devis crée un brouillon de devis dans Divalto en reprenant le client, ses conditions tarifaires négociées et les produits. De même, un outil creer_fiche_client peut initialiser une fiche prospect à partir d'informations collectées. Point essentiel : ces actions d'écriture restent supervisées. L'IA prépare, l'humain valide. Le devis est créé à l'état brouillon, jamais envoyé automatiquement au client sans contrôle.

Un scénario type sur une journée ADV

Pour rendre l'ensemble concret, imaginons une matinée d'un assistant ADV chez un industriel lyonnais équipé de Divalto et d'un assistant connecté en MCP. À neuf heures, un client appelle pour connaître l'avancement de sa commande : réponse en cinq secondes, statut et numéro de suivi à l'appui. À dix heures, un commercial demande une fiche de préparation avant un rendez-vous l'après-midi : l'IA consolide chiffre d'affaires, encours et derniers achats. À onze heures, une demande de prix arrive par mail : l'assistant pré-remplit un devis aux conditions habituelles du client, que l'ADV vérifie et envoie. À midi, un point rapide sur les références en tension permet d'anticiper deux ruptures. Sur la seule matinée, ce sont plusieurs dizaines de minutes de navigation et de ressaisie économisées, sans aucune perte de contrôle.

Ce qui distingue une bonne implémentation Divalto

Tous les connecteurs ne se valent pas. Une implémentation Divalto réussie respecte la logique de gestion de l'ERP : elle ne court-circuite pas les règles de tarification, elle tient compte des unités de vente et des conditionnements, elle reflète fidèlement les statuts de commande et les niveaux de stock par dépôt. Elle renvoie des données déjà mises en forme, exploitables directement, plutôt que des champs techniques bruts. Et elle expose un nombre raisonnable d'outils bien nommés plutôt qu'une multitude d'actions floues. C'est cette qualité de conception qui fait la différence entre un assistant fiable et un gadget décevant.

Décliner l'approche aux autres ERP : SAP, Sage, Cegid, ERP maison

La force du MCP est qu'il ne dépend pas d'un ERP particulier. La logique vue pour Divalto se transpose à tout système de gestion, à condition de disposer d'un point d'accès, API ou base de données, et d'en cartographier les droits. Voici comment l'approche se décline.

SAP et les grands ERP

Sur SAP, qu'il s'agisse de S/4HANA ou de Business One pour les filiales et PME, le serveur MCP s'appuie sur les API standardisées et les services web exposés. La richesse de SAP impose un cadrage rigoureux des périmètres : on n'expose pas tout, on sélectionne les transactions et les vues utiles aux cas d'usage prioritaires. La démarche progressive, lecture d'abord, est ici encore plus importante compte tenu de la criticité des données.

Sage et Cegid

Sage et Cegid, très présents dans la gestion commerciale, la paie et la comptabilité des PME françaises, disposent d'API et de connecteurs qui permettent de bâtir un serveur MCP. Les cas d'usage typiques sont la consultation d'écritures, le suivi de facturation, le contrôle d'encours client ou la préparation de relances. La logique de supervision humaine reste la règle pour toute action qui touche à la comptabilité.

ERP maison et logiciels spécifiques

Beaucoup d'industriels de la région tournent encore sur un ERP développé en interne ou un logiciel métier spécifique. C'est souvent le cas le plus intéressant, car ces systèmes n'ont jamais bénéficié d'écosystème d'intégration. Dès lors qu'on peut interroger leur base de données ou exposer quelques points d'accès, un serveur MCP sur mesure leur donne une seconde vie. C'est exactement le type de projet que Made in AI mène avec Claude Code pour accélérer le développement du connecteur.

Étendre au CRM et à la GED

L'ERP n'est qu'un point de départ. Le même mécanisme s'applique au CRM, pour récupérer un historique d'échanges ou créer une opportunité, et à la GED, pour retrouver un contrat ou une fiche technique. En combinant plusieurs serveurs MCP, un agent IA peut répondre à des questions transverses qui mobilisent simultanément l'ERP, le CRM et la GED, ce qui était jusqu'ici hors de portée sans développement lourd.

C'est là que le couplage MCP et RAG prend tout son intérêt. La GED contient souvent des documents non structurés, contrats, cahiers des charges, fiches techniques, où l'information utile est noyée dans du texte libre. Un moteur RAG indexe ces documents et permet à l'IA d'en retrouver les passages pertinents, pendant que le MCP fournit les données structurées de l'ERP et du CRM. L'assistant peut alors répondre à une question comme : quelles sont les conditions de garantie négociées avec ce client dans son dernier contrat, et combien de commandes a-t-il passées depuis ? La première moitié de la réponse vient du RAG sur la GED, la seconde du MCP sur l'ERP. C'est précisément ce type d'architecture hybride que Made in AI conçoit pour ses clients industriels d'Auvergne-Rhône-Alpes.

Sécurité, droits, périmètres et conformité RGPD

Connecter une IA à un ERP soulève immédiatement des questions de sécurité légitimes. C'est même, dans notre expérience d'agence lyonnaise, le premier frein exprimé par les directions. La bonne nouvelle est que le MCP, bien implémenté, rend le système plus contrôlable qu'un accès humain classique, car chaque action passe par un point unique paramétrable et journalisé.

Gestion fine des droits et des périmètres

Le principe directeur est le moindre privilège : l'IA n'a accès qu'à ce dont elle a strictement besoin pour les cas d'usage validés. On définit des périmètres par profil utilisateur. Un assistant ADV peut lire les commandes et les stocks, préparer des devis, mais ne touche ni à la paie ni à la comptabilité analytique. Les droits de l'IA sont idéalement alignés sur ceux de l'utilisateur qui l'utilise, voire plus restrictifs encore pour les actions d'écriture.

• Lecture seule par défaut sur la majorité des outils, l'écriture étant l'exception soumise à validation.
• Cloisonnement par service : chaque profil ne voit que ses outils et ses données.
• Plafonnement des volumes : limiter le nombre de lignes ou la profondeur d'historique renvoyés en un appel.
• Confirmation humaine obligatoire pour toute action d'écriture ou tout export de données sensibles.

Journalisation et traçabilité

Chaque appel d'outil MCP doit être journalisé : qui a demandé quoi, quel outil a été appelé, avec quels paramètres, quelle réponse a été renvoyée et à quelle heure. Cette traçabilité est doublement précieuse : elle permet d'auditer les usages, de détecter une dérive ou un abus, et elle constitue une preuve en cas de contrôle. Un journal clair est aussi un outil pédagogique pour rassurer les équipes : on peut montrer exactement ce que l'IA a fait.

Conformité RGPD et données personnelles

Dès que l'ERP contient des données personnelles, contacts, dirigeants, salariés, le RGPD s'applique. La connexion IA doit respecter la finalité déclarée, la minimisation des données et l'information des personnes. Concrètement, on veille à ne pas exposer de catégories de données non nécessaires, à privilégier un hébergement européen, à encadrer contractuellement tout sous-traitant et à documenter le traitement dans le registre. L'audit IA que nous réalisons chez Made in AI inclut systématiquement ce volet conformité, car une solution non conforme n'est jamais déployable durablement.

Authentification et isolation des accès

Au-delà des droits fonctionnels, l'accès technique au serveur MCP doit être protégé. On met en place une authentification forte, on chiffre les communications entre le client et le serveur, et l'on isole le serveur dans un segment réseau maîtrisé. Idéalement, l'identité de l'utilisateur final est propagée jusqu'à l'ERP, de sorte que les droits appliqués soient toujours ceux de la personne réelle derrière la demande, et non un compte technique générique surpuissant. Cette propagation d'identité est un point d'architecture déterminant : elle évite l'écueil classique du connecteur qui contourne tout le modèle de sécurité de l'ERP.

Les étapes concrètes d'une intégration réussie

Un projet de connexion ERP vers IA ne se réussit pas en branchant tout d'un coup. La méthode que nous appliquons chez Made in AI suit une progression maîtrisée, qui sécurise chaque étape avant de passer à la suivante. C'est cette discipline qui distingue un prototype prometteur d'une solution réellement adoptée.

Étape 1 : le cadrage

Tout commence par un cadrage. On identifie les cas d'usage prioritaires, ceux qui font gagner le plus de temps avec le moins de risque, généralement des lectures. On cartographie les données concernées, les droits associés et les contraintes techniques de l'ERP. On définit des indicateurs de succès mesurables, par exemple le temps gagné par demande ou le taux de réponses jugées utiles. Cette phase débouche sur un périmètre clair et une estimation réaliste.

Étape 2 : la lecture seule d'abord

On déploie d'abord des outils en lecture seule. Retrouver une commande, vérifier un stock, sortir un historique : ces capacités apportent une valeur immédiate sans risque de modification du système. Cette phase permet aux équipes de se familiariser, de gagner en confiance et de remonter les ajustements utiles. C'est aussi l'occasion de calibrer la qualité des réponses et d'affiner les descriptions d'outils.

Étape 3 : l'écriture supervisée

Une fois la lecture maîtrisée et adoptée, on introduit progressivement des actions d'écriture, toujours sous supervision humaine. Pré-remplir un devis à l'état brouillon, créer une fiche prospect, proposer une relance : l'IA prépare, l'utilisateur valide d'un clic. On commence par les actions les moins risquées et les plus réversibles, puis on élargit en fonction de la confiance acquise et des retours du terrain.

Étape 4 : l'industrialisation

La dernière étape consiste à industrialiser : renforcer la supervision et la journalisation, documenter les outils, former les utilisateurs, mettre en place une gouvernance des évolutions. C'est ici que la formation IA prend tout son sens. Made in AI, organisme certifié Qualiopi, propose des formations finançables par les OPCO pour que vos équipes maîtrisent l'outil, en comprennent les limites et en tirent le meilleur. Une technologie sans appropriation reste lettre morte.

1. Cadrage des cas d'usage, des données et des droits, avec indicateurs de succès.
2. Déploiement en lecture seule pour une valeur immédiate sans risque.
3. Introduction progressive de l'écriture supervisée, des actions les plus réversibles aux plus engageantes.
4. Industrialisation : gouvernance, journalisation renforcée, documentation et formation des équipes.

Cas d'usage par service

Pour rendre le propos tangible, parcourons les apports concrets d'une connexion ERP vers IA service par service, tels que nous les observons chez nos clients industriels de la région lyonnaise.

Administration des ventes (ADV)

• Répondre instantanément à un client sur le statut et le suivi de sa commande.
• Vérifier la disponibilité d'un produit avant de confirmer un délai au téléphone.
• Pré-remplir un devis aux conditions habituelles du client en quelques secondes.
• Préparer une fiche de synthèse client avant un appel ou un rendez-vous.

Production et logistique

• Consulter l'avancement des ordres de fabrication sans ouvrir plusieurs écrans.
• Détecter un stock critique et alerter, en déclenchant éventuellement un flux n8n.
• Croiser les besoins des commandes en cours avec les approvisionnements prévus.
• Identifier les références à risque de rupture sur la semaine.

Achats

• Retrouver les conditions et l'historique d'un fournisseur avant une négociation.
• Comparer les délais et prix sur des achats récurrents.
• Préparer une commande fournisseur en brouillon à partir d'un besoin exprimé.
• Suivre les réceptions attendues et les écarts éventuels.

Direction et pilotage

• Obtenir une synthèse de l'activité, chiffre d'affaires, encours, retards, en langage naturel.
• Interroger les marges par client ou par produit sans attendre un export.
• Repérer les tendances et les anomalies de gestion plus tôt.
• Disposer d'un point d'entrée unique pour des questions transverses ERP, CRM et GED.

MCP face aux intégrations classiques par API

Une question revient souvent : en quoi le MCP diffère-t-il d'une intégration API traditionnelle ? La réponse mérite d'être nuancée, car le MCP ne remplace pas les API, il s'appuie dessus tout en changeant la manière dont l'IA les utilise.

L'intégration classique : rigide et coûteuse à maintenir

Dans une intégration API classique, un développeur code en dur chaque appel : tel bouton déclenche telle requête vers tel endpoint, avec tels paramètres. C'est efficace mais figé. Chaque nouveau besoin exige du développement, chaque évolution de l'ERP peut casser l'intégration, et l'ensemble est difficile à faire évoluer au rythme des demandes métier. Multiplier les connexions point à point entre N applications et M modèles aboutit à une explosion combinatoire ingérable.

Le MCP : une couche standard et auto-descriptive

Le MCP introduit une couche d'abstraction standardisée et auto-descriptive. L'IA découvre les outils disponibles et décide elle-même lesquels appeler en fonction de la demande. Ajouter une capacité côté serveur la rend immédiatement exploitable, sans recoder l'application cliente. On passe d'un câblage rigide à un branchement modulaire. Pour une PME qui veut faire évoluer ses usages au fil de l'eau, c'est un avantage déterminant en coût de maintenance et en agilité.

Les deux approches sont complémentaires

Il ne s'agit pas d'opposer les deux. Le serveur MCP utilise précisément les API de l'ERP pour faire son travail. La différence est la couche d'interface entre l'IA et ces API : standardisée, descriptive et orientée action avec le MCP, codée et figée avec l'intégration classique. Pour des flux purement techniques et stables entre deux systèmes, une API directe ou une automatisation n8n reste souvent le bon choix. Pour donner à un assistant IA un accès souple et évolutif au métier, le MCP s'impose.

Limites et bonnes pratiques

Aucune technologie n'est magique, et le MCP ne fait pas exception. Connaître ses limites est la condition d'un déploiement réussi et durable. Voici les points de vigilance que nous partageons systématiquement avec nos clients.

Les limites à garder en tête

• La qualité des réponses dépend de la qualité des données de l'ERP : des données mal saisies donnent des réponses peu fiables.
• Le modèle peut mal interpréter une demande ambiguë : la formulation des questions et la conception des outils comptent beaucoup.
• L'écriture autonome non supervisée est à proscrire tant que la confiance et le recul ne sont pas établis.
• La maturité de l'écosystème MCP est récente : il faut sélectionner des composants éprouvés et accompagner le déploiement.

Les bonnes pratiques de conception

• Concevoir des outils au périmètre clair, avec des descriptions précises pour guider l'IA.
• Renvoyer des résultats structurés et bornés plutôt que des masses de données brutes.
• Imposer la confirmation humaine sur toute écriture et tout export sensible.
• Journaliser systématiquement et relire régulièrement les usages.
• Itérer : démarrer petit, mesurer, ajuster, étendre.

Le facteur humain, souvent décisif

La réussite d'un projet IA tient autant à l'humain qu'à la technique. Une solution puissante mais incomprise sera contournée ou rejetée. C'est pourquoi nous insistons sur la formation, l'accompagnement au changement et l'implication des équipes métier dès le cadrage. Un assistant IA conçu avec les utilisateurs, et non imposé, devient un réflexe quotidien plutôt qu'un outil de plus.

Mesurer la valeur pour piloter le déploiement

Une bonne pratique trop souvent négligée consiste à mesurer la valeur réelle de la solution une fois déployée. On définit dès le cadrage des indicateurs simples : temps moyen pour répondre à une question client, nombre de demandes traitées par l'assistant, taux de réponses jugées utiles, réduction des erreurs de délai. Ces mesures permettent d'arbitrer les évolutions, de prioriser les nouveaux outils à exposer et de démontrer le retour sur investissement à la direction. Sans mesure, un projet IA reste une intuition ; avec mesure, il devient une démarche d'amélioration continue que l'on peut défendre et financer.

Anticiper les évolutions de l'ERP

Un ERP vit : montées de version, nouveaux champs, modifications de paramétrage. Le serveur MCP doit être conçu pour absorber ces évolutions sans casser. On documente les dépendances aux API et aux structures de données, on prévoit des tests de non-régression sur les outils critiques, et l'on intègre la maintenance du connecteur dans la gouvernance du système d'information. Cette anticipation évite la mauvaise surprise d'un assistant qui cesse soudain de fonctionner après une mise à jour de Divalto, et garantit la fiabilité dans la durée.

Questions fréquentes

Le MCP est-il réservé aux grandes entreprises ?

Non, au contraire. Le MCP est particulièrement pertinent pour les PME et ETI qui ne peuvent pas se payer des intégrations sur mesure coûteuses. Sa logique modulaire permet de démarrer petit, sur un ou deux cas d'usage en lecture seule, puis d'étendre progressivement. Made in AI accompagne précisément les PME industrielles de Lyon et d'Auvergne-Rhône-Alpes dans cette montée en puissance maîtrisée et financièrement raisonnable.

Mon ERP Divalto est-il compatible avec une connexion IA ?

Dans la très grande majorité des cas, oui. Dès lors que Divalto expose des API ou que l'on peut interroger sa base de données dans le respect des droits, un serveur MCP peut être construit pour y connecter un assistant IA. La compatibilité dépend surtout de votre version et de votre configuration, points que nous vérifions lors de l'audit IA initial avant tout développement.

L'IA peut-elle modifier mes données sans contrôle ?

Pas si le système est bien conçu. La règle que nous appliquons est la lecture seule par défaut et l'écriture toujours supervisée. Les actions de modification créent des brouillons soumis à validation humaine, et chaque appel est journalisé. Vous gardez la maîtrise totale : l'IA prépare et propose, mais ce sont vos équipes qui valident et engagent l'entreprise.

Combien de temps pour un premier prototype ?

Un prototype en lecture seule sur un cas d'usage prioritaire peut être mis en place en quelques semaines, selon l'accessibilité de l'ERP et la disponibilité des interlocuteurs. L'objectif d'un prototype est de démontrer la valeur rapidement et concrètement, avant d'investir dans l'industrialisation. C'est l'approche progressive que privilégie Made in AI pour limiter le risque.

Mes données restent-elles en France ?

C'est un choix d'architecture que nous prenons au sérieux. Le serveur MCP peut être hébergé dans votre infrastructure ou chez un hébergeur européen, et l'on minimise les données transmises au modèle. Pour les besoins les plus sensibles, des options de déploiement souverain existent. Le volet RGPD et souveraineté est traité dès la phase de cadrage afin de garantir une solution conforme et durable.

Faut-il former les équipes pour utiliser cet outil ?

L'usage de base est naturel puisqu'on dialogue en langage courant, mais une formation reste vivement recommandée pour en exploiter le potentiel et en comprendre les limites. Made in AI est organisme de formation certifié Qualiopi, ce qui ouvre un financement possible via les OPCO. Former vos équipes, c'est garantir l'adoption et le retour sur investissement de la solution.

Quelle différence entre le MCP et une automatisation n8n ?

Les deux sont complémentaires. L'automatisation n8n orchestre des flux prédéfinis et déclenchés par des événements : quand un stock passe sous un seuil, envoyer une alerte. Le MCP donne à un assistant IA un accès interactif et raisonné aux données, où c'est la demande en langage naturel qui décide de l'action. On combine souvent les deux : l'IA détecte un besoin via MCP, puis déclenche un flux n8n pour exécuter une action récurrente de façon fiable.

Le MCP fonctionne-t-il avec un ERP développé en interne ?

Oui, et c'est souvent l'un des cas les plus utiles. Dès lors qu'on peut interroger la base de données de votre ERP maison ou exposer quelques points d'accès, un serveur MCP sur mesure peut y être construit. Ces logiciels spécifiques n'ont généralement aucun écosystème d'intégration : le MCP leur ouvre l'accès aux assistants IA modernes. Made in AI développe ce type de connecteur, notamment avec Claude Code pour accélérer la mise au point.

Passez à l'action avec Made in AI

Connecter votre ERP à l'IA via le MCP n'est plus un projet de laboratoire : c'est une démarche accessible, sécurisée et progressive, qui transforme un assistant générique en un véritable collaborateur métier capable de retrouver une commande, vérifier un stock, préparer un devis ou synthétiser un historique client. L'exemple Divalto que nous avons déroulé se transpose à SAP, Sage, Cegid, à votre ERP maison, à votre CRM et à votre GED, selon la même méthode prudente : lecture d'abord, écriture supervisée ensuite, industrialisation enfin.

Made in AI, agence IA à Lyon, accompagne les PME et ETI industrielles d'Auvergne-Rhône-Alpes sur toute la chaîne : audit IA pour identifier les cas d'usage à plus forte valeur, prototype rapide pour démontrer le bénéfice concret, déploiement de solutions IA combinant MCP, RAG, automatisation n8n, agents IA et Claude Code, et formation Qualiopi finançable par les OPCO pour ancrer l'usage dans vos équipes.

L'IA utile en entreprise n'est pas celle qui parle bien, c'est celle qui sait. Le MCP est le chaînon qui relie l'intelligence du modèle à la réalité de vos données métier.

Vous utilisez Divalto ou un autre ERP et vous voulez savoir ce qu'une connexion IA changerait concrètement pour vos équipes ? Commencez par un audit IA pour cartographier vos cas d'usage prioritaires, puis lancez un prototype en lecture seule sur la fonction qui vous fait gagner le plus de temps. Contactez Made in AI à Lyon pour en discuter : nous évaluons ensemble la faisabilité sur votre système, dans le respect de la sécurité, des droits et du RGPD, et nous construisons une feuille de route réaliste.