# Surveiller la sécurité de 150 sites : notre tableau de bord en 2026

> Gérer la sécurité d'un site, c'est une discipline. Gérer celle de cent cinquante en parallèle en est une autre. Voici les indicateurs et la routine qui nous permettent de tenir le rythme.

- Auteur : Clément Hadrot
- Publié le : 2026-06-15
- Mis à jour le : 2026-06-15
- Catégorie : Sécurité
- URL : https://wpmoderne.dev.wordpress-developpement.fr/securite/surveiller-securite-150-sites-tableau-de-bord-2026/

## L’essentiel

- Un tableau de bord centralisé remplace la vérification site par site
- Quatre indicateurs suffisent à prioriser l'attention chaque semaine
- La routine hebdomadaire compte plus que l'outil choisi

Quand notre agence gérait une quinzaine de sites, une vérification manuelle hebdomadaire de chacun restait faisable : ouvrir le tableau de bord, regarder les mises à jour en attente, jeter un œil aux journaux d'activité récents. À cent cinquante sites, cette approche s'effondre complètement. Il ne s'agit plus de vérifier des sites un par un, mais de construire un système qui remonte automatiquement ce qui mérite une attention humaine, et de rien d'autre.

Voici comment nous avons structuré ce système, les quatre indicateurs qui composent notre tableau de bord, et la routine hebdomadaire qui transforme ces données en actions concrètes plutôt qu'en simple liste de chiffres consultée sans effet.

## Le principe : centraliser sans dupliquer les outils par site

Le premier choix structurant a consisté à éviter d'installer une extension de sécurité complète et indépendante sur chacun des cent cinquante sites, ce qui aurait multiplié les tableaux de bord à consulter séparément. À la place, un agent léger déployé sur chaque site remonte ses métriques vers une plateforme de supervision centralisée, construite autour d'une base de données unique interrogée par un tableau de bord commun à toute l'équipe.

## Les quatre indicateurs qui composent notre tableau de bord

> L'essentiel à retenir : Un tableau de bord centralisé remplace la vérification site par site ; Quatre indicateurs suffisent à prioriser l'attention chaque semaine ; La routine hebdomadaire compte plus que l'outil choisi

| Indicateur | Ce qu'il révèle | Seuil d'alerte |
| --- | --- | --- |
| Extensions et thèmes obsolètes | Écart entre version installée et dernière version stable disponible | Plus de 14 jours de retard sur un correctif de sécurité connu |
| Vulnérabilités connues actives | Croisement des versions installées avec une base de vulnérabilités à jour | Toute vulnérabilité classée critique ou élevée |
| Anomalies de connexion | Tentatives de connexion échouées en volume anormal, connexions depuis de nouveaux pays | Pic supérieur à trois fois la moyenne habituelle du site |
| Intégrité des fichiers du cœur | Comparaison périodique avec les sommes de contrôle officielles | Toute divergence, sans exception |

Ces quatre indicateurs ne couvrent volontairement pas tout le champ possible de la sécurité : ils ont été choisis parce qu'ils se calculent de façon fiable et automatisée sur l'ensemble du parc, sans faux positifs excessifs qui useraient l'attention de l'équipe à force d'alertes ignorées.

## La routine hebdomadaire, plus importante que l'outil

Un tableau de bord qui n'est consulté par personne ne sert à rien. Notre routine hebdomadaire répartit la charge sur trois personnes en rotation, chacune responsable d'un tiers du parc pour la semaine :

1. **Lundi matin** : revue des alertes accumulées pendant le week-end, avec traitement immédiat de toute vulnérabilité critique détectée.
2. **Mercredi** : passage en revue des mises à jour d'extensions en attente sur l'ensemble du tiers de parc assigné, avec déploiement groupé sur les environnements de recette avant la production.
3. **Vendredi** : vérification de l'intégrité des fichiers du cœur sur l'ensemble du parc, et clôture du rapport hebdomadaire partagé avec les trois membres de l'équipe.

## Ce que cette routine a changé concrètement

Avant la mise en place de ce système, la découverte d'une extension vulnérable sur un site du parc prenait en moyenne plusieurs semaines, souvent via un incident constaté plutôt qu'une détection proactive. Avec le tableau de bord actuel, ce délai est tombé à moins de vingt-quatre heures dans la grande majorité des cas, la détection automatisée précédant largement toute manifestation visible du problème sur le site concerné.

## Les limites que nous assumons

Ce système ne remplace pas un audit de code manuel approfondi sur les extensions personnalisées développées pour un client précis, ni une revue de sécurité complète avant la mise en production d'une nouvelle fonctionnalité sensible. Il couvre la surveillance continue d'un parc existant, pas le développement initial d'un projet. Les deux approches restent complémentaires, pas substituables l'une à l'autre.

Autre limite assumée : les quatre indicateurs choisis ne couvrent pas les vulnérabilités de type zero-day, non encore répertoriées dans les bases de données consultées au moment de leur exploitation initiale. Aucun système de surveillance automatisée ne comble entièrement cette zone d'incertitude, ce qui justifie de conserver, en parallèle, une veille manuelle sur les annonces de sécurité de l'écosystème.

> Un collègue résume notre philosophie ainsi : le tableau de bord ne remplace jamais le jugement humain, il évite simplement à ce jugement humain de se disperser sur cent cinquante vérifications répétitives chaque semaine, pour se concentrer sur les cas qui le méritent réellement.

## En résumé

Passer d'une quinzaine à cent cinquante sites suivis en parallèle a nécessité un changement d'échelle complet dans notre approche de la sécurité, du contrôle site par site vers un tableau de bord centralisé alimenté par quatre indicateurs choisis pour leur fiabilité, couplé à une routine hebdomadaire répartie sur toute l'équipe. Ce système continue d'évoluer à mesure que le parc grandit, mais son ossature reste stable depuis sa mise en place : détecter automatiquement, décider humainement.