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

Éditeur de site (FSE)

Éditeur de site pour collectivité à 500 pages : gouvernance des styles globaux

Organisation type des variations de style et des rôles habilités à les modifier, pour structurer un grand site public de collectivité en éditeur de site.

Par WordPress Développement • 4 février 2024 • 4 min de lecture • Aucun commentaire
Éditeur de site pour collectivité à 500 pages : gouvernance des styles globaux

Janvier 2024 marque le début du chantier de refonte du site d’une communauté de communes regroupant une quarantaine de communes, avec un objectif clair : passer d’un site vitrine d’une trentaine de pages à un site de services complet, environ 500 pages à terme, réparties entre démarches administratives, actualités et pages d’information par commune membre.

Ce billet décrit l’organisation retenue pour gouverner les styles globaux du thème bloc sur ce volume de contenu, ainsi que les rôles habilités à les modifier. L’audit RGAA complet et la configuration serveur du site ne sont pas traités ici, ces sujets faisant l’objet de chantiers distincts sur ce projet.

Le risque propre à un grand volume de pages

Sur un site de trente pages, une modification malheureuse des styles globaux se détecte vite : quelques clics suffisent à parcourir l’ensemble du site et repérer une régression visuelle. Sur cinq cents pages produites et alimentées par une douzaine d’agents aux compétences numériques variées, ce contrôle informel devient illusoire. Une modification de couleur de lien effectuée par erreur dans le Style Book pourrait rester invisible pendant des semaines sur des pages peu consultées.

La gouvernance mise en place répond à cette réalité en distinguant clairement deux populations : les développeurs habilités à faire évoluer la structure visuelle du site, et les agents de la collectivité, autorisés à créer et modifier du contenu, mais pas à toucher aux réglages globaux de style.

Une seule variation de style, verrouillée

Le thème bloc ne propose volontairement qu’une unique variation de style, sans alternative accessible depuis le Style Book. Le rôle editor, attribué aux agents référents de chaque service, se voit retirer la capacité edit_theme_options via un filtre sur map_meta_cap, ce qui masque l’entrée du Style Book dans l’éditeur de site sans toucher à leur capacité de modifier le contenu des pages.

L'essentiel à retenir : Une seule variation de style, verrouillée hors développement ; Rôle dédié pour les modifications ponctuelles autorisées ; Journal de changement tenu en dehors de l'historique natif
add_filter( 'map_meta_cap', function( $caps, $cap, $user_id ) {
    if ( 'edit_theme_options' === $cap && ! user_can( $user_id, 'manage_options' ) ) {
        return array( 'do_not_allow' );
    }
    return $caps;
}, 10, 3 );

Seul le rôle administrator, réservé au développeur référent et à un agent unique de la direction des systèmes d’information, conserve un accès complet aux réglages de style globaux.

Structurer les modifications ponctuelles autorisées

Certaines demandes de personnalisation restent légitimes : une commune membre souhaite parfois une couleur d’accent différente sur ses pages dédiées, pour marquer son identité propre au sein du site intercommunal. Plutôt que d’ouvrir l’accès aux styles globaux, ce besoin est couvert par une palette de couleurs supplémentaires définie dans theme.json, sélectionnable au niveau du bloc via les contrôles de couleur classiques, sans jamais toucher aux styles globaux du site.

Arborescence de la gouvernance

Styles globaux (theme.json)
├── Verrouillés : administrateur uniquement
│   ├── Palette de couleurs de marque
│   ├── Typographie et échelle de titres
│   └── Espacements et mise en page
└── Ouverts au niveau du bloc : agents référents
    ├── Couleurs d'accent par commune
    └── Mise en avant ponctuelle (blocs de groupe colorés)

Tracer les changements hors historique natif

L’historique des révisions de styles globaux natif à l’éditeur de site, bien qu’utile pour un usage individuel, ne suffisait pas pour cette gouvernance à plusieurs intervenants : il ne précise pas qui a effectué une modification ni pourquoi. Un tableau partagé, tenu manuellement par le développeur référent, consigne chaque changement de style global validé, avec sa justification et sa date, en complément de l’historique technique natif.

  • Toute demande de modification des styles globaux transite par le développeur référent, jamais directement par un agent de la collectivité.
  • Chaque changement est daté et justifié dans ce tableau de suivi, consultable par l’ensemble de l’équipe projet.
  • Une revue trimestrielle des couleurs d’accent par commune évite une prolifération incontrôlée de variantes au fil des demandes ponctuelles.

Sur un grand site institutionnel, la gouvernance des styles compte autant que leur qualité initiale : un beau design mal protégé se dégrade toujours avec le temps.

En résumé

Cette organisation, pensée dès le début du projet plutôt qu’ajoutée après coup, a permis d’éviter les dérives visuelles habituellement observées sur les grands sites publics alimentés par de nombreux agents aux profils variés. Elle repose sur un principe simple à retenir pour tout projet de taille comparable : séparer strictement ce qui relève de la structure visuelle globale de ce qui relève du contenu, et n’accorder un accès aux styles globaux qu’au strict nombre de personnes réellement en charge de leur cohérence.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Partager :

À propos de l'auteur

WordPress Développement

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

Voir tous ses articles

Dans la même veine

À lire aussi