Ce texte ne traite pas la reprise d’un site Elementor hérité, un sujet couvert séparément avec ses propres pièges. Il s’agit ici d’un cas plus général et plus fréquent : un client change d’agence, et la nouvelle équipe hérite d’un pipeline de déploiement, de secrets d’accès, et d’une documentation d’une qualité toujours incertaine, laissés par un prestataire précédent parti sans forcément passer le relais correctement.
Cette checklist recense les quatorze points vérifiés systématiquement par l’agence avant d’accepter formellement la responsabilité technique d’un projet repris, dans l’ordre où ils doivent être traités : la sécurité d’abord, la compréhension ensuite, l’amélioration en dernier.
Sécurité : tout ce qui est hérité est potentiellement compromis
- Lister tous les accès existants : SSH, base de données, hébergeur, registre de domaine, comptes cloud. Un ancien collaborateur du prestataire précédent, parti en mauvais termes, peut encore disposer d’un accès actif si personne ne l’a révoqué.
- Régénérer systématiquement toutes les clés SSH utilisées pour le déploiement, sans exception, même si aucune fuite n’est suspectée : le principe de précaution coûte peu et évite une découverte tardive.
- Faire tourner tous les mots de passe de base de données, en particulier ceux stockés en clair dans un
wp-config.phpauquel plusieurs personnes ont pu avoir accès au fil des années. - Vérifier les jetons d’API tiers (paiement, e-mailing, analytics) et les révoquer au profit de nouveaux jetons générés sous le contrôle de la nouvelle équipe.
- Auditer les comptes administrateur WordPress existants et supprimer ceux qui ne correspondent à personne d’identifiable côté client actuel.
Compréhension : ne rien supposer, tout vérifier
- Lire intégralement chaque fichier de pipeline CI existant, ligne par ligne, sans se fier à son statut « vert » historique. Un pipeline qui semble fonctionner peut dépendre d’un secret expiré la semaine prochaine, ou d’un serveur que personne n’a documenté.
- Identifier où et comment sont stockés les secrets actuels : fichier
.envnon versionné mais présent sur le serveur, secrets GitHub Actions, coffre-fort tiers. Sans cette cartographie, impossible de savoir ce qui doit être régénéré ou simplement récupéré. - Vérifier que le dépôt Git fourni correspond réellement au code en production, en comparant un checksum de fichiers clés entre le dépôt et le serveur : il n’est pas rare de découvrir un écart, signe de correctifs appliqués en urgence directement en production sans jamais être reversés dans le dépôt.
- Tester une restauration de sauvegarde dans un environnement isolé, pour vérifier que les sauvegardes existantes sont réellement exploitables avant de s’y fier en cas d’incident futur.
- Recenser les extensions installées et leur statut de licence : une extension premium dont la licence expire au nom de l’ancien prestataire cessera de recevoir des mises à jour de sécurité sans que personne ne s’en aperçoive avant qu’il ne soit trop tard.
Documentation : combler les trous plutôt que faire semblant
- Écrire, même sommairement, ce qui n’est pas documenté et que l’audit vient de révéler : chaque zone d’ombre découverte doit être consignée pour ne pas devenir une surprise pour le prochain intervenant, y compris au sein de la nouvelle équipe.
- Identifier les dépendances externes non évidentes : un cron système sur le serveur, indépendant de tout pipeline versionné, qui exécute une tâche métier critique sans que rien dans le dépôt ne le mentionne.
- Vérifier la présence, ou l’absence, de tout environnement de staging fonctionnel : un projet repris sans environnement de test correctement configuré représente un risque immédiat pour la première intervention de la nouvelle équipe.
- Confirmer par écrit avec le client la liste des personnes ayant encore un accès quelconque au projet, et faire signer un état des lieux qui protège la nouvelle agence en cas de problème découvert après coup mais antérieur à sa prise en charge.
Un exemple qui justifie cette rigueur
Sur une reprise récente pour un client du secteur associatif, l’audit a révélé un cron système sur le serveur, totalement absent de toute documentation ou dépôt Git, qui synchronisait quotidiennement une base d’adhérents avec un service tiers de mailing. Sans cette vérification systématique du point 12, ce cron aurait été purement et simplement écrasé lors de la première intervention de maintenance serveur de la nouvelle équipe, avec des conséquences directes sur la communication du client vers ses adhérents.
| Phase | Objectif | Erreur fréquente si sautée |
|---|---|---|
| Sécurité | Éliminer les accès hérités non maîtrisés | Incident de sécurité imputé à la nouvelle agence |
| Compréhension | Vérifier ce qui fonctionne vraiment | Panne en pensant reproduire un état stable |
| Documentation | Ne pas reproduire le vide laissé par le précédent | Le prochain audit part de zéro, encore |
Un projet repris sans audit ne se reprend pas, il se subit, jusqu’au jour où un problème latent devient un incident dont personne ne comprend l’origine.
En résumé
Ces quatorze points ne visent pas l’exhaustivité théorique mais l’expérience accumulée sur plusieurs reprises de projets par l’agence, chacune ayant révélé au moins une surprise que l’audit systématique aurait permis d’anticiper. Le temps investi dans cette vérification, généralement deux à trois jours selon la complexité du projet, se facture au client comme une prestation à part entière, jamais comme un coût caché absorbé silencieusement par l’agence.
