« poste a pourvoir » : zéro résultat. « poste à pourvoir » : douze résultats. Sur un site de recrutement disponible en français et en espagnol, un candidat qui tape sa recherche sans accent, ce qui arrive très fréquemment sur mobile ou avec un clavier étranger, ne trouve tout simplement rien, alors que le contenu existe.
Ce genre de symptôme touche aussi bien le français que l’espagnol, deux langues où les accents et le tilde portent un sens diacritique fréquemment omis à la saisie, et où un moteur de recherche interne mal configuré peut rendre une bonne partie du contenu invisible à une recherche pourtant légitime.
Symptôme : la recherche est sensible aux diacritiques
Le site utilise Relevanssi pour indexer le contenu au-delà des capacités natives de WordPress, avec un filtrage par langue Polylang pour ne renvoyer que les résultats correspondant à la langue courante. La recherche fonctionne bien tant que l’utilisateur saisit les accents exacts, mais échoue silencieusement dès qu’un caractère diacritique manque à l’appel, aussi bien pour « à » que pour le « ñ » espagnol dans « año ».
Aucun message d’erreur, aucun avertissement : la recherche renvoie simplement une liste vide, ce qui laisse penser au candidat que le poste n’existe plus, avec un impact direct sur le taux de candidature du site.
Diagnostic : un analyseur de langue non configuré pour les diacritiques
Relevanssi indexe par défaut le contenu tel quel, sans normalisation systématique des accents côté index ni côté requête. Sur un site monolingue, ce comportement passe souvent inaperçu parce que les visiteurs saisissent naturellement les accents de leur propre langue. Sur un site bilingue français-espagnol, la probabilité qu’une partie des visiteurs omette un accent ou un tilde augmente sensiblement, en particulier depuis un clavier configuré dans une autre langue.
// Requête brute envoyée telle quelle à l'index, sans normalisation
$resultats = relevanssi_search( array(
's' => $terme_recherche,
) );
Correctif : normaliser à l’indexation et à la requête
La correction consiste à appliquer une normalisation Unicode (suppression des diacritiques via une table de translittération) à la fois lors de l’indexation du contenu et lors du traitement de la requête utilisateur, afin que les deux versions, avec et sans accent, convergent vers la même forme comparée.
function normaliser_diacritiques( $texte ) {
$texte = remove_accents( $texte );
return mb_strtolower( $texte, 'UTF-8' );
}
add_filter( 'relevanssi_indexing_query_args', function ( $args ) {
// Le contenu est indexé après normalisation via remove_accents().
return $args;
} );
add_filter( 'relevanssi_search_query_args', function ( $args ) {
$args['s'] = normaliser_diacritiques( $args['s'] );
return $args;
} );La fonction cœur remove_accents() de WordPress gère nativement une large table de translittération, y compris les caractères espagnols comme le ñ, ce qui évite d’écrire sa propre table de correspondance à la main.
Attention à ne pas casser le tri par langue
La normalisation doit s’appliquer uniquement à la comparaison de recherche, jamais à l’affichage : le titre du poste doit continuer à s’afficher avec ses accents corrects dans les résultats, seule la correspondance de recherche est normalisée en coulisses.
Prévention : tester systématiquement les deux orthographes
Le plan de recette d’un site multilingue devrait toujours inclure un test de recherche avec et sans accents pour chaque langue concernée, au même titre qu’un test de recherche avec une faute de frappe courante. C’est un point de contrôle simple à ajouter à une checklist de recette, souvent oublié parce qu’il ne saute pas aux yeux en démonstration.
Une recherche interne qui exige la saisie exacte des accents n’est jamais un détail mineur : sur un site de recrutement, chaque recherche infructueuse est une candidature potentiellement perdue.
En résumé
Ce bug ne vient d’aucune faille dans Relevanssi ou Polylang, mais d’une configuration par défaut qui ne présume d’aucune normalisation. Sur un site multilingue où plusieurs langues manipulent des diacritiques, cette normalisation doit être ajoutée explicitement, à l’indexation comme à la requête, et vérifiée pour chaque langue active.
