Migration Drupal 7 → Next.js 16 + Payload CMS — Sortir de l'impasse avant la catastrophe

#Drupal 7 EOL — Janvier 2025, la date est passée

La fin de vie de Drupal 7 n'est plus un événement futur — c'est un fait accompli. La Drupal Association a officiellement arrêté le support de sécurité de Drupal 7 le 5 janvier 2025, après trois reports successifs (initialement prévu en novembre 2022, puis novembre 2023, puis janvier 2025). Les Drupal Security Advisories (SA-CORE) publiés depuis cette date ne couvrent que Drupal 10 et Drupal 11. Les modules contribués de l'écosystème Drupal 7 — Views, Pathauto, Metatag, Token, Webform, Redirect, IMCE, Media, Date, Link, Paragraphs — ne reçoivent plus de mises à jour de sécurité de la part de la Drupal Security Team.

#PHP 7.4 EOL — Le problème sous le problème

Drupal 7 fonctionne sur PHP 5.6 à PHP 7.4. La version PHP 7.4 — la plus récente compatible — est en fin de vie depuis le 28 novembre 2022. PHP 8.0, 8.1 et les versions supérieures ne sont pas officiellement supportées par Drupal 7 core (des patchs communautaires existent mais sans garantie de stabilité ni de sécurité). En pratique, un site Drupal 7 en production en 2026 tourne sur un CMS non patché, avec un runtime PHP non patché, servi par un serveur web qui doit maintenir une configuration PHP obsolète. Les hébergeurs majeurs (OVH, Scaleway, AWS) déprécient progressivement PHP 7.4 de leurs offres managées — certains ne le proposent déjà plus.

Les CVEs PHP 7.4 non patchées s'accumulent : vulnérabilités dans les fonctions de manipulation de chaînes multioctets (mbstring), dans les parsers XML (libxml2), dans les extensions PDO et MySQLi. Chaque CVE PHP non corrigée est une surface d'attaque supplémentaire pour le site Drupal 7 qui tourne dessus.

#Vulnérabilités Drupal 7 historiques — Un rappel utile

Drupal 7 a un historique de failles critiques qui montre que le risque est réel, pas théorique. SA-CORE-2014-005 (« Drupageddon ») — injection SQL permettant l'exécution de code arbitraire, exploitée massivement dans les heures suivant sa publication. SA-CORE-2018-002 (« Drupageddon 2 ») — exécution de code à distance via l'API AJAX de Drupal, score CVSS 9.8, exploitée en masse sur les sites non patchés. SA-CORE-2019-003 — XSS via les modules File et Image de Drupal core. Ces failles ont été patchées à l'époque, mais les prochaines failles découvertes sur Drupal 7 ne le seront pas. Le modèle de sécurité de Drupal reposait entièrement sur la réactivité de la Drupal Security Team — cette couverture n'existe plus.

#Drupal 10/11 vs Headless (Next.js 16 + Payload CMS) — La comparaison honnête

Lorsqu'on quitte Drupal 7, deux stratégies s'offrent à vous. Les deux sont des refontes complètes — autant être lucide dès le départ.

#Option A — Migrer vers Drupal 10 ou 11

Drupal 10 (LTS jusqu'en 2028) et Drupal 11 (stable depuis 2024) sont des CMS matures et puissants. La migration depuis Drupal 7 utilise le module Migrate API de Drupal core, qui permet de mapper les types de contenu, les taxonomies et les champs de Drupal 7 vers Drupal 10/11. Mais attention : le chemin de migration n'est pas automatique. Les modules contribués Drupal 7 n'ont pas tous un équivalent Drupal 10 (certains ont été absorbés dans le core, d'autres abandonnés, d'autres encore ont changé d'architecture). Les thèmes Drupal 7 (PHP templates, .tpl.php) ne fonctionnent pas sous Drupal 10 (Twig templates) — le thème doit être recréé intégralement. Les hooks et les fonctions custom en PHP Drupal 7 procédural doivent être réécrits en PHP 8.2+ orienté objet avec le système de plugins/services Drupal 10.

En pratique, la migration Drupal 7 vers Drupal 10 coûte autant d'effort qu'un changement de plateforme — sans les gains architecturaux du headless. Drupal 10 reste pertinent si votre organisation a des compétences PHP/Drupal solides en interne et que le contexte l'exige (multisite massif, intégration avec des systèmes Drupal existants). Dans tous les autres cas, autant profiter de cette refonte obligatoire pour passer sur une architecture moderne.

#Option B — Migrer vers Next.js 16 + Payload CMS (recommandation Nehos)

L'approche headless découple le frontend (ce que voit l'utilisateur) du backend de contenu (ce que gère l'équipe éditoriale). Next.js 16 assure le rendu côté serveur (React Server Components), le routing, la performance et le SEO technique. Payload CMS 3.x assure la gestion de contenu — interface d'édition moderne, API REST et GraphQL auto-générées, collections typées TypeScript, gestion des médias intégrée, versionning de contenu, workflows de publication, et support multilingue natif.

Pourquoi Payload CMS plutôt qu'un autre headless CMS ? Payload est open source (MIT), auto-hébergeable (pas de vendor lock-in), construit nativement en TypeScript avec Next.js, et offre une expérience éditoriale qui rivalise avec les CMS propriétaires. Les collections Payload se définissent en code TypeScript (config-as-code), ce qui permet le versioning Git, les reviews de schéma en PR, et la reproductibilité entre environnements. C'est un choix délibéré chez Nehos : on privilégie les stacks où le client garde le contrôle total.

Les gains concrets du passage au headless. Performance : Lighthouse 90+ sur mobile (contre 40-60 typique pour un Drupal 7 avec thème custom non optimisé). SEO technique : SSR natif, Core Web Vitals optimisés, structured data via Server Components, sitemap dynamique. Expérience éditoriale : interface Payload CMS moderne vs le back-office Drupal 7 vieillissant. Sécurité : surface d'attaque réduite (pas de PHP exposé sur le frontend, Payload CMS derrière une API authentifiée). Déploiement : Vercel ou OVH avec déploiements atomiques, previews par branche, rollback en 1 clic.

#Stratégie de migration du contenu — De Drupal 7 vers Payload CMS

La migration du contenu est le coeur du projet. Un site Drupal 7 est une base de données MySQL/MariaDB avec un schéma normalisé complexe : tables node, field_data_*, taxonomy_term_data, taxonomy_index, url_alias, redirect, file_managed, menu_links. L'extraction propre de ce contenu nécessite une méthodologie rigoureuse.

#Export via Drush et l'API JSON

Drush (Drupal Shell) est l'outil CLI de référence pour interagir avec une instance Drupal. Pour l'export de contenu, on combine Drush avec le module JSON:API (disponible pour Drupal 7 via le module contribué jsonapi ou via Views Datasource). La stratégie d'export Nehos : (1) inventaire des Content Types et de leurs champs via drush field-info fields et drush content-type-list, (2) export JSON de chaque type de contenu avec ses champs, ses références taxonomiques, ses fichiers attachés et ses alias d'URL, (3) export des taxonomies (vocabulaires et termes) avec leur hiérarchie, (4) export des menus et de la structure de navigation, (5) export des redirections (module Redirect) et des alias d'URL (module Pathauto).

Pour les sites volumineux (1 000+ nodes), l'export se fait par batch via des scripts Drush custom qui paginent les requêtes et écrivent des fichiers JSON par type de contenu. L'intégrité référentielle est vérifiée à chaque étape : chaque référence taxonomique, chaque fichier média, chaque lien interne doit exister dans l'export.

#Transformation et import dans Payload CMS

Les fichiers JSON exportés de Drupal 7 sont transformés par des scripts Node.js/TypeScript qui mappent la structure Drupal vers les collections Payload CMS. Content Types Drupal deviennent des Collections Payload. Taxonomies Drupal deviennent des Collections ou Relations Payload. Champs Field API Drupal (Text, Long Text, Image, File, Entity Reference, Date, Link) deviennent des Fields Payload typés (text, richText, upload, relationship, date, link). Body HTML Drupal (format Full HTML ou Filtered HTML) est converti en richText Payload (éditeur Lexical) avec nettoyage des balises obsolètes et des inline styles.

Point d'attention critique : les contenus Drupal 7 contiennent souvent du HTML problématique — balises <font>, <center>, <table> utilisées pour la mise en page, styles inline, classes CSS spécifiques au thème Drupal. Le script de transformation inclut un pipeline de nettoyage HTML (via rehype et sanitize-html) qui normalise le contenu avant import dans le richText Payload.

#Mapping des redirections SEO — Zéro perte de trafic organique

C'est le point que beaucoup de prestataires négligent et qui coûte le plus cher en trafic perdu. Drupal 7 génère des URLs via le module Pathauto (ex: /actualites/mon-article-2024), mais conserve aussi les URLs internes Drupal (/node/1234). Quand vous changez de plateforme, chaque URL Drupal 7 qui reçoit du trafic organique doit être redirigée en 301 vers son équivalent Next.js.

La méthodologie Nehos pour les redirections SEO. Phase 1 — Inventaire : extraction de toutes les URLs indexées via Google Search Console (rapport Pages indexées), croisée avec les données Google Analytics (URLs recevant du trafic organique sur les 12 derniers mois), croisée avec les alias Pathauto et les redirections du module Redirect. Phase 2 — Mapping : chaque URL Drupal 7 est mappée vers son équivalent dans la nouvelle architecture Next.js. Les URLs qui changent de structure (ex: /content/mon-article vers /blog/mon-article) sont documentées dans un fichier de mapping CSV audité manuellement. Phase 3 — Implémentation : les redirections sont implémentées dans next.config.ts via le tableau redirects pour les patterns prévisibles, et dans un middleware Next.js pour les cas complexes (redirections conditionnelles, regex, multilinguisme). Phase 4 — Validation : crawler Screaming Frog sur l'ancien sitemap pour vérifier que 100 % des URLs retournent un 301, monitoring Search Console pendant 3 mois post-migration pour détecter les erreurs 404.

Sur nos 12 dernières migrations Drupal 7, le trafic organique a été maintenu ou amélioré dans les 60 jours post-migration sur 100 % des cas.

#Migration des médias — Fichiers, images, documents

Les fichiers médias Drupal 7 (images, PDFs, documents) sont stockés dans le répertoire sites/default/files/ et référencés dans la table file_managed. La migration des médias suit un pipeline en trois étapes. (1) Export : extraction de tous les fichiers du répertoire files/ avec leurs métadonnées (nom original, type MIME, taille, date, alt text si renseigné dans le champ Image). (2) Optimisation : les images sont optimisées et converties en formats modernes (WebP, AVIF) via Sharp avant upload — les images Drupal 7 sont souvent en JPEG/PNG non optimisé avec des dimensions excessives. (3) Upload vers Payload CMS : les fichiers sont importés dans la collection Media de Payload avec leurs métadonnées (alt text, légende, crédits), puis liés aux contenus correspondants via les relations Payload.

#Multilinguisme — De i18n/Entity Translation vers next-intl

Si votre site Drupal 7 est multilingue (modules i18n, Entity Translation, ou Content Translation), la migration linguistique ajoute une couche de complexité. Drupal 7 gère le multilinguisme via le module i18n (Internationalization) avec une approche par noeud traduit ou par champ traduit selon la configuration. L'export inclut toutes les traductions de chaque noeud et de chaque terme de taxonomie.

Côté Next.js, le multilinguisme est géré via next-intl ou le routing i18n natif de Next.js 16 (préfixe de locale dans l'URL : /fr/, /en/, /de/). Côté Payload CMS, les collections sont configurées en mode localisé (localization: { locales: ['fr', 'en', 'de'] }) — chaque document Payload stocke ses traductions dans le même objet, ce qui simplifie la gestion éditoriale par rapport à l'approche Drupal 7 où les traductions sont des nodes séparés.

#Performance — De LAMP/LEMP vers Next.js 16 / Edge

Un site Drupal 7 typique en production tourne sur une stack LAMP (Linux, Apache, MySQL, PHP) ou LEMP (Nginx, MySQL, PHP-FPM). Chaque requête utilisateur déclenche un cycle complet : bootstrap Drupal (chargement des modules, initialisation de la base, exécution des hooks), requêtes SQL (souvent des dizaines pour une seule page), rendu PHP du template, et envoi du HTML. Même avec les caches Drupal (Page cache, Block cache, Views cache) et un CDN en frontal, le TTFB d'un site Drupal 7 dépasse souvent les 800 ms à 1,5 s sur les pages non cachées.

Next.js 16 change fondamentalement cette architecture. Les pages statiques sont pré-générées au build (ISR — Incremental Static Regeneration) et servies directement depuis le CDN edge avec un TTFB de 20 à 50 ms. Les pages dynamiques utilisent les React Server Components pour un rendu serveur streaming. Les images sont optimisées automatiquement par next/image (lazy loading, formats modernes, dimensions responsives). Les polices sont auto-optimisées par next/font.

Résultat mesurable sur nos migrations Drupal 7 vers Next.js : Lighthouse Performance mobile passe de 40-55 à 90-98, TTFB de 800 ms-1,5 s à 30-80 ms, LCP de 3-5 s à 1-1,5 s. Ces gains Core Web Vitals ont un impact direct et mesurable sur le ranking Google depuis la mise à jour Page Experience.

#Méthodologie Nehos — Phases et calendrier

Phase 0 — Audit site Drupal 7 (5 à 10 jours, à partir de 992 € HT déductibles du projet). Inventaire des Content Types, des champs Field API, des taxonomies, des vues Views. Inventaire des modules contribués actifs et de leur criticité. Audit SEO : URLs indexées, trafic par page, backlinks (Ahrefs/Semrush). Audit performance Lighthouse mobile + desktop. Audit sécurité : version PHP, modules non maintenus, failles connues. Output : plan de migration contenu par contenu, plan de redirections URL par URL, architecture Payload CMS cible, chiffrage définitif.

Phase 1 — Socle technique Next.js 16 + Payload CMS (2 à 3 semaines). Initialisation projet Next.js 16 (App Router, TypeScript strict, Tailwind CSS, ESLint, Prettier). Installation et configuration Payload CMS 3.x (collections, uploads, authentification, API). Configuration CI/CD (GitHub Actions : lint, type-check, tests, build, déploiement Vercel ou OVH). Scripts de migration contenu (export Drush puis transformation Node.js puis import Payload API).

Phase 2 — Migration contenu et développement frontend (6 à 14 semaines selon volume). Exécution des scripts de migration contenu par type. Développement des templates Next.js (pages, articles, catégories, landing pages). Intégration du design system (Tailwind + composants React). Implémentation des redirections SEO 301. Tests Playwright sur les parcours critiques. Validation SEO page par page (méta tags, structured data, canonical, hreflang).

Phase 3 — Bascule DNS et surveillance post-migration (1 à 2 semaines). Bascule DNS vers la nouvelle infrastructure. Monitoring 404 via Search Console et middleware Next.js. Monitoring Lighthouse et Core Web Vitals. Soumission du nouveau sitemap à Google Search Console. Support réactif pendant 30 jours post-bascule.

#ROI — Cas ETI industrielle (450 pages, 3 langues)

Cas client de référence : ETI industrielle secteur aéronautique, site corporate Drupal 7 de 450 pages en trois langues (FR/EN/DE), en production depuis 2014. Enjeux initiaux : failles de sécurité post-EOL, Lighthouse mobile 48, formulaires de contact avec taux d'abandon élevé, refonte graphique impossible sans refondre le thème D7, hébergement PHP dédié coûteux.

Mission Nehos : migration vers Next.js 16 + Payload CMS sur 4 mois. Audit Phase 0 (8 jours). Socle Next.js + Payload (2,5 semaines). Migration contenu + développement (9 semaines). Bascule DNS (1 semaine). Investissement total : 101 k€ HT. Résultats à 3 mois post-bascule : Lighthouse mobile 96 (de 48 à 96, +48 points), 0 perte de trafic organique (redirect mapping 100 %), TTFB 1,2 s réduit à 45 ms, leads formulaire +34 % (React Hook Form vs Webform D7), coût hébergement réduit de 55 % (Vercel + PaaS Node.js vs serveur PHP dédié).

#Tarification — 1,5 k€ HT

Trois fourchettes de prix selon la taille et la complexité du site Drupal 7.

Site vitrine 50 à 200 pages, monolangue : 1,5 k€ HT sur 2 à 3 mois. Inclut l'audit Phase 0, la mise en place Next.js + Payload CMS, la migration de contenu, les redirections SEO, et 1 mois de stabilisation.

Site corporate 200 à 500 pages, multilingue : 35 à 511 k€ HT sur 3 à 5 mois. Inclut le périmètre précédent plus la migration multilingue, les formulaires complexes (Webform vers React Hook Form), les intégrations tiers (CRM, analytics, newsletter), et la formation de l'équipe éditoriale à Payload CMS.

Site complexe 500 à 2 000+ pages, e-commerce ou intranet : 13,5 k€ HT sur 4 à 6 mois. Inclut tout le périmètre précédent plus la migration e-commerce (Drupal Commerce vers Saleor/Medusa ou intégration Shopify headless), la migration des espaces authentifiés, les workflows de publication complexes dans Payload, et l'accompagnement DevOps pour l'infrastructure de production.

Tous les tarifs incluent l'audit initial de 5-10 jours. Estimation précise en 30 minutes via RDV : Calendly migration Drupal 7.