Pulsar bascule vers le FSE de WordPress

Depuis des années, Pulsar conçoit des sites WordPress robustes avec Elementor Pro et la suite Crocoblock (JetEngine, JetSmartFilters, etc.). Aujourd’hui, nous faisons évoluer notre manière de créer des sites pour tirer parti du Full Site Editing (FSE) introduit par WordPress. Cette transition n’est pas un effet de mode : elle répond à des enjeux de performance, de simplicité de maintenance et de pérennité du code. Nous avons été longtemps réfractaire à l'éditeur Gutenberg mais aujourd'hui les avantages apportés par cette approche dépassent de loin les inconvénients de notre méthodologie actuelle. Voici, en toute transparence, pourquoi nous changeons de cap, comment nous mettons en œuvre le FSE au quotidien, et ce que cela change concrètement pour nos clients.

Pourquoi changer ? Les limites d’un stack « page builder + méga-plugins »

Performance et dette technique

Au fil du temps, un site basé sur un constructeur de pages et des plugins « tout-en-un » accumule du code inutile : widgets non utilisés, styles redondants, scripts chargés globalement. Même si l’on optimise, la granularité reste limitée et la dette technique grandit version après version. Avec le FSE, WordPress charge nativement des blocs légers et des styles modulaires. Résultat : moins de couches intermédiaires, moins de CSS/JS superflus, un Time To First Byte et des Core Web Vitals plus faciles à tenir dans la durée.

Standardisation de l’édition et pérennité

Le bloc est devenu le langage commun de WordPress : contenu, modèles, en-têtes, pieds de page, « template parts », tout s’appuie sur la même logique. Par contraste, chaque page builder définit sa propre abstraction. À long terme, rester proche du standard facilite les montées de version, réduit le nombre de dépendances critiques et garantit que vos contenus resteront éditables avec les outils de base de WordPress.

Contrôle fin du design system

Avec theme.json, nous définissons des tokens (couleurs, espacements, typographies, bordures) qui irriguent tout le site. Cette approche « design system-first » réduit les écarts visuels, accélère les déclinaisons et supprime l’inflation de classes utilitaires ou de réglages par page.

Notre nouvelle méthode : comment Pulsar conçoit en Full Site Editing

1) Démarrage par le design system et le theme.json

Nous commençons par cadrer l’identité (palette, échelles typographiques, rayons de bordure, ombres, espacements) dans un theme.json unique. Nous y activons seulement les fonctionnalités nécessaires (supports de blocs, variations, contrôles autorisés), ce qui limite l’interface aux options pertinentes pour vos équipes. Nous ajoutons une typographie fluide via clamp() et définissons des styles globaux pour assurer la cohérence des pages.

2) Construction de thèmes blocs sur mesure

Nous créons un thème bloc (block theme) ou un enfant d’un thème reconnu (ex. Twenty Twenty-Four/-Five) pour bénéficier d’une base stable. Nous y structurons :

• Templates : page d’accueil, pages de contenu, archive, single CPT, recherche, 404, etc.
• Template parts : en-têtes, pieds de page, barres latérales.
• Patterns (modèles de section) : hero, grilles de cartes, appels à l’action, témoignages, FAQ.

Ces briques se déposent ensuite via l’éditeur de site, sans code répétitif ni shortcodes obscurs.

3) Blocs personnalisés et variations

Lorsque les blocs natifs ou les patterns ne suffisent pas, nous créons :

• Variations de blocs (mêmes fonctionnalités, pré-stylées pour vos besoins).
• Blocs dédiés via l’API des blocs (React) ou via ACF Blocks pour des back-offices ultra-simples.

Nous privilégions la sobriété : un bloc = une fonction claire, une interface épurée, des attributs verrouillés pour éviter les dérives de style.

4) Données structurées et CPT

Pour les contenus métiers (offres, réalisations, événements), nous déclarons des Custom Post Types et des taxonomies au code (ou via un plugin léger). Nous exposons des champs clés (dates, lieux, statuts) avec ACF ou les champs personnalisés natifs, puis nous affichons le tout avec le bloc Query Loop, des patterns et, si besoin, des filtres légers.

5) Édition encadrée et expérience éditeur

Nous utilisons l’editor locking : certaines zones (header, footer, blocs critiques) sont verrouillées pour garantir l’intégrité du design. Nous livrons des patterns verrouillés (sections prêtes à l’emploi) pour accélérer la mise en page et éviter les écarts. Nous activons la Style Book pour prévisualiser tous les blocs avec votre design system.

6) Performance par défaut

Nous réduisons le nombre de plugins, utilisons les images WebP, activons le chargement différé natif, limitons les polices externes et évitons les scripts globaux. Nous nous appuyons sur le cache serveur/CDN, puis sur un plugin de cache minimaliste si nécessaire. Le principe : « rien de superflu ne charge sur vos pages ».

7) Versionning, QA, et déploiements sereins

Notre thème bloc, nos patterns et notre theme.json sont versionnés (Git). Nous testons en pré-production, nous validons l’édition avec vos équipes, puis nous déployons. Nous documentons chaque pattern et chaque bloc afin de simplifier l’onboarding et d’anticiper la maintenance des sites WordPress.

Et JetEngine dans tout ça ? Continuité et pragmatisme

Migration progressive, pas de rupture

Nous ne jetons pas l’existant. Selon le contexte, nous conservons temporairement JetEngine (listings complexes, relations multiples, formulaires avancés) et nous remontons progressivement les gabarits vers des Query Loop + patterns FSE. Quand une logique est très spécifique, nous la remplaçons par un bloc dédié plutôt que par une surcouche générique.

Objectif : réduire la dépendance, garder la valeur

L’enjeu n’est pas de « désinstaller pour désinstaller », mais de réduire la dépendance aux plugins lourds. Nous gardons ce qui a de la valeur métier, nous remplaçons ce qui alourdit. Au final, vous conservez vos contenus et vous gagnez en simplicité d’édition et en performances.

Les avantages concrets pour nos clients

Une édition plus simple et plus sûre

Grâce aux patterns, vos équipes composent des pages en glissant-déposant des sections prêtes, cohérentes avec la charte. Grâce au verrouillage, elles ne cassent pas l’en-tête ni le pied de page. Grâce au theme.json, elles n’ont pas à « bricoler » la couleur d’un bouton : tout est normalisé.

De meilleures performances, durables

Moins de code chargé, moins de JS, moins d’appels externes. Les pages s’affichent plus vite, notamment sur mobile. Les scores de performance sont plus stables au fil des mises à jour, car la base reste WordPress natif.

Une maintenance allégée et prévisible

Moins de plugins critiques signifie moins de mises à jour risquées. Les évolutions WordPress (sécurité, éditeur) profitent directement au site. La maintenance se concentre sur votre code métier (thème bloc, patterns, blocs dédiés), versionné et testé.

Accessibilité et sémantique renforcées

Les blocs core respectent une sémantique propre (titres, listes, nav, etc.). En standardisant les composants, nous améliorons la lisibilité pour les lecteurs d’écran et posons une base plus saine pour atteindre vos objectifs d’accessibilité.

Un coût total de possession optimisé

À court terme, la transition se prépare et se pilote. À moyen terme, vous gagnez en temps d’édition, en stabilité, en performances et en sérénité lors des évolutions. Votre budget de maintenance se concentre sur de la valeur : nouvelles sections, nouvelles fonctionnalités, A/B tests, SEO… plutôt que sur du « désamorçage » de conflits de plugins.

Cas d’usage : à quoi ressemble un site FSE livré par Pulsar ?

Structure type

• Thème bloc custom (ou enfant) avec theme.json soigné.
• Templates pour les pages clés : Accueil, Contenu, Blog, CPT.
• Template parts verrouillés : Header, Footer, Mega-menu si nécessaire.
• Patterns : héros, grille de services, preuves sociales, CTA, pricing.
• Blocs dédiés pour les spécificités métiers (ex. carte interactive, calendrier, carrousel éditorial léger).
• CPT (au code) et taxonomies avec champs ACF sobres.

Édition au quotidien

Le marketing assemble des pages en combinant des patterns ; il peut dupliquer une page et remplacer le contenu sans toucher aux réglages de style. Il peut réordonner des sections, insérer un CTA standard, lancer une landing en quelques minutes, toujours dans le cadre du design system.

Notre processus de transition si vous avez déjà un site Elementor/JetEngine

1) Audit et cartographie

Nous listons vos gabarits, vos widgets utilisés, vos CPT, vos filtres et vos formulaires. Nous distinguons : à conserver, à migrer, à réécrire, à supprimer.

2) Atelier design system

Nous extrayons la charte (couleurs, typo, composants clés) et nous la traduisons en theme.json. Nous identifions les patterns nécessaires pour couvrir 80 % de vos pages.

3) Prototype FSE

Nous créons un thème bloc minimal viable avec quelques templates et patterns prioritaires. Nous testons l’édition avec vos équipes, ajustons les verrous et affinons les libellés pour une UX éditeur limpide.

4) Migration par lots

Nous migrons les pages et modèles, en gardant temporairement certains modules JetEngine si utile. Nous remplaçons progressivement par des Query Loop, des patterns et des blocs dédiés.

5) Recette, formation, déploiement

Nous validons les performances, l’accessibilité, les micro-données, la compatibilité SEO. Nous formons vos équipes (1 à 2 heures suffisent souvent), puis nous déployons et assurons le suivi.

Questions fréquentes

Est-ce compatible avec WPML ou Polylang ?

Oui. Les blocs core, les patterns et les chaînes du thème bloc sont traduisibles. Nous organisons les contenus et les taxonomies pour un multilingue propre, sans shortcodes fragiles.

Et si j’ai besoin de filtres avancés sur des listings ?

Nous privilégions des solutions légères (requêtes par blocs, variations + filtres sobres). Si votre besoin est très avancé, nous développons un bloc filtrant dédié ; c’est plus pérenne et plus performant qu’une surcouche générique.

Dois-je tout refaire ?

Non. Nous pouvons migrer progressivement, en commençant par les templates globaux (header, footer, archive) et les pages à fort trafic. Le retour sur investissement se voit vite : édition plus rapide, meilleures perfs, moins de frictions en maintenance.

Un WordPress plus natif, plus rapide, plus durable

Le Full Site Editing n’est pas seulement un « nouveau thème ». C’est une manière plus standard, plus frugale et plus durable de construire votre site. En adoptant le FSE, Pulsar réduit la complexité inutile, renforce la cohérence visuelle et simplifie la maintenance. Vos équipes éditoriales gagnent en autonomie ; votre site gagne en vitesse et en stabilité. Et demain, lorsque WordPress évoluera, vous serez du bon côté : celui du standard.

Envie d’évaluer la transition de votre site actuel vers le FSE ? Parlons-en : nous auditerons votre stack, prioriserons les gains rapides et construirons, pas à pas, un WordPress plus léger, plus clair et plus performant.