Quels accès un prestataire doit (et ne doit pas) demander

Ce qu'un nettoyeur a vraiment besoin de voir

Pour constater et refermer, il faut les fichiers, les journaux, et un accès d'administration du CMS. Concrètement : le panel d'hébergement (ou un utilisateur FTP/SFTP créé pour lui), un export ou un accès lecture à la base, et un compte administrateur du site — pas le vôtre, le sien. Sans ça, on nettoie à l'aveugle.

Un devis honnête le dit avant que vous envoyiez quoi que ce soit. Si on vous promet un « scan à distance » sans jamais toucher le serveur, ce n'est pas un nettoyage : c'est un rapport. Les deux ont leur place ; ils ne se substituent pas. Le guide des premiers gestes fixe déjà l'ordre : copier, changer les accès, puis seulement déléguer.

Nous n'avons pas besoin de votre messagerie personnelle, de votre espace client Stripe, ni de votre session Windows. Si un détail de paiement ou de Search Console devient utile, on le demande à part, pour une action précise, puis on le rend.

• Panel hébergeur, ou utilisateur SFTP dédié et révocable.
• Compte admin CMS créé pour l'intervention, rôle administrateur.
• Accès base (phpMyAdmin restreint, ou dump fourni par l'hébergeur).
• Search Console en lecture si une blacklist ou du spam indexé est en jeu.

Ce qu'il ne doit jamais vous demander

Le mot de passe de votre boîte Gmail, Outlook ou de la messagerie « du dirigeant » n'est pas un outil de nettoyage. Un prestataire qui le réclame « pour voir les emails de l'hébergeur » vous fait transférer le risque : il peut lire vos devis, vos clients, vos relances d'assurance. Créez une adresse dédiée, ou transférez le ticket.

Idem pour le compte Apple, le Wi-Fi du bureau, le dossier comptable, ou « toutes les mots de passe du gestionnaire ». Un incident web n'ouvre pas un droit de regard sur l'entreprise. Si vous avez réutilisé le même secret partout, changez-le vous-même, dans l'ordre décrit dans quels mots de passe changer, puis donnez uniquement les trois accès utiles.

Méfiez-vous aussi de la demande de carte bancaire « pour un plugin premium » pendant l'attaque. Un nettoyeur sérieux n'achète pas d'extensions avec votre CB. Il compare aux zips officiels et vous dit quoi renouveler ensuite.

Panel, SFTP, admin : trois tiroirs distincts

Le panel (o2switch, OVH, Infomaniak) commande les utilisateurs FTP, les cron, parfois la base. Le SFTP ne voit que les fichiers. L'admin WordPress ou PrestaShop ne voit que ce que le CMS expose. Un attaquant qui a l'un n'a pas forcément les autres — et un prestataire non plus. Distinguez-les, même si « c'est le même mot de passe » aujourd'hui.

Donner uniquement wp-admin, c'est laisser le mu-plugin et le cron hors de portée. Donner uniquement le FTP, c'est rater un employé fantôme et une option injectée. Les dossiers que nous reprenons ont souvent reçu « juste le FTP » : la home redevient propre, la porte reste.

Si vous ne voulez pas ouvrir le panel, créez un utilisateur SFTP limité au dossier du site, plus un dump de base fourni par le support. C'est plus lent, c'est acceptable. Ce qui ne l'est pas : envoyer le mot de passe root du serveur dans le même SMS que le code Wi-Fi.

Coffre, mot de passe temporaire, révocation

Un mot de passe collé dans WhatsApp, Messenger ou un email « pour gagner du temps » reste dans l'historique des deux côtés. Un coffre (Bitwarden, 1Password, le partage chiffré de votre gestionnaire) avec une date d'expiration vaut mieux. À défaut, un mot de passe d'un usage, changé dès la fin de journée.

Notez qui a reçu quoi, et jusqu'à quand. C'est utile si l'assureur ou un successeur pose la question dans six mois. Ce n'est pas de la paperasse : c'est la même discipline que pour un ancien développeur encore dans les comptes.

Révoquez dès que le constat est livré, pas « quand vous aurez le temps ». Une session WordPress, une clé d'application, un utilisateur FTP oublié, c'est une porte aussi banale qu'un webshell — et plus fréquente.

• Partage via coffre, pas SMS ni fil Slack public.
• Mot de passe distinct du vôtre, jamais « le même que d'habitude ».
• Date de révocation écrite (fin d'intervention + 48 h max).

Prise de contrôle à distance : utile une heure, pas un mois

TeamViewer, AnyDesk ou Chrome Remote Desktop servent à vous montrer une Search Console, pas à « rester dessus au cas où ». Une session permanente sur le poste de la comptable est un incident en puissance : le prestataire, ou quiconque rejoue cette session, voit plus que le site.

Si un partage d'écran est vraiment nécessaire, vous lancez, vous restez devant, vous coupez. Pas d'accès démarrage, pas de mot de passe enregistré dans l'outil, pas de « je vous laisse le logiciel installé ». Un nettoyeur qui insiste pour une prise en main 24 h/24 sans justification écrite n'est pas le bon.

Pour le serveur, préférez SFTP et le panel. Le bureau à distance du PC n'accélère pas la comparaison des fichiers. Il accélère seulement la confusion entre « mon ordinateur » et « le site ».

Un compte à son nom, pas le vôtre

Créer `agence-avril` ou `site-pirate-intervention` dans WordPress, PrestaShop et le panel permet de voir les actions, puis de supprimer le compte d'un clic. Lui donner votre login « pour aller plus vite » mélange vos sessions, vos cookies, et parfois vos extensions de navigateur.

Même logique pour Search Console et Tag Manager : invitez une adresse professionnelle, rôle restreint si la lecture suffit. Ne transférez pas la propriété du domaine pour un nettoyage. Le détail des invitations GTM est dans Google Tag Manager détourné — le même réflexe s'applique ici, en positif.

Si le prestataire refuse un compte nominatif (« on a l'habitude d'utiliser le vôtre »), c'est un critère de choix, pas un détail de confort.

Après l'intervention : la checklist de clôture

Le jour où le site est propre n'est pas le jour où les accès restent ouverts « au cas où ça revient ». Vous voulez l'inverse : plus personne d'autre que vous (et, si vous le décidez, un mainteneur nommé) ne peut écrire.

Parcourez utilisateurs CMS, utilisateurs FTP, clés SSH, mots de passe d'application, invitations Search Console, utilisateurs GTM, webhooks, et le coffre. Changez le mot de passe que vous aviez communiqué, même via un gestionnaire. Si une page de maintenance était en place, retirez-la une fois le contenu légitime stable.

Demandez un écrit : trouvé, retiré, corrigé, ce qui reste à votre charge (refonte, montée de version, extensions abandonnées). C'est le même document que l'hébergeur et l'assureur attendent. Sans lui, vous n'avez qu'une facture.

• Supprimer le compte d'intervention (CMS + panel + SFTP).
• Révoquer les invitations Search Console / GTM / Business Manager.
• Tourner le mot de passe du panel, même s'il n'a « servi qu'une fois ».
• Conserver le constat, pas seulement le mail « c'est bon ».

Si l'agence d'hier a encore les clés

Beaucoup d'appels ne viennent pas d'un hacker lointain : l'ancien freelance a encore `admin`, le FTP de 2019, parfois le registrar. Avant d'accuser, on constate — copies, journaux, dates. Ensuite on révoque, on tourne, on documente. Le protocole est le même que pour un inconnu.

Ne négociez pas les accès « contre » un avoir ou un dernier correctif. Révoquez d'abord, discutez ensuite. Un accès qui sert de levier commercial est déjà un incident. Qui nous sommes n'a pas vocation à arbitrer un conflit de prestation ; en revanche nous pouvons dire ce qui est encore ouvert sur le serveur.

Si vous changez de prestataire à l'occasion du piratage, deux devis distincts : le nettoyage, puis la reprise de maintenance. Mélanger les deux, c'est exactement le piège décrit dans refonte et nettoyage en même temps.