Disponible pour missions & renforts d’agence · Réponse rapide, par la personne qui intervient

WhatsApp contact@allaux.fr
FR EN TR
allaux.
Urgence Parler de mon projet

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.

Décrire mon problème Discuter sur WhatsApp

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.

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

Décrivez votre besoin en 1 minute

Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.

Qu’attendez-vous en priorité d’un contrat de maintenance ?
Quelle plateforme ?
Le site est-il à jour aujourd’hui ? (facultatif)

Un site en retard de plusieurs versions demande une remise à niveau avant tout contrat.

À quel rythme imaginez-vous les interventions ? (facultatif)
Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Questions fréquentes

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.

Pages liées