Le piège de la migration WordPress-Drupal
Quand une organisation migre d'un site WordPress Gutenberg vers Drupal, elle part souvent avec une hypothèse rassurante : les blocs Gutenberg vont trouver leur équivalent dans Drupal, et le contenu suivra.
Cette hypothèse est fausse. Et c'est là que commencent la plupart des dérapages de projet.
WordPress avec l'éditeur à blocs et Drupal reposent sur deux philosophies d'architecture différentes. Les confondre, c'est planifier une migration de contenu qui se transforme en refonte complète — sans en avoir anticipé ni le périmètre, ni le coût, ni la friction pour les équipes éditoriales.
WordPress blocks : une édition couplée au thème
L'éditeur Gutenberg a transformé l'expérience d'édition WordPress en la rendant visuelle et accessible. Un rédacteur construit sa page comme une composition : il empile des blocs, les configure et voit immédiatement le résultat.
Ce modèle a une contrepartie architecturale souvent invisible : les blocs sont étroitement couplés au thème actif. Un bloc personnalisé encode dans son rendu des décisions de présentation spécifiques à ce thème. Lors d'une migration, cela crée trois problèmes :
- Le contenu et la mise en page sont mélangés. Un bloc "Hero section" contient à la fois le texte éditorial et les décisions de mise en page. Séparer les deux pour les importer dans Drupal suppose de savoir, bloc par bloc, ce qui relève du contenu et ce qui relève du rendu.
- Les blocs personnalisés n'ont pas d'équivalent natif. Les blocs standards migrent ; les blocs développés pour le projet — bloc de témoignage, bloc de tarification, accordéon personnalisé — doivent être reconçus.
- Les éditeurs ont appris une logique d'édition. Migrer vers Drupal change l'expérience de travail des équipes. Sans formation, la friction éditoriale post-migration devient un frein opérationnel durable.
Drupal et la séparation contenu/présentation
Drupal adopte une logique inverse. Son modèle éditorial est fondé sur la structure des contenus : types de contenu, champs, taxonomies. La présentation est distincte du contenu.
Pour créer de la flexibilité éditoriale dans Drupal, l'approche dominante est le module Paragraphs (ou Layout Builder). Chaque composant éditorial devient un type de paragraphe réutilisable, attaché à un nœud de contenu — et non un fragment HTML lié à un thème. Il peut être rendu différemment selon le contexte (web, API headless, application mobile) sans modifier le contenu lui-même.
Cartographier vos blocs WordPress vers des composants Drupal
La première étape d'une migration réussie est un inventaire exhaustif des blocs existants. L'objectif n'est pas de migrer les blocs — c'est de comprendre ce qu'ils font et de décider comment cette fonction sera assurée dans Drupal.
Trois catégories émergent systématiquement :
- Blocs éditoriaux purs (paragraphe, image, titre) : ils migrent vers des champs Drupal ou des types de paragraphes simples.
- Blocs de composition de page (colonnes, sections, grilles) : ils relèvent de Layout Builder ou du thème — ce sont des décisions de mise en page, pas du contenu.
- Blocs métier spécifiques (témoignages, tarifs, accordéons) : chacun devient un type de paragraphe dédié, avec son propre modèle de données et son propre template.
Pour chaque bloc spécifique, la question est : reconcevoir à l'identique, simplifier, ou refondre ? La migration est une opportunité d'éliminer les blocs qui ne servent plus rien — et ceux-là sont souvent nombreux.
Choisir entre thème personnalisé et design system
Deux grandes voies existent pour le front-end dans Drupal.
Le thème Drupal personnalisé (Twig) convient quand le site est la seule surface de diffusion, quand l'équipe est à l'aise avec Twig et PHP, et quand les évolutions visuelles sont rares.
Le design system découplé est recommandé quand le même design s'applique à plusieurs surfaces (site, application mobile, extranet), quand des équipes front-end et back-end travaillent en parallèle, ou quand le cycle de vie du design doit être indépendant du cycle de vie du CMS.
Le critère de choix n'est pas technique, il est organisationnel : qui maintient quoi, à quel rythme, et pour combien de canaux ?
Migrer le contenu sans casser les mises en page
La migration du contenu est l'étape la plus risquée techniquement, et la plus sous-estimée dans les plannings.
Un export XML WordPress standard produit le HTML final des pages — pas la structure de blocs qui l'a généré. Pour récupérer la structure des blocs Gutenberg, il faut utiliser l'API REST WordPress ou un outil de scraping structuré.
Même avec les bons outils (Migrate, scripts Drush, connecteurs API), la migration de contenu structuré demande un travail de mapping champ par champ. Les mises en page complexes nécessitent une intervention manuelle sur un échantillon pour valider les scripts avant de les lancer à l'échelle.
Après la migration automatisée, un certain nombre de pages nécessiteront une correction manuelle. Prévoir un plan de réconciliation avec une estimation réaliste du volume évite les mauvaises surprises en fin de projet.
Plan de reprise et formation pour limiter la friction éditoriale
La migration technique n'est que la moitié du travail. L'autre moitié est l'accompagnement des équipes éditoriales.
Former avant, pas après. Les rédacteurs qui travaillaient dans Gutenberg ont intégré une logique d'édition visuelle et immédiate. L'éditeur Drupal fonctionne différemment. Une formation dispensée avant la mise en production réduit la résistance et les erreurs de manipulation.
Documenter les composants disponibles. Chaque type de paragraphe créé dans Drupal doit être documenté pour les équipes éditoriales : à quoi sert ce composant, quand l'utiliser, quelles options sont disponibles.
Prévoir un filet de sécurité dans les premières semaines. Les premières semaines après la bascule sont critiques. Un dispositif d'assistance léger réduit considérablement la friction et ancre les bonnes pratiques.
Ce qu'une migration WordPress-Drupal exige vraiment
Migrer d'un WordPress à blocs vers Drupal, ce n'est pas un copier-coller technique. C'est un projet d'ingénierie qui touche simultanément à l'architecture des contenus, au front-end, à la donnée et à l'organisation des équipes.
Les organisations qui réussissent ces migrations ont en commun d'avoir posé les bonnes questions avant de commencer : sur leur contenu existant, leurs équipes et leurs ambitions pour les deux ans à venir. Pas sur la technologie — sur leur organisation.