Un acheteur qui arrive sur une fiche produit comble lui-même les manques : il lit la photo, déduit le matériau de la marque, suppose que le délai de livraison s’applique à son code postal, et pose une question en cas de doute.
Un agent qui achète à la place de ce client ne fait rien de tout cela. Il lit uniquement ce qui est publié sous forme structurée, et tout ce qui manque est, pour lui, inexistant. Si l’attribut matériau n’est renseigné que sur 40 % des SKU, vous êtes invisible pour 60 % des requêtes filtrées par matériau. Si les délais de livraison sont rédigés en prose, ils ne sont pas comparables.
Pour les utilisateurs de MedusaJS, la situation est favorable : vous contrôlez directement le modèle de données et la surface de l’API, sans dépendre des choix d’une plateforme. Voici comment en tirer parti.
Cible Medusa 2.x. Le paysage des protocoles — ACP, UCP, MCP — reste en consolidation : considérez les intégrations comme l’état du moment, et le travail de structuration des données ci-dessous comme pérenne, quel que soit le standard qui s’imposera.
Les attributs sont désormais le produit
Dans un catalogue Medusa, la tentation est de laisser la vitrine porter un sens que les données n’ont pas — une fiche technique bien présentée, mais assemblée à partir d’un bloc descriptif. Cela fonctionne pour l’humain, mais échoue pour la machine.
La discipline :
- Modéliser les attributs comme des données typées et structurées, et non comme du texte libre dans une description. Tout ce qu’un client pourrait filtrer, comparer ou interroger doit disposer de son propre champ.
- Utiliser un vocabulaire contrôlé. Trois mille valeurs couleur saisies en texte libre ne forment aucun groupe. Vingt-quatre options définies permettent un filtre exploitable et un attribut comparable.
- Renseignez les identifiants. GTIN, MPN et la marque permettent d’associer votre produit à un même article ailleurs. Si ces identifiants manquent, un agent ne peut pas confirmer qu’il analyse bien le produit attendu.
- Indiquez explicitement les unités.
2,5n’est pas une longueur.2,5 men est une. - Soyez précis sur les variantes. Si la taille et la couleur sont réellement indépendantes, modélisez-les séparément plutôt que comme une liste plate d’options pré-combinées.
La plupart de ces tâches relèvent du même travail de catalogue qui améliore la recherche interne et la navigation à facettes — c’est rassurant, car cela reste utile même si le trafic agent ne se matérialise jamais dans votre secteur. Nous décrivons le processus d’enrichissement dans nettoyer un grand catalogue avec l’IA ; la plateforme de l’exemple change, la méthode reste la même.
La disponibilité doit être réelle, pas optimiste
C’est ici que les canaux agents sanctionnent les boutiques que les humains pardonnent. Un client qui commande un article affiché en stock et reçoit un mail de retard sera simplement agacé. Un agent qui a engagé une transaction sur cette base a pris un engagement au nom du client, en se fondant sur une information que vous avez publiée comme étant exacte.
- Exposez le stock réel, par site si vous livrez depuis plusieurs emplacements — le module d’inventaire de Medusa le gère correctement, utilisez-le plutôt que de tout ramener à un seul chiffre.
- Publiez un délai de livraison que vous assumez, calculé selon l’emplacement et l’état du stock, et non une promesse statique dans un bloc CMS.
- Distinguez rupture de stock et arrêt de commercialisation. Cela implique des comportements d’agent totalement différents.
- Maintenez une fraîcheur maximale. Une disponibilité en cache dépassée d’une heure est une mauvaise réponse donnée avec assurance.
Décidez de votre politique de survente avant d’ouvrir un canal agent, pas après. Une tolérance acceptable avec des humains devient un problème d’exactitude systématique lorsqu’une machine vous cite.
Les politiques doivent être des données, non des PDF
Les délais de retour, conditions de garantie, seuils et restrictions d’expédition sont souvent une page rédigée par le service juridique. Un agent qui demande mon client peut-il retourner cet article attend une réponse structurée.
A minima, rendez lisibles par machine : le délai de retour en jours, qui prend en charge les frais de retour, les catégories exclues, la durée de garantie, le seuil de livraison gratuite et les destinations non desservies. Publiez-les comme champs structurés dans votre API, et — séparément — en balisage schema.org sur la boutique, pour garantir la cohérence entre les deux canaux.
La raison commerciale est simple : un agent qui compare deux produits, dont l’un affiche une politique de retour de 30 jours et l’autre rien, privilégiera celui qu’il peut interpréter.
La surface d’API nécessaire à un agent
L’API Store de Medusa est structurée par ressource, ce qui convient à une boutique mais pas à un agent. Un agent attend des opérations orientées tâches : trouve-moi des produits correspondant à cette description, dis-moi si cet article est disponible dans cette taille à ce code postal, quelle est la politique de retour pour cet article.
Construisez une couche légère au-dessus de vos modules Medusa pour exposer ces opérations, et considérez-la comme un produit à part entière avec ses propres standards de conception. Nous détaillons la conception — y compris ce qui ne doit jamais être exposé — dans votre produit a besoin d’un serveur MCP.
Deux points spécifiques à Medusa. D’abord, le système de modules rend cela agréable : la couche agent consomme vos modules produit, inventaire et tarification, sans les dupliquer. Ensuite, séparez-la de l’API de la boutique — les usages, limites de débit et modèles d’autorisations diffèrent, et les fusionner dégrade les deux.
Être trouvé ou être choisi : deux enjeux distincts
Ce sont deux projets distincts que les équipes confondent souvent.
- Être trouvé — un assistant recommande votre produit dans une réponse. Cela dépend de données structurées et explorables sur la boutique : balisage schema.org, fiches produits propres, contenu réel et une politique d’exploration adaptée aux bons agents. C’est principalement lié au SEO.
- Être acheté — un agent réalise un achat sur vos systèmes. Cela dépend de la conception de l’API, de l’authentification, de la gestion du paiement et des protocoles émergents.
Le premier est accessible à toutes les boutiques aujourd’hui et offre un retour sur investissement plus clair à court terme ; nous le traitons dans faire recommander vos produits par ChatGPT et Perplexity. Le second dépend encore de standards en évolution. Faites le premier dès maintenant, quoi qu’il arrive.
Un ordre de travail pertinent
- Auditez la complétude des attributs sur le catalogue et classez-les selon leur utilité pour la recherche, le filtrage ou la comparaison.
- Corrigez les vocabulaires contrôlés avant d’enrichir quoi que ce soit — sinon vous ajoutez des lignes à une taxonomie incohérente.
- Comblez les lacunes, en échantillonnant le résultat plutôt qu’en lui faisant confiance aveuglément.
- Structurez les politiques et publiez-les à la fois comme champs API et en balisage sur la boutique.
- Vérifiez l’exactitude de la disponibilité par rapport à la réalité pendant un mois. Si c’est erroné pour les humains, ce le sera plus vite et plus publiquement pour les machines.
- Puis construisez la couche API pour les agents, et ne vous préoccupez du protocole qu’ensuite.
Les étapes une à cinq valent la peine, que le commerce agent devienne ou non significatif dans votre secteur — c’est ce qui en fait un investissement sûr dans un domaine encore incertain.
Notre équipe MedusaJS et notre équipe de développement Medusa construisent ces catalogues et les interfaces associées, avec notre équipe d’ingénierie IA côté modèle et nos prestations d’intégration IA pour l’articulation avec votre stratégie commerciale.
Questions fréquentes
Les agents d’achat basés sur l’IA génèrent-ils déjà des ventes significatives ?
Cela varie fortement selon le secteur, et la réponse honnête pour la plupart des boutiques aujourd’hui est pas encore, mais nettement plus qu’il y a un an. L’intérêt d’agir maintenant est que les prérequis — complétude des attributs, disponibilité fiable, politiques structurées — améliorent la recherche, le filtrage et la visibilité organique, quelle que soit l’évolution du canal agent.
Qu’apporte MedusaJS ici qu’une plateforme SaaS ne propose pas ?
Contrôle direct du modèle de données et de la surface de l’API. Vous pouvez ajouter des attributs typés sans vous heurter à une abstraction de métachamp, exposer des opérations adaptées à vos modules, et séparer l’interface destinée aux agents de celle de la vitrine. Sur une plateforme gérée, vous êtes limité à ce que l’éditeur a choisi d’exposer.
Faut-il bloquer les crawlers IA ?
Distinguez les crawlers qui vous citent de ceux qui aspirent sans attribution. Bloquer sans distinction vous exclut totalement des réponses IA, ce qui n’est pas le bon compromis pour la plupart des commerçants. Décidez au cas par cas, documentez la décision et réévaluez-la : il s’agit d’une politique, pas d’un réglage par défaut.
Est-il pertinent de mettre en place des protocoles de paiement agentiques dès maintenant ?
Les protocoles sont encore en cours de consolidation, donc tout développement spécifique comporte un risque de reprise. Le travail sur les données et l’API sous-jacentes n’en comporte pas et prend plus de temps. Commencez par là ; intégrer un protocole sur une base propre est ensuite rapide.
À quel point les données d’inventaire doivent-elles être précises ?
Plus précises que dans la plupart des boutiques aujourd’hui. Un client humain reçoit un e-mail de retard avec agacement ; un agent qui a validé une commande sur une disponibilité affichée a pris un engagement au nom du client, en se basant sur vos données comme sur un fait. Définissez explicitement votre tolérance au surbooking avant d’ouvrir ce canal.
Commencez par l’audit des attributs
Envoyez-nous les taux de remplissage des attributs de votre catalogue Medusa et nous vous dirons ce qu’un agent peut ou non voir actuellement. C’est généralement moins que ce que les équipes imaginent. Contactez notre équipe ; nous répondons sous un jour ouvré.