WordPress ou Drupal : les points de contrôle sécurité à imposer à votre CMS marketing

Pourquoi le débat « WordPress vs Drupal » est mal posé

Lorsqu'un responsable digital s'interroge sur la sécurité de son site marketing ou éditorial, la question arrive souvent sous une forme binaire : WordPress est-il moins sûr que Drupal ? En réalité, la sécurité d'un site repose bien moins sur le nom du CMS (Content Management System, le logiciel de gestion de contenu) que sur la manière dont il est configuré, maintenu et gouverné dans la durée.

Un site Drupal jamais mis à jour et administré par des comptes partagés sera plus vulnérable qu'un site WordPress rigoureusement maintenu, avec des extensions triées et un processus de correction rapide. À l'inverse, un socle technique robuste ne protège pas d'une gouvernance défaillante. La bonne approche consiste donc à raisonner par niveaux d'exposition, et à imposer des points de contrôle à chacun de ces niveaux, quel que soit le CMS choisi ou déjà en place.

Niveau 1 : le cœur du CMS

Le premier niveau d'exposition est le logiciel lui-même. WordPress comme Drupal sont des projets open source matures, dotés d'équipes de sécurité dédiées qui publient régulièrement des correctifs. Le risque ne vient donc pas de l'outil en tant que tel, mais de l'écart entre la version installée et la version maintenue.

Les points de contrôle à imposer :

• Version supportée : le site tourne-t-il sur une version majeure encore couverte par des correctifs de sécurité ? Une version en fin de vie ne reçoit plus de patchs, même en cas de faille critique.
• Délai d'application des correctifs de sécurité : lorsqu'une mise à jour de sécurité est publiée, en combien de temps est-elle appliquée sur votre site ? Ce délai doit être contractualisé, pas laissé à l'appréciation du prestataire.
• Trajectoire de montée de version : les migrations majeures (par exemple d'une version obsolète de Drupal vers une version supportée) sont-elles planifiées et budgétées, ou repoussées indéfiniment ?

Niveau 2 : plugins, modules et dépendances

La majorité de la surface d'attaque d'un CMS ne se situe pas dans son cœur, mais dans son écosystème d'extensions : plugins côté WordPress, modules contribués côté Drupal, auxquels s'ajoutent les bibliothèques tierces (dépendances) dont le projet a besoin pour fonctionner.

C'est ici que les deux écosystèmes diffèrent le plus dans leur culture. L'écosystème WordPress est très vaste et hétérogène, avec des extensions de qualité et de niveau de maintenance très variables. L'écosystème Drupal, plus structuré autour de sa communauté et de son équipe de sécurité, encadre davantage la publication des modules. Mais dans les deux cas, le principe de contrôle est le même :

• Inventaire exhaustif : disposez-vous d'une liste à jour de toutes les extensions installées, avec leur version et leur rôle ? Une extension oubliée est une extension non maintenue.
• Critères de sélection : chaque extension ajoutée est-elle évaluée (maintenance active, réputation, périmètre de permissions demandé) avant installation ?
• Suppression du superflu : les extensions désactivées mais non désinstallées, ou installées « au cas où », doivent être retirées. Chaque ligne de code en moins réduit la surface d'attaque.
• Suivi des dépendances : le prestataire surveille-t-il les alertes de sécurité sur les bibliothèques tierces, et pas seulement sur le CMS et ses extensions ?

Niveau 3 : rôles, comptes et droits d'administration

Un CMS marketing est par nature manipulé par des profils non techniques : équipes communication, marketing, filiales, agences externes. C'est un niveau d'exposition souvent négligé, alors qu'un compte administrateur compromis annule toutes les protections techniques.

Les exigences minimales à formuler :

• Comptes nominatifs : chaque utilisateur dispose de son propre compte. Les identifiants partagés (« le compte de la com ») rendent toute traçabilité impossible et compliquent la révocation des accès.
• Moindre privilège : un contributeur qui publie des articles n'a pas besoin des droits d'administration du site. Les rôles doivent refléter les besoins réels, pas la facilité.
• Authentification renforcée : mots de passe robustes imposés et, idéalement, authentification à deux facteurs pour les comptes à privilèges élevés.
• Revue périodique des accès : les comptes des collaborateurs partis, des stagiaires et des prestataires terminés sont-ils désactivés ? Une revue régulière des utilisateurs actifs devrait être un rituel, pas une exception.

Niveau 4 : hébergement, sauvegardes et environnement technique

Le CMS ne vit pas seul : il repose sur un serveur, un système d'exploitation, une base de données et souvent des services tiers. Les questions à poser à votre hébergeur ou prestataire :

• Chiffrement : l'ensemble du site est-il servi en HTTPS (protocole chiffrant les échanges entre le navigateur et le serveur) ?
• Sauvegardes testées : des sauvegardes régulières existent-elles, et surtout, la restauration a-t-elle déjà été testée ? Une sauvegarde jamais restaurée est une hypothèse, pas une garantie.
• Séparation des environnements : les mises à jour et développements sont-ils testés sur un environnement de préproduction avant d'être déployés en production ?
• Journalisation et supervision : des logs (journaux d'activité) sont-ils conservés et une supervision permet-elle de détecter un comportement anormal ?

Niveau 5 : le cycle de mises à jour et les procédures de correction

C'est le niveau qui distingue le plus nettement un site sous contrôle d'un site à risque. La sécurité n'est pas un état obtenu à la mise en ligne, c'est un processus continu. C'est précisément le rôle d'une TMA (Tierce Maintenance Applicative), c'est-à-dire un contrat confiant à un prestataire la maintenance corrective et évolutive du site dans la durée.

Ce que ce processus doit prévoir, noir sur blanc :

• une fréquence de mises à jour définie pour le cœur du CMS et les extensions ;
• un délai d'intervention engageant en cas de faille de sécurité critique publiée ;
• une procédure d'incident : qui est alerté, qui décide, qui communique, comment le site est restauré ;
• un reporting régulier permettant au responsable digital de vérifier que la maintenance annoncée est réellement effectuée.

WordPress ou Drupal : comment trancher pour un site marketing ?

Une fois ces cinq niveaux posés, le choix du CMS redevient une question de contexte plutôt qu'un débat idéologique. Quelques repères généraux :

• Drupal est souvent privilégié pour les écosystèmes complexes : plateformes multisites, organisations internationales, workflows de contribution avancés, exigences fortes de gouvernance et de gestion fine des rôles. Sa structure encadrée et sa gestion native de permissions granulaires en font un candidat naturel pour les organisations où de nombreux profils contribuent au site.
• WordPress reste un choix pertinent pour des sites marketing et éditoriaux plus resserrés, à condition d'appliquer une discipline stricte sur la sélection des extensions et la maintenance : c'est le mode d'exploitation, plus que l'outil, qui détermine le niveau de risque.

Dans les deux cas, un CMS sans contrat de maintenance, sans propriétaire clairement identifié des mises à jour et sans revue des accès constitue un risque évitable pour l'entreprise, indépendamment de la technologie.

Quand un audit de sécurité devient-il prioritaire ?

Certains signaux doivent déclencher un audit sans attendre :

• vous ne savez pas quelle version du CMS est en production, ni quand la dernière mise à jour a été appliquée ;
• le site a été développé par un prestataire qui n'assure plus le suivi, ou la connaissance technique a quitté l'entreprise ;
• personne ne peut lister les comptes administrateurs actifs ni les extensions installées ;
• une refonte, une migration ou une montée de version majeure est envisagée : l'audit permet alors de décider en connaissance de cause entre correction, migration ou refonte ;
• votre organisation est soumise à des exigences accrues (données sensibles, communication réglementée, image de marque exposée).

Un audit de sécurité CMS n'a pas vocation à produire un rapport anxiogène, mais à hiérarchiser les risques : ce qui doit être corrigé immédiatement, ce qui relève d'un plan de maintenance, et ce qui justifie une évolution plus structurelle. C'est cet arbitrage documenté qui permet à un responsable digital de défendre un budget de maintenance ou de refonte auprès de sa direction.