Votre client a-t-il vraiment besoin de l’éditeur Elementor pour publier une actualité, changer un horaire ou remplacer une photo ? Dans la grande majorité des projets que nous livrons, la réponse est non, et c’est la première chose à établir avant de parler de formation. Un site Elementor mal transmis ne casse pas parce que le client est maladroit, mais parce qu’on lui a remis l’outil qui a servi à construire le site, avec tout son pouvoir de mise en page, alors qu’il avait besoin d’un outil pour en modifier le contenu. Ce onzième épisode de la série « Livrer un site Elementor en agence » propose une démarche en trois temps : choisir ce que le client peut toucher, verrouiller le reste par la structure du site, puis former et documenter. La sécurité des comptes, traitée dans le huitième épisode, n’est pas reprise ici.
Cartographier ce que le client modifiera réellement
Avant de créer le moindre compte, dressez avec le client la liste de ce qu’il modifiera dans les six mois. Pas ce qu’il pourrait modifier un jour : ce qu’il a l’intention de modifier, avec quelle fréquence. Sur un site vitrine, la liste ressemble presque toujours à ceci :
- publier des actualités ou des articles, plusieurs fois par mois ;
- mettre à jour quelques informations pratiques : horaires, coordonnées, tarifs ;
- remplacer des photos ou des textes sur des pages existantes ;
- ajouter de temps en temps une page sur un modèle déjà existant ;
- consulter les demandes reçues par formulaire.
Chaque ligne appelle une réponse différente. Les actualités se publient dans l’éditeur de WordPress et s’affichent grâce au gabarit d’article du Theme Builder : le client n’ouvre jamais Elementor. Les informations pratiques gagnent à être stockées une seule fois, dans des champs personnalisés affichés par les balises dynamiques d’Elementor Pro, plutôt que recopiées dans cinq widgets. Seules les modifications de pages existantes passent réellement par l’éditeur Elementor. Cette cartographie fixe le périmètre de la formation : on forme à ce qui est prévu, pas à Elementor dans son ensemble.
Le rôle WordPress découle de cette liste. Le rôle Éditeur permet de publier et de gérer tous les contenus, y compris ceux des autres utilisateurs, sans accès aux extensions, aux thèmes ni aux réglages du site : c’est le rôle par défaut que nous donnons au client. Le compte administrateur reste à l’agence, ou, si le contrat prévoit que le client en détienne un, il est nominatif, distinct du compte de travail quotidien, et sert uniquement aux opérations exceptionnelles.
Role Manager, Element Manager et composants : limiter sans frustrer
Le Role Manager d’Elementor règle, rôle par rôle, l’accès à l’éditeur. La documentation du Role Manager mentionne trois réglages : No access to editor, qui empêche le rôle d’ouvrir l’éditeur Elementor ; Access to edit contents only, qui permet d’ouvrir l’éditeur et de modifier le contenu des éléments existants sans en ajouter, déplacer ou supprimer ; et l’autorisation d’importer des fichiers JSON, que nous laissons désactivée pour un client. L’interface en ajoute un quatrième depuis Elementor 3.20, l’autorisation d’utiliser le widget HTML, que nous laissons également désactivée. Le Role Manager existe dans la version gratuite, mais l’accès limité au contenu est réservé à Elementor Pro. Si aucune case n’est cochée pour un rôle, ce rôle dispose de l’éditeur complet, sans import de fichiers JSON ni widget HTML.
L’accès limité au contenu est l’outil le plus efficace contre la mise en page abîmée : le client change un titre, une image ou un paragraphe, mais ne peut pas glisser une colonne ou supprimer une section. Sa limite est symétrique : le client ne peut pas non plus ajouter un bloc de témoignage à une page existante. Si ce besoin apparaît dans la cartographie, prévoyez-le autrement, par exemple avec un modèle de page complet qu’il duplique, ou en l’inscrivant dans les petites évolutions du contrat de maintenance.
Deux outils complètent ce réglage. L’Element Manager d’Elementor permet de désactiver des widgets pour tout le site, et, avec Elementor Pro, de restreindre l’usage de chaque widget par rôle : le widget reste affiché pour les visiteurs, mais un rôle non autorisé ne peut plus l’ajouter dans l’éditeur. Attention à la désactivation globale : l’aide d’Elementor prévient que des éléments désactivés alors qu’ils servent sur le site ne fonctionnent plus et peuvent même casser le site. Lancez toujours l’analyse d’utilisation avant de désactiver quoi que ce soit.
Sur un site construit avec les éléments atomiques de la version 4, les composants d’Elementor Pro offrent un verrouillage plus fin. Seuls les utilisateurs de niveau administrateur peuvent créer et modifier un composant ; un éditeur peut en insérer des instances et modifier les propriétés que l’administrateur a exposées, comme un texte, une image ou un lien, sans toucher à la structure ni au style. Une carte de service ou un bandeau d’appel à l’action deviennent ainsi des blocs que le client remplit sans pouvoir les déformer. La fonction de détachement d’une instance existe ; expliquez au client qu’elle coupe le lien avec le modèle, et qu’il ne doit pas l’utiliser.
Verrouiller par la structure plutôt que par l’interdiction
Les réglages de rôles limitent ce que le client peut faire ; la structure du site limite ce qu’il a besoin de faire. Plus le site repose sur des modèles, moins le client ouvre l’éditeur, et moins il a d’occasions de casser une mise en page. Concrètement :
- En-tête, pied de page et gabarits d’articles sont des modèles du Theme Builder, modifiés uniquement par l’agence ;
- Les contenus répétés (coordonnées, horaires, mentions) sont saisis une fois, dans des champs personnalisés ou une page d’options, et affichés par balises dynamiques ;
- Les listes (actualités, réalisations, équipe) sont des boucles alimentées par des articles ou des types de contenu, que le client remplit dans l’éditeur de WordPress ;
- Les pages libres restent l’exception, et chacune part d’un modèle prévu pour être dupliqué.
Un piège classique mérite une mise en garde explicite pendant la formation : ouvrir une page construite avec Elementor dans l’éditeur de WordPress, puis l’enregistrer. Selon la manipulation, la page affichée et la page modifiée ne correspondent plus. Notre règle, écrite noir sur blanc dans la documentation : une page construite avec Elementor se modifie uniquement avec Elementor, un article uniquement avec l’éditeur de WordPress.
La séance de prise en main
Nous organisons une séance d’une heure et demie au maximum, avec les personnes qui modifieront réellement le site, pas avec le décideur qui a signé le devis. Elle se déroule sur la préproduction décrite dans le troisième épisode, jamais sur la production : le client doit pouvoir se tromper sans conséquence. Le déroulé suit la cartographie :
- se connecter avec son propre compte et reconnaître son tableau de bord ;
- publier une actualité de bout en bout, image mise en avant comprise ;
- modifier un texte et une image dans une page Elementor, enregistrer, vérifier l’affichage sur mobile ;
- annuler une erreur avec l’historique des révisions d’Elementor ;
- consulter les demandes reçues par formulaire.
Chaque manipulation est faite par le client, pas par le formateur. La séance se termine par une erreur volontaire : le client supprime un texte, enregistre, puis le restaure lui-même depuis les révisions. C’est l’exercice qui fait le plus pour sa confiance, et le plus pour réduire les appels paniqués.
On ne forme pas un client à Elementor : on le forme à son site, et à rien d’autre.
La documentation livrée et les vidéos courtes
La documentation tient en quelques pages, une par tâche de la cartographie, avec des captures du site du client et non de démonstrations génériques. Chaque fiche indique ce qu’il faut faire, ce qu’il ne faut pas faire, et qui appeler. S’y ajoutent des vidéos de deux à trois minutes, enregistrées sur la préproduction, une par tâche. Les vidéos ont un défaut connu : elles vieillissent à chaque évolution de l’interface. Gardez-les courtes et nombreuses plutôt que longues et exhaustives, afin de pouvoir en remplacer une sans tout refaire.
Prenons un cas concret : un cabinet qui publie deux actualités par mois et met à jour une page d’équipe. Avec un compte Éditeur, l’accès limité au contenu, une boucle pour l’équipe alimentée par un type de contenu, et trois vidéos, le client n’ouvre l’éditeur Elementor que pour corriger un texte d’accueil de temps en temps. Les seules demandes reçues après la livraison portent sur des ajouts de sections, qui relèvent des petites évolutions, et non sur des pages à réparer.
Quand cette démarche ne convient pas
Elle ne convient pas au client qui dispose d’un graphiste ou d’un intégrateur interne : brider l’éditeur pour lui serait contre-productif. Donnez-lui l’éditeur complet, mais formez-le au système de design du site, couleurs et typographies globales, classes et variables, et convenez des modèles que lui seul peut modifier. Elle est également superflue pour le client qui ne modifiera rien lui-même : dans ce cas, la bonne formation est une page d’explications sur la manière de vous transmettre une demande, et le sujet bascule vers le contrat de maintenance. Enfin, aucun réglage de rôle ne compense une structure mal pensée : si chaque page est unique et construite à la main, le client devra l’ouvrir dans l’éditeur, et les restrictions ne feront que déplacer le problème.
En résumé
Laisser un client modifier son site Elementor sans le casser revient à réduire ce qu’il doit faire dans l’éditeur, puis à limiter ce qu’il peut y faire : un rôle Éditeur, l’accès limité au contenu, des modèles et des composants, une séance pratique sur la préproduction, une documentation courte et des vidéos ciblées. Le douzième et dernier épisode conclut la série avec le contrat de maintenance, qui prend le relais pour tout ce que le client ne fera pas lui-même.
