Google a signalé un incident touchant Merchant Center, les flux produits et Merchant API, l’interface de programmation utilisée par les outils qui échangent des données avec Google. L’incident a commencé le 6 novembre à 04:30 UTC et s’est achevé à 13:00 UTC, selon le tableau de statut de Google. Durant cette fenêtre, certains marchands pouvaient ne plus voir leurs données ou rencontrer des lenteurs.
Une panne de huit heures et trente minutes ne justifie pas de reconstruire son catalogue. Elle révèle toutefois un défaut fréquent : beaucoup d’équipes découvrent qu’elles dépendent de Merchant Center seulement lorsque les diagnostics, les refus produit ou les mises à jour de prix deviennent invisibles. Notre position est de prioriser un protocole simple de continuité, pas d’ajouter un outil de surveillance coûteux.
Les huit heures et trente minutes du 6 novembre montrent où un flux produit peut se bloquer
Google n’a pas détaillé la cause de l’incident. Le périmètre déclaré couvre l’interface Merchant Center, les flux et Merchant API. Un marchand ne peut donc pas conclure que son connecteur, son agence ou son catalogue est en faute tant que le statut officiel fait état d’une interruption. C’est un réflexe utile : avant de corriger 500 fiches, vérifier le tableau de statut évite des modifications inutiles qui créent parfois de vrais écarts de stock ou de prix.
Les équipes qui pilotent des campagnes Shopping doivent conserver une trace datée de leurs exports, de leurs erreurs de flux et de leurs principaux refus. Ce journal permet de distinguer, le lendemain, une anomalie Google d’une régression interne. Sans cette séparation, le temps passe dans les tickets et les ajustements manuels, alors que le budget média continue de tourner avec un catalogue potentiellement incomplet.
Un contrôle de 20 minutes suffit avant de toucher aux 500 fiches catalogue
Une boutique de décoration qui diffuse 500 produits peut adopter une routine courte après chaque incident déclaré : capturer l’heure et le périmètre de la panne, comparer le nombre de produits actifs avec le dernier export sain, puis contrôler dix références à forte marge et dix références en promotion. Le test prend environ 20 minutes. Si le volume actif et ces 20 références sont cohérents après le retour à la normale, aucune correction massive n’est justifiée. Si un écart persiste, le marchand ouvre alors un ticket avec les heures, les identifiants produit et les captures déjà réunis.
Le même principe vaut pour les outils qui synchronisent le catalogue. Relancer un flux pendant une indisponibilité peut dupliquer des traitements ou masquer le diagnostic initial. Mieux vaut documenter l’écart, attendre le rétablissement officiel, puis relancer une seule synchronisation contrôlée si les données restent incohérentes.
La vraie priorité est un journal d’incident, pas une alerte de plus
Les alertes automatiques sont utiles quand elles surveillent une conséquence commerciale précise : produits actifs, erreurs de prix, refus critiques ou baisse anormale d’impressions Shopping. Une alerte qui signale seulement que Merchant Center est inaccessible ajoute rarement une décision utile. Le responsable e-commerce doit surtout savoir qui vérifie quoi, quel seuil déclenche une action et quand arrêter les relances.
💶 Opportunité CA
Une checklist téléchargeable « Panne Merchant Center : les 20 contrôles avant de relancer un flux » peut capter des emails de responsables catalogue via une page ressource. Cette requête répond à une intention opérationnelle et peut ensuite accueillir un partenaire affilié de gestion de flux ou de monitoring, après validation de sa pertinence.