Filtres de catalogue : retrouver sa sélection après un retour en arrière

Un visiteur choisit une catégorie, précise une dimension et trie les produits. Il ouvre une fiche, puis appuie sur « Précédent ». Le catalogue réapparaît sans ses critères. Il doit refaire sa sélection avant de poursuivre.

Ce petit parcours mérite un essai avant de valider un site. Pour une PME, conserver une recherche compréhensible facilite aussi les échanges : un commercial peut transmettre une sélection à un client, et un collègue peut retrouver la liste qu’on lui décrit. Voici les choix à prévoir avec votre prestataire. Les situations proposées sont fictives et ne décrivent pas des résultats clients.

Définir ce qui doit être retrouvé

Commencez par écrire l’état attendu de la liste : catégorie, filtres sélectionnés, ordre de tri et page affichée. Ajoutez la position dans la liste si elle compte pour le parcours. Une personne revenue d’une fiche ne devrait pas devoir deviner quels critères restent actifs.

Dans un catalogue fictif de fournitures, le visiteur choisit « Fixations », un matériau et un diamètre. Au retour, les contrôles doivent montrer ces valeurs et les produits affichés doivent leur correspondre. Conserver seulement les cases cochées, tout en rechargeant le catalogue complet, créerait une incohérence.

Distinguez aussi la sélection appliquée de celle qui est encore en cours de préparation. Sur mobile, un panneau de filtres peut proposer « Appliquer » et « Annuler ». Dans ce cas, fermer le panneau ne devrait pas valider silencieusement des modifications. Décidez ce comportement dès la maquette, puis testez-le.

Préparer une adresse qui décrit la sélection

Pour une sélection publique que l’on souhaite partager, les paramètres de l’adresse peuvent représenter les critères. Par exemple, un chemin fictif comme /catalogue?categorie=fixations&matiere=inox&tri=reference décrit une intention lisible. Ce format doit être défini par l’application, avec des valeurs reconnues.

L’interface URLSearchParams du navigateur fournit des méthodes pour lire et modifier ces paramètres. Elle permet notamment de gérer plusieurs valeurs portant le même nom et de sérialiser les paramètres pour une URL. Elle ne décide pas quels filtres votre métier autorise. Documentation MDN sur URLSearchParams.

Demandez un test simple : copier l’adresse après avoir appliqué les filtres, puis l’ouvrir dans un nouvel onglet. La sélection doit être reconstruite à partir de cette adresse. Vérifiez aussi le rechargement complet de la page. Une liste qui fonctionne seulement après plusieurs clics dans la session initiale ne constitue pas encore une sélection partageable.

L’adresse représente des critères, pas une photographie immuable du catalogue. Si un produit est retiré ou si ses caractéristiques changent, la même sélection peut retourner d’autres résultats. Pour un devis ou une proposition commerciale engageante, définissez séparément le document ou la version à conserver.

Donner un sens aux boutons Précédent et Suivant

Une interface peut mettre à jour la liste sans charger une nouvelle page. Le navigateur doit alors disposer d’un historique cohérent. MDN explique que pushState ajoute une entrée d’historique, tandis que replaceState modifie l’entrée courante. L’événement popstate permet à l’application de réagir à certains déplacements dans cet historique. Guide MDN sur la History API.

La règle produit reste à choisir. Nous recommandons de traiter une sélection explicitement appliquée comme une étape identifiable. À l’inverse, enregistrer chaque lettre saisie dans un filtre peut obliger le visiteur à appuyer de nombreuses fois sur « Précédent » pour quitter la page.

Faites démontrer un aller-retour complet : sélection initiale, nouvelle sélection, ouverture d’une fiche, retour au catalogue, puis navigation vers l’avant. À chaque étape, comparez trois éléments : adresse, contrôles et résultats. Leur cohérence compte davantage que le simple changement de l’URL.

Traiter les adresses anciennes ou modifiées

Un lien conservé dans un favori peut contenir une catégorie supprimée, un ancien nom de filtre ou un numéro de page qui n’existe plus. Préparez une réponse explicite au lieu de laisser un écran trompeur.

Pour notre catalogue fictif, l’interface pourrait indiquer qu’un critère n’est plus disponible et proposer de le retirer. Si un changement de filtre ramène volontairement à la première page, ce choix doit être cohérent avec les résultats affichés et l’adresse. Une sélection vide doit rester modifiable sans effacer tous les critères à l’insu du visiteur.

Côté serveur, les paramètres reçus doivent être vérifiés : noms acceptés, valeurs possibles et limites de pagination. Un paramètre modifié à la main ne doit pas permettre d’accéder à des produits réservés à un autre client. Les contrôles d’accès restent nécessaires, que les critères viennent d’un bouton ou d’un lien copié.

Garder les informations privées hors des liens publics

Avant de rendre une sélection partageable, examinez ce que contient l’adresse. OWASP rappelle que des données placées dans les paramètres d’une URL peuvent se retrouver notamment dans l’historique du navigateur et les journaux techniques. HTTPS ne suffit pas à supprimer ces traces. Analyse OWASP sur l’exposition de données dans les URL.

Une catégorie de produit publique peut convenir. Le nom d’un client, une note interne ou un secret d’accès ne devraient pas être ajoutés à un lien de catalogue par facilité. Pour une vue privée, prévoyez un mécanisme adapté, avec authentification et autorisations vérifiées à l’ouverture. Un bouton « Copier le lien » doit annoncer clairement ce que le destinataire pourra consulter.

Vérifier le parcours au clavier et sur téléphone

Chaque filtre doit avoir un intitulé compréhensible. Après application, les critères actifs doivent rester repérables, y compris lorsque le panneau mobile est fermé. Prévoir une action pour retirer un seul critère et une autre pour tout réinitialiser évite de confondre ces deux intentions.

Si la liste se met à jour sans changement de page, faites vérifier l’annonce du message de résultat avec un lecteur d’écran. Le W3C distingue le message indiquant la fin ou le résultat d’une recherche de la liste des résultats elle-même. W3C : comprendre les messages de statut.

Évitez de déplacer inutilement le focus lors d’un changement de filtre. Vérifiez que la personne peut poursuivre sa sélection, ouvrir un résultat et revenir sans perdre le contrôle du parcours.

Une recette courte avant mise en ligne

Demandez une démonstration avec des produits de test :

• appliquer plusieurs critères, ouvrir une fiche et revenir ;
• recharger la liste filtrée et ouvrir son adresse dans un nouvel onglet ;
• parcourir plusieurs étapes avec Précédent et Suivant ;
• modifier puis annuler une sélection dans le panneau mobile ;
• ouvrir une adresse contenant un critère retiré ou une page inexistante ;
• tester une combinaison vide, puis retirer un seul filtre ;
• vérifier les droits avec un autre compte et sans connexion ;
• refaire le parcours au clavier et contrôler les messages de résultat.

Conservez les critères attendus pour chaque essai. Vous disposerez d’un contrôle réutilisable lors d’une refonte ou d’un changement de moteur de catalogue : la personne doit retrouver une sélection compréhensible, pouvoir la modifier et savoir ce que son lien partage réellement.