Écran rouge : le jour où Google a déclaré notre domaine dangereux

En plusieurs années de métier, ça ne m'était jamais arrivé. Un matin, Chrome affiche l'écran rouge pleine page sur une URL de notre propre infrastructure : « Site dangereux ». Pas un client, pas un serveur piraté : nous.

Voici l'autopsie complète, les deux pièges dans lesquels on a failli tomber, et la méthode qu'on applique désormais.

Avant de commencer, si vous n'êtes pas technicien

Retenez juste ceci : cet écran rouge, c'est 100 % de vos visiteurs perdus. Instantanément. Pas 20 % de trafic en moins comme une pénalité de référencement — zéro. Chrome bloque la page avant même qu'elle s'affiche, et il le fait aussi dans les mails, sur mobile, partout.

Et le plus important : il n'y a pas eu de piratage. Personne n'est entré chez nous. On avait simplement construit quelque chose qui, vu par une machine, ressemblait à une arnaque. C'est ça qui rend l'histoire utile : ça peut arriver à une entreprise parfaitement saine, qui a juste voulu bien faire.

L'écran rouge

Tout commence par une opération banale : connecter une boîte Gmail à notre outil d'automatisation. Au moment de valider l'autorisation Google, Chrome bloque la page. Écran rouge, pleine largeur. Motif annoncé : procédé d'hameçonnage — les sites d'hameçonnage se font passer pour d'autres sites.

Premier réflexe : penser à un faux positif. Deuxième réflexe, le bon : vérifier.

Deux sources indépendantes confirment. Le Transparency Report de Google renvoie pour notre domaine le statut « certaines pages de ce site sont dangereuses ». Et la Search Console affiche, dans Sécurité et actions manuelles, un problème de type « Pages trompeuses ».

Avec un détail qui change tout : à la ligne « Exemples d'URL », Google écrit « Sans objet ».

Le diagnostic : on avait tort, et Google avait raison

Notre newsletter fonctionne en double opt-in : vous vous inscrivez, vous recevez un mail, vous cliquez pour confirmer. Classique.

Sauf que le lien de confirmation pointait vers notre sous-domaine d'automatisation — la machine qui fait tourner nos scénarios techniques. Et cette URL, quand on cliquait dessus, affichait une jolie page aux couleurs de la marque : logo, typographie, « merci, votre inscription est confirmée ».

Reprenons du point de vue de la machine qui analyse ça :

• une page qui affiche l'identité visuelle d'une marque,
• servie depuis un domaine qui n'est pas celui de cette marque,
• atteinte via un lien reçu par e-mail,
• avec un jeton d'identification en clair dans l'URL.

C'est la définition, ligne par ligne, d'une page d'hameçonnage. Nous n'avions rien fait de malveillant — mais nous avions construit quelque chose qui en avait exactement la forme. Google avait raison de nous signaler.

Le correctif est simple une fois le problème nommé : les liens des e-mails pointent désormais vers des pages hébergées sur le domaine de la marque elle-même. Le sous-domaine technique, lui, redevient ce qu'il n'aurait jamais dû cesser d'être : une API qui répond du JSON, invisible pour un humain.

Premier piège : croire que réparer suffit

Correctif déployé, cycle complet retesté, tout fonctionne. On classe le dossier.

Erreur.

Google ne retire pas une entrée de sa liste noire parce que la page fautive a disparu. La liste persiste jusqu'à ce que vous demandiez explicitement un examen dans la Search Console. Tant que vous ne cliquez pas sur ce bouton, votre correctif est invisible : vous êtes réparé et toujours blacklisté.

C'est contre-intuitif, et c'est ce qui fait durer les crises Safe Browsing bien au-delà du correctif technique. Ne concluez jamais « pas besoin de révision, l'URL n'existe plus ».

Deuxième piège : demander l'examen trop tôt

On s'apprête donc à demander l'examen. Et là, une question sauve la mise : est-ce qu'on est sûrs que c'était le seul endroit ?

Balayage systématique de tous les scénarios d'automatisation. Résultat : une deuxième page de marque servie depuis le même domaine technique. Cette fois, la page « Merci, votre demande est bien envoyée » qui s'affichait après l'envoi d'un formulaire de contact.

Le plus intéressant, c'est pourquoi elle existait. Le commentaire dans le code était parfaitement assumé : le site ne gérait pas l'affichage d'un message de succès après envoi, donc on servait la page de confirmation directement depuis l'automatisation — pour éviter que le visiteur atterrisse dans le vide. C'était une réponse raisonnable à un vrai problème d'expérience utilisateur.

Le motif n'avait pas disparu. Il avait simplement changé de scénario.

Le correctif tient en trois lignes : au lieu de servir la page, le webhook renvoie une redirection 303 vers une vraie page « merci » hébergée sur le domaine de la marque. Vérification en ligne de commande : code 303, en-tête Location correct, corps de réponse vide, atterrissage final en 200 sur le bon domaine. L'automatisation ne sert plus une seule ligne de HTML à un être humain.

La leçon qu'on n'attendait pas : le motif n'est jamais seul

Fort de cette alerte, on a poussé l'audit à l'ensemble du parc : tous les scénarios, tous les domaines, tous les sous-domaines (y compris ceux oubliés, retrouvés via les registres publics de certificats), toutes les pages servies, tous les liens sortants de nos e-mails.

Et le même motif est réapparu, ailleurs, sous d'autres formes. Des pages de marque servies depuis des sous-domaines techniques. Des maquettes de démonstration publiques et indexables. Des pages de connexion dupliquées sur plusieurs hôtes.

C'est la vraie leçon, celle qu'on ne lit pas dans les guides : une erreur d'architecture n'existe jamais à un seul endroit. Si vous l'avez commise une fois, c'est qu'elle résolvait un problème réel — donc vous l'avez très probablement recommise ailleurs, chaque fois pour d'excellentes raisons. Ce n'est pas un bug qu'on corrige, c'est une habitude qu'on désapprend.

Les 3 règles qu'on applique maintenant (et la checklist)

• 1. Un webhook est une API en coulisse, jamais une page où un humain atterrit. Si un humain doit voir quelque chose, il le voit sur le domaine de la marque. Toujours. Le domaine technique répond du JSON, ou redirige — il n'affiche rien.
• 2. Réparer ne suffit pas : l'examen est une démarche obligatoire. Le correctif technique et la sortie de liste noire sont deux actions distinctes. La seconde ne découle pas automatiquement de la première.
• 3. On ne demande l'examen qu'une fois TOUT balayé. Un examen rejeté coûte bien plus cher qu'une journée d'audit supplémentaire. On ne le demande qu'une fois, mais on le demande bien — en décrivant précisément la cause et l'ensemble des correctifs.

La checklist de sortie de crise, à copier si ça vous arrive :

• 1. Confirmez le signalement par deux sources : le Transparency Report de Google et la Search Console.
• 2. Vérifiez la propriété Search Console de type Domaine (validation DNS) — c'est le seul endroit d'où l'examen peut être demandé.
• 3. N'attendez pas la liste d'URL : Google indique souvent « Sans objet ». Ce n'est pas un bug, c'est la norme.
• 4. Cherchez le motif, pas l'URL : quelle page affiche une marque depuis un domaine qui n'est pas le sien ?
• 5. Balayez l'intégralité de vos automatisations, pas seulement celle qui a déclenché l'alerte — y compris les scénarios inactifs, réactivables demain.
• 6. Auditez vos e-mails sortants : chaque lien cliquable doit pointer vers un domaine de marque.
• 7. Inventoriez vos sous-domaines, y compris ceux que vous avez oubliés (les registres publics de certificats sont impitoyables pour ça).
• 8. Corrigez la cause, puis prouvez-le : chaque correctif se vérifie en ligne de commande, pas « ça devrait aller ».
• 9. Rédigez la demande d'examen en anglais, factuellement : la cause, puis chaque correctif, puis l'état final vérifiable.
• 10. Suivez le statut après la demande (comptez 24 à 72 h) et gardez la preuve du correctif au cas où un second passage serait nécessaire.

Ce balayage complet — toutes les automatisations, les sous-domaines oubliés, chaque lien sortant des e-mails — demande une bonne journée de méthode. Si vous préférez qu'on le fasse pour vous, c'est exactement l'objet de notre audit technique.

Le dénouement

Demande d'examen déposée le 22 juillet 2026 à 19h47. Rédigée en anglais, factuelle, sans plaidoirie : la cause, chaque correctif, l'état final vérifiable.

Réponse de Google le soir même. Le mail est arrivé dans la nuit : « Examen réussi » — les systèmes de Google indiquent que le site ne contient plus de liens vers des pages ou des téléchargements dangereux.

Vérification à deux sources, comme au premier jour : le mail de la Search Console, et le Transparency Report qui affiche désormais un statut propre — sur le domaine signalé comme sur les autres. Google précise que la disparition effective de l'écran rouge côté navigateurs peut demander quelques heures de plus : la décision est actée, la propagation suit.

Et si le motif dormait chez vous ?

Si vous avez lu jusqu'ici, vous avez l'essentiel : le motif à chercher, les deux pièges à éviter, et la checklist pour ne rien oublier. Reste la partie ingrate — passer méthodiquement chaque automatisation, chaque sous-domaine oublié, chaque lien sortant de vos e-mails. C'est long, et surtout : ça ne se devine pas. Ça se vérifie.

Pas le temps de tout balayer vous-même ? On passe votre installation au crible avant Google →

FAQ