Kelly MacLean, VP Engineering, Product & Science chez Amazon Ads, l’a annoncé sans lever la voix : 95 % des API d’Amazon Ads passent désormais par MCP. Derrière la formule technique, une bascule que vous sentez peut-être déjà venir. La régie publicitaire la plus verrouillée du marché ouvre ses portes à une IA que vous pouvez piloter vous-même, sans passer par une équipe technique. Vous, le métier, récupérez une main que vous n’aviez jamais tenue. Reste à savoir ce qui vient avec.
Le Model Context Protocol, c'est l'USB-C de l'IA : un branchement universel entre un modèle et n'importe quel outil. Avant, chaque connexion se codait à la main, à l'unité. Depuis, un seul standard ouvert, adopté par OpenAI et Google, confié à la Linux Foundation. On en a raconté toute l'histoire dans Un chat Claude pour les gouverner tous. Ici, on regarde l'envers du décor : ce que cette liberté coûte vraiment.
La couche d’intermédiaires s’effondre
Pendant vingt ans, faire dialoguer vos outils était un chantier technique. Pour que HubSpot parle à votre site, et que votre site parle à votre serveur, il fallait des développeurs, des intégrateurs, des connecteurs figés qu’on ne touchait plus une fois posés. Le métier formulait le besoin. Un autre tenait le clavier.
Le sachant décrivait la destination. Un autre conduisait la voiture.
MCP dissout cette couche. C’est un protocole ouvert qui permet à une IA de découvrir et d’actionner un outil en langage naturel, sans câblage sur mesure. Amazon vient d’y verser 95 % de sa surface d’API. Ce n’est pas un cas isolé, c’est le sens du courant.
Chez nous, ce n’est pas une projection. Notre studio pilote son HubSpot (CRM), son site et son serveur depuis un seul environnement Claude. Pas d’onglet à jongler, pas de ticket à l’IT pour croiser deux sources.
Un exemple concret, tiré de notre propre infrastructure. Nos noms de domaine vivent sur Netlify (hébergeur cloud), mais certaines instances se déploient chez un hébergeur pro distinct. Une fois les clés récupérées, tout se pilote depuis Claude : lecture d’un statut de déploiement, mise à jour d’un contenu, bascule d’une instance. Ce qui demandait un projet demande maintenant une phrase.
Un système, plusieurs agents
Le vrai levier n’est pas un agent unique qui ferait tout. C’est plusieurs agents spécialisés, chacun expert d’une plateforme, orchestrés depuis un même poste. Un agent qui connaît le schéma de votre CRM. Un autre qui gère les déploiements et lit les journaux du serveur. Un troisième qui produit et publie du contenu. Le métier ne pilote plus des outils, il pilote des intentions, et chaque agent les traduit dans son domaine.
Pourquoi découper plutôt que tout confier à un seul agent tout-puissant ? Pour trois raisons qui vont dans le même sens.
- La fiabilité. Un agent au périmètre étroit se trompe moins. Moins de contexte à tenir, des instructions plus nettes, un seul type de tâche à réussir.
- La sécurité. Un agent qui n’agit que sur une plateforme ne peut pas faire tomber les autres. Le découpage borne les dégâts.
- La lisibilité. Quand chaque agent a un rôle, on sait qui a fait quoi. L’audit devient possible, la correction aussi.
C’est le prolongement direct de piloter cinq IA sans devenir leur secrétaire. La difficulté n’est plus de faire tourner un agent, mais de faire tenir plusieurs agents ensemble sans qu’ils se marchent dessus. L’orchestration devient le métier. Le chef d’orchestre ne joue d’aucun instrument, mais sans lui, l’ensemble n’est que du bruit.
Cette architecture ne se contente pas de répartir le travail. Elle répartit aussi le pouvoir. Et un pouvoir réparti est un pouvoir qu’il faut gouverner, agent par agent, clé par clé. C’est exactement là que le vertige commence.
Spider-Man n’était pas un super-héros, c’était un avertissement
Souvenez-vous du début de l’histoire. Peter Parker se fait mordre, découvre ses pouvoirs, et sa toute première décision est une faute : il laisse filer un voleur, par confort, parce que ça ne le regardait pas. Ce voleur tuera son oncle. La leçon n’arrive pas avec le pouvoir. Elle arrive avec la première erreur.
Le métier qui branche MCP est dans la même scène. Le pouvoir est immédiat, réel, grisant. La faute, elle, attend son heure.
Piloter tout depuis un seul poste, c’est détenir le trousseau qui ouvre tous les coffres. HubSpot, le site, le serveur : une même clé, un même point d’entrée. La puissance est réelle. La surface d’attaque aussi. Une clé qui fuit, un accès mal réglé, et ce n’est pas un outil qui tombe, c’est le système entier.
Via Claude Code, en attaquant directement l'API de mon site (le CMS), j'ai demandé une mise à jour. Je pensais viser l'instance de développement. Claude a poussé en production, des modifications non validées, parce que ma consigne était ambiguë. La leçon n'est pas contre l'outil, elle est contre l'imprécision. Isolez toujours le dev de la prod, et donnez la lecture avant l'écriture.
Un grand pouvoir implique de grandes responsabilités. La phrase n’a jamais été aussi littérale. Reprendre la main sur son système, c’est hériter d’une compétence que le métier n’avait jamais eue à porter : la gouvernance de ses propres accès. Qui lit, qui écrit, qui garde la trace de qui a lu.
API ou MCP : la vraie différence
Techniquement, on peut être sceptique. Un serveur MCP est une surcouche : il s’héberge sur une URL, et il ne fait souvent qu’appeler une API par-dessous. L’API aussi vit derrière une URL. Alors pourquoi passer par le MCP plutôt que d’attaquer l’API directement ?
flowchart LR
A[Le métier] --> B[Claude]
B --> C[Serveur MCP]
C --> D[API de la plateforme]
D --> E[HubSpot, CMS, serveur]
La différence n’est pas dans la plomberie, elle est dans ce que chaque couche expose.
| API | MCP | |
|---|---|---|
| Pensé pour | Des développeurs | Un modèle et un métier |
| Ce que ça expose | Des endpoints bruts | Des outils décrits en langage naturel |
| Découverte | Une documentation à lire | Le modèle découvre les outils seul |
| Permissions | À gérer dans le code | Déclarées dans le serveur |
| Qui peut le tenir | Un dev | Un métier outillé |
Attaquer une API brute via Claude Code, c’est puissant, mais c’est reconstituer la dépendance technique qu’on voulait quitter : clés, endpoints, gestion des erreurs, aucune garde. Le MCP ajoute une couche qui décrit ses propres outils, déclare ses permissions, et cadre ce que l’IA peut faire. C’est la poignée qu’un métier peut réellement tenir. À une condition : que le serveur soit bien conçu. Tout n’est pas encore en MCP, et un mauvais serveur vaut moins qu’une bonne API.
Le vrai choix n’est plus quelle plateforme j’achète. C’est quelle surface je peux gouverner.
Gouverner ce qu’on vient d’ouvrir
Reprendre la main, c’est hériter de trois questions que la DSI portait seule : qui accède, à quoi exactement, et qu’est-ce qui casse si ça tourne mal. Elles n’ont plus de réponse technique toute faite. C’est au métier d’y répondre, maintenant.
La carte des accès
Le principe tient en deux mots : moindre privilège. On ne donne jamais plus que ce qui est nécessaire, et jamais avant que le besoin soit prouvé. Lire n’est pas écrire, écrire n’est pas supprimer. Chaque niveau est une porte, et chaque porte devrait rester fermée par défaut.
| Niveau d’accès | Ce que ça permet | Réglage par défaut |
|---|---|---|
| Lecture | Consulter la donnée, produire un livrable | Ouvert, mais tracé |
| Écriture | Créer ou modifier un enregistrement | Restreint, après validation |
| Suppression | Effacer, souvent irréversible | Fermé, confirmation humaine |
| Administration | Gérer les clés et les accès eux-mêmes | Une seule personne |
La traçabilité complète la carte. Savoir qui a lu la performance HubSpot, qui a modifié une fiche, quand et pourquoi, ce n’est pas de la bureaucratie. C’est ce qui transforme un incident en leçon plutôt qu’en mystère.
Le modèle de menace
Un système ouvert attire des risques précis. Trois méritent votre attention dès le premier jour.
- La clé qui fuit. Un seul secret ouvre parfois tout. Une clé par usage plutôt qu’une clé maître, une rotation régulière, et jamais en clair dans un fichier. Un secret vit dans un coffre, pas dans un dépôt de code.
- L’injection par la donnée. Une donnée que l’agent lit, un email, une fiche, un commentaire, peut contenir une instruction cachée qu’il exécutera comme si elle venait de vous. Ne donnez jamais le droit d’écrire à un agent qui lit des contenus que vous ne contrôlez pas.
- Le serveur MCP non audité. Un serveur tiers, c’est du code qui tient vos clés et parle à vos plateformes. N’installez que ce que vous pouvez auditer, ou ce qui vient de la plateforme officielle. Un mauvais serveur ne se contente pas d’être inutile, il devient une porte.
Aucune de ces menaces n’est exotique. Ce sont les règles qui protègent une entreprise depuis toujours, déplacées vers une main nouvelle : la vôtre.
Penser livrable, pas prouesse
L’erreur classique, c’est de se griser de la technique et d’oublier la finalité. Un système qui pilote tout ne vaut rien s’il ne retombe pas sur un résultat qu’on sait juger.
On ne réplique pas un dashboard. On réplique le résultat qu’il mesurait.
Notre méthode part toujours de ce qui marche déjà. J’ai un tableau de bord qui me dit combien de contacts j’ai générés en avril, combien d’opportunités, combien de chiffre d’affaires. L’objectif n’est pas de reconstruire le dashboard. C’est de reproduire ce chiffre connu, en m’affranchissant de l’outil, répliqué depuis le terminal Claude. Si le résultat retombe sur le nombre que je connais, le système est fiable. Sinon, il ment, et je le sais tout de suite.
Ce contrôle suppose de maîtriser le terrain avant d’y toucher. Sur HubSpot, ça veut dire connaître les champs réellement utilisés. Est-ce le champ pays ou le champ pays1 qui porte la donnée vivante ? Les deux existent, un seul compte. L’orchestration devient plus importante que la prouesse : sans cette maîtrise des livrables initiaux, l’IA produit un résultat plausible et faux, le pire des deux mondes. La question n’est jamais est-ce que ça tourne, mais comment je m’assure que mon livrable est bon. C’est le prolongement direct de la fin des livrables intermédiaires : ce qui compte, c’est le résultat final, vérifiable.
La mise en place, étape par étape
Voici le protocole qu’on applique, dans l’ordre. Aucune étape n’est optionnelle.
- Partir d’un résultat connu et mesuré. Le chiffre d’avril, un livrable validé, une cible vérifiable. On réplique ce qui existe avant d’inventer.
- Cartographier le terrain réel avant d’écrire une ligne. Quels champs sont vraiment utilisés, quels accès existent, quelles instances tournent. Le
payscontre lepays1. - Choisir la surface. API brute via Claude Code pour un usage personnel et ponctuel, serveur MCP hébergé dès que d’autres personnes toucheront cet accès.
- Isoler l’environnement. Instance de dev avant la prod, lecture seule avant l’écriture. Ne jamais donner les clés de la production à une première itération.
- Répliquer, puis comparer. Le résultat doit retomber sur le chiffre de référence. L’écart est votre juge.
- Ouvrir l’écriture seulement quand la lecture est fiable. L’IA qui lit bien peut commencer à écrire. Pas avant.
Avant de brancher quoi que ce soit, quatre questions valent mieux qu’un incident :
- API ou MCP, laquelle des deux surfaces je saurai gouverner ?
- Est-ce que je passe par Claude Code, ou par un serveur hébergé et partagé ?
- Est-ce que d’autres personnes utiliseront cet accès après moi ?
- Quels dégâts si ma consigne est mal formulée, et jusqu’où peuvent-ils aller ?
- MCP fait tomber la couche d'intermédiaires : le métier pilote son système multi-plateformes depuis un seul poste. Amazon Ads y a versé 95 % de ses API.
- Le vrai levier, ce n'est pas un agent qui fait tout, mais plusieurs agents spécialisés, chacun borné à sa plateforme, orchestrés depuis un même poste.
- Cette liberté a un prix : un seul trousseau ouvre tous les coffres. Moindre privilège, lecture avant écriture, traçabilité de qui accède à quoi.
- Trois menaces à traiter dès le premier jour : la clé qui fuit, l'injection par la donnée, le serveur MCP non audité.
- La méthode part toujours d'un résultat connu, qu'on réplique pour le vérifier, dev avant prod.
Peter Parker a mis un film entier à comprendre que ses pouvoirs ne valaient rien sans la main qui les tient. Le métier, lui, n’a pas ce luxe de temps. La main est déjà rendue, les coffres sont déjà ouverts. La seule question qui reste est celle de l’oncle Ben, et elle n’a jamais eu de réponse technique.
Le pouvoir a changé de mains. La responsabilité aussi.
