--- title: "J'ai arrêté d'utiliser MCP pour la majeure partie de mon travail" description: "MCP est idéal pour des tâches ponctuelles. Pour tout volume important, c'est lent, cela consomme trop de tokens et force mon agent à ressaisir des données. Voici mes alternatives: des appels API directs via scripts, une compétence pour les documenter et un proxy pour sécuriser les clés." date: 2026-09-16 language: fr canonical: https://gduv.club/fr/articles/mcp-vs-direct-apis source: gduv.club --- 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. [MCPs at Scale? Stop Wasting All Your Tokens!](https://www.youtube.com/watch?v=LGaqFVPUpfA) ## 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._ **Deux cents descriptions d’outils représentées par deux cents petites étiquettes, dont deux sont utilisées.**
{Array.from({ length: 60 }, (_, index) => ( {index === 17 ? 'create_contact' : index === 41 ? 'update_item' : 'tool'} ))} et 140 de plus
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. | Step | What happens | Cost | | :--- | :--- | ---: | | Lire le CSV | Le fichier est déjà sur le disque | peu coûteux | | Écrire un appel d'outil par ligne | Le modèle saisit chaque champ de chaque payload | ×200 | | Attendre le retour de chaque appel | L'un après l'autre | ×200 | | **Données devant être saisies par le modèle** | | **la totalité** | _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. | Step | What happens | Cost | | :--- | :--- | ---: | | Trouver l'article | Une recherche dans la collection | quelques tokens | | Lire l'élément CMS | Le champ rich text complet est renvoyé | ~2 000 mots | | Réécrire tout le champ | Chaque caractère, pour en changer deux | ~2 000 mots | | Envoyer la mise à jour | Edit item est le seul outil disponible | 1 appel | | **Coût total** | | **~7 min, 20% de ma limite** | _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. **Les mêmes deux mille mots transitent trois fois par le modèle pour changer deux caractères ; via un script, ils ne transitent qu’une fois et le modèle n’écrit que le remplacement.**
Via l’appel d’outil MCP
Lire l’élément 2 000 mots entrants
Le modèle tout ressaisit
2 000 mots
Renvoyer l’élément 2 000 mots sortants
Via un script sur l’API
Extraire vers un fichier local Une fois, et le modèle ne le lit jamais
Rechercher et remplacer
2 caractères
Pousser le fichier Aucune ressaisie
## 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. **Ce que j'ai demandé** (Un champ, vingt lignes) - Vingt dates de publication **Ce qui est entré dans le contexte** (La réponse complète) - Vingt corps d'articles - Tous les autres champs de la collection - La totalité, à chaque tour suivant _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. **Interfaces** - Un serveur MCP - Un CLI - Un script sur votre ordinateur **L’API REST de la plateforme** - Documentée depuis des années - Généralement une spécification OpenAPI - Ce que les connecteurs low-code utilisent déjà **Les mêmes opérations** - Lister les contacts - Créer un contact - Modifier un élément CMS _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. ```markdown # 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. **Il existe des configurations plus optimisées que la mienne** Certains passent par 1Password pour que la clé ne touche jamais un fichier, tout en permettant à l’agent de s’authentifier. Je n’ai pas mis cela en place, donc je ne peux pas témoigner de l’usage pratique. J’utilise concrètement un `.env` ignoré par git et lu par un script. ## 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. 1. **Trouver les candidats**. Trier le CMS par dernière modif, prendre les trois premiers 2. **Récupérer le contenu**. Uniquement pour ces trois-là 3. **Récupérer les performances**. Search Console pour ces URLs 4. **Transmettre un rapport**. La seule chose que le modèle lit _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. **L'équipe** - Une clé personnelle chacun - Aucune clé de service locale - Rien à configurer par interface **Le proxy** - Identifie le collaborateur via sa clé - Centralise les clés de service - Autorise uniquement les opérations sur liste blanche - Permissions différentes par personne **Les services** - Le CRM - Analytics - Le CMS du site web _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. **Choisir MCP** (Ponctuel) - Trouver un élément et le modifier - Explorer un outil rarement utilisé - Tout ce dont le coût principal est le temps de configuration **Choisir un script sur l'API** (Répétitif ou volumineux) - Centaines d'enregistrements d'un coup - Une tâche exécutée chaque semaine - Tout ce qui forcerait la ressaisie d'un payload _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 - [Model Context Protocol: tools specification](https://modelcontextprotocol.io/specification/2025-06-18/server/tools) - [Webflow: CMS items API](https://developers.webflow.com/data/reference/cms/collection-items/staged-items/create-item) - [HubSpot: contacts API](https://developers.hubspot.com/docs/api/crm/contacts) - [Anthropic: Claude Code settings and MCP configuration](https://docs.claude.com/en/docs/claude-code/mcp)