Un agent général peut-il vraiment être rattaché à deux départements à la fois ? Cette question, posée par un réseau d’assurance lors de la conception de son annuaire d’agents, a orienté tout le choix de structuration des données : certains agents généraux couvrent effectivement plusieurs départements limitrophes, ce qui excluait d’emblée un simple champ texte à valeur unique.
La réponse retenue s’appuie sur une taxonomie personnalisée plutôt qu’un champ de sélection classique, avec un filtre côté client qui évite tout rechargement de page lors du changement de département. Voici la construction complète de cet annuaire, pensé pour un thème classique.
Une taxonomie département, pas un champ texte
La taxonomie departement est déclarée sur le type de contenu agent_general, avec les quatre-vingt-seize départements de métropole préenregistrés comme termes lors de l’activation du thème, via une boucle sur un tableau statique associant code et nom de département.
register_taxonomy( 'departement', 'agent_general', array(
'label' => 'Départements',
'hierarchical' => false,
'public' => true,
'show_in_rest' => true,
) );
add_action( 'after_switch_theme', function () {
foreach ( liste_departements_france() as $code => $nom ) {
if ( ! term_exists( $nom, 'departement' ) ) {
wp_insert_term( $nom, 'departement', array( 'slug' => $code ) );
}
}
} );Un agent couvrant plusieurs départements se voit simplement attribuer plusieurs termes de cette taxonomie, sans aucune contrainte technique supplémentaire à gérer côté thème.
Le filtre côté client, sans rechargement de page
Plutôt que de recharger la page à chaque changement de département sélectionné, le filtre s’appuie sur l’API REST de WordPress, interrogée en JavaScript natif au moment où le visiteur choisit un département dans une liste déroulante.
const selecteur = document.querySelector('#filtre-departement');
selecteur.addEventListener('change', async (evenement) => {
const terme = evenement.target.value;
const reponse = await fetch(`/wp-json/wp/v2/agent_general?departement=${terme}&_fields=id,title,link,acf`);
const agents = await reponse.json();
afficherAgents(agents);
});Le paramètre _fields restreint la réponse aux seules propriétés utilisées par l’affichage, évitant de transférer l’intégralité du contenu de chaque fiche agent à chaque filtrage — un détail qui allège sensiblement le poids des réponses sur un annuaire qui compte plusieurs centaines d’entrées.
Rendre la taxonomie interrogeable depuis l’API REST
Par défaut, une taxonomie personnalisée n’expose pas automatiquement de paramètre de requête REST portant son nom : il faut le déclarer explicitement lors de l’enregistrement, via l’argument rest_base combiné à une vérification que show_in_rest est bien actif, faute de quoi le paramètre departement utilisé plus haut serait silencieusement ignoré par l’API.
Le rendu initial, sans JavaScript, pour le premier chargement
Pour ne pas dépendre entièrement du JavaScript à l’affichage initial (accessibilité, référencement, dégradation gracieuse), la page d’archive du type de contenu agent_general affiche déjà, côté serveur, l’ensemble des agents via une boucle WP_Query classique. Le filtre JavaScript ne fait ensuite que remplacer ce contenu initial une fois qu’un département est sélectionné.
- Premier affichage entièrement côté serveur, avec tous les agents visibles sans JavaScript.
- Filtrage ultérieur entièrement côté client, sans rechargement complet de la page.
- Une URL avec paramètre
?departement=reste également gérée côté serveur, pour permettre le partage d’un lien filtré.
Gérer la carte des départements limitrophes
Un agent rattaché au 92 doit souvent apparaître également pour un visiteur qui recherche le 75, en raison de la proximité géographique. Plutôt que de complexifier la logique de filtrage, ce cas est traité simplement en attribuant directement le second département comme terme supplémentaire lors de la saisie de la fiche agent, décision confirmée par le réseau après une phase de test.
Une taxonomie reste toujours préférable à un champ texte libre dès qu’une même fiche peut légitimement appartenir à plusieurs catégories : le filtrage, l’affichage et l’exposition via l’API REST en deviennent naturellement plus simples.
En résumé
Cet annuaire repose sur une architecture volontairement simple : une taxonomie fidèle à la réalité du métier plutôt qu’un champ contraint, un rendu initial accessible sans JavaScript, et un filtrage ensuite délégué à l’API REST native de WordPress. Aucune extension de recherche ni de filtrage n’a été nécessaire pour couvrir ce besoin.
