Migration Drupal Multisite vers Next.js Monorepo

Pourquoi l'architecture Drupal Multisite s'effondre

Drupal multisite était une idée astucieuse en 2012. Un seul code source, des modules partagés, lancez un nouveau sous-site pour chaque département, franchise ou succursale. Les universités fonctionnaient avec 15–30 sous-sites de cette façon. Les organismes gouvernementaux poussaient encore plus loin.

Puis la réalité s'est imposée.

Chaque mise à jour de module devient un déploiement coordonné sur tous les sites. Un correctif de sécurité pour un sous-site signifie un risque d'interruption pour tous les autres. Votre École d'Ingénierie veut un module personnalisé qui entre en conflit avec le thème de l'École de Commerce. Votre franchise à Denver a besoin de flux de travail de contenu différents de celle de Portland, mais ils partagent une configuration de base de données qui rend l'isolation presque impossible.

L'architecture qui vous a fait gagner du temps la première année coûte le triple à la troisième année.

Les problèmes spécifiques que nous rencontrons

• Cauchemars de mise à jour de modules : Un simple drush updb se propage à chaque sous-site. Un hook cassé fait tomber 20 sites simultanément.
• Incohérence des thèmes : Les thèmes de base partagés divergent à mesure que chaque site accumule des remplacements. Le sous-branding se transforme en guerre de spécificité CSS.
• Couplage de base de données : Les tables partagées signifient qu'une migration mal configurée peut corrompre les données entre les locataires. Nous avons vu cela se produire sur un portail gouvernemental fonctionnant avec 40+ sites d'agences.
• Plafond de performance : Le rendu PHP côté serveur de Drupal atteint une limite à grande échelle. Un TTFB de 1,5–2,5 secondes est courant sur les installations multisite sous charge.
• Rareté des talents : Trouver des développeurs Drupal qui comprennent l'architecture multisite, Paragraphs et les références d'entités personnalisées devient plus difficile chaque année. Les talents React/Next.js sont abondants en comparaison.
• Conformité et sécurité : Les bases de code partagées rendent les audits de sécurité au niveau du site presque impossibles — un facteur disqualifiant pour les exigences de conformité gouvernementales et .edu.

Ce que vous obtenez : Next.js Monorepo avec Middleware Tenant et Supabase RLS

L'architecture cible remplace l'intégralité de votre Drupal multisite par une seule application Next.js utilisant l'App Router, une structure monorepo pour le code partagé et spécifique aux locataires, un middleware pour le routage et l'authentification, et Supabase avec Row Level Security pour l'isolation réelle des données.

Comment fonctionne le Middleware Tenant

Le middleware Next.js intercepte chaque requête avant qu'elle n'atteigne vos pages. Pour une université, cela ressemble à ceci :

/departments/engineering → tenant: engineering
/departments/business → tenant: business
/locations/denver → tenant: denver-franchise

Le middleware extrait le slug du locataire, définit le contexte Supabase RLS et la page se rend avec uniquement les données de ce locataire. Aucune requête de base de données partagée ne fuit entre les départements. Aucun déploiement séparé par site.

Votre middleware.ts détecte le locataire à partir du chemin d'URL ou du sous-domaine, définit un paramètre app.current_tenant dans la session Supabase, et chaque requête ultérieure limite automatiquement le contenu aux données de ce locataire.

Supabase Row Level Security : Isolation réelle des données

Chaque table — programs, faculty, events, news, pages — obtient une colonne tenant_id. Les politiques RLS appliquent l'isolation au niveau de la base de données :

CREATE POLICY "tenant_isolation" ON programs
  FOR ALL
  USING (tenant_id = current_setting('app.current_tenant')::uuid);

Ce n'est pas un filtrage au niveau de l'application qui pourrait être contourné par un bug. C'est PostgreSQL qui applique qu'une requête du département d'Ingénierie ne peut littéralement pas voir les enregistrements du département de Commerce. Pour les sites gouvernementaux traitant des données sensibles entre les agences, c'est exactement l'isolation que les auditeurs veulent voir.

Architecture Monorepo

En utilisant Turborepo, la base de code s'organise en :

• packages/ui : Bibliothèque de composants partagés avec thématisation de sous-marque via les propriétés personnalisées CSS
• packages/config : Configuration des locataires — logos, couleurs, structures de navigation, drapeaux de fonctionnalités
• apps/web : L'application Next.js avec des routes dynamiques [tenant]
• packages/db : Client Supabase avec des assistants de requête conscients de RLS

Chaque site de franchise ou département obtient son propre fichier de configuration, pas son propre déploiement. Ajoutez un nouvel emplacement en ajoutant un fichier de configuration JSON et une ligne dans la table des locataires. Aucun changement d'infrastructure.

Notre processus de migration

Phase 1 : Découverte et audit (1–2 semaines)

Nous cartographions chaque sous-site Drupal — types de contenu, taxonomies, menus, alias d'URL, ressources médias, rôles d'utilisateurs et intégrations. Pour les universités, cela signifie cataloguer les connexions SIS, les configurations SSO SAML et les webhooks CRM. Pour les franchises, c'est les localisateurs de sites, les schémas SEO locaux et les intégrations de réservation.

Nous activons l'API JSON de Drupal et exécutons des exportations paginées pour comprendre la forme complète des données : /jsonapi/node/program?page[limit]=50&include=field_department,field_faculty.

Pour les sites Drupal 7 (toujours courants dans les gouvernements), nous interrogeons directement MySQL puisque l'API JSON n'est pas disponible :

SELECT n.nid, n.title, fdb.body_value, fds.field_subtitle_value
FROM node n
JOIN field_data_body fdb ON fdb.entity_id = n.nid
JOIN field_data_field_subtitle fds ON fds.entity_id = n.nid
WHERE n.type = 'program';

Phase 2 : Architecture des données et configuration Supabase (1–2 semaines)

Nous concevons le schéma Supabase avec une isolation appropriée des locataires intégrée dès le départ. Le stockage entité-attribut-valeur de Drupal est aplati en tables relationnelles propres. Les politiques RLS sont écrites et testées avant que toute donnée n'arrive.

La configuration des locataires va dans une table tenants avec des colonnes pour la marque, les drapeaux de fonctionnalités, la navigation et les identifiants d'intégration.

Phase 3 : Création d'application Next.js (3–8 semaines)

C'est là que le gros du développement se produit. Nous construisons :

• Routes dynamiques des locataires : app/[tenant]/page.tsx, app/[tenant]/programs/[slug]/page.tsx
• Middleware : Détection des locataires, authentification, mappage des redirections, gestion des paramètres régionaux
• Composants partagés : Moteurs de recherche de programmes avec recherche facettée, annuaires du corps professoral, calendriers d'événements, flux d'actualités — tous limités par RLS
• Interfaces d'administration : Tableaux de bord limités aux locataires où les administrateurs de département gèrent uniquement leur contenu
• Configuration ISR : revalidatePath pour les mises à jour de contenu sans reconstructions complètes
• Intégration SSO SAML : Critique pour les universités et les portails gouvernementaux

Nous utilisons le développement assisté par IA (Claude Code, Cursor) pour accélérer la conversion Drupal Paragraphs en composants React, qui traite généralement 70–80% des mappages de types de contenu directs.

Phase 4 : Préservation SEO et redirections (1 semaine)

C'est non négociable. Les universités accumulent des milliers de backlinks sur des décennies. Les sites gouvernementaux ont des URL réglementaires qui doivent rester fonctionnelles.

Stratégie de préservation SEO

Nous exportons chaque alias d'URL de Drupal — y compris les chemins /node/1234 vers lesquels les sites externes inévitablement établissent des liens. Ceux-ci sont chargés dans une carte de redirection que le middleware Next.js traite à chaque requête.

Le middleware gère :

• Redirections basées sur les chemins : /school-of-business/mba-program → /departments/business/programs/mba
• Redirections par ID de nœud : /node/4521 → /departments/engineering/faculty/smith
• Consolidation de sous-domaines : business.university.edu → university.edu/departments/business
• Application d'URL canonique : Prévention du contenu dupliqué entre les routes des locataires
• Injection de données structurées : Schémas JSON-LD spécifiques aux départements, balisage LocalBusiness pour les franchises

Nous vérifions chaque redirection avec des analyses automatisées avant le lancement. La Search Console reçoit le sitemap mis à jour immédiatement. Pour les sites .edu, le trafic organique se stabilise généralement dans 2–3 semaines et s'améliore dans 6–8 semaines à mesure que les gains Core Web Vitals prennent effet.

Chronologie et tarification

Étendue	Chronologie	Investissement
Petit (1–5 sous-sites, franchise)	4–8 semaines	50 000–100 000 €
Moyen (10–15 sous-sites, université)	8–12 semaines	150 000–300 000 €
Entreprise (20–40+ sous-sites, gouvernement)	12–16 semaines	300 000–600 000 €

Les sites Drupal 7 ajoutent ~20 % en raison du travail d'extraction MySQL. SSO SAML et les intégrations SIS/CRM ajoutent de la complexité à l'extrémité supérieure. L'hébergement continu sur Vercel + Supabase coûte généralement 200–500 $/mois — une fraction de ce que vous payez pour l'infrastructure d'hébergement Drupal répartie sur plusieurs sous-sites.

Le bilan

Drupal multisite résolvait un vrai problème à son époque. Mais la maintenance de 20 sous-sites sur une infrastructure PHP partagée, avec un vivier de talents en réduction et des préoccupations croissantes en matière de conformité, n'est pas un plan à long terme. Un monorepo Next.js avec Supabase RLS vous donne une véritable isolation des locataires, des chargements de pages infra-seconde, une expérience développeur que les gens apprécient réellement, et une architecture qui se met à l'échelle en éditant un fichier de configuration au lieu de faire tourner l'infrastructure.