MCP : des machines qui se parlent en français

J’ai passé un peu de temps à creuser ce qu’est MCP, le Model Context Protocol. Et plus j’ai poussé, plus j’en suis arrivé à y trouver une réelle ironie.

MCP, c’est le standard qui permet à une IA d’utiliser des outils : chercher dans Notion, lire un ticket Jira, créer une page. Les échanges se font en JSON, en langage machine pur. Mais ce qui décide quel outil appeler, et quand, c’est une description en langage naturel. Une phrase, lue par un modèle.

En gros, on avait des machines qui savaient très bien se parler entre elles (c’est le principe même d’une API), dans leur propre langage, pas forcément compréhensible par un humain, mais optimisé, efficace. Et puis on a mis au milieu un traducteur qui passe par le français (ou l’anglais), en “langage naturel”. On a appris à une machine à parler notre langue, pour qu’elle puisse discuter avec une autre machine. Les deux font donc des efforts supplémentaires, avec les distorsions potentielles.

Il y a de quoi sourire.

On nous avait pourtant appris l’inverse

Pendant une vingtaine d’années, on a appris aux humains à parler comme des machines. Je me rappelle des cours qui m’amusaient par leur trivialité au regard de mes études, mais qui étaient essentiels pour une bonne recherche Google : pas de phrases, pas d’articles, pas de « s’il vous plaît ». Choisir les bons mots-clés. Éventuellement utiliser des guillemets pour une expression exacte, et un signe moins pour exclure un terme.

Celui qui tapait « Quelle est la meilleure façon de faire une recherche sur Internet ? » passait pour un débutant. Celui qui tapait recherche avancée google opérateurs savait y faire.

Aujourd’hui, c’est l’inverse. On encourage les gens à écrire des phrases complètes, avec du contexte, pour qu’une IA les transforme… en mots-clés. Qu’elle enverra à un moteur de recherche.

La boucle est bouclée. Elle consomme juste beaucoup plus d’énergie qu’avant.

MCP résout de vrais problèmes. Pas tous.

Soyons justes : MCP n’est pas un gadget. Avant lui, chaque application d’IA devait écrire sa propre intégration pour chaque service. Dix IA pour cent services, ça faisait mille intégrations. Avec un standard, on passe à dix (clients) plus cent (serveurs).

La norme a aussi beaucoup mûri. L’authentification, longtemps le point noir, est aujourd’hui propre : l’utilisateur se connecte chez le service, l’IA reçoit un jeton limité, personne ne manipule de mot de passe. Depuis juillet 2026, le protocole est sans état et se déploie comme n’importe quel service web. Et une entreprise peut décider à un seul endroit quelle IA accède à quel outil.

Mais plusieurs problèmes restent entiers :

• La sécurité: La spécification le dit elle-même : MCP ne peut pas imposer ses principes de sécurité. Une description d’outil peut cacher des instructions que l’IA suivra. Tout repose sur les clients, les passerelles et la prudence des utilisateurs.
• Le déterminisme: MCP garantit la forme d’une requête, pas son fond. Le modèle choisit l’outil et les valeurs. Une requête peut être parfaitement formée et complètement à côté de la plaque.
• Le coût en contexte: Chaque outil branché envoie sa description au modèle avant même la première question.

Et il y a l’énergie. Selon l’Agence internationale de l’énergie, les data centers ont consommé 415 TWh en 2024, environ 1,5 % de l’électricité mondiale, et devraient dépasser 945 TWh en 2030. L’IA en est le premier moteur.

Google annonce 0,24 Wh pour une requête Gemini médiane. C’est peu. Mais c’est une requête texte simple. Un agent qui passe par MCP lit les descriptions d’outils, enchaîne les appels, relit les résultats, recommence parfois. Dans l’exemple publié par Anthropic, une tâche mal outillée consomme 150 000 tokens là où 2 000 suffisent. Grosso modo, l’énergie suit le volume de calcul. Faire passer par un modèle ce qu’un programme ferait seul, c’est payer ce volume à chaque fois.

Le code mode, ou l’art de ne demander qu’une fois

Il existe une piste que je trouve sous-estimée : le « code mode », poussé par Anthropic et Cloudflare. Au lieu d’appeler les outils un par un et de faire transiter toutes les données par le modèle, on lui demande d’écrire un script qui fait le travail. C’est l’exemple cité plus haut : 150 000 tokens ramenés à 2 000, soit 98,7 % d’économie.

Mais le vrai intérêt est ailleurs, à mon sens. Un script, c’est du code déterministe. Si la tâche revient, on peut le relire, le valider, le figer et le rejouer. Sans IA. Sans tokens. Pour toujours.

Pourquoi si peu de gens le font ? Parce qu’il est tellement plus simple de redemander à l’IA. Chaque fois. Comme on rappellerait un consultant pour refaire le même calcul, au lieu de lui demander de nous laisser le tableur.

(Pour être honnête : faire tourner du code généré par une IA demande un environnement isolé et surveillé. Anthropic le reconnaît lui-même. Et un script figé ne se paie pas qu’une fois. Comme je l’écrivais dans L’IA ne tuera pas le SaaS, ce n’est jamais juste construire, c’est aussi entretenir et faire évoluer. Le jour où l’API derrière change, il faut reprendre le script. Mais il y a de grandes chances que ce coût de maintenance reste sans commune mesure avec celui de tokens consommés à chaque exécution.)

Ma règle, en une phrase : le modèle pour l’imprévu, le code pour le connu.

La recherche n’a pas besoin d’un interprète

Le code mode règle le cas des tâches complexes et répétitives. Mais il reste une grande masse d’usages bien plus simples. L’utilisateur veut juste retrouver quelque chose.

Prenons la recherche, sans doute l’outil MCP le plus classique. « Retrouve mes notes sur le budget 2027. » Pour répondre, le modèle lit les descriptions des outils, reformule la demande en mots-clés (tiens, tiens), appelle la recherche, lit les résultats, et relance parfois avec d’autres mots. Une barre de recherche avec quelques filtres aurait fait la même chose en une requête. Déterministe, instantanée, quasi gratuite. Et l’utilisateur aurait vu les résultats, pas un résumé des résultats.

Je n’ai pas trouvé de statistiques fiables sur les usages réels de MCP. Ce que je vois, c’est que beaucoup de serveurs exposent surtout des actions triviales : chercher, lire, lister. Quand c’est l’IA qui cherche pour son propre travail (une IA de développement qui fouille la documentation pour écrire du code, par exemple), c’est parfaitement justifié. Quand on met une IA entre un humain et sa barre de recherche, beaucoup moins (que dire de l’aperçu IA de Google, d’ailleurs…).

L’IA montre sa vraie valeur à l’étape d’après. Croiser une page Notion, un fil Slack et un ticket Jira. Synthétiser vingt documents. Répondre à « qu’avait-on décidé, et pourquoi ? ». Et cette étape vient vite, souvent juste après la recherche.

D’où un schéma qui me semble plus sain :

1. un outil de recherche classique, avec de bons filtres, pour obtenir les bons résultats ;
2. l’IA, ensuite, sur ce périmètre choisi, pour synthétiser.

Plus efficace, moins coûteux, et l’humain garde la main sur ce que l’IA va lire.

Une question avant de brancher une IA

MCP est une bonne plomberie. Il supprime un vrai travail d’intégration et donne aux entreprises un point de contrôle unique. Mais il n’apporte ni intelligence, ni fiabilité, ni sobriété par lui-même.

Avant de faire passer une demande par une IA, la question à se poser est simple : est-ce que cette demande a besoin d’être interprétée ? Si oui, MCP est un excellent outil. Si non, une machine qui parle à une machine fera mieux, plus vite, et pour beaucoup moins cher. Et on n’a pas besoin de lui apprendre le français.

Recourir à l’IA à tout bout de champ, c’est céder à une facilité qu’on retrouve partout aujourd’hui. C’est le même réflexe qui nous fait commander sur Amazon, livré demain sans bouger de chez soi, plutôt que d’aller en boutique, quitte à attendre que le commerçant reçoive la commande. C’est pratique. Ce n’est pas pour autant la bonne réponse à chaque besoin. Parfois, on peut éviter d’utiliser une enclume pour écraser la mouche.

Pour ceux qui veulent aller plus loin, j’ai résumé tout ça dans une page dédiée : qui fait quoi dans MCP (service, développeur, utilisateur, DSI), comment fonctionne l’authentification, et les pièges classiques avec leurs pistes de résolution : MCP, qui fait quoi.

Image de une : photo de Dana Ward sur Unsplash