# Passer de l’éditeur classique à Gutenberg sur WordPress > WordPress 5.0, sorti le 6 décembre 2018, a remplacé l’éditeur classique (TinyMCE) par l’éditeur de blocs Gutenberg comme éditeur par défaut. Le plugin officiel Classic Editor permet encore de revenir en arrière, mais son maintien n’est pas garanti indéfiniment : mieux vaut planifier la bascule plutôt que la subir. - Source canonique : [https://allaux.fr/wordpress-woocommerce/migration/gutenberg-depuis-editeur-classique](https://allaux.fr/wordpress-woocommerce/migration/gutenberg-depuis-editeur-classique) - Langue : FR - Dernière mise à jour : 2026-08-03 ## Réponse directe > Ne convertissez rien en masse. Ouvrez un article existant : son contenu apparaît dans un unique bloc Classique et continue de s’afficher correctement tel quel. Utilisez « Convertir en blocs » sur une page de test, comparez le rendu, puis avancez par lots. Si une extension dépend encore de l’éditeur classique, gardez le plugin Classic Editor le temps de la remplacer, plutôt que de forcer la bascule. ## Ce qui change concrètement à l’écran d’édition Gutenberg remplace la zone de texte unique de l’éditeur classique par un assemblage de blocs indépendants : paragraphe, image, colonnes, bloc HTML personnalisé, etc. Chaque bloc s’édite et se déplace séparément, ce qui change la façon de composer une page mais ne modifie pas ce qui est déjà publié : le contenu existant reste affiché correctement au moment de la bascule. Le plugin Classic Editor, maintenu officiellement par l’équipe WordPress, permet de continuer à utiliser l’ancien écran d’édition en parallèle le temps de la transition. Il ne s’agit pas d’une solution définitive : aucune date de fin de support ferme n’est annoncée à ce jour, mais rien ne garantit un maintien illimité face à l’évolution du cœur WordPress. ## Pourquoi certaines pages s’affichent mal après le passage à Gutenberg - Le contenu écrit en HTML brut ou avec les shortcodes d’un constructeur tiers (avant Gutenberg) est importé tel quel dans un unique bloc « HTML personnalisé » ou « Classique » : il fonctionne, mais aucun des avantages des blocs natifs (mise en page en colonnes, réglages visuels, réutilisation) n’est disponible sans reprise manuelle. - Les extensions qui ajoutaient des metaboxes personnalisées à l’ancien écran d’édition (champs additionnels sous ou à côté du contenu) doivent être compatibles avec l’API blocs pour continuer à s’afficher : une metabox mal enregistrée peut disparaître silencieusement de l’écran d’édition. - Un thème qui stylait fortement le rendu de l’éditeur classique peut afficher un aperçu incohérent avec le résultat final tant que les styles éditeur Gutenberg (add_theme_support('editor-styles')) ne sont pas déclarés. - Des shortcodes générés par un ancien constructeur de pages (Visual Composer, versions anciennes d’autres outils) restent fonctionnels côté affichage mais deviennent illisibles et non éditables visuellement dans Gutenberg. ## Comment je conduis la bascule vers Gutenberg 1. **Audit du contenu existant** — Je repère les pages écrites en HTML brut, avec des shortcodes d’un ancien constructeur, ou dépendantes de metaboxes personnalisées, pour estimer le volume de reprise nécessaire. 2. **Installation de Classic Editor en transition** — Sur un site avec beaucoup de contenu à convertir, j’installe le plugin Classic Editor pour continuer à publier normalement pendant que je convertis les pages existantes, plutôt que de tout basculer d’un coup. 3. **Vérification des extensions à metaboxes** — Je contrôle que chaque extension ajoutant des champs personnalisés à l’écran d’édition reste compatible avec l’API blocs, et je mets à jour ou remplace celles qui ne le sont plus. 4. **Conversion progressive page par page** — Je convertis le contenu en blocs natifs une page à la fois, en commençant par les pages à fort trafic, et je teste l’affichage front après chaque conversion plutôt qu’en fin de chantier. 5. **Bascule complète** — Une fois l’ensemble du contenu converti et vérifié, je désactive Classic Editor. Ce point marque un retour en arrière plus coûteux : au-delà, revenir à l’écran d’édition classique ne restaure pas la structure en blocs déjà construite. ## Sauvegarder avant toute conversion > Avant toute conversion, je sauvegarde le contenu existant (base de données a minima) : une conversion de bloc mal engagée sur une page complexe se corrige plus vite en repartant d’une copie que ligne par ligne. ## Comment je vérifie après conversion > Je compare le rendu visuel de chaque page convertie avec une capture de la version précédente, et je contrôle que les blocs HTML personnalisés restants n’affichent pas d’erreur de balisage dans la console navigateur. ## Pour aller plus loin - **Migrer d’un constructeur de pages à un autre** — Elementor, Divi, WPBakery enregistrent leur mise en page différemment dans post_content : la conversion suit une logique proche de celle-ci. ([/wordpress-woocommerce/migration/constructeur-de-pages](/wordpress-woocommerce/migration/constructeur-de-pages)) - **Développer une extension sur mesure** — Si une extension à metaboxes n’a pas de version compatible blocs, je peux développer l’équivalent en bloc natif. ([/wordpress-woocommerce/extension-sur-mesure](/wordpress-woocommerce/extension-sur-mesure)) - **Sauvegarder sa boutique avant une intervention** — La sauvegarde précède toute conversion de contenu, comme toute intervention technique sur le site. ([/guides/sauvegarder-boutique-avant-intervention](/guides/sauvegarder-boutique-avant-intervention)) - **Hub migration WordPress et WooCommerce** — Toutes les migrations et montées de version que je traite sur WordPress et WooCommerce. ([/wordpress-woocommerce/migration](/wordpress-woocommerce/migration)) ## FAQ ### Dois-je convertir tout mon contenu en blocs Gutenberg immédiatement ? Non. Le contenu existant continue de s’afficher normalement même resté dans un bloc HTML personnalisé ou classique. La conversion en blocs natifs apporte un confort d’édition, pas une obligation technique immédiate. ### Le plugin Classic Editor va-t-il disparaître ? Il reste maintenu officiellement par l’équipe WordPress, sans date de fin de support ferme annoncée à ce jour. Je le considère comme une solution de transition, pas comme une dépendance à long terme. ### Comment savoir si une extension est compatible avec l’API blocs ? Je vérifie la documentation de l’extension et je teste son affichage sur l’écran d’édition après activation de Gutenberg, sur un environnement de test avant toute bascule en production. ### Mes pages construites avec un shortcode tiers vont-elles casser à l’activation de Gutenberg ? Non, un shortcode continue de s’exécuter côté affichage. Il reste seulement figé dans un bloc unique, non éditable visuellement, tant qu’il n’est pas converti. ### Combien de temps prend la conversion d’un site existant ? Cela dépend du nombre de pages et de la complexité du contenu à reprendre : quelques heures pour un site vitrine simple, plusieurs jours pour un catalogue de pages avec mise en page riche.