Le site marche chez vous, pas chez vos visiteurs : pourquoi

Pourquoi votre écran ment (sans le vouloir)

Le site marche chez vous, pas chez les clients : c’est le motif d’appel le plus fréquent après « on ne sait pas si c’est piraté ». Vous êtes connecté, souvent en desktop, parfois derrière un CDN qui vous a mis en bypass, parfois sur une IP d’admin whitelistée par le payload. Le script est écrit pour ne pas vous déranger. Vous concluez « ça s’est arrangé ». Eux, non.

Quatre familles : cache (vous voyez hier soir), infection conditionnelle (mobile, Google, pays), alerte navigateur (liste noire que votre Chrome n’a pas encore, ou l’inverse), réseau (entreprise, DNS, antivirus). On les sépare par des tests, pas par intuition.

Tant que vous n’avez pas reproduit le symptôme du client, ne « corrigez » pas au hasard. Vous allez casser le thème pour un problème de Safe Browsing, ou flush un cache qui était votre seule preuve. Captures d’abord, les leurs et les vôtres.

• Privée desktop, même URL.
• Téléphone 4G, pas le Wi-Fi du bureau.
• Clic depuis `site:` ou un résultat Google.
• Réseau hors entreprise (4G, autre box).

Le cache qui vous sert la version propre

Plugin de cache, Cloudflare « development mode » oublié chez vous seulement, cookie `wordpress_logged_in` qui bypass le cache page. Vous voyez le HTML actuel (parfois déjà retouché). Le visiteur anonyme reçoit encore la home défigurée de 6 h, ou l’inverse — vous voyez le défacement, le cache leur sert encore l’ancienne home, ils ne comprennent pas votre panique.

Test : privée + autre navigateur + `?nocache=1` si votre plugin le permet + un user-agent curl. Purger le cache est un geste de fin, après copie d’une page servie au visiteur (curl, ou « afficher la source » en privée).

Object cache Redis qui ressert un JS pirate : plus vicieux. Flush après nettoyage fichiers, sinon le symptôme reste. Redis.

La redirection que le desktop ignore

User-agent iPhone, referer Google, pays, absence de cookie admin. C’est le cœur des articles redirection mobile et depuis Google. Chez vous : site normal. Chez eux : jeux, adulte, support. Vous n’êtes pas fou. Le script vous a filtré.

Reproduire : user-agent switcher, téléphone, clic SERP. Sans reproduction, vous cherchez un `.htaccess` « qui n’existe pas » parce que c’est un JS en base qui teste `mobile`.

Ne vous fiez pas à « j’ai tapé l’URL, c’est bon ». Taper l’URL n’envoie pas le referer Google. C’est précisément le filtre.

Ce que Chrome dit chez eux, pas chez vous

Safe Browsing n’est pas synchrone à la minute près sur tous les appareils. Eux ont l’interstitiel « site trompeur », vous pas encore — ou l’inverse après un réexamen partiel. Testez [transparencyreport.google.com] et Search Console. Le cadenas vert ne dit rien. HTTPS et site dangereux.

Firefox / Edge / Safari : listes proches mais pas identiques. Un client 100 % Safari iOS peut voir un warning que votre Chrome desktop ignore encore.

Ne « renouvelez pas le certificat » pour ça. Mauvais levier, une journée perdue.

Le filtre du bureau et le DNS local

Proxy d’entreprise, Cisco, DNS 192.168.1.1 qui a un filtre familial, hosts file d’un prestataire. Le site « ne marche pas au bureau » et marche en 4G : souvent ça, pas un hack. Inverse : marche au bureau (IP whitelistée par le malware) et casse dehors — hack plus probable.

Test 4G vs LAN. Changez de DNS (1.1.1.1) une fois, pour voir. Ne concluez pas sur un seul PC Windows « protégé » par un antivirus qui interstitiel tout `.js` tiers.

IPv6 / `www` vs apex : parfois un seul des deux est sale. IPv6 ou www. Testez les deux hostnames.

Protocole de tests en quinze minutes

Écrivez une grille : privée desktop / iPhone 4G / clic Google / 4G vs bureau / `www` vs apex / HTTP vs HTTPS. Trois « sale » du même type = piste. Un seul « sale » = creuser ce canal avant de tout réinstall.

curl (UA mobile, header Referer google) depuis une machine qui n’est pas vous. Ou un collègue loin, capture. L’inspection Search Console compte comme un test « Googlebot ».

Si tout est propre et les clients encore nombreux : alerte liste noire en propagation, ou un pays ciblé. Un VPN sortant (pays) aide. Pas besoin d’un outil payant le jour J : un collègue en roaming, parfois.

Search Console : le HTML de l’autre côté

Inspection d’URL : HTML téléchargé, capture d’écran Google, ressources. Un écart avec votre view-source desktop est une preuve de cloaking. Gardez ce HTML. Il sert au réexamen et au constat.

Si vous n’avez plus Search Console (email admin changé), c’est déjà un signe d’accès. Reprenez le compte, puis inspectez.

Les rapports « problèmes de sécurité » : autre onglet, autre liste. Une Search Console « pas d’issue » ne dit rien de Chrome chez Madame Martin. Trois listes, délais.

Que faire des captures clients

Gardez-les, URL visible, remerciez, ne les contredisez pas (« chez moi ça va »). Demandez appareil, heure, Wi-Fi ou 4G, depuis Google ou non. Ces métadonnées orientent la famille (cache / mobile / SERP / réseau).

Une comm’ interne : « on reproduit, on traite, ne saisissez rien sur les pages étranges ». Pas un thread de 40 personnes qui rechargent et polluent les logs. Prévenir les clients si le risque dépasse le désagrément visuel.

Puis l’ordre premiers gestes une fois la famille identifiée. Votre écran propre n’annule pas leur capture.