Si tu pilotes Google Ads avec des scripts, un outil maison, un connecteur, ou des jobs d’optimisation qui tournent la nuit, il y a un nouveau genre d’incident qui peut te tomber dessus sans prévenir. Pas une panne réseau. Pas un changement de quota. Juste une campagne qui n’a pas la bonne déclaration « EU political ads »… et d’un coup, tes mutations (create/update) via Google Ads API ou Google Ads Scripts se mettent à échouer.
Le plus vicieux, c’est le côté « tout allait bien hier ». Et le côté « reporting OK ». Tu continues à lire les stats, mais tu ne peux plus pousser de changements. Donc tu peux rester aveugle pendant quelques heures, et te réveiller avec un compte qui n’a pas appliqué ses règles, pas mis à jour ses budgets, pas synchronisé son feed, pas déployé ses pauses. Bref, du SEA en mode manuel forcé.
Ce qui change au 1er avril 2026 : une campagne manquante, et tes mutate tombent
Google impose une déclaration sur le caractère « EU political ads » des campagnes. D’après les infos qui circulent côté annonceurs, la date à retenir est la fin mars 2026 pour déclarer, et à partir du 1er avril 2026, Google durcit l’exécution côté API/Scripts.
Le point important côté dev, c’est le comportement d’échec : si le compte contient au moins une campagne sans déclaration, alors les opérations de type mutate (créer, mettre à jour, etc.) peuvent échouer avec une erreur explicite du style MutateError.EU_POLITICAL_ADVERTISING_DECLARATION_REQUIRED. Et non, ce n’est pas « juste la campagne concernée ». L’effet peut être bien plus large selon ce que tu touches et comment ton automation est construite.
Autre détail qui piège : la partie lecture ne fait pas forcément la gueule. Tu peux continuer à requêter des rapports, à faire du planning, à exporter des stats. Donc ton monitoring « ça répond, tout va bien » peut passer à côté. C’est précisément le genre de demi-panne qui fait perdre du temps.
Sponsorisé par Le Scribouillard
Besoin de contenu optimisé SEO ?
Utilisez la meilleure plateforme française de création de contenu assistée par IA ! Et générez des articles pour moins de 1€ !
La déclaration « EU political ads » : compte, multi-campagnes, campagne
Google laisse plusieurs niveaux de déclaration, et c’est à la fois pratique et dangereux. Pratique parce que tu peux régler ça en une fois si ton compte n’a rien à voir avec du politique. Dangereux parce que tu peux te retrouver avec un mix de cas, des overrides, et une campagne oubliée planquée dans un coin.
Ce que je retiens surtout : un « Non » au niveau compte a vocation à s’appliquer largement, y compris aux futures campagnes, mais tu peux avoir des exceptions. Et si une campagne se retrouve dans un état « pas déclaré » (ou pas au bon niveau), tu peux déclencher le comportement qui casse les mutations. Donc, même si ton business n’a rien de politique, tu dois traiter ça comme une exigence de conformité technique, pas comme un sujet « légal » lointain.
Si tu gères plusieurs comptes (MCC) ou plusieurs marques, c’est encore plus vrai : il suffit d’un compte un peu oublié, d’un stagiaire qui a cloné une campagne, d’un import qui a créé des brouillons, et tu viens d’introduire une bombe à retardement pour tous tes jobs.
Le scénario catastrophe côté dev : le job nocturne tourne… et ne pousse plus rien
Le crash typique, je l’ai déjà vu sous d’autres formes (consentement, policy, champs devenus obligatoires) : ton cron lance 10 000 updates d’enchères, ou met à jour des ads, ou active des mots-clés. Tu récupères une exception. Sauf que ton code est « optimiste » et continue, ou au contraire stoppe tout au premier échec. Dans les deux cas tu perds.
Le stop immédiat est brutal mais au moins visible. Le mode dégradé silencieux est pire : tu loggues l’erreur mais tu ne pagines personne, tu as un dashboard « spend OK », et tu t’aperçois deux jours après que les promotions n’ont pas été poussées, que les budgets n’ont pas bougé, ou que tes exclusions n’ont jamais été appliquées. Et pendant ce temps, la prod SEA brûle de l’argent comme si de rien n’était.
Ce qui rend ce cas particulier, c’est que l’erreur est prédictible et détectable avant que ça casse. Donc si tu la subis en prod, c’est surtout un problème d’hygiène d’automation.
Audit avant la deadline : ce que je vérifie (sans me raconter d’histoires)
Première chose : je ne pars pas du principe que « personne chez nous ne fait du politique ». Je pars du principe que Google veut un état explicite, et que mon code dépend de cet état. Donc je cherche où la déclaration est visible dans l’interface Google Ads (Google a commencé à prévenir par email et via des prompts), et je valide qu’elle est bien positionnée pour tout ce qui existe déjà.
Ensuite, je regarde les zones qui créent des campagnes ou les dupliquent. Les scripts de lancement, les imports (templates), les outils tiers, les features « clone campaign », les opérations de masse. Si tu as un flux qui génère des campagnes à la volée (par exemple par géo, par catégorie, par stock), c’est là que tu peux introduire une campagne « non déclarée » sans t’en rendre compte. Et cette seule campagne peut suffire à transformer ton automation en citrouille.
Enfin, je fais un test très terre-à-terre sur un compte de staging ou un compte peu critique : je déclenche une mutation volontaire (un update simple) et je vérifie le comportement en cas d’erreur. L’objectif n’est pas de « voir si ça marche aujourd’hui ». L’objectif est de valider que, le jour où ça casse, je sais exactement comment ça casse, où ça se loggue, et qui est alerté.
Garde-fous dans le code : ne laisse pas une policy casser toute ta prod
Mon approche, c’est de traiter ce genre de règle comme un feature flag de compliance. Tu ne peux pas empêcher Google de rajouter des champs obligatoires, mais tu peux empêcher ton automation de se comporter comme un château de cartes.
Déjà, je veux un traitement d’erreur explicite sur cette erreur précise. Pas un catch générique « API error ». Si tu vois EU_POLITICAL_ADVERTISING_DECLARATION_REQUIRED, tu dois arrêter de croire que « ça va passer au retry ». Non, ça ne passera pas tant que l’état de déclaration n’est pas corrigé.
Ensuite, je veux un mode dégradé intelligent. Typiquement, je préfère couper les mutate du compte en question, remonter une alerte, et continuer les autres comptes. Et je garde le reporting en marche pour diagnostiquer. L’objectif est d’éviter l’effet domino où un seul compte bloque un batch multi-comptes.
# Exemple (Python) : détecter l'erreur Google Ads API côté mutate et escalader proprement
from google.ads.googleads.errors import GoogleAdsException
def handle_google_ads_mutate(client, request):
try:
return client.get_service("GoogleAdsService").search(request=request)
except GoogleAdsException as ex:
# ex.failure.errors contient les codes précis
for err in ex.failure.errors:
code = err.error_code
if code.mutate_error == code.MutateError.EU_POLITICAL_ADVERTISING_DECLARATION_REQUIRED:
raise RuntimeError(
"EU political ads declaration manquante: bloque les mutate. "
"Corrige la déclaration côté Google Ads avant de relancer."
) from ex
raise
Je ne montre pas ici le champ exact à requêter pour « lister les campagnes sans déclaration », parce que les noms de champs et leur disponibilité varient selon versions et ressources. Mais l’idée est simple : tu ajoutes un pré-check (en lecture) dans ton pipeline. Si ton pré-check détecte un état « non déclaré », tu arrêtes avant de lancer 50 000 opérations, tu ouvres un incident, et tu forces une correction manuelle côté interface.
Monitoring : alerte sur l’erreur, pas sur « le job a échoué »
Le monitoring utile ici n’est pas « nombre d’exceptions ». Il est beaucoup plus ciblé : présence de l’erreur EU_POLITICAL_ADVERTISING_DECLARATION_REQUIRED dans les logs, associée au customer ID. Parce que c’est une erreur binaire. Tant qu’elle est là, tu es bloqué. Quand elle disparaît, tu peux reprendre.
Si tu as un SIEM ou un Datadog/Stackdriver/Sentry, tu peux faire une alerte immédiate dès le premier hit, et une seconde alerte si l’erreur persiste au-delà d’une heure. C’est un bon compromis : tu évites le spam et tu évites l’incident qui pourrit toute la journée.
Et oui, je recommande aussi un garde-fou produit : un « runbook » court qui explique où aller dans Google Ads pour faire la déclaration, qui a le droit de le faire, et comment valider que c’est revenu. Le jour J, tu ne veux pas dépendre d’une seule personne qui « sait où cliquer ».
Remédiation express quand c’est déjà cassé
Quand tu es déjà dans le mur, l’ordre des opérations est important. Tu commences par confirmer que tu es bien sur ce cas, donc tu identifies l’erreur exacte côté logs et tu récupères le customer ID concerné. Ensuite tu vas dans l’interface Google Ads et tu cherches la demande de déclaration (Google a communiqué sur la déclaration au niveau compte, multi-campagnes ou campagne). Tu fais le choix le plus global qui colle à la réalité du compte, et tu évites de « patcher campagne par campagne » si tu sais très bien que le compte n’a rien à voir avec du politique.
Une fois corrigé, ne te contente pas de relancer le gros batch. Relance un test minimal de mutation sur une entité sans enjeu, juste pour valider que l’API est redevenue opérante. Puis seulement tu remets en route tes automations normales. C’est basique, mais ça évite la panique et les doubles incidents.
Mon avis : ce n’est pas un détail « SEA », c’est de la fiabilité logicielle
Si tu automatises Google Ads, tu n’es plus « juste » en train de gérer des campagnes. Tu opères un système externe qui change ses règles. Donc tu dois avoir les réflexes SRE minimum : pré-checks, erreurs typées, isolation par compte, alerting sur erreurs métier, et un plan de remédiation qui tient en 5 minutes.
La déclaration « EU political ads » ressemble à un sujet compliance, et c’en est un. Mais l’impact est purement technique : si tu l’ignores, tu te fabriques un incident. Et ça, ça se traite comme n’importe quel point de fragilité dans une intégration API.
