Former un client non technique à l’éditeur de site WordPress est un exercice à part entière, très différent de la formation à l’ancien éditeur classique. Avec Gutenberg en mode édition de site complète, le client ne touche plus seulement au contenu d’une page : il a potentiellement accès aux templates, à la navigation, aux styles globaux, et à des réglages qui, mal manipulés, peuvent casser la cohérence visuelle de tout le site en quelques clics.
Après une dizaine de formations menées sur des projets d’agence, quelques constantes se dégagent. Certaines zones de l’éditeur se délèguent sans crainte particulière ; d’autres nécessitent un verrouillage systématique ou, à défaut, un accompagnement serré. Voici le bilan de ce que nous avons appris sur le terrain, avec les erreurs qui reviennent le plus souvent.
Ce qui se délègue sans risque
Dans l’immense majorité des cas, un client non technique peut gérer seul l’édition du contenu texte et image dans les blocs existants d’une page. C’est le cœur de l’usage quotidien : changer un titre, remplacer une photo, ajouter un paragraphe dans une section déjà construite. Le risque de casse y est faible, car la structure du bloc encadre la saisie.
Les patterns pré-construits (aussi appelés compositions) sont l’autre grande réussite de la délégation. En proposant une bibliothèque de patterns maison — un bloc « témoignage client », une section « avant/après », un bandeau d’appel à l’action — le client insère une structure déjà stylée sans avoir à composer lui‑même des colonnes ou des espacements. Il choisit dans une liste, remplit le texte, et le rendu reste cohérent avec le reste du site.
- Modification de texte et d’images dans des blocs existants
- Insertion de patterns pré-construits depuis la bibliothèque de motifs
- Réorganisation de l’ordre des blocs au sein d’une même page de contenu
- Ajout de nouvelles pages à partir d’un modèle de page existant
Ce qui reste sensible
À l’inverse, trois zones posent régulièrement problème lorsqu’elles sont laissées en accès libre : les templates, les styles globaux et la navigation.
Les templates définissent la structure commune à un ensemble de pages (l’archive du blog, la page d’accueil, le template d’article). Un client qui modifie par erreur le template au lieu de la page individuelle propage sa modification à toutes les pages qui l’utilisent — un problème classique que l’on retrouve régulièrement en support, où une image ajoutée « juste sur cette page » se retrouve en réalité sur l’ensemble du blog.
Les styles globaux, accessibles via le panneau Styles, permettent de changer la palette de couleurs ou la typographie de tout le site en quelques clics. C’est extrêmement puissant, et c’est justement pour cela que c’est dangereux entre des mains non averties : une couleur de texte changée « pour voir » peut rendre illisible l’ensemble d’un site en production.
La navigation, enfin, est un bloc à part qui mérite une vigilance particulière : sa structure (menus imbriqués, mega-menus) est facilement cassée par un glisser-déposer malheureux.
Verrouiller les blocs sensibles
WordPress propose un mécanisme natif de verrouillage des blocs, accessible via le menu contextuel Verrouiller (clic droit sur un bloc, ou options du bloc dans la barre d’outils). Trois niveaux sont disponibles : empêcher le déplacement, empêcher la suppression, ou les deux à la fois.
Sur nos projets, nous verrouillons systématiquement :
- La structure du header et du footer (déplacement et suppression bloqués)
- Les blocs de navigation, pour éviter la casse accidentelle du menu
- Les conteneurs englobants des patterns, en laissant le contenu interne modifiable
Pour les templates entiers, il est également possible de restreindre l’accès à l’éditeur de site via les capacités utilisateur (en limitant le rôle du compte client à editor plutôt qu’administrator), ce qui masque purement et simplement l’entrée Éditeur de site du menu d’administration pour ce profil. C’est souvent la solution la plus radicale, et la plus sûre, quand le client n’a réellement besoin que de gérer du contenu.
La documentation courte qui change tout
Sur les formations les plus réussies, un point commun ressort : une documentation courte, remise après la session, fait plus pour l’autonomie du client qu’une heure de formation supplémentaire. Nous sommes passés progressivement de documents de dix pages, jamais lus, à des fiches de trois pages maximum, structurées autour de tâches concrètes plutôt que de fonctionnalités.
Une bonne documentation client répond à la question « comment je fais pour… » et jamais à la question « comment fonctionne… ». Le client n’a pas besoin de comprendre Gutenberg, il a besoin de savoir changer une photo sur la page d’accueil.
La structure qui fonctionne le mieux chez nous tient en trois parties : une page « Modifier le contenu d’une page », une page « Ajouter un pattern », et une page « En cas de problème, qui contacter ». Chaque page comporte des captures d’écran annotées plutôt que de longs paragraphes.
Retours du terrain : les bugs remontés par les clients
Les tickets de support post-formation suivent un schéma assez récurrent. Voici les cas les plus fréquents observés sur nos projets :
- Modification d’un template au lieu d’une page, propageant un changement à toutes les pages concernées.
- Suppression accidentelle d’un bloc de navigation non verrouillé, via un raccourci clavier ou un glisser-déposer malheureux.
- Changement de couleur globale depuis le panneau Styles, pensant modifier uniquement un bloc.
- Duplication d’un pattern suivie d’une modification de sa structure interne, cassant sa cohérence avec les autres occurrences.
- Confusion entre l’aperçu (brouillon) et la publication réelle, avec la question récurrente « pourquoi mon changement n’apparaît pas sur le site ? ».
Ce dernier point, en apparence anodin, revient si souvent qu’il mérite désormais sa propre ligne dans toutes nos documentations : rappeler explicitement qu’il faut cliquer sur Enregistrer après chaque modification de page ou de template.
Nos recommandations pour une délégation sereine
Voici la synthèse de ce que nous appliquons désormais systématiquement sur les projets avec un client éditeur non technique :
- Limiter le rôle du compte client à ce dont il a réellement besoin, quitte à masquer l’éditeur de site.
- Verrouiller header, footer et navigation avant la livraison du site.
- Construire une bibliothèque de patterns maison couvrant 90 % des besoins de mise en page courants.
- Remettre une documentation de trois pages maximum, orientée tâches, avec captures annotées.
- Prévoir une session de formation courte (45 minutes) suivie d’une deuxième session un mois plus tard, une fois les vraies questions apparues.
- Mettre en place une sauvegarde automatique quotidienne, filet de sécurité indispensable quel que soit le niveau de verrouillage.
En résumé
L’éditeur de site donne aux clients une autonomie réelle sur le contenu, à condition de tracer une frontière claire entre ce qui relève de l’édition quotidienne et ce qui relève de la structure du site. Le verrouillage de blocs et la restriction des rôles ne sont pas des options secondaires : ce sont, avec une documentation courte et ciblée, les trois piliers qui permettent de déléguer sans craindre le prochain ticket de support un vendredi soir.
