Brancher Claude sur son ERP via MCP : ce qui marche, ce qui ne marche pas

MCP n'est pas « une API de plus »

La tentation, quand on a déjà une API REST, est de la traduire outil par outil : un endpoint, un outil MCP. Ça fonctionne techniquement et ça donne un agent médiocre. Une API est conçue pour un développeur qui lit la documentation une fois ; un outil MCP est lu par un modèle de langage à chaque conversation, qui doit deviner lequel appeler à partir de son nom et de sa description.

Trois conséquences pratiques : moins d'outils, mieux décrits ; des paramètres qui parlent le langage du métier (« équipement », pas « entity_id ») ; et des résultats lisibles — un tableau de dix colonnes JSON perd l'agent, une liste de cinq lignes avec les champs utiles le guide.

Ce qui marche

• ✓Les questions de synthèse. « Quels clients ont une facture en retard de plus de 30 jours ? », « quels équipements ont eu trois pannes ce trimestre ? » : l'agent enchaîne deux ou trois appels de liste et répond. C'est l'usage qui convainc le plus vite.
• ✓La création guidée. Créer un ordre de travail, une page, un contact à partir d'une phrase. L'agent demande ce qui manque et propose un brouillon. Il faut que l'outil accepte un objet incomplet et renvoie des erreurs explicites.
• ✓Les tâches répétitives en série. Dix pages produit à partir d'un catalogue, quarante mentions légales à mettre à jour. L'agent boucle sans se lasser, à condition de travailler en brouillon.
• ✓Les schémas découvrables. Un outil « décris-moi la classe X » qui renvoie propriétés, types et valeurs possibles permet à l'agent de s'auto-documenter avant d'agir. Chez nous, c'est le métamodèle lui-même qui est exposé.

Ce qui ne marche pas

• −Les outils fourre-tout. Un outil « query » qui prend du SQL ou un filtre libre paraît puissant ; en pratique l'agent écrit des requêtes fausses avec assurance. Préférez des filtres typés, quitte à en avoir plusieurs.
• −La publication directe. Laisser l'agent publier, envoyer, valider sans relecture. Ce n'est pas qu'il se trompe souvent ; c'est qu'il se trompe parfois sur quelque chose de visible. Brouillon d'abord, humain ensuite.
• −Les listes non paginées. Un outil qui renvoie 5 000 lignes sature le contexte et l'agent perd le fil. Pagination et tri par défaut sont obligatoires, avec un total pour que l'agent sache qu'il n'a pas tout vu.
• −Le compte de service tout-puissant. Brancher le serveur MCP avec un jeton administrateur « pour aller vite ». C'est le point suivant.

Les droits sont la vraie question

Un agent MCP agit au nom de quelqu'un. S'il tourne avec un compte technique qui voit tout, n'importe quel utilisateur qui lui parle voit tout aussi — et ce que l'agent écrit n'est attribué à personne. La bonne architecture est simple à énoncer et rarement appliquée : le serveur MCP reçoit l'identité de l'utilisateur, et chaque outil applique exactement les droits que cet utilisateur aurait dans l'application.

C'est pour cette raison que, sur agis, le serveur MCP n'est pas une couche à part : il utilise le même moteur de permissions que l'interface web. Un technicien qui ne peut pas clôturer un ordre de travail dans l'écran ne peut pas le faire via Claude non plus, et chaque modification porte son nom dans l'historique.

Par où commencer

Choisissez un domaine borné — les demandes d'intervention, les pages d'un site, les contacts — et exposez cinq outils, pas cinquante : lister avec filtres, lire, créer en brouillon, modifier, décrire le schéma. Testez avec de vraies questions d'utilisateurs, réécrivez les descriptions jusqu'à ce que l'agent choisisse le bon outil du premier coup. Puis seulement, élargissez.

Si votre application est décrite par un modèle, cette étape est en grande partie automatique : c'est ce que nous racontons dans l'étude de cas GMAO.