Accueil / Articles

MCP expliqué : Créer un assistant PostgreSQL en langage naturel pour Claude

Explication du MCP à travers un projet : comment le Model Context Protocol transforme les intégrations N x M en N + M, afin que le serveur PostgreSQL en lecture seule puisse être interrogé par Claude Desktop.

Éditeur : REACTAPP.TOP10 min de lecture2335 mots

Sources: MCP Explained: The Protocol That Finally Gives AI a Standard Way to Talk to the World

Le problème du code de liaison

À un moment donné, tous les développeurs qui créent des produits d’IA se heurtent au même obstacle. Le modèle est performant, et il existe des données utiles dans une base de données, un système de fichiers ou une API. Ce qui manque, c’est une méthode propre et standard pour relier ces deux éléments.

C’est ainsi que naît le code de liaison : un adaptateur ici, un enveloppe fragile là. Ce système fonctionne tant que le modèle ne change pas, qu’une deuxième source de données n’apparaît pas, ou qu’un nouveau collègue doit recompiler toute la couche de connexion.

La solution d’Anthropic est apparue en novembre 2024 sous forme du Model Context Protocol (MCP). En l’espace d’environ deux ans, il est passé d’une expérience de niche à une infrastructure de référence pour les agents : 97 millions de téléchargements de SDK par mois à la mi-2026, ainsi que près de 10 000 serveurs publics actifs dans le registre officiel.

Imaginons un produit dans lequel les utilisateurs posent des questions sur les données de l’entreprise en langue anglaise simple. L’idée est simple, mais sa mise en œuvre est complexe. Le système doit interpréter la question, la transformer en requête de base de données, l’exécuter, renvoyer les résultats au modèle et formater une réponse. Multiplions cela par chaque outil auquel l’IA doit interagir, comme un calendrier, un dépôt GitHub ou un espace de travail Slack, et chacun devient une intégration spécifique avec ses propres formats API, flux d’authentification et formats d’erreurs.

Certains ingénieurs qualifient ce résultat d’« intégration spaghetti ». Si l’on compte les modèles par N et les outils par M, chaque combinaison nécessite un code distinct. L’ajout d’un nouveau modèle oblige à revoir tout le code des outils, tandis que l’ajout d’un nouvel outil exige de mettre à jour les intégrations de chaque modèle.

Qu’est-ce que MCP ?

MCP est une norme ouverte, basée sur JSON-RPC 2.0, qui fournit aux modèles un vocabulaire commun pour interagir avec des outils et des données externes. Le nombre de connexions N × M est réduit à N + M, car un seul serveur peut servir n’importe quel client respectant le protocole.

L’analogie la plus courante est celle du USB-C. Autrefois, les chargeurs variaient selon les ordinateurs portables, téléphones, appareils photo et écouteurs, chacun nécessitant son propre câble. Le USB-C a modifié le connecteur sans changer la nature de l’électricité, permettant ainsi d’utiliser un seul câble pour tout. MCP joue ce rôle pour l’IA : un modèle qui utilise ce protocole peut accéder à n’importe quel outil qui le prend en charge, de sorte qu’un serveur écrit une seule fois fonctionne avec tous les modèles compatibles.

La gouvernance a fait de 2026 un tournant décisif. En décembre 2025, Anthropic a transféré MCP à la Agentic AI Foundation, un fonds géré au sein de la Linux Foundation que Anthropic, Block et OpenAI ont cofondé, ce qui a montré que le protocole n’appartenait plus exclusivement à Anthropic. Un soutien public a suivi : le PDG d’OpenAI l’a approuvé et a annoncé son soutien via l’SDK des agents et ChatGPT, tandis que Google DeepMind a confirmé quelques jours plus tard que Gemini utiliserait MCP pour ses outils. Ce protocole est désormais la voie par défaut pour relier les modèles aux outils, données et services externes.

Les trois composants

L’hôte est l’application que l’utilisateur interagit réellement : Claude Desktop, une extension pour VS Code ou un chatbot interne.

Le client MCP se trouve à l’intérieur de l’hôte. Il maintient des connexions ouvertes avec un ou plusieurs serveurs MCP et route les messages entre le modèle et ces serveurs, de sorte que lorsque le modèle décide d’appeler une fonction, c’est le client qui transmet la demande.

Le serveur MCP est l’endroit où résident les capacités. Chaque serveur encapsule une fonction ou une source de données derrière une interface standard et peut offrir trois types de ressources :

  • Les fonctions sont des fonctions appelables telles que run_sql_query, search_web ou send_email. Le modèle les utilise pour effectuer une action ou récupérer des données.
  • Les ressources sont des données lisible, comme des fichiers, des lignes de base de données ou des documents, que le modèle peut intégrer dans sa fenêtre de contexte.
  • Les modèles de prompts sont des templates de prompts réutilisables que le serveur transmet à l’hôte.

Les messages sont codés en JSON-RPC 2.0 et transmis via l’un de deux protocoles de transport. stdio convient aux serveurs exécutés en tant que processus local sur la machine du client. Streamable HTTP est destiné aux serveurs distants et aux déploiements cloud, en utilisant des requêtes HTTP ordinaires et, éventuellement, Server-Sent Events (SSE) pour des réponses en flux continu et des notifications du serveur au client. Grâce à cette séparation, un seul protocole couvre à la fois le développement local et les systèmes à grande échelle.

Une question, étape par étape

Voici ce qui se passe entre le moment où un utilisateur tape une question et celui où il reçoit une réponse.

  1. Un utilisateur demande : « Combien de commandes avons-nous reçues la semaine dernière ? »
  2. Le modèle voit la question à côté de la liste des outils disponibles, récupérée depuis le serveur MCP au démarrage.
  3. Il décide qu’il est nécessaire d’utiliser query_database et envoie une requête structurée à cet outil.
  4. Le client MCP intercepte l’appel et le renvoie au serveur approprié.
  5. Le serveur exécute la requête et renvoie le résultat sous forme de JSON.
  6. Le modèle lit ce résultat et rédige une réponse en langue simple.

Le modèle ne touche jamais directement à la base de données, et il n’a pas besoin de la chaîne de connexion à l’avance, car c’est le serveur MCP qui s’en occupe.

Le projet : une interface de chat pour PostgreSQL

En dehors de la théorie, voici quelque chose de concret. Une équipe conserve ses données de commandes dans PostgreSQL, et les collègues non techniques demandent constamment à la seule personne connaissant SQL de préparer des rapports. L’objectif est d’avoir une interface de chat permettant de poser des questions en anglais simple et d’obtenir des réponses en temps réel, sans avoir à écrire de SQL.

Le plan consiste en un serveur MCP en amont de la base de données PostgreSQL, offrant une seule fonction query_database et connecté à Claude. Tout membre de l’équipe peut alors poser une question en langage courant et obtenir des données réelles en retour.

Mise en place

Commencez par une nouvelle boîte à projets et installez les dépendances nécessaires.

mkdir nl-db-assistant
cd nl-db-assistant
npm init -y
npm install @modelcontextprotocol/sdk pg dotenv zod

Ces packages se chargent de diviser le travail. @modelcontextprotocol/sdk est le kit officiel d’Anthropic en JavaScript et TypeScript pour les serveurs MCP, pg est le client PostgreSQL habituel pour Node.js, et dotenv empêche les identifiants de base de données d’apparaître dans le code source. zod vérifie les schémas en temps de exécution, et MCP s’appuie sur lui pour générer le schéma JSON grâce auquel le modèle apprend à appeler les outils.

Créez un fichier .env dans la racine du projet contenant la chaîne de connexion.

DATABASE_URL=postgresql://your_user:your_password@localhost:5432/your_database

Ajoutez immédiatement .env à .gitignore, car les identifiants ne doivent jamais être soumis à versionnement.

Le squelette du serveur

Ensuite vient server.js, qui commence par les imports, le nom et la version du serveur, ainsi qu’un pool de bases de données.

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";
import pg from "pg";
import dotenv from "dotenv";

dotenv.config();
// Set up the PostgreSQL connection pool
const pool = new pg.Pool({
  connectionString: process.env.DATABASE_URL,
});
// Create the MCP server instance
const server = new McpServer({
  name: "postgres-assistant",
  version: "1.0.0",
});

Le nom et la version sont communiqués au client lors de l’échange de négociation des capacités au moment de sa connexion. Le pool de connexions est créé une seule fois et réutilisé pour chaque requête, ce qui est bien plus efficace que d’ouvrir une nouvelle connexion à chaque fois.

Exposition du schéma

Afin que le modèle puisse générer des requêtes utiles, il doit connaître les tables et les colonnes existantes. Le schéma en temps réel est exposé sous forme de ressource MCP lisible qu’il peut intégrer dans son contexte.

server.resource(
  "database-schema",
  "schema://main",
  async (uri) => {
    const result = await pool.query(`
      SELECT
        table_name,
        column_name,
        data_type
      FROM information_schema.columns
      WHERE table_schema = 'public'
      ORDER BY table_name, ordinal_position
    `);

    const schema = result.rows.reduce((acc, row) => {
      if (!acc[row.table_name]) acc[row.table_name] = [];
      acc[row.table_name].push(`${row.column_name} (${row.data_type})`);
      return acc;
    }, {});
    const schemaText = Object.entries(schema)
      .map(([table, cols]) => `${table}:\n  ${cols.join("\n  ")}`)
      .join("\n\n");
    return {
      contents: [{
        uri: uri.href,
        text: schemaText,
      }],
    };
  }
);

information_schema.columns est une vue intégrée de PostgreSQL qui décrit chaque table et chaque colonne. Le code interroge cette vue, reformate les lignes en texte lisible et renvoie ce résultat sous forme de ressource. Le modèle la lit avant de décider comment écrire une requête, ce qui lui permet d’avoir l’ensemble du schéma sans devoir deviner quel SQL est valide.

Outil de requête

C’est le cœur du serveur, l’outil que le modèle utilise pour exécuter des SQL sur la base de données.

server.tool(
  "query_database",
  "Run a read-only SQL query against the PostgreSQL database. Use this to answer questions about data, counts, trends, or summaries.",
  {
    sql: z.string().describe(
      "A valid PostgreSQL SELECT query. Only SELECT statements are allowed."
    ),
  },
  async ({ sql }) => {
    // Safety gate: only allow SELECT statements
    const trimmed = sql.trim().toUpperCase();
    if (!trimmed.startsWith("SELECT")) {
      return {
        content: [{
          type: "text",
          text: "Error: only SELECT queries are permitted through this interface.",
        }],
        isError: true,
      };
    }
    try {
      const result = await pool.query(sql);
      const output = JSON.stringify(result.rows, null, 2);
      return {
        content: [{
          type: "text",
          text: `Query returned ${result.rowCount} row(s):\n\n${output}`,
        }],
      };
    } catch (err) {
      return {
        content: [{
          type: "text",
          text: `Query failed: ${err.message}`,
        }],
        isError: true,
      };
    }
  }
);

Faites très attention à la chaîne de description, le deuxième argument, car le modèle la lit pour déterminer s’il faut utiliser l’outil et comment le faire. Rédigez-la comme des instructions destinées à un stagiaire compétent qui n’a jamais vu de base de données. Le schéma de Zod pour le paramètre sql se transforme automatiquement en schéma JSON que voit le modèle, ce qui définit la structure de l’argument. Une vérification en amont n’accepte que les instructions SELECT, de sorte qu’aucune opération d’écriture ne peut passer, que ce soit intentionnellement ou par erreur.

Démarrage du serveur

Finalement, le serveur démarre via le transport stdio.

const transport = new StdioServerTransport();
await server.connect(transport);
console.error("PostgreSQL MCP server is running");

Avec stdio, le client MCP lance le script en tant que processus enfant et communique avec lui via l’entrée et la sortie standard. C’est le moyen de transmission le plus simple et le plus fiable pour le développement local. La ligne de journal utilise délibérément console.error afin de ne pas contaminer le canal stdout que MCP utilise pour les messages de protocole.

Connexion à Claude Desktop

Ouvrez le fichier de configuration de Claude Desktop. Sur macOS, il se trouve ici :

~/Library/Application Support/Claude/claude_desktop_config.json

Sur Windows, le chemin est :

%APPDATA%\Claude\claude_desktop_config.json

Ajoutez une entrée pour le nouveau serveur :

{
  "mcpServers": {
    "postgres-assistant": {
      "command": "node",
      "args": ["/absolute/path/to/nl-db-assistant/server.js"]
    }
  }
}

Redémarrez Claude Desktop, et une petite icône d’outil apparaîtra dans l’interface pour confirmer que les serveurs MCP sont connectés et prêts.

Essayer

Les formulations courantes fonctionnent : combien de commandes ont été reçues au cours de la semaine dernière, quelle catégorie de produit a généré le plus de revenus ce mois-ci, ou quels sont les cinq plus gros clients en termes de valeur totale des commandes.

Claude lit la ressource de schéma en temps réel, écrit une requête SQL appropriée, appelle query_database, reçoit les résultats et les transforme en une réponse claire. Les collègues non techniques ne voient jamais la requête, seulement une question et une réponse.

Environ 80 lignes de JavaScript permettent de créer un serveur qui affiche le schéma PostgreSQL en temps réel pour tout modèle connecté, convertit les questions en langage naturel en requêtes SQL, limite l’accès au mode lecture seule et renvoie des résultats structurés que le modèle peut résumer. Il a été écrit une seule fois, et tout modèle compatible MCP, que ce soit Claude aujourd’hui ou un autre demain, peut l’utiliser sans aucune modification du serveur. C’est là l’avantage d’un protocole partagé.

Chiffres d’adoption

L’adoption a été rapide. Le nombre de téléchargements mensuels du SDK est passé de 100 000 au lancement à 97 millions en mars 2026, soit une augmentation d’environ 970 fois en 18 mois. En revanche, il a fallu à peu près trois ans au package npm de React pour atteindre 100 millions de téléchargements mensuels.

Les utilisateurs professionnels incluent Block, Bloomberg, Amazon ainsi que des centaines d’entreprises du classement Fortune 500. En avril 2026, Pinterest a décrit sa configuration MCP pour les environnements de production : des serveurs spécifiques aux besoins de Presto, Spark et Airflow, avec une personne chargée d’approuver les opérations sensibles. Environ 66 000 appels aux outils par mois, effectués par 844 utilisateurs actifs, permettraient d’économiser environ 7 000 heures de travail d’ingénierie chaque mois.

Il existe actuellement des serveurs MCP officiels ou gérés par la communauté pour Slack, GitHub, Google, Salesforce et Stripe, ainsi que pour HubSpot, Shopify, Notion, Linear, Sentry, Figma, Webflow, Cloudflare et Postman.

Le thème du plan stratégique pour 2026 est la préparation des entreprises. Les principaux éléments prévus sont l’authentification OAuth 2.1 liée à des fournisseurs d’identité d’entreprise, une coordination entre plusieurs agents où l’un d’eux peut être appelé comme un serveur d’outils, ainsi qu’un registre sélectionné de serveurs vérifiés accompagnés de notes de sécurité.

Questions fréquentes

Le MCP n’est-il qu’un appel de fonction avec des étapes supplémentaires ? Non, car ils opèrent à des niveaux différents. Un appel de fonction correspond à un modèle qui choisit d’invoquer un outil, tandis que le MCP est le protocole qui relie le modèle à l’outil. L’appel de fonction décide s’il faut appeler un outil, tandis que le MCP gère la manière d’y accéder et de communiquer avec lui. Les configurations modernes typiques combinent les deux.

Ne fonctionne-t-il qu’avec Claude ? Pas du tout, ce qui constitue l’un de ses meilleurs atouts. OpenAI, Google DeepMind et Microsoft ont adopté le MCP, tout comme des milliers d’équipes de développement. Un modèle disposant d’un client compatible avec MCP peut utiliser n’importe quel serveur MCP, indépendamment de la société qui a développé l’un ou l’autre composant.

Est-il prêt pour la production en 2026 ? Pour la plupart des utilisations, oui, compte tenu des déploiements à grande échelle mentionnés ci-dessus. Cependant, pour les systèmes où la latence est cruciale, comme le trading en temps réel ou les exigences inférieures à 100 ms, cette abstraction comporte des inconvénients, et les connexions API directes peuvent être préférables à celles médiées par MCP.

Est-il suffisamment sécurisé pour un usage d’entreprise ? Il y travaille. La mise à jour des spécifications de mars 2025 a ajouté un cadre d’autorisation complet basé sur OAuth 2.1, et le plan pour 2026 vise l’intégration de SAML et OIDC avec des fournisseurs d’identité tels que Okta et Azure AD. Les secteurs fortement réglementés comme la finance ou la santé nécessitent encore pour l’instant des couches supplémentaires de conformité.

Qui le gère, et Anthropic pourrait-il changer de direction ? Depuis décembre 2025, ce protocole relève de l’Agentic AI Foundation au sein de la Linux Foundation. Cela en fait une infrastructure partagée neutre par rapport aux fournisseurs et gérée par la communauté, comparable à HTTP ou TCP/IP, et aucune entreprise ne peut le rediriger unilatéralement.

Qu’est-ce qui distingue un outil d’une ressource ? Un outil est une action que le modèle choisit d’effectuer, comme lancer une requête, envoyer un message ou créer un fichier. Une ressource, quant à elle, sont des données que le modèle lit passivement, telles qu’un fichier, un schéma ou un document. Les ressources sont chargées dans le contexte, tandis que les outils s’exécutent sur demande au cours de la conversation.

Un seul serveur peut-il gérer plusieurs bases de données ou services ? Oui. Un serveur peut proposer autant d’outils et de ressources que cela est pertinent, et une configuration courante consiste en un serveur de plateforme de données qui offre un accès en lecture à plusieurs bases de données, chacune exposée en tant qu’outil ou ressource distincte.