Le WordPress d'aujourd'hui, décodé pour les développeurs

Performance

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.

Par Clément Hadrot • 12 février 2026 • 4 min de lecture • Aucun commentaire
Un audit de 60 sites de collectivités : trois réglages qui reviennent

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églageSites concernésGain moyen mesuré
Autoload wp_options non purgé28 / 60TTFB -180 ms en moyenne
Cache de page absent ou mal exclu31 / 60Temps de réponse divisé par 3 à 5
Compression Brotli non activée22 / 60Poids 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.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi