L'ancien développeur a encore les accès : le piratage « interne »

Ce que « interne » veut dire concrètement

Un compte encore admin, un FTP de 2019, une clé SSH, le mot de passe du panel envoyé « une fois » dans WhatsApp, une invitation Search Console. Pas besoin d'exploit. Pas besoin de malveillance : l'oubli suffit. Parfois il y a malveillance, ou une rétention d'accès pour un impayé. Dans les trois cas, le geste technique est le même : ces accès ne doivent plus exister.

Nous ne tranchons pas un litige de prestation. Nous disons ce qui est encore ouvert. Qui nous sommes : intervention, pas arbitrage. Si vous avez besoin d'un constat pour un avocat, on date des faits techniques, pas des intentions.

Le cousin du sujet, plus banal encore : le stagiaire ou freelance encore admin six mois après la mission. Même famille, moins de tension humaine, même checklist.

Constater avant le conflit

Copiez le site hors serveur, figez les journaux, capturez les listes d'utilisateurs (CMS, panel, FTP) avant d'envoyer le mail accusateur. Réinstaller « pour se protéger » détruit ce qui permet de dater. C'est vrai pour un inconnu, c'est vrai pour un prénom que vous connaissez.

Un défacement signé, un message « payez la facture », un changement de DNS : notez l'heure, l'URL, l'appareil. Ça sert à l'assureur, parfois à la plainte. Ça ne remplace pas la révocation. Les preuves à conserver s'appliquent ici sans romantisme.

N'accusez pas sur la seule foi d'un plugin qui crie ou d'un fichier nommé `backup-agence`. Croisez deux canaux : un login, une IP, une date de création de compte. Puis fermez. L'ordre évite de calomnier un prestataire qui n'y est pour rien — et d'épargner le vrai compte fantôme.

Ce qu'on révoque en premier, sans débat

Panel, utilisateurs FTP, clés SSH, comptes CMS à privilège, mots de passe d'application, webhooks, invitations GSC/GTM, accès registrar si vous le détenez encore. Vous n'avez pas à prévenir pour « être fair-play » avant de fermer une porte sur un site déjà compromis. Vous prévenez après, si vous le souhaitez, une fois que plus rien ne s'écrit.

Tournez les secrets que cette personne a pu voir, y compris ceux « qui n'ont rien à voir » (SMTP, Stripe) s'ils ont transité par le même coffre ou le même mail. Panel différent du CMS.

TeamViewer / AnyDesk encore installé sur un poste du bureau : désinstallez. Un accès « au cas où le site tombe » n'est pas un contrat. C'est une session.

• Panel + FTP + SSH.
• Admins CMS et employés boutique.
• Invitations Google, Meta, Stripe, hébergeur.
• DNS / registrar si les identifiants ont circulé.

Registrar, factures, et le levier commercial

Le cas le plus toxique : le nom de domaine est encore au nom de l'agence, ou le renouvellement passe par leur carte. Ce n'est plus seulement un mot de passe. C'est une dépendance. Transfert vers votre compte registrar, contact administratif à vous, 2FA. Ça peut prendre des jours. Ça se lance le jour J, pas « quand on aura payé la dernière facture ».

Un prestataire qui refuse de rendre les accès contre un avoir transforme le site en otage. Documentez. Révoquez ce que vous contrôlez. Passez par l'hébergeur pour les reset. Ne « payez pas pour récupérer les clés » comme on paierait une rançon : le cadre n'est pas le même, le résultat (acheter un silence) se ressemble trop. Voir, pour le cadre rançon, pourquoi ne pas payer — ici, c'est un litige, un avocat, pas un wallet.

La responsabilité du prestataire et le contrat de maintenance sont des sujets juridiques. Le serveur, lui, n'attend pas l'assignation.

Ce que les journaux peuvent (et ne peuvent pas) dire

Un login FTP avec le compte `agence` à l'heure du défacement est un indice fort. Une IP d'un VPN partagé n'identifie personne. Un fichier déposé ne dit pas qui a tapé. On écrit ce que l'on voit, au conditionnel ce que l'on déduit.

Les hébergeurs gardent les logs peu longtemps. Demandez-les tout de suite, dans le même ticket que l'incident, sans raconter le feuilleton humain. Un ticket factuel passe mieux. Prévenir l'hébergeur.

Sans journaux, vous avez encore les listes d'accès et la copie. C'est suffisant pour fermer. C'est souvent insuffisant pour un tribunal. Ne retardez pas la fermeture en attendant une preuve parfaite.

Parler, ou seulement fermer

Si la relation est simplement oubliée (personne n'a révoqué à la fin du projet), un mail factuel après révocation suffit : « les accès ont été tournés, merci de détruire vos copies ». Pas besoin d'un roman.

Si la relation est conflictuelle, faites relire le message. N'envoyez pas d'accusation datée d'un scan antivirus. N'annoncez pas de plainte que vous ne déposerez pas. Fermez d'abord.

Ne redonnez pas un accès « pour qu'il explique ce qu'il a fait ». Il peut l'expliquer sur une copie figée, en visio, sans écriture sur la prod. Un accès de plus « pour comprendre » est un accès de trop.

Après : un inventaire d'accès pour de bon

Une page : qui a quoi, jusqu'à quand, comment on révoque. Panel, CMS, DNS, pubs, analytics, caisse, newsletter. C'est ennuyeux. C'est ce qui évite le prochain « interne ». Chaque nouveau prestataire entre dans cette page, avec une date de fin.

Les accès que l'on doit demander et ceux que l'on ne doit pas donner deviennent une règle d'entreprise, pas une exception du jour de crise.

Surveillance trente jours : nouvel admin, nouveau FTP. Si « l'interne » n'a pas apprécié la révocation, c'est dans cette fenêtre que ça se voit. Surveillance continue.

Décider sans transformer le dossier en procès

Ce soir : copie, révocation, rotation, ticket hébergeur. Pas de reconstruction, pas de nouveau domaine « pour lui échapper » — il n'a pas besoin de votre `.fr` s'il a encore le panel.

Le nettoyage du malware, s'il y en a un, est un dossier parallèle. Un accès interne n'exclut pas un plugin vulnérable ; un plugin vulnérable n'innocente pas un compte encore ouvert. On traite les deux.

Vous pouvez nous déléguer la partie technique (constat, fermeture, nettoyage) sans nous charger de la relation humaine. C'est même préférable : nous restons factuels, vous restez maître du discours.