Amir Mousavi

Que peuvent faire les agents IA dans votre pile marketing ?

IA dans les opérations marketingPar Amir Mousavi

« Marketing agentique » figure sur toutes les présentations martech de ce trimestre, et « connexion en un clic » arrive deux diapositives plus loin. Aucune des deux ne dit ce que ce clic accorde.

Je suis donc allé chercher la réponse là où elle vit vraiment, c’est-à-dire dans le serveur d’autorisation plutôt que dans la présentation. Une commande contre celui de HubSpot, comme on vérifie un enregistrement DNS avant de croire à un plan de migration.

curl https://mcp.hubspot.com/.well-known/oauth-authorization-server

La réponse ne contenait aucun registration_endpoint, aucun client_id_metadata_document_supported, et "scopes_supported": []. Autrement dit : un agent ne peut pas s’enregistrer lui-même auprès de HubSpot, et les métadonnées de HubSpot ne vous diront pas à l’avance quelles permissions il s’apprête à céder. Ce n’est pas une critique de HubSpot. C’est la forme réelle de ce qu’on vous vend, et il a fallu une seule commande pour la trouver.

Je dois préciser d’emblée ce que ce billet est et n’est pas. Je n’ai jamais connecté un agent IA au compte publicitaire ou au CRM d’un client, et je n’aurais pas écrit ceci si je l’avais fait — ce qui compte, c’est ce que la documentation s’engage à faire, pas ce qu’une intégration a produit un mardi. Tout ce qui suit provient de documentation de fournisseurs que j’ai ouverte, de tickets GitHub que j’ai lus, de registres et de bases de vulnérabilités que j’ai interrogés, et de commandes que j’ai exécutées, le 21 août 2026. Là où une source contredisait mes notes, la source a gagné et je le dis.

La seule chose que je possède de première main, c’est l’autre côté de la table. Ce site enregistre des outils d’agent en production. J’en ai écrit moi-même les frontières de permission, et c’est la partie de cette histoire que je n’attendais pas.

Les citations de documentation et de tickets sont reproduites en anglais, langue de leurs sources ; la traduction entre parenthèses est la mienne.

Réponse courte

Au 21 août 2026, le serveur MCP de Google Ads est strictement en lecture seule — trois outils, aucune écriture — tandis que celui de Meta s’est ouvert à toute application de développeur le 16 juillet 2026 en documentant la création de campagnes, d’ensembles de publicités, de publicités et d’audiences personnalisées. HubSpot et Salesforce écrivent tous deux dans les fiches CRM et héritent tous deux des permissions existantes de l’utilisateur qui autorise. Le danger n’est pas la liste d’outils, c’est l’octroi : le serveur en lecture seule de Google exige quand même https://www.googleapis.com/auth/adwords, l’unique portée OAuth de l’API Google Ads, qui donne un accès complet en gestion. Ce que je fais avant d’autoriser quoi que ce soit : je lis la portée demandée à l’écran de consentement et j’ignore complètement la liste d’outils, parce que la liste est une promesse du fournisseur et la portée est la permission réelle.

Tout ce billet a été vérifié à sa source primaire le 21 août 2026. Traitez-le comme un instantané dont la durée de vie se compte en semaines. Un mainteneur chez Google a déjà annoncé que les outils d’écriture s’en viennent, ce qui renverse la colonne la plus importante du tableau ci-dessous.

Lequel de ces serveurs peut réellement modifier quelque chose ?

Voici la matrice que personne n’avait publiée quand je suis parti la chercher. Chaque cellule a été lue sur une page de fournisseur ou dans une réponse d’API le 21 août 2026.

PlateformeServeurLectureÉcritureOutils documentésEnregistrement clientDate du docCVE publiée
Google Adsgoogleads/google-ads-mcp, auto-hébergéOuiNon3Votre propre client OAuthMis à jour le 19 août 2026Aucune dans NVD
Meta Adsmcp.facebook.com/ads, hébergé par MetaOuiOui28 sur la seule page de créationFacebook Login ou jeton porteurOuvert le 16 juillet 2026Aucune pour celui de Meta
HubSpotmcp.hubspot.com, hébergé par HubSpotOuiOuiNombre non publiéNi DCR ni CIMDDG le 13 avril 2026Aucune trouvée
SalesforceServeurs MCP hébergés par SalesforceOuiOuiDéfinis par votre orgExternal Client App, pré-enregistréeDG le 29 avril 2026Aucune trouvée
Microsoft Advertisingpartner.api.bingads.microsoft.comNon documentéNon documentéNon publiéEnregistrement d’app AADms.date 22 juillet 2026Aucune trouvée
pipeboard-co/meta-ads-mcp, tierce partiePaquet communautaireOuiOuiNon auditéJeton fourni par l’exploitant—CVE-2026-48039, CVSS 9,1

Deux colonnes méritent un avertissement. « CVE publiée » signifie que je n’en ai pas trouvé, pas qu’il n’en existe aucune — un serveur hébergé par le fournisseur est corrigé en silence et ne produirait jamais de CVE, donc une cellule vide n’y veut presque rien dire pour les quatre lignes hébergées. Et « Outils documentés » désigne ce que le fournisseur a choisi de publier, ce qui, pour HubSpot et Salesforce, n’est pas un nombre.

La dernière ligne est d’une autre nature que les cinq au-dessus, et savoir les distinguer constitue l’essentiel du travail.

Que peut réellement faire un agent IA dans Google Ads ?

Rien qui coûte de l’argent. La page de Google consacrée au serveur MCP de Google Ads, mise à jour le 19 août 2026, le dit sans détour : « This implementation is strictly read-only. It cannot modify bids, pause campaigns, or create new assets. » (Cette implémentation est strictement en lecture seule. Elle ne peut ni modifier les enchères, ni mettre des campagnes en pause, ni créer de nouveaux éléments.) La page indique le mode « Read-only (current release) » et documente exactement trois outils : list_accessible_customers, search et get_resource_metadata.

C’est une contrainte réelle, honnêtement documentée, et elle ne durera pas. Le 4 juin 2026, dans le ticket n° 84 du dépôt googleads/google-ads-mcp, un mainteneur a écrit : « We already have plans to add write access soon; each individual write tool will be configurable with the YAML file introduced in #82. Because of this, we won’t accept PRs adding write features. » (Nous avons déjà prévu d’ajouter l’accès en écriture prochainement ; chaque outil d’écriture sera configurable par le fichier YAML introduit dans le ticket n° 82. Pour cette raison, nous n’accepterons pas de PR ajoutant des fonctions d’écriture.) La proposition a été fermée le matin même. La colonne « lecture seule » de cette matrice est donc une note de version, pas une politique.

Puis il y a l’état de la chose. Le dépôt compte 876 étoiles et a été créé le 3 octobre 2025. Il ne compte aucune version publiée et aucune étiquette, et le fichier pyproject.toml sur main affiche toujours version = "0.0.1". Le ticket n° 107, ouvert le 13 août 2026, s’intitule « Can we publish releases here? » et reste ouvert. Le ticket n° 102, ouvert le 10 août 2026, signale que search — l’un des trois outils — est inatteignable, parce que les identifiants clients sont des chaînes composées uniquement de chiffres que les clients MCP sérialisent en nombres JSON, que le modèle Pydantic généré refuse : « No input both passes validation and is accepted by the API, so the tool is effectively unreachable. » (Aucune entrée ne passe à la fois la validation et l’API, donc l’outil est en pratique inatteignable.) Ouvert lui aussi.

Je veux être prudent sur ce que cela prouve. C’est un échantillon des utilisateurs les plus bruyants, pas un taux de défaut. Mais si vous évaluez ceci pour une équipe cliente, « l’outil de lecture ne fonctionne pas en ce moment » est une autre conversation d’approvisionnement que « lecture seule pour l’instant ».

Le fait vraiment inconfortable est ailleurs, dans le fichier README plutôt que dans la page de documentation. Pour faire tourner ce serveur, vous devez fournir des identifiants portant https://www.googleapis.com/auth/adwords. Le guide OAuth de l’API Google Ads précise : « The scope for the Google Ads API is: https://www.googleapis.com/auth/adwords. » Une seule portée. Il n’existe aucune variante en lecture seule. Le serveur en lecture seule détient donc un jeton capable de modifier chaque campagne de chaque compte qu’il peut voir. La restriction vit dans le code Python du serveur, pas dans l’octroi — et c’est l’octroi qui survit si le jeton fuit.

Que peut réellement faire un agent IA dans Meta Ads ?

Nettement plus, et c’est ici que je dois corriger mes propres notes.

L’annonce de Meta du 16 juillet 2026 indique que toute application peut désormais se connecter au serveur MCP publicitaire, et documente « Create, edit, and delete campaigns, ad sets, and ads » ainsi que « Create, update, and delete custom audiences ». Ma note de travail affirmait que Meta avait livré cela sans aucun garde-fou documenté. C’était faux, et je l’ai découvert en ouvrant la référence des outils plutôt que le billet d’annonce.

La page de création et de gestion publicitaire de Meta indique : « Write tools create entities in a paused state; your AI client asks for confirmation before activation. » (Les outils d’écriture créent les entités en état de pause ; votre client IA demande une confirmation avant l’activation.) Chaque outil d’écriture le répète — ads_create_campaign est décrit comme « Create a new ad campaign (paused) », et la même parenthèse figure sur ads_create_ad_set et ads_create_ad. Le défaut « créé en pause » est réel, il est documenté, et quiconque prétend le contraire — moi y compris, il y a deux jours — a lu le billet d’annonce et non la documentation.

Lisez maintenant la même page pour ce que cela vous coûte. Elle compte 28 outils à elle seule. L’un d’eux est ads_activate_entity : « Change a paused campaign, ad set, or ad to active — starts spending budget. » (Faire passer une campagne, un ensemble ou une publicité de pause à actif — commence à dépenser le budget.) Le filet de sécurité est un défaut que l’agent dispose d’un outil pour retirer, et la confirmation relève explicitement du client, pas du serveur. La phrase de Meta dit « your AI client asks for confirmation ». Rien dans le protocole n’oblige un client à demander. Si vous remplacez Claude Desktop par un orchestrateur autonome écrit par vos soins, vous avez gardé les outils d’écriture et perdu le garde-fou, et ni Meta ni la spécification ne vous en empêcheront.

La deuxième chose que la référence des outils vous apprend, c’est que le billet d’annonce a survendu la suppression. Aucun outil de cette page ne supprime une campagne, un ensemble de publicités ou une publicité. ads_update_entity met à jour des champs, et le seul outil de suppression est ads_delete_custom_audience. Les deux affirmations viennent de Meta. Quand un billet de blogue et une référence d’outils se contredisent, c’est la référence que votre agent appellera vraiment.

Que peut modifier un agent dans HubSpot et Salesforce ?

Les deux écrivent, et les deux gèrent mieux les permissions que les plateformes publicitaires — l’inverse de ce à quoi je m’attendais avant de les lire.

Le serveur MCP distant de HubSpot est passé en disponibilité générale le 13 avril 2026. Son journal des changements découpe la surface explicitement : il lit les fiches CRM, les objets marketing et de contenu, et les activités, et il crée et met à jour contacts, entreprises, transactions, tickets, lignes de produits et produits, en plus des appels, réunions, notes, tâches et courriels. Le modèle de permissions tient dans une phrase : « All actions respect your existing HubSpot user permissions — users can only access or modify records they already have permission to view or edit. » (Toutes les actions respectent vos permissions HubSpot existantes — les utilisateurs ne peuvent consulter ou modifier que les fiches qu’ils sont déjà autorisés à voir ou à modifier.)

Les serveurs MCP hébergés de Salesforce ont atteint la disponibilité générale le 29 avril 2026 avec la même posture, énoncée plus fermement : « Your existing permissions automatically apply — CRUD, FLS, sharing rules, and all the other controls you’ve already mastered », et « Every transaction runs as the authenticated user, without anonymous service accounts or a new security model to learn. » (Chaque transaction s’exécute au nom de l’utilisateur authentifié, sans compte de service anonyme ni nouveau modèle de sécurité à apprendre.) La configuration passe par une External Client App dotée des portées mcp_api et refresh_token, et Salesforce est explicite : « A new OAuth scope provides access to MCP, but not our existing REST APIs. »

Arrêtez-vous sur cette dernière proposition, parce que c’est la meilleure décision de conception de tout ce tableau. Salesforce a créé une portée qui accorde MCP et seulement MCP. Google a réutilisé une portée qui accorde tout. Même protocole, réponses opposées à la même question, et le seul moyen de les distinguer est de lire l’écran de consentement.

Deux autres limites méritent d’être connues, venues de praticiens plutôt que de fournisseurs. Chez Salesforce, Agentforce refusera en silence d’appeler un outil MCP tiers dont la description a changé depuis l’enregistrement. La réponse du fil Salesforce Stack Exchange du 8 juin 2026 explique le mécanisme : Agentforce sauvegarde une copie de la description à l’activation, la compare à l’exécution, et « should any of the content be different, the tool is flagged as having a description_mismatch and excluded from the list of available tools. This is done to prevent rug-pull attacks. » (Si le contenu diffère, l’outil est marqué description_mismatch et exclu de la liste des outils disponibles. Cela vise à prévenir les attaques par retrait du tapis.) C’est une défense délibérée contre un serveur qui livrerait une description pour être approuvé et une autre pour être utilisé. C’est aussi, en pratique, un outil qui cesse de fonctionner sans aucune erreur que votre équipe marketing verra un jour.

Du côté du CMS de HubSpot, la limite est architecturale plutôt que sécuritaire. Le ticket n° 6 du dépôt HubSpot/mcp-server, ouvert le 22 mai 2026 et toujours ouvert, dégage la règle réelle : MCP peut modifier le contenu d’un module lorsque celui-ci est codé en dur dans le gabarit sous la forme {% module "instance_name" %}, parce que le nom d’instance est adressable — et ne le peut pas lorsque le module a été glissé-déposé dans une zone dnd_area ou widget_container, parce que ces instances reçoivent des identifiants numériques auto-générés au moment du placement. Concrètement : vos pages de destination codées sont modifiables par un agent et la page que le marketing a montée dans l’éditeur glisser-déposer ne l’est pas. Cette distinction est invisible du côté marketing de l’outil, et c’est exactement le genre de couture que je croise dans planifier une pile martech avant d’acheter des outils.

Qu’est-ce que connecter un agent accorde vraiment ?

C’est la question que la présentation du fournisseur a sautée, et sa réponse diffère de la liste d’outils sur chacune des lignes.

PlateformePortée ou permission demandéeCe que la surface d’outils exposeL’écart
Google Adshttps://www.googleapis.com/auth/adwords — l’unique portée de l’API3 outils en lecture seuleAccès complet en modification, détenu mais inutilisé
Microsoft Advertisinghttps://ads.microsoft.com/msads.manageAucune liste d’outils dans le guide d’installationUne portée de gestion pour une surface non divulguée
Meta Adsads_mcp_management, ads_read, ads_management, catalog_management, business_management, pages_show_list, instagram_basic28 outils publicitaires, en pause par défautUn jeton d’API Marketing générique ; tout ce qui le détient peut appeler l’API Graph directement et contourner la pause
HubSpotNon annoncée — "scopes_supported": []Lecture plus création et mise à jour des objets CRM principauxLe document de métadonnées ne l’énumère pas — lisez l’écran de consentement
Salesforcemcp_api et refresh_tokenFlows, actions Apex, requêtes nommées, lectures d’objetsMCP uniquement, aucun accès aux API REST

La ligne Microsoft est celle que je mettrais sur une diapositive. Le guide d’installation de Microsoft, daté du 22 juillet 2026, vous demande de configurer la portée https://ads.microsoft.com/msads.manage offline_access et pointe vers un point de terminaison portant ?toolSetNames=OpenBeta. Le guide ne documente aucune liste d’outils, et ses deux exemples de requêtes sont des lectures. On vous demande donc d’accorder une portée de gestion à une surface qui n’est pas publiée. Elle est peut-être entièrement en lecture seule aujourd’hui. Le jeton, lui, s’en moque.

La ligne Meta est la plus tranchante sur le plan opérationnel. Le défaut « créé en pause » vit dans l’outillage MCP de Meta. Les permissions que vous approuvez sont ads_management et compagnie — des permissions ordinaires de l’API Marketing. Tout processus détenant ce jeton d’accès peut appeler l’API Graph directement, là où aucune description d’outil MCP et aucun défaut de pause ne s’appliquent. Le garde-fou est à la couche MCP ; l’octroi est à la couche API en dessous. Voilà toute la réponse à « qu’est-ce que connecter un agent accorde vraiment », et c’est pourquoi j’ai cessé de lire les listes d’outils en premier.

Pourquoi mon client IA se connecte-t-il à HubSpot alors que ma plateforme d’automatisation n’y arrive pas ?

Parce que HubSpot ne prend en charge aucune des deux façons dont un client peut s’enregistrer lui-même, et parce que les deux types de clients échouent différemment.

La révision actuelle de la spécification MCP, datée du 28 juillet 2026, fixe un ordre de priorité pour l’enregistrement client : utiliser des identifiants pré-enregistrés si vous en avez ; sinon les Client ID Metadata Documents si le serveur d’autorisation annonce client_id_metadata_document_supported ; sinon l’enregistrement dynamique de client s’il annonce un registration_endpoint ; et sinon, « Prompt the user to enter the client information if no other option is available. » (Demander à l’utilisateur de saisir les informations du client si aucune autre option n’est disponible.)

Le document de métadonnées de HubSpot, que j’ai récupéré ce matin, n’annonce ni l’un ni l’autre. Tous les clients atterrissent donc à l’étape quatre. Un client IA de bureau gère l’étape quatre sans peine : il affiche un formulaire, vous y collez un identifiant et un secret provenant d’une application que vous avez créée vous-même, et ça marche. Une plateforme d’automatisation dont l’identifiant MCP a été bâti autour des trois premières étapes, non.

Ce n’est pas une hypothèse. Le 28 juillet 2026, un même rapporteur a déposé trois fois le même bogue contre n8n en moins de sept minutes — les tickets 35093, 35094 et 35096, les deux premiers retirés en quelques secondes comme doublons — tous intitulés « MCP OAuth2 API credential cannot authenticate with HubSpot Remote MCP Server ». L’auteur a fait le travail que j’aurais fait : remplacer l’URL du jeton par un webhook pour capturer la requête sortante, puis la comparer à celle de MCP Inspector, qui s’authentifie avec succès auprès de la même application HubSpot. HubSpot renvoie {"status": "BAD_CLIENT_SECRET", "message": "missing or invalid client secret", "error": "invalid_client"}. La cause est dans les métadonnées que j’ai récupérées : HubSpot annonce "token_endpoint_auth_methods_supported": ["client_secret_post"] et rien d’autre, donc les identifiants doivent arriver dans le corps de la requête, alors que n8n envoyait un en-tête Authorization: Basic. Le client fonctionnel envoie aussi resource=https://mcp.hubspot.com/, pour lequel n8n n’avait aucun champ.

La révision de la spécification MCP est ici un arrière-plan, pas le sujet, mais elle explique la direction : la révision du 28 juillet déprécie l’enregistrement dynamique de client au profit des Client ID Metadata Documents, en le gardant « available for backwards compatibility with authorization servers that do not support Client ID Metadata Documents », avec une fenêtre de dépréciation d’au moins douze mois. HubSpot ne prend en charge ni le mécanisme déprécié ni son remplaçant. Si vous choisissez l’outil qui pilotera ces connexions, voilà un critère de sélection bien vivant, de la même famille que les questions d’intégration de CDP, CRM et automatisation marketing.

Qu’est-ce qu’enregistrer des outils d’agent sur mon propre site m’a appris ?

Plus que la lecture des spécifications, parce qu’écrire une frontière de permission est un autre geste que lire celle d’un autre.

Ce site enregistre quatre outils navigateur pour les agents, dont deux dans AgentTools.jsx. Ils sont en lecture seule et de même origine : l’un liste le contenu publié, l’autre renvoie la version Markdown d’une page. C’est le versant écriture d’une question dont j’ai pris le versant lecture dans savoir si une IA peut lire votre site. C’est une surface volontairement réduite — là où j’emploie des agents pour le contenu, la question intéressante relève du flux de travail plutôt que des permissions, et je l’ai traitée à part dans les agents IA pour le contenu SEO. Quatre décisions de ce fichier renvoient à tout ce qui précède.

La liste blanche de chemins. read_page_as_markdown reçoit un chemin en argument et le valide contre /^\/(articles|resources|ressources)\/[a-z0-9-]+$/ avant toute requête. Sans cette expression régulière, l’outil devient un mandataire de récupération de même origine pour n’importe quel chemin qu’on aura convaincu un agent de transmettre. Les arguments d’outil sont des entrées influencées par un attaquant — le modèle à l’autre bout a lu une page web, et la page web avait peut-être des opinions. J’ai vérifié qu’il rejette les URL externes et la traversée par ../. Ce contrôle existe parce que l’alternative est un outil dont la capacité réelle dépasse largement sa description, soit exactement le problème de la portée Google Ads en miniature.

La révocation revient à l’appelant, pas à la plateforme. L’API n’a pas de méthode unregisterTool() ; la section « Unregister tools » de Chrome retire plutôt un outil au moyen d’un AbortSignal, donc on passe un signal à l’enregistrement et on le déclenche soi-même au nettoyage. Mal fait, une capacité que vous croyez avoir retirée reste active sur une page qui ne l’affiche plus. C’est l’étape huit de la liste ci-dessus, en petit. Chaque octroi de ce billet a la même propriété : quelqu’un doit se charger de l’éteindre, et aucun écran de consentement ne le lui rappellera.

L’API correcte est document.modelContext.registerTool(). Une bonne part des textes que j’ai lus en construisant ceci citent plutôt navigator.modelContext.provideContext(), y compris des outils qui auditent des sites pour leur « préparation aux agents ». Cette forme est tout simplement fausse, et c’est un indice utile : une page qui la répète n’a pas exécuté le code. Le même indice fonctionne sur les plateformes publicitaires. Tout texte décrivant le serveur de Meta sans le défaut « créé en pause » cite le billet d’annonce.

Ce qui m’amène à l’analogie à laquelle je me fie vraiment, et elle n’est pas technologique. Dans un programme de services financiers, le travail qui a fait la différence a été d’amener architectes de données, DBA, développeurs et fournisseurs externes à s’entendre sur la forme des données avant qu’aucune ne bouge. Pas une décision d’outil. Une décision sur la définition du « terminé », prise par les gens qui en porteraient les conséquences, avant que le premier octet ne franchisse une frontière. Accorder à un agent une portée d’écriture sur un CRM appartient à la même classe de décisions en habits neufs, et dans la plupart des organisations elle est prise par la personne qui a cliqué sur « Approuver ».

Une liste de vérification avant d’autoriser une intégration d’agent

À exécuter dans l’ordre. Chaque étape a un mode de défaillance que je peux montrer du doigt.

  1. Lisez l’écran de consentement, pas la liste d’outils. Notez la chaîne exacte de la portée avant d’approuver. Échoue quand la liste d’outils et la portée se contredisent : le serveur de Google est en lecture seule et demande https://www.googleapis.com/auth/adwords, l’unique portée de l’API Ads, qui donne la gestion complète. La liste d’outils est une promesse. La portée est une permission.
  2. Établissez qui publie le serveur. Hébergé par le fournisseur, source ouverte publiée par le fournisseur, ou paquet communautaire ? Échoue en silence parce que les noms se ressemblent : le serveur de Meta est mcp.facebook.com/ads, et pipeboard-co/meta-ads-mcp est un paquet non affilié qui portait la CVE-2026-48039. Mêmes mots, rayon d’explosion différent.
  3. Vérifiez sous quelles identités le serveur s’exécute. HubSpot et Salesforce exécutent chaque transaction au nom de l’utilisateur authentifié et héritent de ses permissions, donc un utilisateur CRM restreint est un vrai contrôle. Un serveur auto-hébergé tournant sur une variable d’environnement de l’exploitant, non — c’est la forme qu’a exploitée la CVE-2026-48039.
  4. Récupérez les métadonnées du serveur d’autorisation avant de fixer votre choix de client. Un seul curl sur /.well-known/oauth-authorization-server. Échoue quand vous normalisez d’abord sur une plateforme d’automatisation et découvrez le mur ensuite — HubSpot n’annonce aucun registration_endpoint, aucun client_id_metadata_document_supported et "scopes_supported": [], ce qui explique trois enjeux déposés contre n8n en une matinée.
  5. Cherchez l’espace de noms dans le registre MCP officiel. Échoue par fausse impression de contrôle : les principes de conception du registre affirment « No built-in ranking, curation, or quality judgments » et délèguent la sécurité du code source à npm et PyPI. Une inscription est une revendication de nom, pas un audit.
  6. Demandez où le garde-fou est appliqué — serveur ou client. Les outils d’écriture de Meta créent les entités en pause et « your AI client asks for confirmation before activation ». Échoue le jour où vous remplacez le client par votre propre orchestrateur en gardant la portée d’écriture.
  7. Testez d’abord dans un bac à sable ou avec un utilisateur volontairement restreint. Échoue de façons dont personne ne vous prévient : Agentforce exclut les outils tiers dont la description a changé avec un description_mismatch et aucune erreur visible, et le MCP de HubSpot ne peut pas modifier les modules placés dans une dnd_area.
  8. Écrivez le chemin de révocation et l’expiration, et fixez une date de révision. Échoue par omission. Chaque fait de ce billet porte une date de documentation des cinq derniers mois, et un mainteneur chez Google a déjà annoncé l’écriture. Une décision de permission prise en août 2026 sur des preuves d’août 2026 exige une relecture à l’automne.

Les étapes un à trois sont celles que je ne sauterais pas sous pression d’échéance. Pour la version plus large de cette conversation, l’évaluation interactive de pile martech couvre l’architecture environnante, et le glossaire martech définit le vocabulaire que ces présentations supposent déjà partagé.

Tout cela est-il réellement dangereux ?

Une fois, de façon vérifiable, et pas là où regarde la conversation marketing.

La CVE-2026-48039 a été publiée le 7 août 2026 avec un score CVSS 3.1 de base de 9,1, critique, classée CWE-287. Elle touche pipeboard-co/meta-ads-mcp avant la version 1.0.109 — un paquet communautaire, pas le serveur hébergé de Meta. La description du NVD vaut d’être lue de près, parce que la chaîne de défaillance est ordinaire plutôt qu’exotique : l’intergiciel d’authentification « unconditionally forwards unauthenticated Streamable HTTP requests to downstream MCP tool handlers without issuing a 401 response, allowing any network-reachable caller to invoke MCP tools without authentication ». Sans identifiant par requête, les gestionnaires se rabattent sur le META_ACCESS_TOKEN de l’exploitant. Et quand l’appel à l’API Graph échoue, le code « serialises the raw httpx request URL — including the operator’s access_token as a query parameter — into the JSON-RPC response body, delivering the credential to the unauthenticated caller ».

Trois erreurs ordinaires, empilées. Un 401 manquant, un identifiant de repli, et un gestionnaire d’erreurs qui renvoie une URL en écho. Résultat : une requête ratée remet le jeton de votre compte publicitaire à qui l’a demandé. L’évaluation SSVC de la CISA sur la même fiche marque l’exploitation comme preuve de concept, automatisable, avec un impact technique total.

Ce paquet figure dans le registre MCP officiel. Le serveur Google Ads du même éditeur aussi, publié le 21 mai 2026. Une inscription n’est pas un aval, et le registre le dit dans ses propres documents de conception : « No built-in ranking, curation, or quality judgments », « Let consumers (MCP clients, aggregators) make their own curation decisions », « Avoid features that require constant human intervention or moderation ». Il s’appuie sur npm et PyPI pour la sécurité du code, « obviating the need to reinvent source code security ». C’est une architecture défendable pour un méta-registre. Ce n’est pas un signal de sécurité, et l’écosystème le lit comme s’il en était un. Pour l’échelle : une recherche par mot-clé sur « mcp server » dans la National Vulnerability Database renvoyait 288 fiches le 21 août 2026.

Puis il y a le constat sur lequel je reviens sans cesse. Le registre prend en charge la vérification DNS et HTTP pour les espaces de noms de domaine comme com.example.*, et GitHub OAuth pour io.github.*. J’ai vérifié sept fournisseurs martech. com.hubspot, com.salesforce, com.adobe, com.klaviyo, com.braze, com.twilio et com.segment détiennent zéro serveur à eux tous. Cherchez HubSpot dans le registre et vous obtenez bien des résultats ; chacun se trouve sous l’espace de noms de quelqu’un d’autre, le plus souvent io.github.*. Google détient quinze espaces de noms vérifiés, tous en com.googleapis.* — Compute, Firestore, Cloud Run, Monitoring et les autres — et aucun pour Ads ni Analytics. Pendant ce temps, com.stripe/mcp est inscrit depuis le 28 octobre 2025 et pointe vers mcp.stripe.com.

Ce n’est donc pas une lacune technique. Stripe prouve qu’un fournisseur peut revendiquer son espace de noms quand il juge que l’écosystème compte. Les fournisseurs martech ont livré des serveurs MCP et n’ont pas revendiqué le leur, ce qui signifie qu’un agent qui découvre aujourd’hui un serveur « HubSpot » par le registre trouve le code de quelqu’un d’autre portant le nom de HubSpot.

Mon avis de travail

La matrice lecture/écriture est ce qu’il y a de moins intéressant sur cette page et c’est la seule chose que la plupart des articles reproduisent. Lecture seule contre écriture est une distinction de note de version qu’un commentaire de mainteneur peut invalider en un sprint. La portée, elle, est le fait durable.

Si je conseillais un responsable des opérations marketing cette semaine, la position serait étroite. Connectez librement les outils de lecture ; la valeur est réelle et le risque se résume à un rapport qu’il faut vérifier, ce qui a toujours été le risque du reporting. Traitez toute portée d’écriture comme une modification de votre modèle d’accès, pas comme une fonction de productivité, et faites-la passer par les personnes qui possèdent l’accès à ce système — les mêmes qui auraient dû être dans la salle avant que des données ne bougent ailleurs. Et préférez les plateformes qui ont bien découpé la chose : Salesforce créant une portée réservée à MCP et les deux CRM héritant des permissions de l’utilisateur autorisant sont des postures nettement meilleures qu’une portée publicitaire unique et toute-puissante, et ce classement n’est pas celui que suppose la conversation marketing.

Ce que je ne sais pas, c’est le taux de défaillance opérationnel. J’ai lu la documentation attentivement et j’ai écrit des outils d’agent avec des frontières de permission, et ni l’un ni l’autre ne me dit à quelle fréquence un agent capable d’écrire fait quelque chose de coûteux dans un vrai compte publicitaire. Personne, à ma connaissance, ne l’a publié, et je ne vais pas l’estimer. L’autre chose que je ne sais pas, c’est combien de tout ceci survivra à septembre. La phrase la plus lourde de conséquences que j’ai lue cette semaine est celle d’un mainteneur annonçant l’accès en écriture « soon » — d’où la forme honnête de ce billet : un instantané avec sa date de vérification imprimée dessus, et si vous en lisez une version sans date, elle vous cache quelque chose.

Une conclusion ennuyeuse : lisez la portée, pas la liste d’outils. Je la crois juste, et elle le restera après que les listes d’outils auront changé.

Foire aux questions sur les agents IA dans les comptes publicitaires et le CRM

Un agent IA peut-il mettre une campagne Google Ads en pause ?

Pas par le serveur MCP officiel de Google. Sa documentation, mise à jour le 19 août 2026, indique : « This implementation is strictly read-only. It cannot modify bids, pause campaigns, or create new assets. » Seuls trois outils sont exposés : list_accessible_customers, search et get_resource_metadata. Un mainteneur a confirmé le 4 juin 2026 que l’accès en écriture est prévu ; traitez donc ceci comme un fait de version courante, non comme un engagement de conception.

Un agent IA peut-il créer des publicités Meta sans approbation ?

Il peut les créer, et la documentation de Meta précise qu’elles arrivent en pause : « Write tools create entities in a paused state; your AI client asks for confirmation before activation. » La confirmation relève du client IA, pas du serveur, et un outil distinct nommé ads_activate_entity existe pour faire passer une entité en pause à l’état actif. Un client sur mesure ou autonome conserve les outils d’écriture et perd l’invite.

Quelles permissions accorde la connexion d’un agent IA à HubSpot ?

Celles que possède déjà l’utilisateur qui autorise. Le journal des changements de disponibilité générale du 13 avril 2026 indique que « All actions respect your existing HubSpot user permissions — users can only access or modify records they already have permission to view or edit. » Le serveur lit les fiches CRM, le contenu marketing et les activités, et crée et met à jour contacts, entreprises, transactions, tickets, lignes de produits, produits et activités. Ses métadonnées d’autorisation renvoient "scopes_supported": [], vous ne pouvez donc pas énumérer l’octroi à l’avance : restreignez plutôt l’utilisateur qui se connecte.

Peut-on installer en confiance depuis le registre MCP officiel ?

C’est un annuaire, pas un comité de révision. Ses principes de conception publiés affirment « No built-in ranking, curation, or quality judgments » et délèguent la sécurité du code source à des registres de paquets comme npm et PyPI. Une inscription au registre vérifie une revendication d’espace de noms, rien de plus — pipeboard-co/meta-ads-mcp, qui portait la CVE-2026-48039 critique, y figure.

Les fournisseurs martech publient-ils des serveurs MCP officiels dans le registre ?

Pas au 21 août 2026. Vérifié directement contre l’API du registre, les espaces de noms com.hubspot, com.salesforce, com.adobe, com.klaviyo, com.braze, com.twilio et com.segment détiennent zéro serveur, et les quinze espaces de noms vérifiés de Google sont tous en com.googleapis.*, aucun pour Ads ni Analytics. com.stripe/mcp y est inscrit depuis le 28 octobre 2025 : les fournisseurs s’enregistrent donc clairement quand ils le décident. Prenez vos paramètres de connexion dans la documentation du fournisseur, pas dans un résultat de recherche.

Sources utilisées

Vérifié à la source : 21 août 2026.