Le bouton retour détourné expose un site même lorsque le code fautif vient d’un fournisseur. Depuis le 15 juin 2026, Google peut sanctionner cette pratique : l’inventaire des scripts, les tests réels et le droit de coupure deviennent des preuves de maîtrise.
Pour une PME, la difficulté tient moins à la détection qu’à la gouvernance : qui a installé le code tiers, qui peut le désactiver et quand son comportement a-t-il été vérifié ?
En bref : les points à retenir sur le bouton retour détourné
-
Depuis le 15 juin 2026, Google vise explicitement cette interférence avec l’historique du navigateur.
-
Le script en cause peut venir d’une régie publicitaire, d’un widget ou d’une agence.
-
Un test utile comprend une interaction avant le retour et se répète sur plusieurs pages.
-
Un inventaire doit préciser le titulaire du compte et la personne qui peut couper chaque code.
-
Les sanctions possibles incluent une action manuelle ou une rétrogradation dans les résultats.
Le bouton retour détourné entre dans le périmètre anti-spam
Le bouton retour détourné désigne une page qui manipule l’historique du navigateur pour empêcher un retour immédiat. L’internaute peut alors retrouver une page intermédiaire, une publicité ou une redirection malveillante.
La règle de Google vise le résultat subi par l’utilisateur, non une technologie précise. Elle concerne l’interférence qui bloque la navigation navigateur, qu’elle provienne du code du site ou d’un outil externe. Google a annoncé cette évolution le 13 avril 2026, avec une application prévue dès le 15 juin. Une action manuelle peut viser les pages concernées ; une récidive peut aussi peser sur le classement global.
Il faut distinguer cette pratique d’une entrée d’historique créée après une action volontaire. Un filtre activé par l’internaute dans une application monopage ne constitue pas, à lui seul, un détournement.
Cette nuance compte pour les équipes produit : l’objectif n’est pas de supprimer toute fonction liée à l’historique. Il faut préserver le retour normal vers la page précédente.
Le code tiers élargit le risque au-delà du site
Un code tiers peut agir sans modification visible du dépôt principal. Une régie, un widget de recommandation ou une balise publiée par une agence peut modifier le comportement d’une page. Le cas AdSense illustre ce risque de configuration. En février 2026, Google a annoncé de nouveaux déclencheurs pour ses vignettes publicitaires, dont le retour arrière sur certains navigateurs. L’activation automatique était prévue le mois suivant, sauf refus de l’éditeur.
Google a ensuite annoncé le retrait de ce déclencheur à partir du 15 juin, sans action requise des éditeurs. Ce calendrier montre qu’un réglage externe peut évoluer sans intervention de l’équipe web.
Une PME qui confie ses campagnes à une agence doit donc connaître le titulaire des comptes et les droits de publication. Un audit de gouvernance des prestataires aide à formaliser cette responsabilité opérationnelle. Le problème dépasse la publicité. Des outils de notifications, des fenêtres de sortie et des extensions CMS peuvent aussi affecter l’expérience utilisateur. La sécurité web dépend alors d’une visibilité complète sur les fournisseurs.
| Code tiers concerné | Point de contrôle | Preuve à conserver |
|---|---|---|
| Régie publicitaire | Formats et déclencheurs actifs dans la console | Capture datée des réglages |
| Widget de recommandation | Fonctions qui touchent l’historique | Confirmation écrite du fournisseur |
| Conteneur de balises | Comptes avec droit de publication | Historique des versions publiées |
Découvrez également : Audit du code tiers.
Tester la navigation navigateur avec un protocole daté
Un test sans interaction ne suffit pas. Chrome peut ignorer certaines entrées d’historique ajoutées par une page avant une activation de l’utilisateur. Un défilement ne vaut pas toujours cette activation. Un clic ou un appui tactile constitue une vérification plus fiable, selon la documentation technique du navigateur.
Le protocole doit être reproductible : les équipes peuvent comparer les résultats après chaque mise à jour ou ajout de balise. Voici une séquence simple à consigner :
-
Ouvrir une page issue des résultats de recherche, sur mobile puis sur ordinateur.
-
Répéter l’essai avec les cookies acceptés, puis refusés.
-
Attendre trente secondes pour laisser charger les annonces et les widgets.
-
Toucher une zone neutre, puis utiliser une fois le bouton retour.
-
Noter l’adresse, l’heure, le navigateur et l’état du consentement.
-
Rejouer le test sur plusieurs gabarits, trois fois par page.
Une boutique qui vérifie seulement sa page d’accueil peut manquer un widget chargé uniquement sur les fiches produit. Tester accueil, catégorie et fiche produit réduit cet angle mort.
Les appels publicitaires peuvent varier d’une visite à l’autre. Un test réussi une fois ne prouve donc pas que chaque session reste conforme.
Pour organiser ces contrôles, un protocole d’audit SEO peut associer les tests techniques aux étapes de publication.
Identifier le script intrusif sans accuser à l’aveugle
Quand le retour échoue, la console du navigateur peut aider à retrouver le script intrusif. L’analyse des appels à l’API History et de leur pile d’appels révèle parfois le fichier source et son fournisseur.
Si l’équipe ne maîtrise pas ces outils, elle peut suspendre les balises une par une en préproduction. Après chaque retrait, elle rejoue le même protocole et consigne le résultat.
Une entreprise fictive, Atelier Noroît, découvre ainsi qu’un module de recommandation s’exécute uniquement sur ses pages éditoriales. Le retrait temporaire du module rétablit le retour, puis le fournisseur confirme le réglage responsable.
Les propriétaires de sites ne doivent pas limiter l’examen aux URL citées dans un éventuel avertissement Search Console. Les exemples reçus peuvent ne pas couvrir toutes les pages affectées. Une absence d’alerte ne constitue pas une attestation de conformité. Les équipes doivent garder des preuves datées et disposer d’un accès interne à la propriété Search Console.
La méthode renforce aussi la maintenance technique web : chaque balise possède un responsable, une date de revue et une procédure de retrait.
Reprendre le contrôle du site dans les contrats
La première réponse opérationnelle consiste à couper la fonction suspecte, puis à retester. La discussion commerciale avec le fournisseur vient ensuite, une fois le comportement maîtrisé.
Le contrat doit préciser qui peut désactiver le code, dans quel délai le fournisseur répond et comment il signale les changements de réglages. Il faut aussi demander un historique des versions et des fournisseurs appelés en cascade.
Une clause peut prévoir que les fonctions qui affectent la navigation restent désactivées par défaut. Leur activation exigerait alors une autorisation écrite du client. En droit français, l’article 1231-3 du Code civil encadre la prévisibilité des dommages-intérêts. L’article 1170 concerne les clauses qui privent l’obligation essentielle de sa substance.
Ces textes ne créent pas une clause prête à l’emploi. Le juriste doit vérifier les engagements, les plafonds de responsabilité et les conditions commerciales du fournisseur.
Pour une plateforme en libre-service, les marges de négociation sont parfois nulles. Le client doit alors sécuriser les accès, surveiller les réglages et prévoir un droit de retrait technique.
Un contrat de sous-traitance numérique utile rattache chaque code à un titulaire, un droit de coupure et une preuve vérifiable.
La sécurité web dépend aussi de la gouvernance
Le contrôle du site ne se limite pas au code source. Il dépend aussi des accès aux consoles, des comptes ouverts au nom de l’entreprise et des droits de publication accordés aux agences. Une équipe marketing devrait pouvoir identifier les balises actives sans demander une recherche complète à son prestataire. Elle doit aussi savoir qui peut interrompre une diffusion en urgence.
Le point de vue opérationnel est simple : un script que personne ne peut couper devient un risque porté par l’entreprise. L’externalisation n’efface pas la responsabilité pratique du pilotage.
Cette logique rejoint la gestion des accès numériques et la protection des sites web. Un registre partagé facilite les audits et évite qu’une balise oubliée survive au départ d’un fournisseur. Les décisions commerciales doivent s’appuyer sur les revenus mesurés, pas sur une promesse générale de rendement. Si une fonction menace le trafic ou la navigation, son maintien doit relever d’un arbitrage documenté.
Le bon indicateur n’est donc pas le nombre de scripts supprimés. C’est la capacité à expliquer qui les contrôle, comment les tester et comment les arrêter.
Sources et références
Les règles sont détaillées dans les politiques anti-spam de Google Search et les pages d’aide de Search Console sur les actions manuelles. Les repères navigateur proviennent de la documentation MDN sur l’activation utilisateur et des ressources du projet Chromium. Les références juridiques renvoient aux articles 1170 et 1231-3 du Code civil sur Légifrance.
Questions sur le bouton retour détourné et le code tiers
Une fenêtre de sortie enfreint-elle cette règle ?
Pas nécessairement. Google vise l’interférence avec l’historique et le retour du navigateur ; une fenêtre qui laisse cette navigation intacte ne présente pas le même comportement.
Un site sans publicité peut-il être concerné ?
Oui. Un widget, une extension ou un outil de notification peut comporter un code qui affecte l’historique. Le test s’applique donc à tout site qui charge des scripts tiers.
Google a-t-il publié le nombre de sites sanctionnés ?
Aucun chiffre public précis n’est cité dans les informations fournies. L’absence de données ne prouve pas l’absence de contrôles ou d’actions.
Que faire si un test révèle un détournement ?
Désactivez d’abord la fonction ou la balise suspecte, puis rejouez le test. Conservez les résultats datés et demandez au fournisseur une confirmation écrite du correctif.
