La plupart des projets de recherche sur site commencent par le mauvais endroit : une démonstration chez le fournisseur. Cette démonstration fonctionne toujours, car elle est exécutée sur l’index du fournisseur avec ses propres requêtes. Or, l’étude comparative de recherche 2026 du Baymard Institute révèle que… 56 % des sites e-commerce ont une expérience utilisateur de recherche médiocre, voire mauvaise.et que les échecs se regroupent en types de requêtes spécifiques et nommables plutôt qu'en « pertinence » dans son ensemble (Baymard, mise à jour avril 2026Un nouveau moteur corrige certains de ces problèmes, mais aucun des autres.
Voici une grille d'évaluation pour votre moteur de recherche actuel. Vingt critères, deux points chacun, soit quarante points au total. Appliquez-la à votre catalogue en une après-midi ; vous obtenez un score qui vous indique si le problème vient de la configuration, du contenu ou du moteur lui-même. Cet outil est destiné aux responsables UX e-commerce, aux responsables de la croissance et aux chefs de produit chargés de justifier un budget de recherche.
Ce que la rubrique mesure, et ce qu'elle ignore délibérément
La grille d'évaluation prend en compte quatre aspects : la capacité de la recherche à comprendre les types de requêtes réellement saisies, sa résistance aux entrées incorrectes, sa capacité à gérer les échecs et la mesurabilité de ces aspects. Elle n'évalue pas la qualité du classement des résultats de manière abstraite. Le classement est le dernier paramètre à optimiser et le premier sujet de controverse ; or, il est impossible de l'optimiser tant que les requêtes échouent au niveau de l'analyseur lexical.
Le score est de 0, 1 ou 2 par test. 2 signifie que le test est réussi pour toutes les requêtes de votre liste de test. 1 signifie qu'il est réussi pour les termes principaux, mais échoue pour les requêtes de longue traîne. 0 signifie qu'il échoue pour les termes principaux. Commencez par créer votre liste de test : prenez vos 50 requêtes principales issues de l'analyse, puis ajoutez cinq requêtes que vous construisez pour chacun des huit types de requêtes Baymard afin de représenter les requêtes de longue traîne. Cela représente environ 90 requêtes. Exécutez-les vous-même, sur mobile, en étant déconnecté.
Les 20 chèques
| # | Vérifiez | Scores 2 lorsque |
|---|---|---|
| Groupe A — Couverture des requêtes (clusters de défaillance de Baymard) | ||
| 1 | Requêtes exactes et par numéro de modèle | Le produit mentionné est le premier résultat, et non le quatrième. |
| 2 | Requêtes de type produit | Renvoie une liste à facettes consultable plutôt qu'un simple tableau de pertinence. |
| 3 | Requêtes de fonctionnalités (« manteau de laine rouge ») | Les attributs permettent de restreindre l'ensemble au lieu de le diluer avec la correspondance OU. |
| 4 | requêtes de compatibilité (« chargeur pour modèle X ») | Retourne les accessoires pour le modèle indiqué, pas le modèle lui-même. |
| 5 | Questions non liées aux produits (« politique de retour ») | Renvoie la page de contenu ; 66 % des sites échouent à ce test. |
| Groupe B — Gestion des entrées | ||
| 6 | Tolérance aux fautes de frappe | Les erreurs d'un et deux caractères sur les termes principaux correspondent toujours |
| 7 | Pliage des majuscules et des signes diacritiques | Correct pour toutes les langues prises en charge par le site (voir ci-dessous) |
| 8 | Morphologie et pluriels | Les formes fléchies et suffixées aboutissent aux mêmes produits que le radical. |
| 9 | Synonymes et vernaculaire local | Les termes clients correspondent aux termes du catalogue, dans les deux sens. |
| 10 | Correction automatique des fautes d'orthographe | Des suggestions apparaissent pour les préfixes mal orthographiés ; 69 % des sites échouent à ce test. |
| Groupe C — Résultats et récupération | ||
| 11 | Récupération sans résultat | Au moins deux voies de sortie actives : catégories connexes et requêtes alternatives |
| 12 | persistance des requêtes | La requête reste affichée après soumission ; 37 % des sites l'abandonnent. |
| 13 | La lunette est visible | Le nombre de résultats et le périmètre des catégories appliquées automatiquement sont indiqués et peuvent être supprimés. |
| 14 | Parité des facettes | Les résultats de recherche offrent les mêmes facettes que la page de catégorie correspondante. |
| 15 | La pertinence est explicable | Un membre de l'équipe peut expliquer pourquoi le premier résultat est meilleur que le deuxième. |
| Groupe D — Mesure | ||
| 16 | Chaque parcours de recherche est suivi. | La fonction view_search_results est déclenchée avec search_term, y compris les sauts de saisie automatique. |
| 17 | Les requêtes sans résultat sont isolables | Vous pouvez afficher la liste des requêtes sans résultat du mois dernier par volume, sans intervention de votre part. |
| 18 | Le processus de recherche en vue d'un achat est signalable. | Les personnes effectuant des recherches et celles n'en effectuant pas peuvent être comparées en tant que segments |
| 19 | La requête de révision a un propriétaire | Une personne désignée examine les 50 meilleurs résultats et les résultats nuls à intervalles réguliers. |
| 20 | Les modifications de configuration sont versionnées | Les modifications de synonymes et d'améliorations sont enregistrées, réversibles et testables. |
Les seuils du groupe A proviennent des taux d'échec par type publiés par Baymard : les recherches hors produit échouent sur 66 % des sites, les recherches d'abréviations et de symboles sur 54 %, la compatibilité sur 44 % et les cas d'utilisation sur 43 %.BaymardLa case 11 existe parce que près de la moitié des sites n'offrent aux utilisateurs aucun moyen efficace de sortir d'une impasse (Baymard, février 2025). Les contrôles 10 et 12 proviennent des résultats de la même analyse comparative sur la saisie semi-automatique et la persistance des requêtes (Référence de recherche Baymard).
Vérifiez le point 7 en détail : le piège du pliage qui n’apparaît qu’en dehors de l’anglais
Le point 7 mérite une section à part entière car c'est lui qui, sans le savoir, annule une donnée de marché. La plupart des moteurs de recherche convertissent la requête et l'index en minuscules avant la mise en correspondance. En anglais, cela est sans conséquence. En turc, c'est problématique, et ce même type de problème se pose dans toutes les langues utilisant des caractères autres que l'alphabet latin de base.
Unicode définit une règle de casse spécifique à la langue turque et azerbaïdjanaise : I majuscule (U+0049), minuscules sans point. ı (U+0131), tandis que le İ majuscule (U+0130) se transforme en minuscules ordinaires i (Unicode SpecialCasing.txtUne configuration qui convertit les caractères en minuscules avec les paramètres régionaux par défaut transforme « İPHONE » en « i̇phone » avec un point superflu, ou remplace le « I » majuscule d'un titre de produit par une lettre incorrecte. La requête et l'index divergent alors sur un mot qu'ils contiennent tous deux. Aucune erreur n'est signalée. Vous obtenez simplement zéro résultat pour une marque que vous proposez.
Les deux correctifs sont indépendants et vous devez tous les deux. Premièrement, appliquez la mise en minuscules conforme aux paramètres régionaux lors de l'indexation et des requêtes — Elasticsearch intègre une fonctionnalité de mise en minuscules. turkish analyseur qui enchaîne apostrophe, turkish_lowercase, turkish_stop, turkish_keywords et turkish_stemmer pour cette raison précise (Analyseurs de langage élastiquesDeuxièmement, il convient de décider séparément de la marche à suivre concernant les signes diacritiques, car les acheteurs turcs les utilisent couramment. kilf pour couverture et sarj pour åÿarj sur les claviers qui ralentissent la forme accentuée. asciifolding Ce filtre convertit les caractères non latins de base en leurs équivalents ASCII, et son preserve_original L'option émet à la fois le jeton plié et le jeton original, donc les correspondances exactes l'emportent toujours (Élastique, pliage ascii). Pliez pour référence, conservez l'original pour plus de précision.
En dehors de la Turquie, ce même contrôle présente des particularités locales : les noms composés allemands doivent être décomposés avant qu’une requête de deux mots puisse aboutir, les accents français et espagnols sont parfois saisis de manière incohérente, et le sigma final grec est présent. N’attribuez la note de 2 au contrôle 7 que si vous l’avez testé dans toutes les langues réellement prises en charge par votre boutique en ligne, et non dans la langue parlée par votre équipe.
Correction de la mesure en premier : contrôles 16 à 20
Si le score du groupe D est inférieur à 6, arrêtez-vous et corrigez le problème avant toute autre chose, car vous ne pouvez pas vérifier une correction que vous ne pouvez pas voir. Dans GA4, des mesures améliorées sont déclenchées. view_search_results avec search_term paramètre lorsqu'une page de résultats contient l'un des cinq paramètres de requête par défaut — q, s, search, query or keyword — et vous pouvez ajouter le vôtre (Aide Google AnalyticsDeux modes de défaillance sont fréquents. Si votre page de résultats utilise un segment de chemin plutôt qu'une chaîne de requête, le suivi par défaut ne détecte rien. De plus, si la saisie semi-automatique redirige directement vers un produit, cette recherche ne déclenche jamais l'événement, ce qui biaise discrètement votre journal de requêtes en faveur des recherches infructueuses lors de la première tentative.
Lecture de votre score
| Score | Verdict | Prochaine étape |
|---|---|---|
| 32-40 | Accordez, ne remplacez pas | Dépensez en synonymes, en règles de marchandisage et en triage des résultats nuls |
| 22-31 | Problème de configuration | Corrigez le groupe B et vérifiez d'abord le point 11 ; recalculez la note dans six semaines. |
| 12-21 | Probablement structurel | Réévaluer après la correction du groupe D, puis définir un périmètre de remplacement avec ces 20 contrôles comme critères d'acceptation |
| 0-11 | La fonction de recherche n'est pas encore disponible. | À considérer comme une construction, et non comme une optimisation |
La règle essentielle : ne signez jamais un nouveau contrat sur la base d’un score obtenu avant l’intervention du Groupe D. Un fournisseur évalué par rapport à une recherche non mesurée est évalué par rapport à une démonstration.
Remarque concernant le chiffre que tout le monde cite
On vous présentera une statistique indiquant que les utilisateurs effectuant une recherche sur le site convertissent deux ou trois fois mieux que ceux qui n'en effectuent pas, généralement pour justifier le budget. Ce chiffre circule largement dans les comparatifs de fournisseurs ((ici)) et est rarement attribuable à une étude contrôlée. Il s'agit également d'un biais de sélection : les personnes qui effectuent une recherche ont déjà une intention d'achat. Considérez-le comme une raison d'examiner la recherche, et non comme une projection d'augmentation. Une analyse de rentabilité solide repose sur votre propre volume de résultats nuls et votre propre taux de conversion recherche-achat — deux éléments que les contrôles 17 et 18 permettent de déterminer. [DONNÉES INTERNES REQUISES : Taux de résultats nuls des clients de Switas avant/après correction, le cas échéant.]
Là où cette rubrique présente des lacunes
Ce système est conçu pour la vente par catalogue. Les places de marché proposant un même article à de nombreux vendeurs nécessitent une évaluation des doublons et de la qualité des vendeurs, critères absents de cette grille d'évaluation. Les sites riches en contenu et les sites du secteur public requièrent une pondération basée sur le type de document et sa date de publication, plutôt que sur le groupe A. Les sites de moins de 500 références environ obtiennent souvent de bons scores, mais perdent des revenus liés à la recherche, car avec un catalogue restreint, la solution réside dans une meilleure navigation par catégories, et non dans une recherche plus performante. La grille d'évaluation ne mentionne ni la vitesse de recherche en cas de forte charge, ni la personnalisation ; ces omissions sont volontaires, car les tests sont coûteux et ne constituent pas un problème majeur avec un score inférieur à 30. Enfin, un score n'est qu'un instantané : une importation de catalogue modifiant la dénomination des attributs peut faire chuter le groupe A de six points du jour au lendemain, sans aucun déploiement de code.
QFP
Combien de temps dure le comptage des points ? Comptez environ une demi-journée par personne et par boutique en ligne, une fois la liste de test de 90 requêtes établie. La constitution de cette liste est la partie la plus longue ; prévoyez ensuite deux heures supplémentaires pour extraire les requêtes les plus fréquentes et constituer l’ensemble des requêtes de longue traîne.
Ai-je besoin d'ingénieurs pour le faire fonctionner ? Non. Les contrôles 1 à 15 sont exécutés dans un navigateur. Les contrôles 16 à 20 nécessitent un accès aux outils d'analyse et, pour le contrôle 20, une discussion avec le responsable de la configuration de recherche.
Que se passe-t-il si nous n'avons pas d'historique d'analyse de recherche ? Attribuez la note zéro au groupe D, corrigez le suivi et collectez quatre semaines de données avant d'attribuer la note aux autres groupes. Une liste de test créée sans journal de requêtes réel surreprésentera les requêtes que votre équipe saisirait.
Un score de 28 est-il bon ? C'est normal, et la normalité rime avec médiocrité — les données de référence indiquent que la plupart des sites se situent à ce niveau. Le signal utile n'est pas le total, mais le groupe qui le tire vers le bas.
Faut-il acheter une tolérance aux fautes de frappe ou la développer soi-même ? Achetez-le. La mise en correspondance par distance d'édition avec des seuils pertinents est une solution simple et économique. Le développement porte sur les synonymes et la structure des attributs, spécifiques à votre catalogue et non disponibles dans le commerce.
Quel est le lien avec un audit de page de catégorie ? Ils partagent des facettes et des filtres. Si le contrôle 14 échoue, la correction se trouve généralement dans les modèles de catégories plutôt que dans la recherche ; il est donc conseillé d’exécuter les deux audits lors du même sprint.
Est-ce que cela s'applique aux agents d'achat IA qui consultent notre catalogue ? En partie. Les agents utilisent des attributs structurés plutôt que votre interface de recherche ; les groupes A et B sont donc importants pour eux en raison de la qualité de vos données, tandis que les groupes C et D ne s’appliquent pas du tout. Il s’agit d’un audit distinct.
À quelle fréquence devrions-nous réévaluer le score ? Trimestriellement, et après toute migration de catalogue, changement de plateforme ou modification de la configuration de recherche. Conservez la même liste de 90 requêtes afin que les scores soient comparables.
Si vous voulez connaître le score sans y passer l'après-midi : Laissez-nous réaliser cet audit de votre magasin. et vous remettre la grille d'évaluation, les requêtes non retenues et une liste de corrections priorisées.
Références
- Institut Baymard — Expérience utilisateur de la recherche en e-commerce : les 8 types de requêtes et les taux d’échec par type (mise à jour avril 2026)
- Institut Baymard — Ergonomie de la recherche en e-commerce : Rapport et analyse comparative
- Institut Baymard — 5 stratégies UX éprouvées pour les pages « Aucun résultat » (février 2025)
- Consortium Unicode — SpecialCasing.txt, règles de casse turques et azerbaïdjanaises
- Elastic — Analyseurs de langage, y compris la chaîne d'analyseurs turcs
- Elastic — Filtre de jetons de pliage ASCII et préservation de l'original
- Aide Google Analytics — Mesure améliorée, view_search_results et search_term
- Bonjour Retail — exemple de conversion multiple de recherche sur le site
