Construire une taxonomie de catalogue : catégories, synonymes et facettes sans profilage

Commencer par les situations réelles et le périmètre du catalogue

Avant de créer des catégories, listez les questions auxquelles le catalogue doit répondre : trouver un outil pour préparer un séjour, organiser le quotidien, communiquer, comparer une information ou gérer un logement. Chaque question doit pouvoir être comprise sans connaître l’organisation de l’éditeur. Une rubrique nommée d’après une équipe interne ou une technologie ne dit généralement rien du résultat attendu.

Fixez ensuite le périmètre. Le catalogue référence-t-il des applications, des sites d’information, des démonstrations, des services partenaires ou des documents ? Une même taxonomie ne doit pas masquer ces types de destination. Le type de surface, le statut public et la nécessité d’un compte sont des faits de registre ; ils peuvent devenir des facettes, mais pas des promesses ajoutées par le classement.

Pour chaque situation, faites un tri de cartes avec des mots ordinaires. Demandez à plusieurs profils où ils chercheraient une fiche et ce qu’ils attendent du libellé. Les désaccords révèlent les termes ambigus. Ils ne se résolvent pas en créant une catégorie par participant : documentez le concept commun, ses synonymes et les cas exclus.

1. Définir les objets réellement référencés.
2. Recueillir les questions de recherche des publics prévus.
3. Regrouper les situations qui poursuivent le même résultat.
4. Nommer chaque groupe avec un terme autonome et compréhensible.
5. Tester le classement avec des fiches réelles et des cas limites.
6. Conserver les désaccords comme décisions à documenter.

Donner à chaque concept une fiche stable

Une catégorie ne devrait pas être une simple chaîne de caractères répétée dans le code. Sa fiche minimale contient un identifiant stable, un libellé préféré, une définition, une note de périmètre, les termes admis pour la recherche, un statut et une version. L’identifiant ne change pas quand la rédaction améliore le libellé. Une URL ou une API peut ainsi continuer à reconnaître le concept pendant une transition éditoriale.

Le libellé préféré est celui affiché dans la langue considérée. Un libellé alternatif accueille un synonyme ou un acronyme réellement employé. Un libellé caché peut corriger une faute fréquente dans la recherche sans l’afficher comme terme recommandé. La définition dit ce qui rassemble les fiches ; la note de périmètre précise ce qui reste dehors. Deux concepts ne doivent pas partager le même libellé préféré dans un même contexte sans explication.

Le statut distingue au minimum brouillon, actif et retiré. La version et la date permettent de reproduire un classement. La source peut être une norme, un registre produit ou une décision éditoriale. Une catégorie active doit avoir un propriétaire de maintenance, mais ce propriétaire ne devient pas l’autorité des capacités des applications.

Relier les concepts sans fabriquer un arbre impossible

Une relation plus large place un concept dans un contexte général ; une relation plus précise conduit vers un sous-ensemble. Une relation associée relie deux concepts proches sans prétendre que l’un contient l’autre. Par exemple, “préparer un déplacement” peut être plus large que “choisir un itinéraire”, tandis que “accessibilité du trajet” peut être associée si elle traverse plusieurs branches.

Certaines fiches appartiennent légitimement à plusieurs branches. Cette polyhiérarchie doit rester rare et justifiée par le sens, pas par la volonté d’exposer partout le même produit. Évitez les cycles : si A est plus large que B, B ne peut pas redevenir plus large que A par une chaîne indirecte. Un contrôle automatique simple doit détecter ce défaut avant publication.

Limitez la profondeur. Trois niveaux clairs valent souvent mieux qu’une arborescence savante dans laquelle une application disparaît. Les collections éditoriales temporaires — “à découvrir”, “nouveautés” ou sélection saisonnière — ne sont pas forcément des concepts durables. Elles peuvent regrouper des fiches sans modifier la taxonomie.

• Une relation hiérarchique exprime un sens, pas un ordre d’écran.
• Une association ne crée pas un parent supplémentaire.
• Un concept orphelin doit être rattaché, documenté ou retiré.
• Un cycle bloque la publication de la version concernée.
• Une collection temporaire conserve une date de fin.

Séparer catégories et facettes

Une catégorie répond surtout à “de quoi s’agit-il ?” ou “à quel besoin cela répond-il ?”. Une facette filtre selon une propriété indépendante et observable : type de destination, compte requis, mode hors ligne, public, langue, plateforme ou statut. Croiser plusieurs facettes permet de réduire un ensemble sans créer une catégorie composée pour chaque combinaison.

Les valeurs de facette proviennent du registre public et de preuves datées. Si l’état hors ligne n’est pas qualifié, la valeur doit rester inconnue plutôt que devenir “oui” par déduction. Le filtre “sans compte” ne doit inclure que les parcours réellement consultables sans compte ; une démo anonyme ne prouve pas que l’application métier l’est aussi.

Évitez les facettes subjectives telles que “meilleur”, “facile” ou “pour vous” lorsqu’aucun critère public reproductible ne les définit. Elles ressemblent à une recommandation mais cachent la décision. Préférez des propriétés explicites, accompagnées de leur définition et, lorsque nécessaire, de la date de vérification.

Traiter synonymes, acronymes et langues sans fusionner les sens

Les visiteurs n’emploient pas toujours le terme choisi par l’éditeur. Une recherche utile reconnaît les variantes orthographiques, les acronymes et les synonymes documentés. Elle continue pourtant d’afficher le libellé préféré afin de stabiliser la compréhension. Un terme alternatif n’est pas une seconde catégorie et ne doit pas produire des compteurs incohérents.

Deux mots proches ne sont pas automatiquement équivalents. “Annuaire”, “catalogue” et “portail” peuvent décrire des responsabilités différentes ; “application” peut désigner une page Web, une PWA ou un logiciel distribué. Conservez des concepts séparés lorsque la distinction change l’action ou la preuve attendue, puis reliez-les par une note ou une association.

Pour plusieurs langues, rattachez chaque traduction au même identifiant seulement si le concept est réellement équivalent. Une traduction littérale qui change le périmètre devient un terme distinct ou reste à revoir. La langue du libellé, la date de validation et la personne responsable doivent être connues. Le repli vers le français est explicite, jamais présenté comme une traduction complète.

Rendre filtres et navigation accessibles

L’ordre des catégories doit rester cohérent d’une page à l’autre. Les intitulés de sections et de contrôles décrivent leur but ; une icône seule ne suffit pas. Un filtre au clavier garde un focus visible, annonce son état sélectionné et permet d’effacer facilement les choix. Sur petit écran, le panneau ne doit ni piéger le focus ni cacher le nombre de résultats.

Chaque mise à jour de résultats annonce un bilan compréhensible, sans déplacer brutalement le focus. Un état vide explique quels filtres ont produit zéro résultat et propose de les retirer. Les compteurs sont du texte accessible, pas une information transmise seulement par la couleur. Les liens conservent des intitulés distinctifs hors contexte.

Les critères WCAG 2.2 offrent le cadre général, notamment pour la cohérence de la navigation, les titres et libellés, le clavier, le focus et les messages de statut. La conformité ne se déduit pas de la taxonomie : elle se teste sur le composant réellement rendu, avec zoom, clavier et technologie d’assistance.

1. Parcourir toutes les catégories au clavier.
2. Vérifier le nom accessible de chaque filtre.
3. Sélectionner plusieurs facettes puis les effacer.
4. Contrôler l’annonce du nombre de résultats.
5. Tester un résultat vide et une valeur inconnue.
6. Vérifier les libellés à 200 % de zoom et sur écran étroit.

Classer sans profiler

Une taxonomie publique fonctionne avec les métadonnées des fiches. Le navigateur peut conserver temporairement les filtres de la session sans envoyer l’historique à un serveur. Des favoris facultatifs peuvent rester locaux. Ni la construction des catégories ni leur affichage n’exigent l’identité, les données métier des produits ou le suivi des ouvertures individuelles.

La minimisation recommandée par la CNIL consiste à ne traiter que les données adéquates, pertinentes et nécessaires à la finalité. Ici, la finalité de filtrage peut être satisfaite avec les propriétés publiques du catalogue et les choix explicites du moment. Déduire une situation familiale, une santé, une précarité ou une préférence sensible à partir des catégories consultées créerait une autre finalité et un risque sans utilité pour le classement.

Si une personnalisation est ajoutée un jour, elle reste distincte : activation explicite, explication des signaux, durée limitée, possibilité de corriger ou d’effacer, fonctionnement de base sans profil. Un intitulé comme “pour vous” doit dire pourquoi un résultat apparaît. My DOHM n’a pas besoin de lire les données des applications pour orienter vers elles.

• Métadonnées publiques comme source du classement.
• État de filtre local et éphémère par défaut.
• Pas de collecte de recherches pour faire fonctionner la taxonomie.
• Aucune inférence sensible à partir des catégories.
• Personnalisation facultative, explicable et révocable.
• Accès direct aux produits conservé.

Versionner et gouverner les changements

Une proposition de changement précise le problème observé, les concepts touchés, les fiches affectées et le comportement attendu. Le responsable éditorial décide du vocabulaire ; les propriétaires produits confirment les faits utilisés pour classer leurs fiches. La modification reçoit un numéro de version et une date, puis passe par une prévisualisation avant publication.

Renommer un libellé ne nécessite pas un nouvel identifiant. Fusionner deux concepts exige au contraire une table d’alias, une destination choisie et le traitement des anciennes URL. Scinder un concept demande une règle de reclassement ; aucune fiche ne doit être répartie automatiquement si le registre ne contient pas l’information nécessaire. Un concept retiré reste reconnaissable pour les liens historiques, mais n’apparaît plus comme choix actif.

Les contrôles de qualité cherchent doublons, libellés vides, concepts orphelins, cycles, relations vers des identifiants inconnus et fiches sans catégorie. Ils comparent également les compteurs de l’interface avec le registre. Le rollback restaure ensemble le vocabulaire, les rattachements et les URL ; revenir seulement sur le texte pourrait laisser un classement incohérent.

1. Ouvrir une proposition motivée et bornée.
2. Mesurer les fiches, liens et filtres affectés.
3. Valider les faits avec les autorités compétentes.
4. Prévisualiser la nouvelle version et ses alias.
5. Exécuter les contrôles structurels et d’accessibilité.
6. Publier vocabulaire et rattachements dans le même lot.
7. Conserver la version précédente pour rollback.

Cas concret : un petit catalogue sans données individuelles

Un catalogue générique contient des outils pour préparer un déplacement, organiser un logement et communiquer. Il crée trois catégories de besoin aux identifiants stables. “Trajet” devient un libellé alternatif de “Préparer un déplacement”, mais “Réserver un transport” reste absent si aucune fiche ne prouve cette fonction.

Le registre fournit ensuite trois facettes indépendantes : consultation sans compte, capacité hors ligne et type de destination. Une personne choisit “Préparer un déplacement” puis “sans compte”. Le navigateur calcule le résultat à partir des métadonnées publiques ; le serveur n’a pas besoin de connaître son identité ni de mémoriser sa recherche.

Une fiche n’ayant pas de preuve hors ligne affiche “information non qualifiée” et n’est pas incluse dans le filtre positif. Si la catégorie est plus tard renommée “Organiser un déplacement”, l’identifiant et l’ancien alias de recherche restent stables. Une URL historique redirige vers la page canonique sans transmettre les filtres personnels.

Recette avant publication

Testez d’abord chaque concept avec au moins une fiche qui doit entrer et une qui doit rester dehors. Vérifiez ensuite les combinaisons de facettes, notamment zéro résultat, valeur inconnue et fiche appartenant à deux catégories. La recherche doit retrouver les synonymes sans afficher de doublon. Les anciennes URL et les alias doivent conduire à une destination canonique unique.

La recette éditoriale lit définitions et notes sans le contexte de l’équipe. La recette technique valide les identifiants, relations et compteurs. La recette d’accessibilité contrôle clavier, focus, zoom, lecteur d’écran et messages de statut. Une campagne courte sur les changements suffit ; il n’est pas utile de rejouer les parcours applicatifs que la taxonomie ne modifie pas.

Après publication, contrôlez la version servie, une catégorie, une combinaison de facettes et le rollback. Une erreur critique — résultat trompeur, boucle de navigation ou perte d’accès — justifie le retour immédiat à la version précédente.

• Définitions compréhensibles hors contexte.
• Aucun doublon de libellé préféré ambigu.
• Aucun cycle ni concept orphelin.
• Synonymes trouvables sans seconde catégorie.
• Valeurs inconnues conservées comme telles.
• État vide et effacement des filtres accessibles.
• URL canonique et alias vérifiés.
• Version précédente restaurable.

Ce que My DOHM peut et ne peut pas faire

My DOHM peut publier une taxonomie versionnée, classer des fiches à partir de leur registre et proposer des filtres sur des faits prouvés. Il peut conserver des alias pour la recherche et documenter les changements. Cette responsabilité éditoriale ne lui donne pas autorité sur les comptes, rôles, données métier ou capacités internes des applications.

Le site-guide explique la méthode de façon autonome. Il ne prétend pas que le catalogue actuel synchronise des favoris, personnalise les résultats ou mesure les usages. Ces fonctions restent absentes des promesses tant qu’un parcours public réel n’a pas été qualifié.

Une taxonomie n’est jamais définitive. Elle reste utile si ses concepts sont compréhensibles, ses sources visibles, ses modifications réversibles et son fonctionnement possible sans surveillance individuelle.

Checklist synthétique

• Périmètre et publics du catalogue définis.
• Concepts issus de situations réelles, pas de l’organigramme.
• Identifiants stables et libellés versionnés.
• Synonymes distingués des concepts différents.
• Relations plus larges, plus précises et associées contrôlées.
• Catégories séparées des facettes observables.
• Valeurs sourcées dans le registre, inconnues non inventées.
• Filtres utilisables au clavier et résultats annoncés.
• Classement opérationnel sans identité ni historique.
• Changements gouvernés, aliasés et réversibles.
• Recette sur cas positifs, exclusions et état vide.
• Limites de My DOHM publiées sans surpromesse.