Un an d'API Google Ads : 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 contre cette API, et pendant la majeure partie de cette période, c’était une surface lente qu’on visitait une fois par an, on montait le numéro de version et on oubliait.

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 se cache juste derrière. En septembre 2026, chaque campagne Dynamic Search Ads restante bascule automatiquement vers AI Max, que tu le veuilles ou non.

Ces deux horloges sont les obligations de l’année API de Google. Tout le reste de ce que la plateforme a livré est une opportunité. Des services d’IA pour la création, du reporting des ventes au niveau produit, la 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 complé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 dérive 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 contre la 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 body 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 destination est franchement meilleure que ce qu’elle remplace, et c’est la partie que personne ne te dit. Trois améliorations que tu hérites gratuitement en migrant :

Si tu voulais depuis longtemps durcir ton outillage de flux, l’arrêt est le déclencheur qu’il te fallait. 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 septembre 2026

Le deuxième changement daté, et celui qui 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. À partir de septembre 2026, Google bascule automatiquement vers AI Max toutes les DSA restantes, les assets créés automatiquement et la requête large au niveau campagne. 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. Le marché, c’est du contrôle contre du gain. Avec l’ensemble complet des fonctionnalités (matching des termes de recherche plus personnalisation du texte plus expansion de l’URL finale), Google rapporte environ +7 % de conversions ou de valeur de conversion par rapport au matching seul. En échange, tu confies au modèle le matching, le texte des assets et le choix de la page de destination. Si tu as des règles de marque ou de conformité montées à la main dans ton setup DSA, une bascule silencieuse en septembre peut commencer à envoyer du trafic vers des URL et des textes que tu n’as jamais validé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 crochets 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 le dernier. Crée une expérience ADOPT_AI_MAX 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 le contrôle. Un simple pull GAQL te montre ensuite ce que l’expansion sans mots-clés a réellement matché et rapporté :

-- 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 la disponibilité des champs dans les release notes de 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), l’API Google Ads 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. Un bump mineur mensuel ne casse rien. Rater le sunset 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 sunsets. 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. 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 un exercice incendie.

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 est un levier que tu adoptes à ton propre rythme. Deux services ont transformé le travail sur les assets 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.

La moitié flux, je la prends personnellement. Chez Lynt, nous avons passé deux ans à construire Boostera, 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 déplacent 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 assets image conformes, puis les pousse directement dans le groupe d’assets, 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. Combinée à product_filters (partage conditionnel du flux avec Google Ads, livré en novembre 2025) et à CartDataSalesView (v24), la boucle entre la santé du flux et la dépense publicitaire se referme dans un seul environnement.

Pourquoi ça concerne ton compte. L’ancienne séparation, campagnes dans Scripts et flux géré ailleurs, faisait qu’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 porte 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 l’entrée d’un tiering de rentabilité que tu reconstruisais à la main chaque mois. Nous faisons du reporting business au niveau client dans BigQuery pour nos clients, et la moitié du travail a toujours été de coudre les données publicitaires aux données produit. La couture vit désormais dans deux appels API au lieu d’un export de flux, et tu peux la valider. Vérifie que les item ID correspondent des deux côtés avant de te fier au ratio. (La ressource est cart_data_sales_view, livrée en v24 ; vérifie la disponibilité des segments dans les release notes de ta version.)

L’année sur une seule frise

Chaque version majeure ci-dessous vient des release notes officielles ; les jalons Merchant, des Merchant API latest updates. La colonne de droite est la seule qui devrait piloter ton calendrier. Tout ce qui est marqué FERME 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 est ton exposition au 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 septembre 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 encore ton choix.

FAQ