Le 12 octobre, la série « IA et constructeurs de pages » s’est refermée sur le devis. Ce premier épisode ouvre la série « Livrer un site Elementor en agence », qui en prend la suite : douze épisodes pour suivre un projet du devis signé jusqu’au contrat de maintenance. Le point de départ n’est pas l’éditeur, mais le document qu’on rédige avant de l’ouvrir. Sur un site Elementor, presque toutes les reprises coûteuses viennent d’une décision qui n’a pas été prise au cadrage et qui a été prise, par défaut, dans l’éditeur.
Pourquoi un site Elementor se reprend trois fois
Le schéma est connu. Première reprise : les pages ont été montées une à une, avec leur propre en-tête et leur propre mise en page d’article, puis quelqu’un découvre qu’il fallait des gabarits du Theme Builder. Deuxième reprise : les couleurs et les tailles de texte ont été réglées élément par élément, et la charte change en cours de route. Troisième reprise : les vrais contenus arrivent trois semaines avant la mise en ligne, deux fois plus longs que les textes de remplissage, et les sections ne tiennent plus.
Aucune de ces reprises n’est un problème d’Elementor. Ce sont des questions de cadrage auxquelles l’outil répond très bien, à condition qu’on les lui pose dans l’ordre. Un cahier des charges utile pour un site Elementor n’est donc pas un document commercial : c’est une liste de décisions techniques, chacune avec un responsable et une date. Le devis, traité dans la série précédente, fixait le périmètre et le prix ; ce document fixe la façon de construire.
Arborescence et gabarits : ce que le Theme Builder doit savoir d’avance
L’arborescence ne sert pas seulement au menu. Sur un site Elementor Pro, elle détermine la liste des gabarits du Theme Builder et leurs conditions d’affichage. Pour chaque type de page, le cahier des charges doit dire s’il s’agit d’une page unique, montée à la main, ou d’un modèle appliqué à une série de contenus.
- Gabarits globaux : en-tête, pied de page, éventuellement un en-tête différent pour l’accueil ou pour une zone réservée.
- Gabarits de contenu : article seul, archive d’articles, page de résultats de recherche, page 404.
- Types de contenus personnalisés : réalisations, offres d’emploi, fiches produit hors boutique… Chacun appelle un gabarit « seul » et souvent une archive, avec des champs personnalisés à lister nommément.
- Conditions : quel gabarit s’applique où, et quelles exceptions sont prévues.
Ce dernier point paraît secondaire ; il conditionne pourtant le choix de licence. La page de tarifs d’Elementor précise que la formule Essential donne accès au contenu dynamique mais sans les champs personnalisés ni les types de contenus personnalisés. Si votre arborescence prévoit des fiches alimentées par des champs, la licence d’entrée de gamme ne suffit pas : le deuxième épisode détaille ce choix, mais c’est le cahier des charges qui doit faire apparaître le besoin.
Design system : décider V4 ou V3 avant la maquette
Depuis Elementor 4.0.0, publié le 30 mars 2026, l’éditeur atomique est déclaré stable et activé par défaut sur les nouvelles installations. Les sites existants, eux, ne basculent pas d’eux-mêmes. La foire aux questions officielle de la version 4 ajoute deux précisions qui pèsent directement sur le cadrage : les classes et les variables sont propres aux éléments atomiques et ne s’appliquent pas aux anciens widgets, et un même site peut mélanger widgets V3 et éléments V4 sur une même page.
Concrètement, le cahier des charges doit trancher trois questions.
- Quelle génération d’éléments ? Un nouveau site part logiquement sur les éléments atomiques, en ajoutant des widgets V3 seulement là où aucun équivalent n’existe. Une refonte partielle d’un site V3 peut rester en V3 ; il faut l’écrire, sinon chaque intégrateur choisira selon ses habitudes.
- Quels jetons de conception ? Couleurs, familles et tailles de texte, espacements : la liste des variables se décide avec le graphiste, avec des noms qui décrivent un rôle (« texte-secondaire ») plutôt qu’une valeur (« gris-clair »).
- Quelles classes globales ? Boutons, cartes, titres de section : la liste initiale et la règle de nommage. Le panneau Design System, arrivé avec la version 4.1.0, regroupe variables et classes et permet de les importer et de les exporter ; inutile pour autant d’en prévoir cinquante au cadrage.
La version 4.0 sait aussi synchroniser les variables de couleur et les classes typographiques V4 vers les couleurs et polices globales V3. Sur un site mixte, notez dans le document quelle source fait foi, sans quoi deux personnes modifieront la même couleur à deux endroits.
Contenus, formulaires et fonctions dynamiques : qui, quoi, quand
La rubrique contenus est celle qu’on bâcle le plus souvent, parce qu’elle engage le client. C’est précisément pour cela qu’elle doit être nominative. Pour chaque page ou type de contenu : qui rédige, qui fournit les visuels, dans quel format, à quelle date, et qui valide. Une colonne « longueur indicative » évite la troisième reprise évoquée plus haut : un titre d’accueil prévu pour six mots qui en compte quinze casse une section conçue pour la maquette.
Les formulaires méritent une fiche chacun : liste des champs, destinataires des notifications, message de confirmation, envoi éventuel vers un outil externe, et surtout devenir des données. Si les soumissions sont conservées dans le site, le cahier des charges fixe la durée de conservation et la personne qui y a accès ; c’est une question de conformité, pas de confort. Sur ce point aussi la licence intervient : la formule Essential inclut le constructeur de formulaires, mais la page de tarifs indique que la gestion des soumissions n’y est pas disponible. Le cinquième épisode reviendra sur les limites du widget Form.
Enfin, listez les fonctions dynamiques attendues : grilles de contenus filtrables, fenêtres surgissantes, zones réservées aux membres, conditions d’affichage selon l’utilisateur. Chacune a un coût de réalisation et parfois un prérequis de licence ; découvertes en recette, elles deviennent des avenants.
Langues, accessibilité, existant et licences
Les langues ne se résument pas à une liste. La structure des adresses compte, y compris pour la facture : la page d’aide d’Elementor sur les licences des sites multilingues indique qu’une seule licence suffit pour des sous-répertoires (exemple.fr/en/) ou des paramètres d’adresse, mais que chaque langue servie sur son propre sous-domaine ou son propre domaine demande sa propre licence. Choisir en.exemple.fr plutôt que exemple.fr/en/ n’est donc pas neutre.
Pour l’accessibilité, écrivez un niveau visé et une méthode de vérification : référentiel, niveau de conformité, pages de l’échantillon, qui teste et quand. Une mention vague du type « site accessible » ne protège personne et ne se vérifie pas en recette.
Pour l’existant, un inventaire de dix minutes évite les surprises. Si vous avez un accès en ligne de commande au site actuel, ces commandes WP-CLI suffisent à poser le décor ; la dernière n’est disponible que si Elementor est déjà installé.
wp core version
wp plugin list --status=active --fields=name,version,update
wp theme list --status=active
wp option get home
wp elementor system-info > inventaire-elementor.jsonEnfin, les licences et les comptes : qui achète Elementor Pro, au nom de qui, qui détient les polices payantes, les extensions commerciales, le compte d’hébergement et le nom de domaine. Le cahier des charges n’a pas à arbitrer le choix de licence ni d’hébergeur, traités dans les deuxième et quatrième épisodes, mais il doit nommer le titulaire de chaque compte. C’est ce tableau qui servira, au moment du contrat de maintenance, à rendre au client ce qui lui appartient.
La trame commentée, rubrique par rubrique
Voici la trame que nous utilisons, dans l’ordre où nous la remplissons avec le client. Chaque rubrique se termine par un responsable et une date.
- Objectifs et publics : deux ou trois objectifs mesurables, pas une liste de souhaits.
- Arborescence : pages uniques et types de contenus, avec leur volume estimé.
- Gabarits du Theme Builder : liste, conditions d’application, exceptions.
- Design system : génération d’éléments retenue, variables, classes globales initiales, source de vérité sur un site mixte.
- Contenus : tableau page par page (rédacteur, visuels, format, longueur indicative, date de remise, valideur).
- Formulaires : une fiche par formulaire, avec destinataires, stockage et durée de conservation.
- Fonctions dynamiques : grilles, filtres, fenêtres surgissantes, zones réservées, chacune justifiée par un objectif.
- Langues : liste, structure des adresses, qui traduit.
- Accessibilité : niveau visé, échantillon, méthode et calendrier de vérification.
- Existant : inventaire technique, contenus à reprendre, adresses à rediriger.
- Comptes et licences : titulaire de chaque compte et de chaque licence, accès délégués à l’agence.
- Hors périmètre : ce que le site ne fera pas. C’est la rubrique qui évite le plus de discussions.
Un cahier des charges Elementor réussi se reconnaît à une chose : on peut monter les gabarits et le design system avant d’avoir reçu un seul texte définitif.
Pièges fréquents et cas où il faut alléger
Premier piège : figer le design system avant que la maquette soit validée. Les variables se nomment au cadrage, leurs valeurs se fixent après validation graphique ; sinon chaque retour sur la maquette devient une modification de jeton à propager. Deuxième piège : recopier l’arborescence du site actuel sans se demander quelles pages sont réellement des modèles. Une rubrique « actualités » de quarante pages montées à la main est exactement ce que le Theme Builder doit remplacer. Troisième piège : laisser le choix de la structure multilingue au prestataire de traduction, alors qu’il change le nombre de licences.
Cette trame complète n’est pas toujours justifiée. Pour une page d’atterrissage unique, une campagne de quelques semaines ou un site de trois pages sans contenu dynamique, une page de cadrage suffit : objectifs, contenus avec dates, formulaire, compte titulaire. Inversement, sur un projet où le client a déjà un document de spécifications détaillé, ne le réécrivez pas : ajoutez seulement les rubriques propres à Elementor (gabarits, design system, licences), qui y manquent presque toujours.
Conclusion
Le cahier des charges d’un site Elementor n’a pas besoin d’être long, il doit être tranché : quels gabarits, quelle génération d’éléments, quels jetons, quels contenus remis par qui et quand, quelle structure linguistique, quel titulaire pour chaque compte. Ces décisions prises, l’intégration devient une exécution plutôt qu’une suite d’arbitrages en cours de route. Le deuxième épisode prendra la rubrique « licences » au mot et comparera les offres d’Elementor selon le projet client.
