Paramètres standard des flux produits XML

La plupart des articles sur les flux XML partent du principe que vous vendez des t-shirts.

Cette hypothèse avait du sens il y a dix ans, lorsqu’un « flux produits » désignait un fichier Google Shopping et rien d’autre. Ce n’est plus le cas. Un concessionnaire automobile, un site d’offres d’emploi, un groupe hôtelier, un portail immobilier et une plateforme de paris mènent tous aujourd’hui des campagnes publicitaires alimentées par des flux, et aucun d’eux ne renseigne size ou gtin. Ils renseignent des numéros VIN, des codes IATA, des nombres de chambres, des types de contrat et des heures de coup d’envoi.

Les mécanismes sous-jacents sont identiques. Les paramètres ne le sont pas.

Ce guide couvre les deux : les règles structurelles qui s’appliquent à tout flux XML quel que soit le secteur, et les ensembles d’attributs propres à chacun des grands types de flux (retail, inventaire local, véhicules, voyage, immobilier, emploi, et inventaire limité dans le temps comme les matchs, les événements et les séances). Avec du XML fonctionnel pour chacun.

1. Ce qu’est réellement un flux XML

Un flux XML est un fichier structuré qui décrit un inventaire de manière à ce que des machines puissent l’exploiter sans interprétation humaine. Une plateforme récupère le fichier selon un calendrier, l’analyse et crée des fiches, des annonces ou des résultats de recherche à partir de ce qu’elle y trouve.

Le format compte moins que ce que l’on croit généralement. Ce qui compte, c’est le contrat : chaque destination publie une spécification qui indique les champs obligatoires, les valeurs autorisées et son comportement lorsqu’elles sont erronées. Le flux est votre part de ce contrat.

Deux conséquences en découlent, et elles expliquent pourquoi les flux sont plus difficiles qu’il n’y paraît :

Le contrat dépend de chaque destination. La spécification produits de Google, la spécification de catalogue de Meta et le XML d’offres d’emploi d’Indeed n’ont presque aucun nom de champ en commun. Un même catalogue source doit être transformé différemment pour chacune.

Les infractions échouent le plus souvent en silence. Un champ mal formé casse rarement le fichier. Il entraîne le refus d’un article, déclasse une fiche ou supprime un attribut de l’annonce, et rien dans votre tableau de bord de campagne ne vous le signale.

2. L’anatomie du fichier

La plupart des flux XML publicitaires utilisent RSS 2.0 avec une extension d’espace de noms. La structure comporte toujours les trois mêmes niveaux :

<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:g="http://base.google.com/ns/1.0">
  <channel>
    <title>Example Store — Product Feed</title>
    <link>https://example.com</link>
    <description>Full catalogue, updated hourly</description>

    <item>
      <!-- one inventory item -->
    </item>

  </channel>
</rss>

• La déclaration XML définit l’encodage. En pratique, elle doit être UTF-8 ; toute autre valeur corrompt les caractères dans les catalogues non anglophones et constitue la cause la plus fréquente de titres produits turcs, allemands ou tchèques altérés.
• La déclaration d’espace de noms (xmlns:g="...") est ce qui rend <g:price> valide. Si vous l’omettez, chaque élément préfixé est ignoré silencieusement : le flux est analysé, mais presque rien n’est importé.
• <channel> contient les métadonnées du flux.
• <item> représente une unité d’inventaire. Ce que recouvre « une unité » est une décision, pas une évidence : un SKU, une variante, un véhicule, une offre d’emploi, un hôtel, une rencontre.

Tous les secteurs n’utilisent pas cette forme. Les flux d’offres d’emploi utilisent <source><job>, et certaines marketplaces définissent entièrement leurs propres éléments racines. La logique à trois niveaux (document, conteneur, élément répété) reste valable dans tous les cas.

3. Le socle universel

Sept paramètres apparaissent dans pratiquement toutes les spécifications de flux jamais rédigées, sous des noms différents. Si vous les comprenez, vous pouvez lire n’importe quelle spécification.

Trois règles concernant l’identifiant s’appliquent partout et causent plus de dégâts que n’importe quel autre champ :

1. Il doit être stable. Si votre identifiant est régénéré à l’export (dérivé de l’ordre des lignes, d’un horodatage, d’un hash d’un contenu qui change), chaque synchronisation détruit l’historique de performance accumulé de l’article, qui repart de zéro.
2. Il doit être unique. Les identifiants en double entraînent la suppression des lignes suivantes sans message d’erreur. Les articles disparaissent tout simplement.
3. Il doit correspondre à ce qu’envoie votre pixel ou votre tag. Le rapprochement du catalogue Meta, le remarketing dynamique de Google et tous les produits de retargeting reposent sur le fait que l’identifiant du flux et celui de l’événement du site soient la même chaîne. C’est la raison la plus fréquente pour laquelle le retargeting dynamique « ne fonctionne pas ».

4. Paramètres retail / e-commerce

C’est la spécification la mieux documentée, et la base dont s’inspirent la plupart des autres secteurs.

Obligatoires

Identifiants

brand, gtin, mpn et identifier_exists. Le GTIN est le champ qui détermine si votre produit est rattaché au graphe de connaissances produits de Google, et donc s’il apparaît ou non dans les surfaces de comparaison et de shopping par IA. Il n’est pas facultatif en pratique, quoi qu’en dise la spécification.

Variantes

item_group_id, item_group_title, color, size, size_type, size_system, material, pattern, gender, age_group.

Les variantes sont un sujet à part entière ; en résumé, item_group_id doit être identique dans tout un groupe et dérivé de données sources stables, et gender et age_group sont constants au sein d’un groupe, contrairement à color et size.

Catégorisation

google_product_category (la taxonomie de Google, identifiant ou chemin complet), product_type (votre propre taxonomie : c’est le champ qui rend possible la structuration des campagnes, et il est libre, alors utilisez-le).

Commercial

sale_price, sale_price_effective_date, unit_pricing_measure, unit_pricing_base_measure, installment, subscription_cost, loyalty_program.

Logistique

shipping, shipping_weight, shipping_length / _width / _height, shipping_label, transit_time_label, min_handling_time, max_handling_time, tax.

Pilotage des campagnes

excluded_destination, included_destination, ads_redirect, custom_label_0 à custom_label_4.

Les cinq étiquettes personnalisées sont les champs les plus sous-utilisés de toute la spécification. Elles n’ont aucune signification pour Google : elles existent uniquement pour vous permettre de segmenter. Tranches de marge, profondeur de stock, saisonnalité, ancienneté du produit, niveau de performance GA4. Si votre structure de campagne ne peut pas exprimer une règle métier, c’est généralement pour cette raison.

Médias

additional_image_link, lifestyle_image_link, virtual_model_link, video_link.

Un article retail minimal mais complet

<item>
  <g:id>KRC-4210-BLK</g:id>
  <g:title>Karaca Fine Pearl 6-Person Dinner Set — Black</g:title>
  <g:description>26-piece porcelain dinner set for six. Dishwasher and microwave safe.</g:description>
  <g:link>https://example.com/urun/fine-pearl-6-kisilik</g:link>
  <g:image_link>https://cdn.example.com/krc-4210-blk-01.jpg</g:image_link>
  <g:additional_image_link>https://cdn.example.com/krc-4210-blk-02.jpg</g:additional_image_link>
  <g:video_link>https://cdn.example.com/video/krc-4210.mp4</g:video_link>
  <g:availability>in_stock</g:availability>
  <g:price>4299.00 TRY</g:price>
  <g:sale_price>3499.00 TRY</g:sale_price>
  <g:sale_price_effective_date>2026-11-24T00:00+0300/2026-12-01T23:59+0300</g:sale_price_effective_date>
  <g:brand>Karaca</g:brand>
  <g:gtin>8680150042109</g:gtin>
  <g:condition>new</g:condition>
  <g:google_product_category>672</g:google_product_category>
  <g:product_type>Home &amp; Kitchen &gt; Dinnerware &gt; Dinner Sets</g:product_type>
  <g:custom_label_0>high-margin</g:custom_label_0>
  <g:custom_label_1>bf-2026</g:custom_label_1>
</item>

Notez les & et > dans product_type. Les caractères & non échappés dans les URL et les chemins de catégorie sont la cause la plus fréquente de fichiers XML qui ne peuvent pas du tout être analysés.

5. Ce qui a changé en 2026

Trois changements de la spécification des données produits de Google méritent d’être traités dès maintenant plutôt qu’à l’échéance.

La résolution minimale des images est désormais de 500x500 px pour image_link et additional_image_link, pour toutes les catégories et toutes les méthodes marketing. Les avertissements ont commencé à apparaître dans Merchant Center en avril 2026 ; l’application commence le 31 janvier 2027. Google peut agrandir automatiquement certaines images plus petites, mais considérer cela comme une solution est une erreur : les images agrandies ont l’air agrandies, et la qualité de l’image est une variable du taux de clics.

video_link est actif et diffusé. Les vidéos soumises via cet attribut sont devenues éligibles à la diffusion à partir du 30 juin 2026, avec une validation des règles et de la qualité. Les erreurs bloquent la vidéo mais pas l’offre : c’est donc un champ peu risqué à renseigner. La plupart des catalogues n’ont pas de vidéo produit pour la majorité de leurs SKU, et c’est précisément pour cela que les générer à grande échelle à partir des données du flux constitue désormais un écart concurrentiel plutôt qu’un simple plus.

Les paramètres de livraison au niveau produit ont été étendus. handling_cutoff_time définit une heure limite quotidienne de traitement des commandes, et minimum_order_value précise le montant minimum de commande pour la livraison. L’attribut shipping a également gagné les sous-attributs loyalty_program_label et loyalty_tier_label pour les avantages de livraison liés aux programmes de fidélité.

La tendance est constante : Google continue de faire descendre au niveau de l’article des détails qui se trouvaient auparavant au niveau du compte. Tout ce qui s’exprime article par article peut être automatisé par une couche de gestion de flux, ce qu’un processus manuel ne peut pas faire.

6. La carte des secteurs

Le retail est une ligne de ce tableau, pas le tableau entier.

Deux règles structurelles à bien assimiler avant de construire quoi que ce soit :

Un catalogue Meta ne contient qu’un seul type d’inventaire. Vous ne pouvez pas mélanger hôtels et produits. Si vous vendez les deux, il vous faut deux catalogues.

Google sépare les secteurs au niveau de la source de données. Une source de données de véhicules doit cibler uniquement les annonces de véhicules. Soumettre des véhicules dans une source de données Shopping produit des refus, pas des fiches, et les sources de véhicules ne doivent pas contenir de pièces détachées ni d’accessoires, qui ont leur place dans un flux produits classique.

7. Flux de véhicules

L’automobile est le secteur où l’approche « il suffit d’utiliser la spécification retail » échoue le plus visiblement. Une voiture est un objet physique unique doté d’un identifiant légal, pas un SKU avec une profondeur de stock.

Les attributs de véhicules de Google s’ajoutent au socle commun :

<item>
  <g:id>STK-88214</g:id>
  <g:title>2023 Volkswagen Passat 1.5 TSI Business DSG</g:title>
  <g:description>Single owner, full service history, no accident record.</g:description>
  <g:link>https://example.com/ilan/88214</g:link>
  <g:image_link>https://cdn.example.com/88214-01.jpg</g:image_link>
  <g:price>1450000.00 TRY</g:price>
  <g:condition>used</g:condition>
  <g:brand>Volkswagen</g:brand>
  <g:model>Passat</g:model>
  <g:trim>1.5 TSI Business DSG</g:trim>
  <g:year>2023</g:year>
  <g:vin>WVWZZZ3CZPE000000</g:vin>
  <g:mileage>
    <g:value>42500</g:value>
    <g:unit>km</g:unit>
  </g:mileage>
  <g:body_style>sedan</g:body_style>
  <g:color>Grey</g:color>
  <g:vehicle_fulfillment>
    <g:option>in_store</g:option>
    <g:store_code>IST-01</g:store_code>
  </g:vehicle_fulfillment>
</item>

Ce qui rend les flux de véhicules différents sur le plan opérationnel :

• L’inventaire est à l’unité. Chaque article est un exemplaire unique. Lorsqu’il est vendu, il doit quitter le flux immédiatement, pas à la synchronisation du lendemain. Les fiches de véhicules obsolètes gaspillent des clics à CPC élevé sur des voitures qui n’existent plus et dégradent la qualité du compte.
• La fréquence de rafraîchissement fait toute la différence. Des cycles de rafraîchissement de quatre heures sont la pratique standard dans l’automobile, pas une optimisation.
• La cohérence avec la page de destination est contrôlée. Le prix et le kilométrage du flux doivent correspondre exactement à la page de détail du véhicule. Un changement de prix à l’échelle du concessionnaire, mis à jour sur le site mais pas dans le flux, provoque une vague de refus en quelques heures.
• Les annonces d’inventaire automobile de Meta utilisent un vocabulaire de champs distinct (state_of_vehicle, exterior_color, transmission, drivetrain, dealer_id) : les mêmes données sources nécessitent donc une transformation différente par canal.

8. Flux voyage

Le voyage se divise en trois types de catalogues distincts, et l’erreur consiste à les traiter comme un seul.

Hôtels

Le flux des établissements est relativement statique : nom, description, adresse, coordonnées, nombre d’étoiles, images, prix de départ. Ce qui bouge, ce sont la disponibilité et les tarifs, c’est pourquoi les configurations hôtelières associent généralement un flux statique des établissements à des flux dynamiques de types de chambres et de tarifs.

Paramètres principaux : hotel_id, name, description, brand, url, image, latitude, longitude, address (avec city, region, country, postal_code), base_price, currency, star_rating, neighborhood, phone, guest_ratings.

<item>
  <g:hotel_id>HTL-BDR-114</g:hotel_id>
  <g:name>Blue Bay Resort Bodrum</g:name>
  <g:description>Seafront resort with private beach, three restaurants and a spa.</g:description>
  <g:url>https://example.com/otel/blue-bay-bodrum</g:url>
  <g:image>https://cdn.example.com/htl-114-01.jpg</g:image>
  <g:latitude>37.0344</g:latitude>
  <g:longitude>27.4305</g:longitude>
  <g:address>Yalıkavak Mah. Sahil Cad. 12, Bodrum, Muğla, TR, 48990</g:address>
  <g:base_price>4200.00 TRY</g:base_price>
  <g:star_rating>5</g:star_rating>
  <g:neighborhood>Yalıkavak</g:neighborhood>
</item>

Vols

L’article est une liaison, pas un siège. L’identité est la paire origine-destination : origin_airport et destination_airport sous forme de codes IATA, plus price, url, image, description. Les prix sont généralement des prix « à partir de » et changent en permanence, ce qui fait de la fréquence de mise à jour la contrainte déterminante.

Destinations

L’article est un lieu vers lequel vous vendez des voyages : destination_id, name, address, neighborhood, types, price, url, image. Utile pour la prospection en haut de tunnel, lorsque le voyageur a une intention mais pas d’établissement précis en tête.

Le problème récurrent du voyage est que le prix et la disponibilité sont calculés, et non stockés. Le « prix » d’un hôtel dépend des dates, du nombre d’occupants et de la durée du séjour ; celui d’un vol dépend du moment où vous le demandez. Les flux veulent un seul nombre. Choisir lequel (le plus bas disponible dans les 30 prochains jours, le plus bas pour le week-end à venir, la moyenne) est une décision commerciale qui détermine discrètement la performance de vos annonces, et elle mérite d’être prise délibérément plutôt que de se contenter de ce que l’export a produit par défaut.

9. Flux immobiliers

Structurellement proches des véhicules : des biens physiques uniques, un inventaire à l’unité, une forte valeur par clic et une fiche qui doit disparaître dès que le bien est pris.

Paramètres principaux : home_listing_id, name, description, address, latitude, longitude, url, image, price, currency, property_type (appartement, maison, terrain, local commercial), listing_type (vente, location, neuf), num_beds, num_baths, area_size, area_unit, year_built, availability, agent_name, agent_phone.

<item>
  <g:home_listing_id>EMK-2291</g:home_listing_id>
  <g:name>3+1 Apartment with Sea View — Kadıköy</g:name>
  <g:description>Renovated 3+1 apartment, 4th floor, elevator, closed parking.</g:description>
  <g:address>Caferağa Mah., Kadıköy, İstanbul, TR</g:address>
  <g:latitude>40.9862</g:latitude>
  <g:longitude>29.0299</g:longitude>
  <g:url>https://example.com/ilan/2291</g:url>
  <g:image>https://cdn.example.com/emk-2291-01.jpg</g:image>
  <g:price>12500000.00 TRY</g:price>
  <g:property_type>apartment</g:property_type>
  <g:listing_type>for_sale</g:listing_type>
  <g:num_beds>3</g:num_beds>
  <g:num_baths>2</g:num_baths>
  <g:area_size>135</g:area_size>
  <g:area_unit>sq_m</g:area_unit>
  <g:availability>available</g:availability>
</item>

Un point qui n’est pas un problème de flux mais qui bloquera votre campagne : le logement est une catégorie publicitaire restreinte sur Meta. Les campagnes qui promeuvent des annonces immobilières doivent être déclarées dans la catégorie publicitaire spéciale logement, ce qui restreint les options de ciblage. Le catalogue peut être parfait, la campagne échouera quand même si ce paramètre n’est pas défini.

10. Flux d’offres d’emploi

Le recrutement utilise une structure de document totalement différente (<source> et <job> plutôt que <rss> et <item>), et cela vaut la peine de la voir, car elle montre que le « flux XML » est un modèle, et non un schéma unique.

<?xml version="1.0" encoding="UTF-8"?>
<source>
  <publisher>Example Company</publisher>
  <publisherurl>https://example.com</publisherurl>
  <lastBuildDate>Wed, 12 Aug 2026 09:00:00 GMT</lastBuildDate>

  <job>
    <title><![CDATA[Senior Backend Engineer]]></title>
    <date><![CDATA[Mon, 10 Aug 2026 08:00:00 GMT]]></date>
    <referencenumber><![CDATA[ENG-4471]]></referencenumber>
    <url><![CDATA[https://example.com/careers/eng-4471]]></url>
    <company><![CDATA[Example Company]]></company>
    <city><![CDATA[İstanbul]]></city>
    <state><![CDATA[İstanbul]]></state>
    <country><![CDATA[TR]]></country>
    <postalcode><![CDATA[34394]]></postalcode>
    <description><![CDATA[<p>We are hiring a senior backend engineer to work on our data pipeline...</p>]]></description>
    <salary><![CDATA[120000 - 160000 TRY monthly]]></salary>
    <jobtype><![CDATA[fulltime]]></jobtype>
    <category><![CDATA[Engineering]]></category>
    <experience><![CDATA[5+ years]]></experience>
  </job>

</source>

Quatre règles propres aux flux d’offres d’emploi :

1. CDATA est la norme, pas l’exception. Les descriptions de postes contiennent du HTML, des esperluettes et des apostrophes. Encapsuler chaque champ dans <![CDATA[...]]> évite toute une catégorie d’erreurs d’analyse.
2. La localisation doit comporter au minimum la ville, la région et le pays. Sans eux, l’offre perd par défaut sa visibilité organique sur les principaux agrégateurs.
3. Les postes pourvus doivent être supprimés, pas marqués comme clos. Il n’existe pas d’équivalent à availability. La présence dans le flux est le signal de disponibilité, et les agrégateurs pénalisent les flux qui contiennent des offres obsolètes.
4. Une langue, une entrée. Une offre publiée en deux langues nécessite deux entrées distinctes avec des numéros de référence différents.

Indépendamment du flux, ce sont les données structurées JobPosting en JSON-LD sur la page carrières qui rendent un poste éligible aux fiches d’offres d’emploi dans les résultats de recherche. Les deux sont complémentaires : le flux gère la diffusion vers les agrégateurs, les données structurées gèrent la recherche organique. La plupart des équipes de recrutement font l’un et pas l’autre.

11. Inventaire limité dans le temps

La catégorie de flux la plus intéressante n’a pas de spécification officielle, car les plateformes ne l’ont jamais anticipée : un inventaire dont l’attribut déterminant est le quand, et non le quoi.

Matchs de football. Concerts. Séances de cinéma. Départs de vols. Lots aux enchères. Créneaux de réservation au restaurant. Créneaux de livraison.

Ils ont toutes les propriétés des produits (une identité, un prix, une image, une page de destination), plus une pour laquelle la spécification retail n’a aucun champ : une durée de vie mesurée en heures. Une rencontre dont le coup d’envoi a déjà été donné n’est pas « en rupture de stock », elle n’a plus de sens.

L’approche qui fonctionne consiste à les modéliser comme des produits de catalogue standard et à encoder la dimension temporelle dans des champs que la plateforme comprend déjà :

<item>
  <g:id>MTC-2026-08-16-GS-FB</g:id>
  <g:title>Galatasaray - Fenerbahçe | Super League, Week 2</g:title>
  <g:description>Saturday 16 August, 19:00. Live odds and in-play betting.</g:description>
  <g:link>https://example.com/mac/2026-08-16-gs-fb</g:link>
  <g:image_link>https://cdn.example.com/creatives/mtc-2026-08-16-gs-fb.jpg</g:image_link>
  <g:availability>in_stock</g:availability>
  <g:price>1.00 TRY</g:price>
  <g:product_type>Football &gt; Super League &gt; Week 2</g:product_type>
  <g:custom_label_0>2026-08-16</g:custom_label_0>
  <g:custom_label_1>derby</g:custom_label_1>
  <g:custom_label_2>ms1-2.10</g:custom_label_2>
  <g:expiration_date>2026-08-16T19:00+0300</g:expiration_date>
</item>

Trois éléments font fonctionner cette approche :

• expiration_date ou une règle de suppression équivalente, pour que l’article quitte le catalogue au coup d’envoi plutôt qu’à la synchronisation planifiée suivante.
• Des étiquettes personnalisées portant la dimension temporelle, pour pouvoir structurer les campagnes autour de « ce week-end », « derby » ou « cotes supérieures à 2.0 ».
• Une création par article. C’est là que l’approche bloque généralement. Un calendrier de plusieurs centaines de matchs par semaine nécessite plusieurs centaines d’images, chacune affichant les équipes, la date, l’heure et les cotes actuelles. Aucune équipe design ne produit cela. Générer la création à partir de la ligne du flux est la seule méthode qui suit le rythme, et c’est exactement ainsi que Bilyoner a lancé des annonces catalogue pour la première fois et augmenté son ROAS de 49 %.

Si votre inventaire a une heure de début, il a sa place dans un catalogue. L’obstacle est presque toujours le format, pas le concept.

12. Flux d’inventaire local

L’inventaire local se situe entre le retail et les secteurs spécifiques : les mêmes produits, décrits pour chaque point de vente physique.

Paramètres : id, store_code, quantity, price, sale_price, sale_price_effective_date, availability, pickup_method (achat, réservation, livraison en magasin, non pris en charge), pickup_sla (le jour même, le lendemain, plusieurs jours).

Le point structurel est que le flux local est un complément, et non un remplacement. Il fait référence aux articles du flux produits principal par leur id et ajoute des informations propres à chaque magasin. Un article, de nombreux magasins, de nombreuses lignes.

Une remarque 2026 à souligner : les versions en ligne et en magasin d’un même produit ayant des prix ou une disponibilité différents nécessitent désormais des identifiants produits distincts au lieu d’être regroupées sous un seul. Les flux qui les avaient fusionnées sont invités à les séparer.

13. Règles de formatage

Elles s’appliquent à tous les types de flux de cet article et, à elles toutes, expliquent la grande majorité des flux qui échouent purement et simplement.

Encodage. UTF-8, toujours, déclaré dans la déclaration XML et servi avec un en-tête Content-Type correspondant. Une incohérence entre l’encodage déclaré et l’encodage réel corrompt tous les caractères non ASCII.

Échappement. Cinq caractères doivent être échappés dans le contenu XML : & → &, < → <, > → >, " → ", ' → '. Les esperluettes non échappées dans les URL de tracking sont la première cause de flux qui ne peuvent pas être analysés. L’alternative est CDATA, pratique standard dans les flux d’offres d’emploi et utile partout où les descriptions contiennent du balisage.

Dates. ISO 8601 avec un décalage horaire explicite. 2026-08-16T19:00+0300, et non 16.08.2026 19:00. Les flux qui desservent plusieurs marchés depuis une source sans fuseau horaire produisent des articles qui expirent des heures trop tôt ou trop tard.

Prix. Valeur et devise ISO 4217, point décimal et non virgule, sans séparateur de milliers. 4299.00 TRY. Et le prix du flux doit correspondre à la page de destination : la plupart des plateformes le vérifient par exploration.

Les valeurs énumérées sont sensibles à la casse et au format, et elles diffèrent selon les plateformes. Google attend in_stock ; Meta attend in stock. Cette seule différence a cassé plus d’imports de catalogue que n’importe quelle autre. Ne supposez jamais qu’une valeur énumérée est transposable d’une destination à l’autre.

Mise à disposition du fichier. Compression gzip pour les fichiers volumineux, URL HTTPS stable, pas de barrière d’authentification sauf si la plateforme la prend explicitement en charge, et un serveur qui répond dans le délai imparti par la plateforme. Une URL de flux derrière la protection anti-bots de Cloudflare est une URL de flux qui n’est pas récupérée.

La fréquence de mise à jour doit suivre la volatilité des données sous-jacentes, et non une convention : toutes les heures ou plus souvent pour les cotes, les prix des vols et les stocks retail à rotation rapide ; toutes les quelques heures pour les véhicules et l’immobilier ; une fois par jour pour les catalogues stables.

14. XML, CSV, JSON ou API

Le XML reste le format par défaut pour tout ce qui comporte de l’imbrication : c’est pourquoi les flux de véhicules, de voyage et de retail riches en données de livraison sont généralement en XML, tandis que les catalogues de mode simples sont souvent en TSV. Notez aussi que plusieurs grandes destinations évoluent vers une ingestion prioritairement par API : considérer le fichier comme votre seule voie d’intégration constitue donc un risque à moyen terme.

Si vos titres contiennent des virgules (et les titres avec couleur et taille en contiennent presque toujours), préférez le TSV au CSV. Toute une catégorie de bugs d’analyse disparaît.

15. Checklist avant lancement

• [ ] Le fichier passe un validateur XML avant d’approcher la moindre plateforme
• [ ] UTF-8 déclaré et servi correctement ; les caractères non ASCII s’affichent correctement
• [ ] Chaque & de chaque URL est échappé, ou le champ est encapsulé dans CDATA
• [ ] Identifiants uniques, stables d’une synchronisation à l’autre et identiques aux événements de votre pixel ou tag
• [ ] Tous les attributs obligatoires sont présents pour la destination cible, vérifiés par rapport à la spécification de cette destination et non à une spécification générale
• [ ] Valeurs énumérées transformées pour chaque destination, et non copiées
• [ ] Prix exactement identiques à ceux des pages de destination, y compris la devise et le traitement des taxes
• [ ] Dates au format ISO 8601 avec décalage horaire
• [ ] Images d’au moins 500x500, accessibles en HTTPS sans redirection
• [ ] Les articles vendus, pourvus, expirés ou partis quittent le flux au bon rythme
• [ ] La fréquence de mise à jour correspond à la vitesse réelle d’évolution des données sous-jacentes
• [ ] L’URL du flux est publiquement accessible et n’est pas bloquée par une protection anti-bots
• [ ] Une règle de surveillance existe pour les variations inattendues du nombre d’articles

16. FAQ

Le XML est-il toujours le bon format en 2026 ?
Pour tout ce qui comporte des données imbriquées, oui. Pour les catalogues plats, le TSV est plus simple et moins fragile. Pour les besoins en temps réel, une intégration par API surpasse n’importe quel fichier. Le format doit suivre les données, pas l’habitude.

Puis-je utiliser un seul flux pour toutes les plateformes ?
Une seule source, oui. Un seul fichier, non. Les noms de champs, les valeurs énumérées, les limites de caractères et les attributs obligatoires diffèrent selon la destination, et ces différences ne sont pas cosmétiques. L’architecture viable est un catalogue de référence unique, avec des transformations propres à chaque canal appliquées à l’export.

Et si mon inventaire n’est pas constitué de produits ?
Il vous faut alors la spécification de votre secteur, et non celle du retail. Véhicules, hôtels, vols, destinations, biens immobiliers et offres d’emploi ont tous la leur. Et si votre inventaire est quelque chose pour lequel aucune plateforme n’a de spécification (matchs, séances, créneaux, lots), vous le modélisez comme des produits et encodez la dimension manquante dans les champs existants.

À quelle fréquence le flux doit-il être mis à jour ?
Aussi souvent que les données sous-jacentes changent de manière significative. Un véhicule vendu ce matin et toujours en publicité cet après-midi dépense de l’argent pour rien.

Ai-je besoin de GTIN ?
Pour le retail, en pratique oui. Le GTIN est ce qui relie votre article aux connaissances produits d’une plateforme, ce qui détermine de plus en plus si vous apparaissez ou non dans les surfaces de comparaison et les résultats de shopping pilotés par l’IA. Pour les véhicules, l’immobilier et les offres d’emploi, les champs d’identité équivalents sont vin, l’identifiant de l’annonce et le numéro de référence.

Là où ça se complique

Aucune des règles de cet article n’est difficile en soi. La difficulté, c’est qu’il y en a plusieurs centaines, qu’elles diffèrent selon la destination, qu’elles changent sans prévenir et que leur violation échoue en silence.

Un même catalogue exporté vers Google, Meta, TikTok et trois marketplaces, ce sont six contrats différents à satisfaire simultanément à partir d’une source unique de vérité. Le faire à la main signifie maintenir six fichiers et les réconcilier à chaque modification du catalogue.

C’est la couche pour laquelle Feedance a été conçu : des règles de flux pour normaliser les attributs à la source, des exports par canal qui appliquent la bonne transformation pour chacune des plus de 200 destinations sans toucher à vos données sources, Feed Protection pour détecter les attributs manquants et les variations inattendues du nombre d’articles avant qu’une plateforme ne le fasse, et une Creative Suite qui génère une image ou une vidéo par ligne de flux pour les catalogues où la production manuelle n’a jamais été réaliste.

Il prend en charge les secteurs hors retail comme des citoyens de première classe, et non comme des cas secondaires : inventaire voyage avec tarifs en direct, catalogues de paris avec données d’horaires des matchs, canaux de diffusion automobile, immobilier et emploi.

Si vous voulez savoir où en est votre flux actuel avant de modifier quoi que ce soit, notre outil gratuit d’audit de flux l’évalue gratuitement sur sa complétude, la qualité de ses données et sa santé technique. Ou planifiez une démo de 15 minutes et nous l’examinerons ensemble.

Dernière révision : août 2026. Les spécifications des plateformes changent fréquemment ; vérifiez les exigences actuelles dans la documentation officielle de chaque destination avant la mise en œuvre.