Accès à l'API Google Ads en 2026 : les projets Cloud remplacent les Developer Tokens

Depuis le 9 septembre 2026, l'accès à l'API Google Ads est accordé par projet Google Cloud et non plus par Developer Token. Ce qui a changé, comment configurer l'accès aujourd'hui et ce qui reste exact dans le guide de configuration de juin 2026.

Ce qui a changé le 9 septembre 2026

Notre guide de juin 2026 sur la configuration de l'API Google Ads, l'authentification et les opérations de lecture et d'écriture reposait sur le Developer Token : on le demandait dans l'API Center d'un compte Manager, on y sollicitait l'accès Basic, puis on envoyait le token avec chaque appel. Trois mois plus tard, ce socle a changé. La documentation de Google l'indique désormais sans ambiguïté : « Developer tokens were sunset on September 9, 2026. »

La décision d'accès n'a pas disparu – elle s'est déplacée. Votre niveau d'accès à l'API est désormais déterminé par le projet Google Cloud utilisé pour générer vos identifiants OAuth, et les accès existants ont été migrés automatiquement vers des projets Cloud. Les demandes ne se font plus dans l'API Center : Google demande aux développeurs de ne plus y solliciter de Developer Token et de demander l'accès depuis la page Google Ads API Overview de la Google Cloud Console. Les demandes Basic encore en attente dans l'API Center ont été clôturées et doivent être soumises à nouveau depuis la Cloud Console.

Le guide de juin reste en ligne tel que publié, avec une note datée en tête de page. Ce suivi décrit ce qui diffère aujourd'hui et renvoie au guide partout où le contenu précédent s'applique encore.

Les niveaux d'accès appartiennent désormais au projet Cloud

Les niveaux eux-mêmes sont connus, avec un ajout. Les limites ci-dessous proviennent de la documentation de Google sur les niveaux d'accès, à jour en octobre 2026 :

Niveau d'accès	Comptes de production	Opérations quotidiennes
Test	Non, comptes de test uniquement	15 000
Explorer	Oui	2 880 sur les comptes de production
Basic	Oui	15 000
Standard	Oui	Pas de plafond général (certains services peuvent rester limités)

Explorer est le point d'entrée pratique. Selon Google, une demande effectuée depuis la Cloud Console est examinée automatiquement et, dans la plupart des cas, relevée au niveau Explorer – suffisant pour le reporting interne et une automatisation modeste sur vos propres comptes. Basic et Standard exigent toujours un examen, et tous deux imposent désormais un nouveau prérequis : la vérification de marque du projet Google Cloud. Standard comprend en outre un audit manuel.

Le problème est que la vérification de marque passe facilement inaperçue tant que la configuration technique fonctionne. Un script sous accès Explorer se comportera correctement jusqu'à la limite quotidienne ; prévoyez donc la vérification avant l'arrivée du volume, et non après.

Configurer l'accès aujourd'hui

La séquence est plus courte qu'auparavant, car le projet Cloud est désormais le seul endroit où l'accès est décidé :

Créez un projet Google Cloud, ou choisissez celui qui portera votre intégration Google Ads. La facturation n'est pas nécessaire pour cela.
Activez l'API Google Ads dans la bibliothèque d'API du projet.
Créez les identifiants dans ce même projet – un client OAuth pour un accès basé sur l'utilisateur, ou un compte de service avec une clé JSON.
Demandez l'accès sur la page Google Ads API Overview de la Cloud Console, et réalisez la vérification de marque si vous avez besoin de l'accès Basic ou Standard.

L'étape 3 est la plus importante. Comme l'accès suit le projet qui a émis les identifiants OAuth, des identifiants issus d'un second projet sans lien n'héritent pas du niveau d'accès demandé. Les équipes qui ont créé au fil des ans des clients de test dans des projets distincts devraient les consolider avant de s'appuyer sur un accès en production.

Les détails OAuth du guide de juin – le scope adwords, l'accès hors ligne pour obtenir un refresh token, les raisons pour lesquelles un refresh token cesse de fonctionner – sont inchangés et restent valables.

Authentification et configuration

Le Developer Token est désormais facultatif en pratique. Google indique que vous pouvez continuer à l'envoyer dans les en-têtes de vos requêtes, mais que les serveurs l'ignorent, et qu'une prochaine version majeure de l'API devrait le rejeter. La version 32.0.0 de la bibliothèque Python officielle a supprimé la vérification qui exigeait un token dans la configuration.

Un fichier google-ads.yaml minimal pour OAuth basé sur l'utilisateur se présente donc ainsi :

client_id: YOUR_CLIENT_ID.apps.googleusercontent.com
client_secret: YOUR_CLIENT_SECRET
refresh_token: YOUR_REFRESH_TOKEN
login_customer_id: "1234567890"
use_proto_plus: true

Pour un compte de service, json_key_file_path remplace les trois clés OAuth, éventuellement combiné avec impersonated_email. Chaque clé peut aussi être définie comme variable d'environnement avec le préfixe GOOGLE_ADS_, par exemple GOOGLE_ADS_JSON_KEY_FILE_PATH – le choix le plus judicieux sur les serveurs, où les fichiers de configuration finissent trop souvent dans les sauvegardes et les dépôts.

login_customer_id conserve son sens d'origine. Lorsque vous atteignez un compte client via un compte Manager, il désigne ce compte Manager (chiffres uniquement, sans tirets). Sans lui, de tels appels échouent avec USER_PERMISSION_DENIED.

Versions et bibliothèque Python

L'épinglage de version mérite plus d'attention qu'on ne lui en accorde d'ordinaire. Le guide de juin utilisait version="v22", et cette version n'est plus disponible : la version 33.0.0 de la bibliothèque Python google-ads a supprimé v21 et v22. En octobre 2026, la version actuelle de l'API est v26 (publiée le 14 octobre 2026), et la bibliothèque 34.0.0 en ajoute la prise en charge.

from google.ads.googleads.client import GoogleAdsClient

client = GoogleAdsClient.load_from_storage("google-ads.yaml", version="v26")

Épingler explicitement la version reste la bonne pratique par défaut. En réalité, un client sans version épinglée change silencieusement de comportement à la prochaine mise à jour de la bibliothèque, et Google retire les versions de l'API selon un calendrier publié – une version épinglée transforme au moins ce retrait en changement planifié plutôt qu'en surprise.

La déclaration de publicité politique dans l'UE

Une exigence a pris de court de nombreuses intégrations existantes : le champ contains_eu_political_advertising de la ressource Campaign. Dans les versions de l'API antérieures à v26, chaque nouvelle campagne doit le déclarer. Depuis le 1er avril 2026, les appels mutate échouent avec EU_POLITICAL_ADVERTISING_DECLARATION_REQUIRED lorsqu'un compte contient encore des campagnes sans déclaration. La version 26 assouplit cette règle : le champ devient facultatif pour les campagnes qui ne ciblent pas positivement l'UE.

Le déclarer explicitement coûte une ligne et maintient le code de création de campagnes valide d'une version à l'autre :

campaign.contains_eu_political_advertising = (
    client.enums.EuPoliticalAdvertisingStatusEnum.DOES_NOT_CONTAIN_EU_POLITICAL_ADVERTISING
)

Ce qui reste valable du guide de juin

L'essentiel du pas-à-pas précédent concerne le travail avec l'API plutôt que l'accès à celle-ci, et cette partie a bien vieilli. Les requêtes de lecture GAQL, le modèle validate_only pour tester les opérations d'écriture en toute sécurité, la gestion explicite de update_mask et la séparation entre compte Manager, projet Cloud et compte cible s'appliquent tels que décrits. Ce qui ne s'applique plus, c'est le chemin d'accès : l'API Center, la demande de Developer Token et le schéma d'architecture fondé sur le token.

Une bonne intégration – script interne ou outil destiné aux clients – traite l'accès comme une configuration relevant d'un projet Cloud clairement identifié. C'était une pratique judicieuse avant septembre 2026. Depuis, c'est la manière dont Google définit l'accès en premier lieu.