Vingt-trois offres d’emploi affichées d’un bloc, avec quatre filtres qui se combinent sans recharger la page : c’est le cahier des charges qu’une petite agence de recrutement a posé sur la table, en précisant d’emblée ce qu’elle ne voulait pas — un jobboard complet, avec compte candidat, dépôt de CV et suivi de candidature. Elle avait déjà un outil séparé pour ça ; il fallait juste un affichage vitrine, filtrable, sur le site public.
Le choix s’est porté sur un type de contenu personnalisé simple, « offre_emploi », associé à deux taxonomies (« métier » et « ville »), et un bloc dynamique qui charge l’ensemble des offres publiées en une seule requête, puis laisse le filtrage se faire entièrement côté client.
Poser le type de contenu et les taxonomies
La déclaration du CPT reste volontairement minimale, sans champ de candidature ni statut de traitement :
register_post_type( 'offre_emploi', array(
'label' => 'Offres d\'emploi',
'public' => true,
'show_in_rest' => true,
'supports' => array( 'title', 'editor', 'custom-fields' ),
'has_archive' => false,
) );
register_taxonomy( 'metier', 'offre_emploi', array(
'label' => 'Métier',
'show_in_rest' => true,
'hierarchical' => false,
) );
register_taxonomy( 'ville_offre', 'offre_emploi', array(
'label' => 'Ville',
'show_in_rest' => true,
'hierarchical' => false,
) );
Le paramètre show_in_rest est indispensable ici : le bloc s’appuie sur l’API REST pour récupérer les offres avec leurs taxonomies associées, sans requête SQL personnalisée.
Charger toutes les offres, filtrer sans rechargement
Contrairement à un jobboard qui paginerait ses résultats côté serveur, le volume ici reste modeste (une trentaine d’offres actives au maximum), ce qui permet de tout charger en un seul appel puis de filtrer en JavaScript :
const { offres } = wp.data.select( 'core' ).getEntityRecords( 'postType', 'offre_emploi', {
per_page: 100,
_embed: true,
} );
function filtrerOffres( offres, filtres ) {
return offres.filter( ( offre ) => {
return ( ! filtres.metier || offre.metier.includes( filtres.metier ) )
&& ( ! filtres.ville || offre.ville_offre.includes( filtres.ville ) )
&& ( ! filtres.contrat || offre.meta.type_contrat === filtres.contrat );
} );
}
Un rendu pensé pour un rédacteur non technique
L’agence n’avait aucune personne technique en interne pour publier les offres. Le bloc côté éditeur devait donc rester simple : un champ titre, un éditeur de texte classique pour la description, trois listes déroulantes pour les taxonomies, et un champ personnalisé pour la durée du contrat. Aucun réglage avancé n’est exposé dans le panneau latéral du bloc, pour éviter toute confusion.
La combinaison des filtres, un point d’attention
Quatre filtres combinables signifient que l’utilisateur peut chercher « développeur » à « Nantes » en CDI de plus de six mois, et obtenir un résultat vide si aucune offre ne correspond. Le bloc affiche alors un message explicite plutôt qu’une liste silencieusement absente :
- Un message « Aucune offre ne correspond à ces critères » remplace la liste vide ;
- Un bouton « Réinitialiser les filtres » reste visible en permanence ;
- Le nombre d’offres correspondantes s’affiche en continu au-dessus de la liste, pour donner un retour immédiat à chaque clic.
Ce que le bloc ne fait pas, volontairement
Aucune candidature ne transite par ce bloc. Un simple lien mailto ou un lien vers le formulaire de contact du site suffisait pour rediriger un candidat intéressé, l’agence traitant ensuite la suite du processus via son outil métier existant. Ce choix a évité tout développement de formulaire, de stockage de CV ou de suivi de statut, qui aurait multiplié la complexité pour un besoin qui restait, au fond, un simple affichage vitrine.
Le résultat après trois mois d’utilisation
L’agence a continué à publier ses offres elle-même, sans assistance technique après la mise en place initiale. Le filtrage côté client s’est révélé suffisant pour un volume d’offres qui n’a jamais dépassé la trentaine simultanée ; au-delà, une pagination côté serveur aurait probablement dû être envisagée, mais ce cas ne s’est pas présenté.
Un bloc de liste filtrable n’a pas besoin d’un jobboard complet derrière lui : il a besoin d’un CPT propre, de taxonomies bien pensées, et d’un filtrage qui reste rapide tant que le volume de contenu reste raisonnable.
En résumé
Pour une agence de recrutement qui ne voulait ni compte candidat ni suivi de candidature, un bloc de liste filtrable adossé à un CPT simple et deux taxonomies a suffi à répondre au besoin réel : donner de la visibilité aux offres, permettre un filtrage rapide, et laisser la suite du processus de recrutement à l’outil métier déjà en place.
