Sur une base SQL, la question est de savoir quelles tables exposer. Sur un ERP ou un CRM, elle est différente, et souvent plus simple : l'outil a déjà fait le travail de modélisation. Une commande est une commande, une opportunité est une opportunité, un ticket est un ticket.
Ce déplacement change la nature du projet. On ne reconstitue pas une cartographie, on choisit ce qu'on montre parmi des objets déjà propres. Et on décide, séparément, si l'IA a le droit d'agir dessus.
Ce que veut dire « exposer des objets métier »
Un ERP manipule des entités que tout le monde comprend : clients, articles, commandes, factures, écritures. Un CRM manipule comptes, contacts, opportunités, activités. Un outil de tickets manipule demandes, statuts, affectations, délais.
Exposer ces objets via un serveur MCP consiste à en publier une définition stable, avec les champs utiles et les relations entre eux. Le modèle n'a pas à comprendre le schéma physique, il travaille sur ces objets.
Le gain est immédiat sur les questions transversales, celles qui obligent aujourd'hui à ouvrir trois écrans. « Quels comptes ont une opportunité ouverte, un impayé et plus de cinq tickets ce trimestre ? » n'existe dans aucun écran, parce qu'aucun module ne possède les trois informations.
Trois périmètres qui reviennent systématiquement
La direction
Performance commerciale, marge par activité, écarts par rapport au budget, encours. Ce sont des questions qui existent déjà sous forme de reporting mensuel, et dont l'intérêt est de pouvoir les poser entre deux points mensuels, sur un périmètre non prévu.
Le pilotage de projet
Avancement, charge, glissements, tickets ouverts par client. Le besoin est moins de produire un état que de repérer ce qui dévie avant la réunion, plutôt que pendant.
L'encadrement
Répartition de la charge, absences, saisonnalité. C'est le périmètre le plus sensible, celui qui touche à des données personnelles, et celui sur lequel un seuil d'anonymisation et une association des représentants du personnel s'imposent avant toute mise en service.
La question des actions, à traiter séparément
Un serveur MCP peut exposer des actions : créer un ticket, mettre à jour un statut, rattacher un contact, déclencher un workflow. C'est techniquement l'affaire de quelques jours une fois la lecture en place.
Ce n'est pourtant pas la première chose à faire, pour trois raisons.
La lecture révèle les vrais besoins. Ce que les équipes demandent après trois semaines d'usage ressemble rarement à ce qui figurait dans le cadrage. Ouvrir l'écriture trop tôt revient à automatiser des gestes qu'on n'a pas encore observés.
L'écriture change le régime de responsabilité. Une réponse fausse en lecture se corrige en reposant la question. Un statut modifié à tort dans l'ERP se propage à la facturation, aux relances et au reporting.
La réversibilité doit être pensée avant. Chaque action exposée doit avoir une trace, un auteur identifié et, quand c'est possible, un moyen d'annulation. Cela se conçoit à froid, pas dans l'urgence d'une démonstration.
Quand l'écriture s'ouvre, elle s'ouvre donc objet par objet, opération par opération. Créer un ticket, oui. Modifier un montant facturé, presque jamais.
Ce que ce n'est pas
Trois confusions reviennent régulièrement en rendez-vous.
Ce n'est pas remplacer l'ERP. Les équipes continuent de saisir dans leur outil. La couche MCP sert à interroger, pas à opérer. Le jour où le serveur s'arrête, l'ERP fonctionne exactement comme avant.
Ce n'est pas un module de l'éditeur. Beaucoup d'éditeurs ajoutent aujourd'hui un assistant à leur produit. Ces assistants sont utiles, mais ils voient leur périmètre et lui seul. L'intérêt d'une couche MCP est précisément de croiser plusieurs outils, y compris ceux de fournisseurs différents.
Ce n'est pas de la génération de contenu dans l'ERP. Rédiger une relance ou un compte rendu est un autre sujet, avec d'autres enjeux. Ici, il s'agit d'interroger de la donnée de gestion et d'obtenir une réponse chiffrée et vérifiable.
Les prérequis, et le seul qui bloque vraiment
Techniquement, il faut peu de choses : une API documentée ou un accès en base côté outil, et un compte de service dont les droits sont explicites.
Le prérequis qui bloque réellement est ailleurs. C'est l'arbitrage sur les droits par rôle. Tant que l'entreprise n'a pas décidé qui voit la marge, qui voit les salaires et qui voit les impayés, aucune configuration n'est possible. Cette décision n'appartient ni au prestataire ni à la DSI, elle appartient à la direction, et elle prend souvent plus de temps que la mise en place.
Sur les outils internes développés sur mesure, un point supplémentaire mérite attention : la stabilité du modèle de données. Si le schéma bouge à chaque évolution, les vues exposées casseront, et il faut le prévoir dans le contrat de maintenance.
Par où commencer
Le périmètre de départ le plus efficace n'est pas le plus large, c'est celui qui recouvre les questions transversales déjà formulées. Concrètement : listez les questions que quelqu'un pose aujourd'hui en ouvrant deux ou trois modules à la main. Elles constituent le premier périmètre.
La lecture seule sur ce périmètre, entre les mains de quelques utilisateurs réels, apprend en deux semaines ce qu'un cadrage exhaustif n'aurait pas anticipé. L'élargissement et l'éventuelle ouverture des actions viennent après, sur ce qui a été constaté.
La méthode complète, du premier regard sur l'outil jusqu'à la maintenance des vues, est décrite sur la page serveur MCP et interrogation des données en langage naturel.
