Avis clients : 1 boutique équipée sur 4 muette pour l'IA

Le problème en 60 mots

Le 22 juillet 2026, Google a lancé les Aperçus IA en France. Depuis, tout le monde optimise pour Google. Or Google est précisément le moteur qui voit déjà vos avis clients, parce qu’il exécute le JavaScript de vos widgets. Les autres ne l’exécutent pas. Nous avons mesuré 457 fiches produit Shopify françaises : parmi les boutiques équipées d’une application d’avis, une sur quatre n’expose aucune note sans JavaScript.

Ce que nous avons mesuré

Le 13 août 2026, lecture d’une fiche produit sur 480 boutiques Shopify françaises (clientes d’agences référencées dans le répertoire partenaires Shopify), en HTTP simple, sans exécution de JavaScript. C’est ce que voit un robot qui ne rend pas les pages.

Méthode : une fiche produit par boutique, résolue via /products.json puis le sitemap produits à défaut. Requêtes en HTTP simple avec le user-agent VerityScoreBot/1.0, sans exécution de JavaScript. Recherche de la note et du nombre d’avis sous quatre formes : JSON-LD aggregateRating, microdonnées itemprop, attributs de widget (data-number-of-reviews, data-average-rating), et texte visible du type « 128 avis » ou « 4,6 / 5 ». Détection des applications d’avis par leurs marqueurs propres : domaine de CDN et conteneur de widget dans le DOM servi.

Limites, et elles comptent. Échantillon français de boutiques accompagnées par une agence, donc probablement mieux entretenues que la moyenne.

Une seule fiche par boutique, souvent un produit récent qui peut légitimement n’avoir aucun avis : dans ce cas l’absence de note est correcte, pas une erreur. C’est pourquoi la ligne qui compte n’est pas « 24,5 % n’ont pas d’avis » mais « 24,5 % chargent une application d’avis sans qu’aucune note n’apparaisse dans le HTML ».

23 boutiques sur 480 sont sorties de l’analyse faute de fiche produit résolue : /products.json désactivé, sitemap produits absent, ou réponse non-200. Ce sont typiquement des boutiques qui filtrent les robots ou servent un front découplé, donc plutôt moins lisibles que la moyenne. Leur exclusion rend nos taux optimistes, pas l’inverse.

Enfin, nous avons interrogé chaque boutique avec un user-agent identifiable, pas en usurpant celui d’un robot IA. Une boutique qui sert un HTML différent selon le user-agent apparaîtrait donc ici sous son visage « robot inconnu ». Nous republierons cette mesure sur le même corpus en février 2027.

Un exemple mesuré rend le mécanisme concret. Une boutique de parfums de l’échantillon sert dans son HTML data-number-of-reviews="13960" et une note de 4,65, mais ne publie aucun aggregateRating dans son JSON-LD. Près de 14 000 avis existent, sont comptés côté serveur, et ne sont pas déclarés dans le format que les moteurs attendent.

Pourquoi Google n’est pas le sujet

C’est le contre-pied de la période. L’arrivée des Aperçus IA en France a mis Google au centre de toutes les discussions, alors que Google est le moteur qui a le moins besoin de votre aide sur ce point précis.

Google documente un traitement en trois temps : exploration, rendu, indexation. Le rendu passe par « un Chromium sans interface qui exécute le JavaScript » (Google Search Central). Votre widget d’avis s’exécute, la note apparaît, Google la voit. Google nuance tout de même : la page peut attendre dans la file de rendu « quelques secondes, mais cela peut prendre plus longtemps », et la documentation recommande le rendu côté serveur en rappelant que tous les robots n’exécutent pas le JavaScript.

Les robots des moteurs IA sont exactement ces robots-là. L’analyse conjointe de Vercel et MERJ ne trouve aucune trace d’exécution de JavaScript chez GPTBot, ClaudeBot, PerplexityBot, Bytespider ou meta-externalagent. Ces robots téléchargent parfois les fichiers JavaScript, entre 11 % et 24 % des requêtes selon le robot, mais ne les exécutent pas. Ils lisent le HTML tel qu’il sort de votre serveur. Le constat converge avec des mesures indépendantes plus récentes (SearchOptimo, juin 2026), et Anthropic recommande explicitement de ne pas compter sur le JavaScript pour que son robot lise une page.

D’où la situation asymétrique que personne ne regarde :

Trois précisions honnêtes sur ce tableau, parce qu’il porte toute la thèse.

La mesure Vercel/MERJ couvre GPTBot, ClaudeBot, PerplexityBot, Bytespider et meta-externalagent. Elle ne couvre pas OAI-SearchBot, ChatGPT-User, Claude-SearchBot ni Claude-User, dont certains n’existaient pas à la date de l’étude. Nous les rangeons dans la même colonne par cohérence d’infrastructure, pas sur preuve directe.

Côté Google, « Oui » mérite un astérisque : le rendu passe par une file d’attente. Sur un produit dont la note bouge, Google peut lire une valeur périmée plutôt que l’absence de valeur.

Enfin, la documentation d’OpenAI décrit ses robots et leurs rôles mais ne dit rien du JavaScript. Anthropic, lui, recommande explicitement de ne pas compter dessus. L’absence d’exécution est donc établie par la mesure côté OpenAI, et par la documentation côté Anthropic.

Ce que Google dit vraiment des Aperçus IA

Il faut être précis ici, parce que le marché raconte l’inverse. Google écrit noir sur blanc qu’il n’y a aucune donnée structurée particulière à ajouter pour apparaître dans les Aperçus IA ou le Mode IA : « Vous n’avez pas besoin de créer de nouveaux fichiers lisibles par machine, de fichiers texte IA ou de balisage pour apparaître dans ces fonctionnalités » (Google Search Central).

Donc non, publier un AggregateRating ne vous fera pas entrer dans un Aperçu IA. Vendre cela serait faux.

Ce que le balisage fait réellement, et qui suffit largement à justifier le travail :

1. Il conditionne l’extrait d’avis dans les résultats Google. Pour afficher des étoiles, Google demande de « baliser une évaluation agrégée avec schema.org/AggregateRating », avec au moins ratingCount ou reviewCount, et exige que le contenu d’avis soit visible pour l’utilisateur sur la page (Google Search Central).
2. Il rend la note lisible par les moteurs qui n’exécutent pas le JavaScript. C’est l’objet de cet article.

Deux bénéfices concrets, aucun des deux n’étant « apparaître dans les Aperçus IA ». La distinction est ce qui sépare un conseil vérifiable d’un argument de vente.

Les cinq niveaux de lisibilité

Derrière un affichage identique à l’écran (des étoiles sous le titre du produit), notre mesure fait apparaître cinq situations. Les effectifs sont exclusifs et somment aux 249 boutiques équipées.

Niveau 1, le standard (10,8 %). La note est rattachée au Product, en JSON-LD ou en microdonnées. Google accepte les deux, ainsi que RDFa : il précise que les trois formats « conviennent également », JSON-LD étant seulement le plus simple à maintenir (Google Search Central). C’est la forme la plus sûre pour tout moteur qui parse la page.

Niveau 2, la note orpheline (4,0 %). Un aggregateRating existe, mais sur une autre entité que le produit, typiquement l’Organization. Ces boutiques croient être au niveau 1. Elles n’y sont pas : une note d’entreprise n’est pas éligible aux étoiles d’une fiche produit.

Niveau 3, l’attribut propriétaire (52,2 %). La note vit dans un attribut du conteneur de widget, typiquement data-number-of-reviews="128" chez Judge.me. Le HTML la contient, donc un robot qui ne rend pas le JavaScript peut la lire s’il sait où regarder. Mais rien n’est normalisé, et Google ne s’en sert pas pour les extraits d’avis. C’est le cas le plus fréquent, et c’est un demi-signal.

Niveau 4, le texte seul (8,4 %). Ni balisage ni attribut, mais « 128 avis » et « 4,6 / 5 » sont écrits dans le HTML rendu côté serveur. C’est moins bien qu’un balisage pour Google, et paradoxalement plutôt bon pour un moteur conversationnel, qui lit le texte.

Niveau 5, le silence (24,5 %). Le HTML servi contient un conteneur de widget vide. Ni note, ni compteur, ni texte. Le JavaScript remplit tout au chargement. Pour Google, aucun problème. Pour ChatGPT et Claude, cette boutique n’a pas d’avis du tout.

Une réserve importante sur le niveau 1

Le JSON-LD est la meilleure garantie pour les moteurs qui indexent, pas une garantie universelle. En navigation directe, ChatGPT et Claude lisent souvent le texte visible plutôt que le balisage : notre propre mesure d’extraction par moteur donne 0 % pour Claude et 37,5 % pour ChatGPT quand le prix n’existe qu’en JSON-LD (voir le détail).

La règle sûre n’est donc pas « du JSON-LD » mais les deux à la fois : la note écrite en clair dans le HTML rendu côté serveur, et un AggregateRating rattaché au Product. Le niveau 1 sans texte visible reste un pari.

Le silence se concentre sur trois applications

C’est le résultat le plus contre-intuitif de la mesure. Les boutiques totalement muettes ne sont pas réparties au hasard : elles dépendent de l’application installée.

Judge.me n’est jamais muet. Sur 154 boutiques, aucune n’est au niveau 5 : l’application écrit systématiquement son compteur dans un attribut du HTML servi. C’est un demi-signal, pas le standard, mais un robot qui lit le HTML brut trouve toujours quelque chose. Yotpo, Trustpilot et Loox laissent au contraire entre 42 % et 58 % de leurs boutiques totalement silencieuses.

Deux réserves. Les éditeurs sous 20 observations sont regroupés : à ces effectifs, un « 0 % » se lit comme du bruit, pas comme un classement. Et Trustpilot est un cas à part : c’est une plateforme d’avis d’entreprise, pas une application d’avis produit. Une note Trustpilot correctement implémentée porte sur l’Organization, et n’est donc pas censée produire un AggregateRating de fiche produit. Sa ligne mesure une réalité, pas une faute.

La vérification, en trois minutes

Étape 1. Ouvrez le code source, pas l’inspecteur. C’est le seul piège sérieux de cette procédure. Ctrl+U (Cmd+Option+U sur Mac) affiche le HTML tel que le serveur l’a envoyé. L’inspecteur d’éléments, lui, montre le DOM après exécution du JavaScript : vos avis y apparaissent toujours, et vous concluez à tort que tout va bien.

Étape 2. Cherchez aggregateRating. Avec Ctrl+F dans le code source. Présent avec un ratingValue, et rattaché à un bloc Product : vous êtes au niveau 1, rien à faire. Présent mais rattaché à Organization : vous êtes au niveau 2, la note ne compte pas pour la fiche. Absent : passez à l’étape 3.

Étape 3. Cherchez votre nombre d’avis en clair. Si la page affiche « 128 avis », cherchez 128. Trouvé dans un attribut du type data-number-of-reviews : niveau 3. Trouvé seulement dans le texte : niveau 4. Introuvable alors que la page l’affiche : niveau 5, et c’est le cas à corriger en priorité.

Pour la correction, l’ordre compte, et le raccourci évident ne fonctionne pas :

1. N’attendez pas tout de l’option « rich snippets » de votre application. C’est le réflexe naturel et il est souvent inopérant : chez Judge.me, Loox et Yotpo, le balisage produit par cette option est lui-même injecté en JavaScript, donc invisible pour les moteurs dont il est question ici. Seul Okendo documente publiquement une injection côté serveur, et Stamped la propose en collage manuel dans le thème. Activez l’option, puis vérifiez au code source : si aggregateRating n’apparaît pas, l’option n’a rien changé pour vous.
2. Le correctif fiable passe par le thème. Si votre thème publie déjà un JSON-LD Product (c’est le cas de la plupart des thèmes Shopify récents), ajoutez-y le champ aggregateRating alimenté par les métachamps de votre application d’avis. C’est la seule voie qui garantit un rendu côté serveur.
3. Servez aussi la note en texte. Le balisage sert Google ; le texte rendu côté serveur sert les moteurs conversationnels. Les deux ensemble couvrent tous les cas.
4. Ne balisez jamais une note que la page n’affiche pas. Google exige que le contenu d’avis soit visible pour l’utilisateur. Un AggregateRating sans avis affichés est une infraction aux règles, pas une optimisation.

Sur les blocs multiples : plusieurs blocs Product sur une même page ne sont pas un problème en soi, Google les réconcilie par @id. Ce qui pose problème, ce sont deux blocs qui déclarent des valeurs différentes. La procédure complète de correction, app par app, est détaillée dans notre fiche AggregateRating.

Vérifiez ensuite avec le test des résultats enrichis de Google, puis rechargez votre fiche avec JavaScript désactivé dans le navigateur. Ce que vous lisez alors est une bonne approximation de ce que reçoit un robot qui ne rend pas les pages. La réserve : certains serveurs varient leur réponse selon le user-agent, donc le rendu exact vu par GPTBot peut différer. Pour lever le doute, rejouez la requête avec son user-agent :

curl -A "GPTBot" -sL "https://votre-boutique.com/products/votre-produit" | grep -c aggregateRating

Ce que la mesure dit du reste de la fiche

Les avis sont le trou le plus large, mais la même lecture donne l’état des autres signaux. Sur les 457 fiches, en HTML brut :

Deux points méritent attention. Le prix manque dans 32,6 % des cas, mais la cause diffère de celle des avis : 60 fiches n’ont aucun JSON-LD Product, et 89 en ont un sans prix. Le prix reste presque toujours lisible dans le texte de la page, puisque les thèmes Shopify le rendent côté serveur. C’est une perte de précision, pas une disparition. Et 4,4 % des fiches contiennent au moins un bloc JSON-LD que le parseur rejette : un bloc invalide vaut un bloc absent.

Livraison et retours structurés, à moins de 5 %, restent l’angle mort du marché français. Ce sont pourtant deux critères de décision d’achat que les moteurs conversationnels citent volontiers quand ils les trouvent.

Ce qu’il faut retenir

Le 22 juillet a déplacé l’attention vers Google. C’est logique et ce n’est pas là que se joue votre lisibilité machine, parce que Google exécute déjà le JavaScript de vos widgets. Le décalage est ailleurs : pour un quart des boutiques équipées d’une application d’avis, les moteurs qui lisent le HTML brut ne voient aucune note. Ces moteurs sont ceux où se déroulent aujourd’hui les conversations d’achat assisté.

La correction ne demande ni refonte ni budget, mais elle demande de viser le bon endroit : un champ ajouté au JSON-LD du thème, plutôt qu’un réglage d’application qui produit lui aussi du JavaScript. Ce qui manque, en général, c’est simplement d’avoir regardé le bon HTML.

Une dernière mise en garde sur la lecture de ces chiffres. Ils décrivent une population, pas un produit. À l’échelle d’une boutique, le résultat dépend du mode d’intégration retenu, pas du nom de l’application : nos trois tests boutique par boutique du 23 juillet donnaient trois résultats différents pour des applications identiques.

Kamil Kaderbay, fondateur de Verity Score. Mesure réalisée le 13 août 2026, méthode et limites détaillées plus haut. Prochaine mesure sur le même corpus : février 2027.

Articles connexes

• AggregateRating : la note que les moteurs IA lisent vraiment
• Le mythe schema.org = citations ChatGPT
• Améliorer la visibilité IA de son site Shopify
• Robots IA bloqués : la procédure de vérification

Vous voulez savoir ce que les moteurs lisent de vos fiches ? L’app Shopify Verity Score lit vos pages produit sans exécuter le JavaScript, comme les robots de ChatGPT et de Claude, et liste les signaux manquants. Installer Verity Score depuis le Shopify App Store →