Architecture publique de l'information¶

Statut¶

CONTRACT / DESIGN DE RÉFÉRENCE.

Ce document explique les principes qui doivent guider l'organisation publique de CMonChoix : intentions utilisateur, pages canoniques, navigation, SEO et place des marchands.

Il ne remplace pas la source exécutable CURRENT de navigation, qui est :

plugins/ccx-feeds-industrial/includes/application/navigation-architecture.php

via :

ccx_navigation_architecture_registry()

Si ce document et le registre PHP divergent sur une catégorie ou un slug réellement exposé, le registre exécutable doit être considéré comme l'état CURRENT à diagnostiquer, tandis que cette page conserve le rôle de contrat d'architecture publique.

Pourquoi cette page existe¶

La navigation publique ne doit pas être une copie de :

la taxonomie d'un marchand ;
la structure interne du Pipeline ;
la liste exhaustive des verticales ;
un sitemap SEO ;
les filtres techniques disponibles.

Elle doit représenter des intentions d'achat compréhensibles et stables.

Question structurante¶

Comment organiser le catalogue public pour qu'un utilisateur puisse trouver et comparer un produit sans dépendre de la structure interne des marchands ou du système ?

La réponse repose sur quelques invariants durables.

Invariants publics¶

Une identité produit possède une page canonique¶

Une identité produit ne doit pas être dupliquée simplement parce que l'état commercial change.

Par exemple, neuf, reconditionné et occasion sont des états d'offres. Ils ne doivent pas, par défaut, créer trois identités produit différentes.

Le Frontend consomme l'identité et ses offres ; il ne doit pas inventer une nouvelle identité pour simplifier l'affichage.

Les catégories suivent l'intention utilisateur¶

La catégorie publique doit répondre à la question « qu'est-ce que l'utilisateur cherche à acheter ? » plutôt qu'à une propriété technique secondaire.

Une technologie, une capacité, une couleur ou une marque relève généralement d'un filtre ou d'un attribut, pas d'un univers principal.

Une architecture publique peut contenir plus de destinations que le menu principal n'en affiche.

Le menu sert à orienter rapidement ; le sitemap, la recherche, les filtres et le maillage interne peuvent exposer une profondeur différente.

Aucun marchand ne gouverne l'arbre public¶

Les catégories marchandes sont des données source utiles à la classification, mais elles ne deviennent jamais automatiquement des catégories publiques.

Une nouvelle catégorie publique doit être justifiée par le produit, la demande utilisateur et la cohérence de l'architecture publique.

Une catégorie principale doit mériter son rôle¶

Une branche visible doit rester utile à la comparaison et suffisamment stable pour justifier sa présence dans l'architecture publique.

Les critères peuvent inclure :

intention utilisateur claire ;
profondeur de catalogue suffisante ;
plusieurs marchands ;
valeur de comparaison ;
potentiel éditorial et SEO ;
cohérence avec le positionnement CMonChoix.

Ces critères orientent la gouvernance ; ils ne doivent pas être transformés en score automatique dans le Frontend.

Source exécutable CURRENT¶

Le registre ccx_navigation_architecture_registry() contient actuellement la hiérarchie exécutable de long terme.

Il associe notamment :

un slug ;
un label ;
un ordre ;
des groupes ;
des feuilles ;
des verticales ;
parfois des accessory_types ou exclude_accessory_types.

Le registre peut contenir des feuilles futures qui restent invisibles tant que les données publiques ne satisfont pas leur contrat.

Cette distinction entre déclaration et visibilité Runtime est volontaire.

Arbre documentaire historique¶

Les anciennes versions de cette page et de public-navigation-tree.md contiennent des listes détaillées d'univers et de catégories v0.1/v1.0.

Elles restent utiles pour comprendre les décisions de design, mais elles ne doivent pas être recopiées comme vérité CURRENT sans comparaison avec le registre PHP.

Certaines branches ont évolué, d'autres ont été supprimées ou réorganisées.

Exemple vérifié dans le code CURRENT : le commentaire du registre indique explicitement que Jardin, mobilier, robots tondeuses et arrosage sont intentionnellement absents.

Pages publiques¶

Page univers¶

Une page univers organise une grande intention d'achat et oriente vers les principales familles de produits.

Elle peut présenter :

catégories importantes ;
marques pertinentes ;
guides ;
produits ou modèles représentatifs.

Elle ne doit pas recalculer la classification métier.

Page catégorie¶

Une page catégorie consomme une représentation de lecture déjà préparée.

Elle peut combiner :

modèles ou produits ;
filtres ;
marques ;
contenu éditorial ;
liens internes.

Les filtres ne doivent pas devenir des catégories canoniques par simple facilité de rendu.

Page produit¶

Une page produit représente une identité canonique et ses données projetées.

Elle peut afficher :

titre canonique ;
attributs ;
variantes ;
offres ;
marchands ;
prix ;
médias ;
produits similaires.

Elle ne doit pas reconstruire l'identité à partir des offres visibles.

SEO et architecture publique¶

L'architecture SEO doit suivre les surfaces publiques réellement gouvernées.

Un template SEO ne doit pas créer une arborescence parallèle pour obtenir plus de pages indexables.

Avant de créer une nouvelle surface publique, vérifier :

qu'elle correspond à une intention distincte ;
qu'elle ne duplique pas une page canonique existante ;
qu'elle possède un contrat de données stable ;
qu'elle ne dépend pas d'un marchand particulier ;
qu'elle peut rester cohérente lorsque les offres changent.

Ne pas confondre :

Navigation publique
= structure stable d'intentions d'achat

Filtres
= dimensions de sélection à l'intérieur d'une surface

Attributs
= informations décrivant le produit

États d'offre
= informations commerciales liées à une offre

Une marque, une technologie ou une capacité peut être extrêmement importante pour l'utilisateur sans devenir pour autant un nœud canonique de navigation.

Comment proposer une nouvelle catégorie¶

Une évolution sûre suit ce processus :

documenter l'intention utilisateur ;
observer la profondeur réelle des produits publics ;
vérifier qu'une catégorie existante ne couvre pas déjà le besoin ;
définir le contrat de classification ;
simuler l'impact sur les URLs et la navigation ;
modifier la source canonique exécutable ;
reconstruire les représentations dérivées si nécessaire ;
vérifier les surfaces publiques et les redirections.

Ne pas commencer par ajouter un lien dans le header.

Diagnostiquer une divergence entre documentation et site¶

Le site expose une catégorie absente du design¶

Vérifier le registre PHP et le Runtime avant de conclure à un bug documentaire.

La documentation peut être historique ; le code peut avoir évolué.

La documentation décrit une catégorie absente du site¶

Vérifier d'abord si elle existe encore dans ccx_navigation_architecture_registry().

Si oui, vérifier ensuite le contrat de visibilité et la présence de données publiques.

Si non, la page documentaire doit être reclassée ou mise à jour ; ne réintroduisez pas automatiquement la catégorie dans le code.

Une catégorie marchand semble meilleure¶

Ne pas la copier directement.

Elle constitue une évidence de classification parmi d'autres, pas l'autorité publique.

Ce que le Frontend ne doit jamais décider¶

Le Frontend ne doit pas :

fusionner deux catégories publiques ;
créer une page canonique à partir d'un filtre ;
dupliquer une identité selon l'état d'une offre ;
promouvoir une catégorie marchand ;
décider qu'une feuille future doit être activée ;
appliquer une logique de résolution d'identité.

Vérification après évolution¶

Contrôler au minimum :

source canonique PHP ;
slugs et labels ;
hiérarchie ;
URLs canoniques ;
visibilité avec et sans données publiques ;
absence de duplication avec filtres ou pages existantes ;
header ;
homepage ;
breadcrumbs ;
sitemap si concerné ;
redirections legacy éventuelles.