« Peux-tu faire en sorte que tous les liens vers l’extérieur s’ouvrent dans un nouvel onglet ? » Cette demande revient dans presque tous mes projets éditoriaux, généralement formulée par une personne qui ne veut pas que ses lecteurs quittent le site. Techniquement, la réponse tient en un filtre sur le contenu. La question de fond, elle, mérite d’être posée avant d’écrire la moindre ligne : est-ce vraiment une bonne idée ?
Cet article couvre les deux : comment détecter et modifier automatiquement les liens sortants, et pourquoi l’attribut target="_blank" fait débat du côté de l’accessibilité.
Détecter un lien externe dans le contenu
Le filtre the_content permet d’intercepter le HTML généré avant affichage. Pour repérer un lien externe, on compare son domaine à celui du site courant, récupéré via home_url() :
add_filter( 'the_content', function ( $contenu ) {
$hote_site = wp_parse_url( home_url(), PHP_URL_HOST );
return preg_replace_callback(
'/<a\s+[^>]*href="([^"]+)"[^>]*>/i',
function ( $matches ) use ( $hote_site ) {
$hote_lien = wp_parse_url( $matches[1], PHP_URL_HOST );
if ( $hote_lien && $hote_lien !== $hote_site ) {
return str_replace(
'<a ',
'<a target="_blank" rel="noopener noreferrer" ',
$matches[0]
);
}
return $matches[0];
},
$contenu
);
} );
Cette approche par expression régulière fonctionne pour l’essentiel des cas, mais reste fragile face à un HTML mal formé. Sur un projet plus exigeant, je préfère charger le contenu dans WP_HTML_Tag_Processor (disponible depuis WordPress 6.2), plus robuste que les expressions régulières pour manipuler des attributs HTML :
add_filter( 'the_content', function ( $contenu ) {
$hote_site = wp_parse_url( home_url(), PHP_URL_HOST );
$processeur = new WP_HTML_Tag_Processor( $contenu );
while ( $processeur->next_tag( 'a' ) ) {
$href = $processeur->get_attribute( 'href' );
$hote_lien = $href ? wp_parse_url( $href, PHP_URL_HOST ) : null;
if ( $hote_lien && $hote_lien !== $hote_site ) {
$processeur->set_attribute( 'target', '_blank' );
$processeur->set_attribute( 'rel', 'noopener noreferrer' );
}
}
return $processeur->get_updated_html();
} );

rel= »noopener » : pas négociable
Contrairement à target, l’attribut rel="noopener" n’est pas affaire de goût. Sans lui, la page ouverte dans le nouvel onglet dispose d’un accès partiel à la fenêtre d’origine via window.opener, ce qui a permis par le passé des attaques de type hameçonnage par redirection de l’onglet parent. Depuis les navigateurs modernes, target="_blank" applique par défaut un comportement proche de noopener, mais l’ajouter explicitement reste la pratique recommandée et documentée sur MDN.
Le débat accessibilité sur target= »_blank »
Les référentiels d’accessibilité, dont les critères repris par WCAG, déconseillent d’ouvrir un lien dans un nouvel onglet sans prévenir l’utilisateur. Une personne utilisant un lecteur d’écran ne perçoit pas toujours qu’un nouvel onglet vient de s’ouvrir, ce qui peut la désorienter, en particulier si elle navigue au clavier et cherche à revenir en arrière.
- Le bouton « précédent » du navigateur ne fonctionne plus comme attendu si l’utilisateur ne réalise pas qu’un nouvel onglet s’est ouvert.
- Certains lecteurs d’écran annoncent l’ouverture d’un nouvel onglet, d’autres non, selon la configuration.
- La bonne pratique consiste à ajouter un texte visuellement masqué signalant l’ouverture externe.
Un compromis : prévenir plutôt qu’imposer
Plutôt que d’ouvrir systématiquement tous les liens externes dans un nouvel onglet, une alternative consiste à ajouter une icône et un texte accessible signalant le comportement, sans forcer target="_blank" :
$processeur->set_attribute( 'aria-label', trim( $processeur->get_attribute( 'aria-label' ) . ' (nouvel onglet, site externe)' ) );
Le conseil que je donne systématiquement aux clients qui insistent pour ouvrir tous les liens externes dans un nouvel onglet : au minimum, signaler visuellement et pour les lecteurs d’écran que le lien quitte le site.
Notre verdict
Ajouter rel="noopener noreferrer" à tous les liens sortants est une bonne pratique sans contre-indication. Forcer target="_blank" partout est un choix éditorial à assumer, pas une évidence technique : s’il est retenu, il doit s’accompagner d’une indication claire pour ne pas désorienter les utilisateurs de technologies d’assistance.