La question n’est pas « quel module ». Elle est : où vit le texte des avis. Dans le HTML que le serveur envoie, dans le DOM après l’exécution d’un script, ou dans un document tiers que votre page ne fait qu’encadrer. Ces trois réponses ne coûtent pas la même chose, et deux d’entre elles ne rapportent rien au référencement de la boutique.
Ce guide mesure les quatre montages possibles sur une page de démonstration, avec les mêmes douze avis et le même rendu visuel, sur un profil mobile bridé. Il donne les chiffres de décalage de mise en page et de LCP relevés, montre ce que le robot reçoit dans chaque cas, et explique pourquoi les étoiles que vous espérez dans Google n’apparaîtront pas — même avec un balisage parfait.
Ce que Google affiche, et ce qu’il n’affiche pas
Commençons par la déception utile, parce qu’elle décide de tout le reste. Une boutique qui affiche ses avis Google sur sa page d’accueil, avec un balisage AggregateRating impeccable rattaché à son Organization ou à son LocalBusiness, n’obtiendra pas d’étoiles dans les résultats de recherche. Ce n’est pas une question de qualité de balisage : c’est une règle.
Les extraits d’avis ne sont pas affichés pour les avis qu’une entité collecte ou héberge à son propre sujet sur son propre site. La restriction vise nommément les types
LocalBusinessetOrganization.— résumé de la règle dite des « self-serving reviews », documentation Google sur les extraits d’avis, en vigueur depuis septembre 2019
Autrement dit : votre note globale d’entreprise, sur votre propre domaine, ne produit pas d’étoiles. Ce qui en produit, c’est un avis rattaché à autre chose que vous — et sur une boutique, cet « autre chose » existe : le produit.
| Balisage | Sur quoi | Étoiles possibles |
|---|---|---|
Organization + aggregateRating | votre société, sur votre site | non — avis auto-attribué |
LocalBusiness + aggregateRating | votre magasin, sur votre site | non — même règle |
Product + review | un produit de votre catalogue | oui, si l’avis porte bien sur ce produit |
Product + aggregateRating | un produit, note moyenne | oui, avec reviewCount ou ratingCount |
Avis Google repris en Review | votre société | non, et l’origine du texte ne change rien |
La conséquence est contre-intuitive et rarement écrite : afficher vos avis Google est un travail de conversion, pas de référencement. Le levier de référencement, sur PrestaShop, s’appelle les avis produits — et il passe par un module qui collecte sur votre boutique, pas par une reprise de votre fiche Google. Les deux chantiers sont légitimes ; les confondre fait perdre six mois.
Vérifiez d’ailleurs ce que votre installation émet déjà, avant d’acheter quoi que ce soit :
$ grep -rn "aggregateRating" modules/ themes/ | grep -v node_modules
$ grep -rn "application/ld+json" themes/votre-theme/templates/catalog/product.tplBeaucoup de boutiques découvrent à ce moment-là qu’un module payant injecte un balisage produit invalide depuis deux ans, ou qu’un thème émet deux blocs Product concurrents sur la même page. C’est un quart d’heure de vérification qui économise un module.
D’où viennent les avis : trois sources, trois limites
Tout module d’affichage d’avis Google puise dans l’une de ces trois sources. Aucune n’est neutre.
| Source | Volume accessible | Ce qu’elle exige | Risque |
|---|---|---|---|
| Places API | cinq avis au maximum, choisis par Google | une clé API, une facturation à la requête | aucun, mais vous n’aurez jamais le sixième avis |
| Business Profile API | tous les avis de vos établissements | être propriétaire de la fiche, un jeton OAuth, une demande d’accès | le jeton expire ; sans surveillance, le bloc se vide un jour sans bruit |
| Extraction de la page publique | variable, jusqu’à la prochaine modification du HTML de Google | rien, sauf accepter de violer les conditions d’utilisation | rupture à chaque changement chez Google, et blocage d’adresse IP |
La limite de cinq avis de la Places API explique un phénomène que tous les marchands constatent sans le comprendre : le carrousel affiche toujours les mêmes avis, et le nouveau commentaire à cinq étoiles obtenu la semaine dernière n’y apparaît jamais. Ce n’est pas un défaut du module. C’est le plafond de l’interface. Un module vendu comme « synchronisation complète de vos avis Google » et qui ne demande qu’une clé API ne peut, techniquement, en afficher plus de cinq.
Deux obligations accompagnent l’usage de la Places API, et elles sont contractuelles : l’attribution à Google doit rester visible, et le texte de l’avis ne doit pas être modifié — ni tronqué proprement, ni corrigé, ni traduit. Les conditions de la plateforme autorisent par ailleurs à conserver l’identifiant de lieu sans limite de durée, mais seulement une mise en cache temporaire du reste. Une architecture qui recopie les avis dans votre base pour les y laisser deux ans sort du cadre : vérifiez les conditions en vigueur avant de construire ce cache.
Quatre façons de poser le bloc dans la page
À rendu visuel identique, quatre montages s’offrent à vous. Sur PrestaShop, le point d’accrochage est un hook du thème — displayHome pour la page d’accueil, displayFooter pour le pied, displayFooterProduct ou displayProductAdditionalInfo sur la fiche produit, displayReassurance pour la bande de réassurance du thème classique.
- A — dans le HTML. Un traitement planifié récupère les avis, les enregistre, et le template les rend côté serveur. Le hook ne renvoie que du HTML.
- B — injecté par script, sans place réservée. Le hook renvoie un conteneur vide ; un script le remplit après réponse du service.
- C — injecté par script, place réservée. Le même, avec une hauteur minimale sur le conteneur.
- D — widget en iframe. Le montage de la plupart des services d’avis clés en main : votre page encadre un document tiers.
Ce que coûte chaque méthode, mesuré sur banc
Protocole : quatre pages servies en local, mêmes douze avis, même feuille de style, réseau bridé à cent cinquante millisecondes de latence et 1,6 Mb/s, processeur ralenti quatre fois — le profil d’un mobile de milieu de gamme. Décalage cumulé et LCP relevés par PerformanceObserver, sept chargements par page, médiane retenue. Les sept tours ont donné la même valeur au dix-millième près, ce qui était attendu : la latence est simulée, pas subie.
Premier cas : le bloc d’avis est dans la fenêtre au chargement, comme sur une page d’accueil où la réassurance monte haut.
| Méthode | Décalage cumulé (CLS) | LCP |
|---|---|---|
| A — avis dans le HTML | 0 | 268 ms |
| B — injection sans place réservée | 0,441 | 760 ms |
| C — injection, place réservée | 0,006 | 764 ms |
| D — widget en iframe | 0,317 | 248 ms |
Second cas : le bloc est en bas de page et le lecteur a défilé jusqu’à lui avant que le script ne réponde.
| Méthode | Décalage cumulé (CLS) | LCP |
|---|---|---|
| A — avis dans le HTML | 0 | 264 ms |
| B — injection sans place réservée | 0,116 | 256 ms |
| C — injection, place réservée | 0,037 | 252 ms |
| D — widget en iframe | 0,083 | 252 ms |
Troisième cas, et c’est celui qu’aucun guide ne mentionne : le bloc est en bas de page et le lecteur n’a pas encore défilé quand le script répond. Les quatre méthodes donnent alors un décalage cumulé de zéro. Le décalage ne compte que ce qui bouge dans la fenêtre ; un bloc qui se déplie huit cents pixels sous le pli ne déplace rien de visible.
Trois conclusions, et la première est celle qui économise le plus d’argent.
Le coût d’un widget d’avis n’est pas intrinsèque : il dépend de l’endroit où vous le posez. Le même script, le même service, le même module donne 0,441 en haut de page et 0 en bas de page. Avant de changer de solution parce que la mesure de terrain est mauvaise, déplacez le bloc. Sur une page d’accueil, un bloc d’avis en réassurance haute est le pire emplacement possible pour une injection tardive ; en bas, juste avant le pied, il ne coûte plus rien.
Réserver la hauteur divise le décalage par soixante-dix. De 0,441 à 0,006, pour une ligne de CSS. Encore faut-il que la hauteur réservée corresponde : les six millièmes résiduels viennent d’un écart de quelques pixels entre la hauteur annoncée et la hauteur réelle. Une hauteur trop courte décale encore, une hauteur trop longue laisse un blanc. Mesurez la hauteur rendue une fois, inscrivez-la, et reprenez la mesure si le nombre d’avis affichés change.
Réserver la place ne répare pas le LCP. De 268 à 764 millisecondes, soit presque trois fois, dès lors que le bloc d’avis est le plus grand élément de la fenêtre. La place réservée empêche la page de sauter ; elle n’avance pas le moment où le contenu s’affiche. Le seul montage qui tienne les deux, c’est le rendu serveur.
Notez enfin l’anomalie de la colonne LCP pour l’iframe : 248 millisecondes, la meilleure valeur du tableau, alors que la page saute de 0,317. Le contenu d’une iframe n’est pas candidat au LCP du document parent. L’iframe ne rend pas la page rapide : elle rend la lenteur invisible à l’une des deux mesures.
L’iframe ne met pas vos avis dans votre page
Le même banc donne un second jeu de chiffres, plus décisif que les premiers pour qui cherche du référencement.
| Méthode | HTML servi | Texte des avis dans le HTML servi | Texte dans le document après exécution du script | Éléments du document |
|---|---|---|---|---|
| A — HTML | 6 515 o | oui | oui | 142 |
| B — injection | 3 244 o | non | oui | 144 |
| C — injection réservée | 3 269 o | non | oui | 144 |
| D — iframe | 2 987 o | non | non | 60 |
Soixante éléments au lieu de cent quarante-quatre : les douze cartes d’avis ne sont pas dans votre document, elles sont dans un autre. Le test est reproductible en trois lignes et vaut tous les arguments commerciaux :
$ curl -s https://votre-boutique.fr/ | grep -c "un extrait d'un de vos avis"
0
# puis, dans la console du navigateur, une fois la page chargée :
> document.documentElement.outerHTML.includes("un extrait d'un de vos avis")
false // iframe : le texte n'entrera jamais dans votre page
true // injection : il y entre, mais après coupPour la conversion, l’iframe fait le travail : le visiteur voit les avis, se rassure, achète. Pour tout le reste — le contenu de votre page, la longueur utile de votre page d’accueil, le vocabulaire que vos clients emploient et que vous aimeriez voir associé à votre marque — elle ne fait rien. Le texte appartient au document tiers.
Le balisage : ce qu’il faut écrire, et où
Puisque la note d’entreprise ne produit pas d’étoiles, le balisage utile sur PrestaShop est celui des avis produits, sur la fiche produit, et lui seul. Il tient en un bloc, à côté du Product que votre thème émet déjà — surtout pas dans un second bloc concurrent.
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Nom exact du produit",
"sku": "REF-1234",
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.6",
"bestRating": "5",
"ratingCount": "57"
},
"review": [{
"@type": "Review",
"author": { "@type": "Person", "name": "Prénom N." },
"datePublished": "2026-08-14",
"reviewRating": { "@type": "Rating", "ratingValue": "5", "bestRating": "5" },
"reviewBody": "Le texte de l'avis, non modifié."
}]
}Quatre erreurs reviennent dans les audits, et chacune suffit à faire disparaître les étoiles.
- Le balisage annonce des avis que la page n’affiche pas. La règle est explicite : la note et les avis déclarés doivent être visibles par le visiteur sur cette page. Un
aggregateRatingposé sur une fiche produit dont le bloc d’avis a été masqué par le thème est une invalidation garantie. - Le nombre est faux.
ratingCountcompte les notes,reviewCountcompte les avis rédigés. Les deux existent, ils ne mesurent pas la même chose, et déclarer l’un en donnant la valeur de l’autre est une incohérence détectable. - La note d’entreprise est recopiée sur chaque fiche produit. Vingt-huit fiches qui affichent toutes 4,7 sur 312 avis : c’est la note de la boutique, pas celle du produit. Le motif est repéré.
- Deux blocs
Productsur la même page. Le thème émet le sien, le module d’avis émet le sien. Le moteur en choisit un, souvent le plus pauvre.
Collecter : le moment, le canal, et ce que Google interdit
Sur PrestaShop, la demande d’avis se déclenche proprement sur un changement d’état de commande. Le hook actionOrderStatusPostUpdate reçoit l’état visé ; le seul état qui a du sens est « Livré », pas « Paiement accepté ». Demander un avis à quelqu’un qui n’a pas encore reçu son colis, c’est demander un avis sur votre tunnel de commande — et parfois recevoir un avis sur un retard de transporteur.
Le délai compte autant que l’état. Trop tôt, le client n’a pas utilisé le produit ; trop tard, il a oublié. Une file d’attente qui envoie entre trois et sept jours après le passage à « Livré », selon la nature du produit, est le réglage qui tient : quelques heures pour un service numérique, une semaine pour un objet qu’il faut monter.
Trois interdits, et ils ne sont pas négociables.
- Aucune incitation. La politique de Google sur les avis interdit d’offrir une remise, un bon, un tirage au sort ou quoi que ce soit d’autre en échange d’un avis. Un code promo dans l’e-mail de demande d’avis est une infraction, pas une astuce marketing.
- Aucun filtrage préalable. Demander d’abord « êtes-vous satisfait ? » et n’envoyer vers Google que ceux qui répondent oui — le review gating — est explicitement proscrit. Le montage est repérable, et il se paie par la suppression des avis obtenus.
- Aucun achat. Inutile de développer ; ajoutons seulement que les paquets d’avis achetés arrivent par grappes dans la même semaine, depuis des comptes sans historique, ce qui est exactement le motif que les systèmes de détection cherchent.
Ce qui fonctionne, en revanche, n’est pas spectaculaire : un message court, un seul lien, aucun formulaire intermédiaire, et l’envoi depuis une adresse qui ressemble à celle d’un humain. Le lien direct vers le formulaire d’avis de votre fiche s’obtient depuis votre profil d’établissement ; il faut le tester sur mobile, parce que c’est là que le client le suivra.
L’arithmétique des avis : ce qu’un avis à une étoile coûte vraiment
Les marchands raisonnent en volume — « il me faut plus d’avis » — alors que la mécanique est arithmétique et se calcule. Pour passer d’une moyenne a sur n avis à une cible t, le nombre d’avis à cinq étoiles nécessaires vaut n × (t − a) / (5 − t). Le tableau est brutal.
| Avis actuels | 4,2 → 4,5 | 4,2 → 4,7 | 4,5 → 4,7 | 3,9 → 4,5 |
|---|---|---|---|---|
| 20 avis | 12 | 34 | 14 | 25 |
| 40 avis | 24 | 67 | 27 | 49 |
| 100 avis | 60 | 167 | 67 | 121 |
| 200 avis | 120 | 334 | 134 | 241 |
| 300 avis | 180 | 501 | 201 | 361 |
Une boutique à 4,2 sur 200 avis qui veut afficher 4,7 doit obtenir 334 avis parfaits. À vingt avis par mois, cela fait quatorze mois sans un seul accroc. C’est la raison pour laquelle il faut commencer à collecter avant d’avoir un problème de note : la moyenne est une masse, et une masse a de l’inertie.
Le calcul inverse est plus utile encore. Combien d’avis à cinq étoiles faut-il pour effacer un avis à une étoile, c’est-à-dire revenir à la moyenne d’avant ? La réponse ne dépend pas du nombre d’avis que vous avez — le n disparaît de l’équation — mais uniquement de votre moyenne : k = (a − 1) / (5 − a).
| Moyenne affichée | Avis 5★ pour revenir au même point |
|---|---|
| 4,0 | 3 |
| 4,2 | 4 |
| 4,5 | 7 |
| 4,6 | 9 |
| 4,7 | 13 |
| 4,8 | 19 |
| 4,9 | 39 |
Plus votre note est haute, plus un mécontent coûte cher. À 4,9, un seul avis à une étoile vous demande trente-neuf avis parfaits pour être compensé. C’est un argument de gestion, pas de communication : le budget qui protège la note n’est pas le budget de collecte, c’est celui du service client et du transporteur.
Une nuance, parce qu’elle contredit à moitié ce qui précède : la moyenne affichée, arrondie au dixième, est protégée par le volume. Sur vingt avis à 4,5, un avis à une étoile fait tomber l’affichage à 4,3 ; sur cent cinquante avis, l’affichage reste à 4,5. Le volume n’empêche pas la perte, il la rend invisible — jusqu’au jour où elle franchit l’arrondi.
Consentement : un widget tiers avant le bandeau est un problème
Un widget d’avis clés en main charge un script depuis un domaine tiers, dépose souvent un identifiant, et va chercher les photos de profil des auteurs sur les serveurs de Google. Chacune de ces trois opérations transmet l’adresse IP du visiteur à un tiers, avant tout consentement si le widget se charge au chargement de la page.
Ce n’est pas un détail juridique abstrait : c’est le genre de manquement qui se voit en quinze secondes dans l’onglet réseau, et le premier que regarde un contrôle. La parade est la même que celle qui règle le LCP — récupérer les avis côté serveur, les stocker, servir le HTML et héberger vous-même les éventuelles images. Le montage conforme et le montage rapide sont le même montage. C’est assez rare pour être souligné.
Si vous conservez un widget tiers, alors il se charge après consentement, derrière un substitut cliquable, avec une hauteur réservée pour que l’acceptation ne fasse pas sauter la page. Et vous mesurez à nouveau : le décalage que vous avez mesuré sans bandeau n’est pas celui que vivent vos visiteurs.
L’architecture que nous posons
Sur les boutiques que nous reprenons, le montage tient en cinq pièces, et aucune n’est un module du marché.
- Un traitement planifié, une à quatre fois par jour, appelle l’interface choisie et enregistre les avis dans une table dédiée — texte, note, date, auteur, identifiant d’origine pour éviter les doublons.
- Une trace de l’échec. Si l’appel échoue, le traitement le journalise et conserve les avis précédents. Le bloc ne se vide jamais ; c’est la première chose que font les modules mal écrits quand un jeton expire.
- Le template rend le HTML depuis la table, sans appel réseau à l’affichage. Décalage nul, LCP intact, texte dans la page.
- Le balisage
Productest émis sur les fiches, depuis les avis produits collectés sur la boutique — jamais depuis la note Google de l’entreprise. - La demande d’avis part d’une file d’attente branchée sur le passage à « Livré », avec un délai réglable et un journal des envois pour ne pas solliciter deux fois le même client.
Le coût de ce montage est de deux à quatre jours de développement selon l’interface retenue et l’état du thème. Un module du marché coûte entre soixante et deux cents euros. La différence ne se joue pas sur le prix mais sur trois points : ce que vous pouvez afficher — cinq avis ou tous —, ce que le robot reçoit, et ce qui se passe le jour où le jeton expire. Sur une boutique qui vit de sa réassurance, le module se rentabilise ; sur une boutique qui vise les résultats de recherche, il ne répond pas à la question.
Ce chantier fait partie de ce que nous traitons en développement PrestaShop, et il arrive rarement seul : il croise la question du balisage produit, celle du consentement et celle de la vitesse de la fiche produit.
Le tableau de décision
| Votre situation | Le montage qui convient |
|---|---|
| Cinq avis suffisent, budget serré, bloc en bas de page | Places API, module du marché, bloc sous le pli, hauteur réservée |
| Bloc de réassurance en haut de la page d’accueil | rendu serveur obligatoire — aucune injection ne tient à cet emplacement |
| Vous voulez des étoiles dans les résultats de recherche | avis produits collectés sur la boutique, balisage Product ; les avis Google ne le permettent pas |
| Plusieurs établissements, cent avis et plus | Business Profile API, cache en base, surveillance du jeton |
| Vous partez de zéro avis | commencez par la collecte : l’affichage d’une note à 4,1 sur sept avis dessert la boutique |
Ce qu’il faut retenir
Les avis Google affichés sur votre boutique sont un outil de conversion, et un outil efficace. Ils ne produisent pas d’étoiles dans les résultats de recherche, parce que la règle des avis auto-attribués s’y oppose, et aucun module ne contourne cette règle. Ce qui produit des étoiles, sur PrestaShop, ce sont les avis produits collectés sur votre boutique et balisés sur la fiche.
Pour l’affichage, la hiérarchie est claire et mesurée : le rendu serveur ne coûte rien et met le texte dans votre page ; l’injection avec place réservée est acceptable sous le pli ; l’injection sans place réservée est inacceptable au-dessus du pli ; l’iframe convertit mais n’apporte rien à votre contenu. Et si votre mesure de terrain s’est dégradée après l’installation d’un module d’avis, commencez par regarder à quelle hauteur de page il est posé — c’est souvent tout le problème.
