Trente templates, quatre types de gabarits de page, une douzaine de widgets personnalisés développés au fil des années : voilà l’inventaire de départ du Kit Elementor institutionnel dont la migration vers l’éditeur V4 a occupé l’équipe pendant plusieurs semaines. La bascule ne s’est pas faite en un clic, malgré les outils d’assistance à la migration proposés par Elementor pour cette transition.
Ce billet documente cette migration, menée en tenant compte des contraintes d’accessibilité déjà en place sur ce site de collectivité, sans reprendre ici l’intégralité de l’audit RGAA ni le détail des obligations légales associées, qui sortent du périmètre technique traité.
L’inventaire préalable, étape non négociable
Avant toute migration, un audit complet du Kit existant a permis de classer les trente templates en trois catégories : ceux qui n’utilisent que des widgets natifs Elementor (candidats à une migration automatique), ceux qui reposent sur des widgets personnalisés développés en interne (nécessitant une réécriture), et ceux qui combinent les deux (migration partielle).
Sur ce projet, dix-huit templates entraient dans la première catégorie, huit dans la deuxième, et quatre dans la troisième. Cette répartition a directement conditionné le planning de migration : les dix-huit templates les plus simples ont été traités en premier, pour valider la méthode avant de s’attaquer aux cas complexes.
La réécriture des widgets personnalisés liés à l’annuaire
Le widget personnalisé le plus critique du Kit gérait l’affichage de l’annuaire des services de la collectivité, avec un système de filtres par thématique et par secteur géographique. Construit en architecture V3 classique, il générait son balisage HTML directement en PHP, avec des attributs ARIA codés en dur pour la gestion des filtres accessibles au clavier.
La réécriture pour l’architecture V4 a nécessité de redécomposer ce widget en plusieurs composants atomiques : un composant de filtres, un composant de liste de résultats, et un composant de pagination, chacun devant reproduire fidèlement le comportement d’accessibilité du widget d’origine. Cette étape a représenté à elle seule près de la moitié du temps total consacré à la migration.
wp elementor kit export --path=./kit-institutionnel-backup.zip
wp elementor library sync-library
wp cron event run elementor_recalc_cssPrioriser la migration selon les contraintes RGAA
Plutôt que de migrer les templates par ordre de complexité technique uniquement, l’équipe a intégré une deuxième contrainte : les gabarits les plus consultés par le public, identifiés via les statistiques de fréquentation, ont été migrés en priorité, pour limiter la durée d’exposition à d’éventuelles régressions d’accessibilité pendant la phase de transition.
- Page d’accueil et annuaire des services : priorité maximale, migration et recette approfondie en premier
- Pages de délibérations et actualités : priorité intermédiaire
- Pages institutionnelles peu consultées (organigramme détaillé, archives) : migrées en dernier
Ce que les outils d’assistance à la migration ne couvrent pas
Les outils fournis par Elementor pour accompagner cette transition automatisent la conversion des widgets natifs, mais ne traitent ni les widgets personnalisés ni les styles CSS injectés manuellement en dehors de l’éditeur. Sur ce projet, une feuille de style additionnelle, écrite plusieurs années auparavant pour corriger des problèmes de contraste sur d’anciens widgets V3, a dû être entièrement revue, certains sélecteurs CSS ciblant des classes qui n’existent plus dans l’architecture atomique.
Le résultat après migration complète
Une fois les trente templates migrés, une revalidation complète des critères d’accessibilité concernés par les composants modifiés a été menée, en réutilisant le protocole de recette déjà en place sur ce type de projet institutionnel : navigation clavier, lecteur d’écran, contraste des couleurs. Aucune régression majeure n’a été identifiée, à l’exception d’un composant de filtre où l’attribut aria-pressed avait disparu lors de la réécriture et a dû être réintégré manuellement.
Sur ce type de migration, notre règle est simple : un widget personnalisé qui gère de l’accessibilité ne se migre jamais « à l’identique » sans recette complète, quelle que soit la confiance dans les outils de conversion automatique.
En résumé
La migration d’un Kit institutionnel de trente templates vers l’éditeur V4 d’Elementor a demandé un inventaire préalable rigoureux, une réécriture ciblée des widgets personnalisés les plus critiques, et une priorisation guidée par les contraintes d’accessibilité déjà en place sur le site. Le gain final se mesure moins en performance immédiate qu’en pérennité : le Kit repose désormais sur une architecture activement maintenue par Elementor, plutôt que sur un système progressivement voué à disparaître.
