Le CMS de votre site web est-il encore maintenable ?

La question à poser au prestataire n’est donc pas seulement « le site est-il en ligne ? », mais « pouvons-nous démontrer qu’il est maintenu, surveillé et récupérable ? ». Les recommandations publiées par l’Agence nationale de la sécurité des systèmes d’information (ANSSI) et par Cybermalveillance.gouv.fr donnent une base concrète pour mener cette revue.

Un CMS doit être maintenu, pas simplement installé

Un système de gestion de contenu, ou CMS, associe un logiciel principal, des modules / extensions, un webdesign / thème, un environnement d’exécution et une infrastructure d’hébergement. Chacun de ces éléments peut évoluer indépendamment. Un site ancien n’est pas automatiquement vulnérable, pas plus qu’un site récent n’est automatiquement bien protégé : tout dépend de la capacité à connaître ses composants, à appliquer les correctifs et à vérifier le résultat.

La fiche de Cybermalveillance.gouv.fr consacrée à la sécurisation des sites Internet, mise à jour le 6 mai 2026, rappelle notamment l’importance des mises à jour, des accès limités, des sauvegardes, des extensions choisies avec soin et de la surveillance quotidienne. Le document de l’ANSSI Mise en œuvre sécurisée d’un CMS complète cette approche par dix pratiques de référence.

Les contrôles à revoir régulièrement

1. Connaître les composants et leur état

Demandez l’inventaire du CMS, de sa version, des extensions, des thèmes, de l’environnement technique et des services reliés. Pour chaque extension, le prestataire doit pouvoir indiquer son utilité, son éditeur, sa date de dernière mise à jour et la manière dont une faille est suivie. L’ANSSI recommande de limiter les extensions et les thèmes au strict nécessaire et de privilégier des composants activement maintenus.

Un inventaire n’a de valeur que s’il est daté. Il doit signaler les éléments obsolètes, ceux qui ne peuvent plus être mis à jour et les dépendances qui nécessitent une évolution du site. Cette liste permet aussi de distinguer une mise à jour courante d’un projet de modernisation, avec un budget et un calendrier différents.

2. Vérifier les accès d’administration

Combien de personnes peuvent modifier le site ? Les comptes sont-ils nominatifs ? Les accès d’anciens collaborateurs ou prestataires sont-ils supprimés ? Les droits correspondent-ils réellement aux tâches de chacun ? La réponse doit être précise, y compris pour l’hébergement, le nom de domaine, la base de données et les outils de déploiement.

L’ANSSI recommande des comptes d’administration dédiés, des protocoles sécurisés et l’authentification multifacteur pour les administrateurs fonctionnels du site. En pratique, le responsable de l’organisation doit savoir qui possède les droits les plus élevés et comment récupérer ces accès si le prestataire n’est plus disponible. Un mot de passe transmis dans un document partagé ou un compte utilisé par toute une équipe ne constitue pas un dispositif de continuité.

3. Examiner les sauvegardes comme un service vérifiable

Une sauvegarde doit couvrir le contenu du site et la configuration nécessaire à son fonctionnement : base de données, fichiers, paramètres et, selon le cas, éléments stockés par des services associés. Il faut connaître la fréquence, la durée de conservation, le lieu de stockage et la protection contre une suppression ou un chiffrement simultané du site et de ses copies.

Le contrôle le plus important reste la restauration. Demandez quand le dernier test a été réalisé, sur quel environnement et avec quel résultat. Une copie dont personne ne sait vérifier la cohérence ne permet pas de promettre un retour à la normale. Faites préciser le délai acceptable d’interruption et les données que l’organisation ne peut pas se permettre de perdre. Ces objectifs doivent être compatibles avec le contrat d’hébergement et les moyens réellement disponibles.

4. Vérifier les communications et l’exposition

Le site doit utiliser HTTPS avec une configuration adaptée. L’ANSSI mentionne également HTTP Strict Transport Security, ou HSTS, la Content Security Policy (CSP) et la sécurisation des cookies de session. Ces mécanismes ne remplacent pas la correction des failles du site, mais ils réduisent certaines possibilités d’attaque lorsqu’ils sont correctement configurés.

Le prestataire doit aussi pouvoir expliquer quels services sont exposés à Internet, quels ports sont ouverts et pourquoi. Le principe est simple : ce qui n’est pas nécessaire doit être désactivé ou interdit. Les flux entre le CMS, des services externes et l’hébergement méritent la même attention, notamment lorsqu’une extension récupère des contenus à distance.

5. Organiser la surveillance

Les journaux du CMS et de l’infrastructure peuvent aider à repérer une connexion inhabituelle, une modification inattendue ou une série d’échecs d’authentification. Encore faut-il savoir quels événements sont conservés, pendant combien de temps, qui les consulte et selon quelle procédure une alerte est traitée.

La surveillance ne signifie pas nécessairement une présence humaine permanente. Elle suppose au minimum des seuils, des notifications adaptées et une personne responsable de la décision. Une organisation doit savoir quoi faire si une page est modifiée sans autorisation, si une extension présente une faille critique ou si l’hébergement devient indisponible.

Ce qui peut attendre et ce qui doit être traité vite

Tous les écarts ne présentent pas le même degré d’urgence. Un composant inutile mais isolé peut être retiré lors d’une fenêtre de maintenance planifiée. En revanche, un compte administrateur inconnu, une extension abandonnée qui traite des données sensibles, une absence de sauvegarde exploitable ou une faille connue et activement exploitée appellent une action rapide.

Pour hiérarchiser, croisez quatre questions : le site est-il exposé ? Quelles données ou fonctions sont concernées ? Une action de contournement existe-t-elle ? Combien de temps l’organisation peut-elle rester sans service ? Le résultat doit être une liste courte avec un responsable, une échéance et un moyen de vérifier la correction. Un audit qui produit seulement un rapport volumineux, sans ordre de priorité, aide peu à décider.

Répartir les responsabilités avec le prestataire

La sécurité d’un site externalisé n’est pas entièrement transférée au prestataire. Celui-ci peut administrer le CMS ou l’hébergement, mais l’organisation reste responsable de ses comptes, de ses données, de ses décisions de mise à jour et de la continuité de son activité. Le contrat doit rendre cette répartition lisible.

Demandez notamment :

• qui surveille les alertes de sécurité et dans quel délai elles sont analysées
• qui valide une mise à jour et qui la réalise
• sur quel environnement les changements sont testés
• qui déclenche une restauration et qui en assume la coordination
• quels accès, fichiers et informations sont restitués en fin de contrat
• comment l’organisation est informée d’un incident et quelles preuves sont conservées

Ces questions ne demandent pas toujours une solution complexe. Elles évitent surtout les zones grises : un hébergeur peut protéger l’infrastructure sans maintenir les extensions du CMS ; un prestataire peut corriger le code sans gérer les comptes du nom de domaine ; une sauvegarde peut exister sans être incluse dans le périmètre de restauration.

Commencer par une revue courte et documentée

Pour une PME, une première revue peut tenir en quelques séances. Commencez par réunir l’inventaire, le contrat, la procédure de sauvegarde et la liste des personnes ayant accès au site. Faites ensuite une vérification technique ciblée : composants maintenus, mises à jour en attente, comptes et privilèges, HTTPS, exposition réseau, journaux et restauration.

Classez les résultats en trois niveaux : à traiter immédiatement, à planifier, à surveiller. Ne confondez pas la présence d’un outil de test avec une garantie de sécurité. Un test automatique peut révéler une configuration, mais il ne dira pas si une sauvegarde répond au besoin métier, si un compte doit encore exister ou si une extension est réellement indispensable.

Enfin, fixez une date de nouvelle revue. La maintenabilité n’est pas un état que l’on obtient une fois pour toutes. C’est une pratique régulière, faite d’inventaire, de mises à jour, de tests, de décisions et de preuves. En demandant ces éléments à son prestataire, une organisation ne cherche pas seulement à éviter une panne : elle se donne les moyens de comprendre son site et de décider plus sereinement de son évolution.