Target blank en HTML : pourquoi vous l'utilisez mal

Combien de fois par semaine je vois encore cette horreur ? Trop souvent. J’ouvre l’inspecteur d’un site à auditer dans mon agence web dans l’Oise, et paf : des liens externes tartinés de target blank à tort et à travers.

Le client me soutient mordicus que ça retient le visiteur chez lui. L’ancien prestataire lui a vendu ça comme une astuce de génie. Résultat ? C’est tout l’inverse.

On casse la navigation de l’internaute, on flingue l’accessibilité et on ouvre parfois des trous de sécurité béants. Alors posons les choses à plat deux minutes, sans langue de bois d’école d’ingénieurs.

target blank sans underscore : la boulette classique qui me rend dingue

Attaquons tout de suite par le truc bête. Le détail qui différencie un dev qui sait ce qu’il tape d’un bidouilleur du dimanche. Vous seriez surpris du nombre de templates où je croise target="blank" au lieu de target="_blank".

Pourquoi c’est catastrophique ? Un simple caractère manquant change radicalement le comportement du navigateur.

Un nom de fenêtre au lieu d’un mot-clé réservé

En HTML, les mots-clés réservés pour l’attribut de cible commencent tous par un tiret bas : _blank, _self, _parent, _top. C’est la norme officielle spécifiée par le consortium W3C sur les contextes de navigation.

Quand vous oubliez ce satané underscore et que vous écrivez target="blank", le navigateur n’interprète pas ça comme une instruction générique. Il croit dur comme fer que vous voulez cibler un cadre ou un onglet baptisé littéralement « blank ».

Le premier clic ouvre bien un nouvel onglet nommé « blank ». Parfait en apparence.

Mais que se passe-t-il quand l’internaute clique sur un deuxième lien externe sur la même page ? Le navigateur cherche si un onglet porte le nom « blank ». Il le trouve, l’écrase sans pitié et recharge la nouvelle URL dedans. L’utilisateur perd immédiatement ce qu’il était en train de lire sur le premier lien ouvert. Du pur bricolage.

Les quatre valeurs natives qu’il faut vraiment connaître

Pour clarifier une bonne fois pour toutes les choses dans vos gabarits, voici comment réagissent les navigateurs selon la syntaxe injectée :

• _blank : force l’ouverture d’une nouvelle fenêtre ou d’un nouvel onglet indépendant à chaque clic.
• _self : charge le document dans le même cadre ou onglet (c’est la valeur par défaut si vous n’écrivez rien).
• _parent : charge la page dans le cadre parent direct (très utile si vous manipulez des iframes imbriquées).
• _top : casse toutes les fenêtres intégrées pour occuper toute la largeur de la fenêtre racine.

Si vous tapez autre chose sans tiret bas, vous créez simplement un identifiant arbitraire. Rien de plus.

La faille de sécurité du reverse tabnabbing : quand votre lien pirate votre site

Pendant des années, coller un simple lien vers un site externe avec un nouvel onglet représentait une faille monumentale. Cette faille porte un nom précis : le reverse tabnabbing. Et croyez-moi, les scripts malveillants s’en sont donné à cœur joie.

On ne va pas se mentir : peu de développeurs comprenaient ce qui se passait sous le capot avant que les navigateurs ne durcissent leurs règles par défaut.

Comment window.opener vous poignarde dans le dos

Le principe est vicieux mais simplissime. Lorsque votre page ouvre un site tiers avec target blank, la page cible gagne un accès direct à votre page d’origine via l’objet JavaScript window.opener.

Concrètement, la page distante peut exécuter une ligne de code toute bête :

window.opener.location = "https://faux-site-de-phishing.fr/connexion";

Pendant que votre visiteur consulte distraitement l’article externe sur le nouvel onglet, votre propre onglet — resté ouvert en arrière-plan — est discrètement redirigé vers une fausse page de connexion imitant votre interface. Quand le visiteur revient sur votre onglet, il voit un formulaire de mot de passe. Il tape ses accès. C’est terminé.

Laisser un lien externe ouvrir un onglet sans noopener, c’est prêter les clés de son tableau de bord à un parfait inconnu dans la rue.

rel= »noopener » et rel= »noreferrer » : votre gilet pare-balles

Pour couper court à cette dérive, l’attribut rel est indispensable. Vous devez associer rel="noopener" pour ordonner au navigateur de vider l’objet window.opener et de traiter la nouvelle fenêtre dans un thread totalement distinct.

La documentation de référence sur l’élément a sur MDN rappelle d’ailleurs pourquoi cette combinaison est devenue la norme absolue. Pour blinder vos templates, la syntaxe propre doit ressembler à ceci :

<a href="https://exemple.fr" target="_blank" rel="noopener noreferrer">Lien externe sécurisé</a>

Certains me diront : « Oui mais Sébastien, les moteurs Chromium et Firefox appliquent désormais noopener implicitement quand ils voient un lien externe en nouvel onglet ! » C’est vrai sur les versions récentes. Mais sur les vieilles webviews Android intégrées dans certaines applications ou sur de vieux terminaux non mis à jour, l’absence de l’attribut explicite laisse encore la porte ouverte. Je ne laisse jamais traîner ce genre de dette technique sur mes serveurs.

UX et accessibilité : pourquoi vos visiteurs détestent vos nouveaux onglets forcés

Posez-vous une question toute simple : qui est le patron devant l’écran ? L’internaute ou vous ?

Quand vous forcez l’ouverture d’un onglet, vous prenez une décision dictatoriale à la place de celui qui consulte votre contenu. Vous lui imposez votre façon de naviguer.

Le bouton retour en arrière brisé net

Le premier réflexe de 90 % des utilisateurs du web quand une page ne les intéresse plus, c’est d’appuyer sur le bouton « Précédent » de leur souris ou sur la flèche retour de leur navigateur. C’est un automatisme ancré depuis vingt ans.

En imposant un nouvel onglet, vous videz l’historique de la nouvelle fenêtre. Le bouton retour est grisé. Inactif. L’internaute se retrouve bloqué, regarde sa barre d’onglets, peste, et doit fermer manuellement la fenêtre. Sur smartphone, c’est encore pire : les navigateurs mobiles masquent souvent les compteurs d’onglets, créant une pagaille monstre dans la session de l’utilisateur.

La galère noire pour les utilisateurs de lecteurs d’écran

Parlons accessibilité deux minutes. Si vous effectuez une refonte site vitrine aux normes RGAA ou WCAG, balancer des onglets sans prévenir est une faute éliminatoire.

Une personne malvoyante ou aveugle qui utilise un lecteur d’écran comme NVDA ou VoiceOver écoute le texte. Si elle clique sur un lien externe, le focus saute brutalement sur un nouveau contexte sans aucun avertissement sonore. L’utilisateur croit qu’il est toujours sur la même page, cherche ses repères et perd totalement le fil de sa lecture.

Si vous devez absolument imposer un onglet, la moindre des politesses consiste à prévenir vocalement et visuellement :

<a href="https://doc.fr" target="_blank" rel="noopener">
  Télécharger le guide PDF 
  <span class="sr-only">(ouvre un nouvel onglet)</span>
</a>

La classe CSS sr-only masque le texte visuellement pour préserver votre design, tout en permettant aux synthèses vocales de le lire distinctement. Propre, net et respectueux.

Performances serveur et RAM : l’impact insoupçonné sur le navigateur

On parle souvent de code propre côté serveur, d’optimisation Apache via le fichier .htaccess ou de gestion du cache mémoire. Mais qu’en est-il de la machine de votre visiteur ?

Ouvrir un onglet n’est jamais une opération neutre.

L’isolation des processus et la boulimie de Chrome

Les moteurs de rendu modernes fonctionnent sur un modèle multiprocessus. Chaque onglet réclame son propre espace mémoire pour garantir la stabilité globale. Si une page plante, elle ne doit pas faire tomber tout le navigateur.

Sans la protection noopener, le nouvel onglet ouvert via target blank peut être contraint de partager le même thread d’exécution que votre propre site. Imaginez la scène : le site tiers vers lequel vous renvoyez est codé avec les pieds et fait tourner une boucle JavaScript affreuse. Votre propre site se met à ramer et à saccager le défilement de votre page dans l’onglet d’origine !

Ajouter rel="noopener" force le navigateur à lancer le nouveau site dans un processus mémoire complètement distinct. Vous isolez les risques.

Le comparatif technique : quand faut-il vraiment ouvrir un nouvel onglet ?

Je ne suis pas un ayatollah du zéro onglet. Il y a des situations réelles où l’ouverture externe fait parfaitement sens d’un point de vue fonctionnel. Le problème vient de l’automatisation aveugle.

Voici ma grille de décision sans fioritures pour trancher sereinement lors du développement de vos interfaces :

Gardez cette grille en tête la prochaine fois qu’un chef de projet vous demande d’ouvrir tous les liens externes par défaut. Expliquez-lui les faits avec des arguments techniques solides.

Le mythe SEO qui a la vie dure : non, target blank ne booste pas votre classement

C’est sans doute le fantasme le plus tenace chez les agences marketing : « Si on met des target blank partout, le taux de rebond diminue et le temps passé sur la page augmente, donc Google nous propulse en première page ! »

Soyons clairs deux minutes : c’est du grand n’importe quoi.

Googlebot se contrefout royalement de vos onglets

Le robot d’exploration de Google ne navigue pas comme un être humain avec une souris. Il lit le Document Object Model, extrait les URLs présentes dans les attributs href et les empile dans sa file d’attente d’exploration. Que vous ayez mis target blank ou rien du tout, son comportement reste strictement identique.

L’attribut de cible n’a aucun impact sur la transmission du PageRank. Pour piloter le jus de lien ou signaler un contenu sponsorisé, seuls comptent les attributs rel="nofollow", rel="sponsored" ou rel="ugc".

Quand vous distribuez un backlink vers un site d’autorité, Google enregistre l’association thématique entre les deux pages. Le fait que le lien s’ouvre dans une fenêtre volante n’influence en rien la valeur algorithmique de ce vote de confiance.

La fausse métrique du temps de visite gonflé artificiellement

Pourquoi les gens pensent-ils que cela fonctionne ? Parce qu’ils regardent mal leurs tableaux de bord analytiques.

Quand un utilisateur laisse votre onglet ouvert en arrière-plan pendant qu’il lit un autre site, le compteur de session tourne parfois dans le vide selon la configuration de votre tracker. Vous croyez mesurer un engagement exceptionnel alors que le visiteur a tout simplement oublié de fermer votre onglet au milieu de ses 40 autres fenêtres ouvertes.

Google mesure la satisfaction des usagers via les signaux d’interaction réels sur sa page de résultats. Si votre internaute est agacé par une navigation confuse, il fermera tout et retournera chercher une réponse ailleurs. C’est ça qui détruit votre visibilité.

Comment gérer proprement les liens sortants sous WordPress

Sur l’écosystème WordPress, la gestion des liens est souvent un champ de bataille entre l’éditeur de blocs Gutenberg, les constructeurs de pages tiers et les vieux thèmes mal codés. Comment reprendre la main sans bricoler du JavaScript partout ?

La méthode native dans l’éditeur Gutenberg

L’équipe du CMS a bien travaillé ces dernières années. Quand vous sélectionnez un lien dans Gutenberg et que vous activez l’interrupteur « Ouvrir dans un nouvel onglet », le moteur ajoute automatiquement target="_blank" et injecte en arrière-plan la chaîne rel="noreferrer noopener" dans le code source HTML.

C’est propre, conforme aux recommandations du projet open-source et transparent pour le rédacteur. Le problème survient quand les utilisateurs activent cette case de manière compulsive sur chaque mot-clé cliquable.

Nettoyer ou automatiser via functions.php sans usine à gaz

Si vous devez automatiser un comportement strict sur des centaines d’articles déjà publiés sans installer une extension lourde, vous pouvez filtrer directement le contenu à l’affichage via un petit script PHP placé dans votre thème enfant ou dans un plugin WordPress personnalisé.

Voici un exemple de filtre qui analyse le contenu, détecte les liens externes, et s’assure qu’aucun lien interne ne s’ouvre dans un nouvel onglet par erreur :

add_filter('the_content', function ($content) {
    return preg_replace_callback('/<as+(+)>/', function ($matches) {
        $attributes = $matches[1];
        
        // Si le lien est déjà propre ou interne, on ne touche à rien
        if (strpos($attributes, 'mon-domaine.fr') !== false) {
            // On s'assure de virer un target _blank parasite en interne
            $attributes = preg_replace('/target=['"]*['"]/', '', $attributes);
            return '<a ' . trim($attributes) . '>';
        }
        
        return $matches[0];
    }, $content);
});

C’est léger, ça ne surcharge pas la base de données MySQL et ça garantit une cohérence globale sur tout votre parc de pages.

Foire Aux Questions (FAQ)