# Mon site n’a pas été entretenu depuis des années

> Un site qui tourne depuis des années sans que personne n’y touche n’est pas un site en panne. C’est un site dont le risque a été reporté, et dont la facture arrive d’un coup — le plus souvent le jour où l’hébergeur change la version de PHP, ou celui où une faille connue est exploitée. Avant de décider quoi que ce soit, il faut mesurer l’écart réel.

- Source canonique : [https://allaux.fr/problemes/site-laisse-sans-maintenance](https://allaux.fr/problemes/site-laisse-sans-maintenance)
- Langue : FR
- Dernière mise à jour : 2026-08-03

## Réponse directe

> Commencez par une sauvegarde que vous détenez vous-même : archive du répertoire web et dump mysqldump de la base, stockés sur votre poste. Relevez ensuite la version du CMS, la version de PHP affichée dans le panneau d’hébergement et la date du fichier modifié le plus récemment, puis listez modules et extensions avec leur numéro de version. C’est cet écart, pas l’ancienneté du site, qui décide de ce qui doit être repris.

## Ce que « ça marche encore » veut vraiment dire

Un site figé continue de fonctionner tant que son environnement ne bouge pas. Le problème est que l’environnement bouge sans vous : l’hébergeur retire les anciennes versions de PHP, les navigateurs durcissent leurs exigences, les services de paiement changent leurs protocoles, les fournisseurs de messagerie renforcent leurs contrôles d’authentification.

Le site ne se dégrade donc pas progressivement : il fonctionne, puis il ne fonctionne plus, sans étape intermédiaire. C’est ce qui rend la situation trompeuse. L’absence de symptôme n’est pas un indicateur de santé, c’est simplement l’absence de changement extérieur récent.

## Six points à mesurer avant toute décision

1. **La version du CMS et son statut** — Reçoit-elle encore des correctifs de sécurité, ou est-elle en fin de vie ? La réponse change complètement le niveau d’urgence, et elle est publique.
2. **La version de PHP en cours et celle imposée à terme** — C’est le compte à rebours réel. Un hébergeur qui annonce le retrait d’une version fixe la date à laquelle le site s’arrêtera si rien n’est fait.
3. **L’état des modules et extensions** — Pour chacun : dernière version publiée, éditeur toujours actif ou non. Un composant abandonné ne recevra jamais de correctif, quelle que soit la faille découverte.
4. **Le volume et la nature des modifications faites dans le cœur** — Un cœur modifié directement empêche toute mise à jour propre. Chiffrer ce volume décide souvent à lui seul entre réparer et refaire.
5. **L’existence et la validité des sauvegardes** — Une sauvegarde jamais restaurée n’est pas une sauvegarde. C’est le premier point à rétablir, avant même la moindre mise à jour.
6. **La détention des accès** — Domaine, hébergement, comptes tiers, licences de modules. Un site ancien a souvent traversé plusieurs prestataires, et la propriété est rarement claire.

## Ne lancez pas une mise à jour majeure comme premier geste

> Sur un site en retard de plusieurs versions, la mise à jour n’est pas un bouton : c’est une opération à préparer, sur une copie, avec l’inventaire des composants incompatibles fait au préalable. Lancée directement en production, elle transforme un risque théorique en panne immédiate, et sans sauvegarde vérifiée il n’y a pas de retour en arrière.

## Réparer ou refaire : ce qui fait pencher

Je ne réponds jamais à cette question avant l’inventaire, parce que la réponse dépend d’éléments mesurables et non d’une impression. Plaident pour la remise à niveau : un cœur non modifié, des modules encore maintenus, un thème dont les personnalisations sont isolées, un catalogue et un historique de commandes qu’il serait coûteux de migrer.

Plaident pour la reconstruction : un cœur largement modifié, une majorité de modules abandonnés, un thème acheté dont l’éditeur a disparu, une version du CMS si ancienne que le chemin de migration passe par plusieurs paliers successifs. Dans ce dernier cas, l’effort de remise à niveau approche celui d’un site neuf, sans en donner les bénéfices.

Entre les deux, il existe une voie intermédiaire : sécuriser d’abord ce qui expose, puis planifier la refonte sans urgence.

Le contenu, les adresses et l’historique se conservent dans les deux scénarios ; c’est le code qui se remplace ou non.

## Pages liées

- **Modules et extensions abandonnés** — Comment évaluer le risque d’un composant dont l’éditeur ne publie plus rien. ([/securite/modules-et-extensions-abandonnes](/securite/modules-et-extensions-abandonnes))
- **Versions de PHP en fin de vie** — Pourquoi la version de PHP est le vrai compte à rebours d’un site figé. ([/securite/versions-de-php-en-fin-de-vie](/securite/versions-de-php-en-fin-de-vie))
- **Préparer une mise à jour majeure** — La méthode à appliquer avant de toucher à un site en retard de plusieurs versions. ([/guides/preparer-mise-a-jour-majeure](/guides/preparer-mise-a-jour-majeure))
- **Maintenance de site marchand** — Ce que couvre un suivi régulier, et ce qu’il ne couvre pas. ([/services/maintenance](/services/maintenance))

## FAQ

### Mon site n’a jamais eu de problème, pourquoi le mettre à jour ?

Parce que l’absence d’incident mesure la stabilité de l’environnement, pas celle du site. Les deux événements qui déclenchent la panne — retrait d’une version de PHP, exploitation d’une faille connue — ne dépendent d’aucun signe avant-coureur visible depuis le site.

### Combien de versions de retard peut-on rattraper ?

Techniquement beaucoup, mais rarement d’un seul saut. Les montées de version passent souvent par des paliers imposés, et chaque palier a ses propres incompatibilités de modules. C’est ce qui fait la durée de l’opération, pas la mise à jour elle-même.

### Peut-on sécuriser sans mettre à jour ?

On peut réduire l’exposition : restreindre les accès, retirer les composants inutilisés, corriger les droits de fichiers, surveiller. Cela fait gagner du temps et ne remplace pas la mise à jour, parce que le code vulnérable reste en place.

### Que se passe-t-il si je ne fais rien ?

Le site continue jusqu’au prochain changement extérieur. Je ne peux ni dater cet événement ni promettre qu’il n’arrivera pas ; ce que je constate, c’est que le coût d’une remise en état subie dépasse toujours celui d’une opération planifiée.

### Par quoi commencer si le budget est limité ?

Par une sauvegarde complète, testée en restauration, et par la reprise des accès. Ces deux points ne coûtent presque rien et transforment une situation irrécupérable en situation réparable.