Open Source & Outils. Migration Drupal vers WordPress : le dilemme de Marc sur la refonte

Migration Drupal vers WordPress: le dilemme de Marc sur la refonte

Marc est un personnage fictif, mais son dilemme est parfaitement réaliste. Il administre depuis plusieurs années un site Drupal 7 construit par couches successives: vues personnalisées, paragraphes imbriqués, contenus métier, modules sur mesure et quelques hooks PHP dont plus personne ne se souvient vraiment. Un matin, la direction annonce la décision: le site va migrer vers WordPress.

Sur le papier, le projet ressemble à un changement de CMS. Dans les faits, c’est une refonte qui engage l’architecture des données, les parcours éditoriaux, les URLs, les requêtes, l’environnement serveur et, surtout, la capacité de l’équipe à maintenir le résultat dans la durée. Pour un technicien, un lead developer ou un responsable technique, la vraie question n’est donc pas seulement « Drupal ou WordPress? ». C’est: que va-t-on conserver, que va-t-on reconstruire, et que risque-t-on de perdre en chemin?

La migration CMS Drupal vers WordPress soulève des enjeux techniques bien plus importants qu’un simple export-import. Les contenus ne sont pas modélisés de la même manière, les champs personnalisés ne se traduisent pas automatiquement, les vues doivent souvent être réécrites et les redirections 301 doivent être préparées avant le premier déploiement. Si ces sujets sont repoussés à la fin du projet, la refonte devient rapidement une suite de corrections urgentes.

Le contexte qui rend la migration inévitable

Commençons par le pourquoi, parce que c’est lui qui dicte l’urgence. Drupal 7 est arrivé en fin de vie le 5 janvier 2025. Cela signifie que les équipes qui exploitent encore cette version doivent considérer très sérieusement la suite: migration vers une version plus récente de Drupal, maintien temporaire avec un support spécifique, ou changement de CMS.

Aucune de ces options n’est neutre. Rester sur une version ancienne augmente la surface de risque, notamment pour la sécurité et la compatibilité avec l’environnement serveur. Passer à Drupal 10 ou à une version ultérieure implique souvent une reconstruction importante lorsque le site repose sur des modules abandonnés, des développements spécifiques ou un modèle de contenu très éloigné des pratiques actuelles. Migrer vers WordPress peut alors apparaître comme une manière de repartir sur une base plus facile à recruter, à administrer et à faire évoluer.

C’est l’un des principaux arguments de la migration Drupal WordPress: WordPress dispose d’un écosystème très vaste, d’un grand nombre de profils disponibles sur le marché et d’une documentation abondante. Pour une PME, cette disponibilité peut peser dans le coût de maintenance autant que dans le choix initial du CMS. Elle ne garantit toutefois ni une migration simple ni un site techniquement solide. Un WordPress mal conçu peut reproduire les défauts de l’ancien site sous une autre forme: dette technique, extensions difficiles à remplacer, requêtes lentes et administration devenue illisible.

Deux décisions sont donc souvent mises en balance:

• Moderniser Drupal, en conservant une partie des concepts et des habitudes de l’équipe, mais en assumant une reconstruction parfois profonde.
• Migrer vers WordPress, en profitant d’un écosystème plus large, au prix d’un nouveau modèle de données et d’une réécriture des composants spécifiques.

Le coût de migration d’un site Drupal dépend moins du nombre brut de pages que de la complexité accumulée. Un site de quelques centaines de contenus peut être plus difficile à migrer qu’un site beaucoup plus volumineux si chaque contenu comporte des champs conditionnels, des relations et des règles d’affichage particulières. Avant de parler de budget, il faut donc savoir ce que le site contient réellement.

La migration, ce n’est pas un transfert de fichiers: c’est une traduction entre deux langues qui ne partagent pas la même grammaire.

Architecture des données: le choc entre entités et types de publications

C’est ici que le projet bascule concrètement de la décision stratégique à l’engrenage technique. Drupal fonctionne autour des entités, des champs et des relations. WordPress s’appuie principalement sur les articles, les pages, les types de publications personnalisés — les Custom Post Types, ou CPT —, les taxonomies et les champs méta.

Ce n’est pas une simple différence de vocabulaire. Les deux CMS ne proposent pas la même manière de penser le contenu.

Une installation Drupal d’entreprise peut contenir plusieurs types de nœuds, des vocabulaires de taxonomie imbriqués, des références entre entités, des révisions, des Paragraphs et des blocs placés selon des règles contextuelles. Dans WordPress, chaque élément doit être réinterprété dans une architecture qui repose davantage sur les types de publications, les taxonomies et les métadonnées.

Les nœuds et leurs révisions doivent d’abord être classés. Un type de contenu « étude de cas » devient-il un article, une page ou un CPT? La réponse dépend de son usage, pas de son nom. Si les études de cas doivent posséder leur propre archive, leur propre gabarit et des filtres spécifiques, le CPT est généralement plus cohérent. Si elles sont simplement publiées dans une chronologie éditoriale, le type article peut suffire.

Chaque décision produit des conséquences en cascade:

• Le choix du type de publication détermine les URL et les archives.
• Les taxonomies influencent les filtres, les pages de classement et les métadonnées.
• Les relations entre contenus doivent être reproduites avec des champs de référence ou une logique personnalisée.
• Les droits d’édition doivent être redéfinis pour chaque rôle.
• Les révisions et les statuts de publication doivent être rapprochés des workflows WordPress.
• Les templates doivent être prévus avant l’import, faute de quoi les contenus arrivent dans une structure impossible à exploiter.

Cette phase prend presque toujours plus de temps que prévu. Elle ne produit pourtant rien de spectaculaire: pas de nouvelle page à montrer, pas de bouton visible, pas de démonstration qui impressionne une direction. Il y a surtout des inventaires, des décisions d’architecture, des tableaux de correspondance et des cas particuliers à arbitrer.

C’est précisément pour cette raison qu’elle est souvent compressée dans le planning. On parle d’abord de « récupérer le contenu », puis on découvre que le contenu n’est pas un bloc homogène. Une fiche produit, une étude de cas, une page institutionnelle et un article d’actualité n’ont ni les mêmes champs ni les mêmes règles de publication.

Construire une matrice de correspondance

Avant de lancer un outil de conversion, prépare une matrice qui documente au minimum:

Cette matrice sert autant aux développeurs qu’aux personnes qui valident le contenu. Elle permet de repérer les champs sans destination, les types de contenus oubliés et les choix qui ne pourront plus être modifiés facilement après l’import.

Mapping des contenus et gestion des champs personnalisés

Les champs personnalisés constituent l’un des points les plus sensibles d’une migration Drupal WordPress. Drupal les gère avec une grande finesse via la Field API: champs multiples, valeurs conditionnelles, références, Paragraphs, groupes réutilisables et règles d’affichage. WordPress ne propose pas nativement une équivalence complète.

Des extensions comme Advanced Custom Fields ou Pods peuvent reconstruire une partie de cette structure sans modifier le cœur de WordPress. Elles ne font cependant pas disparaître le travail de conception. Il faut recréer chaque groupe de champs, définir son emplacement dans l’administration, choisir son format de stockage, prévoir les droits d’accès et décider de la manière dont les données seront rendues côté front-end.

Un champ Drupal de type date ne pose pas forcément de difficulté. En revanche, un champ qui contient plusieurs valeurs, une référence vers un autre contenu et une règle d’affichage conditionnelle ne se traduit pas en une simple colonne de la table des métadonnées WordPress. Il faut déterminer:

1. Quelle est la valeur réellement utile à conserver?

2. Sous quelle forme doit-elle être stockée?

3. Comment sera-t-elle modifiée par un rédacteur?

4. Comment sera-t-elle affichée dans le template?

5. Que devient-elle si le contenu référencé est supprimé ou dépublié?

Les Paragraphs de Drupal rendent le sujet encore plus délicat. Un paragraphe est une entité à part entière, avec ses champs, ses révisions et sa logique de rendu. Dans WordPress, trois approches reviennent souvent:

• Traduire les composants simples en blocs Gutenberg.
• Reproduire les structures plus complexes avec des champs répétables.
• Développer des blocs personnalisés lorsque le rendu et les contraintes éditoriales doivent être strictement contrôlés.

Aucune de ces solutions n’est parfaite. Les blocs Gutenberg offrent davantage d’autonomie aux rédacteurs, mais peuvent produire une grande variété de mises en page si les contraintes sont faibles. Les groupes de champs permettent un cadre plus strict, mais ils peuvent rendre l’édition moins intuitive. Les blocs sur mesure donnent un meilleur contrôle du HTML et du comportement, mais augmentent le coût de développement et de maintenance.

Les outils de conversion de contenu Drupal vers WordPress

Plusieurs outils peuvent accélérer l’opération. Ils doivent être considérés comme des moyens d’importation, pas comme des moteurs capables de comprendre automatiquement l’architecture métier du site.

Dans la pratique, une migration sérieuse combine souvent plusieurs outils et scripts. Le premier traitement récupère la masse des contenus. Un second passage corrige les champs, les médias ou les relations. Des scripts spécifiques s’occupent ensuite des Paragraphs, des identifiants historiques ou des éléments qui n’ont pas d’équivalent direct.

Il faut également prévoir les échecs partiels. Un import interrompu ne doit pas créer des doublons à chaque nouvelle tentative. Les données doivent être identifiables, les lots rejouables et les journaux suffisamment précis pour savoir quels contenus ont été traités. Un système d’import sans stratégie de reprise est une source de dette technique avant même la mise en ligne.

Le nettoyage post-import est tout aussi important. Il peut rester des images orphelines, des liens internes qui pointent vers Drupal, des balises HTML mal fermées, des shortcodes résiduels ou des valeurs de champs incompatibles avec le nouveau thème. La migration drupal wordpress ne s’arrête pas au moment où le compteur affiche « 100 % ». Ce chiffre indique seulement que le processus a parcouru ses entrées. Il ne dit rien de la qualité du résultat.

La stratégie de redirection 301 pour préserver votre référencement

C’est le point où l’équipe marketing commence généralement à dormir moins bien. Drupal et WordPress ne construisent pas nécessairement leurs URL de la même manière. Drupal peut s’appuyer sur des alias très personnalisés, tandis que WordPress organise ses permaliens autour de ses propres règles de slug, de hiérarchie et de type de publication.

Même lorsque le titre d’une page ne change pas, son URL peut être modifiée par le passage à un CPT, la suppression d’un préfixe, le changement de taxonomie ou la réorganisation des archives. Sans redirection, les anciennes adresses renvoient vers des erreurs 404. Les moteurs de recherche doivent alors découvrir la nouvelle structure, et les utilisateurs qui arrivent depuis d’anciens liens se retrouvent face à une page morte.

La construction du fichier de redirections 301 doit commencer avant l’import final. Pour chaque URL source, il faut idéalement connaître:

• Son équivalent exact dans la nouvelle architecture.
• Le statut du contenu: conservé, fusionné, supprimé ou remplacé.
• La nouvelle URL canonique.
• Les éventuels paramètres à conserver ou à neutraliser.
• La priorité de la redirection selon le trafic, les liens entrants et la valeur du contenu.

Un tableau simple peut suffire pour commencer, à condition qu’il soit tenu à jour. Les règles génériques ne remplacent pas les correspondances individuelles lorsque les anciennes URL suivent une logique irrégulière.

Une migration sans plan de redirections, c’est comme déménager sans prévenir personne: tu arrives dans une maison vide, et personne ne te cherche à la nouvelle adresse.

Les cas qui échappent aux redirections évidentes

Les pages de taxonomie Drupal ne correspondent pas toujours aux archives WordPress par défaut. Une URL comme /taxonomy/term/12 doit être rapprochée d’une nouvelle taxonomie, d’une archive de CPT ou d’une page éditoriale. La bonne destination n’est pas forcément celle qui porte le même nom: elle doit proposer un contenu cohérent et utile à l’internaute.

Les URLs paginées méritent également un traitement spécifique. Les anciennes pages de pagination peuvent être encore indexées, liées depuis d’autres sites ou utilisées dans des flux. Il faut vérifier leur comportement après le changement de thème et d’architecture.

Les flux RSS, les sitemaps XML et les balises canoniques doivent être régénérés dans le nouveau CMS. Un sitemap qui conserve d’anciennes adresses ou une balise canonique qui pointe vers Drupal peut brouiller les signaux envoyés aux moteurs de recherche.

Même chose pour les détails apparemment secondaires:

• Les slashs finaux doivent suivre une règle cohérente.
• Les majuscules et les minuscules ne doivent pas créer plusieurs variantes d’une même page.
• Les paramètres de filtres et de tri doivent être examinés pour éviter les URLs inutiles.
• Les fichiers PDF, images et documents téléchargeables doivent être inclus dans l’inventaire.
• Les liens internes contenus dans le corps des textes doivent être réécrits.
• Les redirections en chaîne doivent être évitées: une ancienne URL doit pointer directement vers la destination finale.

Le jour du lancement, un crawler permet de comparer les anciennes et les nouvelles réponses HTTP. Mais le travail ne s’arrête pas là. Les rapports de 404, les statistiques de crawl et les données d’acquisition doivent être surveillés dans les semaines suivantes. Certaines URLs ne seront découvertes qu’après la mise en production, notamment celles qui proviennent de liens externes ou de vieux documents partagés.

Réécrire les requêtes complexes: remplacer le module Views

C’est le sujet qui fait généralement transpirer les développeurs plus que les autres lors d’une migration Drupal. Le module Views permet de construire des requêtes de contenu filtrées, triées, paginées ou exposées aux utilisateurs sans écrire directement toute la logique applicative. Sur un site ancien, les Views s’accumulent: études de cas par secteur, articles par auteur, produits par catégorie, contenus régionaux ou listes filtrées par date.

WordPress n’a pas d’équivalent natif complet. Pour reproduire une View, il faut généralement combiner une requête WP_Query, un template et parfois une extension spécialisée. La difficulté ne réside pas uniquement dans la requête. Il faut aussi retrouver l’intention fonctionnelle de la View.

Une liste peut sembler simple dans l’administration et cacher plusieurs règles:

• Exclure les contenus non publiés.
• Afficher les contenus dans une langue donnée.
• Prioriser certains éléments.
• Filtrer sur une relation entre entités.
• Combiner plusieurs taxonomies.
• Appliquer une pagination compatible avec les URLs existantes.
• Modifier le résultat selon le rôle de l’utilisateur ou la page consultée.

La première étape consiste donc à inventorier les Views et à les classer. Certaines sont réellement utilisées. D’autres ont été créées pour une campagne ancienne, un test ou une page qui n’existe plus. Les reproduire toutes à l’identique serait une manière coûteuse de conserver de la complexité inutile.

Pour les Views nécessaires, plusieurs solutions sont possibles. Une requête WP_Query peut convenir lorsque les critères restent simples. Des templates personnalisés permettent de contrôler précisément le rendu. Des extensions comme FacetWP, SearchWP ou Relevanssi peuvent couvrir certains besoins de recherche et de filtrage, mais elles ajoutent une dépendance qu’il faudra maintenir.

Le bon choix dépend du besoin, pas de l’habitude du développeur. Une requête codée en dur sera rapide à mettre en place mais moins accessible aux équipes éditoriales. Un constructeur visuel offrira davantage d’autonomie, mais pourra générer des requêtes moins prévisibles. Une extension spécialisée accélérera le développement, tout en ajoutant une ligne au registre des composants à surveiller.

Le cas spécifique des filtres exposés

Les filtres exposés de Drupal Views méritent une attention particulière. Ce sont les formulaires qui permettent à l’utilisateur final de filtrer une liste par catégorie, date, auteur, localisation ou mot-clé. Dans Drupal, ils sont étroitement liés à la View. Dans WordPress, leur comportement doit être reconstruit.

Un filtre fiable doit gérer au moins:

1. La réception et la validation des paramètres envoyés en GET.

2. La transformation de ces paramètres en arguments de requête.

3. La conservation des filtres actifs dans l’interface.

4. La pagination sans perte des critères sélectionnés.

5. Les états vides lorsqu’aucun résultat ne correspond.

6. La génération d’URLs propres et indexables, ou au contraire non indexables selon le cas.

7. Le comportement sur mobile et avec JavaScript désactivé.

Le filtrage AJAX ajoute une couche supplémentaire. Il faut prévoir les réponses, les états de chargement, les erreurs et l’accessibilité du composant. Un filtre qui fonctionne en démonstration mais ne conserve pas l’URL, ne permet pas le retour arrière du navigateur ou charge toute la base à chaque clic n’est pas réellement terminé.

Optimisation de l’environnement serveur pour l’importation de masse

Dernier épisode technique, mais pas le moindre: l’importation de masse. C’est le genre de phase qui se lance un vendredi soir en pensant profiter du week-end, et qui se solde par un lundi matin catastrophique quand on découvre que le processus s’est arrêté à mi-parcours.

L’erreur classique est le délai d’exécution trop court. Un script d’import peut être interrompu par PHP, le serveur web, un proxy ou une limite imposée par l’hébergeur. Le navigateur affiche alors une erreur de passerelle, alors que le traitement a peut-être continué en arrière-plan — ou s’est arrêté sans laisser d’état exploitable.

La première règle consiste à ne jamais dépendre d’un import lancé depuis une seule page du navigateur. Les gros volumes doivent être découpés en lots, avec un identifiant de reprise et un journal d’exécution. Chaque lot doit pouvoir être vérifié avant de passer au suivant.

Avant l’import, vérifie notamment:

• Les limites PHP liées à la mémoire et au temps d’exécution.
• Les délais du serveur web et du proxy.
• L’espace disque disponible pour les médias et les fichiers temporaires.
• La capacité de la base de données à absorber les écritures successives.
• Les droits d’écriture dans la bibliothèque de médias.
• La configuration de la tâche planifiée si l’import repose sur une file de traitement.
• La présence d’un environnement de préproduction suffisamment proche de la production.

Le nombre de médias est souvent plus problématique que le nombre de pages. Chaque fichier peut déclencher la création de plusieurs tailles d’image, l’écriture de métadonnées et parfois l’appel à un service externe. Un import qui traite correctement les textes peut donc ralentir fortement lorsqu’il arrive aux images.

Il faut aussi décider si les médias sont téléchargés pendant le premier passage ou dans un traitement séparé. Séparer les deux opérations facilite la reprise et permet de valider les contenus textuels avant de mobiliser le stockage. En contrepartie, les pages peuvent temporairement contenir des références incomplètes. Cette situation doit être prévue dans le modèle de données et dans les contrôles de validation.

Sauvegarder les données Drupal avant la migration

La sauvegarde des données Drupal avant migration ne se résume pas à exporter une base SQL. Il faut conserver une copie exploitable de la base, du répertoire des fichiers publics et privés, des réglages utiles, des traductions, des fichiers de configuration et des éléments qui ne sont pas stockés directement dans la base.

Une sauvegarde doit ensuite être testée. Un fichier présent sur un disque n’est pas encore une sauvegarde fiable si personne ne sait le restaurer. Le test peut être réalisé sur un environnement isolé, avec vérification des comptes, des médias, des relations entre contenus et des versions nécessaires à la lecture de l’ancien site.

Conserve également un instantané juste avant la bascule finale. Entre l’import de préproduction et la mise en ligne, de nouveaux contenus peuvent être publiés, des fichiers peuvent être remplacés et des modifications peuvent intervenir dans l’administration. La stratégie doit préciser comment ces changements seront récupérés: gel éditorial, import différentiel ou double saisie temporaire.

Tester la migration avant de parler de lancement

Un environnement de préproduction doit servir à autre chose qu’à montrer le nouveau thème. Il doit permettre de comparer les données, les URLs et les comportements.

Commence par tester un échantillon représentatif:

• Un contenu simple.
• Un contenu avec plusieurs champs.
• Un contenu contenant des Paragraphs.
• Un contenu relié à plusieurs taxonomies.
• Une page avec des médias anciens.
• Une fiche dont l’URL comporte des caractères particuliers.
• Un contenu traduit ou soumis à un workflow éditorial.
• Une liste issue d’une View complexe.

Ces tests révèlent rapidement les défauts de mapping. Un champ peut être présent mais rendu au mauvais endroit. Une image peut avoir été importée sans son texte alternatif. Une relation peut pointer vers un identifiant Drupal qui n’existe plus dans WordPress. Une page peut afficher correctement son titre tout en ayant perdu ses données structurées ou ses liens internes.

Après l’import, le contrôle doit être effectué à plusieurs niveaux:

• Données: les contenus, champs, taxonomies et médias sont-ils présents?
• Présentation: le rendu correspond-il aux modèles attendus?
• Navigation: les menus, liens internes et parcours fonctionnent-ils?
• Performance: les requêtes et les pages critiques restent-elles acceptables?
• SEO: les codes HTTP, canoniques, sitemaps et redirections sont-ils cohérents?
• Éditorial: un rédacteur peut-il réellement modifier le contenu sans intervention technique?

Ce dernier point est souvent oublié. Une migration peut être techniquement réussie et éditorialement ratée. Si chaque mise à jour exige de modifier un champ caché ou de contourner une interface incompréhensible, l’équipe reviendra rapidement à des pratiques qui recréent de la dette.

Ce que Marc doit faire inscrire dans les spécifications

Dans le cas fictif de Marc, le danger ne vient pas du choix de WordPress en lui-même. Il vient de la formule « on verra pendant la migration ». Cette phrase transforme les décisions d’architecture en urgences, et les urgences en dépassements de budget.

Les spécifications doivent donc décrire les éléments qui seront conservés, transformés ou abandonnés. Elles doivent préciser les types de contenus, les champs, les taxonomies, les relations, les médias, les URLs, les redirections, les vues et les règles de publication. Elles doivent aussi indiquer qui valide chaque étape.

Le périmètre doit distinguer clairement:

• La préparation de l’architecture WordPress.
• Le développement des champs et des templates.
• L’export des données Drupal.
• Le mapping et l’import initial.
• Le traitement des cas particuliers.
• Le nettoyage des contenus.
• La réécriture des requêtes et des filtres.
• La préparation des redirections.
• Les tests de charge et de non-régression.
• La bascule et le suivi après mise en ligne.

Cette séparation évite de présenter comme une seule tâche ce qui relève en réalité de plusieurs métiers. Un import automatisé ne comprend pas la stratégie SEO. Un développeur de thème ne connaît pas forcément les règles métier cachées dans une View. Une personne qui valide les pages visibles ne repérera pas nécessairement une relation cassée entre deux entités.

La question du budget doit suivre la même logique. Le coût de migration d’un site Drupal ne se limite pas au temps passé à déplacer les contenus. Il inclut l’audit, la conception, les scripts, les licences éventuelles, l’environnement de test, la validation, la reprise des erreurs, les redirections et la surveillance après lancement. Les projets qui semblent peu coûteux au départ sont souvent ceux qui ont oublié une de ces lignes.

Une migration réussie est une décision d’architecture

Revenir à Drupal peut être le bon choix. Passer à WordPress peut également être pertinent. Aucun des deux CMS ne règle automatiquement les problèmes d’un site ancien. Le choix doit tenir compte du modèle de contenu, des compétences disponibles, des besoins éditoriaux, de la stratégie de maintenance et de la capacité de l’équipe à faire vivre l’architecture après la refonte.

La migration Drupal vers WordPress devient dangereuse lorsqu’elle est vendue comme une opération mécanique. Les outils de conversion de contenu peuvent accélérer une partie du travail, mais ils ne décident pas à la place de l’équipe ce qu’est une entité, une relation, une archive ou un composant éditorial. Ils ne savent pas non plus quelles anciennes URLs portent encore de la valeur.

Pour Marc — personnage fictif, mais représentant de nombreux responsables techniques — la bonne posture consiste à ralentir avant d’accélérer. Inventorier les données, documenter le mapping, sauvegarder Drupal, tester les imports, préparer les redirections et isoler les requêtes complexes: ces étapes paraissent moins visibles qu’une nouvelle page d’accueil. Ce sont pourtant elles qui déterminent si la migration sera une refonte maîtrisée ou un déplacement de problèmes.

WordPress peut offrir une base plus accessible et plus simple à maintenir. Mais cette promesse ne tient que si le nouveau site est conçu comme un produit durable, pas comme un conteneur destiné à recevoir en urgence tout ce que l’ancien CMS renfermait.