Comment répondre à un ticket d'abus de son hébergeur
Citez la référence, le motif, ce qui a été trouvé, ce qui a été retiré, ce qui a été corrigé. Un ticket d’une phrase (« c’est nettoyé, vous pouvez rouvrir ») est presque toujours refusé. L’abuse team lit des dossiers, pas de l’urgence. Voici comment écrire pour qu’un humain puisse rescanner sans vous rappeler.
Citez la référence, le motif, ce qui a été trouvé, ce qui a été retiré, ce qui a été corrigé. Un ticket d'une phrase est presque toujours refusé.
Ce que lit vraiment un opérateur abuse
Il a une file, un ID, un scan, parfois un rapport d’un tiers (Google, PhishTank). Il cherche : est-ce que le motif est encore vrai maintenant ? Il ne cherche pas si votre CA souffre, si vous êtes « un bon client depuis 2012 », si Wordfence est vert. Un roman sur l’agence le fait scroller. Un tableau de chemins lui permet de lancer le rescan.
Vous n’êtes pas en procès. Vous fournissez de quoi lever un flag automatique. Le ton factuel gagne. L’indignation perd. L’anglais passe souvent mieux que le français fleuri sur les tickets internationaux ; en France, un français sec suffit.
S’il manque une pièce, il refuse ou il pose une question qui vous coûte 24 h. Mieux vaut trop de chemins que « on a tout sécurisé ».
- Il vérifie des URL et des paths, pas votre sincérité.
- Un 200 encore sale = non.
- Une entrée non mentionnée + récidive = deuxième non, plus lent.
L’en-tête : référence, domaine, qui vous êtes
Sujet : `Re: Abuse #4521 — exemple.fr — nettoyage effectué`. Première ligne : n° client, titulaire, domaine, adresse de secours hors domaine. Sans ça, la réponse part dans le vide (MX coupée) et vous relancez en croyant qu’ils ignorent.
Un seul fil. Les doublons « URGENT » créent deux dossiers, deux scans, deux refus décalés. Si vous avez ouvert un doublon par erreur, citez les deux IDs et dites lequel est vivant.
Pièce d’identité seulement si on vous la demande (takeover). N’anticipez pas un passeport dans un ticket malware.
Le motif, relu, pas contesté à la légère
Reprendre leurs mots : malware / phishing / spam / resource abuse. Si le motif est phishing, votre constat sur un `eval` à la racine sans parler des URL du kit est incomplet. Si c’est CPU, parlez cron et process, pas seulement « on a mis un cache ».
Contester un faux positif : hashes, lien zip officiel, date. Contester « ce n’est pas nous » alors que le path est dans votre home : perdu d’avance. Le voisin de compte, c’est encore vous. Plusieurs sites.
Si vous n’avez pas le motif : demandez-le, ne inventez pas un constat générique. Un constat à côté de la plaque = rescan qui retrouve « autre chose » = nouveau délai.
Trouvé — chemins et dates
Liste : `public_html/wp-core.php` (mtime 2026-08-25 03:12), `wp-content/uploads/2026/08/x.php`, utilisateur WP `shop_mgr` (créé 03:14), cron `*/5 … cache.php`. Pas besoin du dump hexadécimal. Besoin de pouvoir revérifier.
Si vous n’avez pas tout trouvé : dites ce qui est incertain. « Entrée probable extension Y, retirée, surveillance 30 j ». Mieux qu’un « 100 % sécurisé » faux.
Joindre un txt de chemins si la liste dépasse dix lignes. Pas un zip de tout le site (secrets, taille).
Retiré — ce qui n’est plus en 200
Pour chaque URL / path signalé : 404, 410, ou 403. Dites-le. « On a nettoyé » ne dit pas si `/secure/login.php` répond encore. Testez vous-même avant d’envoyer, y compris user-agent mobile. Un kit qui ne se montre qu’en iPhone fait échouer le rescan.
Les copies `wp-core2.php` : cherchez le préfixe. Un seul fichier retiré, cinq jumeaux : leur scanner les voit.
Quarantine hébergeur : mentionnez-la (« déjà en .suspect de votre côté, confirmé retiré de la prod »). Ça aligne les deux inventaires.
Corrigé — l’entrée et les secrets
Extension mise à jour ou retirée, admin fantôme retiré, mots de passe panel/FTP changés le … à …, 2FA, cron retiré, `.user.ini` nettoyé. C’est la partie qui évite le ticket #4522 la semaine suivante.
Sans ça, certains abuse refusent même si le fichier a disparu — récidivistes. D’autres rouvrent et vous revoient jeudi. Autant l’écrire.
Vous n’avez pas à livrer un audit ISO. Trois à huit lignes de mesures datées suffisent. Voir aussi le constat suspension.
Une phrase = un refus (exemples)
« C’est nettoyé, merci de rouvrir. » « On a installé Wordfence. » « Nos clients attendent, c’est urgent. » « Ce n’était pas notre faute. » « On a restauré la sauvegarde. » Ces cinq-là, on les voit tous les jours. Les trois premières n’ont aucune matière. La quatrième agace. La cinquième, sans dire que la save a été lue, sent le restore sale.
Exemple recevable (court) : « Ref #4521, exemple.fr, client 9988, contact moi@gmail.com. Motif malware. Trouvé `public_html/wp-core.php` (25/08 03:12) et user `shop_mgr`. Retiré les deux, plus de 200 sur ces paths. Corrigé : plugin X retiré, panel+FTP changés 27/08 09:00, 2FA. Merci de rescanner. »
Adaptez. N’y collez pas de mot de passe. N’y collez pas wp-config.
Délais, relances, et pièces jointes
Après un constat recevable : souvent 4–48 h ouvrées. Relance J+1 avec une pièce, pas H+1. Délais globaux. Captures d’URL 404 : utiles en petit nombre. Un PDF de 40 pages de scan Wordfence : non.
Si on demande un complément, répondez dans le fil, point par point, numéroté. « Voir ci-dessus » sur un pavé de 80 lignes les fait rater la ligne 67.
Safe Browsing n’est pas leur job. Ne mélangez pas « Google est encore rouge » et ce ticket, sauf si le motif était précisément un signalement Google et qu’une URL leur appartient encore. Sinon : réexamen à part, après site propre.