Envoyez à Microsoft les produits qui méritent d’être vus.

« Bing Ads » est l'ancien nom de ce que Microsoft a renommé en 2019 Microsoft Advertising. L'outil de catalogue produits que de nombreux annonceurs appellent encore « Bing Merchant Center » s'appelle aujourd'hui officiellement Microsoft Merchant Center (MMC). Si votre équipe, votre agence ou un vieux tableur fait encore référence à « Bing Ads », il s'agit de la même plateforme, simplement sous son nom actuel.

Les campagnes Microsoft Shopping fonctionnent comme les campagnes Google Shopping : vous ne rédigez pas d'annonces produits individuelles. Vous importez plutôt un flux produits structuré — un catalogue de titres, de prix, d'images et d'identifiants — dans une boutique Microsoft Merchant Center, et le moteur de diffusion de Microsoft assemble et diffuse automatiquement des annonces produits à partir de ce catalogue chaque fois qu'une recherche sur le Microsoft Search Network correspond aux attributs d'un produit. Selon la documentation de la Content API de Microsoft, les flux peuvent être gérés via l'application web Microsoft Advertising, envoyés via FTP/SFTP ou transmis par programmation via la Content API de type REST à l'adresse https://content.api.bingads.microsoft.com/shopping/v9.1/bmc/.

En coulisses, chaque produit envoyé est identifié par un identifiant composite construit à partir de quatre champs — channel, contentLanguage, targetCountry et offerId —, et la documentation de Microsoft indique explicitement qu'aucun de ces quatre champs ne peut être modifié une fois le produit ajouté à la boutique, car cela revient en pratique à créer un produit en double.

Connecter votre catalogue à Microsoft Merchant Center place vos produits sous les yeux des acheteurs du Microsoft Search Network, un volume de recherches qui ne recoupe pas entièrement celui de Google. Pour la plupart des annonceurs, cela signifie une portée incrémentale, et souvent un coût par clic inférieur à celui de Google Shopping, sans avoir à créer un second catalogue de zéro.

Le guide de la Content API de Microsoft indique que les campagnes Shopping et les annonces produits sont prises en charge sur un grand nombre de marchés — des États-Unis, du Canada et du Royaume-Uni à des marchés plus petits comme Malte, l'île Maurice, Chypre et les Fidji —, avec un ensemble supplémentaire de pays accessible aux clients pilotes. Cette étendue signifie qu'un seul flux bien structuré peut étendre votre présence Shopping à des marchés que vous n'avez peut-être pas priorisés sur Google.

Comme le schéma Product de Microsoft a été délibérément conçu pour être interopérable avec celui de Google, la plupart des données produits requises pour un flux Google Merchant Center — titre, prix, images, GTIN, marque, MPN — alimentent aussi vos annonces Microsoft Merchant Center, ce qui limite l'effort de configuration supplémentaire.

La documentation de la Content API de Microsoft est d'une franchise inhabituelle sur ce que son schéma emprunte à celui de Google — et sur les points où il s'en écarte discrètement. Plusieurs champs de l'objet Product n'existent que « pour la compatibilité avec Google » : l'API de Microsoft accepte additionalImageLinks, adwordsGrouping, adwordsLabels, destinations et taxes, mais sa propre documentation indique clairement que Microsoft Merchant Center n'utilise pas du tout ces champs. Si vous réutilisez un flux au format Google, ces champs sont simplement transmis sans effet côté Microsoft.

Microsoft documente aussi une fonctionnalité que Google Shopping ne propose pas sous la même forme : les Shopping Campaigns for Brands. Dans ce modèle coopératif, un fabricant importe une liste de produits ne contenant que Brand, GTIN et MPN, la relie à la boutique Microsoft Merchant Center d'un revendeur partenaire, et les deux parties peuvent ensuite enchérir sur la liste commune des produits correspondants, en partageant le coût des clics. La documentation de Microsoft précise que cette fonctionnalité est actuellement limitée aux États-Unis et au Royaume-Uni et qu'elle est en bêta ouverte pour les clients pilotes.

Autre différence pratique : Microsoft refuse explicitement et purement les produits pour adultes (« les produits pour adultes ne sont pas pris en charge et seront refusés »), et applique sa propre logique de validation des identifiants (voir la section sur les attributs obligatoires ci-dessous), indépendamment de la validation que votre flux a déjà passée chez Google.

Selon sa documentation officielle, Microsoft Merchant Center accepte votre catalogue de deux grandes manières :

1. Un fichier de flux à plat importé dans votre boutique ou votre catalogue, envoyé selon un calendrier récurrent via FTP/SFTP.
2. La Content API — une API RESTful basée sur JSON, documentée à l'adresse content.api.bingads.microsoft.com/shopping/v9.1/bmc/ — pour insérer, mettre à jour, récupérer et supprimer des produits individuels, ou les traiter en masse via le point de terminaison /products/batch.

Le point de terminaison batch de la Content API documente des limites concrètes à anticiper : une requête batch peut contenir jusqu'à 12 000 articles, mais le corps total de la requête ne peut pas dépasser 4 Mo ; Microsoft indique donc que l'on peut généralement inclure 2 000 à 6 000 offres non compressées par batch (jusqu'aux 12 000 complets si vous compressez la charge utile en gzip avec l'en-tête Content-Encoding: gzip). Les requêtes de liste sont paginées à 250 produits maximum par appel à l'aide de max-results et start-token.

Les produits résident dans une boutique (store) Microsoft Merchant Center, et une boutique peut éventuellement contenir plusieurs catalogues (indiqués avec le paramètre bmc-catalog-id lors de l'insertion). Chaque offre envoyée a une durée de validité : la documentation de Microsoft confirme que, sauf si vous définissez une expirationDate explicite, une offre expire automatiquement 30 jours après son écriture dans la boutique.

La documentation de référence de la Content API de Microsoft indique explicitement quels champs sont obligatoires pour insérer une offre, et lesquels le deviennent sous conditions. Selon la documentation officielle de la ressource Products :

Feedance construit le flux Microsoft Merchant Center directement à partir des données produits que vous gérez déjà dans votre boutique ou votre PIM, sans export manuel de tableurs. Le moteur de mapping associe vos champs sources au schéma de Microsoft, y compris les champs de l'identifiant composite (channel, contentLanguage, targetCountry, offerId) que Microsoft verrouille après le premier envoi : il est donc important de les définir correctement dès le départ.

1. Connectez votre boutique ou votre source de données (plateforme e-commerce, PIM ou export produits existant) à Feedance.
2. Mappez vos champs sur les attributs obligatoires et conditionnels de Microsoft — Feedance signale les identifiants manquants et applique automatiquement identifierExists: false lorsque la marque, le GTIN ou le MPN ne sont réellement pas disponibles, afin que vous n'accumuliez pas d'avertissements évitables.
3. Générez le flux dans la structure attendue par la Content API et l'ingestion de la boutique Microsoft, et livrez-le par import planifié du flux ou par envoi direct via l'API vers l'identifiant de votre boutique Microsoft Merchant Center.
4. Feedance surveille les statuts des produits qui en résultent — Approved, Warning, Disapproved, pending et expiring —, ce qui vous permet de voir et de corriger les itemLevelIssues sans vous connecter à l'application web Microsoft Advertising à chaque vérification.

Comme votre mapping Google Merchant Center existant couvre déjà la plupart des attributs exigés par Microsoft, connecter une seconde destination via Feedance relève généralement d'une revue des attributs, et non d'une reconstruction.

La documentation de Microsoft fixe une limite stricte : sauf si vous définissez explicitement une expirationDate, chaque offre expire automatiquement 30 jours après sa dernière écriture dans la boutique, et n'est alors plus éligible à la diffusion. Le simple renvoi du produit (même sans modifier aucun champ) remet ce compteur de 30 jours à zéro, mais uniquement si vous n'avez pas vous-même défini une date d'expiration explicite.

En pratique, cette expiration à 30 jours est un plafond, pas un objectif. Comme le prix et la disponibilité doivent correspondre à ce qui figure sur votre fiche produit en ligne — Microsoft vérifie explicitement que le price du flux correspond à celui de la page web du produit —, tout catalogue soumis à des changements de prix réguliers, des ruptures de stock ou des promotions doit être actualisé bien plus souvent qu'une fois par mois. Une cadence au moins quotidienne garantit l'exactitude de la disponibilité et des prix et évite le décalage silencieux entre le moment où un produit est épuisé et celui où votre flux le prend en compte.

La Content API de Microsoft renvoie des codes de statut concrets et documentés pour les offres problématiques, plutôt que des refus vagues. Deux exemples réels tirés directement de la documentation de référence de Microsoft sur les statuts des offres produits :

1. GtinPlusBrandRequiredWarn — « Missing one or more identifiers - The Brand and GTIN or Brand and MPN are required. » (un ou plusieurs identifiants manquants : la marque et le GTIN, ou la marque et le MPN, sont obligatoires). Il s'agit d'un avertissement, et non d'un refus pur et simple : le champ de diffusabilité de Microsoft l'indique comme « Unaffected », ce qui signifie que l'offre continue d'être diffusée, mais vous devez la corriger — soit en fournissant les vrais identifiants, soit en définissant identifierExists sur false s'il n'en existe aucun.
2. EVRejectedErr associé à un code de motif précis comme EV_39 (« Trademark content », contenu lié à une marque déposée) — il s'agit cette fois d'un refus ferme ; la documentation de Microsoft montre le champ status de l'offre défini sur « Disapproved » et servability sur « Disapproved », ce qui signifie que le produit ne sera pas diffusé tant que le contenu signalé n'aura pas été corrigé.

Au-delà des problèmes au niveau des articles, la documentation de Microsoft confirme qu'après avoir passé la validation de base, chaque offre fait l'objet de « validations et vérifications hors ligne supplémentaires, comme des vérifications éditoriales, qui peuvent prendre jusqu'à 36 heures » avant d'être éligible à la diffusion : une offre nouvellement envoyée ou mise à jour qui reste au statut « pending » pendant une journée est donc un comportement attendu, et non un bug. Une vue récapitulative au niveau de la boutique (accessible via la ressource ProductStatuses) indique les nombres d'offres approved, disapproved, expiring et pending, ce qui constitue le moyen le plus rapide d'évaluer en un coup d'œil la santé du catalogue.

1. Fournissez les trois identifiants lorsqu'ils existent. La documentation de Microsoft est explicite : si un fabricant a attribué un GTIN, une marque ou un MPN, vous devez l'inclure — omettre un identifiant connu déclenche l'avertissement GtinPlusBrandRequiredWarn, même si l'offre continue d'être diffusée. Si aucun ne s'applique réellement, définissez identifierExists sur false plutôt que de laisser les champs vides.
2. Regroupez les variantes avec itemGroupId. Pour un produit vendu en plusieurs couleurs, tailles ou motifs, la documentation de Microsoft recommande de créer une offre par variante et de les relier par un itemGroupId commun plutôt que d'essayer de regrouper toutes les options dans une seule offre.
3. Utilisez customLabel0–customLabel4 pour segmenter vos campagnes. Ces cinq champs existent précisément pour vous permettre de filtrer des sous-ensembles de votre catalogue et d'enchérir dessus dans les campagnes Microsoft Shopping.
4. Gardez des titres et descriptions sans contenu promotionnel. Ces deux champs « ne peuvent pas inclure de texte promotionnel » et font tous deux l'objet d'une vérification éditoriale : un langage promotionnel intégré au titre expose à un refus plutôt qu'il ne génère des clics.
5. Surveillez l'expiration de manière proactive. Comme les offres expirent silencieusement 30 jours après leur dernière mise à jour, sauf si vous définissez votre propre expirationDate, les flux des catalogues à faible rotation ont eux aussi besoin d'une cadence d'actualisation, même si aucune donnée produit sous-jacente n'a changé.
6. Renseignez shipping pour les annonces en Allemagne. La documentation de Microsoft indique que la livraison, le libellé de livraison et le poids d'expédition sont obligatoires spécifiquement pour un targetCountry DE — une règle facile à manquer si votre marché principal se trouve ailleurs.

« Bing Ads » est-il encore un nom de produit officiel ? Non — Microsoft a renommé Bing Ads en Microsoft Advertising en 2019. « Bing Merchant Center » s'appelle désormais Microsoft Merchant Center. La plateforme sous-jacente et le fonctionnement des campagnes Shopping n'ont pas changé ; seul le nom a changé.

Puis-je réutiliser mon flux Google Merchant Center pour Microsoft ? Dans une large mesure, oui. Le schéma Product de Microsoft reprend de nombreux noms de champs de Google Merchant Center, et plusieurs champs orientés Google (destinations, taxes, adwordsGrouping, adwordsLabels, additionalImageLinks) sont acceptés uniquement par souci de compatibilité, même si la documentation de Microsoft confirme qu'il ne les utilise pas. Vous devrez tout de même vérifier les champs obligatoires propres à Microsoft comme channel et les règles conditionnelles comme l'exigence de livraison pour l'Allemagne.

Le GTIN est-il obligatoire pour chaque produit ? Uniquement si le fabricant en a attribué un. La documentation de Microsoft exige gtin, brand et mpn lorsqu'ils existent ; s'ils n'existent réellement pas, définissez identifierExists sur false plutôt que de les laisser vides.

Que se passe-t-il si je cesse de mettre à jour mon flux ? Selon la documentation de Microsoft, chaque offre expire automatiquement 30 jours après sa dernière mise à jour (sauf si vous avez défini votre propre expirationDate), et une offre expirée n'est plus éligible à la diffusion.

Combien de temps dure la vérification après l'envoi ou la mise à jour d'un produit ? La documentation de Microsoft indique qu'après la validation de base, les offres font l'objet de vérifications hors ligne supplémentaires, dont une vérification éditoriale, qui « peuvent prendre jusqu'à 36 heures » avant que l'offre ne soit éligible à la diffusion.

Puis-je envoyer mon flux par FTP plutôt que via une API ? Oui — Microsoft Merchant Center prend en charge l'envoi récurrent de fichiers de flux en plus de la Content API basée sur JSON : les équipes sans ressources de développement peuvent donc tout de même automatiser la livraison.

Bing Ads est l'ancien nom de Microsoft Advertising, la plateforme de publicité sur les moteurs de recherche de Microsoft, renommée en 2019. Son outil de catalogue produits, souvent encore appelé Bing Merchant Center, s'appelle désormais Microsoft Merchant Center.

Les campagnes Microsoft Shopping fonctionnent de manière très similaire à Google Shopping. Au lieu de rédiger des annonces produit individuelles, les annonceurs importent un flux produits structuré, avec titres, prix, images et identifiants, dans une boutique Microsoft Merchant Center. Microsoft crée et affiche ensuite automatiquement des annonces produit lorsque des recherches sur le Microsoft Search Network correspondent à ces produits.

Les flux peuvent être soumis sous forme de fichiers via l'application web Microsoft Advertising, importés de manière planifiée par FTP ou SFTP, ou envoyés via la Content API. Le schéma produit de Microsoft est largement compatible avec celui de Google : une grande partie des mêmes données, comme le titre, le prix, l'image, le GTIN, la marque et le MPN, alimente les annonces sur les deux plateformes, même si certains champs Google sont ignorés et que les offres expirent au bout de 30 jours si elles ne sont pas actualisées.

Pour les marchands, Microsoft Shopping offre une portée au-delà de l'audience de Google, souvent à un coût par clic plus faible. Un flux complet, régulièrement mis à jour et doté d'identifiants valides aide à maintenir l'approbation des produits et empêche les offres d'expirer ou d'être rejetées.