# Reprendre l’hébergement d’un site laissé à l’abandon par un prestataire

> Accès partagés jamais révoqués, sauvegardes absentes, versions figées depuis des années : reprendre un hébergement mal documenté impose une méthode d'audit avant toute intervention.

- Auteur : WordPress Développement
- Publié le : 2023-03-26
- Mis à jour le : 2023-03-26
- Catégorie : Hébergement & serveurs
- URL : https://www.wpmoderne.fr/hebergement/reprendre-hebergement-site-abandonne-prestataire/

## L’essentiel

- Ne jamais présumer qu'une sauvegarde existe sans la vérifier
- Considérer tout accès existant comme potentiellement compromis
- Documenter avant de corriger, pas l'inverse

Combien de sauvegardes fonctionnelles restaient réellement disponibles sur ce site, alors que le contrat d'hébergement d'origine en promettait trois versions glissantes ? Aucune. C'est le premier constat d'un audit de reprise mené sur un site WordPress dont le prestataire initial avait cessé toute activité sans transmission organisée du dossier technique.

La refonte du contenu du site, souvent la première envie du client dans ce genre de situation, n'est volontairement pas abordée ici : avant toute refonte, il faut d'abord sécuriser ce qui existe, faute de quoi la refonte elle-même risque de s'appuyer sur des fondations qu'on ne maîtrise pas.

## Ce qu'on observe systématiquement sur ce type de dossier

Reprendre un hébergement abandonné revient presque toujours à découvrir un ensemble de pratiques problématiques accumulées au fil du temps, sans qu'aucune n'ait été corrigée faute de suivi actif. Les sections suivantes détaillent les antipatterns les plus fréquents, pourquoi ils posent problème, et comment les corriger sans casser un site déjà fragile.

## Antipattern 1 : des accès partagés jamais révoqués

> L'essentiel à retenir : Ne jamais présumer qu'une sauvegarde existe sans la vérifier ; Considérer tout accès existant comme potentiellement compromis ; Documenter avant de corriger, pas l'inverse

**Ce qu'on voit :** un unique compte administrateur WordPress, créé à l'installation du site, dont les identifiants ont visiblement été communiqués par courriel à plusieurs personnes au fil des années — collaborateurs successifs, stagiaires, prestataires ponctuels — sans qu'aucun compte distinct n'ait jamais été créé pour chacun.

**Pourquoi c'est un problème :** il devient impossible de savoir qui a réellement accès au site à l'instant de la reprise, ni de révoquer sélectivement un accès sans changer le mot de passe pour tout le monde. Aucune traçabilité des modifications n'est possible non plus, chaque action apparaissant sous le même identifiant générique.

**Quoi faire :** créer immédiatement un nouveau compte administrateur dédié à la reprise, changer le mot de passe de l'ancien compte partagé, puis le rétrograder en simple abonné plutôt que de le supprimer d'emblée, le temps de vérifier qu'aucun contenu ne lui est lié de façon irrécupérable.

## Antipattern 2 : des sauvegardes annoncées mais jamais vérifiées

**Ce qu'on voit :** un plugin de sauvegarde installé et apparemment actif, avec une planification quotidienne configurée, mais dont les fichiers de sauvegarde générés se révèlent, une fois testés, corrompus ou incomplets depuis plusieurs mois — souvent depuis une mise à jour du site qui a rompu silencieusement la compatibilité du plugin sans qu'aucune alerte ne remonte.

**Pourquoi c'est un problème :** une sauvegarde qui existe sans avoir été testée en restauration n'est pas une sauvegarde, c'est une hypothèse. Le risque se révèle uniquement le jour où on en a besoin, c'est-à-dire au pire moment possible.

**Quoi faire :**

- Effectuer immédiatement une sauvegarde manuelle complète, fichiers et base, avant toute autre intervention sur le site repris.
- Tester une restauration de cette sauvegarde sur un environnement de test isolé, jamais directement sur le site en production.
- Mettre en place une supervision de la sauvegarde automatique elle-même, avec alerte en cas d'échec, plutôt que de se fier à la simple présence d'un fichier généré.

## Antipattern 3 : des versions figées depuis l'installation

**Ce qu'on voit :** un cœur WordPress vieux de plusieurs années majeures, des extensions non mises à jour et une version de PHP dépréciée depuis longtemps par son éditeur, le tout laissé en l'état par crainte de casser un site qui « fonctionne encore ».

**Pourquoi c'est un problème :** chaque version non mise à jour accumule des failles de sécurité connues et documentées publiquement, rendant le site une cible facile pour des attaques automatisées qui scannent précisément ce type de version obsolète.

**Quoi faire :** planifier une remise à niveau progressive, jamais en un seul saut brutal, en commençant par les extensions les plus critiques pour la sécurité, testées une par une sur l'environnement de recette créé à cette occasion.

## Antipattern 4 : aucune documentation transmise

**Ce qu'on voit :** ni schéma d'architecture, ni liste des extensions personnalisées, ni explication des éventuelles modifications apportées directement au cœur ou aux fichiers du thème parent — pratique elle-même déconseillée mais parfois découverte a posteriori.

**Pourquoi c'est un problème :** sans documentation, toute intervention future repose sur une exploration à l'aveugle, avec un risque constant de casser une fonctionnalité dont personne ne connaît plus l'existence ni l'utilité réelle.

**Quoi faire :** documenter systématiquement chaque découverte au fil de l'audit, avant même de corriger quoi que ce soit, pour constituer la documentation qui aurait dû exister depuis le début.

> Un principe qu'on applique sur chaque reprise de ce type : ne jamais corriger avant d'avoir compris, et ne jamais présumer qu'un mécanisme fonctionne simplement parce qu'il semble configuré.

## En résumé

Reprendre un hébergement laissé à l'abandon impose une phase d'audit méthodique avant toute correction : vérifier les accès, tester réellement les sauvegardes, évaluer l'ampleur du retard de version et documenter ce qui existe. Cette discipline, plus lente qu'une intervention directe, évite de transformer une reprise de projet en incident de production évitable.