Mon prestataire web a disparu et le site est piraté

Ce que « disparu » recouvre (et ce que ça change)

Prestataire introuvable, agence en liquidation, freelance qui ne répond plus, « le cousin qui gérait » parti sans les mots de passe : le site est piraté et vous n’avez ni FTP, ni wp-admin, ni parfois l’email du panel. Le piratage et la disparition se cumulent. Traitez d’abord l’accès légitime, ensuite l’infection. Inverser, c’est demander à un inconnu de « tout refaire » sur un domaine que vous ne contrôlez pas encore.

Parfois le prestataire n’a pas disparu : il ignore, ou il facture une reprise. Relancez une fois par écrit (date, 7 jours). En parallèle, partez vers l’hébergeur. Ne restez pas trois semaines à attendre un WhatsApp.

Juridique : le nom de domaine et le contrat d’hébergement sont souvent à votre nom, ou au sien. C’est la première chose à lire (facture, registrar, Whois / RDAP). Si tout est à son nom, la récupération est plus longue (registrar, preuves de marque / SIRET). Commencez aujourd’hui, pas après la refonte.

• Qui est titulaire du domaine ? de l’hébergement ? de Google ?
• Quels emails de facturation avez-vous encore ?
• Une relance écrite au prestataire, datée.

Premier interlocuteur : l’hébergeur, pas un nouveau freelance

L’hébergeur peut réinitialiser le panel, fournir une archive, les logs, parfois un accès temporaire. Un nouveau freelance sans ça recréera un site « qui se ressemble » sur un autre serveur, DNS inchangé, infection toujours servie, ou DNS basculé vers un tree vide — SEO et mails par terre. Migrer sale : pire ici, parce que vous n’avez même pas le zip source.

Ticket : identité, n° client si vous l’avez (factures), domaine, « prestataire injoignable, besoin reset panel + archive, incident sécurité ». Adresse de secours. Pièce d’identité. Les process anti-takeover existent : c’est normal, ça prend un à trois jours ouvrés, pas dix minutes de chat.

Si l’hébergeur ne « vous connaît pas » (contrat au nom de l’agence) : demandez la procédure de transfert de titulaire. Fournissez Kbis, factures, captures du site. En parallèle, le registrar pour le domaine. Deux tickets, deux titulariats possibles.

Prouver que le compte est à vous

Factures PDF, RIB qui payait le prélèvement, emails depuis une adresse `@votre-societe`, documents officiels. Pas un « c’est mon site, tout le monde le sait ». Les support ont des procédures d’hijacking. Aidez-les à vous dire oui.

Si vous payiez l’agence et l’agence payait l’hébergeur : vous n’êtes pas dans leur base. Passez par le registrar + un constat, parfois un avocat pour une injonction de récupération. En attendant, Search Console (si encore à vous) et les captures restent vos pièces assurance.

Ne donnez pas de nouveau mot de passe choisi par un freelance « le temps de voir ». Après reset, vous posez le mot de passe, vous le stockez, vous déléguez un FTP limité. Mots de passe dans l’ordre.

Récupérer archive, mails, DNS, Search Console

Une fois le panel à vous : archive + dump + logs + liste FTP + cron. Copie hors serveur. Puis seulement on parle nettoyage. Les MX et la zone DNS : notez-les avant de toucher. Un reset « tout par défaut » casse la messagerie en plus du site.

Search Console / Analytics / Ads : récupération via les emails de l’entreprise, ou via un enregistrement DNS que vous contrôlez enfin. Si le prestataire reste seul propriétaire Google : procédure de récupération Google, plus longue. Commencez le dossier.

Certificats, Cloudflare (compte à lui) : même combat. Si Cloudflare est chez lui, le DNS peut rester bloqué. Registrar A record en direct, en dernier recours, après avoir copié la zone.

Le CMS sans admin : base et panel

phpMyAdmin depuis le panel : table users, nouvel admin, ou reset de hash. WP-CLI si SSH. Ne réinstallez pas pour « avoir un login ». Voir compte admin bloqué et plus d’accès FTP.

Les contenus sont dans la base et `uploads`. Recréer le thème de mémoire perd l’historique et n’enlève pas le shell si vous pointez encore vers l’ancien tree. Archive d’abord.

Licences (thème, extensions) : souvent sur l’email du prestataire. Vous reconstruirez les licences plus tard. Ce n’est pas le jour J.

Ne pas recréer ailleurs « pour avancer »

La pression « on a besoin du site lundi » pousse à un WordPress neuf sur un Hostinger au nom du stagiaire. Vous perdez la copie, les logs, parfois le domaine si le DNS est mal basculé, et l’attaquant continue sur l’ancien A record que 50 % du net voit encore. Avancer, c’est l’archive et le reset panel.

Une page parking « maintenance, nouveau site bientôt » sur un hébergement que vous tenez, oui, si le DNS est à vous et que l’ancien vhost n’est plus servi. Ce n’est pas une recréation du catalogue.

Si le domaine n’est pas à vous, un nouveau domaine « temporaire » n’est pas une reprise, c’est un autre site. Traitez le titulaire.

Recruter la suite sans refaire la même serrure

Accès à votre nom, révocation à la fin de mission, documentation (où est le DNS, où sont les backups), 2FA, pas de mot de passe unique. Contrat : qui possède comptes et codes. C’est banal, c’est ce qui manquait.

Un prestataire qui exige « tous les accès sur mon email perso » : refusez. Un qui travaille dans votre panel, FTP limité, c’est le modèle.

Pour l’incident en cours, un intervenant sécu n’a pas besoin de « devenir l’agence ». Mission courte, constat, secrets à vous à la fin. Créer un dossier.

Checklist de reprise à J+0

Factures domaine / hebergement / Google. Relance écrite prestataire. Tickets registrar + hébergeur (identité). Adresse de secours. Captures de l’incident. Quand le panel tombe : archive, logs, reset secrets, puis nettoyage ou délégation. Ne pas commander un site neuf le jour J.

Si le site sert du phishing aujourd’hui : le registrar / l’hébergeur peuvent couper plus vite que votre récupération de compte. Signalez le motif abuse, même sans panel. L’URL sale en 200 est prioritaire. Faut-il couper.

Vous n’êtes pas bloqué « tant qu’il n’a pas répondu ». Vous êtes bloqué tant que le titulaire technique n’est pas vous. C’est ça le chantier.