Agent IA e-commerce : construire un assistant d’achat avec Claude

Il est désormais possible de lancer un agent IA e-commerce sans repartir de zéro : la boucle agentique, les skills, les contrats d’outils, les garde-fous et les patterns d’interface sont déjà définis. Claude Commerce Agents fournit ce cadre. Le vrai travail consiste à le connecter à des données catalogue fiables, à rattacher chaque action au bon client, à maintenir les stocks à jour et à arrêter le modèle avant tout paiement ou changement irréversible.

Cet effort de mise en production compte, car les gains se mesurent. Selon Anthropic, les distributeurs qui utilisent des agents shopping sur Claude ont vu le montant des paniers progresser jusqu’à 35%, tandis que les clients étaient 60% plus susceptibles de finaliser leur achat. Ces chiffres ne constituent pas une promesse pour toutes les boutiques. Ils invitent à considérer l’agent comme un produit de conversion, et non comme un simple widget de chat.

Claude Commerce Agents cadre l’agent IA e-commerce, pas la boutique

Claude Commerce Agents est une implémentation de référence sous licence Apache-2.0 qui couvre deux rôles. Côté client, l’agent shopping peut rechercher et comparer des articles, préparer un achat composé de plusieurs produits, remplir un panier, répondre aux questions sur les politiques de la boutique ou les commandes, et mémoriser des préférences. En coulisses, l’agent marchand peut analyser les performances, surveiller les stocks, suggérer des ajustements de prix et préparer des campagnes.

Pour un agent destiné aux clients, l’architecture reste volontairement simple : un modèle exécute une boucle, les règles communes figurent dans son prompt système, les procédures moins fréquentes sont réparties entre cinq skills, et des outils appellent les systèmes e-commerce déjà en place. Imaginez un conseiller de vente expérimenté à un comptoir. Il garde le fil de toute la conversation, mais consulte le terminal de la réserve pour le stock, le système client pour l’identité et la caisse pour le panier.

La même définition peut fonctionner avec Messages API, Claude Agent SDK ou Claude Managed Agents. Cette portabilité est utile, mais elle ne transforme pas les exemples en solution prête pour la production. Anthropic précise que les démonstrations ne comportent aucune authentification. Le dépôt ne passe pas commande, ne débite aucune carte et n’intègre pas vos règles de lutte contre la fraude, d’éligibilité, de stock ou de conformité.

L’équation économique commence après la démo

Le blueprint réduit le coût nécessaire pour obtenir une première version crédible. Sur la page de lancement d’Anthropic, Wix indique avoir créé en 15 minutes un prototype capable de recevoir un prompt, Fetch affirme avoir exécuté localement les deux agents de référence en nettement moins d’une heure, et Zomato estime que les pratiques fournies peuvent épargner plusieurs semaines de tâtonnements aux équipes. Il s’agit de retours de partenaires, pas de garanties de livraison. Le déplacement budgétaire est néanmoins clair : moins de temps d’ingénierie sert à inventer l’ossature de l’agent, davantage à fiabiliser le catalogue, les droits, les évaluations et le dernier kilomètre jusqu’au checkout.

Le coût du modèle peut également rester faible face au travail d’intégration. Claude Sonnet 5 est facturé $2 par million de tokens d’entrée frais, $0.20 par million de tokens d’entrée servis depuis le cache et $10 par million de tokens de sortie. Pour un tour illustratif comprenant 20,000 tokens d’entrée et 800 tokens de sortie, le modèle coûte $0.048 si tous les tokens d’entrée sont frais. Si 18,000 tokens d’entrée proviennent du cache et que 2,000 sont frais, le même calcul donne $0.0156. Cette estimation exclut la recherche, l’hébergement, l’observabilité, le support et toutes les API e-commerce qui entourent le modèle.

Anthropic indique que ses déploiements e-commerce les plus performants atteignent des taux d’accès au cache de 90% à 99%. Le budget de production ne se résume donc pas à « acheter un LLM ». Il faut rendre chaque parcours d’achat finalisé exact, rapide, attribuable et sûr.

Comment construire un parcours prêt pour la production

L’ordre de développement doit suivre les revenus et les risques. Commencez par le besoin d’achat, puis connectez les données et l’identité, ouvrez ensuite les actions, et optimisez enfin la vitesse. Une conversation impeccable fondée sur un stock périmé reste l’équivalent d’une boutique défaillante.

1. Choisir un seul besoin d’achat et un seul indicateur de réussite

Ne partez pas de l’objectif « répondre à toutes les questions sur notre catalogue ». Ciblez plutôt une mission précise : aider un client à choisir la bonne taille de matelas, constituer un kit de camping de trois produits dans un budget donné, ou trouver un remplacement disponible pour un article en rupture.

La réussite doit correspondre à une tâche accomplie, pas à une réponse agréable. Parmi les indicateurs utiles figurent une sélection de produits étayée par les données, une recommandation acceptée, un ajout au panier, un transfert vers le checkout, une résolution sans ticket de support et le taux de retour des commandes assistées. Suivez le montant du panier et la finalisation de l’achat au même titre que la latence et le coût du modèle. Même peu chère, une réponse devient coûteuse lorsqu’elle recommande la mauvaise variante.

2. Placer la recherche et le classement existants derrière l’outil catalogue

Le modèle ne doit pas devenir votre moteur de recherche. Dans le pattern d’Anthropic, search_products renvoie des résultats déjà classés. Claude détermine ensuite quels articles respectent les contraintes du client et combien en présenter.

Structurez le catalogue sous trois formes : produits simples, familles de produits et variantes achetables. Une famille de chemises peut regrouper les options de taille et de couleur, tandis que chaque variante porte son prix et son stock actuels. La recherche peut renvoyer la famille, mais toute écriture dans le panier doit désigner la variante exacte. Cette distinction empêche un agent convaincant d’ajouter une « chemise bleue » sans savoir si le modèle bleu en taille M est disponible.

Ne renvoyez que les champs nécessaires au raisonnement du modèle. L’identifiant du produit, le titre, le prix, la disponibilité, les valeurs des options, les attributs importants et l’horodatage de la source suffisent généralement. Répéter les URL d’images et de longs textes marketing pour chaque résultat consomme du contexte sans améliorer la décision.

Si vous disposez déjà d’un service de recherche ou de recommandation, conservez-y la logique métier. Sinon, corrigez la récupération des résultats avant d’ajuster le prompt. Un outil catalogue ne peut pas compenser des attributs incomplets, des SKU en double ou un classement qui ignore les contraintes du client.

3. Lier l’identité avant d’exposer le moindre outil au modèle

L’authentification relève de l’application hôte. Celle-ci connecte le client, lui associe une identité de client ou d’invité, puis ouvre une session. Les méthodes backend lisent cette identité dans l’état de session côté serveur. Le modèle ne reçoit ni l’identifiant client comme argument d’outil, ni le credential utilisé pour appeler votre boutique.

Traitez les invités comme de véritables identités, mais avec moins de droits. Si un invité demande l’historique de ses commandes ou ses adresses enregistrées, le backend doit exiger une connexion. Après l’authentification, ouvrez une nouvelle session au lieu de transformer en cours de conversation une identité anonyme.

Ce cloisonnement paraît secondaire dans une démo, mais devient coûteux à ajouter après coup. Il marque la différence entre « l’agent a appelé l’outil de commande » et « ce client authentifié avait le droit de consulter cette commande ».

4. Faire du stock la source d’autorité au moment de l’action

Les résultats de recherche aident l’agent à raisonner, mais le backend détient la vérité. Vérifiez de nouveau le stock, l’éligibilité, le prix, les limites d’achat, les heures limites de traitement et les règles promotionnelles au sein même de l’opération sur le panier. Cette vérification doit être atomique : si le stock disparaît entre la lecture et l’écriture, la réponse doit l’indiquer sans ambiguïté.

Lorsqu’une variante demandée n’est plus disponible, renvoyez son identifiant ainsi que les variantes valides de la même famille. L’agent peut alors expliquer le compromis et laisser le client choisir. Ne remplacez jamais un produit en silence. Pour une marketplace, une tarification liée au compte, des dates de voyage ou un retrait propre à un magasin, transmettez le contexte pertinent au backend chargé du calcul.

5. Traiter chaque outil comme une surface d’API soumise à autorisation

L’implémentation de référence construit la liste des outils visibles à partir de la configuration de déploiement. Désactivez les systèmes absents de votre environnement. Placez les noms restants sur liste blanche. Dans le code, refusez tout appel qui sort de cette liste.

Ajoutez ensuite des contrôles de provenance. Une écriture dans le panier ne doit accepter qu’un identifiant produit renvoyé par votre serveur pendant la session ou déjà présent dans ce panier. Vous bloquez ainsi les identifiants inventés, ceux qui ont été copiés depuis un autre compte et les instructions dissimulées dans les contenus produit. Le même principe vaut pour l’affichage : l’agent peut sélectionner un identifiant renvoyé, mais le serveur renseigne la fiche produit depuis son propre enregistrement.

Considérez les fiches produit, avis, politiques, messages des vendeurs et souvenirs enregistrés comme des données non fiables. Le runtime d’Anthropic nettoie et isole le texte tiers avant que Claude ne le lise. Les règles inscrites dans le prompt sont utiles, mais les autorisations, plafonds de quantité, champs protégés et écritures sérialisées doivent être imposés par le code.

Si votre déploiement demande davantage de contrôle sur le runtime ou la passerelle, le guide des outils pour agents managés détaille les choix d’infrastructure autour des agents équipés d’outils.

6. Arrêter les pouvoirs de l’agent au checkout

Claude Commerce Agents fixe une limite nette : le modèle peut constituer et afficher le panier, mais il ne peut ni passer la commande ni débiter une carte. L’application hôte fournit la destination du checkout après l’appel au modèle, de sorte que l’URL n’entre jamais dans le contexte du modèle.

Choisissez un mode de transfert :

1. Ouvrir le checkout dans votre propre application.
2. Ouvrir l’URL de checkout hébergée par la plateforme e-commerce.
3. Pour une marketplace, afficher un lien de checkout par vendeur.

Cette frontière relève d’un bon design produit, pas d’une fonctionnalité oubliée. Le client peut ainsi vérifier la quantité, l’adresse, la livraison, les remises et le montant total dans le système qui gère déjà le paiement et la conformité.

Prévoyez un transfert distinct vers le support humain lorsque l’ambiguïté dépasse ce que l’agent doit gérer. Définissez les intentions qui le déclenchent, la file qui le reçoit, le résumé de conversation transmis et ce que l’opérateur humain peut approuver. « Parler à quelqu’un » est un workflow assorti de règles d’identité et de niveau de service, pas une phrase de repli.

7. Afficher l’interface e-commerce au moyen d’outils typés

Les grilles de produits, tableaux comparatifs, sélections, paniers et fiches de commande doivent passer par des outils de présentation typés. Claude appelle un composant avec des arguments structurés, le serveur les valide et les enrichit, puis le client affiche le résultat.

L’interface visible fait alors partie de l’historique de conversation. Quand le client demande « le deuxième », la liste ordonnée de produits reste présente dans les messages. Cette approche évite aussi de demander au modèle d’inventer un balisage personnalisé fragile. Pour construire l’enveloppe conversationnelle, le guide de création d’un chatbot couvre les décisions d’interface plus générales.

8. Budgéter la latence sur l’ensemble de la tâche

Mesurez le délai jusqu’à la tâche accomplie en additionnant les tours du modèle et le temps des outils. Réduire le nombre de tours, accélérer les outils et livrer les tokens plus vite comptent tout autant.

Chargez le contexte probable de la page avant le premier appel au modèle. Exécutez en parallèle les lectures indépendantes du catalogue ou des politiques. Lancez chaque outil dès que ses arguments ont fini d’arriver en streaming. Affichez progressivement les fiches produit à mesure que leurs champs sont disponibles, et présentez un simple message d’avancement pendant une recherche lente.

Selon Anthropic, une réponse e-commerce affichée représente souvent 500 à 700 tokens de sortie, soit un écran vide pendant cinq secondes ou plus en l’absence de rendu progressif. Anthropic rapporte également qu’un lancement anticipé des outils a ramené des délais observés de plusieurs secondes à quelques centaines de millisecondes. Faites ce travail d’ingénierie avant de rétrograder le modèle. Un modèle moins performant peut exiger davantage de tours et coûter plus cher par tâche accomplie.

9. Transformer les exigences produit en évaluations

Une évaluation est un cas reproductible qui vérifie le comportement de l’agent à partir d’un état connu. Préparez les messages, les enregistrements du catalogue, le panier, les informations utilisateur et les pannes qui comptent, puis notez l’état final et la réponse affichée.

Couvrez cinq catégories : demandes d’achat principales, tours dépendants du contexte, scénarios de sécurité et de marque, comportement de l’interface, et messages qui traversent deux fonctionnalités. Pour chaque cas positif, rédigez son pendant négatif. Si l’agent doit recommander une variante disponible, testez aussi la situation où toutes les variantes valides sont épuisées. Testez un texte hostile dans une fiche produit, l’identifiant de commande d’un autre utilisateur, les timeouts, les recherches vides, les ajouts répétés au panier et un prix qui change entre la recherche et le panier.

Anthropic recommande 50 à 100 cas par parcours utilisateur pour commencer. Constituez-les avec les équipes produit, juridique, service client et merchandising, puis transformez chaque incident réel en cas de non-régression permanent. Conditionnez les déploiements canary à l’exactitude des réponses étayées, au taux de réussite des tâches, au taux de conformité sécurité, aux latences p50 et p99, au taux d’accès au cache et au coût par tâche accomplie.

Sept usages e-commerce, classés selon leurs bénéficiaires

Les gains les plus importants concernent les boutiques où les clients ont de vraies contraintes et où le catalogue impose des arbitrages significatifs. Un bot de FAQ générique constitue l’usage le moins pertinent de cette architecture.

1. Conseiller pour les achats à forte implication

Pour qui : Une enseigne de matelas, d’électroménager, d’équipement outdoor ou d’électronique dont les produits demandent à être comparés.

Workflow : Le client précise son objectif, son budget, ses dimensions et ses préférences. L’agent interroge les résultats classés du catalogue, récupère le détail des meilleurs candidats, présente une comparaison structurée, confirme la variante exacte et prépare le panier.

Pourquoi c’est rentable : L’aide à la décision intervient directement pendant l’achat. C’est l’usage le plus proche des hausses de panier et de finalisation rapportées par Anthropic, car l’agent peut lever les doutes avant le départ du client.

2. Créateur de paniers par objectif

Pour qui : Une boutique qui vend des produits complémentaires, par exemple du matériel de camping, de l’équipement de bureau à domicile, des routines de soin ou les essentiels d’une première cuisine.

Workflow : L’agent décompose un objectif en plusieurs besoins produit, lance en parallèle des recherches indépendantes, vérifie le budget total, explique les compromis et ajoute au même panier les variantes approuvées.

Pourquoi c’est rentable : L’agent peut augmenter le panier en menant une mission à son terme, plutôt qu’en poussant simplement un article supplémentaire. Il évite également au client d’ouvrir plusieurs pages de catégorie et de vérifier seul les compatibilités.

3. Guide des variantes et de l’ajustement

Pour qui : Les vendeurs de mode, de cosmétiques, de mobilier et de produits configurables exposés à un risque élevé de retour.

Workflow : Le client fournit ses contraintes de coupe, de teinte, d’espace ou de compatibilité. L’agent consulte les options de la famille, vérifie le stock de la variante exacte, ne présente que les combinaisons valides et refuse d’ajouter une famille qui n’a pas été résolue en variante.

Pourquoi c’est rentable : La valeur vient de la réduction des mauvais choix, pas d’un surcroît de conversation. Une variante valide au checkout peut réduire les annulations et retours évitables tout en maintenant l’élan d’achat.

4. Découverte et suivi après-vente réunis

Pour qui : Les boutiques dont le support traite sans cesse le statut des commandes, les retours, les garanties et les questions de politique commerciale.

Workflow : La même conversation passe de la découverte produit à la consultation authentifiée d’une commande ou à une recherche dans les politiques. L’agent lit uniquement les dossiers du client, affiche le statut et transfère les exceptions à un humain avec leur contexte.

Pourquoi c’est rentable : Une seule interface peut soutenir à la fois la conversion et la résolution autonome. Le client n’a pas à répéter les informations sur le produit, la commande et la politique à un bot distinct.

5. Assistant d’achat B2B tenant compte du compte

Pour qui : Les distributeurs et entreprises par abonnement qui appliquent des tarifs contractuels, des règles d’éligibilité ou des assortiments approuvés.

Workflow : L’application hôte lie le compte et le rôle de l’acheteur à la session. Les outils backend renvoient uniquement les prix, produits autorisés et options de livraison de ce compte. L’agent prépare un devis ou un transfert vers le bon de commande au lieu de faire comme si le checkout grand public convenait.

Pourquoi c’est rentable : Il condense un processus d’achat riche en règles sans sacrifier les droits applicables au compte. Le modèle explique les choix, mais le système de comptes reste l’autorité.

6. Coordinateur de paniers pour marketplace

Pour qui : Une marketplace où plusieurs vendeurs peuvent répondre à la même demande.

Workflow : Le vendeur devient un critère de recherche. L’agent compare les offres, regroupe les lignes du panier par vendeur, puis l’application hôte affiche un lien de checkout distinct pour chacun lorsque cela s’impose.

Pourquoi c’est rentable : Une conversation de planification unique remplace un achat fragmenté, sans masquer la réalité commerciale : le paiement et la livraison relèvent de vendeurs différents.

7. Copilote de stock et de promotion pour les marchands

Pour qui : Les équipes merchandising qui doivent jongler avec les ventes, les stocks, les prix et les campagnes sur de nombreux SKU.

Workflow : L’agent marchand consulte les performances et les alertes de stock, propose un réapprovisionnement ou une promotion, prépare le changement et attend une validation dans une véritable interface opérateur avant toute application.

Pourquoi c’est rentable : Il peut raccourcir le travail d’analyse et de préparation tout en conservant les contrôles à quatre yeux déjà appliqués par l’entreprise. L’humain garde la main sur les prix, le budget et les fiches en ligne.

Trois produits qui méritent d’être développés

1. Un kit de lancement vertical pour agent shopping

Créez un package de production pour une catégorie à forte implication — équipement outdoor, mobilier ou beauté, par exemple — et vendez-le aux marchands qui ont dépassé les limites d’un widget de chat générique.

L’échelle tarifaire existe déjà. Brambles affiche des abonnements pour assistant shopping de $29 à $499 par mois pour 10,000 à 500,000 sessions. Rye facture $149 par mois pour son infrastructure de commerce agentique, puis $0.02 par fiche produit récupérée et $0.05 par commande passée. Ces montants attestent à la fois d’un budget marchand par abonnement et d’une dépense d’infrastructure à l’usage.

La plus petite version commercialisable prend en charge une plateforme e-commerce et une catégorie. Elle mappe les familles et variantes, lie les sessions invitées et authentifiées, implémente la recherche et les détails produit, constitue un panier, transmet au checkout hébergé, affiche en streaming deux ou trois composants d’interface typés, et inclut un pack d’évaluations propre à la catégorie ainsi qu’un parcours de transfert vers un humain.

La pression sur les prix constitue le principal écueil. Les plateformes et les assistants bon marché des boutiques d’applications peuvent répondre aux questions génériques sur les produits. Votre couche défendable doit réunir la logique de la catégorie, un mapping fiable du catalogue, l’attribution des conversions et des cas issus des échecs réels de ce secteur.

C’est l’opportunité la plus solide. Elle est directement liée au chiffre d’affaires du marchand, tandis que le blueprint supprime suffisamment de travail générique pour qu’une petite équipe se concentre sur les spécificités de la catégorie que les acheteurs sont prêts à payer.

2. Préparation du catalogue et contrôle qualité des variantes pour les agents

Créez un service qui vérifie si un catalogue peut répondre de manière sûre aux requêtes d’un agent avant que celui-ci ne soit exposé aux clients.

Une infrastructure conséquente existe déjà autour de ce problème. Channel3 indique que sa couche produit couvre 100 millions de produits chez 25,000 distributeurs et répond en moins d’une seconde. Rye facture $0.02 par fiche produit récupérée. Google facture AI Commerce Search $2.50 pour 1,000 requêtes. La récupération de données structurées et à jour représente donc déjà une ligne budgétaire.

Un MVP importe un flux, construit les relations entre familles et variantes, contrôle les attributs obligatoires, compare les horodatages des prix et des stocks, exécute une bibliothèque de contraintes d’achat réelles, puis signale par SKU les réponses absentes ou contradictoires. Ajoutez un test de replay pour confirmer qu’une même requête ne produit jamais une variante indisponible lors de l’ajout au panier sans parcours de récupération explicite.

Le poids des plateformes constitue l’écueil. Shopify et les autres plateformes e-commerce possèdent les flux catalogue de référence et peuvent intégrer une validation élémentaire. Le produit doit donc proposer une normalisation multiplateforme, hiérarchiser les problèmes selon les parcours d’achat perdus et prouver que les corrections réduisent les mauvaises recommandations.

3. Une validation de mise en production fondée sur des évaluations e-commerce

Construisez la couche de test qui détermine si un changement de prompt, de modèle, d’outil ou de catalogue peut être déployé sans risque.

L’évaluation des agents dispose déjà d’un budget. Langfuse indique que plus de 50,000 entreprises utilisent sa plateforme et affiche ses offres de production à $29 et $199 par mois, avec une formule Enterprise à partir de $2,499. Anthropic recommande 50 à 100 cas d’évaluation pour chaque parcours e-commerce. Le manque ne concerne pas un nouvel outil de visualisation des traces, mais une bibliothèque maintenue d’états e-commerce, de catalogues empoisonnés, d’invariants de panier et de règles de mise en production.

Le MVP importe les transcriptions, transforme les incidents en cas de test figés et fournit des évaluateurs déterministes pour la provenance des produits, la fidélité des prix, la sélection des variantes, les plafonds de quantité, les limites du checkout, les fuites d’identité, la reprise après timeout et la qualité du transfert. Il doit comparer les modèles et prompts selon la réussite des tâches, la latence p99 et le coût par tâche accomplie.

Le marché horizontal est très encombré : c’est l’écueil. La barrière défendable doit provenir de jeux de données propres au commerce, de la précision des évaluateurs, des connecteurs aux plateformes et des données de benchmark. Une simple observabilité générique sera copiée ou intégrée à une autre offre.

Ce que Claude Commerce Agents ne résout pas

Soyons clairs : ce blueprint traite mieux la structure de l’agent que l’intégration à la boutique. C’est un point de départ sérieux, pas un produit shopping hébergé.

• Il n’authentifie pas les clients et n’accorde pas de droits aux équipes. Cette responsabilité revient à l’application hôte et à la passerelle.
• Il ne corrige ni un catalogue médiocre, ni un mauvais classement, ni la latence du stock. Vos systèmes e-commerce en restent responsables.
• Il ne passe pas de commande, ne conserve pas les credentials de paiement, ne débite aucune carte et ne définit pas la politique antifraude.
• Il ne choisit ni les règles d’escalade vers un humain, ni les files de service, ni les rôles d’approbation.
• Il ne rend pas les gains de conversion rapportés par Anthropic applicables à tous les catalogues. Vous devez réaliser vos propres mesures contrôlées.
• Il ne supprime pas les décisions de confidentialité liées à la mémoire. Les préférences stockées exigent de définir les types de données acceptés, leur durée de conservation, l’accès, la correction et la suppression.

Ne construisez pas cet agent pour un minuscule catalogue où des filtres suffisent à régler chaque achat en un clic. Ne le lancez pas si les prix et les stocks sont périmés. N’accordez pas de droit d’écriture sous prétexte que le prompt paraît prudent. L’agent mérite sa place lorsque la conversation résout un achat réellement complexe et que vos systèmes peuvent fournir des faits actuels et soumis à autorisation.

L’action à lancer lundi

La semaine prochaine, choisissez un parcours générateur de revenus. Prenez 50 exemples réels issus de la recherche du site, du chat commercial et des échanges avec le support. Commencez par connecter uniquement la recherche catalogue et les détails produit ; tous les autres outils doivent répondre qu’ils sont indisponibles. Mesurez si l’agent choisit des variantes disponibles et étayées par les données, puis si les clients acceptent la recommandation. N’ajoutez le panier et le checkout qu’une fois le parcours de lecture validé par ses cas. C’est ainsi que Claude Commerce Agents passe d’une démo impressionnante à une mise en production maîtrisée.

Comment fonctionne un assistant shopping propulsé par l’IA ?

Un agent Claude conserve le fil de la conversation et appelle des outils typés pour la recherche catalogue, les détails produit, le panier, les politiques, les commandes, la mémoire et la présentation. Votre backend authentifie le client, applique les règles de prix et de stock, puis renvoie des faits structurés. Le modèle raisonne à partir de ces faits, sans devenir la source de vérité.

Comment connecter mon catalogue produit ?

Branchez le backend storefront du blueprint sur vos services existants de recherche et de produits. Faites renvoyer par la recherche des familles déjà classées, par le service de détails produit des variantes exactes et achetables, et par vos systèmes de référence les prix et disponibilités à jour. Gardez les credentials et l’identité du client côté serveur.

Comment fonctionnent les autorisations utilisateur dans Sidekick ?

Pour votre propre agent shopping ou marchand, reprenez le principe sous-jacent, pas l’implémentation du produit Sidekick. Identifiez l’utilisateur et son rôle avant le tour de l’agent, n’exposez que les outils autorisés, conservez les credentials côté serveur, vérifiez encore l’autorisation dans chaque méthode backend et exigez une véritable approbation de l’application hôte pour les écritures marchandes sensibles.

Puis-je le développer moi-même avec Claude ou un outil similaire ?

Oui. Le dépôt open source contient des exemples exécutables et un plugin Claude Code capable de générer une première structure à partir de votre backend. Le travail restant pour une réalisation en interne demeure conséquent : authentification, mapping du catalogue, stock en temps réel, intégration du panier et du checkout, autorisations, transfert vers un humain, monitoring et évaluations.

Si vous souhaitez adapter l’un de ces produits à votre catalogue et à vos règles opérationnelles, découvrez le développement d’agents IA.