Guillaume Duvernay

J'ai arrêté d'utiliser MCP pour la majeure partie de mon travail

14 min de lecture

AI efficiencyagentsMCP

Cela fait quelques mois que j’évite MCP dès que j’ai le choix, pour utiliser autre chose. Le problème ne vient pas du protocole lui-même, mais de ce qu’il me coûte dans mon travail quotidien, qui consiste en beaucoup d’opérations répétitives sur un CRM, un CMS et quelques outils d’analyse.

Ceci est la version écrite d’une vidéo que j’ai publiée, avec les mêmes exemples.

Video: MCPs at Scale? Stop Wasting All Your Tokens!Play

Une configuration jamais uniforme selon les interfaces

Je passe de Claude Code à Codex ou Antigravity selon mes besoins. Chacun d’eux connecte les serveurs MCP à sa manière. Parfois, c’est un fichier de config JSON. Parfois, il faut trouver un plugin officiel, et quand il n’y en a pas, on ajoute un serveur personnalisé à la main.

Ainsi, chaque fois que j’ouvrais une session dans une interface différente, je n’étais jamais sûr que tout était connecté. Certains serveurs s’étaient déconnectés et nécessitaient une réauthentification. Je commençais le travail pour m’en rendre compte à mi-parcours.

Sur un forfait d’équipe, c’est pire. Dans Claude Code, seul l’administrateur peut ajouter des connecteurs personnalisés avant qu’ils ne soient disponibles pour tous, donc un collègue qui en a besoin doit attendre.

C’est une friction acceptable. Ce qui me coûte réellement se situe plus loin.

Les descriptions d’outils consomment des tokens avant même la première question

Lorsqu’un serveur MCP est connecté, il expose ses outils au client. Pour un CRM, il s’agit de fonctions comme lister les contacts, récupérer un contact, créer un contact ou modifier un contact. Chaque outil possède une description indiquant quand l’utiliser, ainsi que le schéma du payload attendu.

Tout cela reste dans la session. Connectez dix serveurs avec vingt outils chacun et vous transportez deux cents descriptions d’outils et leurs schémas dans chaque conversation, même celles où vous n’en utilisez que deux.

Le calcul de dix serveurs à vingt outils est illustratif et non la mesure d’une configuration précise. Cela montre la structure : un budget fixe, dont la majeure partie est consommée avant même que la conversation ne commence.
Chacune d’elles est chargée, que la session y fasse appel ou non. Les deux marquées sont celles appelées lors d’une session typique.

Les clients s’améliorent sur ce point. Claude Code peut révéler les outils progressivement au lieu de charger toutes les descriptions d’emblée, et d’autres approches permettent à l’agent de rechercher l’outil dont il a besoin. Je m’attends donc à ce que ce problème disparaisse de lui-même, c’est pourquoi ce n’est pas mon grief principal.

L’agent réécrit ce que vous possédez déjà

Imaginons que vous demandiez à votre agent de pousser deux cents contacts depuis un CSV vers votre CRM. Le fichier est là, sur votre ordinateur, correctement formaté.

L’agent doit tout de même écrire chaque appel d’outil lui-même, caractère par caractère : le nom de l’outil, puis le payload avec le nom du contact, l’email et tout le reste. Deux cents fois. Généralement sans parallélisme.

Les coûts ici représentent des structures plutôt que des mesures. La ligne centrale évolue avec la taille de votre fichier, contrairement aux autres.

Ce que je souhaiterais, c’est que l’agent analyse le CSV, détermine comment les en-têtes correspondent aux champs du CRM, puis déplace les données sans les lire intégralement. C’est une transformation, et la plupart des clients ne savent pas le faire, alors ils réécrivent tout.

C’est aussi peu fiable. Au-delà de quelques centaines d’enregistrements, un agent devient paresseux et n’en traite que la moitié, ou commet une petite erreur au milieu que vous découvrirez plus tard.

Sept minutes pour changer un seul chiffre

C’est ce point précis qui m’a poussé à arrêter MCP pour mes tâches répétitives.

Je gère un site web sur Webflow. Les articles sont dans une collection CMS, une ligne par article, et le corps est en rich text, que Webflow stocke en HTML inline. Un article typique fait deux mille mots.

J’ai demandé à l’agent de trouver un article et d’y modifier un chiffre, 70 en 80.

La recherche a été instantanée. Ensuite, le MCP de Webflow ne propose qu’un seul outil pour cela : modifier un élément CMS, où l’on transmet les champs à modifier ainsi que leurs nouvelles valeurs. Il n’y a pas de fonction “rechercher et remplacer” à l’intérieur d’un champ. Pour changer deux caractères, l’agent a donc relu tout le corps du texte, a ressaisi les deux mille mots avec le nouveau chiffre au milieu, et a renvoyé l’ensemble.

Les sept minutes et les 20% sont mes propres mesures sur une session ce jour-là, pour un seul article.

Une solution serait d’avoir des outils plus intelligents : un point de terminaison de recherche et remplacement sur un champ CMS. Cela aiderait, mais je ne peux pas l’imposer sur le serveur de quelqu’un d’autre.

L’autre solution ne demande la permission de personne. Récupérer l’article une fois, l’écrire dans un fichier local, le modifier là avec les outils dont l’interface est déjà performante, et le renvoyer.

La colonne centrale fait toute la différence. Modifier un fichier est l’une des meilleures capacités de ces interfaces, et aucune de ces modifications ne passe par le modèle.

L’impossibilité de limiter les données de retour

Un appel MCP renvoie toujours quelque chose, et tout ce qui est renvoyé devient partie intégrante de votre fenêtre de contexte.

Demandez vos vingt articles les plus récents pour obtenir leurs dates de publication, et à moins que le serveur ne propose un paramètre de sélection de champs, vous recevrez vingt articles complets. Corps inclus. Deux mille mots chacun, plus tous les autres champs de la collection.

Sauf si le serveur expose un paramètre dédié, le payload arrive entier et reste dans la fenêtre pour le reste de la session.

L’API était déjà là

Beaucoup de serveurs MCP ne sont que des enveloppes autour d’une API que l’entreprise possédait déjà.

Webflow, HubSpot et les autres disposent d’API REST documentées et publiques depuis des années. C’est sur elles que Zapier, Make, n8n et Softr ont construit leurs connecteurs. Lorsque ces entreprises ont lancé un serveur MCP, la plupart ont simplement mappé leurs points de terminaison existants dans le protocole. C’est donc une seconde interface pour les mêmes opérations.

Lorsqu’une plateforme maintient la parité entre son MCP et son API, l’interface choisie ne change pas les possibilités d’action.

Et votre agent peut appeler une API parfaitement. Dans une session Codex ou Claude Code, il écrit la requête et l’exécute depuis votre machine. La différence est qu’un appel API peut être intégré dans un script.

C’est cette nuance qui règle le problème de la ressaisie. L’agent analyse votre CSV, définit le mappage une seule fois, écrit un script qui boucle sur les lignes en effectuant un appel pour chacune, puis l’exécute. À partir de là, le modèle n’est plus dans la boucle. Le script tourne jusqu’à la fin.

Écrire une compétence, pas une liste d’outils

Une API n’est pas explicite par nature, et c’est précisément ce que MCP vous apporte. Dites à un agent d‘“utiliser l’API HubSpot” et il devinera en fonction de ses souvenirs. C’est généralement proche, mais rarement exact.

Mais les API sont documentées, souvent avec une spécification OpenAPI que vous pouvez indiquer ou laisser l’agent trouver. Et pour tout ce que vous faites plus d’une fois, vous le consignez par écrit.

# Compétence : CSV vers contacts CRM

Nous n’utilisons jamais le MCP du CRM. Tout passe par l’API REST.

## Points de terminaison utilisés
- `POST /crm/v3/objects/contacts` pour un contact
- `POST /crm/v3/objects/contacts/batch/create` jusqu’à 100 par appel
- Référence complète : https://developers.hubspot.com/docs/api/crm/contacts

## Authentification
La clé se trouve dans le fichier `.env` à la racine du repo sous `CRM_KEY`. À lire via
`source .env` dans le script. Ne jamais l’afficher, ne jamais la coller dans un
message.

## Mappage
Inspecter d’abord les en-têtes du CSV, puis mapper vers les champs du CRM. Demander
avant de deviner pour tout ce qui n’est pas une correspondance évidente.

Une fois ce fichier créé, l’agent sait comment vous communiquez avec votre CRM, quels points de terminaison vous utilisez et comment vous authentifier. Il arrête de deviner, et vous obtenez la même fiabilité que celle offerte par MCP.

Les CLI fonctionnent de la même manière et sont souvent préférables. Les agents maîtrisent les commandes de terminal, la plupart des CLI se documentent via l’aide, et beaucoup gèrent l’OAuth pour vous : vous vous connectez une fois dans le navigateur et le token reste sur votre machine. Sous le capot, c’est généralement encore la même API.

La clé reste dans le fichier

C’est le seul point où les API demandent plus de travail que MCP. La plupart des serveurs MCP utilisent désormais OAuth : on clique sur une page de connexion et c’est fini. Avec une API, on manipule généralement une clé.

Je garde un fichier .env à la racine du dossier où l’agent travaille, et je précise à l’agent que la clé s’y trouve et comment l’utiliser : via une commande qui l’injecte dans le script, et jamais en l’affichant dans la conversation. L’agent sait que la clé existe et où elle se trouve, sans jamais en voir la valeur.

Enchaîner comme on le fait déjà dans le terminal

Une fois que les appels sont dans des scripts, vous pouvez les mettre bout à bout, et le modèle ne voit que le résultat final.

Prenons une tâche régulière : trouver les trois articles que je n’ai pas touchés depuis le plus longtemps, récupérer leurs performances et décider lesquels réécrire.

Via MCP, chaque réponse intermédiaire aurait atterri dans la fenêtre de contexte. Ici, les trois premières étapes n’atteignent jamais le modèle.

L’agent reçoit un rapport court et structuré et fait ce pour quoi il est réellement doué : l’analyser et me dire quoi corriger. Il n’a jamais vu les vingt articles qu’il a dû trier.

Personne n’a besoin d’une clé API sur son ordinateur

L’objection évidente : nous sommes dix personnes dans l’équipe marketing, tout le monde doit-il garder des clés API sur sa machine ?

Non. Ce que nous avons construit chez Softr est un proxy. Chaque personne possède sa propre clé personnelle. Elle appelle le proxy avec celle-ci, le proxy l’identifie et route la requête vers le bon service en utilisant la clé du service qu’il détient.

La couche de permissions est l’élément que nous ne pouvions pas construire auparavant. Une clé brute possède les mêmes droits pour tous ceux qui la détiennent.

Les permissions sont l’aspect qui m’importe le plus. Une clé API est définie lors de sa création, et ensuite, tout détenteur peut effectuer les mêmes actions. Via le proxy, nous filtrons les opérations : notre clé Webflow peut être en lecture seule pour la majorité de l’équipe, tout en permettant à un content manager de créer et modifier. Personne ne peut supprimer un article par accident, et personne n’a rien eu à installer.

Quand MCP reste le bon outil

Je ne plaide pas contre MCP. Pour un travail ponctuel, c’est l’outil le plus rapide, et je continue de l’utiliser.

Il ne s’agit pas de choisir l’un pour tout. Le coût de MCP apparaît avec le volume et la répétition, c’est donc là qu’il vaut la peine d’être remplacé.

Le moment d’envisager ce changement est quand une partie réelle de votre travail passe par un agent communiquant avec vos outils. Avant cela, la configuration représente la majeure partie de l’effort, et MCP l’emporte.

Passé ce stade, cela mérite une après-midi de travail. Demandez à votre agent quels points de terminaison vos outils exposent, rédigez la compétence avec lui, et testez l’une de vos tâches récurrentes des deux manières. La différence sera immédiate sur tout ce qui implique du volume.

Sources