Gutenberg est l'éditeur par défaut de WordPress depuis la version 5.0, sortie fin 2018. Sept ans plus tard, des millions de sites tournent encore sur Classic Editor. Si le vôtre en fait partie, il est temps d'y réfléchir sérieusement. Le plugin Classic Editor vit en sursis, les thèmes et plugins modernes sont conçus pour Gutenberg, et le Site Editor n'est accessible qu'avec l'éditeur de blocs.
Ce guide vous accompagne dans la migration, de la préparation au jour J. Pas de précipitation, pas de mauvaises surprises.
Pourquoi migrer maintenant
Un petit retour en arrière. Quand Gutenberg est arrivé avec WordPress 5.0 en décembre 2018, la réaction de la communauté a été, disons, mitigée. L'éditeur était encore jeune, bugué par endroits, et imposait un changement radical. WordPress a alors sorti Classic Editor comme plugin officiel, en promettant de le maintenir "au moins jusqu'en 2022". Puis 2022 est devenu 2024. Puis 2024 est devenu "tant que nécessaire". On est en 2026 et le plugin est toujours là, mais sa page officielle est claire : maintenance uniquement. Pas de nouvelles fonctionnalités, juste des correctifs de sécurité quand c'est nécessaire.
Toute la feuille de route de WordPress repose sur Gutenberg. Les thèmes block, les patterns, le Site Editor : tout ça nécessite l'éditeur de blocs.
Concrètement, voici ce qui se passe si vous ne migrez pas :
- Les thèmes modernes (y compris les thèmes par défaut Twenty Twenty-Four, Twenty Twenty-Five, Twenty Twenty-Six) sont conçus pour Gutenberg. Ils fonctionnent mal, voire pas du tout, avec Classic Editor.
- De plus en plus de plugins abandonnent la compatibilité avec l'éditeur classique. Les nouveaux plugins sont développés en priorité pour l'éditeur de blocs.
- Vous ne pouvez pas utiliser le Site Editor, qui permet de modifier visuellement l'intégralité de votre site (header, footer, templates) sans toucher au code.
- La communauté WordPress concentre ses efforts sur Gutenberg. Les ressources, tutoriels et le support évoluent dans cette direction.
Vous devrez migrer tôt ou tard. Autant le faire maintenant, de façon organisée, plutôt que d'y être contraint le jour où Classic Editor cassera avec une mise à jour majeure.
Préparer la migration
Ne désactivez pas Classic Editor un vendredi soir en espérant que tout ira bien. Une migration, ça se prépare.
Auditer vos contenus existants
Avant toute chose, faites un inventaire de ce qui compose votre site :
- Les shortcodes (
[contact-form], [gallery], [slider]...) : il faudra vérifier qu'ils sont compatibles avec Gutenberg ou trouver des alternatives en blocs natifs.
- Les page builders : si vous utilisez Elementor, Divi ou WPBakery, la migration est un projet à part entière (on en parle plus bas).
- Les champs personnalisés créés avec ACF, Meta Box ou Pods nécessitent une attention particulière. La plupart fonctionnent avec Gutenberg, mais des ajustements peuvent être nécessaires.
- Les contenus hérités : certaines pages très anciennes peuvent contenir du HTML brut ou des mises en forme qui ne se convertiront pas proprement.
Sauvegarder votre site
Pas d'excuse. Faites une sauvegarde complète avant de toucher à quoi que ce soit : fichiers, base de données, tout. Si vous ne savez pas comment faire, notre guide sur comment dupliquer un site WordPress couvre les méthodes disponibles.
Créer un environnement de staging
Ne testez jamais la migration directement en production. Créez une copie de votre site sur un environnement de staging (la plupart des bons hébergeurs proposent cette fonctionnalité en un clic). Vous pourrez y dupliquer votre site et tester la migration sans risque.
Vérifier la compatibilité de vos plugins
C'est l'étape que beaucoup négligent, et c'est souvent là que les problèmes surgissent.
Les plugins qui posent problème
Certains plugins sont connus pour ne pas bien s'entendre avec Gutenberg :
- Les anciens plugins de formulaires qui reposent uniquement sur des shortcodes, sans bloc dédié.
- Les plugins de SEO très anciens qui n'ont pas été mis à jour pour l'éditeur de blocs (les principaux comme Yoast et Rank Math sont compatibles depuis longtemps).
- Les plugins de galeries et de sliders qui n'ont pas intégré de blocs natifs.
Trouver des alternatives Gutenberg-native
Pour chaque plugin incompatible, cherchez une alternative qui propose un bloc Gutenberg natif. La plupart des catégories de plugins ont aujourd'hui des options conçues pour l'éditeur de blocs : formulaires (WPForms, Gravity Forms), galeries (bloc natif WordPress, Lightbox Block), tableaux (bloc natif, TablePress), etc.
Le cas ACF et Gutenberg
Advanced Custom Fields fonctionne avec Gutenberg. ACF Pro permet même de créer des blocs Gutenberg personnalisés à partir de vos groupes de champs. Si vous utilisez ACF de manière intensive, passer à Gutenberg peut rendre l'édition plus agréable pour vos rédacteurs.
Vérifiez que vous êtes sur la dernière version d'ACF et testez le rendu de vos champs dans l'éditeur de blocs sur votre staging.
Migrer étape par étape
Votre staging est en place, vos plugins sont compatibles, votre sauvegarde est faite. On y va.
Activer Gutenberg
Si Classic Editor est installé comme plugin, il suffit de le désactiver. Gutenberg est intégré au core de WordPress, il n'y a rien à installer. Si vous aviez forcé l'éditeur classique via le fichier functions.php ou un mu-plugin, pensez à retirer ce code.
Convertir les contenus existants
Quand vous ouvrez un article ou une page existant(e) dans Gutenberg, WordPress le place automatiquement dans un "bloc classique". Ce bloc encapsule votre ancien contenu tel quel. C'est fonctionnel, mais ce n'est pas l'objectif.
Vous avez deux options :
- Conversion automatique : dans le bloc classique, cliquez sur le menu (trois points) puis "Convertir en blocs". WordPress fait de son mieux pour découper le contenu en blocs appropriés. Ca fonctionne bien pour du contenu simple (texte, images, listes).
- Conversion manuelle : pour les pages complexes, reconstruisez le contenu bloc par bloc. C'est plus long mais le résultat est plus propre, et vous pouvez en profiter pour moderniser la mise en page.
Notre recommandation : utilisez la conversion automatique pour les articles de blog simples, et la conversion manuelle pour les pages importantes (accueil, services, landing pages).
Tester page par page
Oui, c'est fastidieux. Non, vous ne pouvez pas faire l'impasse. Après la conversion, vérifiez chaque page :
- Le contenu s'affiche correctement en frontend
- Les images sont bien positionnées
- Les formulaires fonctionnent
- Les shortcodes restants sont rendus correctement
- La mise en page responsive est préservée
Commencez par les pages les plus visitées (Google Analytics vous dira lesquelles), puis progressez vers les pages secondaires.
Les blocs essentiels à connaître
Gutenberg propose des dizaines de blocs. Voici ceux que vous utiliserez au quotidien :
- Le paragraphe, le bloc de base. Chaque paragraphe est indépendant, ce qui permet de les réorganiser facilement.
- L'image : glissez-déposez ou sélectionnez depuis la bibliothèque de médias. Le bloc gère le redimensionnement, l'alignement et le texte alternatif.
- Le titre (H2, H3, H4...). La hiérarchie des titres compte autant pour le SEO que pour la lisibilité.
- Les colonnes : des mises en page multi-colonnes sans CSS, de 2 à 6 colonnes.
- Le groupe : regroupez plusieurs blocs pour leur appliquer un style commun (couleur de fond, padding, bordure).
- Les boutons d'appel à l'action, avec des options de style intégrées.
- Les blocs réutilisables : créez un bloc une fois, utilisez-le partout. Modifiez-le, il se met à jour partout. Pratique pour les CTA ou les encarts récurrents.
- Les patterns : des compositions de blocs pré-configurées. WordPress en fournit, et vous pouvez créer les vôtres.
Le reste viendra avec la pratique. Une fois qu'on a compris que tout est un bloc, on s'y retrouve vite.
Les vrais inconvénients de Gutenberg
Gutenberg n'est pas parfait. On ne va pas vous dire le contraire.
Si vous utilisez l'éditeur classique depuis des années, la transition demande un temps d'adaptation. L'approche par blocs change les réflexes. Des actions qui prenaient deux secondes (insérer une image dans le texte, par exemple) demandent un ou deux clics de plus au début. Au bout d'une semaine d'utilisation quotidienne, la plupart des gens retrouvent leur vitesse.
Pour de la rédaction pure (un article de blog sans mise en page complexe), l'éditeur classique était efficace dans sa simplicité. Gutenberg ajoute une couche de structuration qui peut sembler superflue quand on veut juste écrire du texte. Gutenberg fait plus, donc il en demande un peu plus.
Côté technique, les meta boxes classiques fonctionnent dans Gutenberg, mais elles sont reléguées sous l'éditeur ou dans un panneau latéral. L'intégration n'est pas toujours élégante. ACF Pro résout ce problème en permettant de créer des blocs natifs, mais ça demande une configuration supplémentaire.
Gutenberg vs Classic Editor : le comparatif
| Critère | Classic Editor | Gutenberg |
|---|
| Facilité d'utilisation | Simple, familier | Plus riche, courbe d'apprentissage initiale |
| Flexibilité de mise en page | Limitée sans page builder ou CSS | Native, avec colonnes, groupes, et patterns |
| Performance du rendu | Dépend des shortcodes et plugins | HTML plus propre, moins de dépendances |
| Compatibilité thèmes | Thèmes classiques uniquement (offre en déclin) | Thèmes classiques + thèmes block |
| Site Editor | Non compatible | Compatible |
| Blocs réutilisables | Inexistant | Natif |
| Gestion des médias | Basique | Avancée (drag & drop, alignements étendus) |
| Support et avenir | Maintenance uniquement, fin programmée | Développement actif |
Si vous remettez en question le choix du CMS lui-même, notre article sur comment choisir son CMS peut vous intéresser.
Cas particulier : sites avec des page builders
Si votre site a été construit avec un page builder, la migration vers Gutenberg est un projet plus conséquent. Le contenu créé dans Elementor, Divi ou WPBakery est stocké dans un format propriétaire qui ne se convertit pas directement en blocs Gutenberg.
Elementor
Elementor propose un export limité vers Gutenberg, mais le résultat est rarement satisfaisant. Dans la plupart des cas, il faudra reconstruire les pages manuellement. La bonne nouvelle, c'est que Gutenberg avec des plugins comme Stackable ou Spectra permet aujourd'hui de reproduire la majorité des mises en page Elementor.
Divi
Divi stocke le contenu dans des shortcodes propriétaires. Désactiver Divi sans migration préalable affichera une masse de shortcodes bruts sur vos pages. Il existe des plugins de conversion (comme Flavor), mais une reconstruction manuelle des pages importantes reste la méthode la plus fiable.
WPBakery
Même constat que Divi. Le contenu WPBakery est basé sur des shortcodes propriétaires. La migration vers Gutenberg nécessite une reconstruction, page par page. C'est l'occasion de simplifier : beaucoup de mises en page créées avec WPBakery il y a quelques années peuvent être reproduites avec les blocs natifs de Gutenberg, en plus léger.
Dans les trois cas, la migration est aussi l'occasion de repenser la structure de votre site. Si vos pages n'ont pas été revues depuis plusieurs années, c'est le moment.
Après la migration
La migration technique est terminée. Il reste quelques étapes pour boucler proprement.
Désactiver Classic Editor
Une fois que tous vos contenus ont été migrés et testés, désactivez et supprimez le plugin Classic Editor. Le garder actif "au cas où" ne sert qu'à retarder l'inévitable et peut créer des conflits.
Former les rédacteurs
Si d'autres personnes contribuent au contenu de votre site, prenez le temps de les former à Gutenberg. L'éditeur se prend en main vite, mais les habitudes ont la vie dure. Une session de 30 minutes suffit généralement pour couvrir les blocs essentiels et les manipulations courantes (déplacer un bloc, transformer un bloc, utiliser les patterns).
Mettre en place un workflow de contenu
Gutenberg ouvre des possibilités qui n'existaient pas avec Classic Editor. Profitez-en pour structurer votre workflow : créez des patterns pour vos contenus récurrents, mettez en place des blocs réutilisables pour les éléments communs.
Et surtout, assurez-vous que votre site bénéficie d'une maintenance régulière. Les mises à jour de Gutenberg sont fréquentes et apportent régulièrement de nouvelles fonctionnalités et corrections.
Faut-il migrer ? Notre recommandation selon votre profil
Nous accompagnons des clients WordPress depuis des années. On a vu Gutenberg à ses débuts, quand c'était légitime de rester sur Classic Editor. Ce n'est plus le cas. Plus vous attendez, plus la migration sera complexe, parce que les écarts se creusent.
- Blog simple ou site vitrine léger : migrez maintenant. La conversion sera rapide. Quelques heures suffisent dans la plupart des cas.
- Site vitrine avec du contenu structuré : planifiez la migration sur quelques jours. Profitez-en pour nettoyer et moderniser vos pages.
- Site e-commerce (WooCommerce) : WooCommerce fonctionne très bien avec Gutenberg. Si vous avez des personnalisations lourdes liées à Classic Editor, faites-vous accompagner. Sinon, lancez-vous.
- Site avec page builder (Elementor, Divi, WPBakery) : c'est le cas le plus complexe. La migration implique souvent une reconstruction partielle. Ca vaut le coup, mais prévoyez un budget et un calendrier réalistes.
- Site sur mesure avec beaucoup de custom fields : évaluez la compatibilité de vos champs avec Gutenberg. ACF Pro facilite la transition. Un développeur WordPress pourra vous donner une estimation précise du travail.
WordPress reste largement dominant sur le marché des CMS, et Gutenberg est ce vers quoi il évolue.
Si votre site fait plus de 50 pages, utilise un page builder sur l'ensemble du site, ou repose sur des custom fields complexes, le coût d'une migration professionnelle est largement compensé par le temps gagné et les problèmes évités.
Vous préférez être accompagné ? Contactez-nous, on évalue la complexité ensemble et on vous propose un plan d'action adapté.