is_rtl() répond à une question précise : la locale actuellement active s’écrit-elle de droite à gauche ? La fonction, présente dans le cœur de WordPress depuis longtemps, renvoie un booléen basé sur la propriété text_direction de la locale en cours. Rien de plus, rien de moins. C’est cette simplicité qui, sur le thème audité un an après sa mise en production, s’est révélée être une source de confusion silencieuse.
L’audit de code a été déclenché par un motif banal : un développeur reprenant la maintenance de ce thème vieux de sept ans avait remarqué un bloc conditionnel utilisant is_rtl() à un endroit qui n’avait, à première vue, aucun rapport avec la direction d’écriture. Cette observation isolée a justifié une recherche systématique de toutes les occurrences de la fonction dans la base de code.
Ce que fait réellement is_rtl()
La documentation officielle du cœur est claire : is_rtl() détermine si le texte de la locale en cours s’écrit de droite à gauche, comme l’arabe ou l’hébreu. Elle sert typiquement à charger une feuille de style spécifique (style-rtl.css) ou à ajuster des propriétés de mise en page dépendant du sens d’écriture.
if ( is_rtl() ) {
wp_enqueue_style( 'theme-rtl', get_template_directory_uri() . '/style-rtl.css' );
}
Ce cas d’usage, documenté et attendu, n’est pas celui qui posait problème sur ce thème. Le souci venait de trois autres endroits, où la fonction avait été utilisée comme un raccourci pour une tout autre question.
Premier usage détourné : distinguer le français de l’anglais
Le premier cas retrouvé utilisait is_rtl() pour choisir entre deux mises en page de pied de page, sur un site alors bilingue français / anglais :
if ( ! is_rtl() ) {
get_template_part( 'template-parts/footer', 'fr-en' );
}
Le raisonnement du développeur d’origine, retrouvé après discussion avec l’équipe encore présente, était que ni le français ni l’anglais ne s’écrivent de droite à gauche, donc is_rtl() renvoyait toujours false pour ces deux langues, et la condition semblait « fonctionner ». Le problème est apparu bien plus tard, quand une troisième langue candidate à l’ajout, l’arabe, a été évoquée en réunion : ce code aurait alors silencieusement basculé vers un comportement jamais testé pour cette langue, non pas parce que le sens d’écriture le justifiait vraiment dans ce contexte précis, mais par effet de bord d’une condition qui n’avait jamais eu vocation à distinguer autre chose que le sens d’écriture.
Deuxième usage : un contournement de cache
Le deuxième cas était plus surprenant encore. Une extension de cache de page, mal configurée à l’origine, servait parfois une version en cache incorrecte lors du changement de langue. Un développeur avait ajouté ce correctif temporaire :
if ( is_rtl() ) {
header( 'Cache-Control: no-cache' );
}
Ce correctif n’avait de sens que dans un contexte très particulier, oublié depuis : à l’époque, seule une locale RTL était configurée en plus du français, et désactiver le cache pour cette locale contournait le bug de l’extension sans affecter les autres langues. Le correctif temporaire n’a jamais été retiré ni documenté, et sept ans plus tard, plus personne dans l’équipe ne savait pourquoi cette ligne existait.
Troisième usage : une supposition sur le nombre de langues actives
Le troisième cas conditionnait l’affichage du sélecteur de langue dans le menu :
if ( is_rtl() ) {
echo '<li class="lang-switcher-multiple">';
} else {
echo '<li class="lang-switcher-simple">';
}
L’intention supposée, déduite du nom des classes CSS, était de choisir un gabarit de sélecteur différent selon que le site avait « beaucoup » de langues actives ou seulement deux. is_rtl() ne répond en rien à cette question : le nombre de langues actives sur un site multilingue n’a aucun lien logique avec la direction d’écriture de la locale courante. Ce code produisait un résultat qui semblait correct par coïncidence, tant que la configuration linguistique du site restait celle en place au moment où il a été écrit.
Pourquoi ces détournements sont restés invisibles pendant sept ans
Le point commun aux trois cas : chacun produisait un résultat visuellement correct dans la configuration linguistique du site au moment où il a été écrit, et aucun n’a été remis en question tant que cette configuration n’a pas changé. Un test manuel classique, qui vérifie que le site fonctionne dans son état actuel, ne peut pas détecter ce type de problème : il faudrait changer la configuration linguistique pour révéler l’écart entre l’intention du code et son comportement réel.
Une fonction cœur au comportement simple et bien documenté peut malgré tout être détournée comme raccourci pour une tout autre condition, tant que ce raccourci produit le bon résultat dans la configuration du moment. Le risque ne se révèle qu’au changement de configuration, souvent des années plus tard.
La méthode d’audit appliquée
La recherche systématique a porté sur toutes les occurrences de is_rtl( dans la base de code du thème, avec pour chaque occurrence une question unique : ce code changerait-il de comportement si on passait le site à une locale RTL réelle sans changer quoi que ce soit d’autre ? Les usages légitimes (chargement de feuille de style RTL) répondaient naturellement oui à cette question de façon cohérente avec leur intention. Les trois usages détournés répondaient oui également, mais de façon incohérente avec ce que le code était censé accomplir, ce qui les a immédiatement fait ressortir.
En résumé
Un an après sa mise en production, l’audit de ce vieux thème a montré qu’une fonction cœur aussi simple que is_rtl() peut être détournée en condition générique de langue, de comptage de langues actives, ou même en contournement de bug sans rapport avec son rôle documenté. Ces détournements restent invisibles tant que la configuration linguistique du site ne change pas, ce qui en fait un risque différé plutôt qu’un bug immédiat. La méthode d’audit la plus efficace reste de confronter systématiquement chaque usage d’une fonction à son comportement documenté, plutôt qu’à son comportement observé dans la configuration actuelle.
