Le 2 septembre 2026, Anthropic a publié un blueprint de commerce agentique comprenant des implémentations de référence pour un agent d’achat et un agent destiné aux équipes marchandes. L’éditeur décrit une architecture articulée autour d’un modèle, de compétences, d’outils métier et d’une suite d’évaluations. L’annonce arrive alors que les plateformes cherchent à déplacer la recherche, la comparaison et la constitution du panier dans une conversation. La difficulté réelle n’est pourtant pas de produire un dialogue convaincant : elle est de préserver la vérité du catalogue, l’état du panier, le consentement et la responsabilité du paiement.
À retenir : un agent de commerce doit raisonner librement mais agir dans des interfaces étroites et déterministes. Le catalogue, le prix, le stock, les conditions et le panier restent des sources de vérité externes. L’agent propose et orchestre ; les services métier valident, persistent et confirment.
1. Ce que recouvre réellement un agent de commerce
Un agent d’achat aide un client à formuler un besoin, chercher des produits, comparer des options, construire un ensemble cohérent et transmettre un panier au checkout. Il peut également répondre à des questions après la commande, comme le suivi, le retour ou la politique de remboursement.
Un agent marchand s’adresse aux équipes de l’entreprise. Il analyse les ventes et les stocks, signale un risque de rupture, suggère une promotion ou prépare une campagne. Les actions externes — modification de prix, publication ou commande fournisseur — doivent rester soumises à une approbation explicite.
Ces deux agents utilisent parfois les mêmes données, mais leurs permissions diffèrent. L’agent client lit le catalogue et modifie le panier de la session. L’agent marchand peut accéder à des agrégats, des marges et des stocks plus larges. Les réunir sous une identité unique augmente inutilement le risque.
Anthropic annonce que certains utilisateurs de ses agents ont observé des paniers jusqu’à 35 % plus élevés et une probabilité d’achat supérieure de 60 %. Ces chiffres sont présentés par le fournisseur et ne constituent pas une garantie applicable à tous les secteurs. Ils doivent servir d’hypothèse à tester, avec une attention particulière aux effets de sélection, à la marge et aux retours.
Le succès ne peut pas être réduit à la taille du panier. Un agent qui pousse des produits inadaptés peut augmenter le montant immédiat tout en dégradant la confiance, le taux de retour et la valeur client.
2. Une architecture simple avant une multiplication de sous-agents
Le guide technique d’Anthropic propose un modèle principal dans une boucle agentique, équipé de compétences et d’outils. Il déconseille de créer un sous-agent par domaine lorsque la conversation, les préférences et le panier doivent rester cohérents au fil des tours.
Cette recommandation est pragmatique. Chaque délégation exige de transférer un contexte, introduit de la latence et crée un risque de perte d’état. Une demande comme « remplace la veste par une option moins chère mais garde la livraison vendredi » combine recherche, comparaison, panier et logistique ; elle se découpe mal en silos.
Les compétences permettent de charger des procédures au moment opportun : politique de retour, guide de compatibilité, méthode de comparaison ou règles de style. Les outils effectuent les opérations déterministes : rechercher, vérifier le stock, créer un panier, calculer une livraison ou lire une commande.
Un sous-agent reste utile pour une tâche autonome et volumineuse, comme une recherche approfondie dont seul le résultat synthétique revient à l’orchestrateur. Il peut aussi être justifié lorsqu’un domaine réglementé possède son propre agent, son identité et son parcours de conformité.
La règle est de ne pas confondre modularité du code et multiplication des agents. Les services métier restent modulaires ; la conversation peut conserver un seul propriétaire tant que le contexte doit rester partagé.
3. Garder catalogue, prix et stock comme sources de vérité
Le modèle ne doit jamais inventer la fiche produit. Il reçoit des résultats structurés d’un moteur de recherche ou d’une API catalogue : identifiant, variante, prix courant, disponibilité, caractéristiques, conditions et URL canonique.
La réponse affichée doit pouvoir être reliée à ces objets. Lorsque l’agent affirme qu’un produit est disponible, l’interface montre l’heure de vérification. Avant l’ajout au panier et avant le checkout, le service revérifie le prix et le stock.
Les outils imposent des schémas stricts. L’agent peut demander search_products avec un besoin et des filtres autorisés, mais il ne compose pas une requête SQL ni une URL interne. Il peut demander get_offer pour un identifiant de variante, sans fournir lui-même le prix attendu.
Les comparaisons doivent distinguer faits et appréciations. Le poids, la garantie et la composition proviennent du catalogue. « Plus adapté à un week-end avec deux enfants » est une recommandation produite par l’agent, qui doit être justifiée par les critères exprimés.
Les règles commerciales restent déterministes. Une remise, une éligibilité, des frais ou une limite de quantité sont calculés par les services existants. Le modèle peut expliquer le résultat, mais il ne réécrit pas la politique.
Cette architecture s’inscrit dans la préparation décrite dans notre article sur le commerce agentique et l’exposition du catalogue et du checkout.
4. Rendre le panier idempotent et explicable
Le panier est un objet transactionnel, pas un paragraphe de conversation. Il possède un identifiant, une version et un état conservé par le système de commerce. Chaque modification utilise une clé d’idempotence afin qu’une reprise réseau ou une répétition du modèle ne double pas les quantités.
Les outils doivent exprimer l’intention : ajouter telle variante, modifier une quantité, supprimer une ligne ou appliquer une option. Le service vérifie la version du panier et refuse une écriture si un autre canal l’a modifié entre-temps. L’agent relit alors l’état et explique le conflit.
Avant une modification importante, l’interface présente la conséquence : produit, variante, quantité, prix unitaire, total et éventuelle substitution. Une confirmation est nécessaire lorsque l’agent change une caractéristique essentielle, remplace plusieurs articles ou dépasse un budget exprimé.
Conservez la provenance de chaque ligne. Le client doit savoir ce qu’il a explicitement demandé, ce que l’agent a suggéré et ce qu’il a confirmé. Cette distinction facilite le support et évite qu’une recommandation soit perçue comme un choix certain de l’utilisateur.
Prévoyez le retour arrière. Tant que le checkout n’est pas engagé, une opération inverse doit pouvoir restaurer la version précédente. Les changements sont journalisés sans stocker inutilement l’intégralité de la conversation.
5. Séparer recommandation, confirmation et paiement
Le paiement constitue une frontière. Anthropic indique que son blueprint laisse le paiement au marchand, via le checkout existant ou un fournisseur de paiement agentique. Cette séparation doit être conservée, même lorsque l’expérience paraît continue.
L’agent peut préparer le panier, collecter des préférences de livraison et expliquer les conditions. Un service déterministe calcule le total final, les taxes, la livraison et les promotions. L’utilisateur voit un récapitulatif complet avant de confirmer.
La confirmation doit être récente et spécifique. Elle inclut le marchand, le montant, la devise, l’adresse, le mode de livraison, les articles et les conditions principales. Une phrase ancienne comme « oui, prends-les » ne doit pas être réutilisée après une modification du panier.
Les données de paiement ne doivent pas entrer dans le contexte du modèle. Elles sont saisies dans un composant du prestataire et tokenisées. L’agent reçoit seulement un statut et un identifiant de transaction non sensible.
En cas d’ambiguïté, l’état reste payment_pending plutôt que paid. Les webhooks sont traités de manière idempotente et le statut affiché provient du backend. Un agent ne déduit jamais le succès d’un simple changement visuel dans le navigateur.
Pour les actions marchandes, appliquez la même logique. Une proposition de baisse de prix ou de campagne est un brouillon. Une personne autorisée valide l’objet, le périmètre, la date et l’impact avant publication.
6. Personnaliser sans franchir la frontière du consentement
La personnalisation peut améliorer la pertinence, mais elle rassemble rapidement préférences déclarées, historique, comportement, budget et contexte. L’utilisateur doit comprendre quelles données sont utilisées et pouvoir corriger ou supprimer une préférence.
Distinguez la mémoire de session de la mémoire durable. La première sert au parcours actuel et expire. La seconde n’est créée que pour une finalité claire, avec une base juridique et une interface de gestion. Une préférence déduite ne doit pas être enregistrée comme un fait sans validation.
Évitez les catégories sensibles ou les inférences susceptibles de produire une discrimination. Un agent ne doit pas ajuster le prix ou la qualité du service en fonction d’une vulnérabilité supposée. Les règles de recommandation doivent être auditées et compatibles avec la politique commerciale.
Anthropic indique que son blueprint vise à contraindre les suggestions aux produits et prix réels et à éviter les pratiques d’upsell manipulatrices. L’organisation doit traduire cet objectif en contrôles testables : respecter le budget, présenter les alternatives moins chères, expliquer les commissions, ne pas créer de rareté fictive et ne pas masquer une option pertinente.
Mesurez également les effets après l’achat : annulations, retours, réclamations et satisfaction. Une personnalisation responsable optimise la pertinence sur la durée, pas la pression au moment du checkout.
7. Tester un système non déterministe avec des évaluations métier
Une suite d’évaluations doit couvrir le raisonnement, les outils, l’interface et le résultat transactionnel. Commencez par des scénarios représentatifs : demande multi-produits, budget strict, incompatibilité, rupture, variante ambiguë, livraison urgente, retour et question sur une commande.
Ajoutez des cas adverses : instruction malveillante dans une description produit, prix contradictoire, outil lent, stock modifié en cours de tâche, répétition d’un webhook et tentative d’obtenir une donnée d’un autre client. Vérifiez que les politiques restent appliquées indépendamment de la réponse du modèle.
Mesurez : taux de tâche terminée, exactitude des produits et prix, cohérence du panier, nombre de tours, latence, coût, confirmations demandées, erreurs transactionnelles et interventions humaines. Pour la qualité commerciale, suivez conversion, marge, taille du panier, satisfaction, retours et valeur à trente ou quatre-vingt-dix jours.
Les évaluations hors ligne ne suffisent pas. Un pilote A/B peut comparer l’agent à la recherche classique, mais doit maintenir une expérience témoin et des garde-fous identiques. Les résultats sont segmentés par type de demande, terminal et complexité.
Examinez les conversations échouées avec une taxonomie : mauvaise compréhension, catalogue incomplet, outil en erreur, choix inadapté, politique bloquante ou interface confuse. Cette analyse oriente les améliorations mieux qu’un prompt toujours plus long.
À chaque changement de modèle, de compétence, d’outil ou de catalogue, rejouez les scénarios critiques. Un agent est un système en mouvement ; sa certification n’est jamais définitive.
8. Déployer un pilote en quatre-vingt-dix jours
Pendant les trente premiers jours, choisissez un parcours borné et non critique : une catégorie de produits, un pays, des utilisateurs volontaires et un checkout existant. Exposez le catalogue en lecture, construisez le panier dans un environnement de test et définissez les évaluations.
Du jour 31 au jour 60, ouvrez le pilote avec des écritures réversibles sur le panier. Conservez une validation explicite avant toute transition vers le checkout. Mesurez les erreurs, la latence, le coût et les demandes abandonnées. Corrigez les données et les outils avant d’augmenter l’autonomie.
Du jour 61 au jour 90, ajoutez progressivement le suivi de commande ou quelques fonctions marchandes en lecture seule. Les recommandations de prix et de campagne restent des brouillons. Réalisez un exercice d’incident : catalogue indisponible, confirmation dupliquée, modèle dégradé ou politique de retour incorrecte.
Les critères de passage à l’échelle doivent être définis avant le pilote : zéro erreur de montant tolérée, taux minimal de tâche terminée, plafond de latence, coût par session, satisfaction, taux de retour et absence d’écart de politique. Une hausse de conversion ne compense pas une perte d’intégrité transactionnelle.
Prévoyez un mode dégradé. Si le modèle ou un outil n’est pas disponible, l’utilisateur retrouve la recherche, le panier et le support classiques sans perdre son état. L’agent enrichit le commerce ; il ne doit pas devenir un point de défaillance unique.
Conclusion
Les agents de commerce peuvent réduire la friction entre l’intention et l’achat, notamment pour les demandes complexes qui combinent plusieurs produits, critères et étapes. Leur valeur dépend moins de l’éloquence du modèle que de l’architecture qui l’entoure.
Catalogue, prix, stock, panier et paiement doivent rester déterministes et vérifiables. L’agent orchestre des outils étroits, demande des confirmations précises, respecte le consentement et est évalué sur la qualité durable de la transaction. Partitech accompagne les acteurs du commerce dans la conception de ces architectures, l’intégration aux systèmes existants et la construction de pilotes mesurables et réversibles.
Références vérifiées le 3 septembre 2026
- Anthropic — « Building commerce agents with Claude », 2 septembre 2026 : https://claude.com/blog/claude-for-commerce-agents
- Anthropic — « A guide to the anatomy of effective commerce agents », 2 septembre 2026 : https://claude.com/blog/the-anatomy-of-effective-commerce-agents
- Anthropic — dépôt de référence Commerce Agents : https://github.com/anthropics/commerce-agents