Audit UX d'Adopt : recherche interne, bandeau promo et panier

Contexte

J'ai découvert Adopt à travers une publication LinkedIn. Je ne connaissais pas cette marque de parfums, née à Bordeaux en 1986 : c'était donc une première visite, comme pour un nouveau client.

En explorant son site e-commerce, j'ai relevé plusieurs points de friction, surtout dans la recherche interne, ainsi que deux bugs sur la liste de souhaits et le panier.

La recherche mérite une attention particulière. Un visiteur qui tape une requête sait souvent ce qu'il veut : c'est un client à fort potentiel. Si le moteur lui répond « Aucun résultat », il risque de conclure que la boutique n'a rien pour lui.

Méthodologie

• Périmètre : page d'accueil, barre d'annonces, recherche interne (panneau de suggestions et page de résultats), liste de souhaits, panneau du panier.
• Navigateurs : Firefox 156.0 et Google Chrome 154.0, sur ordinateur.
• Plateforme : Magento 2 avec le thème Hyvä. La recherche repose sur Smile ElasticSuite, d'après le code source des pages.
• Hors périmètre : version mobile, tunnel de commande, SEO.
• Date des constats : 30 septembre 2026. Certains points ont été revérifiés le 19 octobre 2026.

Un site rapide

La page d'accueil présente une interface soignée et se charge rapidement. Le test Google Lighthouse du 30 septembre 2026, en mode ordinateur, le confirme : score de performance de 98/100, Largest Contentful Paint de 1,0 s et Cumulative Layout Shift de 0,001.

C'est un vrai point fort, et un bon exemple de ce que permet le thème Hyvä sur Magento 2. Les points qui suivent ne relèvent donc pas de la performance, mais de l'usage.

Barre d'annonces : un défilement trop rapide et sans contrôle

Constats.

La barre d'annonces, en haut de chaque page, fait défiler trois messages, dont « Livraison OFFERTE dès 35€ » et « Inscrivez-vous à notre newsletter et recevez -20% sur votre prochain achat ».

1. Le message change toutes les trois secondes. Le code de la page le confirme (setInterval de 3 000 ms). C'est trop court pour lire certains messages, en comprendre l'intérêt et décider de cliquer.
2. Le défilement s'interrompt bien au survol de la souris et lorsque le bandeau reçoit le focus clavier. C'est un bon point.
3. Aucune commande visible ne permet de revenir à l'annonce précédente ou de passer à la suivante. Il faut quitter le bandeau et attendre la reprise du défilement. Le glissement vers la gauche ou la droite ne fonctionne pas non plus. Seuls les utilisateurs du clavier peuvent naviguer, avec les flèches haut et bas, sans que rien ne l'indique.

Lors de ma première visite, une annonce a retenu mon attention. Le temps de la lire puis de déplacer ma souris pour cliquer, le message avait changé : j'ai ouvert la page correspondant à l'annonce suivante, qui ne m'intéressait pas.

Pourquoi c'est un problème.

Le Nielsen Norman Group a observé que les contenus qui défilent automatiquement ne laissent pas le temps de lire aux lecteurs lents ou non natifs, et qu'ils gênent les personnes qui ont du mal à cliquer avant que l'élément ne change. Chaque message n'est par ailleurs visible qu'un tiers du temps.

Côté accessibilité, le bandeau porte l'attribut aria-live="polite". Les lecteurs d'écran annoncent donc chaque nouveau message, toutes les trois secondes. Le guide des pratiques ARIA du W3C recommande au contraire aria-live="off" tant que le carrousel défile automatiquement, et des boutons « précédent » et « suivant ».

Ma recommandation.

1. Allonger la durée d'affichage à 6 ou 7 secondes au minimum, ou l'adapter à la longueur du message.
2. Ajouter deux flèches discrètes de part et d'autre du message, sous forme de vrais boutons.
3. Passer aria-live à off pendant le défilement automatique, et à polite lorsqu'il est en pause.

Recherche interne : des requêtes qui mènent à une impasse

La recherche s'ouvre dans un panneau de suggestions qui se met à jour pendant la saisie. Une pression sur Entrée mène à la page de résultats complète. J'ai testé les deux.

Les recherches de « services »

Constat.

La recherche ne sert pas qu'à trouver des produits. J'ai testé des requêtes comme « suivre ma commande », « remboursement » ou « frais de livraison ».

Pour « suivre ma commande », le panneau affiche « Aucun résultat » en haut, puis des nouveautés. Le lien « Suivre ma commande » apparaît bien, mais tout en bas, dans le bloc « Comment vous aider ? ». La page de résultats complète, elle, répond « Oups ! Nous n'avons pas trouvé de résultat » pour ces trois requêtes.

Pourquoi c'est un problème.

Un client peut s'arrêter au message « Aucun résultat » sans voir le lien proposé plus bas. Or ces requêtes n'ont rien de marginal : lors de ses tests, Baymard a constaté que 34 % des utilisateurs cherchaient des contenus autres que des produits, comme la politique de retour, les frais de livraison ou le suivi de commande.

Ma recommandation.

Associer les requêtes de service les plus fréquentes (suivi, retour, remboursement, livraison, contact) aux pages correspondantes. Pour une requête précise comme « suivre ma commande », rediriger directement vers la page. Pour une requête vague comme « livraison », afficher le lien d'aide en tête du panneau, avec un style distinct de celui des produits. Les journaux de recherche permettent de compléter la liste.

Les fautes de frappe et variantes orthographiques

Constats.

Pour les requêtes « parfin », « parfun », « parfim », « vannille » et « vanile », le panneau de recherche affiche « Aucun résultat ».

Pour « parfin », il propose en revanche des suggestions qui reprennent la faute :

• Parfin instinct mal
• parfin rose noir pour femme
• parfin à moin de 7 euros
• Parfin adopt instinct mal
• Parfin Praline Rose

Ces suggestions semblent issues de recherches précédentes d'autres visiteurs, fautes comprises.

Sur la page de résultats complète, le comportement est différent : le moteur indique « Aucun résultat exact » et propose des « résultats approchants ».

Lors de ma vérification du 19 octobre, ces résultats approchants étaient pertinents pour « vannille » (Vanille bourbon, Vanille coco…) et pour « parfin rose noir pour femme » (Rose Noire). Pour « parfin » seul, en revanche, les premiers produits étaient « Jolie Paris », « Paris-Brest » et des étuis à parfum : le moteur a rapproché « parfin » de « Paris ».

Pourquoi c'est un problème.

Le moteur sait donc corriger une partie des fautes, mais le panneau de suggestions, le premier que voit le visiteur, affirme le contraire. Un client qui lit « Aucun résultat » n'a aucune raison d'appuyer sur Entrée.

Baymard estime que 69 % des sites ne proposent pas de suggestions pertinentes pour les requêtes légèrement mal orthographiées, et observe que les utilisateurs hésitent à lancer une recherche sans la confirmation de ces suggestions.

Ma recommandation.

Appliquer au panneau de suggestions la même tolérance aux fautes que sur la page de résultats. ElasticSuite dispose de réglages de tolérance aux fautes (fuzziness) et de recherche phonétique. Ajouter des synonymes pour les fautes les plus courantes (« parfin » → « parfum », « vanile » → « vanille »), et retirer des suggestions les requêtes mal orthographiées.

Les recherches qui expriment un besoin

Constats.

La suggestion « parfin à moin de 7 euros » exprime un besoin précis : trouver un parfum à moins de 7 €. Elle mène pourtant à une page « Oups ! Nous n'avons pas trouvé de résultat ». Le catalogue contient bien des parfums à ce prix : lors de ma vérification du 19 octobre, plusieurs étaient affichés à 5,95 €.

Pour « parfum pas cher », le panneau met en avant un seul produit, le Présentoir Floral à 39,78 €. La catégorie « Parfums pas chers », qui contenait au moment de mon test des produits entre 11,95 € et 30 €, n'apparaît qu'en bas du panneau, en petits caractères.

En appuyant sur Entrée, je suis redirigé vers la fiche du Présentoir Floral, avec le message : « Présentoir Floral est le seul produit correspondant à votre recherche : 'Parfum pas cher' ». C'est faux.

Pourquoi c'est un problème.

Le seul produit mis en avant est plus cher que ceux de la catégorie suggérée. Le client risque de se faire une fausse idée du premier prix :

Est-ce vraiment le produit le moins cher ? Il dépasse mon budget, je vais chercher ailleurs.

Baymard constate qu'une grande partie des sites e-commerce proposent une page « Aucun résultat » qui est une impasse, alors qu'elle devrait guider l'utilisateur vers des produits ou des catégories proches.

Ma recommandation.

Rediriger les requêtes de type « pas cher », « petit prix » ou « moins de X euros » vers la catégorie « Parfums pas chers » triée par prix croissant, plutôt que vers une fiche produit. Sur la page « Aucun résultat », proposer au minimum les catégories principales et les meilleures ventes.

Les suggestions de recherche du site

Constat.

Avant toute saisie, le champ de recherche propose des exemples rédigés en langage naturel : « Je recherche des notes de vanille », « Je recherche un calendrier », « Je cherche un coffret découverte »…

Le principe est intéressant. Pourtant, chacune de ces suggestions a conduit à une page « Aucun résultat ». À l'inverse, la requête « coffret découverte » seule renvoie bien des produits.

Pourquoi c'est un problème.

Le site invite le visiteur à formuler sa recherche comme une phrase, mais son moteur ne sait pas la traiter. Les mots « je », « cherche » et « un » font échouer la recherche. Le visiteur qui suit l'exemple proposé par le site aboutit à une impasse dès sa première recherche.

Ma recommandation.

Ignorer les formules d'introduction (« je cherche », « je recherche », « un », « des ») en les ajoutant aux mots vides du moteur, ou faire pointer chaque suggestion vers une catégorie existante (« Coffrets », « Calendrier de l'Avent »…). Tester chaque suggestion après sa mise en ligne.

Liste de souhaits : impossible de retirer un produit

Constat.

Étapes pour reproduire le bug :

1. Ouvrir la recherche ;
2. Ajouter un produit à la liste de souhaits depuis les résultats ;
3. Ouvrir sa fiche produit ;
4. Tenter de le retirer de la liste de souhaits.

Le bouton ne produit aucun effet et une erreur JavaScript apparaît dans la console :

Uncaught TypeError: can't access property "classList", e[i].querySelector(...) is null
    removeFromWishlist https://www.adopt.com/fr/eau-de-parfum-moonlight-8883701429858858-fr.html:149
    removeFromWishlist https://www.adopt.com/fr/eau-de-parfum-moonlight-8883701429858858-fr.html:149
    toggleWishlist https://www.adopt.com/fr/eau-de-parfum-moonlight-8883701429858858-fr.html:149
    ...

Pourquoi c'est un problème.

Le bug est d'autant plus frustrant qu'il n'est pas non plus possible de supprimer ce produit depuis la page « /wishlist ». Le client ne peut plus faire le tri dans sa liste.

Ma recommandation.

Le script cherche un élément qui n'existe pas sur la fiche produit, sans vérifier sa présence. Il faut tester le retour de querySelector avant d'accéder à classList, puis vérifier l'ajout et le retrait depuis chaque point d'entrée : résultats de recherche, listes de produits, fiche produit et page « /wishlist ».

Panier : un produit supprimé reste affiché

Constat.

Étapes pour reproduire le bug :

1. Ajouter un produit au panier ;
2. Attendre l'ouverture du panneau de confirmation ;
3. Faire passer la quantité du produit à zéro.

Le produit ne disparaît visuellement qu'après la fermeture du panneau. Pourtant, la suppression est bien prise en compte : le compteur de livraison offerte affiche « Plus que 35.00 € », soit le seuil complet, comme si le panier était vide. Le produit à 13,96 € reste affiché juste au-dessus.

Pourquoi c'est un problème.

Le panneau affiche deux informations contradictoires. L'absence de retour visuel immédiat crée un doute au moment le plus sensible du parcours :

Ai-je bien supprimé le produit ? Je ne voudrais pas le commander par erreur.

Ma recommandation.

Retirer la ligne du produit dès que la quantité passe à zéro, avec un message de confirmation et un lien « Annuler ». Au passage, harmoniser le format des prix : « 35.00 € » utilise un point, alors que les prix des produits utilisent une virgule (« 13,96 € »).

Synthèse des constats

Conclusion

Adopt dispose d'une base technique solide : le site est rapide, et son moteur de recherche sait déjà corriger une partie des fautes de frappe. La plupart des points relevés tiennent donc moins à la technique qu'à la configuration et aux tests.

C'est la recherche qui concentre le plus de friction. Panneau qui annonce « Aucun résultat » alors que des produits existent, suggestions du site qui échouent, demande de petit prix qui renvoie vers un produit à près de 40 € : à chaque fois, le visiteur le plus motivé reçoit le message que la boutique n'a rien pour lui.

Trois vérifications simples permettraient de repérer la plupart de ces erreurs :

1. Consulter chaque mois les requêtes sans résultat dans les statistiques de recherche, et corriger les plus fréquentes par des synonymes ou des redirections.
2. Tester chaque suggestion affichée par le site, dans le panneau et sur la page de résultats complète.
3. Tester les actions réversibles (ajouter puis retirer de la liste de souhaits, ajouter puis supprimer du panier) depuis chaque point d'entrée.

J'espère que cette étude de cas vous a donné un aperçu concret de ma démarche d'audit. Vous préparez une refonte ou une migration de votre boutique, ou vous souhaitez identifier les points de friction de votre site e-commerce ? Découvrez mes prestations d'audit UX et SEO e-commerce.