Pourquoi la maintenance de votre site web est indispensable

Un site sans maintenance ne tombe pas en panne du jour au lendemain. Il se dégrade lentement, puis casse au pire moment, en général pendant que vous faites autre chose.

Grégory Administrateur systèmes
Publié le
Lecture 7 minutes
Partager

Un site web n’est pas un objet fini. Il repose sur un serveur, un langage, un socle applicatif et des extensions, tous mis à jour par d’autres, à leur rythme. Ne rien faire n’est pas un statu quo : c’est un décalage qui s’accumule.

Ce qui arrive à un site laissé seul

Les failles connues deviennent publiques. Une mise à jour de sécurité annonce la faille qu’elle corrige. À partir de là, des robots parcourent le web à la recherche des sites qui ne l’ont pas appliquée. Ce n’est pas un ciblage, c’est un balayage : la taille de votre entreprise n’y change rien.

Les versions se décalent. L’hébergeur fait évoluer la version de PHP, une extension exige une version plus récente du socle, une autre n’est plus compatible. Chaque mois d’attente rend la remise à niveau plus longue, jusqu’au point où elle devient un chantier à part entière.

Les choses cassent sans prévenir. Un formulaire qui n’envoie plus rien, un module de paiement qui refuse une carte, une page qui s’affiche de travers sur la dernière version d’un navigateur. Personne ne le signale : les visiteurs partent, et le constat arrive des semaines plus tard par la baisse des demandes.

Les trois natures d’intervention

La maintenance corrective répare ce qui est cassé. C’est la plus visible et la seule que tout le monde accepte de payer, parce que le problème est devant les yeux.

La maintenance préventive applique les mises à jour, surveille les sauvegardes, contrôle les certificats et les journaux d’erreur. C’est la plus rentable et la plus difficile à justifier, puisqu’un mois où rien ne se passe ressemble à un mois où rien n’a été fait.

La maintenance évolutive fait avancer le site : nouvelle fonction, adaptation à un nouveau besoin, montée de version majeure. Elle relève d’un budget de projet plus que d’un budget d’entretien.

Confondre les trois est la source de la plupart des malentendus entre une entreprise et son prestataire. Elles ne répondent pas aux mêmes urgences ni aux mêmes rythmes.

Le socle non négociable

Quel que soit le site, quatre points doivent être assurés par quelqu’un, en interne ou à l’extérieur.

  • Les mises à jour du socle et des extensions, appliquées après contrôle et non en aveugle.
  • Les sauvegardes, automatiques, stockées ailleurs que sur le serveur du site, et dont la restauration a été testée au moins une fois. Une sauvegarde jamais restaurée est une hypothèse, pas une garantie.
  • La surveillance de la disponibilité, pour être prévenu avant le premier client mécontent.
  • Le suivi des extensions abandonnées : une extension qui n’a plus reçu de mise à jour depuis longtemps est une porte ouverte, à remplacer avant qu’elle ne pose problème.

Reconnaître un site déjà en retard

Quelques signes suffisent. L’administration affiche des notifications de mise à jour depuis des mois. Personne ne sait dire où sont les sauvegardes ni comment on les restaure. Le site tourne sur une version de PHP qui n’est plus maintenue. Des extensions installées ne servent plus à rien depuis longtemps. Et surtout, personne ne sait qui est responsable de tout cela.

Si plusieurs de ces points s’appliquent, la question n’est plus de savoir s’il y aura un incident, mais quand. La remise à niveau coûte alors davantage qu’un entretien régulier, et elle se fait dans l’urgence plutôt qu’au calme.

Qui s’en charge

En interne, à condition qu’une personne identifiée en ait la charge, le temps et les accès. Une responsabilité partagée entre trois personnes est une responsabilité que personne n’exerce.

À l’extérieur, c’est l’objet de nos interventions de maintenance de site internet, avec le détail de ce qui est couvert. Sur WordPress en particulier, les mises à jour et la surveillance sont traitées ensemble, le sujet étant décrit sur notre page sécurité et maintenance WordPress.

Dans les deux cas, ce qui compte est de savoir répondre à une question simple : si le site tombe demain matin, qui s’en aperçoit et en combien de temps ?

Une sauvegarde qui n’a jamais été restaurée ne vaut rien. Le jour de l’incident, on découvre que le fichier est corrompu, que la base n’était pas incluse, ou que la restauration demande un accès que personne n’a. Le test de restauration se fait une fois, à froid, et change tout le reste.

Questions fréquentes

Questions fréquentes sur la maintenance d’un site

Fréquence, périmètre et responsabilité.

Les correctifs de sécurité s’appliquent rapidement, dans les jours qui suivent leur publication. Les autres mises à jour peuvent attendre un passage groupé mensuel, après contrôle sur un environnement de test. La règle inverse, tout mettre à jour automatiquement sans vérification, casse des sites régulièrement.

Le site continue de fonctionner, jusqu’au moment où il ne fonctionne plus. Entre-temps, les failles publiées s’accumulent et la remise à niveau devient un chantier, parce qu’il faut franchir plusieurs versions majeures d’un coup au lieu d’une à la fois.

Pour les correctifs de sécurité mineurs, elles sont utiles. Pour le reste, non : une mise à jour appliquée sans contrôle peut casser une fonction sans que personne le remarque. L’automatisation se complète d’une vérification, sinon elle déplace le risque au lieu de le réduire.

Oui, pour les mêmes raisons de sécurité : les robots qui cherchent des failles ne regardent pas la taille du site. Le volume de travail est simplement plus faible. Un site vitrine négligé finit régulièrement détourné pour héberger des pages qui n’ont rien à y faire.

Ailleurs que sur le serveur qui héberge le site. Une sauvegarde stockée sur la même machine disparaît avec elle, que la cause soit une panne, une erreur ou une intrusion. Et sa restauration doit avoir été testée au moins une fois.

Grégory

Administrateur systèmes

Il s'occupe de l'administration des serveurs, de leurs mises à jour et de leur sécurisation. Architecte serveur, il configure des VM et des services à la carte selon les besoins de chaque client, et tient la supervision des sites que nous hébergeons. Son péché mignon : l'open source.

LinkedIn
À lire ensuite