Le Model Context Protocol (MCP) est devenu en 2025-2026 le standard de facto pour connecter des agents IA à des données d’entreprise. 97 millions d’installations. Adoptés par tous les grands éditeurs — Microsoft, Salesforce, GitHub, Atlassian.

La majorité des articles francophones sur MCP expliquent la même chose : “c’est comme une prise universelle pour l’IA”. Analogie USB. Réduction M×N en M+N. Exemples : Slack, Notion, GitHub.

Ce que ces articles n’expliquent pas : le nommage et le typage de vos outils MCP influencent directement la qualité de raisonnement de l’agent.

Un agent qui peut appeler GetClientRiskProfile(clientId) raisonne différemment d’un agent qui peut exécuter SELECT * FROM clients WHERE id = ?. Même données. Résultats très différents.

Voici pourquoi — et comment on a appliqué ça sur des ERP manufacturiers legacy.

Comment un agent IA utilise vos outils

Un agent IA (Claude, GPT-4, n’importe quel modèle de fondation) reçoit au démarrage la liste des outils disponibles — leurs noms, leurs descriptions, leurs paramètres attendus.

Quand l’utilisateur pose une question, l’agent décide quels outils appeler, dans quel ordre, avec quels paramètres — avant même d’avoir les données. C’est ce choix initial qui détermine la qualité de la réponse finale.

Si vos outils sont des requêtes SQL génériques, l’agent doit deviner quelles tables interroger, quels champs sont pertinents, comment croiser les résultats. Il peut se tromper. Il peut appeler trop d’outils. Il peut manquer du contexte pour interpréter les données brutes.

Si vos outils ont des noms et des descriptions sémantiques clairs — GetClientRiskProfile, GetProductionCapacity, GetAssemblageContext — l’agent comprend l’intention derrière chaque outil avant de l’appeler. Il choisit mieux. Il interprète mieux. Les réponses sont plus précises.

La qualité d’inférence de l’agent est proportionnelle à la sémantique de vos outils.

Un exemple concret : trois façons d’exposer le même outil

Question posée à l’agent : “Est-ce que je devrais accepter la commande du client 4821?”

Approche 1 — SQL brut

Outil disponible : execute_sql
Description : exécute une requête SQL sur la base de données ERP

L’agent doit deviner quelle table contient les clients, quels champs représentent le risque de crédit, comment joindre avec l’historique de commandes, comment interpréter les codes de statut Mapics (qui n’ont aucune sémantique explicite).

Il va probablement produire une requête partiellement correcte, manquer certaines tables, et retourner des données brutes que ni lui ni l’utilisateur ne sauront interpréter sans contexte.

Approche 2 — Endpoint REST générique

Outil disponible : get_client
Description : retourne les informations d'un client
Paramètre : client_id

Mieux — mais “les informations d’un client” est vague. Est-ce que ça inclut son historique de paiement? Son encours actuel? Ses commandes en cours? L’agent ne sait pas ce qu’il va recevoir avant de faire l’appel.

Approche 3 — Outil à sémantique métier (ce qu’on utilise)

Outil disponible : GetClientRiskProfile
Description : Retourne le profil de risque de crédit d'un client pour décision d'acceptation de commande.
  - Historique de paiement des 12 derniers mois (Acomba)
  - Encours actuel vs limite de crédit
  - Commandes en attente de livraison (Mapics)
  - Tickets qualité ouverts (Isovision)
  - Score de risque calculé (faible / moyen / élevé / critique)
Paramètre : client_id (identifiant ERP)

Maintenant l’agent comprend exactement ce qu’il obtient et pourquoi. Il peut expliquer sa démarche à l’utilisateur. Il peut croiser ce résultat avec d’autres outils de façon cohérente. Et si le score est “élevé”, il sait ce que ça signifie sans avoir à deviner.

C’est la différence entre donner à l’agent des données et lui donner de la connaissance.

Ce qu’on a construit : un serveur MCP sur sources hétérogènes

Sur le projet réel, on avait cinq systèmes sources : Mapics (AS400/DB2), Acomba (32-bit COM/OLE), Progression Live (REST), Isovision (SQL Server), GuideTI.

Le serveur MCP expose une vingtaine d’outils métier. Chacun agrège des données de une à trois sources différentes. L’agent ne sait pas (et ne doit pas savoir) que ces données viennent de systèmes différents.

Quelques exemples d’outils :

GetProductionCapacity(weekStart, productFamily) Retourne la capacité disponible pour une famille de produits pour une semaine donnée. Croise le calendrier de production Mapics avec les absences planifiées et les en-cours en production. Utile pour répondre à : “Est-ce qu’on peut prendre la commande pour jeudi?”

GetAssemblageContext(productId, revision) Retourne le guide de travail complet pour un assemblage : étapes, pièces requises, temps standard, points de contrôle qualité. Agrège GuideTI + Isovision + le catalogue Mapics. Utile pour : “Comment on assemble le produit 8832-C rev 3?”

GetMaintenanceRisk(machineId, horizon) Retourne le risque de panne estimé pour une machine sur un horizon donné, basé sur l’historique de capteurs IoT et le calendrier de maintenance préventive. Utile pour : “Est-ce que je peux planifier une grosse commande sur la presse 4 la semaine prochaine?”

La règle d’or : nommer les outils comme des intentions, pas comme des requêtes

En concevant les outils de votre serveur MCP, posez-vous cette question pour chaque outil :

“Si quelqu’un lisait le nom et la description de cet outil sans contexte, saurait-il pourquoi il existerait?”

Si la réponse est non — si vous avez besoin de connaître le schéma de votre base de données pour comprendre à quoi sert l’outil — l’outil n’est pas assez sémantique.

Un bon outil MCP reflète une intention métier, pas une opération de données. Ce n’est pas get_table_rows — c’est GetMonthlyProductionSummary. Ce n’est pas join_clients_invoices — c’est GetClientPaymentHistory.

Granularité : ni trop fin, ni trop large

Il y a un équilibre à trouver.

Des outils trop fins (un outil par champ de base de données) obligent l’agent à faire de nombreux appels et à assembler lui-même les pièces — exactement ce qu’on voulait éviter avec SQL brut.

Des outils trop larges (un seul outil “GetEverythingAboutClient”) retournent trop de données, augmentent le contexte inutilement, et ralentissent l’agent.

La bonne granularité correspond à une décision métier. Un outil par question que vos gestionnaires se posent réellement. “Peut-on livrer à temps?” “Ce client est-il fiable?” “Cette machine est-elle disponible?” Ce sont vos outils.

Ce que ça donne en utilisation réelle

Un gestionnaire peut maintenant demander en langage naturel, dans une interface de chat connectée au serveur MCP :

  • “Quelles commandes risquent d’être en retard cette semaine?”
  • “Quel est notre niveau de risque client en ce moment?”
  • “Y a-t-il des problèmes de qualité récurrents sur la ligne 3?”

L’agent appelle les bons outils, croise les résultats, et répond avec une synthèse — pas avec un dump de données brutes.

L’AS400, l’Acomba, les cinq systèmes sources continuent de tourner exactement comme avant. Ils n’ont jamais su que quelque chose avait changé.