Merchant Center multi-pays : devises, livraison, taxes et retours

Merchant Center multi-pays : devises, livraison, taxes et retours

Passer d’un pays à deux dans Google Merchant Center, c’est le moment où la plupart des catalogues craquent. Un flux domestique avec des prix arrondis, une seule grille de livraison et une page retours générique survit uniquement parce que rien ne le teste vraiment. Ajoutez un deuxième pays cible et le système audite tout en même temps : la devise déclarée dans le flux contre la devise du service de livraison, le prix sur Shopping contre le prix sur la page de destination, l’URL de retours contre la langue de destination, l’inclusion de la TVA contre la règle locale, le GTIN contre le registre fabricant. Une configuration domestique qui fonctionne n’est pas une configuration multi-pays qui fonctionne, c’est une configuration qui n’a pas encore été mesurée contre les règles d’un autre pays que le sien.

Ce guide couvre l’architecture et les détails opérationnels. On parle du choix entre un compte unique multi-pays et plusieurs comptes liés en hiérarchie, des attributs cibles pays et langue sur le flux, de la règle d’affichage de la devise qui désapprouve la majorité des catalogues transfrontaliers, de la règle d’inclusion de la TVA UE et du guichet unique IOSS, de la sales tax américaine et du régime nexus post-Wayfair plus marketplace facilitator, de la GST en Australie, en Inde et au Canada, du dédoublement TVA Royaume-Uni post-Brexit, des zones de livraison avec rate tables ou rates calculés par transporteur, des retours sous la directive UE droits des consommateurs, des désapprobations produits qui varient par pays, des règles de flux pour dériver les variantes pays depuis une source unique, et de la cadence opérationnelle pour ajouter un nouveau pays sans casser le reste.

Décision d’architecture : compte unique multi-pays ou un compte par pays

La première décision : un seul compte Merchant Center qui cible plusieurs pays, ou un compte par pays liés en hiérarchie Merchant Center (la structure anciennement appelée Multi-Client Account). L’aide Google Merchant Center autorise les deux. La bonne réponse est opérationnelle, pas théorique, et dépend de trois variables : le recouvrement catalogue, la devise de paiement, et le rayon de souffle d’une suspension.

Un compte unique convient quand le recouvrement catalogue est fort (les mêmes SKU partent vers tous les pays ciblés), quand l’entité juridique vendeuse est la même, quand la devise de paiement est unique, et quand l’équipe accepte qu’une violation de politique dans un pays peut désactiver les annonces Shopping de tout le compte le temps de la revue. Search Engine Land a documenté plusieurs cas où une cascade de désapprobations sur un seul produit en Allemagne (formulation réglementaire sur l’étiquette d’un complément alimentaire) a fait tomber les flux français et italien pendant des semaines parce que l’avertissement compte avait basculé en suspension. La leçon n’est pas de fuir les comptes multi-pays, c’est de comprendre que le compte est l’unité de suspension.

Des comptes séparés en hiérarchie conviennent quand les catalogues divergent matériellement par pays (SKU différents, marque différente, accord de distribution exclusive), quand des entités locales facturent en monnaie locale et veulent une comptabilité propre, quand un pays vend une catégorie qu’un autre interdit, et quand l’équipe veut explicitement isoler le rayon de souffle. Tinuiti a publié des études de cas de retailers transfrontaliers qui ont migré du compte unique vers la hiérarchie après qu’une désapprobation alcool au Royaume-Uni a menacé une campagne Shopping aux États-Unis sans rapport avec l’alcool. Le coût de la migration est réel (refonte des politiques de livraison, re-vérification des domaines, re-upload des flux), le bénéfice est un rayon de souffle propre.

Règle pragmatique : pour deux à quatre pays avec le même catalogue et la même entité juridique, un compte unique avec flux ciblés par pays. Pour cinq pays ou plus, ou pour tout pays vendant des catégories réglementées (alcool, compléments, produits financiers), une hiérarchie avec un compte par pays. Les architectures hybrides (un compte UE, un compte UK, un compte US) marchent bien en pratique parce qu’elles épousent les régimes de TVA et les devises de paiement.

L’attribut pays cible sur le flux

Chaque flux Merchant Center a un pays cible, déclaré au niveau du flux dans les paramètres. Le pays est le pays où les produits du flux sont vendus, pas le pays où le marchand est établi. Un marchand français qui vend en Allemagne déclare l’Allemagne comme pays cible sur le flux allemand. Le pays cible pilote la devise attendue, la langue attendue, la règle d’inclusion de TVA, l’éligibilité de livraison, et l’ensemble des politiques contre lesquelles les produits sont évalués.

Vous pouvez aussi cibler plusieurs pays depuis un seul flux primaire en ajoutant des pays supplémentaires dans les paramètres du flux. C’est la configuration la plus simple et Google la supporte pour la plupart des combinaisons de pays, mais elle impose une contrainte : chaque produit du flux doit être éligible dans chaque pays ciblé. Si un produit est restreint dans un des pays ciblés (un complément interdit en France mais autorisé en Allemagne), tout le flux produit une désapprobation pour ce produit dans le pays restreint et un avertissement au niveau du flux. L’avertissement est récupérable, la récidive ne l’est pas.

Le pattern propre, recommandé par Search Engine Journal dans ses guides Merchant Center multi-pays, est un flux primaire par pays plus des flux supplémentaires qui surchargent les attributs pays-spécifiques. Chaque flux primaire déclare un seul pays cible. Les flux supplémentaires se superposent pour injecter les prix locaux, les descriptions locales, les coûts de livraison locaux. Le bénéfice : une désapprobation dans un pays ne traverse jamais vers un autre flux, et les métriques au niveau du flux (part d’impressions, taux de clic, nombre de désapprobations) sont visibles par pays.

L’attribut pays dans une entrée de service de livraison, dans un paramètre de taxe ou dans une règle de flux est toujours un code ISO 3166-1 alpha-2 (DE, FR, IT, ES, GB, US, CA, AU). Mélanger l’alpha-2 avec un nom de pays complet (« Germany » au lieu de « DE ») dans les règles de flux est une cause fréquente d’échec silencieux. Validez chaque code contre la liste ISO avant de pousser.

L’attribut langue cible

L’attribut content language sur le flux déclare la langue des titres, descriptions et autres champs textuels, pas la langue du client. Google applique un mapping strict entre pays cible et langues acceptées. L’Allemagne accepte l’allemand (de). La France accepte le français (fr). La Belgique accepte le français et le néerlandais (fr, nl). La Suisse accepte l’allemand, le français et l’italien (de, fr, it). La liste complète figure dans l’aide Merchant Center sous « Langues et devises supportées par pays ».

La langue déclarée doit être la langue effective du texte. Un flux déclaré en français (fr) ciblant la France avec des titres en anglais est rejeté avec des désapprobations « Language mismatch ». Un flux déclaré en anglais ciblant la France passe le contrôle de langue mais perd l’éligibilité Shopping parce que Google n’affiche pas d’annonces Shopping en anglais à des utilisateurs français quand des alternatives en français existent. La configuration correcte : un flux par langue, même si la langue sert plusieurs pays. Un seul flux en français sert la France, la partie francophone de la Belgique et la partie francophone du Luxembourg en activant ces pays dans l’onglet de ciblage du flux.

La localisation ne se limite pas au titre et à la description. Marque, couleur, matière, taille, genre et type de produit doivent être dans la langue cible pour le ranking. Un blouson cuir décrit « 100% leather, full-grain, cognac brown, size L » dans le flux anglais doit devenir « 100% Leder, vollnarbig, cognac-braun, Größe L » dans le flux allemand. DataFeedWatch a mesuré une amélioration de 15 à 30% de la part d’impressions sur les attributs localisés correctement par rapport aux attributs auto-traduits, parce que le matcher de Google utilise les valeurs localisées pour comprendre les requêtes, pas seulement pour l’affichage.

Règles d’affichage de la devise

La règle dure, documentée dans l’aide Merchant Center sous « Currency requirements », est que la devise du flux doit correspondre à la devise attendue pour le pays de destination. L’Allemagne attend EUR, le Royaume-Uni attend GBP, les États-Unis attendent USD, la Suisse attend CHF. Un produit à 100 EUR ne peut pas être affiché à des clients britanniques en EUR, il doit l’être en GBP. Deux mécanismes : la conversion automatique de devise au niveau Merchant Center, ou la tarification manuelle par pays dans des flux séparés.

La conversion automatique utilise les taux Google Finance. Le marchand télécharge des prix dans une devise unique, le système affiche le prix converti aux clients dans des pays à devise différente. La conversion est une estimation, pas un prix engageant. Le montant réel dépend du moyen de paiement du client et du taux de l’émetteur. La couverture Search Engine Land des annonces Shopping transfrontalières note les deux risques principaux : des contestations visibles d’écart de prix quand la banque du client applique un taux moins favorable au checkout, et une compression de marge pour les produits dont la marge est de 5 à 12% quand la volatilité EUR-GBP atteint 3 à 5% sur un trimestre. La conversion automatique est acceptable pour les catégories à forte marge, peu volatiles, et pour les pilotes de nouveaux pays. Elle ne l’est pas pour des produits commodités à marge fine à grande échelle.

La tarification manuelle par pays est le pattern de production des opérations multi-pays établies. Le marchand maintient des flux séparés, chacun dans la devise cible, avec des prix posés stratégiquement plutôt que mathématiquement. Une marque française peut prix une robe à 89 EUR en France, 92 EUR en Allemagne (positionnement premium), 79 GBP au Royaume-Uni (arrondi retail psychology, pas 76 issu de l’auto-conversion), 85 EUR en Espagne (pression concurrentielle). DataFeedWatch et les plateformes équivalentes (Channable, GoDataFeed, Feedonomics) exécutent cela par règles : prix de base en EUR, multiplicateur pays, conversion de devise si nécessaire, arrondi retail. Le même prix de base coule vers cinq flux pays avec cinq prix finaux différents, tous mis à jour dans la cadence quotidienne du flux.

La devise du service de livraison doit correspondre à la devise du flux. Un flux allemand en EUR avec un service de livraison déclaré en USD est rejeté à la validation. Idem pour les paramètres de taxe et pour les règles de flux qui calculent un coût de livraison. La cohérence de devise entre prix, coût de livraison et taxe est la cause unique la plus fréquente de rejet de flux transfrontaliers.

TVA UE et guichet unique IOSS

La règle UE, posée par le paquet TVA e-commerce en vigueur depuis le 1er juillet 2021, est que les prix affichés aux consommateurs doivent inclure la TVA. Le flux Merchant Center pour un pays cible UE doit donc soumettre des prix TTC. Une marque française qui vend en Allemagne à 100 EUR soumet 100 EUR, la TVA allemande (19%) est embarquée. Google n’ajoute pas la TVA, ne soustrait pas la TVA, n’affiche pas de prix HT aux consommateurs dans les pays UE cibles. Soumettre un prix HT en attendant que Google ajoute la TVA est une erreur récurrente qui déclenche des désapprobations price-mismatch parce que la page de destination (qui inclut correctement la TVA) ne correspond plus au flux.

Les taux de TVA ne sont pas uniformes dans l’UE. Les taux standards en 2026 vont de 17% au Luxembourg à 27% en Hongrie, la majorité des pays se situant entre 19 et 23% : Allemagne 19%, France 20%, Espagne 21%, Italie 22%, Pays-Bas 21%, Pologne 23%, Suède 25%. Le même produit au même coût HT donne des prix TTC différents par pays. Un produit à 100 EUR HT devient 119 EUR en Allemagne, 120 EUR en France, 121 EUR en Espagne, 122 EUR en Italie. Une stratégie tarifaire peut aplatir ces écarts (un prix d’affichage unique de 119,90 EUR à travers l’UE absorbe les écarts de taux dans la marge), mais le flux doit toujours porter le prix TTC exact affiché sur la page de destination.

L’Import One-Stop-Shop (IOSS) est le mécanisme UE pour les ventes à distance de biens importés jusqu’à 150 EUR. Un marchand non-UE (Royaume-Uni, États-Unis, Suisse, Norvège) qui vend à des consommateurs UE peut s’enregistrer à l’IOSS dans un seul État membre et y reverser la TVA pour toutes les ventes UE, au lieu de s’enregistrer dans chaque pays de consommation. Les marchandises sous IOSS dédouanent sans collecte de TVA à l’import à la frontière parce que la TVA a déjà été collectée au point de vente. L’implication Merchant Center : un marchand non-UE inscrit à l’IOSS soumet des prix TTC dans les flux UE au taux du pays de destination, et la page de destination doit collecter la TVA au même taux. Le numéro IOSS est déclaré côté douane, pas dans le flux.

Le One-Stop-Shop (OSS) est le mécanisme parallèle pour les marchands établis dans l’UE qui vendent en transfrontalier à des consommateurs UE. Un marchand français qui vend à des consommateurs allemands au-delà du seuil pan-UE de 10 000 EUR s’enregistre à l’OSS en France et reverse la TVA allemande via le portail OSS français. Même implication flux : prix TTC au taux du pays de destination. Store Growers a couvert l’arbitrage opérationnel en détail : l’OSS réduit la charge de conformité d’une immatriculation TVA par pays à une seule immatriculation OSS, au prix d’abandonner la récupération de TVA locale sur les coûts d’intrants locaux.

Sales tax américaine : nexus, marketplace facilitators et configuration du flux

Le paysage de la sales tax américaine est unique. Pas de TVA fédérale. Chaque État, et beaucoup de comtés et villes au sein de chaque État, fixe son propre taux et ses propres règles. En 2026, 45 États plus le District of Columbia imposent une sales tax. Cinq États (Alaska, Delaware, Montana, New Hampshire, Oregon) ne l’imposent pas, bien que l’Alaska autorise les juridictions locales à la fixer. Les taux d’État standards vont de 2,9% (Colorado) à 7,25% (Californie), et les taux combinés État plus local peuvent dépasser 10% dans certaines parties de la Louisiane, du Tennessee et de l’Alabama.

Le régime post-Wayfair, posé par l’arrêt Cour suprême South Dakota v. Wayfair de 2018, est que les États peuvent obliger les vendeurs hors État à collecter la sales tax dès lors que le vendeur a un nexus économique dans l’État. La plupart des États définissent le nexus économique comme 100 000 USD de ventes ou 200 transactions par an dans l’État, mais les seuils varient. La couverture Search Engine Journal des annonces Shopping transfrontalières insiste sur l’implication opérationnelle : le vendeur ne choisit pas où collecter la taxe, c’est la loi de nexus de l’État qui décide. Le franchissement du seuil en octobre déclenche une obligation d’enregistrement qui s’applique à toutes les ventes à partir de ce moment.

Les lois marketplace facilitator, désormais adoptées par tous les États avec sales tax, transfèrent l’obligation de collecte vers la marketplace (Amazon, eBay, Walmart) pour les ventes faites via cette marketplace. Un vendeur qui vend la même SKU sur Amazon et sur son site doit toujours collecter la sales tax sur les ventes du site pour les États où il a nexus, même si Amazon collecte sur la même SKU côté marketplace. Les annonces Google Shopping pointent vers le site du vendeur, donc tombent en dehors de la règle facilitator.

L’implication Merchant Center : les flux US soumettent des prix HT, et la taxe est configurée au niveau du compte (Outils > Sales tax) par État, avec un taux déclaré par État et un drapeau indiquant si l’État applique le sourcing destination ou origine. Google calcule la taxe affichée dans l’annonce Shopping selon l’État de destination du client. Le marchand peut aussi utiliser un service de calcul de sales tax (TaxJar, Avalara, Vertex) intégré au front, qui applique les taux locaux précis au checkout. Les paramètres taxe Merchant Center n’ont alors besoin d’être qu’approximativement corrects pour l’affichage des annonces, le front impose le taux exact.

L’erreur récurrente documentée par Tinuiti dans ses audits transfrontaliers est le marchand UE qui configure le flux US avec des prix TTC. Les États-Unis n’utilisent pas la TVA. Le prix dans le flux US doit être HT, la sales tax est ajoutée au checkout, et la page de destination doit afficher le prix HT par défaut avec une estimation de taxe calculée depuis le code postal du client. Soumettre un prix TTC aux États-Unis déclenche une désapprobation price-mismatch contre la page HT dans les heures qui suivent les premières impressions.

GST et autres taxes régionales : Australie, Inde, Canada

L’Australie applique une Goods and Services Tax (GST) à 10% sur la plupart des biens et services. Pour les biens importés sous 1 000 AUD, le vendeur est responsable de la collecte de la GST au point de vente si le chiffre d’affaires GST annuel vers l’Australie dépasse 75 000 AUD. Le vendeur doit s’enregistrer auprès de l’Australian Taxation Office et reverser la GST collectée trimestriellement. L’implication Merchant Center : les prix dans le flux australien doivent inclure la GST, même règle TTC que l’UE.

L’Inde applique la GST depuis 2017 avec une structure multi-taux : 0%, 5%, 12%, 18% et 28% selon la catégorie de produit. L’habillement sous 1 000 INR est taxé à 5%, au-dessus à 12%, l’électronique à 18%, le luxe à 28%. Le flux Merchant Center indien soumet des prix GST incluse et la page de destination affiche le même. Les vendeurs étrangers qui expédient en Inde via le e-commerce font face à un ensemble séparé de droits de douane par-dessus la GST, et le traitement douanier dépend du mode courrier (postal, express, commercial).

Le Canada applique une GST fédérale de 5% combinée à des taxes provinciales (PST) qui varient par province. Cinq provinces (Ontario, Nouveau-Brunswick, Terre-Neuve, Nouvelle-Écosse, Île-du-Prince-Édouard) ont harmonisé leur PST avec la GST fédérale en une Harmonized Sales Tax (HST) unique de 13 à 15%. Le Québec applique la Quebec Sales Tax (QST) à 9,975% par-dessus la GST fédérale, sur une base de calcul différente de la PST. Colombie-Britannique, Saskatchewan et Manitoba appliquent une PST séparée. Résultat : la même SKU vendue à Toronto (HST 13%), à Montréal (GST 5% plus QST 9,975%), à Vancouver (GST 5% plus PST 7%) et à Edmonton (GST 5%, pas de PST) porte quatre taux effectifs différents. Le flux Merchant Center canadien peut être configuré au niveau du compte avec des taux province par province à la manière des États américains, ou avec des prix TTC qui varient par province de destination via des règles de flux.

TVA Royaume-Uni post-Brexit

Le Royaume-Uni a quitté le régime TVA UE le 1er janvier 2021. Depuis, la TVA britannique s’applique à tout bien vendu à un consommateur britannique, quel que soit l’établissement du vendeur, avec deux régimes distincts coupés par la valeur du colis. Pour un colis n’excédant pas 135 GBP, le vendeur est responsable de la collecte de la TVA britannique au point de vente et la reverse à HMRC sous immatriculation TVA britannique. Pour un colis dépassant 135 GBP, c’est le régime de TVA à l’importation qui s’applique et la TVA est collectée à la frontière, soit auprès du client (DDU, delivered duty unpaid), soit auprès du vendeur (DDP, delivered duty paid).

Le protocole nord-irlandais a ajouté une seconde couche. L’Irlande du Nord reste dans le régime TVA UE pour les biens, alors que le reste du Royaume-Uni (Grande-Bretagne) opère le régime TVA britannique post-Brexit. Un vendeur en UE continentale qui expédie à Belfast suit les règles UE, livraison intracommunautaire et reporting OSS. Le même vendeur qui expédie à Londres suit les règles britanniques, immatriculation TVA UK et reporting HMRC. La configuration Merchant Center utilise GB comme code de pays cible pour la Grande-Bretagne et suit la tarification TTC TVA UK sous 135 GBP.

Le pattern opérationnel recommandé par DataFeedWatch et Store Growers pour les vendeurs UE qui entrent au Royaume-Uni : immatriculation TVA britannique auprès de HMRC, flux UK avec prix TTC, politiques de livraison dédiées en GBP, URL politique de retours en anglais avec référence explicite au UK Consumer Rights Act 2015, et numéro EORI pour le dédouanement. Sauter une étape pour expédier plus vite produit en général une cascade de désapprobations dans le premier mois.

Zones de livraison : rate tables ou rates calculés transporteur

Merchant Center autorise jusqu’à 100 services de livraison par compte et jusqu’à 20 paramètres de livraison par pays, plus que ce dont une opération raisonnable a besoin. Le choix de configuration est entre tarif fixe, rate table et rate calculé transporteur, avec des implications opérationnelles différentes pour chacun.

Le tarif fixe est un coût unique par service, optionnellement avec un seuil de livraison gratuite au-dessus d’un montant panier. Il convient aux retailers à poids colis uniforme (habillement, accessoires, petite électronique). Le coût est prévisible, la configuration triviale, l’expérience client claire. L’inconvénient : le fixe sur-facture ou sous-facture selon la composition du panier. Un t-shirt et une botte lourde paient le même frais.

Les rate tables calculent la livraison selon le sous-total commande, le poids, la destination (code postal ou région) ou la quantité. Merchant Center supporte des rate tables imbriquées où la dimension ligne est une variable (poids) et la dimension colonne une autre (zone code postal). Un retailer peut poser : « 0-2 kg vers zone A : 4,99 EUR ; 2-5 kg vers zone A : 6,99 EUR ; 0-2 kg vers zone B : 7,99 EUR ; 2-5 kg vers zone B : 10,99 EUR ». Les rate tables collent à la tarification réelle des transporteurs mieux que le fixe mais exigent un poids exact sur chaque produit du flux. Une SKU au poids manquant ou faux produit un price-mismatch et désapprouve.

Les rates calculés transporteur tirent les coûts en direct depuis les API FedEx, UPS, USPS ou DHL selon le code postal d’origine, le code postal de destination, les dimensions du colis et le poids. Avantage : alignement exact avec ce que le transporteur facturera à l’expédition. Inconvénients opérationnels : chaque produit du flux a besoin de dimensions et poids précis, l’intégration API doit être maintenue, et les fluctuations de tarif transporteur coulent directement vers le coût de livraison affiché dans l’annonce. Les rates calculés sont le bon choix pour les biens lourds ou volumineux (mobilier, électroménager, matériaux de construction) et pour les marketplaces avec de nombreux vendeurs tiers expédiant depuis des sites différents.

Le pattern rate-table type Cdiscount est utile pour les opérations transfrontalières européennes : France métropolitaine 2,99 EUR fixe, gratuit au-dessus de 30 EUR ; Corse 5,99 EUR fixe, gratuit au-dessus de 60 EUR ; Allemagne 4,99 EUR fixe, gratuit au-dessus de 45 EUR ; Espagne 5,49 EUR fixe, gratuit au-dessus de 50 EUR ; Italie 6,99 EUR fixe, gratuit au-dessus de 50 EUR ; Belgique et Luxembourg 3,99 EUR fixe, gratuit au-dessus de 45 EUR. Chaque pays reflète le coût réel du transporteur sur la lane du vendeur, pas une moyenne pan-européenne qui perd de l’argent sur l’Italie et sur-facture la Belgique.

Retours et droits des consommateurs UE : 14 jours de rétractation

La directive UE 2011/83/UE relative aux droits des consommateurs fixe un délai minimum de 14 jours de rétractation pour les contrats à distance. Le consommateur peut renvoyer un produit sans motif dans les 14 jours suivant la réception, et le vendeur doit rembourser le prix complet, frais d’envoi initial inclus (à hauteur de l’option de livraison standard la moins chère offerte), dans les 14 jours suivant la réception du produit retourné ou la preuve d’expédition retour. Le consommateur paie les frais de retour sauf si le vendeur a accepté de les prendre en charge ou a omis de l’informer de cette obligation.

Merchant Center exige que chaque pays ciblé ait une URL de politique de retours publiée dans la langue locale. Google crawle l’URL, parse les conditions, valide contre les règles du pays, et affiche les conditions clés (fenêtre de retour en jours, coût de retour, exceptions catégorie) directement dans les annonces Shopping. Les données structurées MerchantReturnPolicy, documentées sur Google Search Central, sont le moyen recommandé d’exposer la politique en format machine pour que l’affichage Shopping colle exactement au contenu de la page.

Les variations entre pays UE sont minimales sur la règle principale (14 jours minimum dans les 27 États membres) mais réelles sur les détails opérationnels. La France impose la mise à disposition explicite du formulaire de rétractation sur le site et l’envoi du formulaire avec le produit. L’Allemagne impose au vendeur la prise en charge des frais de retour pour tout retour pour défaut quel que soit le montant, et la majorité des consommateurs allemands attendent du vendeur qu’il prenne aussi en charge les frais de retour pour les retours sans défaut, raison pour laquelle la plupart des retailers allemands offrent les retours gratuits comme standard concurrentiel. L’Italie et l’Espagne s’alignent sur le minimum directive.

Le Royaume-Uni post-Brexit suit les Consumer Contracts Regulations 2013, qui conservent la rétractation 14 jours de la directive UE d’origine. Les règles substantielles de retour au Royaume-Uni sont proches de l’UE, la différence est juridictionnelle. Un litige retour entre un vendeur français et un consommateur britannique relève du droit britannique de la consommation et est tranché par le UK trading standards, pas par le droit français. L’URL de politique de retours pour le Royaume-Uni doit référencer explicitement le droit britannique pour éviter que Google ne marque la politique comme non-localisée.

Les États-Unis n’ont pas de loi fédérale sur les retours. Les conditions sont posées par le vendeur, avec des règles de protection des consommateurs État par État qui couvrent les pratiques trompeuses sans imposer de fenêtre de retour. La majorité des retailers US offrent 30 jours comme standard de fait, 60 à 90 jours pour les enseignes premium et un petit nombre offrent les retours à vie comme différenciateur de marque. Le minimum politique Merchant Center est de 30 jours pour les États-Unis, imposé par Google comme condition d’éligibilité Shopping depuis 2022.

Désapprobations produits qui varient par pays

Le même produit peut être approuvé dans un pays et désapprouvé dans un autre parce que chaque pays évalue le catalogue contre son propre cadre réglementaire. Les catégories à plus forte variance sont alcool, compléments alimentaires, armes, produits de santé, services financiers, jeux d’argent et tabac. Search Engine Land a publié plusieurs analyses sur la dérive réglementaire entre États membres UE sur les compléments : un complément vitaminé conforme à la Lebensmittel-, Bedarfsgegenstände- und Futtermittelgesetzbuch allemande peut être désapprouvé en France pour un écart d’étiquetage INCO et ré-approuvé en Italie sans changement de la fiche.

L’alcool est le cas le plus net. Allemagne, Royaume-Uni, Pays-Bas et la plupart de l’Europe centrale et orientale autorisent les annonces Shopping alcool avec age-gating et statut de retailer agréé. La France autorise les annonces alcool mais sous règles de contenu strictes au titre de la Loi Évin (pas d’imagerie lifestyle, mention sanitaire obligatoire). Suède, Finlande et Norvège opèrent des monopoles d’État alcool qui interdisent en pratique les annonces alcool privées. Les États-Unis autorisent les annonces alcool dans 41 États sous vérification de licence retailer, neuf États interdisent purement les expéditions directes au consommateur.

Les compléments varient par allégation. Une allégation « boosts immunity » approuvée aux États-Unis est rejetée dans l’UE au titre du règlement 1924/2006 sur les allégations nutritionnelles et de santé parce qu’elle ne figure pas sur la liste autorisée. Une allégation utilisant le libellé exact autorisé du registre EFSA passe la revue UE. Les soumissions qui traduisent une allégation US mot à mot en français ou en allemand désapprouvent presque toujours à la première revue.

Le pattern opérationnel : maintenir une matrice d’éligibilité pays par SKU dans les données maître produit, pas comme une décision au moment du flux. Chaque SKU est taggée avec les pays dans lesquels elle est autorisée. Le pipeline de génération de flux filtre par tag par flux pays. Une nouvelle SKU démarre autorisée dans zéro pays et n’est activée par pays qu’après revue réglementaire. Tinuiti a publié des études de cas de retailers qui ont sauté cette étape, poussé un catalogue US dans un flux UK, et absorbé un taux de désapprobation de 30 à 50% qui n’a jamais été redressé parce que l’historique de revue par pays est collant.

Règles de flux : dériver plusieurs variantes pays depuis une source unique

Les règles de flux dans Merchant Center sont des transformations appliquées à un flux primaire ou supplémentaire au moment de l’upload, avant validation. Un seul flux source (l’export master de la plateforme e-commerce) traverse différents jeux de règles par pays pour produire les variantes pays. Les plateformes DataFeedWatch et Channable externalisent cette logique avec plus de souplesse que les règles de flux natives Merchant Center, mais le mécanisme est le même.

Le pipeline de règles type pour une configuration multi-pays UE, dérivé du flux source :

• Filtrer : ne garder que les SKU taggées comme autorisées dans le pays cible.
• Transformer le prix : convertir depuis la devise de base (EUR) vers la devise cible si différente, appliquer un multiplicateur pays-spécifique (1,00 pour la France, 1,03 pour l’Allemagne, 0,95 pour l’Espagne), arrondir aux points de prix retail (xx,99 ou xx,95 selon catégorie).
• Injecter la TVA : appliquer le taux de TVA de destination au prix HT de base pour produire le prix TTC attendu par le flux.
• Surcharger la description : remplacer la description en langue de base par la version langue cible issue de la base de localisation.
• Surcharger la livraison : poser l’identifiant de service de livraison du pays cible.
• Surcharger la disponibilité : positionner la disponibilité depuis le stock entrepôt local, pas le stock global.
• Injecter les custom labels : tagger avec groupe marketing, bande de marge, étape cycle de vie pour le filtrage campagne en aval.

Le pipeline de règles tourne quotidiennement ou horairement. Chaque pays produit un flux de sortie qui part vers Merchant Center comme flux primaire de ce pays. Le bénéfice de ce pattern par rapport à la maintenance manuelle de cinq exports séparés : tout changement à la source (nouvelle SKU, mise à jour de prix, mouvement de stock) se propage à tous les flux pays au prochain run du pipeline, et les divergences entre pays sont explicites (encodées en règles) au lieu d’implicites (dérivées dans le temps à travers des spreadsheets séparés).

L’erreur la plus commune en règles de flux : ne pas valider la sortie. Une règle peut transformer un prix de 100 EUR en 1,00 EUR si un multiplicateur a été mal configuré, et le bug part en production en silence parce que le flux valide structurellement même si les prix sont faux. Les audits Tinuiti ont révélé des cas où ce type de bug a tourné deux semaines avant que l’équipe ventes ne remarque le pic de volume. La parade : un sanity check sur chaque flux de sortie. Comparaison du prix moyen par catégorie contre le run précédent, avec blocage dur si l’écart dépasse un seuil (10% au niveau catégorie d’un run au suivant).

Ajouter un nouveau pays : cadence et calendrier opérationnels

Le calendrier bout en bout pour ajouter un nouveau pays à une configuration multi-pays qui marche, en supposant l’enregistrement juridique et fiscal déjà en place :

• Jour 0 : décision business d’entrer dans le pays. Audit d’éligibilité du catalogue (catégories réglementaires, couverture GTIN, couverture de langue). Immatriculation fiscale vérifiée ou lancée. Pour l’UE : enregistrement OSS confirmé. Pour le Royaume-Uni : TVA et EORI confirmés.
• Jours 1 à 7 : négociation des politiques de livraison avec les transporteurs sur la lane. Conditions de retour rédigées en langue locale, URL de retours publiée, données structurées ajoutées.
• Jours 7 à 14 : pipeline de flux étendu avec règles pays-spécifiques. Localisation des titres, descriptions et attributs des SKU autorisées dans le pays cible. Validation devise, langue et inclusion TVA contre des SKU de test.
• Jour 14 : pays ajouté dans les paramètres Merchant Center, flux primaire créé et uploadé, services de livraison configurés, URL politique de retours soumise.
• Jours 14 à 21 : revue initiale par Google. Désapprobations investiguées et résolues. Drapeau d’éligibilité pays par SKU basculé pour retirer proprement les produits non éligibles plutôt que de les laisser désapprouver.
• Jour 21 : campagne Shopping pilote lancée à 10-20% du budget steady-state attendu. Performance mesurée contre un benchmark domestique avec signaux d’enchère pays-spécifiques.
• Jours 35 à 42 : montée en charge budget si les métriques tiennent, sinon cycle de débrief et de corrections.

L’erreur dans la majorité des calendriers est la compression de la phase jours 7 à 14. Brûler la localisation, l’URL de retours ou le pipeline de flux produit un lancement avec un taux de désapprobation élevé qui prend plus de temps à corriger que celui économisé en allant vite.

Pièges courants

Les modes d’échec récurrents observés sur les déploiements Merchant Center transfrontaliers, tirés des études de cas Search Engine Land, Tinuiti et DataFeedWatch :

• Un flux, plusieurs langues : un seul flux avec titres anglais ciblant Allemagne, France et Espagne. Désapprouvé sur language mismatch dès la première revue.
• Devise et livraison incohérentes : flux en EUR, service de livraison en USD. Rejet silencieux à l’impression.
• Confusion TTC/HT : prix HT soumis à des flux UE qui attendent du TTC, ou prix TTC soumis à des flux US qui attendent du HT. Les deux produisent des désapprobations price-mismatch contre la page de destination.
• Auto-conversion en production sur des catégories à marge fine : dérive de prix visible entre l’annonce Shopping, le panier et le relevé de carte du client.
• URL retours non localisée : page retours en français servie à des clients allemands. Violation politique, perte d’éligibilité annonce.
• GTIN faux ou devinés : valeurs placeholder type 12345678901234 déclenchent un rejet automatisé, les écarts marque vs registre GS1 produisent des désapprobations répétées.
• Tarif de livraison fixe unique sur tous les pays : profitable sur la lane la moins chère, déficitaire sur les lanes les plus chères, opaque pour les chefs de produit.
• Catalogue poussé vers un pays sans filtrage d’éligibilité par SKU : 30 à 50% de taux de désapprobation qui devient plus difficile à effacer à chaque resoumission.
• Suspension au niveau du compte attribuée à un flux alors qu’elle a été déclenchée par les violations réglementaires répétées d’une seule SKU.

Conclusion

Le multi-pays Merchant Center est avant tout une discipline opérationnelle, pas un manque de fonctionnalité. La même devise et la même langue doivent tenir entre flux, paramètres de livraison et paramètres de taxe. La TVA doit être incluse là où la destination l’impose et exclue là où elle ne l’impose pas. Les retours doivent être localisés en langue et en référence juridique. L’éligibilité doit être évaluée par SKU et par pays avant que le flux n’arrive chez Google, pas après. Les règles de flux industrialisent la dérivation par pays depuis une source unique pour que les changements de catalogue se propagent proprement. Ajouter un nouveau pays demande une cadence de 4 à 6 semaines quand la base juridique et fiscale est en place, plus longtemps quand elle ne l’est pas.

Les comptes qui scalent à l’international y arrivent parce qu’ils ont investi cette couche opérationnelle une fois et l’ont maintenue. Ils tournent des dashboards de taux de désapprobation par pays, des alertes de mismatch de devise, le statut de crawl des URL de retours, des notifications de changement de taux de TVA. Les comptes qui échouent au multi-pays ont en général une configuration domestique qui marche et la croyance qu’elle fonctionnera identique dupliquée sur un nouveau pays. Elle n’y arrive presque jamais.

Sources

• Aide Google Merchant Center : « Afficher les produits dans plusieurs pays cibles », « Langues et devises supportées par pays », « Configurer les paramètres de livraison pour un compte entier », « À propos des informations fiscales pour vos produits », « Configurer vos politiques de retour pour Shopping et les fiches gratuites ».
• Google Search Central, « Données structurées de la politique de retours du marchand ».
• Search Engine Land, couverture sur l’expansion pays Merchant Center, les annonces Shopping post-Brexit, la mise en place TVA UE et IOSS.
• Search Engine Journal, guides de configuration multi-pays Merchant Center, couverture sales tax US post-Wayfair.
• Tinuiti, études de cas e-commerce transfrontalier, audits Shopping multi-pays.
• Store Growers, guides opérationnels OSS et IOSS pour vendeurs UE et non-UE.
• DataFeedWatch, guides de gestion de flux multi-pays, études d’impact de la localisation.