1. À quoi sert un Product Feed
Comparé au e‑commerce classique, le Product Feed est quelque part entre :
- une « vitrine » de produits (catalogue avec prix, disponibilité, liens et médias) ;
- et un contrat technique décrivant précisément quels SKU le marchand est prêt à afficher et/ou à vendre via ChatGPT.
Dans sa spécification, OpenAI indique explicitement que le feed est la source unique de vérité sur les produits, sur laquelle s’appuient la recherche, les recommandations et la préparation des données pour le checkout.
Dans une boutique en ligne classique, l’utilisateur navigue lui‑même sur les pages, feuillette les catégories, filtre, etc. En AI‑commerce, c’est l’inverse : l’utilisateur dit simplement au modèle « trouve‑moi un cadeau numérique à moins de 30 dollars pour un ami développeur qui aime les jeux de société » — et ChatGPT détermine quels SKU de votre Product Feed conviennent, dans quel ordre les afficher et comment tout présenter sous forme de cartes puis d’Instant Checkout.
Le Product Feed résout donc plusieurs tâches à la fois.
Premièrement, il fournit à ChatGPT des données structurées pour la recherche. Le modèle s’appuie non seulement sur le titre et la description, mais aussi sur les catégories, tags, prix, disponibilité, locale, restrictions par pays.
Deuxièmement, il est la source de données pour le checkout. Lorsque ChatGPT commence à préparer une checkout_session, les ID de SKU, le prix, la devise, le seller URL et d’autres informations commerciales proviennent du feed.
Enfin, le Product Feed est un contrat formalisé entre vous et la plateforme. Vous déclarez explicitement : « voici la liste des SKU, voici ceux qui sont disponibles uniquement en recherche (discovery) et ceux qui peuvent aussi être traités via Instant Checkout ».
Pour le visualiser, dessinons un schéma simple.
flowchart TD A[GiftGenius DB] --> B[Feed Builder] B --> C["Product Feed (CSV/JSON/...)"] C --> D[OpenAI Ingestion] D --> E[Index de recherche + classement] E --> F[ChatGPT/Agent sélectionne des cadeaux] F --> G["Instant Checkout (ACP)"]
À gauche — votre base interne où vit déjà le « vrai » catalogue. À droite — ChatGPT, qui s’affiche à l’utilisateur. Au milieu — le Product Feed et les mécanismes de son ingestion et de son indexation. Tout ce que nous faisons dans ce cours se situe exactement entre A et D.
2. Formats et « physique » du Product Feed
La spécification OpenAI est assez souple quant au format des fichiers : TSV, CSV, XML et JSON sont pris en charge. C’est fait exprès pour que la plupart des systèmes existants (des monolithes maison à Shopify) puissent exporter un feed sans bricolage.
Typiquement :
- vous hébergez un fichier ou un endpoint avec le Product Feed sur votre serveur HTTPS ;
- vous enregistrez cette adresse dans le portail ChatGPT Merchants ;
- OpenAI récupère périodiquement ce feed, le valide et indexe les produits.
La documentation souligne qu’il faut mettre le feed à jour régulièrement (même toutes les 10–15 minutes) afin que les utilisateurs voient des prix et des disponibilités à jour, surtout pendant les soldes et les pics.
Dans l’exemple pédagogique GiftGenius, nous utiliserons le format JSON, car il convient bien aux développeurs TypeScript. Mais il est important de comprendre : au niveau de la spécification, OpenAI n’est pas lié à JSON ; c’est simplement plus pratique pour nous.
Un feed JSON minimal pourrait ressembler à ceci :
[
{
"id": "gg-coffee-sub-1m-usd",
"title": "Abonnement café 1 mois",
"description": "Boîte mensuelle de café en grains pour développeur.",
"price": 2900,
"currency": "usd",
"availability": "in_stock",
"link": "https://giftgenius.app/gifts/coffee-subscription-1m",
"image_link": "https://cdn.giftgenius.app/images/coffee-1m.png",
"enable_search": true,
"enable_checkout": true
}
]En réalité, il y aura plus de champs : certains obligatoires, d’autres recommandés ou optionnels. Nous allons voir comment c’est structuré.
3. Produit vs variante (SKU) : comment modéliser
L’une des questions les plus fréquentes : « Comment refléter dans le Product Feed les tailles, packs, durées d’abonnement et autres variantes d’un même produit ? »
La spécification du Product Feed travaille avec des lignes/enregistrements, chacun décrivant une configuration vendable. Le pattern architectural recommandé par l’industrie (et bien aligné avec le feed OpenAI) est le suivant : chaque configuration distincte (taille, durée d’abonnement, plan tarifaire, région) est une entrée séparée du feed, c’est‑à‑dire un SKU distinct.
Le produit de base vit dans votre modèle interne, et dans le feed vous travaillez au niveau des SKU.
Par exemple, vous avez un service avec des abonnements de 1, 3 et 6 mois. Du point de vue du product feed, ce sont des SKU différents. Si un service peut être acheté selon 20 conditions différentes, vous devez avoir 20 SKU dans le product feed.
En TypeScript, cela peut s’exprimer ainsi :
// Modèle interne GiftGenius
export interface GiftProduct {
id: string; // product_123
name: string;
description: string;
baseImageUrl: string;
}
// SKU qui ira dans le Product Feed
export interface GiftSkuFeedItem {
id: string; // product_123_usd_1m
productId: string; // référence à GiftProduct.id
title: string;
description: string;
price: number; // en unités minimales (centimes)
currency: string; // "usd"
}
Dans GiftGenius, vous pouvez avoir une relation un‑à‑plusieurs entre GiftProduct et GiftSkuFeedItem. Et dans le feed, vous exposez une liste « plate » de SKU.
Pour permettre à ChatGPT de comprendre quels SKU appartiennent à un même produit de base (par exemple, abonnement de 1, 3 et 12 mois), on utilise souvent un champ de regroupement tel que item_group_id. Ce n’est toutefois qu’un pattern d’architecture, pas une exigence stricte du standard.
Par exemple :
{
"id": "gg-coffee-sub-1m-usd", // SKU de l’abonnement pour 1 mois
"item_group_id": "gg-coffee-sub", // Votre produit
"title": "Abonnement café — 1 mois",
"price": 2900,
"currency": "usd",
"enable_search": true,
"enable_checkout": true
}Et pour l’abonnement de 3 mois :
{
"id": "gg-coffee-sub-3m-usd", // SKU de l’abonnement pour 3 mois
"item_group_id": "gg-coffee-sub", // Même id du produit
"title": "Abonnement café — 3 mois",
"price": 7900,
"currency": "usd",
"enable_search": true,
"enable_checkout": true
}Cette approche facilite la vie du modèle et de votre backend lors de la création des commandes : l’ID du SKU devient la clé unique qui vous permet toujours de retrouver la configuration exacte achetée par l’utilisateur.
4. Champs obligatoires du Product Feed et leur impact sur l’UX
Dans la spécification du Product Feed, OpenAI regroupe les champs en trois catégories : obligatoires (required), recommandés (recommended) et optionnels (optional).
Il faut toujours vérifier les intitulés et listes dans la documentation à jour, mais pour un apprentissage on peut s’appuyer sur ce socle « minimal ».
| Champ | À quoi il sert | Que se passe‑t‑il s’il manque |
|---|---|---|
|
Identifiant unique du SKU au sein du marchand | Impossible d’identifier l’article de façon univoque |
|
Intitulé court pour la carte | Le modèle aura plus de mal à comprendre de quel article il s’agit |
|
Description détaillée | Les réponses seront plus générales, personnalisation moindre |
|
Prix en unités minimales | Impossible de préparer le checkout |
|
Code de devise ISO 4217, généralement en minuscules | La plateforme ne saura pas dans quelle devise compter |
|
URL de la page produit chez le marchand | L’utilisateur ne pourra pas aller sur votre site |
|
Statut de disponibilité (in_stock, out_of_stock, etc.) | Des articles indisponibles peuvent être affichés |
|
Peut‑on utiliser l’article dans la recherche | Sans true, l’article n’apparaîtra pas dans les résultats |
|
Peut‑on acheter via Instant Checkout | Découverte/renvoi (link‑out) uniquement |
Point important : enable_search et enable_checkout séparent logiquement les modes de fonctionnement.
Si enable_search = true et enable_checkout = false, l’article peut apparaître dans les résultats, mais au moment d’acheter l’utilisateur sera redirigé via votre lien (link) vers votre site, et non vers l’Instant Checkout dans ChatGPT (où la carte est déjà enregistrée).
Si en revanche enable_checkout = true, alors, si les autres conditions sont réunies (région prise en charge, devise, backend ACP valide), l’article peut être acheté directement dans ChatGPT en un ou deux clics (ce qui augmente fortement la conversion).
Exemple d’objet GiftGenius « minimement apte » au checkout :
{
"id": "gg-dev-notebook-plain-usd",
"title": "Cahier minimaliste pour développeur",
"description": "Noir, sans lignes, 120 pages. Pour ceux qui écrivent des spécifications à la main.",
"price": 1500,
"currency": "usd",
"availability": "in_stock",
"link": "https://giftgenius.app/gifts/dev-notebook",
"image_link": "https://cdn.giftgenius.app/images/dev-notebook.png",
"enable_search": true,
"enable_checkout": true
}Notez que, même dans l’exemple, nous ajoutons une image (image_link) — formellement elle peut être recommandée et non obligatoire, mais sans elle l’UX sera nettement moins bonne.
5. Champs recommandés et optionnels : comment rendre le feed « plus appétissant »
Les champs obligatoires servent « à ce que ça fonctionne ». Mais si vous vous arrêtez là, vous obtiendrez un CSV minimal valide pour la comptabilité, pas une superbe vitrine IA.
Les champs recommandés incluent généralement :
- l’URL d’image principale et des URL supplémentaires ;
- la catégorie du produit (souvent basée sur une taxonomie, comme « gifts > experiences > online courses ») ;
- la marque/le nom du marchand ;
- des attributs tels que la couleur, la taille, le matériau ;
- des indicateurs de contenu adulte, des restrictions d’âge, etc.
Plus vous décrivez richement l’article, plus le modèle pourra générer des réponses pertinentes. Par exemple, si vous indiquez explicitement que le cahier est fabriqué en papier recyclé et « soutient les développeurs soucieux de la planète », ChatGPT pourra le recommander en connaissance de cause à un utilisateur demandant des cadeaux éco‑responsables.
Dans GiftGenius, nous pourrions enrichir la description de ce SKU :
{
"id": "gg-dev-notebook-plain-usd",
"title": "Cahier éco pour développeur",
"description": "Cahier minimaliste sans lignage, 120 pages en papier recyclé.",
"price": 1500,
"currency": "usd",
"availability": "in_stock",
"link": "https://giftgenius.app/gifts/eco-dev-notebook",
"image_link": "https://cdn.giftgenius.app/images/eco-dev-notebook.png",
"category": "gifts > office > notebooks",
"brand": "GiftGenius Originals",
"enable_search": true,
"enable_checkout": true
}Des attributs supplémentaires comme category et brand améliorent non seulement la recherche, mais aident aussi l’analytique : vous pouvez voir quelles catégories convertissent le mieux via ChatGPT et lesquelles fonctionnent moins bien.
Les champs optionnels sont souvent liés à des scénarios très spécifiques (par exemple, des paramètres géo pour les prix, dont nous parlerons séparément, ou des métadonnées personnalisées). Il faut les ajouter au fur et à mesure que le projet mûrit, et non pour « cocher une case ».
6. Indicateurs commerciaux et mode discovery‑only
Clarifions encore la logique de enable_search et enable_checkout, car c’est un pont critique vers les prochaines leçons sur ACP et Instant Checkout.
Supposons que vous débutez comme marchand ChatGPT. Vous avez un catalogue de cadeaux, mais l’ACP backend et le Delegated Payment sont encore en développement. Vous voulez déjà que ChatGPT puisse trouver vos SKU et envoyer les utilisateurs vers votre site pour payer.
Dans ce cas, vous :
- publiez un Product Feed avec enable_search = true pour les SKU concernés ;
- laissez enable_checkout = false jusqu’à ce que l’intégration ACP soit finalisée et certifiée.
ChatGPT pourra alors inclure vos cadeaux dans les réponses aux utilisateurs, afficher des cartes et proposer un lien « Aller sur le site GiftGenius », mais ne construira pas l’UI interne d’Instant Checkout.
Lorsque vous implémentez Agentic Checkout et Delegated Payment, certains articles peuvent passer en mode « prêt pour Instant Checkout » — en mettant simplement enable_checkout = true et en satisfaisant toutes les exigences de données (prix, devise, seller URL, etc.).
Au niveau des spécifications, ce sont précisément les champs du Product Feed qui serviront à remplir les line_items et le montant de la checkout_session.
Ainsi, le feed devient un levier de réglage fin : quels SKU, et sous quelle forme, ChatGPT a le droit de vendre en votre nom.
7. Locales, devises, régions et prix multi‑régionaux
Vous savez que le monde ne se limite pas à en-US et aux dollars. Dans les modules sur la localisation, nous avons déjà évoqué comment locale et userLocation influent sur la logique métier. Ici, cela passe au premier plan : les produits en Allemagne peuvent coûter différemment qu’aux États‑Unis, et certains cadeaux ne peuvent tout simplement pas être vendus dans certains pays.
La spécification du Product Feed prend en compte cela via plusieurs mécanismes.
Premièrement, la devise : currency doit être un code ISO 4217 valide (par exemple, usd, eur, gbp).
Deuxièmement, on peut utiliser des champs décrivant des prix et disponibilités dépendant de la zone géographique. La documentation donne un exemple d’attributs comme geo_price et de codes régionaux associés basés sur l’ISO 3166.
Il existe deux approches architecturales de base.
Approche 1 : un feed par région.
- product-feed-us-en.json pour les États‑Unis ;
- product-feed-de-de.json pour l’Allemagne ;
- product-feed-br-pt.json pour le Brésil.
Dans chaque feed, tous les SKU sont déjà alignés sur la devise et la locale voulues. C’est plus simple pour ChatGPT, mais cela vous demande plus de travail pour maintenir plusieurs feeds.
Approche 2 : un feed unique avec des champs geo.
Dans chaque enregistrement, vous conservez soit un tableau de prix, soit des attributs supplémentaires :
{
"id": "gg-dev-notebook-multi",
"title": "Cahier éco pour développeur",
"description": "Soutient votre amour du code propre et de la planète.",
"prices": [
{ "region": "US", "currency": "usd", "price": 1500 },
{ "region": "DE", "currency": "eur", "price": 1400 }
],
"availability_by_region": [
{ "region": "US", "availability": "in_stock" },
{ "region": "DE", "availability": "out_of_stock" }
],
"enable_search": true,
"enable_checkout": true
}La structure exacte des champs multi‑région dépend de la version de la spécification, mais l’idée est la même : le feed doit permettre à la plateforme de comprendre dans quels pays le SKU existe et combien il y coûte.
Du point de vue de GiftGenius, il est important de penser le mapping entre :
- locale et userLocation, connus de ChatGPT ;
- et la partie du feed d’où il faut prendre les prix et les textes.
Le plus souvent, dans les scénarios commerciaux, vous ne fournissez pas un seul enregistrement « pour le monde entier », mais vous créez des SKU distincts par pays, afin de respecter plus simplement les taxes, la politique et les restrictions sur les produits.
8. Qualité des données et politique : sans cela, l’Instant Checkout ne décollera pas
Le Product Feed ne concerne pas seulement le format, mais aussi la qualité des données et le respect de la politique d’OpenAI.
Concernant la qualité, OpenAI exige explicitement :
- des identifiants corrects et stables ;
- des URL valides en HTTPS avec un code de réponse 200 ;
- la cohérence du prix et de la devise ;
- une disponibilité à jour (pas d’articles in_stock alors qu’ils ne le sont plus en réalité).
La spécification impose aussi des contraintes de longueur de texte : par exemple, title ne doit pas être trop long (des centaines de caractères), et description a une limite raisonnable (des milliers de caractères), pour que les cartes restent propres et ne se transforment pas en roman.
Bloc à part : la Prohibited Products Policy. C’est la liste des catégories de produits et services interdits à la vente via Instant Checkout et/ou ChatGPT en général : des cas évidents comme les produits illégaux, les armes, certains services médicaux, etc. Il faut toujours vérifier les détails dans la politique à jour, mais retenez : le Product Feed sera vérifié non seulement sur la forme, mais aussi sur l’admissibilité du contenu.
Si votre catalogue contient des catégories ambiguës (par exemple, alcool, jeux d’argent ou tout ce qui touche aux enfants), traitez‑les avec une attention particulière. Il est souvent plus simple de les laisser en mode enable_checkout = false et de ne vendre que via votre propre site avec tout l’encadrement juridique.
9. Pratique : construire un Product Feed minimal pour GiftGenius
Appliquons tout cela en pratique et constituons un feed simple pour trois SKU GiftGenius. Supposons que nous ayons :
- Un cahier éco pour développeur.
- Un abonnement café d’1 mois.
- Une carte‑cadeau pour le cours « TypeScript pour adultes ».
Décrivons d’abord le type TypeScript que nous utiliserons pour générer le feed :
export interface GiftGeniusFeedItem {
id: string;
title: string;
description: string;
price: number; // en centimes
currency: "usd" | "eur";
availability: "in_stock" | "out_of_stock";
link: string;
image_link?: string;
enable_search: boolean;
enable_checkout: boolean;
}Créons maintenant dans le code un tableau avec quelques éléments, puis sérialisons‑le en JSON :
export const giftGeniusFeed: GiftGeniusFeedItem[] = [
{
id: "gg-eco-notebook-usd",
title: "Cahier éco pour développeur",
description: "Cahier minimaliste sans lignage en papier recyclé.",
price: 1500,
currency: "usd",
availability: "in_stock",
link: "https://giftgenius.app/gifts/eco-dev-notebook",
image_link: "https://cdn.giftgenius.app/images/eco-dev-notebook.png",
enable_search: true,
enable_checkout: true
},
{
id: "gg-coffee-sub-1m-usd",
title: "Abonnement café pour développeur — 1 mois",
description: "Boîte mensuelle de café en grains. Compatible avec les deadlines.",
price: 2900,
currency: "usd",
availability: "in_stock",
link: "https://giftgenius.app/gifts/coffee-subscription-1m",
image_link: "https://cdn.giftgenius.app/images/coffee-1m.png",
enable_search: true,
enable_checkout: true
},
{
id: "gg-ts-course-gift-usd",
title: "Carte‑cadeau pour le cours TypeScript",
description: "Cours en ligne pour les développeurs qui veulent enfin comprendre les generics.",
price: 9900,
currency: "usd",
availability: "in_stock",
link: "https://giftgenius.app/gifts/ts-course",
image_link: "https://cdn.giftgenius.app/images/ts-course.png",
enable_search: true,
enable_checkout: false // pour l’instant discovery uniquement
}
];Vous pouvez ensuite créer un petit utilitaire qui, toutes les N minutes, génère le fichier product-feed.json à partir de cette structure et le publie sur votre serveur HTTPS.
import { writeFile } from "node:fs/promises";
import { giftGeniusFeed } from "./feed-data";
// Générateur de feed JSON tout simple
async function buildProductFeed() {
const json = JSON.stringify(giftGeniusFeed, null, 2);
await writeFile("public/product-feed.json", json, "utf8");
}
buildProductFeed().catch(console.error);Évidemment, dans un projet réel vous ne conserverez pas tout le feed dans le code ; les données viendront de la base. Mais pour démarrer, il est utile de construire au moins cet exemple pédagogique afin de tester le pipeline : génération → publication → validation.
10. Anti‑exemple : à quoi ressemble un « mauvais » Product Feed
Pour mieux ressentir les exigences de la spec et l’UX, regardons un exemple de feed qui fonctionne presque formellement, mais qui posera des problèmes en pratique :
{
"id": "1",
"title": "Cadeau",
"description": "Super cadeau",
"price": 12.333333,
"currency": "usdollars",
"availability": "yes",
"link": "http://giftgenius.local/gift/1",
"enable_search": "true",
"enable_checkout": "maybe"
}On peut compter plusieurs problèmes d’un coup ici.
Premièrement, id = "1" est un identifiant pauvre et instable. Si vous migrez un jour la base ou introduisez du sharding, de tels identifiants deviennent fragiles. Mieux vaut utiliser des ID explicites et suffisamment longs, uniques au sein du marchand.
Deuxièmement, price est indiqué comme un décimal à la précision excessive. Les spécifications et les systèmes de paiement attendent généralement un prix en unités minimales (centimes) sous forme d’entier, pour éviter les problèmes de virgule flottante et d’arrondi.
Troisièmement, currency = "usdollars" et availability = "yes" ne correspondent pas aux formats attendus (ISO 4217 et liste des statuts valides).
Quatrièmement, link pointe vers http et un domaine local — inacceptables en production ; la spécification exige explicitement HTTPS et un accès public.
Cinquièmement, les indicateurs enable_search et enable_checkout doivent être booléens, pas des chaînes. Sinon, le parseur OpenAI refusera le feed ou utilisera une valeur par défaut qui pourrait vous surprendre.
Ces problèmes peuvent conduire soit à une erreur de validation franche (feed rejeté), soit à une situation plus désagréable : le feed est accepté formellement, mais une partie des SKU est ignorée ou ne fonctionne pas comme prévu. D’où l’intérêt d’investir dans une validation côté serveur.
11. Erreurs courantes avec le Product Feed
Erreur n°1 : penser au feed comme à un « CSV ponctuel » pour l’import.
Parfois, les équipes perçoivent le Product Feed comme un fichier qu’elles génèrent une fois « pour l’intégration » puis oublient. En AI‑commerce, ce n’est pas le cas : le feed est une source de vérité vivante, qui doit être mise à jour régulièrement. Si vous modifiez des prix, retirez des produits, lancez des promos — tout cela doit arriver rapidement dans le feed. Sinon, ChatGPT recommandera ce qui n’existe plus, ou à l’ancien prix, et les utilisateurs seront légitimement mécontents.
Erreur n°2 : mélanger le modèle produit et le SKU.
Un anti‑pattern populaire consiste à essayer de refléter un produit de base avec beaucoup d’options dans un seul enregistrement de feed avec des champs « size1/size2/size3 » ou « duration1/duration2 ». Le modèle ne comprend alors pas ce qui est réellement vendu, et votre backend ACP souffre au moment de décompresser ces champs pendant le checkout. Bien plus simple et fiable : un SKU — un enregistrement de feed, même si c’est une variante d’un même produit.
Erreur n°3 : ignorer les locales et les régions.
Les développeurs qui construisent un premier MVP mettent souvent currency = "usd" et enable_checkout = true partout, sans penser au fait qu’Instant Checkout peut ne pas être disponible dans votre région ou que certains articles ne peuvent pas être vendus dans certains pays pour des raisons politiques ou légales. Puis, en entrant sur un nouveau marché, tout se met à casser : incohérences de prix, taxes non prises en compte. Mieux vaut, dès le départ, lier les SKU aux régions et devises, même si vous n’avez qu’un seul marché pour l’instant.
Erreur n°4 : traiter les descriptions comme des textes SEO d’un autre temps.
Certaines équipes copient dans le Product Feed de vieilles descriptions de leurs sites, parfois écrites pour des « mots‑clés » et des robots. Pour ChatGPT, c’est plutôt nuisible : le modèle sait déjà écrire du texte, il a surtout besoin de faits structurés, honnêtes et précis. Mieux vaut une description courte et précise qu’un description pleine de verbiage marketing.
Erreur n°5 : ne pas valider le feed soi‑même.
Se reposer uniquement sur la validation côté OpenAI conduit à des nuits blanches avant les deadlines. Mettez en place un validateur simple dans votre backend ou votre CI, qui vérifie les schémas de champs, les valeurs autorisées, les formats d’URL et de devises. Vous pouvez le faire en TypeScript avec, par exemple, Zod ou vos propres vérifications. Vous détecterez ainsi les problèmes avant de publier le feed en production.
Erreur n°6 : inclure « tout et n’importe quoi » dans le Product Feed.
La tentation est grande d’y mettre des milliers de SKU « au cas où ». En pratique, cela complique le debug, l’analytique et le contrôle qualité. Il est bien plus raisonnable de commencer par un sous‑ensemble limité : uniquement les catégories et SKU que vous êtes prêts à maintenir et que vous souhaitez réellement vendre via ChatGPT. Le reste peut rester en mode discovery ou sans intégration.
Erreur n°7 : ne pas synchroniser le Product Feed et l’ACP backend.
Le feed et l’API ACP sont les deux faces d’une même pièce. Si un nouveau SKU apparaît dans le feed alors que votre backend ne sait pas encore le vendre (ou inversement, si un SKU est retiré du feed mais que le backend croit encore qu’il existe), vous aurez de la désynchronisation, des bugs complexes et des tickets de support difficiles. La bonne pratique : une unique modèle de domaine pour le catalogue, utilisé à la fois pour générer le feed et pour traiter le checkout.
GO TO FULL VERSION