L’ancienne API marchande de Google est arrêtée : votre flux produit fonctionne-t-il encore ?

Un catalogue peut paraître intact dans Merchant Center et pourtant ne plus se mettre à jour correctement. Prix, disponibilité, titre d’un produit ou variante : la panne ne se voit pas toujours le jour où elle commence. Elle apparaît parfois lorsque les annonces Shopping et les fiches gratuites ne reflètent plus la boutique.

Le sujet dépasse le développement. Il pose la même question que toute prestation déléguée : ce qui reste sous la responsabilité du client dans une prestation déléguée. Le client ne programme pas l’API, mais il doit savoir qui surveille l’interface qui alimente son catalogue.

Google a déplacé le calendrier une première fois. La prudence consiste donc à contrôler la configuration réelle plutôt qu’à se fier à un ancien planning ou à une promesse d’agence. Vingt minutes suffisent pour repérer un risque et ouvrir le bon ticket.

Ce qui s’est arrêté, et depuis quand

La Content API for Shopping a atteint sa date de retrait le 18 août 2026. Depuis le 1er septembre, les requêtes non couvertes par une extension peuvent recevoir des erreurs HTTP 410 Gone de manière intermittente. Google annonce une désactivation complète des points d’accès au début de 2027, sous réserve de l’avancement de la migration dans l’écosystème.

Ce régime d’erreurs progressives brouille le diagnostic. Une relance peut réussir après un premier échec. Un connecteur peut donc continuer à envoyer une partie des produits tout en laissant certaines mises à jour de côté. Le flux produit n’est pas nécessairement « tombé ». Il devient moins fiable, ce qui est plus difficile à détecter.

La Merchant API ne remplace pas seulement une adresse technique. Google sépare désormais la donnée envoyée, ProductInput, du produit traité, Product. Les écritures exigent aussi une source de données explicitement indiquée. Ce changement oblige un module ou un développement sur mesure à revoir sa logique, pas seulement son identifiant de connexion.

Comment savoir en vingt minutes si vous êtes touché

La vérification peut être conduite par un responsable e-commerce sans lire une ligne de code. Elle nécessite en revanche l’accès à Merchant Center et une réponse précise de la personne qui maintient le flux. Gardez la trace de chaque réponse dans le ticket de maintenance.

• Repérez la source de données active dans Merchant Center. Une source nommée « Content API » indique qu’une partie du dispositif hérite encore de l’ancienne configuration.
• Demandez quel acteur émet les appels : plateforme, extension, connecteur PIM ou script maison. Le nom du projet Google Cloud et celui du module doivent apparaître dans la réponse.
• Faites contrôler les journaux depuis le 1er septembre. Le code HTTP 410 Gone ou la mention content_api_sunset confirme que des appels continuent vers l’ancien service.
• Choisissez cinq références modifiées récemment et comparez boutique, Merchant Center et statut du produit. Un écart de prix ou de stock mérite une investigation immédiate, même si les autres fiches semblent correctes.

Les trois symptômes qui ne préviennent pas

Le premier symptôme est une fiche qui conserve un ancien prix ou une disponibilité dépassée. Le deuxième est plus discret : les produits sont bien présents dans Merchant Center, mais leur état n’évolue plus après une modification du catalogue. Enfin, les diagnostics peuvent signaler des éléments en attente sans que personne ne les relie à l’interface arrêtée.

Ces indices ne prouvent pas à eux seuls une défaillance de migration. Ils justifient une vérification du flux produit avant d’attribuer la baisse de diffusion à la saisonnalité, à la concurrence ou aux campagnes.

Qui devait migrer : la plateforme, le module ou l’agence

La réponse dépend de la chaîne réelle. Si la boutique utilise l’intégration native d’une plateforme e-commerce, Google indique que le partenaire de plateforme gère la migration. Encore faut-il confirmer que l’intégration en place est bien celle du partenaire, et non un ancien module ajouté par une agence lors d’une refonte.

Le module d’export porte souvent le travail de migration quand il produit le flux ou appelle directement l’API. L’agence qui pilote Google Shopping doit, elle, détecter un problème de diffusion et le signaler. Le client reste le seul à pouvoir demander un responsable identifié, un calendrier et un test de reprise.

Le défaut classique tient à la répartition des tâches : chacun intervient sur un morceau, sans que personne ne détienne le suivi de l’ensemble. Cette difficulté existe aussi dans la chaîne d’outils d’une équipe marketing externalisée. Le contrat doit nommer le responsable de la veille et celui qui paie la correction lorsqu’une alerte n’a pas été traitée.

La clause de veille technique à ajouter au contrat de maintenance

Une clause utile ne demande pas à un prestataire de prévoir chaque évolution de Google. Elle précise ce qu’il surveille : avis de dépréciation des interfaces utilisées, messages d’erreur, annonces éditeur du module et changements de compatibilité de la plateforme. Le périmètre doit lister les connecteurs réellement utilisés.

Le texte peut imposer un délai de notification, par exemple cinq jours ouvrés après l’identification d’une dépréciation affectant le compte. La notification doit contenir le risque, le périmètre touché et un plan d’action. Le client sait alors s’il doit financer une évolution, changer de module ou mobiliser sa plateforme.

Ajoutez enfin le traitement d’un manquement : qui remet le flux en état si le prestataire n’a pas suivi une dépréciation relevant de son périmètre ? Cette précision complète ce que couvre et ne couvre pas un contrat de maintenance. Elle ne remplace pas une consultation juridique, mais évite qu’une panne prévisible soit qualifiée trop tard de demande hors forfait.

Ce que cette panne annonce pour la suite

La Merchant API apporte de nouvelles ressources, des identifiants différents et des contrôles de données plus explicites. Elle ne garantit pas qu’un flux ancien soit compatible sans essai. Google conserve d’ailleurs une page d’incidents connus, dont des problèmes de débit pour certaines insertions de produits et d’inventaires.

La leçon est opérationnelle : la veille technique doit devenir un livrable de la maintenance. Une dépréciation mérite une alerte, un propriétaire et une date de vérification. Un catalogue ne se réduit pas à un export automatique. C’est une infrastructure de diffusion qui peut arrêter de suivre la boutique sans bruit.

Les marchands qui veulent éviter cette dépendance aveugle ont intérêt à documenter chaque source, chaque module et chaque accès. Le même principe vaut pour rendre un catalogue lisible par une machine : la qualité d’un catalogue dépend aussi de la façon dont les systèmes le reçoivent et le traitent.

La panne qui ne déclenche aucune alerte, seulement une baisse de ventes

L’arrêt de la Content API ne demande pas au dirigeant de devenir développeur. Il demande une réponse écrite à une question simple : qui certifie que le flux a été migré et testé ? Demandez cette semaine le nom de la source de données, le dernier contrôle effectué et le responsable désigné. Si la réponse reste vague, le risque n’est pas technique. Il est contractuel.

Sources et références

Cet article s’appuie sur le calendrier officiel de retrait de la Content API for Shopping, sur le guide Google de migration des produits vers la Merchant API, sur la documentation de migration des sources de données, sur les dernières évolutions de la Merchant API, sur la page officielle des incidents connus et sur la présentation de la Merchant API.