Attributs conversationnels Google Merchant Center : les 6 champs pour l'AI Mode

Les attributs conversationnels de Google Merchant Center sont six champs optionnels, lancés au Google Marketing Live en mai 2026. Ils aident l’AI Mode, Gemini et le Business Agent à comprendre un produit en langage naturel : questions fréquentes, pièces et accessoires, notices PDF, famille de variantes, axes de déclinaison, popularité interne.

Ils ne remplacent pas le flux Google Merchant Center. Ils ne désapprouvent pas un SKU. Google le dit explicitement : les fournir n’a aucune incidence sur l’état d’approbation des offres existantes. Ce n’est pas non plus un levier de ranking Shopping documenté. C’est une couche de faits, lue surtout par les systèmes d’IA, pour répondre, comparer et recommander.

Le timing compte pour un retailer européen. Le checkout UCP / Universal Cart reste largement US-first. Ces six champs, eux, sont déjà globaux. C’est le levier Merchant Center actionnable maintenant, avant que le parcours d’achat agentique n’arrive sur le marché.

Pourquoi le flux classique ne suffit plus

Le flux a été conçu pour matcher un titre à une requête courte. L’AI Mode répond à autre chose : une question d’achat, avec contraintes et suites (« une veste respirante pour le running sous la pluie, en 42, et le filtre qui va avec »). Un titre et une description d’une ligne ne portent pas cette matière.

Google l’a d’abord annoncé en janvier 2026, au NRF, parmi les guidelines Merchant Center pour le commerce agentic. En mai, au Google Marketing Live, la spec est devenue concrète : six attributs, documentés dans l’aide Merchant Center, disponibles dans tous les pays.

Le teaser de janvier parlait de « des dizaines » d’attributs. Six seulement sont documentés et soumis. On travaille avec la spec actuelle, pas avec une feuille de route.

Trois champs n’existaient pas dans le flux standard, parce que le format n’était pas fait pour ça :

• question_and_answer
• related_product
• document_link

Les trois autres raffinent des concepts déjà présents (item_group_id, color, size) : item_group_title, variant_option, popularity_rank.

Règle Google à appliquer dès le mapping : si une information est déjà dans description, product_highlight ou product_detail, ne pas la recopier dans les attributs conversationnels.

Cette couche s’ajoute au socle. Elle ne rattrape pas un catalogue pensé uniquement pour les Shopping Ads. Titre, GTIN, prix aligné site, stock, images : sans ça, l’IA n’a rien de solide à citer.

Les 6 attributs, un par un

1. question_and_answer - FAQ attachée au SKU

C’est le champ le plus utile à remplir en premier. Il sert aux questions qu’un acheteur pose vraiment, pas à une liste de mots-clés.

Limites officielles (spec question_and_answer) :

• jusqu’à 30 paires par produit
• 1 000 caractères par question, 1 000 par réponse
• 10 000 caractères au total pour le produit
• disponible dans tous les pays

Google interdit : prix, dates, promos, délais, nom de l’entreprise, listes de termes de recherche. Il demande des réponses factuelles, grammaticalement correctes, et une variété de questions (specs, ingrédients, contenu du colis, usage, entretien), pas cinq reformulations du même bénéfice.

Point souvent manqué : ne pas soumettre de Q&R si le même contenu est déjà dans document_link. Google indique extraire les FAQ depuis les PDF. Les deux champs en parallèle, sur le même fond, c’est du bruit.

Format TSV (une paire) :

"Est-elle compatible lave-vaisselle ?":"Oui, cycle délicat 40 °C, sans sèche."

Exemple électroménager, dans l’esprit de la documentation Google :

Quels sont les paliers de température ? Cinq paliers : 80 °C (thé vert), 92 °C (oolong), 93 °C (piston), 100 °C (ébullition).

Quelle est la capacité ? 1,7 litre, avec jauge visible.

La fonction maintien au chaud dure combien de temps ? Jusqu’à 15 minutes sur la température choisie.

Pour un catalogue de plusieurs milliers de SKU, ces paires ne se rédigent pas à la main. Elles se génèrent à partir de la fiche, des specs et des pages produit, puis se poussent en flux secondaire. C’est le type de traitement que Feed Enrich orchestre, sans toucher au prix ni à la disponibilité du flux principal.

2. document_link - PDF crawlables

URL(s) vers la documentation produit au format PDF : notice, manuel, instructions de montage, insert d’emballage, fiche technique, liste INCI. Google s’en sert pour répondre à des questions trop longues pour une description.

Limites (spec document_link) :

• jusqu’à 5 PDF par produit, 50 Mo chacun
• URL http:// ou https://, caractères ASCII, RFC 3986
• fichier réellement en PDF
• public : Googlebot sans login, sans restriction robots.txt
• le marchand doit détenir les droits d’usage marketing
• URL stable, qui n’expire pas

Ce n’est pas une plaquette marque, ni un catalogue corporate. Le document doit porter sur le produit (éventuellement une petite famille de produits liés).

Plusieurs URL, séparées par une virgule :

https://example.com/notice.pdf, https://example.com/montage.pdf

Encoder les virgules dans l’URL (%2C). Un PDF derrière un espace client ou un CDN qui bloque les bots ne sert à rien. Côté erreurs Merchant Center, c’est le même réflexe que pour les images : le fichier doit être vraiment accessible, pas seulement « présent dans le PIM ».

3. related_product - relations catalogue typées

Pas un merchandising « vous aimerez aussi ». Six types de relation, chacun avec un identifiant (id du flux ou gtin). Max 30 relations par produit. Les trois sous-attributs sont obligatoires : relationship_type, identifier_type, identifier.

part_of_set — même série / même gamme. Exemple : chaise d’un ensemble table + chaises.

required_part — indispensable au fonctionnement. Exemple : filtre d’une cafetière, batterie d’une lampe.

often_bought_with — fréquemment acheté ensemble. Exemple : coque avec un téléphone.

substitute — alternative comparable. Exemple : autre modèle d’imprimante, même usage.

different_brand — même produit, autre marque. Exemple : équivalent marque de distributeur.

accessory — accessoire optionnel. Exemple : webcam pour un desktop.

Format TSV (spec related_product) :

required_part:id:AZ7A,required_part:id:AZ7B,accessory:gtin:811571013579

Une entrée par produit lié. Ne pas lister plusieurs IDs dans le sous-attribut identifier. Caractères autorisés dans l’identifiant : alphanumériques, _ et - uniquement (pas de virgule, :, guillemets, backslash).

C’est le champ qui permet à un agent de raisonner en bundle, en pièce détachée ou en substitution, au lieu de coller un accessoire au hasard.

4. item_group_title - nom de la famille

Le title reste le nom SKU (T-shirt coton bio homme noir M). item_group_title est le nom parent (T-shirt coton bio homme). Max 150 caractères. Même valeur pour toutes les variantes du même item_group_id.

En France, item_group_id est déjà obligatoire pour les variantes (Shopping et free listings). item_group_title complète ce grouping pour l’IA : présenter d’abord la famille, puis descendre sur la variante demandée.

Sans ce titre de groupe, un agent voit N SKU voisins, pas un produit décliné.

5. variant_option - axes qui distinguent la variante

Groupe name + value (250 caractères chacun, jusqu’à 30 paires, 5 000 caractères au total). À utiliser avec item_group_id et item_group_title.

écran:XL,mémoire:512Go,couleur:quartz gris

Contrainte de cohérence : toutes les variantes d’un même groupe doivent partager les mêmes axes (name). Chaque variante se distingue par une combinaison de value unique. Ne pas renseigner variant_option si le produit n’est pas une variante.

Google recommande de continuer à envoyer aussi color, size, material, pattern, gender, age_group lorsque ces champs identifient la variante : les attributs classiques servent aussi aux produits non-variantes, variant_option dit à l’IA quels axes font vraiment la maille.

C’est le champ qui répond à « la même veste, en 42, bleu marine ».

6. popularity_rank - percentile interne, pas une note

Float de 0 à 100, décimale avec un point (.). Exemple : 95.5.

C’est votre classement de popularité sur votre inventaire (ventes, volume, performance boutique), pas une note Trustpilot, pas un ranking Google. Plus le nombre est élevé, plus le produit performe par rapport au reste du catalogue.

Google s’en sert pour les formulations du type « vos best-sellers running ». Un 12.3 n’est pas une erreur : c’est un produit de fond de catalogue. Mieux vaut un percentile honnête, recalculé régulièrement, qu’un 99 partout.

Comment les envoyer

Trois voies, d’après Google :

1. Flux secondaire (recommandé) : colonnes conversationnelles uniquement, jointure sur id / offer_id. Le flux principal (prix, stock, titre Shopping) ne bouge pas.
2. Flux primaire : possible, mais on mélange donnée transactionnelle et couche IA.
3. Merchant API : champs questionsAndAnswers, documentLinks, relatedProducts, variantOptions, itemGroupTitle, popularityRank. Les client libraries n’étaient pas encore à jour au moment du rollout ; le workaround documenté est de passer par des custom attributes le temps que les SDK suivent.

Préférer le TSV au CSV : les Q&R et les relations sont pleines de virgules et de deux-points. Dans Google Sheets, échapper , : \ dans les valeurs de sous-attributs. On peut aussi éclater question_and_answer ou related_product en plusieurs colonnes du même nom.

Un formatage incorrect sur cette couche ne désapprouve pas le SKU Shopping. Ça ne veut pas dire que Google lira n’importe quoi : une URL PDF inaccessible, un identifiant related_product introuvable dans le flux, ou des axes de variante incohérents dans un groupe, et le champ est simplement inutilisable.

Par où commencer (sans traiter 50 000 SKU)

Le socle reste le flux classique. Les attributs conversationnels ne compensent pas un titre vide ou un GTIN faux. C’est le même constat que sur ce qui a changé sur le flux produit en 2026 : Performance Max, Meta et les agents lisent le même catalogue. La couche conversationnelle s’ajoute ; elle ne dispense pas du reste.

Ordre de travail réaliste :

1. Segmenter le top 5–10 % du catalogue (trafic Shopping, marge, ou best-sellers internes). C’est aussi la base d’un popularity_rank crédible.
2. question_and_answer sur ce segment, à partir des FAQ déjà sur les fiches, du SAV et des specs. Pas de slogans.
3. related_product là où le merchandising existe déjà (accessoires, pièces, cross-sell). Typer la relation, ne pas tout mettre en often_bought_with.
4. document_link sur l’électro, le meuble à monter, le bricolage, la beauté réglementée : les PDF existent souvent, ils ne sont juste pas dans le flux.
5. item_group_title + variant_option sur la mode et l’électronique, où la maille variante est déjà un sujet Merchant Center.
6. popularity_rank en dernier, calculé (ventes, commandes, ou un proxy interne), pas saisi à la main SKU par SKU.

Un audit de flux reste le bon point d’entrée : complétude du socle, puis faisabilité de la couche conversationnelle sur le segment qui vaut le coup. Le détail opérationnel (titres, attributs classiques, préparation AEO) est aussi dans le guide d’optimisation des flux produits.

FAQ

Les attributs conversationnels sont-ils obligatoires ?  Non. Optionnels, complémentaires, sans effet sur l’approbation des produits déjà dans Merchant Center.

Est-ce que ça améliore le ranking Shopping ?  Google ne le documente pas. L’usage déclaré : surfaces IA (AI Mode, et plus largement les expériences conversationnelles), et un complément aux expériences de recherche classiques. Traiter ça comme un boost Performance Max serait de la spéculation.

Faut-il les mettre dans le flux principal ?  Possible, pas souhaitable. Un flux secondaire limite le risque opérationnel et sépare clairement donnée d’offre et donnée de compréhension.

Peut-on remplir les Q&R et envoyer aussi le PDF ?  Oui, si les contenus sont distincts. Si la FAQ est déjà dans le PDF, Google demande de ne pas renvoyer question_and_answer.

Le checkout agentique (UCP) est-il lié ?  Lié dans la stratégie Google, pas dans le même livrable. UCP gère le parcours d’achat dans les surfaces IA. Les attributs conversationnels gèrent la compréhension produit. En Europe, on peut (et on devrait) remplir les seconds sans attendre le premier.

Par quel champ commencer si on n’en fait qu’un ?  question_and_answer sur le top catalogue. C’est le plus proche des questions réelles, et souvent le plus simple à sourcer (fiches, SAV, notices).