Full Site Editing en 2026 : après 50 sites en thèmes blocs, voici ce qu'on en pense

En 2018, Gutenberg arrivait dans WordPress pour révolutionner l'édition de contenu. En 2022, le Full Site Editing (FSE) promettait d'étendre cette révolution à l'ensemble du site — plus besoin de page builders, plus besoin de code, tout se fait dans l'éditeur visuel. En 2026, WordPress 7.0 a enfin stabilisé l'éditeur de site complet, après des années de maturation parfois douloureuse.

Mais la promesse est-elle tenue ? Les thèmes blocs sont-ils vraiment prêts à remplacer Elementor, Divi, et les thèmes classiques ? Et surtout, pour qui et pour quel projet ?

On a construit 50 sites en thèmes blocs depuis 2024 : des blogs personnels, des sites d'entreprise, des boutiques WooCommerce, des sites média allant jusqu'à 5 000 pages. Certains sont partis de zéro, d'autres ont migré depuis Elementor ou le constructeur classique. Chaque projet nous a appris quelque chose de nouveau sur les forces et les faiblesses du FSE.

Voici notre bilan honnête — ce qui marche vraiment, ce qui coince encore, et si vous devez sauter le pas aujourd'hui ou attendre encore.

---

Ce que FSE fait vraiment bien en 2026

Après des années de développement chaotique (versions instables, fonctionnalités promises puis retirées, documentation incomplète), le FSE tient enfin ses promesses sur plusieurs points fondamentaux.

1. La performance native : un bond en avant

La raison numéro un de passer aux thèmes blocs, c'est la performance. Et les chiffres parlent d'eux-mêmes :

Pourquoi c'est plus rapide : un thème bloc génère exactement le HTML nécessaire pour chaque page — pas de shortcodes interprétés dynamiquement, pas de scripts de constructeur chargés inutilement en front-end, pas de CSS volumineux pour des fonctionnalités que vous n'utilisez pas. Elementor charge son moteur de rendu complet sur chaque page (même celles qui n'utilisent qu'un seul widget). Le FSE charge uniquement les styles des blocs présents sur la page.

Pourquoi 380 Ko au lieu de 1,2 Mo fait une différence concrète : sur une connexion mobile 4G (vitesse moyenne 10 Mbps), un site à 1,2 Mo met environ 1,2 seconde à charger ses ressources avant même d'afficher quoi que ce soit. Un site à 380 Ko met 0,3 seconde. L'utilisateur voit votre contenu 0,9 seconde plus tôt — ce qui améliore directement le LCP, le taux de rebond, et le temps passé sur le site.

2. La cohérence du design grâce au theme.json

Le theme.json est la pièce maîtresse des thèmes blocs. C'est un fichier de configuration centralisé qui contrôle tous les aspects visuels du site : typographie, couleurs, espacements, tailles de blocs, comportements responsifs. Plus besoin de chercher "dans quel champ CSS custom le client a modifié la couleur des titres" ou "quelle règle CSS écrase le style du bouton".

Ce qui change fondamentalement :

• Source de vérité unique : le theme.json devient le référentiel du design. Tout est prévisible, documenté, et facile à maintenir.
• Pas de CSS mystérieux : fini les feuilles de style de 2 000 lignes dont personne ne maîtrise l'impact. Le theme.json expose uniquement les paramètres de design configurables.
• Héritage des styles : les styles definis dans le theme.json s'appliquent automatiquement à tous les blocs. Un changement de couleur primaire se répercute sur tous les boutons, tous les titres, toutes les bordures — sans effort.
• Exportable : vous pouvez exporter votre theme.json et le réutiliser sur un autre projet (ou le partager avec votre équipe).

{
  "version": 3,
  "settings": {
    "color": {
      "palette": [
        { "slug": "primary", "color": "#6366f1", "name": "Indigo" },
        { "slug": "secondary", "color": "#ec4899", "name": "Rose" }
      ]
    },
    "typography": {
      "fontFamilies": [
        { "fontFamily": "Inter, system-ui, sans-serif", "slug": "inter", "name": "Inter" }
      ]
    }
  }
}

Avant le theme.json : un client demande "pouvez-vous agrandir un peu la police des titres ?" → 20 minutes à trouver le bon sélecteur CSS, tester, valider, prier pour que ça ne casse pas ailleurs.

Avec le theme.json : un client demande la même chose → 2 minutes pour modifier la valeur "fontSize" dans le fichier JSON, un déploiement, c'est fait. Partout.

3. Les variations de style

WordPress 7.0 et les versions récentes de Gutenberg permettent de créer des variations de style par page ou par bloc. Concrètement, un même thème bloc peut avoir plusieurs palettes de couleurs, plusieurs typographies, et plusieurs mises en page appliquées à des sections spécifiques du site — sans code personnalisé.

Cas d'usage concret : vous construisez un site d'entreprise avec une page d'accueil en indigo/blanc, une section blog en bleu marine/beige, et une page de contact en vert émeraude. Avec les variations de style, chaque page peut avoir sa propre identité visuelle tout en restant dans le même thème — cohérence garantie, pas de CSS en vrac.

{
  "version": 3,
  "styles": {
    "blocks": {
      "core/group": {
        "variations": {
          "dark": { "color": { "background": "#111", "text": "#fff" } },
          "accent": { "color": { "background": "#6366f1", "text": "#fff" } }
        }
      }
    }
  }
}

4. Les nouveaux blocs natifs

WordPress 7.0 apporte des blocs qui manquaient cruellement aux versions précédentes et qui réduisent la dépendance aux plugins :

• Bloc Tabs : créer des onglets de contenu sans extension tierce — idéal pour les FAQ, les fiches produits, les présentations en sections
• Bloc Fil d'Ariane (Breadcrumbs) : natif et gratuit — plus besoin d'installer Yoast ou Rank Math uniquement pour ça
• Bloc Icônes : une banque d'icônes intégrée (Font Awesome et Dashicons) — plus besoin de plugin d'icônes ou de bibliothèque externe
• Galerie avec Lightbox : un bloc galerie avec visionneuse intégrée — plus de plugin de galerie à installer
• Visibilité adaptative : afficher ou cacher un bloc selon l'appareil (mobile, tablette, desktop) — nativement, sans shortcode ni CSS personnalisé

Pourquoi ces blocs natifs changent la donne : chaque plugin installé est une dépendance supplémentaire. Les plugins de fonctionnalités simples (onglets, galeries, icônes) sont parmi les plus mal maintenus du répertoire WordPress. En les intégrant nativement, WordPress élimine des centaines de milliers de failles de sécurité potentielles et réduit la charge de maintenance.

---

Ce qui coince encore

On ne va pas vous vendre du rêve. Le FSE a fait d'énormes progrès, mais il reste des points noirs — et les ignorer serait vous rendre un mauvais service.

1. La courbe d'apprentissage : plus accessible, mais pas intuitive

Construire un thème bloc depuis zéro demande une maîtrise réelle de plusieurs concepts : theme.json, templates PHP, variations de blocs, styles personnalisés, ligues de style. C'est plus accessible qu'en 2022 (la documentation s'est améliorée, les exemples se multiplient), mais c'est objectivement moins intuitif qu'Elementor.

Pour qui c'est un problème :

• Les débutants qui veulent "glisser-déposer" sans comprendre la structure du site
• Les designers habitués aux interfaces visuelles complètes de Divi/Elementor (éditeur de thème visuel, builder de templates)
• Les freelances qui veulent livrer un site en 2 jours et n'ont pas le temps d'apprendre une nouvelle approche

Pour qui ça passe :

• Les développeurs qui écrivent du JSON et du PHP sans crainte
• Les intégrateurs motivés prêts à investir 2 à 3 jours dans l'apprentissage
• Les agences qui veulent standardiser leur production

Le vrai problème : ce n'est pas que le FSE soit dur à apprendre. C'est qu'Elementor a abaissé la barre d'entrée à un niveau très bas. Le FSE demande un niveau d'abstraction plus élevé (comprendre la différence entre un template, un bloc, un pattern, une variation de style). Ce n'est pas inaccessible, mais c'est différent — et le changement fait mal.

2. Les limites de l'éditeur de site (Site Editor)

L'éditeur de site (Site Editor) reste en deçà des page builders sur plusieurs aspects fonctionnels :

• Header/Footer : plus simple qu'avant (on peut maintenant les éditer visuellement), mais moins flexible qu'Elementor Header Footer Builder qui permet des conditions d'affichage avancées (header différent selon la catégorie, selon l'utilisateur connecté, selon l'appareil)
• Mega menus : toujours pas natifs dans le FSE en 2026. Si votre projet nécessite un mega menu avec images, colonnes, et liens personnalisés, il vous faut un plugin dédié (Max Mega Menu, JetMenu)
• Conditions d'affichage avancées : impossible d'afficher une sidebar différente selon la catégorie de l'article, ou un footer spécifique pour les pages produits — sans code PHP personnalisé
• Animations : rien de natif dans le FSE. Les animations au scroll, les transitions, les parallax — tout est à faire avec des blocs custom ou un plugin (Greenshift, Animations for Blocks)

3. La compatibilité WooCommerce : le vrai point faible

C'est la limite la plus importante à connaître. Les thèmes blocs WooCommerce existent (Dale, Bricks avec support FSE, et quelques thèmes dédiés), mais l'éditeur de site ne couvre pas encore les parties critiques d'une boutique :

• Page produit personnalisée par catégorie : impossible en FSE natif. Il faut un thème classique ou du code PHP.
• Variations de style pour le tunnel d'achat : le checkout, le panier, et le remerciement ne sont pas éditables via l'éditeur de site — ils restent en templates PHP classiques.
• Checkout personnalisé : pour modifier le checkout WooCommerce (ajouter des champs, modifier la mise en page), vous passez par des hooks PHP ou un plugin (Checkout Field Editor), pas par le FSE.

Notre recommandation : si votre site est un e-commerce avec des besoins complexes de personnalisation, restez sur un thème classique WooCommerce ou passez en headless (voir notre article sur la migration headless). Le FSE n'est pas encore assez mature pour ça en 2026 — et il ne le sera probablement pas avant 2027 ou 2028.

---

Thèmes blocs vs page builders : le match complet

Pourquoi Elementor et Divi ont une maintenance élevée : chaque mise à jour d'Elementor peut casser vos templates personnalisés (changement de classes CSS, de structure HTML, d'API de widgets). Les shortcodes générés par les page builders sont stockés en base de données — si vous désactivez le plugin, votre site devient illisible. C'est ce qu'on appelle la dette technique : plus vous utilisez un page builder, plus il est difficile de vous en libérer.

Notre verdict par type de projet :

• Site vitrine simple (< 10 pages) : thème bloc natif — plus rapide, moins cher, plus durable, et le client peut modifier le contenu sans casser le design
• Blog / site de contenu : thème bloc natif — la performance fait la différence sur le SEO et l'expérience de lecture
• Site entreprise (10-50 pages) : thème bloc + quelques blocs custom (développés sur mesure) — le meilleur compromis entre flexibilité et performance
• E-commerce / site complexe : Elementor ou Bricks — plus flexible et plus mature aujourd'hui pour les cas avancés

---

Les 3 thèmes blocs qu'on a gardés

Après 50 sites, on a testé une dizaine de thèmes blocs. Voici les 3 que nous utilisons en production :

---

Notre workflow FSE en 2026

Voici comment on construit un site en thème bloc aujourd'hui — notre process standardisé après 50 itérations :

1. Choix du thème : GeneratePress FSE (pour les projets complexes) ou Frost (pour les projets design) selon les besoins
2. Configuration theme.json : typographie (polices, tailles, graisses), couleurs (palette complète), espacements (marges globales, paddings) — 1 heure de configuration pour un theme.json bien fait qui sert de base cohérente à tout le projet
3. Création des templates : header (logo, menu principal, bouton CTA), footer (3 colonnes, mentions légales), template single (article complet), template archive (grille d'articles), page par défaut — une demi-journée
4. Développement des blocs custom : uniquement si nécessaire (boutons avec animations, grilles avancées, formulaires personnalisés) — un jour maximum. Plus de 80 % des besoins sont couverts par les blocs natifs
5. Création des pages avec l'éditeur : contenu + variations de style par section — une demi-journée pour un site de 10 pages
6. Tests performance : jusqu'à atteindre 90+ sur PageSpeed mobile — quelques heures (le FSE est déjà performant, c'est principalement les images à optimiser)

Temps total pour un site de 10 pages : 2 à 3 jours (contre 1 à 2 jours avec Elementor). Oui, c'est plus long. Mais...

Gain sur le long terme : la maintenance est quasi nulle. Pas de mise à jour de page builder, pas de conflit de shortcode, pas de CSS qui pète une mise à jour. Le site est plus rapide, plus stable, et coûte moins cher à maintenir sur la durée. Un site Elementor nécessite 2 à 4 h/mois de maintenance contre 30 min/mois pour un thème bloc.

---

Ce qu'on retient de 50 sites en FSE

Le FSE n'est pas prêt pour 100 % des cas. Il faut être honnête :

• Pour les sites vitrine, les blogs, les sites de contenu : c'est un choix excellent, plus performant et plus durable que les page builders. Performance supérieure, maintenance réduite, pas de dépendance à un constructeur tiers.
• Pour les e-commerces complexes et les sites avec une personnalisation extrême : attendez encore un peu ou passez par un hybride (thème bloc + page builder pour certaines pages spécifiques, ou headless).

WordPress 7.0 a rendu le FSE enfin viable. L'éditeur iframé (plus rapide, plus stable), les variations de style (flexibilité design sans code), les nouveaux blocs (Tabs, Icônes, Breadcrumbs) comblent les lacunes qui rendaient le FSE frustrant en 2024-2025. Le FSE est passé du statut "bêta permanente" à "prêt pour la production" pour la majorité des cas d'usage.

La tendance est claire : WordPress pousse vers les blocs. Les thèmes classiques ne disparaîtront pas demain (trop de sites en production, trop de développeurs formés), mais les fonctionnalités exclusives aux thèmes blocs (DataViews, variations de style, patterns Content-Only, commandes globales) se multiplient à chaque version. À moyen terme (2027-2028), le thème bloc deviendra le standard et les thèmes classiques l'exception.

Notre conseil le plus important : commencez aujourd'hui sur un petit projet, pas sur votre site principal. Apprenez, testez, validez — puis généralisez.

---

---

---

---

FAQ — Full Site Editing

Qu'est-ce que Full Site Editing ?

En 2018, Gutenberg arrivait dans WordPress pour révolutionner l'édition de contenu. En 2022, le Full Site Editing (FSE) promettait d'étendre cette révolution à l'ensemble du site — plus besoin de page builders, plus besoin de code, tout se fait dans l'éditeur visuel. En 2026, WordPress 7.0 a enfin stabilisé l'éditeur de site complet, après des anné

Ce que FSE fait vraiment bien en 2026 : quels sont les points clés ?

Après des années de développement chaotique (versions instables, fonctionnalités promises puis retirées, documentation incomplète), le FSE tient enfin ses promesses sur plusieurs points fondamentaux. La performance native : un bond en avant

La raison numéro un de passer aux thèmes blocs, c'est la performance. Et les chiffres parlent d'eux-mêmes : Thème classique + Elementor Gain 1,2 Mo -68 % 28 -5

Ce qui coince encore : quels sont les points clés ?

On ne va pas vous vendre du rêve. Le FSE a fait d'énormes progrès, mais il reste des points noirs — et les ignorer serait vous rendre un mauvais service. La courbe d'apprentissage : plus accessible, mais pas intuitive

Construire un thème bloc depuis zéro demande une maîtrise réelle de plusieurs concepts : theme.json, templates PHP, variations de blocs, styles personnalisés, ligues de style.

Thèmes blocs vs page builders : le match complet : quels sont les points clés ?

Thème bloc natif Divi Excellent Faible Moyenne Bonne Bonne Très bonne Faible Élevée Gratuit (sauf thème) 89 €/an Garantie (natif WordPress) À vérifier En croissance Très vaste Limité Moyen Bonne (code natif) Moyenne Pourquoi Elementor et Divi ont une maintenance élevée : chaque mise à jour d'Elementor peut casser vos templates personnalisés (changement de classes CSS, de structure HTML, d'API de w

Les 3 thèmes blocs qu'on a gardés : quels sont les points clés ?

Après 50 sites, on a testé une dizaine de thèmes blocs. Voici les 3 que nous utilisons en production : Notre usage Points faibles Sites vitrine, blogs Design générique (reconnaissable entre mille), peu de templates pré-fabriqués Sites entreprise, sites médias Moins de templates et de patterns que GeneratePress, communauté plus petite TOUS types de sites Version FSE relativement récente (encore en

Notre workflow FSE en 2026 : quels sont les points clés ?

Voici comment on construit un site en thème bloc aujourd'hui — notre process standardisé après 50 itérations :

1. Choix du thème : GeneratePress FSE (pour les projets complexes) ou Frost (pour les projets design) selon les besoins
2. Configuration theme.json : typographie (polices, tailles, graisses), couleurs (palette complète), espacements (marges globales, paddings) — 1 heure de configuration p

Ce qu'on retient de 50 sites en FSE : quels sont les points clés ?

Le FSE n'est pas prêt pour 100 % des cas. Il faut être honnête :

Pour les sites vitrine, les blogs, les sites de contenu : c'est un choix excellent, plus performant et plus durable que les page builders. Performance supérieure, maintenance réduite, pas de dépendance à un constructeur tiers.

Quels sont les prérequis pour se lancer ?

Avant de commencer, assurez-vous d'avoir les bases : un site ou projet bien défini, des objectifs clairs, et les ressources nécessaires (temps, budget, compétences). Le reste s'acquiert en chemin.

Combien de temps faut-il pour voir des résultats ?

Les premiers résultats peuvent apparaître en 2 à 4 semaines pour les actions rapides. Pour les efforts plus profonds, comptez 3 à 6 mois. La régularité est le facteur clé.

Par où commencer après avoir lu cet article ?

Identifiez votre besoin prioritaire, choisissez 2-3 actions concrètes de cet article, et lancez-vous cette semaine. Fixez-vous un point dans 30 jours pour ajuster. L'important est de passer à l'action.