Migration d'un site Drupal vers une architecture headless : Drupal 11 conservé comme back-office et exposé par JSON:API, front pré-généré en Next.js ou Astro, cas particulier du Drupal 7 en fin de vie, multilingue et workflows éditoriaux préservés.
Depuis Drupal 8.7, le module JSON:API fait partie du cœur : chaque type de contenu, chaque taxonomie, chaque média peut être mis à disposition par API sans développement spécifique, selon les droits d'accès définis dans Drupal ; par défaut, cette API est en lecture seule. Les forces qui ont fait choisir Drupal restent dans le back-office : workflows éditoriaux (Content Moderation), droits fins, multilingue natif, multi-sites. Le découplage (séparer l'affichage du back-office) ne remplace que la couche d'affichage, le thème Twig, par un front moderne.
Drupal 7 n'est plus maintenu par la communauté Drupal depuis le 5 janvier 2025 (drupal.org ; certains prestataires proposent un support étendu payant). Il n'a pas JSON:API dans son cœur et son modèle de données diffère de celui des versions récentes. Passer un Drupal 7 en headless revient donc à migrer d'abord le back-office vers Drupal 11, ou vers un autre CMS headless, puis à construire le front. Les deux chantiers se mènent ensemble : c'est l'occasion de ne pas reconstruire un thème Twig destiné à disparaître. Même logique pour Drupal 10, qui arrive en fin de vie le 9 décembre 2026 (drupal.org) : un projet lancé aujourd'hui vise Drupal 11. Voir Mise à niveau Drupal.
Le choix dépend de ce que le site doit encore faire côté Drupal.
Les robots des moteurs IA lisent le HTML renvoyé par le serveur. Un front pré-généré leur livre chaque page complète, dans chaque langue, avec des balises hreflang maîtrisées. Un front construit dans le navigateur leur livre le plus souvent une page vide (deux exceptions : Google AI Overviews et Microsoft Copilot). Le détail est dans Migration CMS vers headless ; pour un site WordPress, voir Migration WordPress vers headless.
Équipe JavaScript, besoin d'un aperçu éditeur et d'une mise à jour automatique des seules pages modifiées.
Site majoritairement éditorial, peu d'interactivité : pages très légères, presque sans JavaScript.
Espace connecté ou formulaires métier lourds dans Drupal : on découple les pages publiques d'abord, le reste ensuite.
Contenu structuré comme une base de données, équipe à l'aise en SQL, volonté de quitter PHP.
Le thème actuel donne satisfaction et aucun autre canal n'est prévu : une mise à niveau Drupal suffit.
Estimation indicative, à confirmer au cadrage : pour un Drupal 11 déjà à jour, ou un Drupal 10 passé en 11 dans le même projet, comptez 8 à 16 semaines selon le nombre de types de contenus, de langues et de gabarits de page. Pour un Drupal 7, ajoutez la migration du back-office, à chiffrer avec la mise à niveau Drupal. Équipe type : un chef de projet, un développeur Drupal (API, modèle de contenu, migration), deux développeurs front (Next.js ou Astro), un référent SEO à temps partiel.
Requêtes JSON:API en cascade : le front appelle l'API dix fois pour une page parce que les relations ne sont pas incluses.
Paramètres d'inclusion des relations dès la conception, ressources dédiées pour les pages lourdes, mesure du nombre d'appels par gabarit avant la mise en ligne.
Multilingue et écriture de droite à gauche oubliés côté front : Drupal gère les traductions, mais le nouveau front doit gérer lui-même l'arabe, les URL par langue et les balises hreflang.
Routage par langue, mise en page miroir pour l'arabe et balises hreflang conçus dès la première maquette, testés sur chaque gabarit.
Workflow éditorial cassé : les éditeurs perdent l'aperçu des contenus en cours de validation.
Aperçu des brouillons branché sur les états de Content Moderation, pour que le relecteur voie la page finale avant publication.
Référencement perdu à la bascule : alias d'URL Pathauto et métadonnées Metatag non repris par le front.
Alias et métadonnées lus depuis Drupal par le front, cartographie des URL avant développement, redirections 301 exhaustives, suivi Search Console après la mise en ligne.
Refonte du site institutionnel d'une université publique du Moyen-Orient sur Drupal, bilingue arabe et anglais avec écriture de droite à gauche native, et intégration d'API vers les services académiques. Site Drupal classique : la référence porte sur le back-office et le multilingue, pas sur le headless.
Le site access-international.dev est servi par un front Next.js en export statique, sans CMS, bilingue français et anglais, avec balises hreflang complètes.
Non pour l'essentiel : JSON:API est dans le cœur de Drupal depuis la version 8.7. Des modules complémentaires servent ensuite à l'aperçu des brouillons ou à la régénération du front à chaque publication.
Pas raisonnablement. Drupal 7 n'est plus maintenu depuis le 5 janvier 2025 et n'a pas JSON:API dans son cœur. Il faut migrer le back-office vers Drupal 11, ou vers un autre CMS headless, en même temps que l'on construit le front. Voir Mise à niveau Drupal.
Next.js quand il faut de l'interactivité, un aperçu éditeur riche et une régénération incrémentale. Astro pour un site surtout éditorial, avec des pages presque sans JavaScript. Les deux savent produire un HTML pré-généré lisible par les moteurs IA.
Oui, à condition de les traiter côté front dès la conception : Drupal continue de gérer les traductions, mais le routage par langue, la mise en page de droite à gauche et les balises hreflang deviennent la responsabilité du nouveau front.
Le coût dépend de la version de départ (un Drupal 7 impose de migrer aussi le back-office), du nombre de gabarits de page à reconstruire et du nombre de langues. Cadrage initial gratuit, de 30 minutes à 2 heures.
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 →