En bref: Il reste quatre semaines. La Content API for Shopping v2.1 s’éteint le 18 août 2026 et il n’y aura pas de sursis. Voici le compte à rebours : un grep pour repérer chaque intégration condamnée, les traitements qui touchent au chiffre d’affaires à migrer d’abord, les opérations de lecture ensuite, puis une exécution en parallèle pour désactiver toi-même l’ancienne intégration avant que Google le fasse à ta place.
Le rappel a sonné ce matin. Je l’avais programmé le jour où j’ai écrit sur la fermeture de la Content API, exactement quatre semaines avant l’échéance. Le 18 août 2026, Google éteint la Content API for Shopping v2.1 pour de bon. Quatre semaines, c’est assez pour migrer calmement. C’est aussi assez pour te convaincre que tu le feras la semaine prochaine, quatre fois de suite.
J’ai déjà expliqué ce qui casse et pourquoi la Merchant API est le meilleur outil dans l’article précédent. Je ne vais pas me répéter. Voici le plan que je déroule à l’approche d’une échéance non négociable. Une semaine par phase.
Cette semaine, trouve tout ce qui va mourir
Tu ne peux pas migrer ce que tu n’as pas trouvé. Lance ceci sur chaque dépôt qui touche au Merchant Center :
grep -rEn \
"shoppingcontent\.googleapis\.com|ShoppingContent|content/v2(\.1)?([^[:alnum:]_.-]|$)|[\"']content[\"'][,[:space:]]+[\"']v2(\.1)?[\"']|\.content\([\"']v2(\.1)?[\"']" .Le premier motif repère les appels REST directs. Les autres repèrent les bibliothèques clientes officielles, parce qu’elles te cachent l’URL. Python construit le client condamné avec build('content', 'v2.1'), PHP l’appelle Google_Service_ShoppingContent, Node utilise google.content('v2.1'), et les projets Apps Script chargent un service avancé ShoppingContent qui n’apparaît dans aucun dépôt. Vérifie tes projets de scripts à la main.
Ensuite, consigne chaque résultat dans un tableau à quatre colonnes : ce que fait l’intégration, sa fréquence d’exécution, son responsable et le délai avant que quelqu’un remarque une panne silencieuse. C’est la dernière colonne qui sert au tri.
Ton grep ne couvre que le code que tu as écrit. Les scénarios Zapier, les outils de flux, les outils de tarification automatique et les connecteurs peuvent aussi reposer sur l’ancienne API. Écris cette semaine à chaque prestataire et demande-lui de confirmer par écrit sa date de migration vers la Merchant API. Son échéance de migration, c’est la date de ta panne.
Deuxième semaine : migre les traitements critiques pour le chiffre d’affaires
Commence là où le silence coûte du chiffre d’affaires : mises à jour de prix et de stock, envois de flux. Dans la Merchant API v1, disponible pour tous depuis juillet 2025, ces opérations relèvent des sous-API products, inventories et datasources. Le guide de compatibilité indique, pour chaque ancien appel, son équivalent.
Une chose m’a agréablement surpris quand nous avons redirigé nos propres outils vers les nouveaux endpoints chez Lynt. Le token OAuth existant avec l’ancien scope content a fonctionné tel quel. Les autorisations restent valables, pas le code. Tu réécris les appels et tu évites de refaire toute la procédure d’autorisation avec chaque client.
Troisième semaine : migre les opérations de lecture
Les contrôles de refus et le reporting migrent ensuite. C’est aussi la semaine où la migration commence à te rembourser. La pagination des rapports passe à 1 000 lignes au lieu de 250, si bien que le même traitement se termine en un quart des appels. Et là où ton ancien code interrogeait les statuts des produits à intervalles réguliers, la sous-API notifications t’envoie directement les changements.
Quatrième semaine : désactive toi-même l’ancienne intégration
Fais tourner les deux pipelines en parallèle et compare les sorties pendant quelques jours. Puis coupe délibérément l’ancienne intégration environ une semaine à l’avance, pendant que la v2.1 répond encore. Si un élément oublié en dépend toujours, le problème remonte alors que tu peux encore rétablir les anciens appels pendant une journée et le corriger proprement.
Après le 18 août, il n’y a pas de retour en arrière. Google bascule l’interrupteur pour tout le monde en même temps, et ce que le grep n’a pas trouvé meurt en production.
Douze ans sur la Google Ads API m’ont appris que les échéances non négociables sont rares. Google prolonge, maintient l’existant, reporte. Pas cette fois. Alors lance le grep avant de fermer cet onglet. Le nombre qu’il affiche est la seule estimation de l’effort de migration dont tu as besoin.
