---
title: Créer un connecteur MCP : exposer votre service aux LLM
source: https://synapx.fr/blog/creer-connecteur-mcp/
date: 2026-06-26
category: IA
site: SynapxLab
---

# Créer un connecteur MCP : exposer votre service aux LLM

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

```json
{
  "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 ».

```
Adliss (ERP)                Serveur MCP                 IA (Claude…)
  ┌─────────┐   endpoints   ┌──────────────┐   tools    ┌─────────┐
  │ Clients │──────────────▶│ rechercher_  │◀──────────▶│ "Trouve │
  │ Factures│               │   client     │            │  le CA  │
  │ Devis   │               │ creer_facture│            │  de X"  │
  └─────────┘               │ liste_devis  │            └─────────┘
                            └──────────────┘
```

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) :

```json
{
  "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.

## 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.