« L’accès existe encore ? » C’est la question posée en audit de routine, six mois après la bascule d’un site vers WordPress, en tombant sur un identifiant de connexion Wix toujours actif et associé à une adresse e-mail ne correspondant plus à personne dans l’organisation actuelle. Ce cas ne traite pas de la migration technique du contenu, terminée depuis longtemps et fonctionnelle : il porte sur ce qui n’a, lui, jamais été fait — la fermeture propre des accès de l’ancienne plateforme.
Comment cet oubli passe inaperçu si longtemps
Une migration de site se concentre presque toujours sur ce qui doit continuer à fonctionner : contenu transféré, redirections mises en place, référencement préservé. La question des accès à l’ancienne plateforme, elle, ne bloque rien visible pour les visiteurs ni même pour l’équipe qui utilise désormais le nouveau site au quotidien. Elle sort du champ de vision, précisément parce que plus personne ne s’y connecte volontairement, ce qui ne veut pas dire que personne ne le pourrait encore.
Ce que l’audit a retrouvé
Trois éléments distincts sont ressortis de la vérification :
- Le compte administrateur principal de l’ancienne plateforme, avec son mot de passe d’origine jamais changé depuis la création du site plusieurs années auparavant.
- Un compte collaborateur créé pour une personne ayant quitté l’organisation huit mois avant la migration, jamais désactivé ni sur l’ancienne plateforme ni ailleurs.
- Une intégration tierce connectée à l’ancienne plateforme pour l’envoi d’e-mails transactionnels, toujours autorisée à accéder au compte, alors que ce service n’était plus utilisé depuis la bascule.
Aucun signe d’exploitation malveillante n’a été trouvé lors de cet audit précis, mais la fenêtre de risque était bien réelle : n’importe lequel de ces accès, s’il avait été compromis par ailleurs (réutilisation de mot de passe, fuite chez un tiers), aurait permis de consulter des informations liées à l’historique du site, voire de tenter une usurpation via les paramètres de messagerie encore associés.
La procédure de clôture mise en place
Une checklist de fin de migration a été formalisée, distincte de la checklist technique de bascule, avec les étapes suivantes :
- Lister l’ensemble des comptes utilisateurs actifs sur l’ancienne plateforme, sans exception, y compris les comptes de service liés à des intégrations.
- Révoquer ou désactiver chaque compte individuellement, en conservant une trace écrite de la date de révocation.
- Retirer les autorisations accordées aux intégrations tierces connectées à l’ancien compte, plutôt que de simplement cesser de les utiliser.
- Changer le mot de passe du compte principal avant sa désactivation définitive, en dernière mesure de précaution si la plateforme conserve malgré tout une trace du compte.
- Programmer une vérification de suivi, plusieurs semaines après la bascule, pour confirmer qu’aucun accès résiduel n’a été oublié dans la précipitation du jour de la migration.
Pourquoi cette étape doit être planifiée, pas improvisée
Le jour de la bascule concentre déjà de nombreuses tâches sous tension : vérification des redirections, tests fonctionnels, communication aux parties prenantes. Ajouter la révocation des accès à cette liste déjà chargée conduit presque systématiquement à son report « à plus tard », un plus tard qui, dans ce cas précis, s’est étiré sur six mois sans qu’aucune date de suivi n’ait été fixée à l’avance.
Un contrôle applicable à toute migration future
La leçon retenue par l’équipe dépasse le cas de cette plateforme particulière : chaque projet de migration, quelle que soit la plateforme d’origine, doit désormais inclure une date de vérification post-migration inscrite au calendrier dès le lancement du projet, avec un responsable clairement désigné pour la conduire, indépendamment de la personne ayant piloté la bascule technique.
En résumé
Une migration réussie sur le plan technique peut malgré tout laisser une porte ouverte, simplement parce que personne n’a formellement fermé l’ancienne. La révocation des accès mérite sa propre checklist, sa propre date planifiée et son propre responsable, séparés de la charge du jour de bascule.
