Un an avec la Google Ads API : deux échéances fermes, le reste est une opportunité

En janvier, Google a publié la v23 de l’Ads API et annoncé qu’à partir de là, une nouvelle version sortirait chaque mois. J’ai relu la note deux fois. Ça fait douze ans que j’écris du code qui appelle cette API, et pendant la majeure partie de cette période, elle changeait assez lentement pour qu’on puisse y passer une fois par an, monter le numéro de version et ne plus y penser.

Puis j’ai fait ce que ces années m’ont appris à faire. J’ai ouvert notre code chez Lynt et cherché shoppingcontent.googleapis.com. Chaque résultat est un script qui meurt le 18 août 2026, le jour où la Content API for Shopping s’éteint. Une deuxième date arrive juste derrière, et Google l’a déjà repoussée : à partir de février 2027, chaque campagne Dynamic Search Ads restante bascule automatiquement vers AI Max, que tu le veuilles ou non. En septembre 2026, les campagnes utilisant des composants créés automatiquement et la requête large au niveau campagne passent en premier.

Ces deux dates sont les obligations que Google t’impose cette année. Tout le reste de ce que la plateforme a livré est une opportunité : services d’IA pour la création, reporting des ventes au niveau produit, Merchant API dans Google Ads Scripts. Je vais donc parcourir l’année par ordre de priorité, l’échéance la plus dure d’abord. Pour chaque changement : ce que c’est, pourquoi ça concerne ton compte, et l’appel, le payload ou la migration exacte à lancer.

Je ne laisserai rien au stade du « tu devrais migrer ». Une échéance sans artefact concret, c’est juste de l’anxiété. À chaque étape, tu as l’endpoint qui remplace l’ancien, le payload de l’expérience ou la requête GAQL, pour voir exactement quoi construire avant que la date n’arrive.

Échéance numéro un : la Content API for Shopping meurt le 18 août 2026

C’est la date la plus dure de l’année, donc elle passe en premier.

Ce qui a changé. La Content API for Shopping v2.1 s’éteint le 18 août 2026. Sa remplaçante, la Merchant API v1, est passée en GA en juillet 2025, et l’intermédiaire v1beta s’est déjà éteinte le 28 février 2026. Le vieux monolithe est remplacé par des sous-API ciblées. datasources, products, inventories, reports, notifications.

Pourquoi ça concerne ton compte. Tout ce qui touche ton flux via l’ancienne API cesse de fonctionner ce jour-là. Envois de flux, flux supplémentaires, libellés personnalisés, mises à jour de prix et de stock, lecture des refus. Ce n’est pas un « ce serait bien de migrer », c’est une coupure ferme. Si un script quotidien synchronise tes prix, il se tait le 18 août et ton flux s’éloigne lentement de la réalité jusqu’à ce que quelqu’un remarque le chiffre d’affaires perdu. J’ai vu ce mode de défaillance sur de vrais comptes, et ce qui coûte cher n’est jamais la panne elle-même, ce sont les semaines où personne ne la remarque.

Quoi faire. Reconstruis ton intégration pour la nouvelle structure en sous-API. La migration est mécanique. L’hôte, le chemin et le modèle de ressources changent, l’intention reste la même. Voici l’avant-après de l’appel le plus courant de tous, l’upsert d’un produit :

# OLD: Content API for Shopping v2.1 (off on 2026-08-18)
curl -X POST \
  "https://shoppingcontent.googleapis.com/content/v2.1/{merchantId}/products" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{ "offerId": "SKU-123", "title": "...", "price": {"value":"19.90","currency":"EUR"} }'

# NEW: Merchant API v1 (productInputs sub-API)
curl -X POST \
  "https://merchantapi.googleapis.com/products/v1/accounts/{account}/productInputs:insert?dataSource=accounts/{account}/dataSources/{ds}" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{ "offerId": "SKU-123", "contentLanguage": "en", "feedLabel": "US",
        "productAttributes": { "title": "...", "price": {"amountMicros":"19900000","currencyCode":"EUR"} } }'

(Les hôtes des endpoints et le découpage en sous-API viennent de la doc de Google. Vérifie le corps exact de la requête pour ta ressource dans la référence de la Merchant API avant de déployer, car ce sont les noms de champs qui ont changé, pas seulement l’URL.)

La Merchant API v1 est une meilleure API que la Content API qu’elle remplace, et c’est ce que personne ne te dit. Trois améliorations dont tu hérites gratuitement en migrant :

Si tu voulais depuis longtemps durcir ton outillage de flux, l’arrêt est ce qui va enfin t’y forcer. Reconstruis une fois, et ressors avec une gestion d’erreurs plus propre et moins d’allers-retours que la v2.1 n’en a jamais permis.

Échéance numéro deux : les Dynamic Search Ads deviennent AI Max en février 2027

C’est le deuxième changement à date fixe, et il redistribue la part de contrôle que tu gardes.

Ce qui a changé. AI Max for Search est passé en GA le 15 avril 2026 après un lancement en bêta en mai 2025. Le déploiement se fait en deux temps : à partir de septembre 2026, Google fait basculer automatiquement vers AI Max les campagnes utilisant des composants créés automatiquement et la requête large au niveau campagne ; la fin des DSA et leur migration automatique commencent quant à elles en février 2027, après avoir été repoussées par rapport à la date de septembre annoncée initialement par Google. Après ça, tu ne peux plus créer de campagne DSA. Ni dans l’interface, ni dans Editor, ni via l’API.

Pourquoi ça concerne ton compte. Tu échanges du contrôle contre du gain. Avec l’ensemble complet des fonctionnalités (mise en correspondance des requêtes plus personnalisation du texte plus expansion de l’URL finale), Google rapporte environ +7 % de conversions ou de valeur de conversion par rapport à la seule mise en correspondance des requêtes. En échange, tu confies au modèle la mise en correspondance, le texte des composants et le choix de la page de destination. Si tu as des règles de marque ou de conformité montées à la main dans ta configuration DSA, une bascule automatique silencieuse peut commencer à envoyer du trafic vers des URL que tu n’as jamais validées, avec des textes d’annonce que tu n’as jamais approuvés. Une automatisation que tu n’as pas mesurée est une automatisation que tu ne contrôles pas.

Quoi faire. N’attends pas de découvrir ce que la bascule fait à tes chiffres. Mesure-le maintenant. Google a livré les garde-fous et les points de mesure via l’API en même temps que la fonctionnalité, tu peux donc tester le basculement en A/B sur tes propres données avant qu’il ne devienne obligatoire :

Le geste pratique, c’est l’expérience ADOPT_AI_MAX. Crée-la sur tes comptes et laisse-la tourner. Le delta de CPA et de ROAS, tu le lis en comparant les campagnes du bras d’expérience avec les campagnes de contrôle. Un simple pull GAQL te montre ensuite les requêtes que l’expansion sans mots clés a réellement retenues et les résultats qu’elles ont générés :

-- After ADOPT_AI_MAX runs: inspect automated expansion performance.
-- Calculate trial/control delta separately from the experiment arm campaigns.
SELECT campaign.name,
       metrics.conversions,
       metrics.conversions_value,
       metrics.cost_micros
FROM targeting_expansion_view
WHERE segments.date DURING LAST_30_DAYS

(ADOPT_AI_MAX est l’un des nouveaux types d’expérience livrés en v24.1 ; targeting_expansion_view est la ressource de reporting de la v22. Vérifie dans les notes de version que ces champs sont disponibles pour la version que tu appelles.)

L’échéance glissante : une version chaque mois

Pas une date unique, mais une horloge qui tourne désormais en permanence.

Ce qui a changé. Depuis la v23 (28 janvier 2026), la Google Ads API est passée à une cadence de publication mensuelle. Quatre versions majeures par an plus des versions mineures mensuelles, avec un an de support par version majeure.

Pourquoi ça concerne ton compte. Un accès plus rapide aux fonctionnalités, et une obsolescence plus rapide. Les versions expirent selon un calendrier publié. La v20 atteint sa fin de vie en juin 2026, la v21 en août, la v22 en octobre. Une montée de version mineure mensuelle ne casse rien. Laisser passer la date de fin de vie d’une version majeure, c’est voir tes scripts renvoyer des erreurs sans autre avertissement qu’une date dans un calendrier que tu ne regardais pas.

Quoi faire. Épingle ta version et surveille le calendrier des fins de vie. L’assurance la moins chère est un contrôle récurrent qui sait quelle version tu appelles et t’alerte environ 60 jours avant l’expiration de cette version. Le tout tient en quelques lignes :

# Recurring guardrail: alert ~60 days before your pinned version sunsets.
from datetime import date

PINNED = "v22"                 # the version your client is pinned to
SUNSET = {"v20": "2026-06-01", "v21": "2026-08-01", "v22": "2026-10-01"}  # sunset-dates page
sunset = SUNSET.get(PINNED)    # None until your version reaches the published calendar
if sunset and (date.fromisoformat(sunset) - date.today()).days < 60:
    alert(f"{PINNED} sunsets {sunset}; schedule the version bump")  # major bump needs a re-test

Un 404 renvoyé par une version expirée est une panne que tu t’es infligée toi-même. Traite la gouvernance de versions comme une tâche récurrente permanente, pas comme une urgence de dernière minute.

Maintenant le bonus : l’IA s’installe dans la création et le flux

Les échéances réglées, le reste de l’année avance au rythme que tu choisis. Deux services ont transformé le travail sur les composants et le flux en quelque chose de scriptable sur des milliers de SKU.

• AssetGenerationService (Ads API, v22, bêta fermée). Génération de texte et d’images par IA, avec amélioration et extraction d’images pour PMax ; la v23.2 a ajouté VideoEnhancement pour la vidéo générée par Google. La production créative quitte l’interface pour une couche programmable.
• Product Studio (Merchant API, alpha depuis avril 2025). Titres et descriptions de produits générés par IA, plus AutomatedDiscounts pour la tarification en temps réel. Réécrire les titres au niveau de l’API, c’est améliorer en masse des milliers de SKU sans travail manuel.

Le volet flux, lui, me tient particulièrement à cœur. Chez Lynt, nous avons passé deux ans à construire Boostora, une couche d’IA qui enrichit les flux Merchant Center, parce que la qualité du flux est le plafond de la performance Shopping et PMax. De meilleurs titres rapportent plus de chiffre d’affaires que la plupart des ajustements d’enchères. Product Studio amène une partie de cette capacité dans la plateforme elle-même.

Le pipeline que ça débloque lit un SKU dans le flux, génère un titre, une description et des composants image conformes, puis les pousse directement dans le groupe de composants, sans étape manuelle dans Canva au milieu. Les deux services sont en pré-GA. Traite-les comme un pilote sur une tranche du catalogue, pas comme un déploiement sur tout le catalogue, tant qu’ils n’ont pas atteint la GA.

La plomberie : Ads et Merchant enfin réunis

Le changement le plus sous-estimé de l’année n’a rien de glamour. Les deux moitiés d’un compte e-commerce se retrouvent au même endroit.

Ce qui a changé. Depuis le 22 avril 2026, la Merchant API est accessible depuis Google Ads Scripts. Ajoute à ça product_filters (partage conditionnel du flux avec Google Ads, livré en novembre 2025) et CartDataSalesView (v24), et la boucle qui va de l’état du flux à la dépense publicitaire se referme dans un seul environnement.

Pourquoi ça concerne ton compte. L’ancienne séparation gardait les campagnes dans Scripts et le flux ailleurs. Un produit refusé continuait de brûler du budget jusqu’à ce qu’un humain s’en aperçoive. Désormais, un seul script peut réagir à un refus dans le flux en mettant une campagne en pause ou en retirant le SKU d’un groupe de fiches PMax. Et CartDataSalesView amène dans l’API le chiffre d’affaires par SKU vendu, issu des données de panier. La vue contient le chiffre d’affaires, pas la dépense, donc un vrai ROAS par SKU demande deux requêtes. Commence par le côté revenus :

-- Revenue per sold SKU from cart data (v24+)
SELECT segments.product_item_id,
       metrics.revenue_micros,
       metrics.all_revenue_micros
FROM cart_data_sales_view
WHERE segments.date DURING LAST_30_DAYS
ORDER BY metrics.revenue_micros DESC

Récupère ensuite le côté coûts depuis shopping_performance_view et joins les deux résultats sur product_item_id :

-- Cost per advertised SKU; join to the revenue query on product_item_id
SELECT segments.product_item_id,
       metrics.cost_micros,
       metrics.conversions_value
FROM shopping_performance_view
WHERE segments.date DURING LAST_30_DAYS
ORDER BY metrics.cost_micros DESC

Ces lignes jointes sont la matière première des paliers de rentabilité que tu reconstruisais à la main chaque mois. Dans BigQuery, nous produisons du reporting business au niveau client pour les comptes que nous gérons, et la moitié du travail a toujours été de coudre les données publicitaires aux données produit. Deux appels API font désormais la couture qui demandait un export de flux, et tu peux en contrôler le résultat toi-même. Vérifie que les item ID correspondent dans les deux requêtes avant de te fier au ratio. (La ressource est cart_data_sales_view, livrée en v24 ; vérifie dans les notes de version que les segments sont disponibles pour la v24.)

L’année sur une seule frise

Chaque version majeure ci-dessous vient des notes de version officielles ; les jalons Merchant, des Merchant API latest updates. La colonne de droite est la seule qui devrait piloter ton calendrier. Chaque ligne qui porte le marqueur HARD est non négociable.

La première heure de travail

Pas toute la migration. Un grep. Cherche shoppingcontent.googleapis.com dans ton code et note chaque job qui remonte. Cette liste, c’est tout ce que tu risques le 18 août, et elle t’a pris dix minutes.

Consacre le reste de l’heure à créer une expérience ADOPT_AI_MAX sur le compte où les DSA comptent le plus, pour que la bascule arrive comme un changement mesuré et non comme une surprise. Les échéances appartiennent à Google. Qu’elles te frappent comme des pannes ou comme des mises à niveau, c’est toujours toi qui décides.

FAQ