Ce qui a changé cette année dans les API de Google — et exactement quoi faire

Toute l’année en une phrase

Deux dates couperets vont casser votre stack si vous les ignorez — Content API for Shopping s’arrête le 18 août 2026, et les Dynamic Search Ads basculent automatiquement vers AI Max en septembre 2026 — et un troisième changement, le nouveau rythme de releases mensuel, fait discrètement vieillir votre version d’API plus vite qu’avant. Tout le reste que Google a livré cette année est une opportunité, pas une obligation. Cet article traite chaque changement de la même façon : ce qui a changé, pourquoi c’est important pour votre compte, et l’appel, le payload ou la migration exacte à lancer — par ordre de priorité, l’échéance la plus dure d’abord.

Je ne vais rien laisser à l’état de « vous devriez migrer ». À chaque étape, il y a l’artefact concret — l’endpoint qui remplace l’ancien, le payload d’expérimentation, la requête GAQL — pour que vous voyiez exactement quoi construire avant l’arrivée de la date.

Un mot sur la raison pour laquelle tout cela compte. Pendant des années, les API Google Ads et Merchant étaient une surface lente que l’on pouvait toucher une fois par an. C’est fini. La plateforme livre désormais tous les mois, deux de ses plus grandes surfaces sont en train d’être éteintes, et le contrôle que vous teniez à la main passe aux modèles. Les comptes qui s’en sortent en tête sont ceux qui ont traité cette année comme un projet de migration, pas de maintenance.

Échéance n°1 — Content API for Shopping → Merchant API (18 août 2026)

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

Ce qui a changé. Content API for Shopping v2.1 s’arrête le 18 août 2026. Son successeur, Merchant API v1, est passé en GA en juillet 2025, et l’intermédiaire v1beta a déjà été arrêté le 28 février 2026. L’ancien monolithe est remplacé par des sous-API ciblées — datasources, products, inventories, reports, notifications.

Pourquoi c’est important pour votre compte. Tout ce qui touche votre flux via l’ancienne API cesse de fonctionner à cette date : envois de flux, flux supplémentaires, custom labels, mises à jour de prix et de stock, lectures de refus. Pas « agréable à migrer » — un arrêt sec. Si un script quotidien tient vos prix synchronisés, il devient muet le 18 août et votre flux dérive lentement jusqu’à ce que quelqu’un remarque le chiffre d’affaires perdu.

Quoi faire. Reconstruisez sur la structure en sous-API. La forme de 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 pour l’appel le plus courant, un upsert de 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 '{ "channel": "ONLINE", "offerId": "SKU-123", "contentLanguage": "en", "feedLabel": "US",
        "attributes": { "title": "...", "price": {"amountMicros":"19900000","currencyCode":"EUR"} } }'

(Les hôtes d’endpoint et le découpage en sous-API viennent de la doc Google ; vérifiez le corps exact de la requête pour votre ressource dans la référence Merchant API avant de livrer — les noms de champs ont changé, pas seulement l’URL.)

La destination est franchement meilleure que ce qu’elle remplace, et c’est la partie que personne ne vous dit. Trois améliorations que vous héritez gratuitement en migrant :

Si vous comptiez durcir votre outillage de flux, l’arrêt est le déclencheur : reconstruisez une bonne fois, et sortez-en avec une gestion d’erreurs plus propre et moins d’allers-retours que la v2.1 ne l’a jamais permis.

Échéance n°2 — Dynamic Search Ads → AI Max (sep. 2026)

Le deuxième changement daté, et celui qui redéfinit la part de contrôle que vous gardez.

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 toutes les DSA restantes, les composants créés automatiquement et la requête large au niveau campagne vers AI Max. Après cela, vous ne pouvez plus créer de nouvelle campagne DSA — ni dans l’interface, ni dans l’Editor, ni via l’API.

Pourquoi c’est important pour votre compte. L’échange, c’est du contrôle contre du gain. Avec l’ensemble des fonctionnalités — matching de 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 au seul matching de requêtes. En retour, vous confiez au modèle le matching, le texte des composants et le choix de l’URL de destination. Si vous avez des règles de marque ou de conformité câblées à la main dans votre montage DSA, une bascule silencieuse en septembre peut discrètement commencer à envoyer du trafic vers des URL et des textes que vous n’avez pas validés.

Quoi faire. N’attendez pas de découvrir ce que la bascule fait à vos chiffres — mesurez-la dès maintenant. Google a livré les garde-fous et les points de mesure via l’API au rythme de la fonctionnalité, vous pouvez donc tester la bascule en A/B sur vos propres données avant qu’elle ne devienne obligatoire :

Le geste pratique, c’est le dernier : créez une expérimentation ADOPT_AI_MAX sur l’ensemble des comptes, laissez-la tourner, puis lisez le vrai écart avec une requête GAQL classique — au lieu de le découvrir une fois la bascule irréversible :

-- After ADOPT_AI_MAX runs: read the keywordless match, then the trial delta
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érimentation livrés en v24.1 ; targeting_expansion_view est la ressource de reporting de la v22. Vérifiez la disponibilité des champs dans les release notes pour la version que vous appelez.)

Échéance n°3 (continue) — releases mensuelles, durée de vie plus courte

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 à un rythme de releases mensuel : quatre versions majeures par an plus des versions mineures mensuelles, avec un an de support par version majeure.

Pourquoi c’est important pour votre compte. Un accès plus rapide aux fonctionnalités, et une obsolescence plus rapide. Les versions vieillissent 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 ; rater l’arrêt d’une majeure signifie que vos scripts commencent à renvoyer des erreurs sans autre avertissement qu’une date dans un calendrier que vous ne surveilliez pas.

Quoi faire. Épinglez votre version et surveillez le calendrier d’arrêt. L’assurance la moins chère, c’est une vérification récurrente qui sait quelle version vous appelez et alerte ~60 jours avant son expiration — l’API renvoie même la version de la requête, donc la vérification 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"}  # from 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 dû à une version arrêtée est une panne que vous vous infligez vous-même. Traitez la gouvernance des versions comme une tâche récurrente permanente, pas comme un exercice d’urgence.

Maintenant le bonus — l’IA entre dans le créatif et le flux

Une fois les échéances gérées, le reste de l’année est un levier que vous adoptez à votre propre rythme. Deux services ont transformé le travail sur les composants et les 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’image par IA, avec amélioration et extraction d’image pour PMax ; la v23.2 a ajouté VideoEnhancement pour la vidéo générée par Google. La génération créative sort de l’interface pour passer dans une couche programmable.
• Product Studio — Merchant API, en alpha depuis avril 2025 : titres et descriptions de produits générés par IA, plus AutomatedDiscounts pour le pricing en temps réel. La qualité du flux est le plafond de la performance Shopping et PMax, donc réécrire les titres au niveau de l’API revient à améliorer en masse des milliers de SKU sans travail manuel.

Le pipeline concret que cela débloque : lire un SKU dans le flux → générer un titre/une description conformes et des composants image → les pousser directement dans le groupe de composants, sans étape Canva manuelle au milieu. Les deux services sont pré-GA — traitez-les comme un pilote sur une tranche du catalogue, pas comme un déploiement à l’échelle du catalogue, jusqu’à ce qu’ils sortent.

Et la tuyauterie — Ads et Merchant au même endroit

Le changement le plus sous-estimé de l’année est le moins glamour : les deux moitiés d’un compte e-commerce se rejoignent enfin.

Ce qui a changé. Depuis le 22 avril 2026, la Merchant API est accessible depuis les Google Ads Scripts. Combinée à product_filters (partage conditionnel de 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 c’est important pour votre compte. L’ancienne séparation — campagnes dans les Scripts, flux géré ailleurs — faisait qu’un produit refusé continuait de brûler du budget jusqu’à ce qu’un humain le remarque. Désormais, un seul script peut réagir au refus d’un flux en mettant une campagne en pause ou en retirant le SKU d’un listing group PMax. Et CartDataSalesView amène la segmentation des conversions au niveau produit dans l’API, vous obtenez donc un ROAS au SKU sans raccorder manuellement les données de campagne au flux :

-- Product-level ROAS straight from the API (v24+), no manual feed stitching
SELECT segments.product_item_id,
       metrics.conversions_value,
       metrics.cost_micros
FROM cart_data_sales_view
WHERE segments.date DURING LAST_30_DAYS
ORDER BY metrics.conversions_value DESC

Cette seule requête est l’entrée d’un tiering de rentabilité que vous reconstruisiez à la main chaque mois. (La ressource est cart_data_sales_view, livrée en v24 ; vérifiez la disponibilité des segments dans les release notes de votre version.)

Toute l’année sur une seule frise chronologique

Chaque version majeure ci-dessous vient des release notes officielles ; les jalons Merchant des dernières mises à jour de la Merchant API. La colonne de droite est la seule qui doit piloter votre calendrier — tout ce qui est daté est non négociable.

[HARD Aug 18] 1. Feed migration → off v2.1, onto Merchant sub-APIs
[HARD Sep]    2. DSA inventory → run ADOPT_AI_MAX A/B first
[ROLLING]     3. Version watch → alert 60 days pre-sunset
[upside]      4. Asset pipeline → AssetGenerationService / Product Studio
[upside]      5. SKU ROAS → cart_data_sales_view tiering
[upside]      6. Closed loop → Merchant-in-Scripts: disapproval → pause

FAQ