Le 2 septembre 2026, Anthropic a publié sur GitHub un dépôt qui va faire du bruit dans l'e-commerce sans que personne n'en parle vraiment : anthropics/commerce-agents, sous licence Apache 2.0. Pas un produit, pas une marketplace, pas une nouvelle plateforme à rejoindre. Un plan de référence open source pour construire soi-même des agents shopping et des agents marchands avec Claude. Si tu vends en ligne et que tu suis le guide complet pour apprendre Claude, c'est la brique qui te manquait pour passer du chatbot gadget à quelque chose qui touche vraiment au chiffre d'affaires.
Je vais te dire ce qu'il y a dedans, ce qui marche déjà, ce qui reste à construire, et surtout ce qu'un marchand francophone peut poser cette semaine sans embaucher.
Ce que recouvre Claude Commerce Agents
Le dépôt fournit deux agents prêts à cloner. Un agent shopping côté client : il cherche des produits, compare, construit un plan d'achat, gère le panier, coordonne le passage en caisse, répond aux questions sur les commandes et les politiques, garde en mémoire le profil du client. Un agent marchand côté back-office : il analyse la performance, corrige les fiches produits, remonte les alertes stock et commandes, gère la tarification et les promotions, prépare les brouillons de campagnes.
Le même code tourne sur trois runtimes au choix, avec les mêmes prompts, les mêmes skills, les mêmes contrats d'outils : l'API Messages directement, l'Agent SDK, ou Claude Managed Agents (agents hébergés par Anthropic). Tu écris ton agent une fois, tu choisis ensuite où il tourne selon ton budget et ton besoin d'autonomie opérationnelle.
Point important à comprendre tout de suite : le dépôt fournit des interfaces génériques à implémenter (StorefrontBackend, MerchantBackend). Aucune intégration prête à l'emploi avec Shopify, WooCommerce ou PrestaShop n'est livrée. Anthropic te donne la charpente et la logique de l'agent, tu branches ton propre catalogue. C'est un blueprint, pas un plugin.
Autre nuance à retenir : le dépôt est explicitement marqué comme non maintenu et n'accepte pas de contributions externes. Ce n'est pas un produit Anthropic avec support et roadmap, c'est une implémentation de référence à forker.
Pourquoi Anthropic pousse l'open source ici
Le pari est lisible. Plutôt que de construire une marketplace fermée à la Amazon où Claude serait l'intermédiaire propriétaire entre acheteurs et vendeurs, Anthropic publie la mécanique en open source pour que n'importe quel marchand branche son catalogue à n'importe quel agent, Claude ou autre. La brique de communication sous-jacente, c'est le Model Context Protocol (MCP), un standard ouvert créé par Anthropic en 2024 et gouverné en 2026 avec plusieurs éditeurs.
Pour un marchand, l'enjeu concret est simple : ne pas dépendre d'une plateforme unique qui capterait la relation client. Si demain trois agents shopping différents (l'un dans Claude, l'un dans ChatGPT, l'un dans un navigateur) peuvent tous interroger ton catalogue via un protocole commun, tu vends via chacun d'eux sans réécrire ton intégration à chaque fois. C'est le pari que fait Anthropic, et c'est ce qui rend le sujet stratégique même si tu n'utilises pas Claude aujourd'hui.
Les quatre types d'agents commerce que ça débloque
Voici comment se répartissent les cas d'usage concrets, avec le niveau de difficulté honnête pour chacun.
| Agent | Cas concret | Brique MCP requise | Difficulté |
|---|---|---|---|
| Agent vendeur | Répond aux 20 questions produit récurrentes, 24/7, en français | Lecture catalogue + FAQ + politique retour | Facile, quelques jours |
| Agent shopping | Achète à la place du client sur brief ("un cadeau à 40 € pour ma sœur") | Recherche produit + panier + checkout | Moyenne, dépend du checkout |
| Agent opérations | Alerte stock bas, propose réassort, traite les demandes de remboursement niveau 1 | Écriture stock + commandes + remboursements | Moyenne, avec approbation humaine |
| Agent contenu | Génère fiches produits, emails post-achat, briefs Ads à partir du catalogue | Lecture catalogue + écriture CMS | Facile, fort ROI immédiat |
Le dépôt Commerce Agents met explicitement en place ce qu'Anthropic appelle des staged writes côté agent marchand : chaque modification proposée (prix, fiche produit, campagne) est mise en attente et doit être approuvée par un humain avant exécution. Aucune action n'est automatique. C'est un choix de design important à ne pas retirer sous prétexte de vouloir tout automatiser.
La stack technique concrète aujourd'hui
Ce que tu peux brancher maintenant, sans attendre une v2 d'Anthropic :
- Le Claude Agent SDK pour orchestrer les tours de conversation et les appels d'outils
- Un serveur MCP maison qui expose ton catalogue (produits, stock, prix, politique retour) en lecture, et tes commandes en lecture/écriture
- Des Skills personnalisés pour encoder les règles métier propres à ta boutique (grille de remises fidélité, politique d'échange saisonnier, ton de marque)
- Claude Fable 5.1 ou Opus 5 pour l'agent lui-même selon la complexité des demandes
L'architecture type se lit en trois couches. Couche données : ton catalogue structuré et ton API commande, accessibles via un serveur MCP. Couche agent : le SDK Claude qui appelle les outils MCP au bon moment. Couche interface : un widget sur ta boutique, un canal Slack pour ton équipe, ou WhatsApp Business pour tes clients.
Les limites réelles à connaître avant de te lancer. La latence d'un tour agent complet (lecture catalogue + raisonnement + réponse) dépend fortement de la complexité de la requête et du modèle choisi : à mesurer sur ton propre catalogue avant de promettre un chat live instantané, surtout avec un modèle de raisonnement poussé comme Opus sans réglage. Le coût par conversation dépend du volume de contexte injecté : un agent qui recharge ton catalogue complet à chaque tour va exploser ta facture, il faut absolument utiliser le cache de prompt (voir le nouveau tarif cache read de Fable 5.1). La gestion du panier multi-tours reste ta responsabilité : Claude ne stocke pas ton panier, il envoie des appels d'outils que ton backend doit persister.
Préparer sa boutique aux agents acheteurs
Voici où beaucoup de marchands vont se rater. Un agent shopping ne lit pas ta page produit comme un humain. Il n'a pas d'yeux pour ton hero image, il ne se laisse pas convaincre par un badge "bestseller", et il ne clique pas sur ton onglet "livraison" caché en bas de page. Il interroge une API ou un serveur MCP, il reçoit des attributs structurés, il compare.
Ce qu'il te faut :
- Un catalogue structuré au format schema.org Product avec des attributs riches : matière, dimensions, poids, compatibilité, allergènes selon ton secteur
- Une API accessible (REST ou GraphQL) qui expose stock et prix en temps réel, pas un dump quotidien
- Une politique de retour rédigée en langage clair et découpée en champs lisibles (délai en jours, conditions, qui paie le retour)
- Des variantes produit exposées comme telles, pas noyées dans un texte descriptif
Si tu pars de zéro sur la partie catalogue et boutique, mieux vaut poser les bonnes bases dès le début : le pilier créer un site web avec Claude couvre cette étape avant même de penser aux agents. Et pour la partie configuration technique (clés API, SDK, environnement local), le pilier setup te sert de checklist.
Ce que ça change pour le SEO et le marketing
L'agent shopping court-circuite la page produit classique. Si un client demande à Claude "trouve-moi une écharpe en laine mérinos autour de 60 €", l'agent interroge des catalogues via MCP, compare des attributs structurés, et propose deux ou trois options. Ta page produit n'a jamais été visitée par un humain, ton A/B test sur le bouton "ajouter au panier" n'a servi à rien pour cette vente.
Conséquences concrètes que tu vas observer, probablement dès 2027 selon la vitesse d'adoption des agents shopping grand public :
- Baisse progressive du trafic direct sur les pages produits classiques
- Hausse du trafic API et agent, souvent invisible dans Google Analytics
- Nécessité de nourrir les modèles avec du contenu factuel plutôt que persuasif
- Retour en force du travail sur la donnée produit propre, structurée, à jour
On appelle parfois ça GEO (Generative Engine Optimization), un mot un peu creux qui recouvre une idée simple : ce qui fait qu'un LLM cite ou choisit ton produit n'est pas ce qui fait qu'un humain clique dessus. Une fiche produit qui convertit un humain joue sur l'émotion, la preuve sociale, l'urgence. Une fiche qui convainc un agent joue sur l'exactitude des attributs, la disponibilité vérifiable, la clarté de la politique retour.
Pour la partie contenu généré par Claude sur tes fiches produits et emails, le pilier e-commerce détaille les workflows concrets. Le contenu reste utile, il change juste de public : de plus en plus, tu écris pour un lecteur qui n'est pas humain.
Par où commencer cette semaine
Cinq étapes qui tiennent sur cinq jours pour un marchand solo ou une petite équipe :
- Audit catalogue. Exporte ton catalogue et regarde ce qui manque : attributs structurés, variantes, politique retour lisible. Deux heures suffisent pour voir l'état réel.
- Test d'un serveur MCP local. Clone un serveur MCP d'exemple, connecte-le à un extrait de ton catalogue en JSON, teste depuis Claude Desktop. Tu comprends la mécanique en une après-midi.
- Prototype d'agent SAV. Prends les 10 questions les plus fréquentes de ton service client, écris un agent qui y répond via le SDK, teste sur 50 messages historiques. Le coût réel dépend de ton volume de contexte et du modèle choisi : à mesurer directement sur ce prototype, avec Sonnet ou Haiku pour rester sur un budget de test contenu.
- Mesure du coût réel. Regarde ce que consomme ton prototype par conversation, extrapole à ton volume mensuel. Si ça tient, tu passes en pilote sur ton site. Sinon, tu ajustes le modèle ou le cache.
- Décision go/no-go. Un pilote de deux semaines avec métriques claires (taux de résolution, satisfaction, coût par ticket évité) tranche mieux qu'un débat interne d'un mois.
Le point le plus sous-estimé : l'agent SAV. C'est le cas d'usage qui rapporte le plus vite, pour le moins de risque et de complexité. Un marchand qui reçoit un volume régulier de tickets peut en absorber une bonne partie via un agent bien configuré, en gardant l'humain sur les cas non triviaux. Le ROI se mesure généralement plus vite que sur un projet d'automatisation classique, mais reste à vérifier sur ton propre pilote.
Si tu veux passer de la théorie à un vrai projet suivi, avec un pipeline Claude complet (setup, site, blog, automatisation, marketing) construit sur cinq semaines, la formation Maîtriser Claude au quotidien couvre ces briques dans l'ordre où un e-commerçant en a besoin, y compris la partie serveurs MCP et Agent SDK.