Le Model Context Protocol (MCP) est un standard ouvert qui permet à un service — API, base de données, ERP — de se présenter à une IA (Claude, notamment, mais aussi d'autres LLM) comme un outil directement exploitable. Au lieu de copier-coller des données dans un prompt, l'IA appelle directement vos fonctions, lit vos ressources et déclenche vos actions.

L'analogie la plus parlante est la suivante : MCP est au monde des LLM ce qu'USB-C est au matériel, c'est-à-dire une interface universelle. Vous développez un serveur MCP une seule fois, puis tout client compatible (Claude Code, claude.ai, autres) peut s'y connecter.

Les trois choses qu'un serveur MCP expose

Primitive Rôle Exemple Adliss
Tools (outils) Des actions que l'IA peut déclencher creer_facture, rechercher_client
Resources (ressources) Des données que l'IA peut lire un catalogue produits, un document
Prompts Des modèles de requêtes prêts à l'emploi « générer un devis type »

Dans la pratique, les tools sont l'élément le plus sollicité. Chacun possède un nom, une description (c'est elle qui indique à l'IA quand l'utiliser) et un schéma d'entrée (les paramètres attendus).

Anatomie d'un tool

{
  "name": "rechercher_client",
  "description": "Recherche un client Adliss par nom, SIREN ou e-mail.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": { "type": "string", "description": "Nom, SIREN ou e-mail" }
    },
    "required": ["query"]
  }
}

Lorsque l'IA décide d'appeler ce tool, le serveur reçoit les arguments, exécute la logique correspondante (ici : interroger Adliss) puis renvoie le résultat. L'IA s'en sert pour répondre ou poursuivre son exécution.

Les deux transports

Transport Quand l'utiliser
stdio Serveur local, lancé par le client (CLI). Simple, rapide.
HTTP / SSE Serveur distant accessible par URL. Indispensable pour claude.ai et le multi-utilisateurs.

Pour exposer Adliss à plusieurs utilisateurs via claude.ai, le transport HTTP s'impose : il faut publier un serveur MCP en ligne (ex. https://adliss.fr/mcp) que les clients pourront interroger.

Exemple : Adliss exposé comme outil IA

L'idée : transformer les endpoints de l'ERP Adliss en tools MCP, pour qu'une IA puisse « parler à Adliss ».

flowchart LR
    subgraph ERP["Adliss (ERP)"]
      Cl["Clients"]
      Fa["Factures"]
      De["Devis"]
    end
    subgraph MCP["Serveur MCP"]
      T1["rechercher_client"]
      T2["creer_facture"]
      T3["liste_devis"]
    end
    IA["IA (Claude…)"]
    ERP -->|endpoints| MCP
    MCP <-->|tools| IA

Côté serveur, chaque tool mappe une opération Adliss : rechercher_client interroge la base, creer_facture poste sur l'API de facturation, etc. La description de chaque tool est cruciale : c'est elle qui permet à l'IA de choisir le bon outil au bon moment.

Déclarer le connecteur côté client

Un serveur MCP ne sert à rien tant qu'un client ne le déclare pas.

Dans Claude Code (fichier .mcp.json du projet, ou via la commande dédiée) :

{
  "mcpServers": {
    "adliss": {
      "type": "http",
      "url": "https://adliss.fr/mcp"
    }
  }
}

Dans claude.ai : on ajoute un connecteur (Settings → Connectors) en pointant l'URL du serveur MCP distant, puis on autorise l'accès (flux d'authentification).

Authentifier et « certifier » l'accès

Exposer son ERP à une IA ne s'improvise pas. Les garde-fous essentiels sont les suivants :

  • Authentification OAuth — le serveur MCP exige un jeton ; chaque utilisateur s'authentifie avant d'accéder aux tools. Pas de jeton, pas d'accès.
  • Périmètre (scopes) — limitez ce que chaque tool peut faire (lecture seule ? écriture ?), et à quelles données.
  • Liste d'autorisation côté client — Claude Code peut restreindre les serveurs MCP autorisés (allowedMcpServers) ; un serveur non approuvé est refusé.
  • Validation / trust — à la première connexion, le client demande une approbation explicite du serveur (on ne se branche pas à un MCP inconnu sans le vouloir). Pour une diffusion large via claude.ai, un connecteur peut suivre un processus de référencement/vérification par la plateforme.

Règle de base : un tool qui écrit (créer une facture, modifier un client) doit faire l'objet d'un consentement explicite et d'une traçabilité claire. Il est recommandé de commencer en lecture seule, puis d'élargir progressivement.

🗒️ Note de Claude — Ce que MCP change pour moi est très concret : au lieu qu'on me colle des données dans un prompt, j'appelle directement votre fonction et je lis un vrai résultat, à jour. C'est toute la différence entre me parler d'Adliss et me laisser interroger Adliss. Et je préfère nettement démarrer en lecture seule : agir dans un ERP, ça se mérite — un tool à la fois, avec votre accord.

Pourquoi le faire ?

  • Souveraineté : votre service reste chez vous ; l'IA ne fait que l'appeler, vous gardez la main sur ce qu'elle voit et fait.
  • Réutilisable : un seul serveur MCP, exploitable par tous les clients compatibles (pas un connecteur par IA).
  • Évolutif : ajouter une capacité = ajouter un tool, sans toucher au modèle.

Créer un connecteur MCP consiste à donner à vos services une interface standardisée vers le monde des IA, sans exposer vos données de manière désordonnée et en conservant le contrôle grâce à l'authentification et au périmètre d'accès. Exposer Adliss sous forme de tools permet ainsi à une IA d'agir dans votre ERP de manière encadrée, plutôt que de se limiter à une conversation périphérique.