Maintenance CMS de site web : comment garder le site entre vos mains

Le cabinet déplace ses consultations du vendredi au matin. Sur le site web figure toujours l’ancien horaire, et l’accueil téléphonique se demande qui il faudrait appeler. Le webdesigner de l’époque a changé de métier depuis, et les e-mails ne lui parviennent plus. Personne dans le cabinet ne sait s’il existe seulement un identifiant ni où il est conservé. Ce scénario est inventé, mais le schéma qui se cache derrière ne l’est pas.

Dans de telles situations, ce n’est que rarement la technique qui fait obstacle. Il manque la réponse à trois questions simples : qui peut modifier quoi, où se trouvent les accès, et que se passe-t-il si le prestataire fait défaut ? Le système lui-même, qu’il s’agisse d’un constructeur ou d’un CMS, est souvent tout à fait correct. Le problème, c’est une entreprise qui a fait construire un site web sans commander aussi son entretien.

C’est pourquoi nous ne considérons pas seulement le choix d’un système de gestion de contenu, mais tout le cycle de vie d’un site web : entretenir les contenus, maintenir les logiciels à jour, sauvegarder les données, surveiller l’hébergement et, en cas de besoin, pouvoir changer proprement. Qui comprend la « maintenance CMS de site web » comme une seule et même tâche prend de meilleures décisions que celui qui se contente de choisir un outil.

Une situation de départ typique dans une petite entreprise ressemble à ceci : le site web a été construit il y a quelques années par une personne extérieure, un identifiant figure sur un bout de papier ou dans un vieux courriel, et les modifications sont signalées au prestataire par message. Tant qu’il est joignable, cela fonctionne. C’est un arrangement qui repose sur la bonne volonté et n’a aucune structure, et la bonne volonté est une mauvaise base pour quelque chose qui accueille des clients tous les jours.

Le premier est la prise en main. Un système de rédaction que le développeur utilise avec plaisir est souvent, pour la responsable du cabinet, un labyrinthe de menus, de blocs et de champs où un faux clic suffit à détruire la mise en page. Qui a peur du système ne l’entretient pas, et un site non entretenu vieillit en silence. Des horaires, des prix ou des interlocuteurs périmés font perdre la confiance bien avant que quiconque s’en aperçoive.

Le deuxième est la maintenance invisible. Les mises à jour de sécurité du noyau, des extensions et du logiciel serveur ne se font pas toutes seules. Avec un CMS classique doté de plugins, des dépendances s’accumulent et deviennent obsolètes les unes après les autres. Un constructeur vous décharge de ce fardeau, mais vous lie à un fournisseur. Les deux voies sont légitimes, mais toutes deux ont des coûts qui disparaissent souvent dans les petites lignes des devis.

Le troisième est la propriété. Si l’agence enregistre le nom de domaine à son propre nom, que le code se trouve dans son dépôt et que l’hébergement passe par son compte, alors l’entreprise ne possède au fond que le contenu. Ce n’est pas par malveillance, mais souvent par simple commodité. Cela ne devient un problème que lorsqu’on veut ou doit changer.

S’y ajoute une quatrième raison, moins tangible : personne ne se sent responsable. La direction voit dans le site web un sujet de marketing, le marketing une question technique, et la technique l’affaire du prestataire. Un responsable désigné nommément, avec un suppléant, résout plus de problèmes que n’importe quelle décision logicielle. À défaut, les tâches restent en suspens jusqu’à ce qu’un incident les rende visibles.

Les constructeurs de sites, comme les grands services de création de sites, regroupent éditeur, hébergement, sécurité et mises à jour dans un seul abonnement. Pour une entreprise avec peu de pages et peu de demandes particulières, c’est souvent la solution la plus sereine, car il n’y a rien que vous deviez corriger vous-même. Les limites apparaissent avec une structure sur mesure, le réglage fin des performances et l’export : les contenus ne peuvent souvent être emportés que de façon restreinte ou dans des formats peu maniables.

Le CMS classique, dans les PME généralement WordPress ou un système similaire doté d’un écosystème de plugins, offre le plus grand choix de fonctions et de prestataires. En contrepartie, il exige une exploitation : mises à jour, sauvegardes, hébergement, durcissement. Bien entretenu, il est simple et peu coûteux à migrer ; non entretenu, il est la porte d’entrée la plus fréquente des attaques, car les failles des anciennes extensions sont publiquement documentées.

Les systèmes headless séparent le contenu de sa présentation. La rédaction travaille dans le CMS, et le site web est généré par une application distincte. Cela apporte rapidité, structure propre et liberté de conception. Mais cela apporte aussi deux systèmes qui doivent fonctionner ensemble et, le plus souvent, un développeur nécessaire à chaque modification importante de la présentation. Pour une entreprise artisanale de dix pages, ce n’est que rarement la bonne échelle.

Notre appréciation est en conséquence sobre. Les sites petits et stables relèvent souvent d’un constructeur ou d’un CMS classique configuré de façon allégée. Le headless se justifie quand plusieurs canaux utilisent le même contenu, qu’il existe des exigences élevées de performance ou qu’une équipe de développement est de toute façon impliquée. Ce qui fait la différence, c’est la réponse claire à la question de savoir quelle charge d’exploitation vous êtes prêt à assumer.

Un tableau de fonctionnalités induit ici en erreur, car presque chaque système finit par obtenir presque chaque fonction d’une manière ou d’une autre. Nous demandons plutôt ce qui va réellement se passer dans les trois prochaines années : à quelle fréquence les contenus changent-ils, qui les modifie, combien y a-t-il de types de pages, et qui s’occupe de la technique quand tout est calme ? Le résultat est rarement le nom d’un système, mais un profil auquel on peut confronter les systèmes.

La question de la responsabilité pèse particulièrement lourd. Un système qui exige une maintenance par des tiers doit effectivement mandater ces tiers. Cela signifie : un contrat de maintenance avec des prestations claires, des délais de réaction et une possibilité de résiliation, ou un responsable désigné en interne. Oublier les deux à la fois est l’erreur la plus fréquente.

S’y ajoute l’effort de changement. Nous estimons ce que coûterait un déménagement dans cinq ans et le prenons en compte. Un constructeur avec un mauvais export est bon marché aujourd’hui et coûteux plus tard. Un système ouvert à l’architecture bien documentée est plus cher aujourd’hui et serein plus tard. Les deux décisions sont défendables, pourvu qu’elles soient prises en connaissance de cause.

Une étape de contrôle a fait ses preuves : avant que le choix ne soit arrêté, nous déroulons un cas éditorial réaliste. Créer une nouvelle page de prestations, remplacer une image, modifier un horaire, remettre une page hors ligne. Celui qui l’essaie avec la personne qui devra le faire par la suite en apprend plus en une heure que dans n’importe quelle brochure produit. Si le test est difficile, c’est dû au système ou à son paramétrage, et les deux peuvent encore être modifiés au préalable.

Il faut se méfier des promesses du type « tout est simple ». Est simple ce que la personne concrète, à son poste de travail concret, accomplit sans demander d’aide, et non ce qui fait bonne impression dans une démo. Nous évaluons donc la prise en main à partir de vos propres contenus, et non des pages de démonstration du fabricant.

Pour un site web géré par trois personnes, une répartition simple suffit souvent : une administration qui répond de la structure et de la technique, et des rédacteurs qui peuvent modifier les contenus mais n’installent pas d’extensions et ne touchent pas aux réglages. Qui peut tout faire peut aussi tout détruire, le plus souvent sans mauvaise intention. Le principe du moindre privilège paraît strict, mais il protège des incidents les plus courants.

Un circuit éditorial n’a pas besoin d’être complexe. Ce qui compte, c’est que chaque modification soit attribuée à une personne et qu’il existe un point de validation de ce qui est visible lorsqu’il s’agit de questions juridiques, de prix ou d’affirmations médicales. Dans les petites entreprises, cela signifie deux paires d’yeux sur une page, pas davantage. Brouillon, aperçu, publication : chaque système devrait savoir séparer proprement ces trois états.

S’y ajoute un guide court et écrit. Il décrit quels champs existent, comment les images sont préparées, quelles formulations éviter et que faire en cas de doute. Deux pages suffisent. Le guide soulage la personne qui répondrait sinon à chaque question par téléphone, et c’est l’élément le plus important quand le personnel change.

Le design devrait lui aussi absorber les erreurs. Plutôt que des constructeurs de pages libres où chaque taille de police et chaque couleur sont au choix, des blocs fixes ont fait leurs preuves : bloc de texte, légende d’image, carte de prestation, encadré de contact. La rédaction remplit des champs, le design reste cohérent. Cela restreint et protège à la fois, car une page qui, après deux ans, a encore le même aspect que le premier jour est rarement le fruit de la discipline, mais de limites raisonnables.

Les mises à jour ne sont pas un projet, mais un rythme. Avec un CMS classique, vous vérifiez le noyau, les thèmes et les extensions à intervalles fixes, vous les installez d’abord sur une copie, puis en production. Les mises à jour de sécurité doivent être installées rapidement ; pour les sauts de version importants, une fenêtre planifiée suffit. Qui ne réagit que lorsque quelque chose est cassé paie nettement plus cher par la suite.

Moins d’extensions, c’est moins de surface d’attaque. Chaque plugin est du code tiers qu’il faut entretenir. C’est pourquoi, avant chaque installation, nous vérifions si une fonction peut aussi être réalisée sans module supplémentaire, si le module est activement développé et combien d’autres l’utilisent. Avec les constructeurs, le fournisseur prend en charge une partie de ce travail, mais la responsabilité des accès et des mots de passe reste la vôtre.

Les sauvegardes suivent une règle simple qui a fait ses preuves au fil des ans : plusieurs copies, en des lieux distincts, régulièrement, et surtout testées. Une sauvegarde qui n’a jamais été restaurée est un espoir. Nous fixons la fréquence des sauvegardes, la durée de conservation des versions et la personne habilitée à déclencher une restauration. Le test consiste notamment à démarrer réellement la copie sur un environnement séparé.

S’y ajoutent de petites sentinelles : surveillance de la disponibilité, alerte sur les certificats arrivant à expiration, notification en cas de connexions échouées. Elles n’empêchent pas les attaques, mais veillent à ce que vous soyez informé des problèmes avant vos clients.

En matière d’hébergement, ce sont moins les termes marketing qui comptent que des questions auxquelles on peut répondre concrètement : où se trouvent les serveurs, combien de temps les sauvegardes sont-elles conservées, quelle est la réactivité du support, et peut-on continuer à exploiter quelque temps une ancienne version du logiciel ? Un hébergement mutualisé bon marché suffit souvent pour des sites simples, mais devient juste lorsque plusieurs sites, de nombreux formulaires ou des réservations sont en service. Changer d’hébergeur est faisable si les sauvegardes et la documentation sont en ordre.

Les mots de passe sont la voie d’entrée la plus fréquente dans le système, et elle est banale. Un gestionnaire de mots de passe, des comptes individuels et l’authentification à deux facteurs éliminent la plupart des risques réalistes, sans qu’un projet de sécurité soit nécessaire. En complément, vous ne devriez pas laisser la page de connexion du CMS sans protection face au bombardement permanent de tentatives automatiques, et supprimer régulièrement les comptes inutilisés.

Le nom de domaine, le contrat d’hébergement, le code, les fichiers de design et les comptes d’analyse, de cartes ou de newsletter doivent être au nom de l’entreprise, avec une adresse e-mail qui n’est pas liée à une seule personne. Cela se met en place en une heure et épargne des semaines plus tard. Nous la tenons pour la mesure la plus importante de toutes, même si elle paraît la moins spectaculaire.

Le code soulève aussi la question des droits d’utilisation. Ce que vous avez payé, vous avez le droit de l’utiliser, mais dans quelle mesure, si cela peut être modifié ou transmis, c’est le contrat qui le règle. Pour les composants tiers comme les thèmes ou les extensions, ce sont leurs licences qui s’appliquent. Nous sommes ici volontairement prudents : il s’agit d’une orientation, pas d’un conseil juridique, et pour des affirmations engageantes, un contrat aux règles claires doit être sur la table, le cas échéant examiné par un juriste.

En pratique, un simple document de passation aide : une liste de tous les comptes avec titulaire, finalité et responsable, sans mots de passe en clair, qui sont conservés dans un gestionnaire de mots de passe. S’y ajoutent une description de l’architecture, des routines de maintenance et de la restauration. C’est l’assurance contre l’appel qui reste trois semaines sans réponse, et c’est la première chose dont un nouveau prestataire a besoin lors d’un changement.

Le prestataire fait défaut, l’hébergement est résilié, un constructeur modifie ses formules, ou le site est piraté. Chacun de ces cas est concevable, aucun n’est exotique. Un scénario de sortie décrit donc à l’avance ce qu’il faut faire dans une telle situation, qui le fait et combien de temps cela prend. Il n’a pas besoin d’être parfait, mais il doit exister.

En cas de compromission, un ordre fixe s’applique : mettre le site en mode maintenance, changer les accès, restaurer un état nettoyé à partir d’une sauvegarde, rechercher la cause, rattraper les mises à jour, et seulement ensuite le remettre en ligne. Avec un constructeur, le chemin reste plus court, car le fournisseur en assume une partie ; avec un CMS classique, il dépend de votre préparation. Qui a réutilisé des mots de passe commence par faire le ménage de ce côté.

Lors d’un changement de prestataire, ce qui compte, c’est que les contenus soient disponibles dans un format lisible. Les images et les textes se copient vite ; plus difficiles sont les redirections, les réglages SEO et les destinations de formulaires, qui se perdent facilement lors d’un déménagement. Nous recommandons de consigner la liste des adresses existantes avant un changement, afin qu’aucune page ne disparaisse involontairement après la migration.

Un cas particulier est celui des entreprises de plusieurs personnes avec un effectif changeant. Les comptes des collaborateurs partis devraient être bloqués le dernier jour de travail, et non des semaines plus tard. Cela vaut aussi pour les comptes auprès de services tiers qu’un site web n’utilise qu’indirectement, comme les outils de réservation ou les cartes.

Le bénéfice d’un site web bien entretenu se voit d’abord dans les petites choses. Les modifications sont publiées le jour même au lieu de plusieurs semaines après, et personne n’a besoin de demander de l’aide pour changer un numéro de téléphone. Cela se mesure simplement : délai entre le déclencheur et la publication, nombre de demandes de modification en attente, ancienneté de la dernière page contrôlée. Ce sont des indicateurs issus de votre propre entreprise, pas des valeurs de comparaison extérieures.

Côté technique, un contrôle des niveaux de mise à jour, une restauration documentée et les alertes de la surveillance sont utiles. La Search Console montre en outre si des erreurs, comme des pages inaccessibles, apparaissent. Le temps de chargement et la stabilité peuvent être suivis avec PageSpeed Insights et un coup d’œil aux temps de réponse. Des affirmations sur l’effet de tout cela sur les demandes ou le classement relèveraient de la spéculation.

Ce qui ne peut pas être promis doit être posé ouvertement sur la table. Aucun système n’est invulnérable, aucune sauvegarde ne remplace la rigueur sur les mots de passe, et aucun hébergement ne garantit une disponibilité ininterrompue. Les coûts non plus ne peuvent être annoncés de façon forfaitaire : ils dépendent du système, de l’effort et du prestataire. Ce qui est honnête, c’est une fourchette après un premier état des lieux, pas avant.

Un exemple de lecture : si, après un déclencheur, il faut régulièrement plusieurs jours pour qu’une modification soit en ligne, le goulet d’étranglement se situe le plus souvent du côté de la responsabilité, pas du système. Si la restauration révèle des lacunes lors du test, par exemple des fichiers multimédias manquants, c’est une bonne découverte, car elle intervient avant le cas d’urgence. De telles observations sont le véritable rendement d’un entretien régulier.

Un site web que l’entreprise peut entretenir elle-même est moins une question de système qu’une question d’organisation. Le meilleur CMS sert à peu de chose si les rôles sont flous, si les mises à jour restent en attente et si personne ne sait où se trouve le nom de domaine. À l’inverse, un constructeur simple mène loin si les responsabilités, les sauvegardes et la propriété sont réglées. La technique est interchangeable, l’ordre ne l’est pas.

Votre première étape ne coûte rien. Dressez une liste : nom de domaine, hébergement, CMS ou constructeur, newsletter, analyse, cartes, réservation, chacun avec titulaire, accès et responsable. Vérifiez si une personne dans l’entreprise saurait se connecter et modifier un horaire d’ouverture. S’il manque une réponse, vous avez trouvé votre tâche la plus importante avant même d’avoir demandé un devis.

Nous vous aidons volontiers à faire le point : un regard sur votre système existant, un avis honnête sur l’opportunité de rester ou de changer, et un concept d’entretien adapté à votre taille. Un contrat de maintenance est ici une option, pas une obligation. L’essentiel est que vous sachiez à tout moment où se trouve votre site et qui peut y toucher.

Deux principes ressortent de cet examen. Premièrement : choisissez le système en fonction de l’effort d’entretien que vous pouvez réellement assumer, et non de l’étendue fonctionnelle dont vous aurez peut-être un jour besoin. Deuxièmement : mettez par écrit ce qui se trouvait jusqu’ici dans la tête d’une seule personne. Les deux coûtent peu et évitent qu’un site web ne devienne une dépendance que l’on ne remarque qu’en cas d’urgence.