Panorama de l’AI‑commerce et rôle d’OpenAI

1. Qu’est‑ce que l’AI‑commerce, au juste

Si l’e‑commerce classique est l’histoire « je vais sur le site — j’ouvre le catalogue — j’ajoute au panier — je me traîne à travers trois formulaires », l’AI‑commerce, lui, fait du dialogue avec ChatGPT l’interface principale. L’utilisateur formule sa demande en langage naturel, et un agent dans ChatGPT endosse le rôle de conseiller, merchandiser et, partiellement, de product manager.

Les requêtes ne ressemblent pas à « category=socks&price_max=20 », mais à « trouve un cadeau drôle mais pas trop cringe pour un collègue jusqu’à 20 $, que je peux envoyer par e‑mail ». L’agent interprète la tâche, pose des questions de clarification, consulte le catalogue des produits, explique les avantages et inconvénients des options, puis accompagne l’utilisateur jusqu’à l’achat — et tout cela sans que l’utilisateur voie un « panier » comme une page distincte.

Du point de vue de l’architecture, l’App ChatGPT se transforme alors d’un « catalogue intelligent de cadeaux » en une application de commerce capable de :

1. Comprendre l’intention et les contraintes de l’utilisateur (budget, type de cadeau, pays, produit numérique/physique).
2. Sélectionner des SKU précis à partir du product feed et expliquer le choix.
3. Initier la finalisation de l’achat via le protocole standardisé ACP (Agentic Commerce Protocol).

L’idée de l’AI‑commerce est que « catalogue + checkout » ne sont plus un site séparé, mais la continuation logique du dialogue que l’utilisateur mène déjà avec GPT.

2. E‑commerce classique vs AI‑commerce

Pour mieux sentir la différence, mettons les deux approches côte à côte. Ci‑dessous — un tableau simplifié, qui ne prétend pas à l’exhaustivité, mais illustre bien le changement de paradigme.

Conséquence pratique : dans l’AI‑commerce, l’attention se déplace du design visuel du « catalogue et du panier » vers la structure et la qualité des données, ainsi que vers le protocole formel d’interaction entre ChatGPT, votre backend et le prestataire de paiement. Le Product Feed et les endpoints ACP deviennent une « UI » aussi importante que le widget lui‑même.

Si, dans une boutique classique, on peut rattraper une partie du UX dans le navigateur, dans l’AI‑commerce le modèle s’appuie presque entièrement sur les données et schémas que vous lui avez fournis : de la description du produit aux statuts de la session de checkout.

3. Les blocs constitutifs d’OpenAI Commerce

OpenAI ne propose pas une « solution de paiement magique GPTPay » qui ferait tout toute seule. À la place, il y a un ensemble de spécifications et de guides qui décrivent comment connecter correctement les marchands et prestataires de paiement existants au monde de ChatGPT. Parmi ces documents, quatre briques sont particulièrement importantes pour nous.

Premièrement, la Product Feed Specification. C’est le format officiel dans lequel le vendeur décrit son catalogue : id, title, description, prix, devise, disponibilité, images, etc. Le feed sert de « source structurée de vérité » que OpenAI valide, indexe et utilise pour la recherche, le classement et le checkout à l’intérieur de ChatGPT.

Deuxièmement, la Agentic Checkout Specification. C’est un contrat REST pour travailler avec l’entité checkout_session : l’API décrit comment créer une session de paiement, la mettre à jour (par exemple, en cas de changement d’adresse ou d’option de livraison) et la terminer, ainsi que les champs que le backend doit renvoyer (montants, taxes, options de fulfillment, liens vers la politique de retour, etc.).

Troisièmement, la Delegated Payment Specification. C’est le protocole par lequel la plateforme de l’agent (ChatGPT) obtient un jeton de paiement délégué auprès du prestataire de paiement (par exemple, Stripe Shared Payment Token) et le transmet à votre backend, sans divulguer les données de paiement elles‑mêmes. Le jeton est limité par le montant, la durée de vie et d’autres paramètres, et il est utilisé par votre backend pour créer le paiement réel chez le PSP.

Enfin, l’Instant Checkout dans ChatGPT — une couche UX au‑dessus de ces spécifications. Un interface de checkout compact apparaît dans le chat : produit sélectionné, prix, adresse, méthode de paiement. Sous le capot, il s’appuie sur le Product Feed, appelle vos /checkout_sessions selon l’Agentic Checkout Spec et utilise Delegated Payment pour effectuer la transaction chez le PSP.

La bonne nouvelle, c’est que tout cela n’est pas un « API secret de ChatGPT », mais des spécifications ouvertes ACP (Agentic Commerce Protocol). Cela signifie que le même backend peut théoriquement fonctionner avec d’autres plateformes d’IA, si elles prennent également en charge ACP.

4. Rôles et frontières de responsabilité

Là, les choses deviennent vraiment intéressantes : quand de l’argent entre dans le système, les régulateurs et les juristes deviennent soudain vos meilleurs amis. Pour éviter toute confusion, il est important de bien séparer les rôles.

Le rôle principal revient à la plateforme de l’agent, dans notre cas — ChatGPT. Elle détient l’expérience utilisateur : chat, widgets, UI d’Instant Checkout. La plateforme initie le flux de commerce, choisit les produits depuis le Product Feed, appelle vos endpoints ACP et affiche le résultat à l’utilisateur. Mais ChatGPT ne devient ni propriétaire du produit, ni prestataire de paiement, et ne stocke pas vos données produit comme « son propre catalogue » — il utilise précisément le feed que vous lui avez fourni.

En second rôle — le marchand (seller, merchant‑of‑record). C’est le propriétaire des biens ou services. Le marchand est responsable du product feed lui‑même (structure, qualité, exactitude des prix et de la disponibilité), de la bonne implémentation des endpoints ACP (/checkout_sessions, webhooks), de la création et du stockage des commandes, de la livraison, du support et des retours. La documentation ACP souligne que c’est le marchand qui reste le vendeur de référence au sens juridique, et non la plateforme de l’agent.

Troisième rôle — le prestataire de services de paiement (PSP), par exemple Stripe. Le PSP est responsable du traitement des paiements, du respect de PCI DSS et autres exigences, du stockage des coordonnées de paiement, de la lutte contre la fraude et des rétrofacturations. Dans le contexte de Delegated Payment, le PSP remet à la plateforme de l’agent un jeton spécial (SPT), ensuite utilisé par votre serveur pour créer le paiement réel (par exemple, un PaymentIntent chez Stripe).

Quatrième rôle, et le plus important — l’utilisateur. Il formule la demande, prend la décision finale d’achat, donne son consentement au paiement et, idéalement, lit les Conditions / Politique de confidentialité que vous affichez honnêtement dans l’UI du checkout. Le Product Feed peut contenir des liens vers ces documents et vers la politique de retour, pour plus de confiance et de transparence.

Pour plus de clarté, on peut résumer cela dans un petit tableau :

La séparation des responsabilités est importante non seulement pour les juristes, mais aussi pour l’architecture. Par exemple, si demain vous branchez un deuxième PSP, vous n’avez pas besoin de réécrire l’App ChatGPT : il suffit d’adapter la couche Delegated Payment dans votre backend. Et si une deuxième plateforme d’IA apparaît, qui comprend aussi ACP, vous pourrez réutiliser à la fois le product feed et les endpoints de checkout.

5. À quoi ressemble un scénario d’achat « tout dans le dialogue »

Rassemblons maintenant tout cela et voyons à quoi ressemble un scénario de bout en bout (end‑to‑end) d’achat d’un cadeau numérique dans ChatGPT, du point de vue de l’architecture. C’est un scénario simplifié, mais il en reflète l’essence.

sequenceDiagram
  participant U as Utilisateur
  participant C as ChatGPT
  participant G as GiftGenius App
  participant B as Backend marchand
  participant P as PSP (Stripe)

  U->>C: "Achète un cadeau numérique jusqu’à 50 $"
  C->>G: callTool(find_gifts, budget<=50)
  G->>B: GET /catalog?budget_lte=50
  B-->>G: Liste des SKU pertinents
  G-->>C: Options de cadeaux + métadonnées
  C-->>U: Explique le choix, propose des options
  U->>C: "Je prends celui‑ci"
  C->>B: POST /checkout_sessions (sku, price...)
  C->>P: Demander un jeton de paiement (SPT)
  C->>B: POST /checkout_sessions/{id}/complete (token)
  B->>P: Exécuter le paiement
  B-->>C: Webhook de création de commande
  C-->>U: Confirmation d’achat

En langage ACP « à sec », il se passe ceci :

1. L’agent utilise le Product Feed (via votre backend) pour sélectionner des SKU pertinents.
2. Au moment de « on achète », ChatGPT crée une checkout_session via votre /checkout_sessions selon l’Agentic Checkout Spec.
3. Pendant l’Instant Checkout, ChatGPT demande au PSP un jeton de paiement délégué pour un montant et un marchand précis.
4. Ce jeton est transmis dans le POST /checkout_sessions/{id}/complete, votre backend crée le paiement chez le PSP et génère la commande.
5. Quand la commande est prête, votre serveur notifie OpenAI via un webhook, après quoi l’utilisateur voit la confirmation finale.

Ce qui nous importe ici n’est pas tant de mémoriser les noms des endpoints que de voir la structure : feed → sélection des SKU → checkout_session → paiement → commande → webhook. Dans les prochains cours, nous détaillerons chaque morceau séparément, y compris les champs du feed, les champs de la session de checkout et le format des paiements délégués.

6. GiftGenius : comment notre App s’insère dans l’AI‑commerce

Jusqu’ici, GiftGenius jouait le rôle d’« assistant de sélection de cadeaux ». Il savait :

• demander à l’utilisateur pour qui et à quelle occasion il faut un cadeau ;
• utiliser les outils MCP pour chercher dans son propre catalogue ;
• afficher les fiches d’options dans le widget et envoyer des boutons de suivi (follow‑up) dans le chat.

Du point de vue du commerce, c’était un « discovery intelligent » sans achat réel. Dans l’univers OpenAI Commerce, ce mode correspond à un feed où, pour un SKU, on met enable_search = true, mais enable_checkout = false : les produits peuvent être trouvés et discutés, mais l’Instant Checkout est désactivé pour eux.

Dans le module AI‑commerce, nous allons progressivement transformer GiftGenius en marchand pleinement intégré :

• ajouter un Product Feed structuré selon la spécification OpenAI ;
• concevoir un backend ACP capable de travailler avec les checkout_sessions ;
• brancher Delegated Payment via le Stripe Shared Payment Token ;
• apprendre à l’App à indiquer à l’utilisateur qu’il peut non seulement sélectionner, mais aussi acheter un cadeau directement dans le chat.

Pour que tout cela ne ressemble pas à de la « magie noire », ajoutons à notre code une petite couche technique qui modélise explicitement les rôles et les étapes du flux de commerce. Ce sera utile pour les logs et pour les tests internes.

// app/commerce/types.ts
export type CommerceRole = "user" | "chatgpt" | "merchant" | "psp";

export interface CommerceStep {
  id: string;
  role: CommerceRole;
  description: string;
}

Ces types aident à distinguer mentalement « qui fait quoi » même au niveau de TypeScript. Nous pouvons les utiliser, par exemple, dans des tests ou dans une UI de débogage à l’intérieur du widget.

Petit exemple de tableau d’étapes pour le scénario « cadeau numérique jusqu’à 50 $ » :

// app/commerce/exampleFlow.ts
import type { CommerceStep } from "./types";

export const digitalGiftFlow: CommerceStep[] = [
  { id: "intent", role: "user", description: "Formuler la demande et le budget" },
  { id: "search", role: "chatgpt", description: "Sélectionner des SKU à partir du Product Feed" },
  { id: "checkout", role: "merchant", description: "Créer la checkout_session" },
  { id: "payment", role: "psp", description: "Effectuer le paiement via le jeton" }
];

Ce code ne parle pas encore au réseau, mais il crée déjà un « axe de coordonnées » utile, autour duquel nous allons étoffer le code ACP réel dans les prochains cours.

7. Mini‑exercice : déroulez le flux « Achète‑moi un cadeau numérique jusqu’à 50 $ »

En fin de cours, il est utile de dérouler à la main ce que nous venons de décrire. Prenez la requête de l’utilisateur :

« Achète‑moi un cadeau numérique jusqu’à 50 $ ».

Objectif : décrire en 3–5 étapes logiques ce qui se passe ensuite, et pour chaque étape indiquer qui l’exécute : ChatGPT, votre backend marchand, le prestataire de paiement ou l’utilisateur lui‑même. Vous pouvez vous appuyer sur le diagramme ci‑dessus et sur le tableau digitalGiftFlow, mais ce n’est pas obligatoire de correspondre exactement.

Par exemple, vous pouvez commencer par l’étape où ChatGPT interprète la requête et demande des précisions (bon d’achat numérique, région du destinataire, pour qui est le cadeau). Puis l’étape où votre backend cherche des SKU adaptés via le Product Feed, ensuite — la création de la checkout_session, l’obtention du jeton de paiement auprès du PSP et la finalisation de l’achat.

Si vous le souhaitez, vous pouvez l’écrire directement en code, en ajoutant quelques étapes au digitalGiftFlow et en les rendant dans un petit composant de débogage dans le widget. Un tel exercice entraîne à penser non seulement « code », mais aussi « rôles dans le protocole ».

Exemple d’un endpoint d’API simple qui pourrait recevoir un « plan de flux » de ce type et le journaliser (sans vraie partie commerce pour l’instant) :

// app/api/commerce/flow/route.ts
import { NextRequest, NextResponse } from "next/server";
import type { CommerceStep } from "@/app/commerce/types";

export async function POST(req: NextRequest) {
  const steps = (await req.json()) as CommerceStep[];
  console.log("Planned AI-commerce flow:", steps);
  return NextResponse.json({ ok: true, stepsCount: steps.length });
}

Dans la vraie vie, au lieu de console.log, vous écrirez des logs structurés et, éventuellement, conserverez ces scénarios comme partie de la documentation ou des tests. Mais même ce petit exemple aide à relier l’architecture abstraite à du code TypeScript concret dans votre application Next.js.

Si l’on garde en tête la carte des rôles que nous avons détaillée dans ce cours, les détails techniques à venir — champs du Product Feed, schémas des sessions de checkout et structure des paiements délégués — se mettront en place beaucoup plus facilement, sans romantiser à outrance un « GPT tout‑puissant ».

8. Erreurs typiques dans la compréhension de l’AI‑commerce et des rôles

Erreur n° 1 : penser que « ChatGPT fera tout tout seul ».
Parfois, les développeurs pensent qu’il suffit de « connecter Stripe » et de « donner à la mesure l’accès à l’API », et que GPT se débrouillera. En réalité, l’AI‑commerce autour de ChatGPT s’appuie sur des spécifications formelles : Product Feed, Agentic Checkout, Delegated Payment. Si vous n’avez pas décrit les produits sous forme de feed structuré, si vous n’avez pas implémenté /checkout_sessions et configuré le Delegated Payment, aucun modèle ne l’inventera à votre place.

Erreur n° 2 : confondre les rôles de ChatGPT et du marchand.
Autre confusion fréquente : croire que ChatGPT devient « la boutique » et que vous « ne faites que brancher le catalogue ». En réalité, c’est l’inverse : vous restez le marchand, vous conservez le product feed, vous créez et maintenez les commandes, vous gérez les retours. ChatGPT n’est responsable que de l’UX du dialogue et des appels corrects à vos endpoints ACP. Si vous concevez le système comme si « GPT distribuait lui‑même les abonnements et envoyait les produits », vous vous retrouverez tôt ou tard dans une impasse juridique et technique.

Erreur n° 3 : ignorer le prestataire de paiement comme entité distincte.
La tentation est grande de « cacher » le PSP dans le backend et de lui parler comme à n’importe quel REST‑API, en oubliant que la couche paiement a ses propres règles (PCI, fraude, rétrofacturations, limites). Dans l’approche ACP, la Delegated Payment Spec est distincte pour une bonne raison : la plateforme de l’agent communique avec le PSP à son niveau, obtient un jeton SPT et vous le transmet, et c’est vous qui créez le paiement. Si vous essayez de contourner ce schéma et d’accepter directement les données de carte dans l’App, vous vous tirerez rapidement une balle dans le pied côté conformité.

Erreur n° 4 : percevoir le product feed comme un « réglage marketing » plutôt que comme un API pour une LLM.
Beaucoup viennent avec un bagage Google Shopping et pensent au feed comme à quelque chose de plus important pour le compte publicitaire que pour le code. Dans le monde de l’AI‑commerce, le feed est, en substance, la base de connaissances de votre assortiment pour le modèle. S’il contient des liens d’images cassés, des attributs incohérents, des unités bizarres et des hyperboles marketing au lieu de faits, le modèle proposera ce qu’il ne faut pas, et la conversion baissera.

Erreur n° 5 : essayer d’activer l’Instant Checkout « en une seule étape ».
La tentation est forte : « activons tout de suite enable_checkout, que les utilisateurs achètent depuis le chat ». Mais sans un discovery solide (feed de qualité), sans un backend de checkout fiable et sans une intégration réfléchie avec le PSP, vous risquez d’obtenir un système fragile où la moitié des commandes restent bloquées en milieu de parcours. Il est beaucoup plus raisonnable d’avancer par paliers, comme le propose OpenAI : d’abord un Product Feed de qualité, puis le débogage des endpoints ACP, ensuite le Delegated Payment et seulement après activer l’Instant Checkout en mode production.