Google Ads : le developer token n'existe plus

Publié le 20 septembre 2026 par l'équipe Oriva.

Google a changé deux choses en 2026 pour les conversions envoyées à Google Ads par API. Depuis le 15 juin, l'ancienne méthode d'import (UploadClickConversions) refuse les jetons qui n'avaient envoyé aucune conversion hors ligne entre le 17 décembre 2025 et le 15 juin 2026. Le 9 septembre, Google a supprimé les developer tokens : l'accès dépend maintenant du projet Google Cloud qui a servi à créer tes identifiants, et la restriction a suivi. Si tu montes un nouvel envoi de conversions depuis ton serveur, tu reçois donc l'erreur CUSTOMER_NOT_ALLOWLISTED_FOR_THIS_FEATURE. Google demande de passer à la Data Manager API, qui n'exige pas de developer token. Si tes conversions passent uniquement par le tag Google ou par Google Tag Manager, ce changement ne te concerne pas.

Qu'est-ce qui a changé exactement ?

Le 15 juin 2026 : les requêtes UploadClickConversions échouent pour les jetons qui n'avaient envoyé aucune conversion hors ligne, ni conversion améliorée pour les leads, entre le 17 décembre 2025 et le 15 juin 2026. L'erreur renvoyée est CUSTOMER_NOT_ALLOWLISTED_FOR_THIS_FEATURE. Google écrit : « Migrate your offline conversion workflows to the Data Manager API instead. » ;
Le 9 septembre 2026 : « Developer tokens are deprecated and have been sunset. » Ton niveau d'accès à l'API est désormais déterminé par le projet Google Cloud avec lequel tu as généré tes identifiants OAuth ;
La restriction n'a pas disparu avec le token. Google écrit que les developer tokens ont été remplacés par des projets Google Cloud, « but this historical access restriction remains in effect ».

17 décembre 2025
Début de la période observée
Un jeton qui n'envoie aucune conversion hors ligne pendant cette période sera restreint.
15 juin 2026
Début de la restriction
L'ancienne méthode d'import refuse les jetons restreints, avec l'erreur CUSTOMER_NOT_ALLOWLISTED_FOR_THIS_FEATURE.
9 septembre 2026
Fin des developer tokens
L'accès dépend du projet Google Cloud de tes identifiants OAuth, et la restriction reste en vigueur.
Aujourd'hui
Google demande de migrer
Vers la Data Manager API, qui n'exige pas de developer token.

Dates de la page des dépréciations de l'API Google Ads.

Est-ce que je suis touché ?

Oui, si :

tu envoies des conversions à Google Ads depuis ton serveur ou avec un outil, par la méthode UploadClickConversions, avec un gclid, un gbraid ou un wbraid ;
et ton projet Google Cloud (ou ton ancien token) n'avait envoyé aucune conversion de ce type entre le 17 décembre 2025 et le 15 juin 2026. C'est le cas de tout projet créé depuis.

Probablement pas, si :

ton envoi tournait déjà avant le 15 juin : Google ne restreint que les jetons sans envoi dans cette période ;
tes conversions passent par le tag Google ou par Google Tag Manager. Google ne parle que des envois par API.

La restriction vise les conversions par gclid, gbraid et wbraid, et les conversions améliorées pour les leads.

Comment vérifier ?

Cherche CUSTOMER_NOT_ALLOWLISTED_FOR_THIS_FEATURE dans les journaux de ton script, de ton outil ou de ton agence. C'est l'erreur que Google renvoie aux jetons restreints. Si tu ne l'as jamais vue et que tes conversions apparaissent dans Google Ads, tu n'as rien à faire aujourd'hui, mais Google demande quand même de migrer.

Que change la Data Manager API ?

	Google Ads API (ancienne méthode)	Data Manager API
Developer token	Obligatoire	Non requis
Erreurs	Échec partiel : les événements valides passent, les autres échouent	Échec immédiat : un événement invalide fait échouer toute la requête
Adresse IP et attributs de session	Réservés à certains utilisateurs de l'API	Disponibles pour tous
Compte cible	Le compte parent ou un compte enfant	Le compte qui possède l'action de conversion

Trois points pratiques, écrits par Google :

l'API doit être activée explicitement dans ton projet Google Cloud ;
la portée OAuth demandée est https://www.googleapis.com/auth/datamanager ;
l'accès au compte Google Ads passe par les droits d'utilisateur : tu ajoutes l'email du compte au compte Google Ads ou à son compte gestionnaire parent.

Génère donc ton refresh token pour cette portée, celle que demande la Data Manager API.

Attention à activer « Data Manager API » et non « Google Ads API » : c'est la première erreur probable.

Google propose aussi de valider une requête sans l'appliquer, avec validateOnly, et de dédupliquer par transactionId les conversions venues de sources différentes, comme ton tag et la Data Manager API.

Et si je garde mon tag Google ?

Tu n'as pas à choisir. Google écrit que, depuis avril 2026, Google Ads accepte les données fournies par l'utilisateur depuis les tags de site, la Data Manager et les connexions API, sans avoir à choisir entre ces méthodes.

Pour qu'une même vente ne soit pas comptée deux fois, donne la même référence de commande au tag (paramètre transaction_id) et à l'envoi serveur (transactionId) : sur une même action de conversion, Google reconnaît le doublon et ne compte pas le second. Sans identifiant, un rechargement de la page de confirmation peut compter la commande deux fois.

Quelle option choisir ?

	Rester sur l'ancienne méthode	Migrer toi-même vers la Data Manager API	Oriva	Tag Google seul
Fonctionne pour un projet neuf	Non	Oui	Oui	Oui
Developer token	Obligatoire	Non requis	Non requis	Sans objet
Prix	Gratuit	Ton temps de développement	79 €/mois (Starter)	Gratuit
Mise en place	Sans objet si refusée	Du code et une authentification OAuth	Un formulaire, mais OAuth à préparer	Une balise sur ton site
Vente confirmée par ton serveur	Oui, si l'accès existe	Oui	Oui, par l'API serveur	Non
Autres plateformes	Non	Non	Meta, TikTok, postback d'affiliation	Non
Preuve de chaque envoi	Selon ton code	Selon ton code	Journal de livraison	Rapports Google Ads

Comment Oriva envoie à Google Ads

l'envoi passe par la Data Manager API, sans developer token ;
Oriva transmet l'identifiant de clic Google (gclid, gbraid ou wbraid), l'email et le téléphone chiffrés quand tu les as, la valeur, la devise, et une référence de transaction unique ;
une destination Oriva = une action de conversion Google Ads. Si tu suis les leads et les achats, tu crées deux destinations ;
le bouton « Tester cette destination » demande à Google de vérifier la requête sans l'enregistrer : tes identifiants, ton accès au compte et le format sont contrôlés, rien n'est compté ;
sans l'accord du visiteur pour la publicité, Oriva n'envoie rien à Google Ads. Le statut de consentement (adUserData) part avec chaque événement envoyé.

La limite, dite franchement : c'est la mise en place la plus technique des destinations d'Oriva, parce que Google exige des identifiants OAuth. Il faut un projet Google Cloud avec la Data Manager API activée, un client OAuth et un refresh token. Le piège le plus fréquent : ne pas publier l'écran de consentement OAuth en production avant de générer le refresh token. Google écrit qu'un projet dont l'écran de consentement est de type externe et en mode « Testing » reçoit un refresh token qui expire au bout de 7 jours (sauf si les seules portées demandées sont le nom, l'email et le profil). Les envois s'arrêtent alors une semaine après l'installation.

Le guide pas à pas est sur la page Google Ads.

Qui n'a pas besoin d'Oriva ?

Tes conversions passent par le tag Google ou Google Tag Manager, et tu ne fais de la publicité que sur Google Ads. Le changement ne te concerne pas. Ajoute la référence de commande à ton tag et garde-le.
Tu as un développeur qui peut migrer ton envoi. Google décrit la migration, et c'est un changement de format plus qu'une réécriture. Oriva sert quand tu veux le même envoi vers Meta et TikTok, un journal de livraison, et la raison de chaque échec au même endroit.

Commencer l'essai gratuit