Tags: ChatGPT Commerce, OpenAI, ACP, Architecture, eCommerce, Agentic Commerce Protocol, Delegated Payment, Merchant Edge

Le ChatGPT Commerce ne remplace pas la stack commerciale d'un marchand. Le modèle actuel d'OpenAI débute avec des flux de produits structurés, puis connecte les actions commerciales via des flux de l'Agentic Commerce Protocol et des paiements délégués, tout en laissant le marchand responsable du traitement des paiements, de l'acceptation des commandes, de l'exécution, des remboursements, des litiges, de la conformité et du support.

C'est le point de départ utile car il ancre la conversation dans la réalité. L'aspect intéressant n'est pas le "shopping IA" comme slogan. L'aspect intéressant est ce que les développeurs doivent exposer, orchestrer et gouverner pour qu'un nouveau canal conversationnel puisse utiliser en toute sécurité les systèmes commerciaux existants.

Si vous êtes la personne à qui on confie ce projet, la question pratique n'est pas de savoir si ChatGPT peut afficher des produits. OpenAI documente déjà comment les marchands peuvent intégrer les données de catalogue et supporter le checkout via ACP. La vraie question est de savoir si votre architecture actuelle peut supporter un nouveau canal sans coupler ChatGPT au code de la boutique, dupliquer la logique métier, ou créer des incohérences de paiement et d'état de commande.

Ce qu'OpenAI documente réellement

Les directives commerciales actuelles d'OpenAI décrivent trois blocs de construction fondamentaux pour les marchands qui veulent participer à ce modèle.

Premièrement, les marchands partagent un flux de produits structuré pour que ChatGPT puisse indexer les produits, comprendre les attributs clés, et présenter des informations produit exactes dans les expériences d'achat. OpenAI recommande de commencer par là, et précise que l'intégration du flux de produits dans ChatGPT est actuellement disponible pour les partenaires approuvés.

Deuxièmement, ChatGPT peut appeler les endpoints ACP du marchand pour créer ou mettre à jour des sessions de checkout, transmettre en toute sécurité les informations de l'acheteur et de livraison, et recevoir un état de commande après que le marchand ait validé la transaction et décidé de l'accepter ou de la refuser. OpenAI précise également que l'interface de checkout est intégrée à ChatGPT, tandis que l'état de checkout et le traitement des paiements restent sur les systèmes du marchand.

Troisièmement, la spécification de paiement délégué d'OpenAI permet à OpenAI de partager en toute sécurité les détails de paiement avec le marchand ou son PSP désigné. Le marchand et le PSP traitent ensuite le paiement de la même manière que toute autre transaction numérique, et OpenAI précise explicitement qu'il n'est pas le marchand d'enregistrement.

C'est le modèle de plateforme factuel. Tout le reste de cet article est un conseil d'implémentation sur la manière de construire proprement autour de ce modèle.

Ce que les développeurs doivent construire

En termes pratiques, une intégration marchande nécessite cinq couches fonctionnelles.

Un pipeline de flux de produits fiable.
Une bordure marchande sécurisée pour les requêtes ACP.
Un accès aux services commerciaux centraux comme la tarification, les promotions, l'inventaire, les taxes et l'expédition.
Une intégration de paiement délégué avec un PSP ou un vault existant.
Une connectivité post-commande vers l'OMS, l'exécution, les retours et les systèmes de support.

La raison pour laquelle cela compte est simple : ChatGPT peut devenir une nouvelle surface d'intention et de checkout, mais il dépend toujours des systèmes du marchand pour la transaction sous-jacente. Si ces systèmes sont fragmentés, inconsistants, ou cachés derrière une logique spécifique à la boutique, le canal ChatGPT fera rapidement apparaître ces faiblesses.

C'est pourquoi cela devrait être traité comme un projet d'intégration de systèmes, et non comme une fonctionnalité de chatbot.

Vue d'architecture

Diagramme d'architecture ChatGPT Commerce montrant cinq couches : Canal ChatGPT, Bordure Marchande, Services Commerciaux, Stack de Paiement, et Opérations de Commande

L'architecture approuvée pour cet article décompose l'implémentation en cinq couches : Canal ChatGPT, Bordure Marchande, Services Commerciaux, Stack de Paiement, et Opérations de Commande. C'est une recommandation architecturale, pas un diagramme OpenAI, mais elle correspond bien aux responsabilités documentées dans le modèle commercial d'OpenAI. Copiez et collez le code FlowZap suivant dans un Diagramme de votre compte FlowZap et commencez à l'éditer pour l'adapter à votre cas d'usage !

merchantEdge { # Bordure Marchande
  n1: rectangle label="Publier le flux produits"
  n2: rectangle label="Valider le flux"
  n3: rectangle label="Exposer les endpoints ACP"
  n4: rectangle label="Créer la session de checkout"
  n5: diamond label="Approuver la commande ?"
  n6: rectangle label="Retourner le résultat"
  n1.handle(right) -> n2.handle(left)
  n2.handle(right) -> n3.handle(left)
  n3.handle(right) -> n4.handle(left)
  n4.handle(right) -> n5.handle(left)
  n5.handle(right) -> n6.handle(left) [label="Oui"]
  n2.handle(bottom) -> commerce.n7.handle(top) [label="Rafraîchir le catalogue"]
  n4.handle(bottom) -> payment.n11.handle(top) [label="Requête de paiement délégué"]
  n6.handle(bottom) -> operations.n14.handle(top) [label="Créer l'événement commande"]
  n6.handle(top) -> chatgpt.n20.handle(bottom) [label="Résultat de la commande"]
}

commerce { # Services Commerciaux
  n7: rectangle label="Résoudre le contenu"
  n8: rectangle label="Résoudre prix et promos"
  n9: rectangle label="Résoudre l'inventaire"
  n10: rectangle label="Résoudre taxes et livraison"
  n7.handle(right) -> n8.handle(left)
  n8.handle(right) -> n9.handle(left)
  n9.handle(right) -> n10.handle(left)
  n10.handle(top) -> merchantEdge.n4.handle(bottom) [label="Données de checkout"]
}

payment { # Stack de Paiement
  n11: rectangle label="Tokeniser le paiement"
  n12: rectangle label="Autoriser le paiement"
  n13: rectangle label="Retourner le statut"
  n11.handle(right) -> n12.handle(left)
  n12.handle(right) -> n13.handle(left)
  n13.handle(top) -> merchantEdge.n5.handle(bottom) [label="Approuvé ou refusé"]
}

operations { # Opérations de Commande
  n14: rectangle label="Créer la commande OMS"
  n15: rectangle label="Réserver l'inventaire"
  n16: rectangle label="Déclencher l'exécution"
  n17: rectangle label="Gérer retours et support"
  n14.handle(right) -> n15.handle(left)
  n15.handle(right) -> n16.handle(left)
  n16.handle(right) -> n17.handle(left)
  n17.handle(top) -> chatgpt.n21.handle(bottom) [label="Service et support"]
}

chatgpt { # Canal ChatGPT
  n18: circle label="Intention de l'acheteur"
  n19: rectangle label="Afficher les produits"
  n20: rectangle label="Afficher la confirmation"
  n21: circle label="Entrée support"
  n18.handle(right) -> n19.handle(left)
  n19.handle(right) -> n20.handle(left)
  n20.handle(right) -> n21.handle(left)
  n18.handle(left) -> merchantEdge.n3.handle(right) [label="Requête de découverte"]
  n19.handle(left) -> merchantEdge.n4.handle(right) [label="Requête de session"]
  n20.handle(left) -> merchantEdge.n5.handle(right) [label="Approbation d'achat"]
}

Commencer par le flux

Le chemin d'intégration recommandé par OpenAI commence par le flux de produits, et c'est aussi le bon point de départ pour l'ingénierie. Le flux est ce qui donne à ChatGPT les données de catalogue nécessaires pour comprendre les titres, descriptions, images, prix, disponibilité, et autres attributs produit clés.

Les directives sont assez spécifiques pour être transformées en un vrai plan de livraison. OpenAI recommande soit le téléversement de fichier, soit l'API, suggère généralement d'envoyer l'intégralité du flux une fois par jour via téléversement et d'utiliser l'API pour les mises à jour intra-journalières, et précise que les données de promotions ne peuvent être fournies que via l'API. Elle exige également la validation des champs obligatoires et des rafraîchissements réguliers des données.

Pour les développeurs, cela se traduit par un travail concret :

Identifier le système de référence pour chaque champ du flux.
Mapper le modèle produit interne au schéma documenté.
Valider les champs obligatoires sur chaque enregistrement.
Publier un instantané quotidien.
Pousser les changements intra-journaliers pour le prix, la disponibilité et les promotions.
Surveiller la fraîcheur du flux et les échecs de schéma.

Ce n'est pas un travail glamour, mais il est fondamental. Une boutique en ligne peut masquer une mauvaise structure de catalogue avec des modèles, de la navigation et de la logique de marchandisage. Un flux lisible par machine ne le peut pas.

Construire une bordure marchande

OpenAI documente le flux au niveau du protocole, mais elle n'oblige pas les marchands à exposer ces capacités via des contrôleurs de boutique ou des API spécifiques à des pages. C'est là que le jugement architectural entre en jeu.

L'implémentation la plus propre consiste généralement à construire une bordure marchande : une passerelle ou une couche d'orchestration qui accepte les requêtes originaires de ChatGPT et coordonne les services commerciaux sous-jacents. Cette couche devrait exposer des endpoints sécurisés pour la découverte, la création de session de checkout, les mises à jour de checkout, l'achèvement du paiement, et les recherches de service post-commande.

Une bordure marchande doit bien faire quatre choses :

Traduire les requêtes ChatGPT en appels de service internes.
Normaliser les réponses en aval en données prêtes pour le canal.
Appliquer les politiques, l'observabilité, l'idempotence et le traçage.
Garder le canal découplé du comportement spécifique à la boutique.

Ce dernier point est important. Si le canal ChatGPT dépend de cookies de session, de logique de rendu de page, ou de contrôleurs de boutique, l'intégration devient fragile. Le meilleur pattern est que ChatGPT consomme des capacités commerciales, pas des détails d'implémentation de la boutique.

Une surface de capacités pratiques pourrait inclure des fonctions comme :

searchProducts(query, locale, filters)
getProduct(productId)
createCheckoutSession(items, buyerContext)
updateCheckoutSession(sessionId, shippingAddress, deliveryChoice, promoCode)
completeCheckout(sessionId, delegatedPaymentToken)
getOrderStatus(orderId)
getReturnEligibility(orderId, itemIds)
openSupportCase(orderId, reason)

Ces noms d'endpoints sont des exemples architecturaux, pas une partie de la spécification publiée d'OpenAI. L'idée est que la bordure marchande devrait orchestrer des capacités métier plutôt que réutiliser des API de boutique.

Garder la vérité dans les systèmes sources

Un échec fréquent dans les projets d'intégration consiste à transformer le middleware en une seconde source de vérité accidentelle. Ce canal devrait l'éviter.

La bordure marchande devrait orchestrer, pas posséder la réalité. La vérité produit devrait rester avec le catalogue ou le PIM. La vérité tarifaire devrait rester avec les services de tarification et de promotions. La vérité inventaire devrait rester avec les services d'inventaire ou ATP. La vérité taxes et livraison devrait rester avec les calculateurs correspondants. La vérité commande devrait rester avec l'OMS. La vérité paiement devrait rester avec le PSP et les systèmes de paiement du marchand.

Cette conception maintient la réconciliation gérable et rend le nouveau canal beaucoup plus facile à exploiter.

Comment fonctionne réellement le paiement délégué

La spécification de paiement délégué d'OpenAI est assez spécifique pour que les développeurs puissent raisonner sur le flux sans deviner.

Selon la spécification, l'acheteur passe en checkout en utilisant un mode de paiement préféré enregistré dans ChatGPT. OpenAI envoie ensuite une charge utile de paiement délégué directement au PSP ou au vault du marchand. Le paiement délégué est à usage unique et contraint par des limites comme le montant maximum, la devise, l'ID de session de checkout, l'ID de marchand, et l'expiration. Le PSP ou le vault retourne un token de paiement étendu à ce paiement délégué, et OpenAI transmet le token lors de l'appel de complétion de checkout pour que le marchand puisse finaliser la transaction.

OpenAI énonce également plusieurs contraintes importantes. OpenAI n'est pas le marchand d'enregistrement. Les marchands sont censés apporter leur propre PSP et traiter les paiements comme ils le feraient pour toute autre transaction numérique. Le règlement, les remboursements, les litiges et la conformité restent avec le marchand et son PSP. L'intégration directe avec la spécification de paiement délégué est destinée aux PSP ou aux marchands de niveau PCI DSS 1 utilisant leurs propres vaults, tandis que d'autres marchands peuvent utiliser une implémentation de PSP compatible comme le chemin de Shared Payment Token de Stripe.

Du point de vue de l'implémentation, la conclusion est simple : ne refaites pas les paiements. Intégrez le flux de token délégué dans le chemin PSP existant du marchand, préservez l'idempotence et la traçabilité, et créez la commande uniquement après que les vérifications d'autorisation et de politique côté marchand aient réussi.

Une séquence runtime pratique

Une fois que le flux existe et que la bordure marchande est en place, le runtime bout-en-bout devient plus facile à raisonner.

L'acheteur exprime son intention dans ChatGPT.
ChatGPT demande les données produit via la bordure marchande.
La bordure marchande interroge les services de catalogue, tarification et inventaire et retourne des résultats normalisés.
ChatGPT initie ou met à jour une session de checkout via des endpoints compatibles ACP.
La bordure marchande résout l'expédition, les taxes, les promotions et les totaux finaux auprès des services faisant autorité.
OpenAI déclenche le paiement délégué via le flux PSP ou vault.
Le marchand reçoit le token de paiement délégué et finalise l'autorisation sur ses propres systèmes.
Le marchand accepte ou refuse la commande et retourne cet état à ChatGPT.
Si approuvée, le marchand crée la commande OMS, réserve l'inventaire, et déclenche l'exécution en aval.
Le service post-commande continue via les propres systèmes opérationnels du marchand.

Cette séquence n'est pas copiée d'une seule page OpenAI. C'est une synthèse pratique des flux de flux, checkout et paiement documentés en une architecture marchande implémentable.

Ce qui casse généralement en premier

Les points faibles de cette architecture ne sont généralement pas surprenants.

Les données de flux dérivent de l'inventaire réel.
Les promotions sont résolues différemment dans différents services.
Les totaux d'expédition et de taxes changent entre les étapes.
Les flux de token PSP heurtent des cas limites autour des retries ou de l'expiration.
La logique de fraude et de risque n'a pas été conçue avec ce canal à l'esprit.
Les systèmes OMS ou de support ne sont pas intégrés assez tôt.

Les propres directives d'OpenAI laissent déjà entrevoir l'un des principaux correctifs : utilisez des instantanés quotidiens plus des mises à jour API plutôt que de vous reposer sur un flux statique une fois par jour si l'état commercial sous-jacent change plus fréquemment. Les promotions sont également explicitement pilotées par API, ce qui signifie que le marchand a besoin d'un chemin de mise à jour robuste au-delà de la livraison de fichiers statiques.

Le reste relève d'une discipline d'ingénierie familière : un seul chemin de calcul de checkout faisant autorité, une propriété de service claire, des écritures idempotentes, et de l'observabilité sur chaque transition critique.

Un déploiement progressif réaliste

Le déploiement le plus sûr est étroit.

OpenAI précise que l'intégration du flux de produits dans ChatGPT est actuellement disponible pour les partenaires approuvés, et que l'Instant Checkout dans ChatGPT est également disponible pour les partenaires approuvés. Cela signifie que la première phase n'est pas un déploiement complet en production. C'est la préparation, l'accès et le contrôle de la portée.

Un plan progressif pratique ressemble à ceci :

Phase 0 : préparation

Confirmer le chemin d'accès partenaire.
Rédiger une courte note d'architecture.
Identifier les systèmes sources et les propriétaires.
Réviser la politique des produits prohibés et la propriété de la conformité.

Phase 1 : préparation du catalogue

Mapper les champs du flux.
Valider les champs obligatoires.
Générer et soumettre un échantillon initial.
Publier des instantanés quotidiens.
Ajouter des mises à jour API intra-journalières pour les données changeantes.

Phase 2 : orchestration des transactions

Construire les endpoints de la bordure marchande.
Connecter les services de tarification, inventaire, taxes, livraison et promotions.
Intégrer le paiement délégué avec le chemin PSP.
Retourner les décisions de commande et les états de confirmation appartenant au marchand.

Phase 3 : opérations post-commande

Connecter les événements OMS.
Ajouter les recherches de statut de commande.
Ajouter la logique d'annulation et d'éligibilité aux retours.
Router le support via la stack de service du marchand.

Ce plan progressif n'est pas imposé par OpenAI, mais il correspond au modèle de plateforme documenté et réduit le risque en évitant un déploiement du type "tout connecter en même temps".

Quoi dire à la direction

Les équipes de direction peuvent entendre "ChatGPT Commerce" et supposer qu'il s'agit d'un module complémentaire de chatbot ou d'une intégration UI légère. La description la plus exacte est différente.

C'est un nouveau canal qui utilise les capacités commerciales existantes du marchand via des flux structurés, des flux de checkout basés sur ACP, et des paiements délégués, tout en conservant la responsabilité du marchand pour le paiement, l'acceptation de commande, l'exécution, la conformité et le support client.

Ce cadrage est utile car il maintient la conversation honnête. L'opportunité est réelle, mais le travail d'implémentation l'est tout autant.

Point final

La manière la plus utile de penser au ChatGPT Commerce n'est pas comme un remplacement de la stack commerciale, mais comme un nouveau canal d'intention qui exige une exposition plus propre de la stack que le marchand possède déjà. La documentation d'OpenAI est explicite sur la propriété marchande de la qualité produit, du traitement des paiements, de l'acceptation de commande, et du suivi opérationnel.

L'originalité dans l'implémentation ne vient pas d'inventer de nouveaux faits sur la plateforme. Elle vient de bien construire la bordure marchande, de garder la vérité métier dans les bons systèmes, et de déployer le canal de manière étroite, observable et supportable.

Préparez-vous au ChatGPT Commerce : un plan d'implémentation pratique pour les entreprises