Google Ads Developer Policies : les MCP entrent dans le cadre
Épisode 0
Retour au blog
Google AdsGoogle Ads APIMCPConformitéAgences

Google Ads Developer Policies : les MCP entrent dans le cadre

MAXENCE VANDERSWALMEN

MAXENCE VANDERSWALMEN

Dirigeant d'agence & Expert Google Ads

4 min

Google a publié le 31 août 2026 une mise à jour de ses règles destinées aux développeurs, désormais appelées Google Ads Developer Policies. Le texte de référence range les MCP parmi les outils développeurs couverts et interdit les services proxy mutualisés qui font transiter les requêtes automatisées de plusieurs entreprises indépendantes par un même accès. Pour une agence qui branche des outils IA sur les comptes de ses clients, la question devient très terre à terre : quel jeton développeur et quel projet Google Cloud tournent derrière le connecteur.

Ce que dit l'annonce du 31 août 2026

La page d'annonce est datée du 31 août 2026 et tient en quelques lignes : « We are updating our Google Ads Developer Policies formerly the 'Google Ads API Policy', to support developers in building robust, high-quality integrations as new AI capabilities continue to shape the advertising industry ». Google indique vouloir « establish clear frameworks for emerging technologies that are more secure and drive better outcomes for our shared customers » (Update to the Google Ads Developer Policies, August 2026).

Deux éléments à retenir de cette page. Le nom des règles change : Google Ads API Policy devient Google Ads Developer Policies. La justification affichée porte sur les capacités IA qui se diffusent dans la construction des outils publicitaires. La page ne détaille pas elle-même les clauses modifiées : elle renvoie vers l'article de référence Google Ads Developer Policies.

Les MCP sont nommés dans le périmètre des outils développeurs

Le texte de référence définit les « Developer Services » comme « the Google Ads API and other Google Ads developer tools like MCPs ». Le périmètre ne se limite donc pas aux intégrations API classiques : les MCP sont cités comme faisant partie des outils développeurs couverts (Google Ads Developer Policies).

Le texte va plus loin qu'une simple mise dans le périmètre. Il énonce que « Google prohibits third-party hosted interface, secondary API, wrapper service, or MCP server, proxy endpoint, or any similar service that solely replicates, wraps, or re-exposes Google Ads programmatic capabilities as an intermediate layer » (Google Ads Developer Policies). Un serveur MCP dont la seule fonction est de ré-exposer les capacités programmatiques de Google Ads tombe donc sous une interdiction, et pas seulement sous une obligation d'accès propre.

Deux exigences structurent la suite du texte. Google demande « a direct, verifiable connection between our users and Google », et un projet Google Cloud par entité. Côté opérationnel, cela signifie que l'entité qui accède aux données doit être identifiable et rattachée à son propre projet Cloud.

Le proxy développeur mutualisé est explicitement interdit

Le texte interdit à un développeur de « allow agencies, end-advertisers, or other third parties to access Google Ads access in a way that would allow those third parties to avoid applying for their own Google Ads developer access and Google Cloud Platform project ». Il vise nommément les « shared developer proxy services that route automated requests from multiple independent businesses to bypass individual access » (Google Ads Developer Policies).

C'est le passage qui concerne le plus directement les agences et les freelances. Un outil tiers qui fait passer les appels de plusieurs comptes clients indépendants par un accès développeur unique correspond à la description donnée par Google. Le texte apporte par ailleurs une précision de périmètre utile sur un autre sujet : « RMF applies only to projects with Standard Access », donc l'obligation de fonctionnalités minimales ne pèse que sur les projets disposant du niveau Standard Access.

Ce que la documentation ne tranche pas

La page d'annonce n'indique pas de date d'entrée en vigueur ni de période de grâce. Rien dans les sources consultées ne permet d'écrire que la règle s'applique à compter d'une date précise (annonce du 31 août 2026).

L'annonce ne dit pas non plus quelles clauses ont été ajoutées, supprimées ou reformulées par rapport à la version précédente. Les phrases sur les MCP, sur le projet Google Cloud par entité et sur les proxys mutualisés figurent dans le texte de référence tel qu'il est publié aujourd'hui, mais cette page ne porte aucune date de dernière mise à jour visible, seulement un « ©2026 Google » en pied de page (Google Ads Developer Policies). À partir de ces deux sources, il est impossible de dater l'apparition de ces clauses.

Les conséquences d'un non-respect sont, elles, décrites. Le texte prévoit un avertissement possible avant facturation : « Google may send you a warning before charging non-compliance fees in accordance with the rates detailed on the Google Ads API rate sheet ». Il ajoute que « Violation of these policies may also lead to additional consequences, including downgrading your access, imposing other quota limits on your Google Ads usage, or termination of your Google Ads programmatic access » (Google Ads Developer Policies). Trois leviers sont donc nommés : frais de non-conformité, dégradation ou plafonnement de l'accès, résiliation de l'accès programmatique. Les pages ne précisent en revanche ni le délai ni la procédure de régularisation.

Deux zones restent ouvertes. La répartition des responsabilités entre l'éditeur d'un outil non conforme et l'agence ou l'annonceur qui l'utilise n'est pas précisée. Enfin, aucune liste d'outils, de connecteurs ou de serveurs MCP concernés n'est publiée, et le statut des outils MCP publiés par Google lui-même n'est pas traité.

Ce dossier repose uniquement sur ces deux pages normatives Google. Aucune analyse de presse spécialisée n'a pu être ouverte sur ce sujet précis, donc aucun chiffre ni aucune interprétation tierce n'est reprise ici.

Ce qu'un gestionnaire de compte peut vérifier maintenant

Le sujet ne se lit pas dans l'interface Google Ads. Les deux pages consultées décrivent une règle applicable aux accès développeurs, et ne mentionnent aucun signal visible côté compte annonceur. La vérification se fait donc auprès des fournisseurs d'outils.

1. Lister les connecteurs, scripts, dashboards, outils IA et serveurs MCP branchés sur les comptes clients dont vous avez la gestion. 2. Pour chacun, demander au fournisseur quel accès développeur et quel projet Google Cloud sont utilisés, et si chaque entité dispose bien des siens. Le texte exige « a direct, verifiable connection between our users and Google » (Google Ads Developer Policies). 3. Repérer les outils dont la réponse décrit un accès partagé entre plusieurs entreprises indépendantes : c'est la configuration nommée dans la clause d'interdiction (« shared developer proxy services that route automated requests from multiple independent businesses to bypass individual access »). 4. Repérer séparément les outils dont la fonction se réduit à ré-exposer les capacités programmatiques de Google Ads : le texte vise « any similar service that solely replicates, wraps, or re-exposes Google Ads programmatic capabilities as an intermediate layer » (Google Ads Developer Policies).

À surveiller ensuite : la page d'annonce et l'article de référence, aucun des deux n'indiquant de calendrier à ce stade (annonce du 31 août 2026).

Les points clés à retenir

  • Google a annoncé le 31 août 2026 le passage de la Google Ads API Policy aux Google Ads Developer Policies, en citant la montée des capacités IA comme motif.
  • Le texte de référence range les MCP parmi les outils développeurs couverts, et demande un accès développeur et un projet Google Cloud propres à chaque entité.
  • Les services proxy mutualisés qui routent les requêtes automatisées de plusieurs entreprises indépendantes pour contourner l'obtention d'un accès individuel sont interdits. Un serveur MCP qui se contente de répliquer ou de ré-exposer les capacités programmatiques de Google Ads est prohibé par le texte, indépendamment de la question du jeton développeur.
  • Les sanctions sont décrites : frais de non-conformité, dégradation de l'accès, plafonds de quota, jusqu'à la résiliation de l'accès programmatique. En revanche, ni date d'entrée en vigueur, ni période de grâce, ni répartition des responsabilités entre éditeur et agence ne figurent dans les pages consultées.
  • Action concrète : inventorier les connecteurs branchés sur les comptes clients et demander à chaque fournisseur quel jeton développeur et quel projet Google Cloud il utilise.

Cet article est basé sur l'épisode 0 du podcast

Écoutez la version complète avec Alexia et Maxence pour aller encore plus loin.

Écouter l'épisode