MCP revient souvent depuis quelques mois. Dans un thread, dans une vidéo, peut-être dans la bouche d'un collègue qui lâche "ah ouais, faut que tu testes avec MCP". Un hochement de tête poli, et la question qu'on n'ose pas poser.
Facile de classer ça parmi les acronymes des gens qui font de l'IA, un truc à côté du sujet quand on code en React, en Symfony ou en Python. On a déjà assez à faire sans courir derrière chaque nouveauté annoncée en grande pompe qui disparaît trois mois plus tard.
Sauf que MCP a pris une autre trajectoire. En dix-huit mois, c'est devenu le standard que l'industrie utilise pour connecter les IA à des outils: 97 millions de téléchargements mensuels des SDK, plus de 10 000 serveurs actifs, une adoption par Anthropic, OpenAI, Microsoft et Google. Le protocole a même quitté le giron d'Anthropic pour passer sous la Linux Foundation. À ce stade, ça devient une compétence de base plutôt qu'un sujet exotique.
Cet article explique ce que MCP fait, pourquoi ça simplifie la vie d'un développeur même sans projet IA, et comment t'y mettre sans y consacrer un mois.
Le problème : connecter une IA à un outil, c'était du bricolage
Imagine la situation suivante. Tu veux qu'un assistant IA puisse lire tes fichiers Google Drive, regarder tes tickets Jira, et créer une issue sur GitHub à partir d'un email reçu. Trois outils, trois API différentes, trois systèmes d'authentification.
Avant MCP, il fallait écrire un connecteur sur mesure pour chaque combinaison "outil IA / outil métier". Tu utilises Claude ? Tu écris un connecteur pour Google Drive, un pour Jira, un pour GitHub. Tu changes pour ChatGPT ? Tu réécris tout, parce que l'API d'OpenAI n'attend pas les choses de la même manière. Tu passes à Gemini ? Rebelote.
Les ingénieurs ont un nom pour ce genre de situation : le problème N x M. Si tu as N applications IA et M outils, tu te retrouves avec N x M intégrations à maintenir. Cinq IA et vingt outils, ça fait cent connecteurs. Personne ne peut suivre.
Tu en as vécu une version, à moindre échelle, dès que tu as voulu brancher trois services entre eux dans une appli : chaque webhook avec sa propre forme, chaque API avec ses propres règles, et toi qui passes tes journées à écrire de la glue.
Le principe : MCP, c'est l'USB-C des outils IA
L'image revient partout, et elle est juste. Avant l'USB-C, tu avais un câble pour ton téléphone, un autre pour ton appareil photo, un autre pour ta tablette, un autre pour ton ordinateur portable. Aujourd'hui, un seul câble branche tout. Tu n'as plus besoin de connaître les détails internes de chaque appareil pour qu'il fonctionne avec un autre.
MCP fait pareil pour les IA. Le protocole définit une manière standard de décrire trois choses :
- Les outils, c'est-à-dire les actions que l'IA peut déclencher : envoyer un email, créer un ticket, faire un commit.
- Les ressources, c'est-à-dire les données que l'IA peut lire : un fichier, le contenu d'une base, l'historique d'un projet.
- Les prompts, c'est-à-dire des modèles de conversation préparés à l'avance que l'application peut proposer.
Du côté technique, c'est du JSON-RPC 2.0, un format de message éprouvé depuis vingt ans. Pas d'invention bizarre, pas de nouvelle technologie à apprendre. Si tu sais lire un appel API REST, tu sais lire un message MCP.
L'architecture tient en trois rôles. Un hôte (Claude Desktop, Cursor, VS Code, ChatGPT) qui contient l'IA. Un client intégré à l'hôte qui sait parler MCP. Un serveur que tu écris (ou que quelqu'un a déjà écrit) qui expose tes outils ou tes données. Le client et le serveur communiquent, l'IA reçoit ce dont elle a besoin pour agir.
Exemples : à quoi ça ressemble dans ta vie de dev
Ton assistant lit tes fichiers locaux pour t'aider
Tu travailles sur un projet Symfony. Tu installes le serveur MCP filesystem dans Claude Desktop, tu pointes ton dossier de projet, et tu peux demander à l'IA "regarde mon entité User et propose-moi un Repository qui suit les conventions du projet". L'IA lit ton code directement, pas une description vague.
Avant MCP, tu copiais-collais ton fichier dans la conversation. Maintenant, l'IA peut naviguer dans ton projet comme tu le ferais, à condition que tu l'autorises explicitement.
Ton IDE parle à ta base de données
Tu installes le serveur MCP Postgres. Tu poses la question "donne-moi un exemple de requête qui retourne les commandes des dix derniers jours pour les utilisateurs premium". L'IA inspecte le schéma réel de ta base, génère une requête qui correspond aux vraies colonnes, et te dit si elle a un doute.
Plus de devinettes sur les noms de colonnes, plus de "regarde ton schéma et adapte". L'IA voit le schéma directement.
Tes outils habituels deviennent disponibles dans la conversation
Des serveurs MCP existent déjà pour GitHub, GitLab, Slack, Linear, Notion, Sentry, Google Drive, Figma, et des centaines d'autres. Tu en installes un, tu autorises les actions que tu veux permettre, et l'IA peut les utiliser pour toi.
Tu peux dire "crée une issue GitHub sur le repo lapolaris-frontend avec ce titre et cette description" sans quitter ta conversation, sans ouvrir d'onglet, sans copier-coller un identifiant.
Écrire ton propre serveur MCP, c'est du Python ou du TypeScript classique
Voici à quoi ressemble un serveur MCP minimal en Python qui expose une fonction de calcul de TVA :
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("Calculateur TVA")
@mcp.tool()
def calcule_ttc(prix_ht: float, taux_tva: float) -> float:
"""Calcule un prix TTC a partir du HT et du taux de TVA."""
if prix_ht < 0:
raise ValueError("Le prix HT ne peut pas etre negatif")
return round(prix_ht * (1 + taux_tva), 2)
if __name__ == "__main__":
mcp.run()C'est tout. Trois imports, un décorateur, une fonction documentée. Une IA compatible MCP qui se connecte à ce serveur voit immédiatement la fonction, sait comment l'appeler, et peut l'utiliser. Pas de schéma JSON à écrire à la main, pas de routage HTTP, pas d'authentification à câbler pour démarrer.
Pourquoi ça te concerne même si tu ne fais pas d'IA
C'est la question qui doit te trotter dans la tête. Tu n'écris pas d'agents, tu ne fais pas de chatbot, tu fais du web ou du backend classique. Réponse en quatre points.
Ton workflow personnel va y passer. En 2026, écrire du code avec un assistant n'est plus une option exotique, c'est la norme. Cet assistant n'est utile que s'il accède à ton vrai contexte : ton repo, ta base, tes tickets. MCP est ce qui rend cet accès possible et sécurisé. Ignorer MCP, c'est se condamner à utiliser une IA aveugle.
Les services que tu construis vont devoir être MCP-ready. Si tu fais du SaaS, du B2B, ou même une plateforme interne dans une grande entreprise, tes utilisateurs vont attendre de pouvoir interagir avec ton produit via leur IA. Forrester estime que 30% des éditeurs SaaS lanceront leur propre serveur MCP en 2026. Si ton produit n'est pas accessible aux agents IA dans deux ans, il devient invisible.
Tu vas en croiser dans les offres d'emploi. Les mentions "expérience avec MCP" ou "connaissance des protocoles d'intégration LLM" sont déjà fréquentes côté tech lead et senior. Ça arrive aussi vite chez les juniors qu'on cherche à former. Avoir touché à MCP, même brièvement, fait la différence en entretien.
Le pattern est transférable. Comprendre comment MCP résout le problème N x M, c'est comprendre comment toute l'industrie standardise les intégrations. Le même raisonnement structure les API REST, les webhooks, les event buses. Apprendre MCP, c'est aussi se mettre à jour sur un mode de pensée architectural moderne.
Pièges classiques à éviter
Confondre MCP avec function calling
Le function calling, c'est la capacité d'un modèle (côté API OpenAI ou Anthropic) à émettre un appel de fonction structuré dans sa réponse. C'est une couche basse, propre à chaque fournisseur de modèle.
MCP est une couche au-dessus, qui standardise la manière dont les outils sont décrits, découverts et appelés, indépendamment du modèle. Les deux travaillent ensemble, mais ce ne sont pas la même chose. Un projet bien fait utilise les deux.
Ouvrir trop de portes
Un serveur MCP qui expose toute la surface de ton API à une IA, c'est aussi un serveur qui peut être manipulé par une instruction malveillante glissée dans un fichier que l'IA va lire. Les attaques par injection de prompt à travers MCP sont documentées depuis 2025.
Règle simple : tu n'exposes que ce dont tu as réellement besoin, tu valides toutes les entrées comme si elles venaient d'un utilisateur hostile, et tu refuses par défaut tout ce qui n'est pas explicitement autorisé. C'est exactement la logique de Fail Fast appliquée à la sécurité.
Croire que MCP remplace tes API
MCP ne remplace pas une API REST ou GraphQL. C'est une couche au-dessus qui expose ton API à des IA. Tes utilisateurs humains, tes intégrations classiques, tes mobiles, continuent de passer par les canaux habituels.
Quand tu écris un serveur MCP pour ton produit, tu fais essentiellement le mapping entre tes endpoints existants et la grammaire MCP. Tu ne réinventes pas ton backend.
Sous-estimer la gestion des permissions
Une IA branchée à un serveur MCP qui a tous les droits, c'est une IA qui peut supprimer une base de prod sur la base d'un malentendu. Les hôtes MCP sérieux demandent une confirmation utilisateur avant chaque action sensible, mais ce comportement dépend de ta configuration.
Tu réfléchis au principe du moindre privilège dès le départ. Lecture seule sur ce que tu peux, écriture limitée à un périmètre précis sur le reste. Tu ne donnes jamais à un agent IA des droits que tu ne donnerais pas à un junior qui débarque dans l'équipe.
Vouloir tout installer en même temps
Les hôtes MCP peuvent se connecter à des dizaines de serveurs simultanément. Le piège, c'est que chaque serveur ajoute sa liste d'outils au contexte de l'IA, ce qui finit par la noyer et par coûter cher en tokens.
Tu actives les serveurs en fonction du contexte de ton travail. Sur un projet Symfony, tu n'as pas besoin du serveur Figma actif en permanence. La discipline ici, c'est la même que pour les extensions de ton IDE : moins mais mieux.
Par où commencer cette semaine
Tu n'as pas besoin d'un plan d'attaque sur trois mois. Tu peux toucher à MCP en une après-midi.
Premier pas : installe Claude Desktop ou un IDE compatible (VS Code avec Copilot, Cursor, Zed). Active un serveur MCP officiel, par exemple le serveur filesystem. Pointe-le sur un de tes projets. Pose des questions sur ton code et observe ce que l'IA fait.
Deuxième pas : connecte un service que tu utilises tous les jours. GitHub, Slack, Notion. Regarde ce qui change dans ton flux de travail quand l'IA peut agir sur ces outils sans que tu changes de fenêtre.
Troisième pas, optionnel mais formateur : écris ton propre serveur MCP, même tout petit. Une fonction qui expose une recherche dans un fichier CSV, un outil qui retourne la météo, ce que tu veux. L'objectif n'est pas l'utilité, c'est de comprendre le protocole de l'intérieur. Une fois que tu as fait ça, MCP cesse d'être un mot mystérieux.
Pour aller plus loin
Si tu veux comprendre le contexte plus large des agents IA et de leur arrivée en entreprise, l'article sur les agents IA en 2026 donne la perspective globale. Et pour passer à la pratique, le décryptage du dossier .claude montre comment MCP s'intègre dans un projet de dev assisté par IA.
Côté formation, si tu veux bâtir des applications qui exploitent les LLM avec une vraie compréhension des protocoles d'intégration, la formation Création d'une application IA avec Python et l'API OpenAI couvre les bases que MCP suppose acquises. Pour le travail sur les prompts et la conception d'agents, la formation Prompt Engineering API LLM donne le cadre dans lequel MCP devient pleinement utile.
