Que faire quand aucun mot de passe, aucune clé API et aucun accès serveur n’ont été transmis par le prestataire précédent ? La réponse la plus honnête est de ne rien tenter de deviner et de considérer que tous les accès existants sont compromis par défaut, faute de preuve du contraire. Cela impose de construire un registre de secrets entièrement neuf avant de rétablir quoi que ce soit.
Ce cas se présente régulièrement dans une reprise de client mécontent ou dans une rupture de contrat sans transition organisée. La tentation de brancher rapidement un outil de gestion de secrets existant se heurte à un problème plus fondamental : il faut d’abord savoir ce qui existe avant de savoir où le ranger.
Recenser avant de ranger
La première étape ne concerne pas l’outillage, mais l’inventaire. Sans documentation, il faut reconstruire la liste des accès nécessaires en observant ce qui existe réellement : configuration DNS, hébergeur, dépôt de code, service d’emailing transactionnel, éventuel CDN, compte de paiement si le site en dépend, et accès administrateur WordPress lui-même.
- Accès DNS chez le registrar (souvent le point le plus critique et le plus négligé).
- Accès à l’hébergeur (panneau, SSH, base de données).
- Accès au dépôt de code source, quelle que soit sa plateforme.
- Comptes administrateur WordPress, à recréer plutôt qu’à réutiliser.
- Clés API des services tiers connectés (emailing, paiement, recherche).
- Certificats TLS et leur méthode de renouvellement.
- Éventuels comptes de messagerie liés au nom de domaine du projet.
Le registre : un outil simple avant tout
Pour une agence qui reprend un seul projet dans l’urgence, un coffre-fort de secrets applicatif complexe n’est pas la priorité immédiate. Un gestionnaire de mots de passe d’équipe avec partage par dossier suffit dans un premier temps, à condition de respecter une structure stricte dès la création :
# Convention de nommage du registre neuf
projet-nom / hebergeur / acces-ssh
projet-nom / hebergeur / panneau-admin
projet-nom / dns / registrar
projet-nom / code / depot-git
projet-nom / wordpress / admin-principal
projet-nom / tiers / service-emailing
projet-nom / tiers / service-paiementCette convention plate mais lisible évite l’écueil classique d’un registre organisé par type de secret plutôt que par usage : en situation de crise, on cherche « l’accès au DNS de ce projet », pas « tous les mots de passe DNS de l’agence ».
L’ordre de rotation compte autant que la rotation elle-même
Changer tous les mots de passe en même temps semble prudent, mais crée un risque opérationnel si un accès change de main au mauvais moment. L’ordre recommandé commence par le DNS, car c’est le point qui permet de reprendre la main sur tout le reste (y compris la messagerie liée au domaine), puis l’hébergeur, puis le dépôt de code, puis WordPress, et enfin les services tiers, souvent les moins critiques dans l’immédiat.
Variante pour une reprise progressive
Si la reprise se fait projet par projet dans une agence qui gère plusieurs clients de l’ancien prestataire, le registre neuf peut être créé une fois pour l’agence, avec un sous-dossier par projet suivant la même convention. Cela évite de recréer la structure à chaque nouvelle reprise et permet de capitaliser sur les catégories déjà identifiées.
Autre variante : pour un client qui n’a pas les moyens de payer immédiatement un audit de sécurité complet, une rotation minimale porte uniquement sur le DNS et l’hébergeur dans un premier temps, le reste suivant dans les semaines qui suivent, avec un tableau de suivi partagé indiquant ce qui reste à faire.
Un accès non documenté n’est jamais un accès sûr, même s’il n’a jamais servi à rien de visible : le silence n’est pas une preuve d’innocence.
Notre verdict
Reprendre un projet sans transmission d’identifiants n’est pas d’abord un problème d’outillage, c’est un problème de méthode : recenser avant de ranger, ranger avant de faire tourner, et faire tourner dans un ordre qui protège le point d’entrée le plus critique en premier. Le registre de secrets neuf n’a de valeur que si sa structure survit à la personne qui l’a créé.
