Sécurité d'un connecteur MCP : 8 questions avant de brancher l'IA sur vos clients

Réponse courte : brancher une IA sur des données marketing en sécurité repose sur quatre garanties vérifiables — OAuth saisi par le client chez Google (jamais de mot de passe transmis), scopes en lecture seule, aucune donnée métier stockée par le connecteur, et une révocation qui agit chez Google, pas seulement dans l’outil. Un connecteur qui ne répond pas clairement à ces quatre points n’est pas prêt pour des comptes clients.

La frontière exacte : ce qui est stocké chiffré, ce qui ne fait que transiter.

Nous avons construit Attaché, donc cet article n’est pas neutre. Mais la checklist qui suit, nous l’appliquerions à n’importe quel outil — y compris au nôtre, et surtout au nôtre. Quand une agence branche une IA sur les comptes Google de ses clients, elle engage sa responsabilité sur des données qui ne lui appartiennent pas. Ça mérite mieux qu’un badge « sécurisé » sur une page d’accueil.

Un connecteur MCP est un serveur qui expose des sources de données externes (GA4, Google Ads, Search Console…) à un assistant IA comme Claude, sous forme d’outils que l’IA appelle à la demande. Si le concept est encore flou, on l’a expliqué sans jargon ici. La question de cet article, c’est : comment évaluer la sécurité d’un tel connecteur avant de lui confier douze comptes clients.

Qui saisit les identifiants ?

La seule bonne réponse : le client, chez Google, via OAuth. Pas l’agence. Pas un « compte de service partagé ». Et certainement pas un mot de passe collé dans un formulaire tiers.

Le jour où un outil vous demande le mot de passe Google d’un client, arrêtez la démo. Ce n’est pas un détail d’implémentation, c’est un modèle de confiance : un mot de passe donne tout, pour toujours, sans trace. Un jeton OAuth donne un périmètre précis, visible sur l’écran de consentement, révocable à tout moment. Chez Attaché, le client clique un lien d’invitation, se connecte une fois chez Google, coche les propriétés qu’il accepte de partager. Personne de l’agence n’est jamais ajouté dans GA4, Google Ads ou Search Console — le détail du flux est dans notre article sur l’onboarding sans mot de passe.

Quels scopes l’outil demande-t-il ?

Vous n’avez pas à croire le vendeur : Google affiche les scopes demandés sur l’écran de consentement, avant que le client clique. analytics.readonly et webmasters.readonly sont des scopes en lecture seule. Si vous voyez un scope d’écriture ou un scope large sans justification, la question suivante s’impose.

Prenez deux minutes pendant l’essai pour lire cet écran ligne par ligne. C’est la vérification la moins chère de toute votre due diligence.

Le cas Google Ads, celui dont personne ne parle

Ici, une vraie limite que la plupart des pages sécurité passent sous silence : Google ne publie pas de scope lecture seule pour Google Ads. Le scope adwords est le seul disponible, et il autorise l’écriture.

Tout connecteur Google Ads porte donc ce risque, le nôtre inclus. La bonne réponse est un garde-fou applicatif : côté serveur, sur chaque requête, sans mode admin ni exception. Chez Attaché, toute requête GAQL qui n’est pas un SELECT est rejetée avant d’atteindre l’API de Google. C’est une garantie de moindre nature qu’un scope en lecture seule — elle repose sur notre code, donc sur notre parole. Un fournisseur qui vous dit « notre IA ne modifie rien » sans expliquer comment l’écriture est bloquée vous vend une intention, pas une garantie.

Que stocke le connecteur, exactement ?

Un connecteur temps réel n’a besoin de stocker que trois choses : des jetons OAuth chiffrés, les identifiants des ressources partagées, et un journal des requêtes. C’est tout ce qu’Attaché conserve — les jetons en AES-256-GCM, et le journal garde la question posée, jamais le résultat renvoyé.

Si l’outil que vous évaluez stocke les réponses d’API, demandez où, combien de temps, chiffrées comment, et pourquoi. Un entrepôt de données clients est une surface d’attaque permanente ; une donnée qui ne fait que transiter n’a nulle part où fuir. Nous avons détaillé l’inventaire complet de notre base — y compris ce qui ne nous arrange pas — dans ce qu’Attaché peut voir de vos données.

La révocation agit-elle chez Google ?

C’est la question qui sépare les outils sérieux des autres. Révoquer un accès « dans l’outil » ne suffit pas : si le jeton reste valide chez Google, il reste utilisable — par le fournisseur, ou par quiconque copierait sa base.

La bonne implémentation appelle l’endpoint de révocation officiel de Google. Le jeton meurt à la source, et vous pouvez le vérifier vous-même : ouvrez myaccount.google.com/permissions après révocation, l’application a disparu de la liste. Cette vérification en trente secondes vaut tous les certificats. On a consacré un article entier à la fin de mission, parce que c’est là que ce détail technique devient un argument commercial.

Le multi-clients est-il structurel ou bricolé ?

Une agence, ce n’est pas un compte Google avec douze propriétés : c’est douze clients qui ne doivent jamais se voir entre eux. Vérifiez que l’isolation est structurelle — un tenant par client, résolu à chaque requête — et pas un compte Google « fourre-tout » de l’agence qui centralise les accès de tout le monde. Le fourre-tout, c’est exactement le modèle qui produit des accès fantômes impossibles à auditer.

Vérifiez aussi le périmètre par membre : si votre chef de projet ne gère que quatre clients, peut-il être limité à ces quatre-là ? Chez Attaché, le propriétaire du compte restreint chaque membre à certains clients, et la restriction s’applique instantanément, y compris aux connecteurs déjà installés.

Un exemple pour fixer les idées

Prenons une agence fictive de 12 clients e-commerce qui évalue deux outils. L’outil A demande un compte Google « agence » avec accès à tout, synchronise les données chaque nuit dans son entrepôt, et sa révocation consiste à désactiver le compte dans son interface. L’outil B fait signer chaque client via OAuth, ne stocke rien, et révoque chez Google.

Dix-huit mois plus tard, l’agence perd un client qui part chez un concurrent. Avec l’outil A, il faut retrouver quel accès couvrait ce client, espérer que la purge de l’entrepôt fonctionne, et croire le fournisseur sur parole. Avec l’outil B : un clic, une vérification sur la page des autorisations Google, terminé. La différence ne se voyait pas à la démo. Elle se voit le jour où ça compte.

Le détail complet de nos réponses à ces huit questions est sur notre page sécurité — scopes exacts, chiffrement, sous-traitants.

Questions fréquentes

Un connecteur MCP peut-il modifier mes campagnes Google Ads ?

Techniquement, le scope adwords de Google autorise l’écriture — il n’existe pas de scope lecture seule pour Ads. Un connecteur sérieux bloque donc l’écriture côté serveur, sur chaque requête. Chez Attaché, toute requête GAQL qui n’est pas un SELECT est rejetée avant d’atteindre l’API.

Comment vérifier qu’un accès a vraiment été révoqué ?

Ouvrez myaccount.google.com/permissions avec le compte Google concerné : la liste montre toutes les applications autorisées et leurs scopes. Si l’outil a correctement appelé l’endpoint de révocation de Google, il a disparu de cette liste. Si l’outil n’y figure plus mais que le vendeur parle de « désactivation », méfiance : ce sont deux choses différentes.

Faut-il un compte Google Workspace ou Team pour utiliser un connecteur en équipe ?

Pour Attaché, une organisation Claude Team ou Enterprise permet au propriétaire d’ajouter une seule fois l’URL du connecteur pour toute l’équipe ; chaque membre se connecte ensuite avec son compte Attaché, jamais avec un compte Google. Sur Claude Pro ou Max, chaque personne utilise son URL personnelle. Dans les deux cas, aucun identifiant Google ne circule dans l’équipe.

---

Attaché se teste gratuitement pendant 60 jours, sans carte : app.attache.studio. GA4, Google Ads et Search Console de tous vos clients dans un seul connecteur Claude.