Lorsqu’une relation avec une agence web, un développeur freelance ou un prestataire technologique prend fin, supprimer son utilisateur WordPress n’est généralement qu’une partie du travail. Le prestataire peut conserver un accès au domaine, à l’hébergement, aux sauvegardes, à l’e-mail transactionnel, aux dépôts de code ou aux intégrations qui permettent de modifier le site ou de consulter des données opérationnelles.
Le problème concret consiste à retirer ces accès sans rendre une boutique, les formulaires, les notifications de commande ou les renouvellements du domaine inopérants. La solution ne consiste pas à tout révoquer d’un seul coup : elle exige d’identifier les dépendances, de garantir d’abord le contrôle interne et d’appliquer une fermeture documentée et vérifiable.
La portée réelle des accès d’un prestataire web
Un site web d’entreprise ou un e-commerce dépend normalement de plusieurs services connectés. Outre l’administrateur du CMS, il peut exister des comptes chez le registrar du domaine, pour la gestion DNS, l’hébergement ou le cloud, un CDN, un pare-feu d’applications, des plateformes de paiement, des outils d’e-mail, de CRM, d’analytique, de supervision et de sauvegarde. Chaque service peut disposer de ses propres utilisateurs, jetons, clés ou mécanismes de récupération.
Le premier risque d’une fermeture précipitée est l’interruption : désactiver un compte qui renouvelle une crédential d’API peut arrêter l’envoi des commandes vers l’ERP ; retirer une adresse e-mail de récupération peut empêcher de récupérer un compte critique. Le second consiste à conserver des accès résiduels sans le savoir. L’OWASP recommande d’appliquer le principe du moindre privilège, de revoir régulièrement les autorisations et de refuser l’accès en l’absence d’autorisation explicite. [2]
Préparez un inventaire avant de révoquer le moindre accès
Avant de modifier des mots de passe ou de supprimer des utilisateurs, rassemblez un inventaire des actifs et des accès. Pour chaque actif, notez le service, l’URL ou l’identifiant, le propriétaire interne, les administrateurs, le prestataire ayant accès, l’usage opérationnel, la méthode de récupération et la date de retrait prévue. Ce registre permet de décider de l’ordre des changements et réduit la dépendance à des informations dispersées dans des e-mails ou des conversations.
Incluez au minimum le domaine et le DNS ; l’hébergement, le cloud, le CDN et le WAF ; WordPress et la boutique ; les paiements ; l’e-mail sortant et les formulaires ; le CRM et les automatisations ; les sauvegardes, alertes et la supervision ; les dépôts ; les clés SSH ; les jetons d’API ; les applications OAuth et les webhooks. Il est également utile de recenser les sessions actives et les comptes de service, car ils ne sont pas toujours supprimés lors de la suppression d’un utilisateur du CMS.
- Attribuez un responsable interne et un suppléant à chaque actif critique.
- Distinguez les comptes de personnes, les comptes partagés, les comptes de service et les identifiants d’intégration.
- Indiquez quels services affectent les ventes, le service client, les campagnes, les sauvegardes ou le renouvellement du domaine.
Garantissez la propriété, la récupération et le MFA au sein de l’entreprise
L’entreprise doit être propriétaire sur le plan administratif de ses actifs critiques, même si elle en délègue l’exploitation. Avant de retirer le prestataire, vérifiez qu’au moins deux personnes autorisées de l’organisation peuvent administrer ou récupérer les comptes les plus sensibles par des voies distinctes. Le NIST indique qu’il faut maintenir les comptes actifs en tant qu’identités uniques et enregistrer les authentificateurs associés ; disposer de plus d’un moyen d’authentification réduit la dépendance à un seul processus de récupération. [1]
Examinez les adresses e-mail et numéros de téléphone de récupération, les clés de secours et les facteurs d’authentification multifacteur. La CISA recommande d’activer le MFA partout où cela est possible, en commençant par les comptes administratifs et les accès qui traitent des informations sensibles. Si un facteur MFA doit être remplacé, faites-le selon une procédure validée : l’OWASP avertit que ce changement est une action à risque et recommande d’exiger une nouvelle authentification au moyen d’un facteur déjà enregistré, puis de la notifier par un canal indépendant. [3] [4]
Effectuez le retrait par phases et avec des tests opérationnels
Une séquence prudente consiste à créer d’abord des comptes internes nominatifs, à vérifier qu’ils fonctionnent, puis à réduire les autorisations du prestataire jusqu’à les retirer. Remplacez les comptes partagés par des comptes personnels disposant du rôle minimal nécessaire. Pour les identifiants techniques, planifiez une rotation : générez une nouvelle clé ou un nouveau jeton, mettez à jour l’intégration autorisée, vérifiez son fonctionnement, puis seulement invalidez l’élément précédent.
Exemple hypothétique : une boutique sous WordPress envoie des commandes vers un ERP au moyen d’une API configurée par son agence. Au lieu de supprimer immédiatement le prestataire, l’équipe identifie l’identifiant utilisé, en crée un nouveau sous le contrôle de l’entreprise, met à jour la configuration dans un environnement ou pendant une fenêtre de changement convenue, et vérifie qu’une commande de test autorisée arrive à la bonne destination. Elle révoque ensuite l’ancien jeton et l’accès administratif de l’agence.
- Vérifiez l’accès au domaine avant de modifier le DNS ou l’hébergement.
- Vérifiez les formulaires, les paiements, les commandes, les e-mails transactionnels et la restauration des sauvegardes après chaque change
- Fermez les sessions actives lorsque le service le permet et retirez les clés SSH, les jetons, OAuth, les webhooks et les autorisations dans
Documentez la fermeture et examinez les accès restants
Consignez chaque action de fermeture avec l’actif concerné, le compte ou l’identifiant retiré, la personne responsable, la date, le remplacement appliqué et le test effectué. Ce registre ne remplace pas un audit complet, mais il facilite la réponse aux incidents et permet de savoir ce qui reste en attente. Conservez également des instructions opérationnelles à jour, sans inclure de secrets dans des documents accessibles sans discernement.
Après le changement, planifiez une revue autorisée des comptes, des autorisations et des journaux disponibles afin de confirmer qu’il ne reste aucun accès inutile. La CISA recommande de retirer les comptes qui ne sont plus nécessaires, d’examiner périodiquement si les comptes restent nécessaires et d’appliquer le principe du moindre privilège. Si l’inventaire révèle des configurations inconnues ou des dépendances critiques, un audit de protection web à périmètre convenu peut aider à prioriser les corrections défensives sans affecter l’exploitation. [5]
Questions fréquentes
Suffit-il de supprimer l’agence en tant qu’administratrice de WordPress ?
Pas nécessairement. Cette action ne révoque pas à elle seule les accès à l’hébergement, au domaine, au DNS, aux sauvegardes, aux dépôts, à l’e-mail transactionnel, aux comptes de service, aux jetons d’API, aux applications OAuth ou aux sessions actives. Examinez chaque actif inclus dans l’inventaire avant de considérer la fermeture comme terminée.
Dois-je modifier tous les mots de passe à la fin de la relation ?
Donnez la priorité aux comptes critiques et à ceux qui ont été partagés ou gérés par le prestataire. En plus des mots de passe, examinez les méthodes de récupération, le MFA, les clés SSH, les jetons et les autorisations des intégrations. Le changement doit être effectué par phases afin d’éviter de perturber les services qui dépendent d’un identifi
Que faire si je ne sais pas qui contrôle le domaine ou une intégration ?
Ne retirez pas les accès à l’aveugle. Identifiez le registrar, les données de titularité, les comptes de récupération et les responsables actuels. Pour une intégration, déterminez quel système l’utilise, avec quel identifiant elle fonctionne et comment son bon fonctionnement est validé. En cas d’incertitude technique importante, délimitez une revue