J’étais à dotdev les 21 et 22 juillet, à Toronto, pour les deux journées où Shopify réunit les développeurs autour de sa feuille de route. Une chose est revenue dans plusieurs sessions : le point d’entrée de votre boutique n’est plus seulement un humain qui tape une requête dans Google. C’est de plus en plus un agent d’IA qui interroge un catalogue structuré, compare, et revient avec des suggestions de produits. Les chiffres de Shopify pour le premier trimestre 2026 vont dans ce sens : les commandes référées par l’IA ont été multipliées par près de 13 en un an, et les visiteurs venus de l’IA convertissent environ 50 % mieux que ceux de la recherche organique.

En rentrant, j’ai voulu savoir ce que ça donnait concrètement. J’ai construit un catalogue dans le Dev Dashboard de Shopify et je l’ai interrogé comme le ferait un agent, sur plusieurs boutiques, pour comprendre pourquoi certains produits ressortent et d’autres jamais. C’est l’exercice le plus révélateur que j’aie fait cette année sur la qualité des données produits, et il prend une trentaine de minutes.

Deux choses différentes s’appellent « catalog »

C’est la confusion à dissiper en premier, parce qu’elle change complètement ce que vous avez à faire.

Shopify Catalog est le dépôt centralisé où Shopify agrège les produits admissibles de ses marchands, dans un format structuré, pour que les plateformes d’IA puissent les découvrir. Côté marchand, c’est automatique : aucune action requise, et surtout, aucune façon de s’en retirer complètement. Vous pouvez bloquer certaines vitrines agentiques individuellement, mais vos produits admissibles sont dans le catalogue, que vous le sachiez ou non.

L’API Catalog est l’autre bout du tuyau : l’interface que les agents interrogent. Shopify en expose deux variantes : le Global Catalog, qui cherche à travers tous les marchands, et le Storefront Catalog, limité à une seule boutique. Les deux implémentent la capacité Catalog du Universal Commerce Protocol, ce protocole que Google et Shopify co-développent et que j’ai décortiqué dans mon article sur le UCP et le SEO e-commerce.

La conséquence est simple : vous ne choisissez pas d’entrer dans le catalogue, vous choisissez seulement d’y entrer bien ou mal. Et l’API vous donne le moyen de vérifier laquelle des deux situations est la vôtre.

Ce que Shopify exige avant même de vous indexer

Avant de tester quoi que ce soit, vaut mieux savoir si vos produits sont seulement admissibles. Les critères sont publics et précis, et ils se répartissent en trois blocs.

Côté boutique : être au minimum sur le forfait Starter, ne pas être protégée par mot de passe, et respecter les conditions d’utilisation de Shopify.

Côté produit : un titre, au moins une image, un prix supérieur à 0 $, une publication sur la boutique en ligne (ou sur Hydrogen ou Headless, avec un formatage de route correct), et une URL de produit identifiable. Les produits en statut non répertorié ou masqués aux moteurs de recherche sont exclus, tout comme les contenus sensibles.

Côté compte, et c’est la partie que les marchands oublient : courriel vérifié, authentification à deux facteurs activée, historique de ventes réel par les canaux normaux, commandes honorées rapidement, taux de rétrofacturation bas, factures Shopify payées à temps. L’admissibilité au catalogue est donc aussi une question d’hygiène opérationnelle, pas seulement de fiches produits.

Construire un catalogue dans le Dev Dashboard

Voici l’exercice comme je l’ai fait. Dans le Dev Dashboard, la section Catalogs permet de créer un catalogue sauvegardé, qui est une fonctionnalité du Global Catalog. L’idée : préconfigurer des filtres persistants plutôt que de les répéter à chaque requête.

Par défaut, un catalogue neuf ne borne rien et cherche dans tous les produits de Shopify. C’est en le resserrant que ça devient intéressant. L’interface regroupe les filtres en cinq blocs :

• Source : tout Shopify, ou des boutiques précises
• Query : un préfixe de recherche et une limite de résultats
• Region : pays de l’acheteur, destination d’expédition et origine d’expédition, trois champs distincts
• Attributes : catégorie, couleur, genre, taille, état du produit
• Listing : en stock seulement, fourchette de prix, palier de prix, note minimale et nombre minimal d’avis

Ces deux derniers filtres méritent qu’on s’y arrête, j’y reviens plus bas.

Bonne nouvelle pour les non-développeurs : pas besoin d’écrire une ligne de code pour tester. Le Dev Dashboard intègre un aperçu de recherche à droite de la configuration, avec la requête, la réponse en version visuelle ou en JSON brut. Vous tapez ce qu’un client demanderait et vous voyez ce que l’agent verrait. Le reste de l’exercice tient dans cette fenêtre.

Et c’est là que ça devient un diagnostic. Si vous vendez des produits alimentaires, interrogez le catalogue avec la requête qu’un client formulerait, et regardez si vous ressortez. Si vous ne ressortez pas, ce n’est pas l’agent qui a un problème : c’est que vos données ne permettent pas de vous trouver. Vous venez de découvrir un angle mort que ni Google Analytics ni votre rapport de ventes ne vous montrera jamais.

Le même exercice appliqué à vos concurrents vous dit lesquels ont pris de l’avance en commerce agentique. C’est l’étude de marché la plus honnête qui soit : personne ne peut vous raconter n’importe quoi, la requête tranche.

Vos avis clients viennent de changer de fonction

C’est la découverte qui m’a le plus surpris, et elle n’apparaît nulle part dans la documentation.

Chaque résultat retourné par le catalogue affiche le nom du marchand, une note sur cinq et un nombre d’avis entre crochets, à côté du prix. Et le bloc Listing de la configuration permet de filtrer sur une note minimale et un nombre minimal d’avis.

Lisez ça deux fois, parce que la conséquence est brutale : celui qui configure l’agent peut vous exclure de la sélection avant même que la pertinence de votre produit entre en jeu. Vos avis ne sont plus seulement de la preuve sociale destinée à rassurer un humain hésitant sur votre fiche produit. Ils sont devenus un critère d’admissibilité lisible par une machine, appliqué en amont, sans que personne ne voie jamais votre boutique.

Sur ma requête « snowboard », un produit noté 5,0 avec un seul avis se classait deuxième, devant un produit noté 4,8 cumulant 617 avis. Une seule requête ne fait pas une règle, et je me garde d’en tirer une théorie du classement. Mais ça suffit à établir que la mécanique n’est pas celle du SEO classique, où le volume finit toujours par peser.

Ce que j’ai observé : vos metafields publics décident de votre visibilité

À force de comparer des boutiques qui ressortaient et des boutiques qui restaient invisibles sur des requêtes équivalentes, un facteur est revenu plus souvent que les autres : les metafields, et surtout leur niveau d’accès.

Le piège est vicieux, parce qu’il est invisible depuis l’admin. Un metafield Shopify est privé par défaut. Dans la définition, le réglage access.storefront vaut none tant que personne ne le change, ce que la documentation traduit par « masqué de l’API Storefront ». Il faut explicitement le passer à public_read pour qu’une source externe puisse le lire.

Résultat : une équipe peut passer des semaines à documenter proprement la composition, les certifications, les dimensions, la compatibilité de chaque produit, et tout ce travail reste enfermé. Le marchand le voit dans son admin. Il le voit peut-être même affiché sur sa fiche produit, puisque le réglage Storefront n’affecte pas Liquid. Mais un agent qui interroge le catalogue, lui, ne voit rien. La donnée existe, elle est juste inaccessible à celui qui recommande.

Le reste de la chaîne, en revanche, est documenté. Shopify Catalog Mapping permet de désigner des metafields ou des références de métaobjets comme sources du titre, de la description et de la catégorie de produit, avec un menu Grouping metafield dédié au regroupement des variantes. Shopify précise que cette fonction est « surtout utile si votre boutique utilise des données personnalisées et une logique de regroupement, comme des metafields, des métaobjets, des préfixes d’étiquettes ou des séparateurs dans les titres de produits ». Et du côté des réponses, le Storefront Catalog retourne un objet metadata qui transporte précisément ce type de données, comme certifications: ["USDA Organic", "Fair Trade Certified"].

Le corollaire vaut d’être dit clairement : tout ce que vous encodez dans la présentation plutôt que dans la donnée est perdu. Shopify est explicite là-dessus, une information qui vit « dans des gabarits Liquid, de la logique de rendu JavaScript ou des règles d’affichage personnalisées » est invisible pour l’IA. Des pastilles de couleur générées en JavaScript, des regroupements gérés dans le thème, des options modélisées en étiquettes : pour un humain ça fonctionne, pour un agent ça n’existe pas.

Une réserve honnête pour finir : aucune page de Shopify n’écrit noir sur blanc « vos metafields doivent être en public_read pour alimenter Shopify Catalog ». Ce que la documentation établit, c’est que les metafields sont privés par défaut, qu’ils peuvent servir de sources au mapping, et que les réponses du catalogue transportent bien ces données personnalisées. Le lien entre les trois vient de mes tests, pas d’une page officielle. Vérifiez sur votre propre boutique avant d’en faire une politique interne, ça prend dix minutes avec l’aperçu de recherche.

Les limites à garder en tête

L’exercice est révélateur, mais il ne faut pas surinterpréter les résultats.

Être dans le catalogue ne garantit ni le classement, ni le placement, ni l’affichage sur les canaux. Shopify le dit explicitement. Certains champs retournés sont générés par IA et marqués comme inférés, avec une exactitude variable selon les données disponibles : ne bâtissez pas une conclusion sur un champ inféré. Des limites de débit s’appliquent, et l’accès sans clé ne permet pas de les augmenter. La mise en cache des résultats et des images est interdite, parce que les réponses doivent refléter les préférences en direct du marchand. Enfin, Shopify précise que les URL de l’API sont susceptibles de changer, ce qui est le signal habituel d’une surface encore jeune.

Autrement dit : traitez ça comme un instrument de mesure, pas comme un tableau de bord de production.

Par où commencer cette semaine

Cinq choses, dans l’ordre, et aucune ne demande de développement.

1. Vérifiez votre admissibilité. Parcourez la liste des critères. La 2FA et l’historique de ventes bloquent plus de boutiques qu’on pense.
2. Créez un catalogue et interrogez-le dans l’aperçu de recherche, avec les cinq requêtes que vos clients formulent le plus souvent. Notez lesquelles vous font ressortir et lesquelles vous laissent de côté.
3. Refaites le test sur trois concurrents. L’écart vous donne votre plan de travail, priorisé par ce qui manque réellement.
4. Auditez l’accès de vos metafields. Listez ceux qui portent une information d’achat réelle, composition, certifications, dimensions, compatibilité, et vérifiez lesquels sont encore à none. C’est le correctif le moins coûteux et le plus souvent négligé.
5. Regardez vos avis avec des yeux neufs. Note et nombre d’avis sont maintenant des filtres. Si votre programme d’avis clients dormait au fond de la liste des priorités, il vient de remonter.

Si vous voulez le contexte plus large avant de vous lancer, mon guide du commerce agentique pour marchands Shopify explique pourquoi cette bascule arrive maintenant et ce qu’elle change dans le parcours d’achat.

Et ensuite

Le travail qui suit le diagnostic est rarement spectaculaire : structurer une taxonomie, compléter des attributs, revoir la logique de regroupement des variantes, corriger des descriptions écrites pour un humain pressé plutôt que pour un agent qui compare. Ce n’est pas glamour, mais c’est exactement ce qui décide si un agent vous recommande ou recommande votre concurrent.

Chez Junifia, c’est le genre de mandat qu’on prend en charge : un audit de l’architecture de votre plateforme e-commerce qui part de vos données produits et remonte jusqu’à ce que les agents en font.

Si vous voulez qu’on regarde ensemble ce que le catalogue dit de votre boutique, écrivez-nous.