Content API s’arrête : sécuriser la migration vers Merchant API
Content API s’arrête le 18 août 2026. Auditez votre flux catalogue, migrez vers Merchant API et testez produits, erreurs et repli.
Google désactivera Content API for Shopping le 18 août 2026. Si votre catalogue est encore envoyé à Merchant Center par cette API, il faut migrer vers Merchant API ou obtenir de l’éditeur du connecteur une preuve datée qu’il l’a fait. Si vos produits arrivent uniquement par un fichier, une feuille ou une autre source sans Content API, cette échéance ne crée pas automatiquement un chantier pour vous.
La bonne question n’est donc pas « avons-nous installé la nouvelle API ? », mais le prix, le stock, les identifiants et les erreurs traversent-ils encore toute la chaîne jusqu’aux destinations utilisées ? Une migration réussie conserve la vérité du catalogue, expose les rejets et permet de reprendre le flux sans déplacer silencieusement une offre vers la mauvaise source.
Ce guide propose une matrice originale source → écriture → traitement → destination → preuve → repli, puis huit scénarios de recette. Il ne remplace pas la documentation technique de Google ; il aide le marchand, l’éditeur et l’équipe qui exploite la boutique à partager la même preuve de continuité.
Que se passe-t-il le 18 août 2026 ?
L’annonce officielle de Google Merchant Center indique que Merchant API remplace Content API for Shopping pour l’accès par programmation. Content API reste accessible jusqu’au 18 août 2026, puis doit être désactivée.
Cette date concerne l’interface utilisée par un logiciel pour gérer des comptes, produits, inventaires, rapports ou autres ressources Merchant Center. Elle ne signifie pas que chaque e-commerçant écrit lui-même du code. Une application de plateforme, un gestionnaire de flux, une agence ou un service interne peut porter cette intégration.
Elle ne prouve pas non plus qu’une campagne s’arrêtera dans tous les cas à la même seconde. L’effet dépend de la manière dont les données sont alimentées, de leur durée de validité, des ressources utilisées et de la réaction des systèmes en aval. Présenter une perte automatique de toutes les campagnes serait donc plus alarmiste qu’utile.
La décision immédiate tient en trois questions :
- une source de données Merchant Center utilise-t-elle encore Content API ;
- qui possède et maintient le connecteur concerné ;
- quelle preuve montre que Merchant API alimente déjà les produits réellement utilisés ?
Si ces trois réponses sont disponibles, le chantier peut se limiter à une recette et à une surveillance renforcée. Si personne ne sait répondre, l’échéance révèle surtout un défaut de propriété du flux.
Êtes-vous réellement concerné par la migration Merchant API ?
Commencez dans Merchant Center par l’inventaire des sources de données, des comptes et des applications autorisées. Relevez le nom de la source, sa méthode d’alimentation, sa dernière mise à jour, les marchés concernés et le propriétaire opérationnel. Ne vous contentez pas du nom de la plateforme e-commerce : deux boutiques sur le même socle peuvent utiliser des connecteurs différents.
Vous êtes directement concerné si un développement interne appelle Content API. Vous l’êtes aussi, mais avec une responsabilité différente, si un service tiers le fait pour vous. Dans ce second cas, demandez à l’éditeur :
- quelle version et quelles ressources il utilise aujourd’hui ;
- à quelle date la production est passée sur Merchant API ;
- quels comptes, sources de données et marchés ont été migrés ;
- comment les erreurs avant et après migration sont comparées ;
- quelle action reste à la charge du marchand ;
- comment revenir à un état sûr si une anomalie de catalogue apparaît.
Une réponse commerciale du type « la migration est prise en charge » n’est pas encore une preuve. Demandez un état observable dans votre compte et un résultat sur un échantillon de produits.
Si votre catalogue arrive par un fichier XML récupéré à intervalles réguliers, un fichier envoyé, une feuille ou une autre méthode sans Content API, ne migrez pas par réflexe. Vérifiez seulement qu’aucune fonction annexe — rapport, promotion, inventaire local ou synchronisation publicitaire — ne dépend encore de l’ancienne interface.
La matrice source, écriture, traitement, destination, preuve et repli
Une intégration catalogue n’est pas une flèche entre la boutique et Google. C’est une suite de responsabilités. Remplissez une ligne par famille de flux avant de modifier le connecteur.
| Élément | Question de contrôle | Preuve attendue | Repli si la preuve manque |
|---|---|---|---|
| source | quel système possède la référence, le prix, le stock et la variante ? | export daté et propriétaire nommé | figer le périmètre et corriger la source avant migration |
| écriture | quel connecteur crée, modifie ou supprime les données dans Merchant Center ? | version, compte de service, journaux et méthode appelée | limiter les écritures au lot testable |
| traitement | quelle dataSource reçoit l’entrée et quel produit final Google calcule-t-il ? |
correspondance ProductInput / Product, statut et problèmes |
stopper l’élargissement, vérifier l’identifiant de source |
| destination | où l’offre est-elle utilisée : fiches gratuites, Shopping, campagne ou marché ? | produit éligible et destination attendue sur l’échantillon | exclure le segment affecté sans masquer l’erreur |
| preuve | quels écarts déclenchent une alerte et qui la traite ? | taux d’erreur, prix, stock, refus, fraîcheur et responsable | surveillance manuelle bornée avec date de fin |
| repli | comment reprendre une opération ou changer de connecteur ? | procédure, accès, export et scénario rejoué | conserver l’ancien état sans double écriture aveugle |
Cette matrice complète le guide du SEO e-commerce et de la vérité du catalogue. Celui-ci reste propriétaire des catégories, produits, facettes, données structurées et règles d’indexation. La présente page porte une intention plus étroite : maintenir le flux programmatique de Merchant Center pendant le changement d’API.
Le principe Zence est simple : la migration n’est terminée que lorsque le nouveau chemin produit une preuve complète. Une requête HTTP réussie ne prouve ni que le bon produit a été traité, ni qu’il apparaît dans la bonne destination, ni que l’équipe saura corriger le prochain rejet.
Qu’est-ce qui change entre Content API et Merchant API ?
Le guide de migration de Google demande de cartographier les anciennes méthodes vers de nouvelles sous-API et de nouveaux noms de ressources. La migration n’est donc pas un remplacement d’URL isolé.
Pour les produits, quatre changements méritent une recette explicite.
ProductInput et Product n’ont pas le même rôle
La documentation de migration des produits sépare les données envoyées dans ProductInput du produit final en lecture seule dans Product. Ce dernier reflète le traitement de Google, les règles et les sources complémentaires.
Votre contrôle doit donc comparer l’entrée acceptée et la sortie traitée. Tester seulement l’écriture revient à vérifier qu’un colis est parti sans contrôler sa destination ni son état à l’arrivée.
La source de données devient explicite
Les écritures productInputs exigent un paramètre dataSource. Cette précision protège la gouvernance des données, mais une mauvaise valeur peut déplacer une offre vers une autre source principale. Google décrit ce risque comme un « offer stealing ».
N’organisez donc pas un double run en envoyant aveuglément le même triplet langue, libellé de flux et offerId vers deux sources principales. Pour une montée progressive, utilisez un compte de test, un segment réellement isolé ou une stratégie de sources validée avant l’écriture.
Les identifiants et les statuts changent
Merchant API utilise des noms de ressources de type accounts/{account}/products/{product}. Le service séparé productstatuses disparaît : les problèmes de validation et les statuts de destination sont intégrés au produit traité.
Conservez le même offerId pour le même produit lorsque vous migrez. Google le recommande afin d’éviter de perdre l’historique du produit. Vérifiez aussi la langue, le feedLabel et l’encodage lorsque l’identifiant contient des caractères réservés.
custombatch n’est plus disponible
Les traitements par lots doivent passer par des requêtes asynchrones ou le batching HTTP selon le besoin. Un catalogue volumineux doit donc être testé avec son débit réel, ses quotas, ses reprises et son ordre d’exécution. Un essai sur trois produits ne prouve pas que cinquante mille mises à jour de stock termineront avant la prochaine synchronisation.
Migrer sans couper la vérité du catalogue
La séquence recommandée par Google consiste à identifier les sous-API utilisées, enregistrer le projet développeur, tester des parcours simples, déployer par méthode ou petit segment et surveiller les problèmes. Transformez cette orientation en six décisions opérationnelles.
1. Geler l’inventaire fonctionnel
Listez produits, comptes, sources, rapports, inventaires, promotions et fonctions annexes réellement appelés. Pour chaque méthode Content API, nommez l’équivalent Merchant API ou marquez « non migré ». N’ajoutez pas une nouvelle fonction pendant que la continuité de l’existant reste inconnue.
2. Choisir un échantillon qui porte les risques
Prenez au minimum un produit simple, une variante, une promotion, une rupture, un produit multi-marché, un identifiant contenant un caractère particulier et une suppression. L’échantillon doit représenter les règles, pas seulement les meilleures ventes.
3. Séparer le test de la production
Google documente des comptes de test et recommande un déploiement progressif. Évitez une seconde source primaire improvisée dans le compte de production. Si un test réel en production est nécessaire, isolez une famille dont les identifiants, la source, les destinations et la procédure de retrait sont connus.
4. Comparer l’entrée et le produit traité
Pour chaque référence, conservez la requête utile, la réponse, le ProductInput, le Product, ses problèmes et ses destinations. Comparez ensuite prix, devise, disponibilité, lien, image, variante et date de mise à jour avec la page de vente.
5. Élargir selon des seuils définis
Décidez avant le déploiement ce qui bloque l’étape suivante : produit manquant, mauvais prix, déplacement de source, erreur non expliquée, hausse du taux de rejet ou délai incompatible avec la fréquence de stock. « La plupart des produits passent » n’est pas un critère de recette.
6. Retirer l’ancienne dépendance
Une fois le périmètre validé, supprimez ou désactivez les tâches qui appellent encore Content API. Conservez la correspondance des méthodes, les journaux nécessaires, la procédure d’incident et la date de revue. Une ancienne tâche planifiée oubliée peut continuer à échouer ou à produire un faux signal d’alerte après le 18 août.
Huit scénarios de recette avant et après la bascule
La recette doit provoquer des situations où une migration superficielle échoue.
- Création nominale. Un nouveau produit apparaît avec le bon identifiant, la bonne source et les destinations attendues.
- Modification de prix. Le prix traité rejoint la source de vérité dans le délai défini, sans être écrasé par une autre entrée.
- Rupture et retour en stock. La disponibilité change dans les deux sens et reste cohérente avec la fiche.
- Variante. La langue, le
feedLabel, l’offerIdet les attributs distinguent correctement chaque offre. - Rejet volontaire. Une donnée invalide produit un problème visible, attribué et corrigeable ; elle ne disparaît pas dans un journal inaccessible.
- Suppression. Le bon
ProductInputest supprimé dans la bonnedataSource, sans déplacer ou retirer une autre offre. - Retard ou doublon. Une mise à jour tardive ne remplace pas une valeur plus récente et une répétition ne crée pas une seconde offre.
- Indisponibilité du connecteur. L’équipe détecte l’arrêt, connaît l’état du dernier lot et rejoue seulement les opérations nécessaires.
Après la bascule, contrôlez au moins un cycle complet de prix et de stock, puis un cycle de rapport ou de campagne réellement utilisé. La durée dépend de votre fréquence métier : vingt-quatre heures peuvent suffire pour un petit catalogue quotidien, mais pas pour une promotion hebdomadaire ou un stock mis à jour toutes les minutes.
Qui est responsable lorsque le connecteur vient d’un tiers ?
Le marchand reste responsable de la vérité commerciale présentée à ses clients, mais il ne doit pas prétendre maintenir un code qu’il ne possède pas. Répartissez les responsabilités selon les faits.
- Le marchand nomme la source de vérité, les marchés, les destinations et les seuils métier acceptables.
- L’éditeur du connecteur décrit la version, les ressources migrées, les limites, les erreurs et son calendrier de support.
- L’agence ou l’intégrateur vérifie le paramétrage propre au compte, les dépendances et la recette convenue.
- L’équipe acquisition contrôle l’éligibilité et les campagnes sans confondre diffusion et qualité de la donnée.
- L’équipe métier confirme que prix, stock, variantes et règles correspondent à l’offre réelle.
Cette répartition rejoint la grille Shopify ou PrestaShop : une application compatible ajoute son propre cycle de maintenance, ses permissions et sa dépendance à un éditeur. Le nom de la plateforme ne garantit pas la version du connecteur.
Demandez aussi qui possède le projet Google Cloud, le compte Merchant Center principal, les comptes de service et la documentation. Une migration menée depuis le compte personnel d’un prestataire peut fonctionner techniquement tout en dégradant la maîtrise et la réversibilité des actifs numériques.
Exemple fictif : un catalogue géré par un connecteur SaaS
Imaginons une boutique fictive de 8 000 références. Les produits sont créés dans un ERP, enrichis dans la plateforme e-commerce puis envoyés à Merchant Center par un connecteur SaaS. L’équipe marketing voit les produits dans Google, mais ignore quelle API le connecteur appelle.
Elle ne lance pas immédiatement un développement. Elle inventorie la source Merchant Center, demande à l’éditeur la date de passage sur Merchant API et choisit huit produits couvrant variantes, promotions, ruptures et deux marchés. L’éditeur fournit la preuve de la nouvelle source ; l’équipe compare ensuite ProductInput, produit traité, prix, stock et destinations.
Un test révèle qu’une ancienne règle utilise encore le pays cible là où la nouvelle structure attend un feedLabel. La correction est appliquée au segment, puis la recette est rejouée avant élargissement. Le marchand conserve la matrice, les seuils d’erreur, les accès et la procédure d’incident.
Cet exemple n’est pas un cas client et ne promet aucun résultat. Il montre surtout qu’un marchand peut piloter la preuve sans devenir l’auteur du connecteur.
Quelle première action prendre aujourd’hui ?
Ouvrez Merchant Center et choisissez une seule source de données qui alimente vos produits. Notez sa méthode, son propriétaire, sa dernière activité et cinq références représentatives. Demandez ensuite une preuve que ces références sont écrites par Merchant API, traitées dans la bonne source et visibles dans les destinations attendues.
Si vous utilisez encore Content API, ne commencez pas par migrer tout le catalogue. Cartographiez les méthodes, isolez un échantillon et fixez les seuils qui autorisent l’élargissement. Si un tiers porte le connecteur, exigez la preuve au lieu de reconstruire son travail.
Zence relie cette migration à la conception et l’exploitation d’un e-commerce : catalogue, intégrations, erreurs, visibilité et reprise. Le but n’est pas d’adopter une API neuve. Il est de conserver une offre exacte et un flux que l’entreprise sait surveiller après l’échéance.
