# Un audit de 60 sites de collectivités : trois réglages qui reviennent

> Soixante sites de collectivités audités à la reprise d'un parc existant, et le même trio de réglages qui revient presque partout. Une checklist classée par gain mesuré, pour les prestataires qui héritent d'un parc déjà en place.

- Auteur : Clément Hadrot
- Publié le : 2026-02-12
- Mis à jour le : 2026-02-12
- Catégorie : Performance
- URL : https://wpmoderne.dev.wordpress-developpement.fr/performance/audit-60-sites-collectivites-trois-reglages/

## L’essentiel

- Trois réglages reviennent sur plus de la moitié des soixante sites audités
- Classement par gain mesuré, pas par facilité de mise en œuvre
- Une checklist pensée pour une reprise de parc, pas pour une création

Reprendre la maintenance d'un parc de soixante sites de collectivités territoriales, hérités de plusieurs prestataires successifs sur une décennie, impose un audit systématique avant toute promesse de délai ou de tarif. Plutôt que d'auditer chaque site en profondeur dès le premier mois, un audit rapide et standardisé a été mené sur l'ensemble du parc, pour prioriser les interventions selon un classement par gain mesuré plutôt que par facilité de mise en œuvre.

Le résultat le plus frappant n'a pas été la diversité des problèmes rencontrés, mais leur répétition : sur les soixante sites, trente-quatre présentaient exactement le même trio de réglages absents ou mal configurés, indépendamment du prestataire d'origine ou de l'ancienneté du site.

## Réglage n°1 : l'autoload de wp_options jamais purgé

Sur vingt-huit des trente-quatre sites concernés, la table `wp_options` contenait plusieurs milliers de lignes marquées en autoload, chargées à chaque requête même quand leur contenu n'était plus utilisé depuis des années, souvent des résidus de plugins désinstallés sans nettoyage de leurs données. Une requête simple a permis de quantifier le problème sur chaque site :

```
SELECT SUM(LENGTH(option_value)) AS taille_octets, COUNT(*) AS nombre_lignes
FROM wp_options
WHERE autoload = 'yes';
```

Sur le site le plus touché, cette requête a révélé plus de 4 Mo de données chargées en autoload à chaque affichage de page, pour un gain immédiat une fois les options orphelines identifiées et purgées via `wp option delete` en ligne de commande, plugin par plugin désinstallé.

> L'essentiel à retenir : Trois réglages reviennent sur plus de la moitié des soixante sites audités ; Classement par gain mesuré, pas par facilité de mise en œuvre ; Une checklist pensée pour une reprise de parc, pas pour une création

## Réglage n°2 : aucun cache de page actif ou mal exclu

Sur trente et un des trente-quatre sites, soit aucun mécanisme de cache de page n'était activé, soit il l'était mais avec des règles d'exclusion trop larges qui désactivaient le cache sur des pans entiers du site sans raison fonctionnelle claire (souvent héritées d'un bug ancien jamais réexaminé). Le gain de temps de réponse à la simple activation ou correction du cache de page a constitué, à lui seul, l'intervention la plus rentable de tout l'audit.

| Réglage | Sites concernés | Gain moyen mesuré |
| --- | --- | --- |
| Autoload wp_options non purgé | 28 / 60 | TTFB -180 ms en moyenne |
| Cache de page absent ou mal exclu | 31 / 60 | Temps de réponse divisé par 3 à 5 |
| Compression Brotli non activée | 22 / 60 | Poids transféré -15 % en moyenne |

## Réglage n°3 : la compression Brotli jamais activée côté serveur

Vingt-deux sites servaient encore leurs assets uniquement en Gzip, alors que le serveur nginx sous-jacent supportait Brotli sans configuration supplémentaire à installer, juste un bloc de configuration jamais ajouté lors de la mise en service initiale. L'activation a représenté l'intervention la plus rapide de toute la checklist, pour un gain de poids transféré non négligeable sur les gros fichiers CSS et JS.

- Vérifier la présence du module Brotli avec `nginx -V 2>&1 | grep brotli` avant toute promesse de mise en œuvre rapide.
- Activer la compression sur les types MIME texte, CSS et JavaScript en priorité.
- Conserver Gzip en repli pour les clients qui ne supportent pas Brotli.

## Pourquoi ce trio revient autant

> Ces trois réglages ont un point commun : aucun n'est visible sans un audit actif. Un site qui « marche » ne signale jamais qu'il pourrait tourner trois fois plus vite avec un cache correctement configuré.

Aucun de ces trois problèmes ne provoque de panne visible ni de message d'erreur : le site fonctionne, simplement plus lentement que nécessaire, ce qui explique qu'ils survivent à plusieurs changements de prestataire sans jamais être corrigés. Un audit qui se limite à vérifier l'absence d'erreurs passe complètement à côté.

## Ce que la checklist a permis de prioriser

Plutôt que de traiter les soixante sites dans l'ordre alphabétique ou chronologique de reprise, le classement par gain mesuré a permis de concentrer les deux premières semaines sur les correctifs de cache de page, avant de passer aux purges d'autoload puis à l'activation de Brotli, dans cet ordre précis de rentabilité observée sur l'échantillon.

## Les trois réglages à retenir

Sur un parc hérité de plusieurs prestataires, ces trois vérifications suffisent à couvrir la majorité des gains rapides disponibles, avant même d'entrer dans un audit approfondi site par site. Elles ont l'avantage d'être mesurables en quelques minutes chacune, ce qui en fait un point de départ systématique pour tout prestataire qui reprend un parc de sites publics existant.