Dette technique : ce que votre site accumule sans vous prévenir

« Le site marche, on ne touche à rien. » C’est raisonnable en apparence, et c’est la phrase qui précède la plupart des interventions d’urgence que je traite.

Un site web n’est pas un objet stable. Son socle logiciel évolue, ses composants cessent d’être maintenus, ses versions atteignent leur fin de vie. Pendant ce temps, le site continue d’afficher ses pages normalement. L’écart se creuse sans aucun signal visible — jusqu’au jour où il devient bloquant.

Trois indicateurs à vérifier maintenant

La version de PHP. C’est le langage qui exécute la majorité des sites d’entreprise. Chaque version a une date de fin de support, au-delà de laquelle elle ne reçoit plus aucun correctif de sécurité. Une version obsolète ne casse rien immédiatement : elle vous laisse simplement sans protection contre les failles découvertes après cette date.

Cette information est visible dans le panneau de votre hébergeur. Si le numéro commence par 7, la situation demande une attention immédiate.

Les composants non maintenus. Sur une installation typique, une à deux extensions ne reçoivent plus de mise à jour depuis plus de deux ans. Chacune est du code exécuté à chaque visite, dont plus personne ne corrige les vulnérabilités. Ce sont les points d’entrée que je retrouve le plus souvent après une compromission.

Les sauvegardes non testées. Une sauvegarde qui n’a jamais été restaurée n’est pas une sauvegarde : c’est une hypothèse. J’ai vu des archives complètes mais inutilisables — base de données corrompue, fichiers partiels, procédure de restauration inconnue. On l’apprend toujours le jour où on en a besoin.

Pourquoi la panne arrive au pire moment

Ces éléments ne cassent pas isolément. Ils cassent en cascade, déclenchés par un événement extérieur.

Le scénario classique : l’hébergeur annonce la fin de support d’une version de PHP et impose une migration. Le site bascule sur la nouvelle version, et le thème n’est pas compatible. Il faut donc mettre à jour le thème, qui exige des versions récentes de plusieurs extensions. Deux d’entre elles ne sont plus maintenues et n’ont jamais été mises à jour. Il faut leur trouver des remplaçantes, ce qui implique de reconstruire les fonctionnalités concernées.

Ce qui devait être une case à cocher dans un panneau d’administration devient un chantier de plusieurs semaines. Et il se déclenche à la date choisie par l’hébergeur, pas par vous.

Ce que ça coûte des deux côtés

Une migration anticipée se planifie. Vous choisissez la période creuse, vous préparez un environnement de test, vous validez avant de basculer. Le site reste disponible pendant toute l’opération.

Une migration subie se fait dans l’urgence, souvent avec un site partiellement indisponible, sans possibilité de tester sérieusement. Le budget n’était pas prévu. Le prestataire habituel n’est pas forcément disponible.

L’écart entre les deux situations se compte rarement en pourcentages. Il se compte en multiples.

La routine minimale

Vous n’avez pas besoin d’un contrat de maintenance pour couvrir l’essentiel. Trois habitudes suffisent à éviter la majorité des situations bloquantes.

Chaque trimestre, vérifiez la version de PHP dans votre panneau d’hébergement et comparez-la au calendrier de fin de vie officiel. Cinq minutes.

Chaque trimestre, listez vos extensions et repérez celles dont la dernière mise à jour remonte à plus de dix-huit mois. Décidez pour chacune : remplacer, retirer, ou assumer sciemment le risque.

Deux fois par an, restaurez réellement une sauvegarde sur un environnement de test. Pas vérifier que le fichier existe : le restaurer et ouvrir le site. C’est le seul contrôle qui prouve quelque chose.

Si vous gérez plusieurs sites

Au-delà de trois ou quatre sites, la vérification manuelle ne tient plus. On oublie, on décale, et l’écart se creuse silencieusement sur celui qu’on regarde le moins.

Un outil de supervision centralisée règle la question : une vue unique sur les versions, les mises à jour en attente et l’état des sauvegardes de l’ensemble du parc. C’est le premier chantier que j’ouvre quand je reprends un portefeuille de sites — avant même de toucher au moindre contenu.

Parce qu’on ne peut pas arbitrer ce qu’on ne mesure pas.