Le proxy de l'entreprise de vos clients bloque votre site

Ce n'est pas « un antivirus capricieux »

Les filtres d'entreprise (SWG, NGFW, proxy explicite) décident pour des milliers de salariés. Ils préfèrent un faux positif à un kit. Votre domaine a été vu sale, ou voisin d'IP, ou trop jeune, ou dans un feed payant. Ce n'est pas de la mauvaise volonté envers votre PME.

Le blocage peut n'exister que sur le réseau du client (siège), pas en 4G. D'où « chez moi ça marche ». Demandez s'ils sont au bureau. Ça tranche proxy vs Safe Browsing public.

Traitez quand même le site : souvent le feed a raison, avec 48 h de retard sur ce que vous avez déjà enlevé. Un path encore 200 quelque part sur le compte (sous-domaine, HTTP) suffit à nourrir le feed. Avant d'écrire au DSI, faites la tournée des hôtes comme pour Safe Browsing. Leur appliance n'est pas « capricieuse » si `old.` sert encore le kit.

Lire le bandeau : l'éditeur est la clé

Capture obligatoire : logo Palo Alto, FortiGuard, Umbrella, Zscaler, « Symantec », un code catégorie (`phishing`, `malware`, `command-and-control`). Sans ça, vous ouvrez le mauvais formulaire et attendez dans le vide.

L'URL bloquée : home ou un path `/wp-content/…`. Le path dit si leur cache a encore le kit.

Un numéro de ticket interne côté client : vous le mentionnez dans vos échanges. Ça les aide à tracer.

• Éditeur + catégorie.
• URL exacte bloquée.
• Réseau siège vs 4G.

Palo Alto, Fortinet, Cisco, « Secure Web »

Chacun a un « URL filtering request » / False Positive. Google n'y est pour rien. Le DSI client peut souvent soumettre plus vite que vous (ils sont clients de l'appliance). Donnez-leur l'URL, la date de clean, un live 404.

Les bases se recoupent (BrightCloud, etc.). Un refus « encore listé chez X » explique un blocage Y. Patience en série, pas cinq nettoyages.

Les noms marketing (« Secure Web Gateway ») cachent parfois le même moteur. Le bandeau technique compte plus que le slide commercial.

Pourquoi ça reste après Safe Browsing vert

Feeds commerciaux mis à jour toutes les 4, 12, 24 h, parfois plus. TTL de cache proxy. Une catégorie « newly seen » qui n'a rien à voir avec le malware mais bloque les domaines récemment signalés.

24-72 h Google, 3 à 10 jours proxy : chiffres de terrain, pas un contrat. Annoncez la fourchette haute aux commerciaux qui veulent « une date ». Un tableau à trois lignes (Chrome, Edge grand public, proxy nommé) dans le même mail évite que chaque interlocuteur croie que « Google » parle pour tout le monde. Le DSI, lui, veut l'éditeur du bandeau et une URL 404, pas une théorie sur Safe Browsing.

Une IP mutualisée encore sale chez le feed (voisin) : vous payez le voisinage. L'hébergeur peut bouger d'IP après clean ; ça aide parfois, ça n'est pas magique.

Ce que vous envoyez au DSI client

Court : incident le [date], path frauduleux retiré le [date], URL maintenant 404/410, réexamen Google déposé / levé le [date], constat en PJ si vous en avez un. Demande : exception temporaire + soumission false positive chez leur vendeur.

Pas le nom du webshell. Pas « on a été hackés c'est la faute de l'agence ». Ils veulent de quoi défendre une exception auprès de leur RSSI.

Copie au commercial chez vous : même texte. Évite les versions brodées.

Formulaires vendeurs et délais réels

Remplissez le false positive si vous y avez accès. Sinon le client. Une fois par vendeur. Joindre le live test.

Relance J+5, pas H+2. Un ticket « urgent black friday » sans 404 se ferme. Si le client peut poser une exception temporaire d'URL, donnez-lui le path exact et une date de revue (J+7). Pas une whitelist du domaine entier « pour toujours » : leur RSSI la refusera, et vous n'aurez plus de levier pour prouver que le feed peut se vider.

Norton, McAfee grand public : autres formulaires, clients moins DSI. Voir alerte Norton.

Catégorie « phishing » vs « malware » vs « newly registered »

Phishing : ils ont vu un kit ou un signalement. Malware : un téléchargement, un JS. Newly registered / parked : parfois un faux positif après un changement de DNS. Le traitement site est le même (propre) ; l'argument du formulaire change.

« Command and control » : plus grave dans leur tête (botnet). Votre constat doit montrer qu'il n'y a plus de PHP appelant l'extérieur. Logs.

Mauvaise catégorie persistante : le false positive le dit. Ne discutez pas la taxonomie sur LinkedIn.

Ne pas contourner leur sécurité

Pas de « mettez le site en whitelist permanente sans revue ». Pas de tuto pour désactiver le proxy. Exception temporaire, URL précise, durée, responsable chez eux.

Un second domaine « le temps que ça passe » : vous perdez le SEO et vous paraissez fuir. Sauf si le métier est vraiment à l'arrêt et que le DSI l'exige — alors soyez transparents : c'est un miroir temporaire, le domaine canonique revient.

VPN perso pour « tester chez le client » : vous ne testez plus leur proxy. Inutile pour le diagnostic de leur bandeau.

Votre propre réseau de bureau ment

Votre office a peut-être déjà whitelisté votre site. Testez hors de là. Les devs « ça marche » depuis 10 ans sur le même Wi-Fi.

Un split tunnel, un PAC file. Demandez au client un test depuis un poste standard, pas depuis l'IT.

Vous pouvez déclarer le site. Les captures proxy + la catégorie, c'est le dossier. On ne promet pas une date de levée Palo Alto.

• Éditeur identifié.
• Site réellement 404 sur le path.
• Mail unique pour tous les DSI.
• False positive + exception temporaire.