Catalogue de pièces agricoles trié par Data Views, côté back-office

« Les Data Views fournissent une interface unifiée pour parcourir, trier et filtrer des collections d’éléments dans l’administration », résume la documentation officielle du projet Gutenberg. Pour une coopérative agricole gérant plusieurs milliers de références de pièces détachées, cette interface introduite dans l’écosystème de l’éditeur de site est devenue le point de passage obligé avant toute publication vers le catalogue public.

Le besoin exprimé par la coopérative n’était pas d’afficher le catalogue au public autrement : c’était de donner à son équipe interne un outil de tri fiable pour repérer les références à corriger, à retirer ou à regrouper avant qu’elles ne remontent sur le site, sans dépendre d’un tableau Excel parallèle devenu ingérable.

L’architecture retenue

Le catalogue repose sur un type de contenu personnalisé piece_detachee, avec un statut personnalisé « à valider » distinct du statut « publié ». L’équipe interne travaille exclusivement sur les fiches au statut « à valider », dans un écran Data Views dédié, avant de les faire basculer en publication où elles deviennent visibles dans la Query Loop du catalogue public.

architecture-catalogue/
├── piece_detachee (type de contenu)
│   ├── statut : a_valider | publie
│   ├── taxonomie : categorie_machine
│   └── champs : reference, compatibilite, stock
├── ecran-data-views (back-office)
│   ├── vue « à valider » (filtrée par statut)
│   ├── vue « stock bas » (filtrée par champ stock)
│   └── vue « sans catégorie » (filtrée par taxonomie vide)
└── query-loop-catalogue (front-office)
    └── filtrée sur statut = publie uniquement

Configurer les vues Data Views

Chaque vue Data Views se configure comme une combinaison de champs affichés, de filtres actifs et de tri par défaut. Pour la coopérative, trois vues couvrent l’essentiel du travail quotidien de l’équipe catalogue : les fiches en attente de validation, les références en stock bas, et celles qui n’ont pas encore reçu de catégorie de machine compatible.

const vueStockBas = {
    type: 'table',
    fields: [ 'reference', 'compatibilite', 'stock' ],
    filters: [
        { field: 'stock', operator: 'lessThan', value: 10 },
    ],
    sort: { field: 'stock', direction: 'asc' },
};

Cette configuration s’appuie sur le composant DataViews du paquet @wordpress/dataviews, exploitable aussi bien dans l’écran natif de gestion des pages que dans un écran d’administration personnalisé construit pour ce type de contenu spécifique.

Ce que ça change au quotidien pour l’équipe

• Le tri par stock bas remplace l’ancien tableau partagé, mis à jour manuellement une fois par semaine.
• Le filtre « sans catégorie » évite qu’une référence reste invisible dans le catalogue public faute de taxonomie associée.
• Le passage du statut « à valider » à « publié » se fait directement depuis la vue, sans ouvrir chaque fiche individuellement.

Pourquoi ne pas tout faire dans la Query Loop publique

Mélanger logique de préparation interne et logique d’affichage public complique les deux. La Query Loop du catalogue n’a besoin de connaître qu’un seul filtre : le statut « publié ». Toute la complexité de tri, de détection d’anomalies et de préparation reste confinée à l’écran Data Views, invisible du visiteur et sans impact sur les performances de la page publique.

Un bon catalogue public commence toujours par un bon écran de tri en coulisses : c’est là que se joue la qualité des données, pas dans la mise en page finale.

Limites de cette architecture

Data Views reste un outil de gestion interne : il ne remplace pas une recherche publique performante sur un volume important de références. L’affichage public du catalogue, avec ses propres besoins de pagination et de filtrage côté visiteur, relève d’un chantier distinct, construit sur la Query Loop plutôt que sur Data Views.

Notre verdict

Pour une coopérative agricole qui gère un catalogue de références en constante évolution, séparer clairement l’écran de préparation interne, construit avec Data Views, de l’affichage public porté par une Query Loop, évite que la complexité de l’un ne contamine la simplicité nécessaire de l’autre. Cette séparation architecturale, plus que la technologie elle-même, fait la différence sur la durée.