Serveurs MCP de base de données comparés : relais cloud vs MCP local

Il y a un an, « laisse l'IA regarder ma base de données » était un tour de passe-passe. Tu branchais un serveur MCP, demandais à Claude de lister tes tables, le regardais faire la chose, puis tu fermais l'onglet et retournais à ton vrai workflow. C'était astucieux. C'était aussi assez brut pour que tu ne lui confies rien d'important.

Ça a changé. La prise en charge de MCP est désormais standard parmi les assistants que les gens utilisent réellement — Claude Desktop, Cursor, Windsurf, Codex — et les serveurs se sont améliorés. La découverte de schéma fonctionne, la génération de requêtes fonctionne, et la boucle est assez fiable pour que j'y aie recours plusieurs fois par jour sans y penser.

Ce qui signifie que la question intéressante s'est déplacée. Ce n'est plus s'il faut connecter une IA à ta base de données. C'est où vit la connexion. Cette seule décision détermine qui détient tes identifiants, ce que tes données touchent sur le chemin vers le modèle, et si tes coéquipiers peuvent utiliser la même configuration.

Il y a trois architectures couramment utilisées, et elles sont amalgamées dans beaucoup de listicles « MCP pour bases de données » comme si elles étaient interchangeables. Elles ne le sont pas. J'ai mis en place les trois et j'ai intégré l'une d'elles dans un produit, donc j'ai des opinions. Mais ce n'est pas un réquisitoire contre les options cloud — elles résolvent de vrais problèmes, et je le dirai. Le but est une carte lucide pour que tu choisisses délibérément au lieu de te rabattre par défaut sur ce que le premier tutoriel que tu as lu t'a dit de faire.

Ce qu'est réellement un serveur MCP de base de données

Enlève le marketing et un serveur MCP de base de données est une petite chose, presque ennuyeuse : c'est un processus qui détient une connexion à une base de données et l'expose à un assistant IA sous forme d'un ensemble d'outils appelables.

MCP — le Model Context Protocol — est un protocole ouvert pour exactement ça. Il est basé sur JSON-RPC, ce qui est une façon élégante de dire que le client et le serveur échangent des messages de requête et de réponse structurés. Le client, c'est l'assistant IA avec lequel tu discutes. Le serveur est un processus séparé qui fait le vrai travail. Le client décide quand appeler un outil en fonction de la conversation ; tu n'invoques rien manuellement. Tu dis « montre-moi les commandes de la semaine dernière » et l'assistant comprend qu'il doit appeler l'outil de requête avec du SQL.

Un serveur de base de données expose typiquement une poignée d'outils dans cet esprit :

list tables — énumérer les tables de la base de données
describe schema — renvoyer les colonnes, les types et les contraintes d'une table donnée
run query — exécuter une instruction SQL et renvoyer des lignes
execute — exécuter une instruction qui modifie les données ou le schéma (souvent conditionné derrière un flag)

Les noms exacts varient d'un serveur à l'autre, mais la forme est cohérente. L'IA lit les définitions des outils quand elle se connecte, voit qu'un outil run query existe, et sait qu'elle peut y recourir quand une question appelle de vraies données.

La partie que les gens ratent, c'est la séparation entre le client et le serveur, et le fait que le serveur doit aller d'où il tourne jusqu'à ta base de données d'une manière ou d'une autre. Deux transports sont courants. Local stdio signifie que le serveur est un processus enfant du client IA, tournant sur ta machine, communiquant via l'entrée et la sortie standard — aucun réseau impliqué du tout. HTTP ou SSE signifie que le serveur est joignable sur le réseau, ce dont tu as besoin quand il ne tourne pas sur la même machine que le client.

Si tu veux la version pratique de tout ça — les vrais fichiers de configuration et la mise en place pas à pas — j'ai écrit un guide complet dans configurer un serveur MCP local pour ta base de données. Cet article-ci est la comparaison ; celui-là est le tutoriel.

Trois architectures

Il y a trois façons de mettre un serveur MCP de base de données en production. Elles semblent identiques depuis la fenêtre de chat. Elles sont très différentes en dessous.

Relais cloud

Un relais cloud est un point de terminaison MCP hébergé. Au lieu de faire tourner un serveur toi-même, tu t'inscris à un service, tu lui confies les détails de connexion à ta base de données — une connection string, ou une autorisation OAuth dans ta base de données — et il te donne une URL à coller dans la config de ton client MCP. Le client IA envoie les appels d'outils au cloud du fournisseur, le cloud du fournisseur exécute les requêtes contre ta base de données, et les résultats reviennent de la même façon.

L'attrait est évident, et je veux être juste à ce sujet. La mise en place est réellement nulle : aucun processus à installer, aucun runtime à gérer, aucun fichier de config au-delà d'une URL. Ça fonctionne depuis n'importe quelle machine, y compris un portable d'entreprise verrouillé où tu ne peux pas installer de logiciel. Et c'est partageable — toute une équipe peut pointer vers le même point de terminaison, ce avec quoi les configurations locales ont du mal. Si ton organisation a une équipe plateforme centrale qui veut offrir « l'accès aux bases de données pour l'IA » comme un service interne géré, le modèle du relais est un choix naturel, et certains de ces services ajoutent la journalisation des requêtes, la limitation de débit et des pistes d'audit qu'un serveur local nu n'a pas.

Le coût est tout aussi évident une fois qu'on le dit à voix haute : tes identifiants de connexion vivent sur les serveurs de quelqu'un d'autre, et chaque requête que tu exécutes — le SQL et les lignes qu'il renvoie — transite par leur infrastructure. Ce sont deux expositions distinctes. Celle des identifiants m'inquiète le plus, parce qu'un identifiant de base de données est une clé vers toute la base de données, pas seulement vers la requête que tu as lancée. L'exposition des données est celle que les gens mentionnent d'habitude en premier, et elle est réelle : le jeu de résultats passe par le relais sur son chemin vers toi et sur son chemin vers le modèle.

Rien de tout ça n'est une raison de qualifier les relais de mauvais. C'est une raison d'être précis sur ce que tu achètes. Un relais est une décision de confiance — tu décides que la commodité d'une mise en place nulle vaut la peine d'ajouter un tiers à un chemin qui n'en aurait autrement que deux. Pour une base de données d'analyse en lecture seule dont les données sont déjà largement accessibles, cet échange peut être acceptable. Pour une base de production avec des dossiers clients, ce n'est généralement pas le cas.

Distant auto-hébergé

L'option intermédiaire est de faire tourner le serveur MCP toi-même, mais pas sur ton portable. Tu le montes sur un VPS, un conteneur, ou un hôte interne, et ton client IA s'y connecte via HTTP. C'est l'option « je veux la portée d'un relais sans le tiers ».

Tu contrôles l'hôte. Tu contrôles les identifiants — ils sont sur une infrastructure que tu possèdes, pas celle d'un fournisseur. Tu peux le placer derrière ton VPN, le mettre sur un sous-réseau privé, le brancher à ton auth existante, et le journaliser comme tu veux.

Le compromis, c'est que tu viens d'assumer un service toujours actif. Ce serveur est maintenant un processus de longue durée avec une connexion à une base de données et un écouteur réseau, ce qui signifie qu'il a une surface d'authentification, un rythme de mise à jour, et une histoire de disponibilité. Il est joignable depuis le réseau par conception — c'est le but — donc la question devient qui peut l'atteindre et avec quoi. S'il est exposé à internet sans une solide auth devant lui, tu as construit un proxy de base de données et laissé la porte ouverte.

L'auto-hébergement est la bonne réponse pour certaines équipes — en particulier celles qui ont la maturité opérationnelle pour bien faire tourner des services internes. C'est une mauvaise réponse pour un développeur solo qui veut juste que l'IA voie son Postgres local, parce que la charge de maintenance ne lui apporte rien.

MCP local

Le MCP local est le plus simple des trois à appréhender. Le serveur est un processus sur ton portable. Il parle au client via stdio, ou via HTTP lié à localhost. Tes identifiants ne quittent jamais la machine, parce que la machine qui les détient est celle sur laquelle le serveur tourne, et le client est sur cette machine aussi.

Le flux est assez court pour tenir en une ligne : client IA → processus serveur local → ta base de données, le tout sur du matériel que tu contrôles. Rien dans ce chemin ne franchit une frontière réseau sans y être obligé. Quand la base de données est elle-même locale — un fichier SQLite, ou une instance Postgres tournant dans Docker — la boucle entière peut fonctionner avec le wifi coupé, une propriété qu'aucune des autres architectures ne possède.

Le compromis, c'est que c'est par machine. Ta config vit sur ton portable. Le portable de ton coéquipier a la sienne. Il n'y a pas de point de terminaison partagé, pas d'endroit central où mettre à jour, et aucun moyen pour la configuration soignée d'une personne de bénéficier à quiconque d'autre. Si tu fais tourner un identifiant de base de données, tu le fais tourner à un endroit sur ta machine et séparément sur celle de tous les autres. Pour un développeur solo ou une petite équipe, c'est une erreur d'arrondi. Pour une organisation de cinquante personnes, c'est ce qui te pousse vers l'une des options distantes.

Il y a aussi un pli qui mérite d'être nommé : le MCP local n'est sûr qu'à hauteur de la sécurité de la machine. Si ton portable est compromis, la connexion à la base de données qu'il détient l'est aussi. C'est vrai de tout identifiant sur la machine, cependant, donc ce n'est pas un argument contre le MCP local en particulier — c'est juste la posture de sécurité standard d'un poste de travail, et c'est un problème plus petit et plus familier que « un tiers détient une clé de ma base de données de production ».

La comparaison

Voici la comparaison côte à côte. La colonne qui compte le plus est la dernière, mais les colonnes du milieu sont là où vivent les vrais compromis.

Architecture	Où vivent les identifiants	Effort de mise en place	Partage en équipe	Les données quittent-elles ta machine ?
Relais cloud	Serveurs du fournisseur	Minimal — inscription, colle une connection string, copie une URL	Intégré — un point de terminaison pour tout le monde	Oui — les requêtes et les résultats transitent par le fournisseur
Distant auto-hébergé	Ton hôte (VPS/conteneur/interne)	Modéré — déployer, sécuriser et maintenir un service	Oui, si tu le partages — plus la gestion des accès	Oui — quitte la machine du client pour ton serveur
MCP local	Ta machine uniquement	Faible — installer et configurer par machine	Non — par machine par conception	Non — le serveur tourne sur ta machine

Quelques choses découlent de ce tableau.

Premièrement, « les données quittent-elles ta machine » et « atteignent-elles le modèle » sont deux questions différentes, et il est facile de les confondre. Avec le MCP local, tes identifiants ne partent jamais, et les résultats de la requête vont quand même au fournisseur d'IA, parce que le modèle a besoin de les voir pour te répondre. C'est fondamental dans le fonctionnement de tout ça — tu ne peux pas faire raisonner une IA sur tes données sans que l'IA voie tes données. Ce que le MCP local supprime, c'est le relais : le tiers supplémentaire assis entre ta machine et le modèle. Il ne supprime pas le modèle lui-même, et aucune architecture ne le fait.

Deuxièmement, la colonne « effort de mise en place » est trompeuse à elle seule, parce qu'elle mesure la première heure et non la centième. Le relais cloud gagne la première heure de manière décisive. Le distant auto-hébergé perd la première heure et continue de la perdre à chaque fois que tu patches, fais tourner ou débogues. Le MCP local est facile la première heure et le reste, mais tu le paies dans la colonne « partage en équipe ».

Troisièmement, le partage en équipe est le seul endroit où le modèle local est réellement faible, et je ne prétendrai pas le contraire. Si ton organisation a besoin d'une couche d'accès aux bases de données partagée, gérée et auditable pour l'IA, une architecture distante est le bon choix, point final. Le MCP local est un outil personnel, et il vaut mieux l'évaluer comme tel.

Ce qu'il faut rechercher dans un serveur MCP de base de données

Quelle que soit l'architecture que tu choisis, l'ensemble de fonctionnalités du serveur lui-même compte énormément. Une connexion à une base de données remise à une IA est une chose puissante, et la différence entre un serveur soigneux et un serveur négligent est la différence entre un outil que tu peux utiliser sur de vraies données et un handicap. Voici ce que je vérifie réellement.

Mode lecture seule. C'est le minimum vital. Un bon serveur peut être configuré pour autoriser SELECT et l'inspection du schéma tout en refusant tout ce qui écrit — pas d'INSERT, pas d'UPDATE, pas de DELETE, pas de DDL. Pour toute base de données que tu ne peux pas te permettre de perdre, ça devrait être le défaut, pas une option que tu dois dénicher.

Périmètre par source. Si tu as plusieurs bases de données connectées, le serveur devrait te laisser choisir lesquelles sont exposées à l'IA. Tu veux pouvoir dire « l'IA peut voir la base de brouillon mais pas celle de production » sans déconnecter quoi que ce soit. C'est l'un des contrôles les plus sous-estimés, parce qu'il te permet d'être généreux avec l'IA sur les bases qui ne comptent pas et strict sur celles qui comptent.

Confirmation avant les opérations destructrices. L'IA ne devrait pas pouvoir supprimer une table ou effacer des lignes sans une étape délibérée. Que ce soit un mode qui bloque entièrement les écritures ou une invite de confirmation, l'idée est que la destruction n'est jamais un seul appel d'outil non gardé. C'est important parce que les modèles font des erreurs et parce que l'injection de prompt est réelle — si l'IA lit du texte hostile dans tes données, tu ne veux pas que ce texte puisse se transformer en DROP TABLE.

Liaison à localhost uniquement. Si le serveur parle HTTP, il devrait se lier à 127.0.0.1, pas 0.0.0.0. La différence est de savoir si quelqu'un d'autre sur ton réseau peut l'atteindre. Un serveur MCP de base de données accidentellement exposé sur le wifi d'un café, c'est un mauvais après-midi.

Visibilité de l'audit et des logs. Tu devrais pouvoir voir quelles requêtes l'IA a réellement exécutées. Quand quelque chose semble anormal — une écriture inattendue, une requête qui touche une colonne qu'elle n'avait aucunement à toucher — tu veux un enregistrement à examiner. Les serveurs qui exposent ça te donnent une boucle de rétroaction ; ceux qui ne le font pas te demandent de faire aveuglément confiance.

Couverture des bases de données. Vérifie que les bases de données que tu utilises réellement sont prises en charge, et bien prises en charge. Un serveur qui « prend en charge Postgres » nominalement mais s'étouffe sur les schémas avec des extensions, ou un qui ne gère pas les particularités de SQLite, est pire qu'inutile parce qu'il échouera de manière déroutante.

Peux-tu le pointer vers un réplica ? Le meilleur geste de durcissement pour l'accès IA à une base de données est de le connecter à un réplica de lecture plutôt qu'au primaire. Si le serveur peut être pointé vers un réplica — ou si tu peux simplement lui donner un utilisateur en lecture seule sur l'un d'eux — alors même une erreur catastrophique du modèle ne peut pas endommager tes données de production. C'est l'équivalent base de données de travailler sur une copie, et c'est le conseil que je donne le plus souvent.

Le paysage

Je vais décrire ça en catégories plutôt qu'en liste de produits, parce que l'écosystème MCP bouge assez vite pour que toute liste spécifique soit périmée au moment où tu la lis. Mais les catégories sont stables, et elles valent la peine d'être comprises.

Serveurs officiels et communautaires pour des bases de données spécifiques. Il y a des serveurs MCP pour Postgres, pour SQLite et pour MySQL, maintenus par un mélange de la communauté du protocole lui-même et de développeurs indépendants. Ils prennent généralement une connection string ou un chemin de fichier, se connectent directement à la base de données, et exposent les outils de requête/schéma décrits plus haut. Ils sont typiquement open source et auditables, ce qui est une vraie vertu — tu peux lire exactement ce qu'ils font. Le hic, c'est que la plupart sont des serveurs directs : ils détiennent tes identifiants, ils tournent là où tu les fais tourner, et ils tendent à être minimaux en matière de contrôles d'accès. Beaucoup n'ont pas de mode lecture seule robuste, et la plupart ne te donnent ni périmètre par source ni journal d'audit. Ils sont excellents pour le développement local contre une base jetable et mal adaptés à tout ce qui est de qualité production sans emballage supplémentaire.

Offres hébergées qui encapsulent une connexion à une base de données. Ce sont les relais cloud. La catégorie inclut des services dont le produit entier est « connecte ta base de données à ton IA » — tu t'inscris, ils gèrent la connexion, et tu obtiens un point de terminaison. La qualité varie énormément, et la posture de sécurité varie encore plus, ce qui est exactement pourquoi la checklist ci-dessus compte. Ceux qui valent la peine d'être considérés sont ceux qui sont honnêtes sur leur traitement des données, offrent des contrôles de lecture seule et de périmètre, et peuvent expliquer en langage clair ce qui arrive à tes identifiants et à tes résultats de requête.

Outils de bureau qui embarquent leur propre serveur MCP local. C'est la catégorie la plus récente et celle dont je suis le plus proche, puisque BaseVolt en fait partie. L'idée, c'est que l'outil de base de données que tu utilises déjà pour parcourir et modifier des données fait aussi tourner un serveur MCP sur localhost comme l'une de ses fonctionnalités. Parce que l'outil gère déjà tes connexions et tes identifiants, le serveur MCP hérite de cette gestion — les identifiants restent dans l'appli, chiffrés localement, et le client IA parle à un processus sur ta machine plutôt qu'à un point de terminaison distant.

BaseVolt est une appli de bureau local-first pour macOS et Windows qui se connecte directement à PostgreSQL, MySQL, SQLite et Cloudflare D1. Son serveur MCP tourne sur localhost — le point de terminaison par défaut est http://localhost:3107/mcp — et comme il est local, le client IA parle à un processus sur ta propre machine, sans relais par un tiers. Il prend en charge le mode lecture seule et les restrictions par source de données, donc tu peux exposer une base de données à l'IA et en garder une autre entièrement hors de portée, et il journalise les appels d'outils MCP pour que tu puisses voir ce que l'IA a réellement fait. Tu peux voir tout le workflow sans rien installer sur la démo live.

La raison pour laquelle je l'ai construit ainsi plutôt qu'en livrant un relais autonome est précisément le problème des identifiants. L'outil doit déjà détenir tes identifiants de base de données pour fonctionner tout court — c'est ce qu'est un client de base de données. Lui donner un serveur MCP signifie que ces identifiants n'ont jamais à être dupliqués dans un fichier de config ou remis à un fournisseur. Le client IA ne les voit jamais, et le modèle non plus.

Une checklist de sécurité avant de connecter une IA à ta base de données

C'est la partie que j'imprimerais. Rien de tout ça n'est exotique ; tout est facile à sauter.

Commence par un utilisateur en lecture seule ou un réplica. Crée un utilisateur de base de données avec des privilèges SELECT uniquement, ou pointe le serveur vers un réplica de lecture. Fais ça avant tout le reste. C'est la chose au plus fort levier de cette liste, parce qu'elle rend tout le reste de la surface de risque radicalement plus petite. Si l'IA ne peut pas écrire, le pire cas cesse d'être « perte de données » et devient « le modèle a vu quelque chose qu'il n'aurait pas dû ».
Ne le pointe jamais vers la production avec un accès en écriture. Pas par défaut, pas « juste pour tester », pas pendant cinq minutes. L'accès en écriture à la production via un client IA est une erreur que tu ne peux faire qu'une seule fois. Si tu as besoin que l'IA aide sur des changements de schéma, fais-le contre une copie.
Limite à une seule base de données. Ne remets pas à l'IA tout ce que tu peux atteindre. Expose la base de données spécifique dont elle a besoin pour la tâche en cours, et rien d'autre. Ça limite à la fois le rayon d'impact d'une erreur et la quantité de données dans lesquelles le modèle peut s'aventurer.
Garde-le sur localhost quand c'est possible. Si le serveur peut tourner sur ta machine, fais-le tourner là. Un serveur lié à localhost n'est pas joignable depuis le réseau, ce qui élimine toute une classe de problèmes. Ne passe au distant que quand tu as une raison — le partage en équipe, ou une machine sur laquelle tu ne peux pas installer — et quand tu le fais, sécurise le point de terminaison délibérément.
Traite les résultats de requête comme des données que le modèle possède désormais. C'est le changement de modèle mental auquel les gens résistent. À l'instant où un jeu de résultats revient via le serveur MCP, ces lignes font partie du contexte de la conversation et sont en route vers le fournisseur du modèle. Si une colonne contient quelque chose que tu ne collerais pas dans une fenêtre de chat, ne la sélectionne pas. Utilise SELECT avec des colonnes explicites plutôt que SELECT *, et filtre ce dont tu n'as pas besoin.
Examine ce que le serveur journalise. Regarde le journal des requêtes régulièrement, au moins au début. Tu cherches des surprises — des écritures que tu n'as pas demandées, des tables que tu ne t'attendais pas à voir l'IA toucher. Un journal que tu ne lis jamais équivaut à pas de journal.
Révoque les identifiants quand tu as terminé. Si tu as créé un utilisateur dédié pour l'accès IA, supprime-le quand l'expérience est finie. Si tu as utilisé un jeton, fais-le tourner. Des identifiants créés dans un but ne devraient pas survivre à ce but, parce que la prochaine personne qui les trouvera ne saura pas pourquoi ils existent.

Le thème qui traverse tout ça, c'est que tu devrais minimiser ce que l'IA peut atteindre, pas seulement qui peut atteindre l'IA. La majeure partie de la conversation sur la sécurité MCP porte sur la protection du serveur. Le plus grand gain consiste généralement à limiter ce que le serveur est autorisé à toucher.

Comment choisir

Si tu as lu jusqu'ici, voici comment je déciderais réellement.

Si tu es un développeur solo ou une petite équipe travaillant avec des bases de données qui te tiennent à cœur, va en local. Installe un outil qui embarque son propre serveur MCP local, ou fais tourner un serveur direct contre une base de données locale. Garde les identifiants sur ta machine. Accepte que ce soit par machine, parce que pour une petite équipe ce coût est trivial. C'est l'architecture avec la meilleure posture de sécurité et le moins de maintenance continue, et elle couvre l'écrasante majorité des cas d'usage.

Si ton organisation a besoin d'un accès partagé, géré et auditable, va en distant — et fais-le délibérément. Soit auto-héberge, pour que tu possèdes l'hôte et les identifiants, soit choisis un relais dont tu as réellement lu le traitement des données. Mets une vraie auth devant. Donne-lui un utilisateur en lecture seule ou un réplica. Traite-le comme un service interne avec un propriétaire, pas comme un point de terminaison qu'on configure et qu'on oublie.

Si tu ne fais qu'explorer, utilise ce qui est le plus rapide, mais utilise une base de données jetable. L'expérience zéro configuration du relais est un véritable avantage quand tu tâtes le terrain. Ne laisse simplement pas la base de données jetable devenir discrètement celle de production. La migration de « expérience amusante » à « outil porteur » est exactement le moment où la décision d'architecture devient coûteuse à inverser.

La seule chose que j'éviterais, c'est le défaut dans lequel beaucoup de gens tombent sans décider : un relais cloud branché directement sur une base de données de production avec accès en écriture, parce que c'était le premier tutoriel et que ça a marché du premier coup. Cette combinaison est pratique et c'est celle que j'aurais le moins envie de faire tourner.

En résumé

Les serveurs MCP de base de données sont réellement utiles maintenant, et la question qui compte n'est pas s'il faut en utiliser un — c'est où vit la connexion. Les relais cloud t'achètent une mise en place nulle et le partage en équipe, et ils te le facturent en confiance : tes identifiants et tes résultats de requête passent par un tiers. Les serveurs distants auto-hébergés te donnent le contrôle de l'hôte au prix d'un service toujours actif avec une surface d'authentification exposée au réseau. Le MCP local garde les identifiants et la connexion à la base de données sur ta propre machine et abandonne en retour le partage facile en équipe.

Il n'y a pas de réponse unique et correcte, et je mentirais si je disais le contraire. Mais il y a un bon défaut : garde la connexion locale chaque fois que tu peux, mets un utilisateur en lecture seule ou un réplica devant tout ce qui compte, limite l'IA à la seule base de données dont elle a besoin, et souviens-toi que quoi que lise le modèle, il le sait désormais. Fais ces quatre choses et la question d'architecture se répondra en grande partie d'elle-même.

BaseVolt est ma vision de l'extrémité locale de tout ça — une appli de bureau qui se connecte directement à tes bases de données et fait tourner son propre serveur MCP sur localhost, pour que le client IA parle à un processus sur ta machine au lieu d'un relais. L'offre Hobby est gratuite à vie et couvre deux sources de données sans compte requis, et Pro est à 99 $/an pour des sources de données illimitées si tu la dépasses. Tu peux voir la tarification ou simplement l'essayer — il y a un essai de 14 jours sans carte bancaire, et la démo montre le workflow sans rien installer.

Si tu veux les étapes de mise en place plutôt que la comparaison, le tutoriel MCP local le parcourt de bout en bout.