Comment on a automatisé la création de devis dans un ERP avec le Model Context Protocol (MCP)

Il y a quelques mois, un client nous a posé une question simple : « Est-ce qu’on pourrait créer un devis juste en le demandant ? »

Ce client gère une PME avec un ERP sur mesure qu’on développe et maintient. Leurs commerciaux passaient plusieurs minutes à naviguer entre les écrans pour saisir un devis : sélectionner le client, ajouter les lignes, renseigner les quantités, valider. Rien de compliqué en soi, mais répété 20 fois par jour, ça impacte la productivité de l’équipe.

Nous avons pu les accompagner grâce à un serveur MCP.

C’est quoi MCP ?

MCP (Model Context Protocol) est un standard open source publié par Anthropic fin 2024. Le principe : définir un protocole commun pour qu’un modèle de langage comme Claude puisse interagir avec des outils externes de façon structurée.

En pratique, tu crées un serveur MCP qui expose des « tools » (des fonctions) que le modèle peut appeler. Claude décide lui-même quand appeler quel outil, selon ce que l’utilisateur lui demande. C’est là que ça change par rapport à une intégration API classique : tu n’écris plus la logique d’orchestration, tu la délègues au modèle.

Si tu veux comprendre les bases de MCP avant d’aller plus loin, on a écrit un article d’introduction qui couvre le fonctionnement général du protocole.

Ce qu’on a construit

Le client avait déjà son ERP avec une API interne. On a développé un serveur MCP qui expose les opérations clés :

• Rechercher un client ou un fournisseur
• Créer un devis
• Ajouter des lignes à un devis (article, quantité, prix)
• Consulter le catalogue produit

Une fois le serveur connecté à Claude, le commercial peut écrire :

« Crée un devis pour le client Martin avec 50 unités de l’article réf. X42 à 12 euros pièce. »

Claude appelle les outils dans le bon ordre : il cherche le client, vérifie l’article dans le catalogue, crée le devis, ajoute la ligne. En quelques secondes, le devis est dans l’ERP.

Les vrais défis techniques

C’est simple à mettre en place lorsqu’on maîtrise bien les API et l’IA, mais il y a certaines choses à garder en tête.

Définir des schémas de paramètres clairs

Chaque outil MCP a un schéma JSON qui décrit ses paramètres. Si ce schéma est flou ou incomplet, Claude fait des suppositions, et ça déraille. Notre outil create_quotation_item n’avait pas le champ quantity au départ. Claude essayait de le passer quand même, l’API renvoyait une erreur, et la conversation ne s’en remettait pas.

La règle qu’on a retenue : chaque paramètre doit avoir une description claire, avec les valeurs attendues si nécessaire. Le schéma doit être exhaustif, pas minimaliste.

Renvoyer des erreurs utiles

Quand une opération échoue, Claude doit recevoir un message d’erreur qu’il peut interpréter pour s’adapter ou expliquer le problème à l’utilisateur. Un « 500 Internal Server Error » générique ne lui sert à rien. On a revu tous nos handlers pour renvoyer des messages structurés : ce qui a échoué, pourquoi, et ce qu’il peut tenter à la place.

Pourquoi c’est différent d’une intégration classique

Avec une intégration API traditionnelle, tu construis une interface : des formulaires, des boutons, des workflows. C’est prévisible, mais rigide. Si l’utilisateur veut faire quelque chose que tu n’as pas prévu, il est bloqué.

Avec MCP, tu exposes des capacités, pas des interfaces. Le modèle compose lui-même les appels selon ce qu’on lui demande. Des cas d’usage que tu n’avais pas anticipés peuvent fonctionner, dans les limites de ce que tes outils permettent.

Pour un ERP avec beaucoup d’opérations répétitives et des utilisateurs non-techniques, c’est une vraie différence d’approche.

Ce que ça change au quotidien

Le gain le plus visible, c’est le temps. Créer un devis passe de 3-4 minutes à moins de 30 secondes. Mais il y a un autre effet qu’on n’avait pas anticipé : les commerciaux utilisent l’ERP autrement. Ils interrogent le système en langage naturel, consultent l’historique d’un client en posant une question, demandent des comparatifs de prix. Des actions qui existaient dans l’ERP mais que personne ne faisait parce que c’était trop long à aller chercher.

Ce qu’on retient

MCP est encore jeune. L’outillage autour (débogage, monitoring, clients natifs) n’est pas encore mature. Mais le protocole est solide, et la valeur est réelle sur des cas d’usage répétitifs bien définis.

Si tu as une application métier avec une API interne, c’est le bon moment pour explorer MCP. Le coût de développement d’un serveur est très raisonnable, et le retour est immédiat côté utilisateur.

Chez Fenxi, c’est devenu un service à part entière : on développe et maintient des connecteurs MCP pour les logiciels propriétaires de nos clients. Contacte-nous si tu veux en discuter.