Migration d'un site WordPress vers Drupal : préservation du référencement, migration du contenu et des médias, refonte du modèle éditorial, gestion des workflows de publication multi-acteurs, multilingue avancé.
WordPress domine le web (40%+ des sites mondiaux) grâce à sa simplicité et son écosystème de plugins. Mais sur certains profils d'usage, il atteint des limites structurelles. Workflow éditorial multi-acteurs : auteur > relecteur > publication, avec validations et droits granulaires, est mal adapté nativement (extensions tierces fragiles). Multilingue avancé : WPML est puissant mais complexe à maintenir, surtout en RTL. Modélisation de contenu structurée : types de contenus complexes avec relations, taxonomies imbriquées, contenus partagés entre sections. Performance à grande échelle : sites institutionnels et médias avec 10 000+ pages.
Drupal 10/11 est conçu pour les sites éditoriaux complexes. Workflow natif : Drupal Workflows + Content Moderation pour des chaînes de validation à plusieurs niveaux. Multilingue natif (depuis Drupal 8) : pas besoin d'extension, gestion des entités traduites cohérente, support RTL solide. Modèle de contenu fortement typé : Entity API, Field API, Paragraphs pour le contenu structuré. Sécurité éprouvée : audit OWASP, équipe sécurité dédiée. Multi-sites natif pour les organisations gérant plusieurs marques ou pays. Voir notre expérience Drupal sur Ministère Culture KSA et plateformes multi-sites.
Trois pièges courants. Préservation SEO : changement d'URL, perte des données Yoast (méta-descriptions, images OG), redirections 301 manquantes. Plugins critiques : ACF, Gravity Forms, Elementor n'ont pas d'équivalents directs en Drupal — refonte nécessaire. Conduite du changement : éditeurs habitués à Gutenberg WordPress doivent apprendre Drupal Layout Builder ou Paragraphs. Les projets qui négligent ces trois points déraillent typiquement de 30-50% sur le planning.
WordPress mono ou multi-sites avec extensions critiques (WPML, ACF, Yoast)
Sites éditoriaux structurés, workflows multi-acteurs, multilingue avancé. Choix par défaut pour migration WP éditoriale.
Site cherchant performance Core Web Vitals max et flexibilité front. Voir Migration CMS vers headless.
Si le besoin est seulement la performance ou la sécurité, sans complexité éditoriale, optimiser WordPress (mise à jour, audit plugins, hosting performant) coûte moins cher qu'une migration.
Migration plus radicale vers stack JavaScript moderne. Effort plus important mais résultat performant.
Une migration WordPress vers Drupal se structure typiquement sur 4 à 9 mois selon le volume de contenu et la complexité éditoriale. Pour un site institutionnel ou média avec 500 à 2000 articles, comptez 4 à 6 mois en cellule de 4-5 personnes : architecte Drupal, deux développeurs Drupal (modules custom, thème), un intégrateur, un référent éditorial. Pour des programmes plus larges (multi-sites, multilingue 5+ langues, 5000+ articles), comptez 6 à 9 mois et 6-8 personnes.
Préservation SEO mal cadrée. Le changement de structure d'URL casse les positions Google si les redirections 301 ne sont pas exhaustives. Les métadonnées Yoast (meta-description, OG image) ne migrent pas automatiquement.
Cartographie URL complète avant tout dev, table de redirections 301 exhaustive validée par le SEO référent. Migration des métadonnées via scripts custom (Yoast → Drupal Metatag). Audit Search Console post-migration sur 90 jours. Voir aussi le parcours Migration CMS vers headless pour les patterns SEO préservation.
Sous-estimer les plugins critiques. ACF (Advanced Custom Fields), Gravity Forms, Yoast, Elementor sont au cœur des sites WordPress mais n'ont pas d'équivalents 1-for-1 en Drupal.
Inventaire exhaustif des plugins dès l'Intake : qualification de chaque plugin (équivalent Drupal natif, contrib module, à réécrire). ACF → Field API + Paragraphs, Gravity Forms → Webform module, Elementor → Layout Builder, Yoast → Metatag + Pathauto + Schema.org. Tests fonctionnels par cas d'usage.
Migration de contenu fragile. Les sites WordPress ont des contenus avec des shortcodes, des blocs Gutenberg complexes, des médias dispersés (uploads multi-années). Une migration naïve casse des centaines de pages.
Migrate API Drupal avec scripts custom par type de contenu, conversion des shortcodes en Paragraphs ou blocs équivalents, ré-import des médias avec préservation des chemins. Tests par échantillon avant migration de masse. Phase de double-run où WP reste accessible le temps de la validation.
Conduite du changement éditeurs négligée. Les éditeurs WP habitués à Gutenberg trouvent Drupal moins intuitif au démarrage.
Formation hands-on des éditeurs sur 2-3 sessions courtes avant et après go-live. Documentation visuelle des nouveaux flux. Customisation Drupal Layout Builder ou Paragraphs pour rester proche de l'expérience Gutenberg. Hyper-care de 4-6 semaines post-bascule avec présence renforcée.
Refonte digitale complète d'une université publique du Moyen-Orient sur Drupal CMS, avec gestion bilingue native arabe/anglais, RTL natif, intégration APIs RESTful vers les services académiques. Capacité Drupal cible éprouvée sur projet livré.
Plateforme XR sur 14 sites patrimoniaux pour un ministère de la culture (Vision 2030), CMS de gestion patrimoniale Drupal bilingue arabe/anglais. Capacité Drupal cible sur projet stratégique multi-annuel.
Maîtrise des CMS WordPress source via projets livrés : Azur City (3 centres commerciaux, plateforme multi-sites WordPress) et Gnet News (portail actualité WordPress). Cette expertise WordPress backend permet de bien comprendre le patrimoine source à migrer (plugins, custom fields, taxonomies, médias) avant la traduction vers Drupal.
Trois raisons légitimes. Workflow éditorial multi-acteurs complexe (auteur, relecteur, validation, publication) que WP gère mal nativement. Multilingue avancé (5+ langues, RTL) : Drupal multilingue natif est plus robuste que WPML. Modélisation de contenu structurée avec relations complexes. Si le besoin est juste de la performance ou de la sécurité, optimiser WP coûte moins cher.
Trois leviers. Cartographie URL exhaustive avant tout dev avec table de redirections 301. Migration des métadonnées Yoast vers Drupal Metatag via scripts. Monitoring Search Console sur 90 jours post-migration avec alerte sur baisse de positions. Sur les projets bien cadrés, perte de trafic SEO inférieure à 5% transitoire, retour à la normale en 6-8 semaines.
Pour un site éditorial de 500-2000 articles, comptez 4-6 mois avec une cellule de 4-5 personnes en co-delivery nearshore. Pour des programmes plus larges (multi-sites, multilingue 5+ langues, 5000+ articles), 6-9 mois et 6-8 personnes.
Le coût d'une migration WordPress vers Drupal dépend du nombre d'articles et de types de contenu, mais surtout du nombre d'extensions critiques sans équivalent Drupal (champs personnalisés, multilingue, SEO), qui doivent être reconstruites plutôt que migrées. La troisième variable est le périmètre éditorial : mono-site ou multi-sites, et le nombre de langues. Cadrage initial gratuit, de 30 minutes à 2 heures.
Cela dépend de votre état actuel. Si vous êtes sur Drupal 7 ou 8 en fin de support, prioriser un upgrade Drupal vers une version maintenue (D10/D11) est généralement plus rapide et moins risqué qu'une refonte complète. Si vous voulez sortir du monolithe et ouvrir l'application aux canaux modernes (mobile, API), regarder plutôt la migration CMS headless (Strapi, Drupal headless via JSON:API, WordPress headless via WPGraphQL).
Nous cadrons la trajectoire, le chiffrage et les livrables en un premier échange de trente minutes. Un POC court peut être proposé avant engagement du programme complet.
Lancer ce parcours →