Configuration du projet

La théorie MCP est en place ; cette section la met en pratique sur un projet complet. Nous allons construire un chatbot en ligne de commande (CLI) pour comprendre comment les clients et serveurs MCP fonctionnent ensemble — un projet assez compact pour rester lisible, assez réaliste pour exercer chaque primitive du protocole : outils, ressources et prompts y trouveront tous leur rôle.

Ce que nous construisons

Le chatbot sera une interface en ligne de commande permettant de discuter avec un ensemble de documents :

• Interface CLI de chat
• Capacités de lecture et d’édition de documents pour Claude
• Fonctionnalité de « mention » de documents avec la syntaxe @nom_doc
• Exécution de commandes avec la syntaxe /nom_commande
• Collection de faux documents stockés en mémoire

Si les syntaxes @ et / vous rappellent Slack, Notion ou Claude Code, c’est voulu : ce sont les conventions d’interface que les utilisateurs connaissent déjà — et vous verrez qu’elles correspondent exactement à deux primitives MCP. La mention @ s’appuiera sur les ressources, les commandes / sur les prompts ; quant aux demandes en langage naturel (« corrige la faute dans le rapport »), elles passeront par les outils.

Architecture du système

Le projet se compose de trois composants principaux :

1. Notre client MCP : gère l’interaction utilisateur et l’interface de chat
2. Notre serveur MCP : fournit les outils pour les opérations sur les documents
3. Stockage de documents : collection en mémoire de divers types de fichiers

Le serveur MCP implémentera deux outils de base — un outil pour lire le contenu d’un document, un outil pour mettre à jour le contenu d’un document. Ce duo lecture/écriture suffit à couvrir l’essentiel des interactions documentaires, et il servira de modèle : tout outil supplémentaire suivrait exactement le même chemin de fabrication.

Tous les documents (PDF, tableurs, fichiers texte, fichiers Markdown) seront stockés en mémoire plutôt que sur disque, gardant le projet simple et centré sur les concepts MCP. C’est un choix pédagogique à portée pratique : dans un serveur réel, remplacer ce dictionnaire en mémoire par un accès à votre système de fichiers, votre CMS ou votre base documentaire ne changerait rien au protocole — clients et Claude verraient les mêmes outils, les mêmes ressources.

Note importante sur l’architecture

Un point à clarifier avant d’écrire du code, car il détermine ce que vous réutiliserez de cette section : dans les projets réels, vous implémentez généralement soit un client MCP, soit un serveur MCP — pas les deux. Deux profils types :

• Construire un serveur MCP pour distribuer un service à d’autres développeurs
• Construire un client MCP qui se connecte à des serveurs MCP tiers existants

Si votre équipe possède des données ou des API à exposer aux applications IA — la vôtre ou celles du marché, comme Claude Desktop —, vous écrirez un serveur, et les clients existants s’y connecteront. Si vous développez votre propre application de chat, vous écrirez un client, et vous brancherez les serveurs de l’écosystème. Notre projet implémente les deux composants dans une seule base de code uniquement à des fins pédagogiques : voir les deux extrémités du câble est la façon la plus rapide de comprendre ce qui y circule — après quoi vous ne garderez que l’extrémité dont votre projet a besoin.

Points clés à retenir

• Projet fil rouge : un chatbot CLI qui lit, édite et mentionne des documents via MCP
• Les conventions d’interface mappent les primitives : @mention → ressources, /commande → prompts, langage naturel → outils
• Trois composants : client (interaction), serveur (outils documentaires), stockage en mémoire
• Le stockage en mémoire est interchangeable — le protocole ne verrait aucune différence avec une vraie base
• En production, on écrit un client ou un serveur ; les deux ici, pour voir les deux faces du protocole