De Drupal à Next.js : ce qui fonctionne, ce qui ne fonctionne plus, ce qu’il faut faire.

Ce qui est transféré de Drupal vers Next.js, et ce qui ne l'est pas?

Votre modèle de contenu ne survit que si vous gardez Drupal derrière la nouvelle interface utilisateur. Il en va de même pour vos autorisations et les habitudes de vos rédacteurs. Vos modèles Twig et votre thème, eux, ne se transfèrent nulle part ; ne comptez donc pas conserver l'ancienne présentation. Dans une configuration découplée, vos pages se nourrissent du module JSON:API, standard dans toutes les applications Drupal découplées, et vous ne reconstruisez que la couche de présentation. Mais si vous abandonnez Drupal, vous repensez le modèle sur la plateforme cible.

Vérifiez vos hypothèses avant de commencer la mise en place. Commencez par ce qui se cache. Vous ne pouvez pas interroger le nom de votre site, votre slogan, votre page d’accueil, votre logo ou votre favicon via JSON:API, car ils vivent dans la configuration simple ; vous devez donc les recréer à la main. Ces détails n’ont rien de cas particuliers, et ce sont pourtant ceux qu’on oublie le plus souvent. Vos images intégrées et vos jetons d’intégration se comportent comme les shortcodes WordPress ; vérifiez donc chaque occurrence avant la mise en production. Les paragraphes et les champs de référence d’entités ressemblent davantage aux modèles « headless » qu’aux structures WordPress, ce qui vous donne une longueur d’avance sur la définition du schéma.

Comment planifiez-vous la structure des URL et les redirections afin de préserver votre trafic de recherche ??

Vous cartographiez vos URL avant d’écrire la moindre ligne de code : exportez toutes les URL actives et tous les alias de chemin, puis reliez chacun à une seule nouvelle adresse. Commencez par là. Le module Redirect de Drupal attribue une URL canonique à chaque contenu et renvoie les autres alias vers elle avec une redirection 301 ; vos redirections existantes doivent donc entrer dans l’inventaire dès le départ. Les alias font partie de la cartographie. Et si vous les traitez comme un ménage à faire après le lancement, votre trafic fuit sans faire de bruit. Quand plusieurs alias de votre site mènent au même nœud, c’est à vous de décider lequel reste.

Sur le nouvel hébergeur, configurez des redirections 301 ou 308 côté serveur, sans chaîne de redirection. Ensuite vient le nettoyage : mettez à jour vos liens internes, publiez un nouveau plan du site, pointez vos balises canoniques vers les nouvelles URL et supprimez les règles « noindex » temporaires. Les balises canoniques doivent indiquer les nouvelles adresses, pas les anciennes. Mais si vous comptez seulement sur rel=canonical, gardez en tête que Google le traite comme une suggestion, pas comme une instruction. Testez vos redirections avec l’outil d’inspection des URL, ou écrivez un script si vous en gérez des milliers. Sur un site de grande taille, migrez section par section, surveillez le trafic sur les deux sites et relisez vos rapports d’erreurs 404 pour retrouver les URL oubliées. Gardez vos redirections actives au moins un an.

Comment le contenu est-il transféré depuis Drupal : exportation, API ou exploration ??

Extrayez le contenu de Drupal via des requêtes API. Les exportations de base de données et le scraping de pages existent aussi, bien sûr. Prenez la source la plus propre. C’est l’API, parce que votre contenu y est déjà structuré. Quand JSON:API est activé, vous interrogez un chemin comme /jsonapi/node/article et vous recevez vos articles en JSON typé, avec les références intactes. Une exportation brute vous laisse des fichiers plats à reformater. Quant à l’exploration, elle ne récupère que ce qu’affichent vos pages rendues : réservez-la aux pages orphelines, et rien de plus.

Commencez par mapper vos données à la main. Pas de raccourci ici. La traduction du schéma demande votre attention avant tout script, tout comme la modélisation des références et les règles de localisation. Lancez l’import automatisé en dernier, pas en premier. Ensuite, votre système cible ingère les enregistrements avec son outil d’import ou son API d’écriture. Si vous gardez Drupal comme backend, vous sautez l’import : votre front-end interroge directement cette même API en temps réel.

Vérifiez séparément vos contenus multimédias : fichiers, textes alternatifs et PDF passent chacun leur tour. Ensuite, vos éditeurs contrôlent un échantillon de chaque type de contenu.

Quels avantages vos rédacteurs bénéficient-ils sur Next.js par rapport à Drupal ??

Vos rédacteurs n’auront des écrans de prévisualisation et de publication à la demande que si vous les construisez, car votre front-end Next.js retire la couche de thème de Drupal. Drupal ne s’en occupe plus pour le nouveau front-end. Dans une approche découplée, vos rédacteurs gardent l’interface d’administration Drupal qu’ils connaissent. Vous configurez le mode « Brouillon » pour qu’ils puissent ouvrir la page d’un nœud et prévisualiser les brouillons comme les révisions non publiées. Le bouton de prévisualisation peut aussi fonctionner avant la première sauvegarde.

C’est vous qui configurez ce qui doit être actualisé. Soyez précis. Avec le plugin « tags », votre site Drupal envoie des balises de cache à votre point de terminaison de revalidation Next.js, qui invalide alors les données associées. Seul ce que vous connectez est concerné. Si votre page d’accueil liste des articles, ajoutez à la main son chemin aux paramètres de revalidation des articles. Donc contrôlez chaque page de liste que vous exploitez [les pages aux données périmées sont toujours celles que personne n’a vérifiées].

Si vous choisissez plutôt un CMS « headless », vos rédacteurs doivent apprendre une nouvelle interface hébergée. C’est le compromis. Sanity Visual Editing leur permet, quel que soit le forfait choisi, de passer en un clic de l’aperçu de votre site à l’environnement Studio pour y modifier le contenu. Côté Drupal, vous abandonnez les modules, et vous reconfigurez vos droits d’accès au lieu de les transférer tels quels.

Combien de temps dure une migration de Drupal vers Next.js, et quels sont les facteurs qui déterminent l'ampleur de la tâche ??

Votre calendrier tient à cinq facteurs que vous pouvez chiffrer dès aujourd'hui. Commencez par vos URL et vos types de contenu : faites-en l'inventaire complet, puis comptez vos médias. Ajoutez ensuite vos intégrations et vos paramètres régionaux (c'est souvent là que tout s'allonge). Dans le scénario le plus lourd, une étude de référence publiée estime qu'une migration d'entreprise type de Drupal vers Contentful prend entre 12 et 22 semaines, avec un risque modéré. Ce délai couvre la refonte du modèle de données, son import et la reconstruction complète du front-end. La localisation, la configuration des flux de travail et la formation des équipes éditoriales entrent aussi dans cette enveloppe. Mais votre site demandera peut-être beaucoup moins : estimez la durée à partir de vos propres chiffres, pas de la moyenne des autres.

Garder Drupal raccourcit la migration de vos contenus. En échange, vous conservez deux systèmes à gérer, et votre équipe doit maintenir puis surveiller à la fois un hébergement Drupal et un hébergement Next.js. Remplacer Drupal, c'est migrer votre contenu plus facilement et en finir, pour de bon, avec votre hébergement Drupal.

Je conçois et mène ce type de migration : architectures historiques, parcs WordPress, bascules vers Astro ou Next.js. Les chiffres passent avant le reste. Le nombre de paramètres régionaux et votre liste d'intégrations m'en disent d'abord plus que le total de pages. Alors je les audite avant de regarder la volumétrie.

Dans quels cas ne faut-il pas passer de Drupal à Next.js ??

Ne changez pas de plateforme si votre site Drupal fonctionne bien. Si vos rédacteurs y travaillent sans encombre et que votre trafic de recherche reste stable, une migration met ces trois éléments en danger. Restez où vous êtes lorsque l'évaluation gratuite donne à votre site un bon score de santé, entre 80 et 100, et que vos faiblesses se corrigent directement dans Drupal : en-têtes HTTP, cache, sortie de schéma ou poids des images. Il s'agit alors d'un chantier de correction sur place. Et parler de migration reviendrait ici à vous vendre une prestation dont vous n'avez pas besoin.

Choisissez cette approche si vous ne pouvez pas financer l'exploitation de deux systèmes, car une architecture découplée garde Drupal à côté d'une interface distincte. Le coût compte vraiment. Attendez si votre seule motivation vient de l'effet de mode. Ce changement devient rentable lorsque vous construisez une vraie application. Il le devient aussi si vous exigez de la personnalisation ou si de nombreux rédacteurs travaillent sur un modèle structuré.

Votre choix dépend simplement de vos besoins. Astro convient lorsque votre site rassemble surtout des pages de contenu ou du marketing. Pour une application, de la personnalisation ou une équipe éditoriale nombreuse, Next.js associé à Sanity ou Contentful fait l'affaire. Astro retire l'espace de travail visuel à vos rédacteurs. Et un CMS « headless » remplace vos modules et votre console d'administration autonome par un tableau de bord géré.

Vos questions, nos réponses.

À lire ensuite.

1. 01Alternatives à DrupalMettez à niveau, dissociez ou déplacez, en fonction de vos pages.
2. 02De Drupal vers WordPressQuand la simplicité est de mise, et ce que le modèle de contenu perd.
3. 03Audit SEO Next.jsMode de rendu, métadonnées, coût d'hydratation.
4. 04Audit SEO de CMS headlessRendu, URL canoniques, aperçus, données structurées du modèle.