# Antipatterns d’un parc multisite de 500 collectivités après un audit > Un audit de sécurité externe sur un réseau WordPress multisite de 500 collectivités a révélé des erreurs d'isolation et de sauvegarde récurrentes. - Auteur : Clément Hadrot - Publié le : 2025-07-21 - Mis à jour le : 2025-07-21 - Catégorie : Outils & workflow - URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/antipatterns-parc-multisite-500-collectivites-audit/ ## L’essentiel - L'isolation entre sites d'un même réseau multisite n'est jamais automatique - Une sauvegarde globale n'est pas une sauvegarde par site - Les rôles super-administrateur s'accumulent sans jamais être révisés Un réseau WordPress multisite regroupant 500 sites de collectivités territoriales : sur le papier, une mutualisation efficace de la maintenance et des mises à jour. Un audit de sécurité externe, commandé après un incident mineur sur l'un des sites du réseau, a révélé une accumulation d'erreurs d'isolation et de gestion des sauvegardes qui, prises individuellement, semblaient anodines, mais dont l'effet cumulé exposait l'ensemble du réseau à un risque disproportionné par rapport à l'incident initial. Ce texte reprend les principaux antipatterns identifiés par cet audit, pourquoi chacun constitue un problème réel, et ce qui a été corrigé dans les mois qui ont suivi. ## Ce qu'on voit : des comptes super-administrateur jamais révisés L'audit a recensé dix-sept comptes disposant du rôle super-administrateur sur le réseau, capables d'agir sur l'intégralité des 500 sites simultanément. Plusieurs de ces comptes appartenaient à des prestataires n'ayant plus travaillé sur le réseau depuis plus de deux ans, sans qu'aucune révision périodique des accès n'ait jamais été formalisée. **Pourquoi c'est un problème** : un rôle super-administrateur non révisé constitue une porte d'entrée potentielle sur l'ensemble du réseau, y compris pour un compte dont les identifiants auraient été compromis chez un ancien prestataire sans lien direct avec l'agence actuelle. Sur un réseau multisite, l'ampleur du dommage potentiel est démultipliée par le nombre de sites concernés par un seul compte compromis. ## Ce qu'on voit : une sauvegarde unique pour l'ensemble du réseau > L'essentiel à retenir : L'isolation entre sites d'un même réseau multisite n'est jamais automatique ; Une sauvegarde globale n'est pas une sauvegarde par site ; Les rôles super-administrateur s'accumulent sans jamais être révisés La politique de sauvegarde en place reposait sur un unique export de la base de données globale du réseau, réalisé une fois par nuit, sans granularité par site individuel. Restaurer un seul site de la collectivité concernée par l'incident initial impliquait donc théoriquement de restaurer l'ensemble du réseau, ou de reconstruire manuellement les tables spécifiques à ce site à partir de l'export global. **Pourquoi c'est un problème** : dans un contexte où chaque collectivité gère des contenus qui lui sont propres, souvent soumis à des obligations de conservation spécifiques, l'absence de granularité par site rend toute restauration ciblée lente, risquée et sujette à erreur. Un incident affectant un seul site ne devrait jamais nécessiter une intervention sur l'ensemble du réseau pour être résolu. ## Ce qu'on voit : des extensions installées site par site sans contrôle centralisé Sur un réseau multisite, les extensions peuvent être activées globalement pour tout le réseau ou individuellement par site. L'audit a révélé que près de 40 % des 500 sites disposaient d'au moins une extension activée localement, en dehors du contrôle de l'équipe technique centrale, souvent installée directement par un agent de la collectivité disposant de droits d'administration sur son propre site. **Pourquoi c'est un problème** : chaque extension installée hors du processus de validation centralisé échappe à la politique de mise à jour et de contrôle de compatibilité appliquée au reste du réseau, créant potentiellement des failles de sécurité non détectées et des risques de conflit lors des montées de version groupées. ## Quoi faire : les corrections mises en œuvre - Révision trimestrielle obligatoire de la liste des comptes super-administrateur, avec justification écrite de chaque maintien d'accès - Mise en place d'une sauvegarde par site individuel, en complément de la sauvegarde globale du réseau, via un export automatisé par identifiant de site - Restriction des droits d'installation d'extensions au niveau réseau uniquement, avec une procédure de demande pour toute extension supplémentaire souhaitée par une collectivité - Mise en place d'une alerte automatique en cas d'activation d'extension en dehors du catalogue validé ## Ce que cet audit a changé dans notre méthode Au-delà des corrections techniques immédiates, cet audit a surtout révélé l'absence d'un processus de révision périodique, indépendant de tout incident déclencheur. Nous avons instauré depuis un audit interne annuel systématique sur chaque réseau multisite géré, plutôt que d'attendre qu'un incident, mineur ou majeur, en révèle les failles accumulées. > Un réseau multisite mutualise la maintenance, jamais automatiquement la sécurité de chaque site qui le compose. ## En résumé Les erreurs relevées sur ce réseau de 500 collectivités n'avaient rien d'exceptionnel individuellement : des accès jamais révisés, une sauvegarde trop globale, des extensions échappant au contrôle centralisé. Leur accumulation, en revanche, transformait un réseau mutualisé en surface de risque bien plus large que la somme de ses sites pris isolément.