Votre instance Drupal 7 multi-site exécute 23 emplacements de franchise sur une infrastructure partagée qui n'a pas reçu de correctif de sécurité depuis février 2025. Vous contemplez une migration D7-to-D10 qui représente en réalité 23 reconstructions séparées — les modules personnalisés de chaque emplacement, chaque remplacement de thème, chaque type de contenu reconstruit à la main. Les équipes Drupal 9 ont fait face à cette exacte douleur de reconstruction lors du passage de D7. Maintenant, D10-to-D11 apporte une autre vague de changements incompatibles, et votre réseau multiplie chaque défaut de compatibilité par le nombre de sites que vous gérez. Nous avons retiré des réseaux multi-site de Drupal et les avons placés sur Next.js + Supabase en moins de 90 jours. La différence architecturale explique pourquoi les équipes font ce passage permanent — et pourquoi revenir en arrière devient impensable une fois que vous voyez le déploiement à grande échelle.

Je veux être clair dès le départ : Drupal n'est pas un mauvais logiciel. Il a alimenté — et alimente toujours — certains des sites les plus importants d'Internet. Mais Drupal multi-site en 2026 est une proposition fondamentalement différente de celle de 2015. L'écosystème a changé, l'économie a changé, et le vivier de talents développeurs a migré vers JavaScript. Si vous êtes une équipe IT ou une agence gérant un réseau multi-site Drupal pour une université, un système hospitalier, une agence gouvernementale ou une entreprise multi-sites, cet article est pour vous.

Table des matières

Drupal Multi-Site Est Mort : Ce Que Les Entreprises Multi-Sites Utilisent a la Place

Pourquoi Drupal Multi-Site meurt

Drupal multi-site était une idée élégante en 2010. Un seul codebase, un seul serveur, plusieurs sites partageant des modules et des thèmes. Pour les universités avec 50 sites de département ou les systèmes hospitaliers avec 30 emplacements de cliniques, c'était le choix logique. Vous pouviez tout gérer à partir d'un seul panneau d'administration, pousser les mises à jour une seule fois et maintenir la cohérence dans tout le réseau.

Ce modèle s'est fissuré sous le poids de l'évolution propre de Drupal.

Le problème fondamental n'est pas un seul problème — c'est l'effet cumulatif de cinq pressions simultanées : coûts de mise à niveau, compatibilité des modules, rareté des talents, attentes en matière de performance et économie de l'hébergement. Chacune seule serait gérable. Ensemble, elles rendent Drupal multi-site intenable pour la plupart des organisations.

La Taxe de Mise à Niveau Qui Casse les Budgets

Drupal 7 a atteint la fin de vie en janvier 2025. Ce n'est pas une dépréciation progressive — cela signifie plus de correctifs de sécurité, plus de support communautaire, et une exposition aux vulnérabilités actives pour chaque site de votre réseau. Si vous exécutez toujours Drupal 7 multi-site, vous portez un risque réel.

Mais voici la partie qui brûle : une mise à niveau de Drupal 7 vers Drupal 10 ou 11 n'est pas une mise à niveau. C'est une reconstruction. Drupal 8 a réécrit l'architecture entière, passant d'un modèle PHP procédural à un PHP orienté objet basé sur Symfony. Vos thèmes D7 ? Disparus. Vos modules personnalisés ? Réécrivez-les. Vos fichiers de modèle ? Recommencez avec Twig.

Sur un seul site, c'est un projet douloureux mais gérable. Sur un réseau multi-site de 20 sites, c'est 20 reconstructions. Même si les sites partagent un thème de base, chaque emplacement a probablement des personnalisations — des types de contenu personnalisés, des configurations Views, des blocs, et des mises en page de types Paragraph qui nécessitent une attention individuelle.

Les chiffres racontent l'histoire :

  • Migration D7 à D10 pour un seul site : 30 000 $–80 000 $ selon la complexité
  • Migration D7 à D10 pour un réseau de 20 sites : 200 000 $–600 000 $+ (pas un multiplicateur simple en raison du code partagé, mais loin d'un coût de site unique)
  • Mise à niveau D10 vers D11 : Moins dramatique mais implique toujours des changements incompatibles autour des composants Symfony 7, des exigences PHP 8.3 et la suppression des API dépréciées

Et le cycle ne s'arrête pas. Drupal s'est engagé à publier des versions majeures annuelles, ce qui signifie des changements incompatibles annuels. Chaque version augmente la version PHP minimale, déprécie les API et oblige les auteurs de modules à mettre à jour leur code. Pour un réseau multi-site, cela crée un tapis roulant de mise à niveau perpétuel.

J'ai parlé à des directeurs IT qui décrivent leur budget de mise à niveau Drupal comme « le coût de rester immobile ». Ils dépensent six chiffres simplement pour maintenir la parité des fonctionnalités — pas pour ajouter quelque chose de nouveau.

Le Piège de la Compatibilité des Modules

La puissance de Drupal provient de son écosystème de modules contributés. Une installation multi-site typique pourrait utiliser 40-80 modules contributés — Views, Paragraphs, Webform, Pathauto, Metatag, Media, Layout Builder, et bien d'autres.

Voici le piège : dans une configuration multi-site, tous les sites partagent le même codebase. Cela signifie que chaque module doit être compatible avec chaque site simultanément. Quand un auteur de module abandonne le support de Drupal 9 (qui est déjà en fin de vie depuis novembre 2023) et ne supporte que D10/D11, vous ne pouvez pas mettre à niveau sélectivement les modules pour un seul site. Vous mettez à niveau le module pour tous les sites, ou aucun.

Cela crée une impasse de dépendances. Vous voulez mettre à niveau le Module A car il a un correctif de sécurité critique, mais la nouvelle version du Module A nécessite Drupal 10.3+, et votre codebase est sur 10.1 car le Module B n'a pas encore publié une version compatible avec 10.3. Multipliez cela par 60 modules et 20 sites, et vous dépensez des sprints entiers sur les tests de compatibilité.

L'écosystème des modules contributés rétrécit également. Selon les statistiques de Drupal.org, le nombre de modules activement maintenus est en déclin depuis 2020. De nombreux mainteneurs de modules se sont orientés vers d'autres plates-formes ou ont simplement arrêté de mettre à jour leurs modules. La communauté Drupal est plus petite qu'elle ne l'était il y a cinq ans, et cette tendance s'accélère.

Drupal Multi-Site Est Mort : Ce Que Les Entreprises Multi-Sites Utilisent a la Place - architecture

La Pénurie de Talents Drupal Est Réelle

C'est celle que les propriétaires d'agences et les directeurs IT ressentent le plus intensément. Trouver des développeurs Drupal en 2026 est genuinement difficile.

Drupal nécessite un ensemble de compétences spécifique : PHP (avancé), Symfony, modèles Twig, le système d'entités/champs de Drupal, l'API plugin, la gestion de configuration (basée sur YAML), et le pipeline de rendu. Ce n'est pas que ces compétences soient mauvaises — elles sont juste de plus en plus rares. Les développeurs sortant des bootcamps et des programmes CS apprennent React, Next.js, et TypeScript. Ils n'apprennent pas Drupal.

Les taux du marché reflètent cela :

Rôle Développeur Drupal Développeur Next.js
Junior 80–120 $/h 60–90 $/h
Niveau intermédiaire 120–170 $/h 80–130 $/h
Senior 170–220 $/h 120–170 $/h
Vivier de talents disponibles En déclin En croissance rapide
Temps moyen de recrutement 6-12 semaines 2-4 semaines

Vous payez plus cher pour des développeurs qui sont plus difficiles à trouver, travaillant dans un écosystème avec moins de ressources communautaires. Ce n'est pas une position durable pour aucune organisation.

Nous avons construit notre pratique de développement Next.js spécifiquement parce que c'est là que les talents et la demande ont convergé.

Performance : Rendu PHP vs Livraison En Périphérie

Drupal sert les pages via le rendu PHP. Chaque requête frappe le serveur, amorce Drupal, interroge la base de données, traverse le pipeline de rendu et retourne du HTML. Même avec des couches de cache (Varnish, Redis, le cache de page interne de Drupal), l'architecture a un plafond de performance.

Scores Lighthouse typiques sur les installations multi-site Drupal en production :

  • Performance : 55–70
  • LCP (Largest Contentful Paint) : 2,5–4,5 secondes
  • CLS (Cumulative Layout Shift) : 0,1–0,3
  • TTFB (Time to First Byte) : 800 ms–2,5 s (selon l'hébergement)

Next.js sur Vercel avec ISR (Incremental Static Regeneration) ou SSG (Static Site Generation) :

  • Performance : 90–100
  • LCP : 0,8–1,5 secondes
  • CLS : 0–0,05
  • TTFB : 50–200 ms (en cache périphérique)

Ce n'est pas une différence marginale. C'est un écart générationnel. Les Core Web Vitals de Google sont un facteur de classement, et l'écart de performance entre Drupal et une structure de frontale moderne sur une infrastructure périphérique est mesurable dans les classements de recherche.

Pour les entreprises multi-sites, cela importe encore plus. Chaque page d'emplacement est une page d'atterrissage de SEO local. Si votre page de clinique de Dallas se charge en 4 secondes tandis que celle de votre concurrent se charge en 1,2 secondes, Google le remarque.

Comparaison des Coûts : Hébergement Drupal vs Stack Moderne

Drupal multi-site nécessite un hébergement Drupal géré. Vous avez besoin de PHP, MySQL/MariaDB, cache au niveau du serveur, et idéalement une plateforme qui comprenne la structure de fichiers et la configuration multisite de Drupal. Les principales options :

  • Acquia Cloud : 800 $–3 000 $/mois pour multi-site
  • Pantheon : 300 $–1 500 $/mois selon le plan et le nombre de sites
  • Platform.sh : 500 $–2 000 $/mois
  • Auto-géré sur AWS/GCP : 200 $–800 $/mois pour l'infrastructure, plus 2 000 $–5 000 $/mois pour un administrateur système pour le gérer

Notre stack moderne recommandé pour les sites multi-sites :

  • Vercel Pro : 20 $/mois
  • Supabase Pro : 25 $/mois
  • Total : 45 $/mois

C'est 540 $/an vs 3 600 $–36 000 $/an. Même si vous ajoutez un CDN pour les médias (20 $/mois) et un outil de surveillance (30 $/mois), vous êtes à 1 140 $/an. Les économies d'hébergement seul paient souvent la migration au cours de la première année.

Pour être juste : la tarification de Vercel et Supabase s'ajuste selon l'utilisation. Un site multi-site à fort trafic pourrait voir des factures Vercel de 100 $–300 $/mois et Supabase de 50 $–100 $/mois. Même au haut de la fourchette, vous êtes à 4 800 $/an — toujours une fraction de l'hébergement Drupal géré.

Face à Face : Drupal Multi-Site vs Next.js + Supabase

Facteur Drupal Multi-Site Next.js + Supabase
Coût de mise à niveau (par version majeure) 200 K $–600 K $ pour 20 sites 0 $–5 K $ (mises à jour de dépendances mineures)
Coût d'hébergement annuel 3 600 $–36 000 $ 540 $–4 800 $
Taux horaire des développeurs 120 $–220 $/h 80 $–170 $/h
Temps pour ajouter un nouvel emplacement 2–4 semaines 1–3 jours
Posture de sécurité Nécessite une correction constante, codebase partagé = risque partagé Pages générées statiquement, pas de serveur à exploiter
Score de performance Lighthouse 55–70 90–100
Support i18n Module Drupal i18n (configuration complexe) next-intl + colonnes locale (simple)
Édition de contenu Interface d'administration Drupal Tableau de bord Supabase, admin personnalisé, ou CMS headless
Déploiement Déploiement SSH/Git sur un seul serveur Poussée Git → Déploiement automatique Vercel avec URLs d'aperçu

Le Chemin de Migration : Drupal vers Next.js + Supabase

Voici le processus réel que nous suivons lors de la migration des réseaux multi-site Drupal. Ce n'est pas un projet de fin de semaine, mais c'est bien défini et prévisible.

Étape 1 : Exportation de Contenu à partir de Drupal

L'approche dépend de votre version de Drupal.

Drupal 10/11 : Utilisez le module JSON:API (inclus dans le noyau) pour exporter le contenu programmatiquement :

# Exporter tous les nœuds de type 'location'
curl https://your-drupal-site.com/jsonapi/node/location?page[limit]=50 \
  -H "Authorization: Basic BASE64_CREDENTIALS" \
  > locations.json

Drupal 7 : Il n'y a pas d'API REST intégrée. Vous devrez interroger directement la base de données. Drupal 7 stocke le contenu sur plusieurs tableaux — node, field_data_*, field_revision_*, et des tableaux de taxonomie.

-- Exporter les nœuds location D7 avec les données de champ
SELECT 
  n.nid,
  n.title,
  n.created,
  n.changed,
  fdb.body_value AS body,
  fda.field_address_value AS address,
  fdp.field_phone_value AS phone,
  fdl.field_latitude_value AS latitude,
  fdl.field_longitude_value AS longitude
FROM node n
LEFT JOIN field_data_body fdb ON n.nid = fdb.entity_id
LEFT JOIN field_data_field_address fda ON n.nid = fda.entity_id
LEFT JOIN field_data_field_phone fdp ON n.nid = fdp.entity_id
LEFT JOIN field_data_field_location fdl ON n.nid = fdl.entity_id
WHERE n.type = 'location'
AND n.status = 1;

C'est un peu bringuebalant — le stockage de champ EAV (Entity-Attribute-Value) de Drupal 7 signifie que vous joignez une table séparée pour chaque champ. Mais ça marche.

Étape 2 : Transformer les Données Drupal en Schéma Supabase

Le modèle de données de Drupal ne correspond pas 1:1 à un schéma relationnel propre. Voici comment nous gérons les conversions clés :

Types de Paragraphes → Champs JSONB

Drupal Paragraphs stocke des mises en page de contenu flexibles comme des entités référencées. Dans Supabase, nous utilisons des colonnes JSONB :

CREATE TABLE locations (
  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  slug TEXT UNIQUE NOT NULL,
  site_id TEXT NOT NULL, -- identifie quel emplacement/site
  title TEXT NOT NULL,
  body TEXT,
  address JSONB, -- {street, city, state, zip, country}
  phone TEXT,
  coordinates GEOGRAPHY(POINT, 4326),
  page_sections JSONB, -- remplace les types de Paragraph
  meta JSONB, -- métadonnées SEO
  locale TEXT DEFAULT 'en',
  published BOOLEAN DEFAULT false,
  created_at TIMESTAMPTZ DEFAULT now(),
  updated_at TIMESTAMPTZ DEFAULT now()
);

Le champ JSONB page_sections stocke ce que les Paragraphes Drupal avaient l'habitude de gérer :

[
  {
    "type": "hero",
    "heading": "Bienvenue dans Notre Emplacement de Dallas",
    "image": "/images/dallas-hero.webp",
    "cta": {"text": "Réserver une Rendez-vous", "url": "/dallas/book"}
  },
  {
    "type": "text_block",
    "body": "<p>Notre clinique de Dallas a servi la communauté depuis 2008...</p>"
  },
  {
    "type": "staff_grid",
    "staff_ids": ["uuid-1", "uuid-2", "uuid-3"]
  }
]

Drupal Views → Requêtes Supabase + Composants Serveur

Drupal Views est essentiellement un constructeur de requêtes visuelles. Dans la nouvelle stack, celles-ci deviennent des requêtes Supabase appelées à partir des Composants Serveur Next.js :

// app/[location]/page.tsx -- remplace une Drupal View
import { createClient } from '@/lib/supabase/server'

export default async function LocationPage({ 
  params 
}: { 
  params: { location: string } 
}) {
  const supabase = await createClient()
  
  const { data: location } = await supabase
    .from('locations')
    .select('*')
    .eq('slug', params.location)
    .eq('published', true)
    .single()

  if (!location) notFound()

  const { data: nearbyLocations } = await supabase
    .rpc('nearby_locations', {
      lat: location.coordinates.coordinates[1],
      lng: location.coordinates.coordinates[0],
      limit_count: 3
    })

  return (
    <main>
      <LocationHero location={location} />
      <SectionRenderer sections={location.page_sections} />
      <NearbyLocations locations={nearbyLocations} />
    </main>
  )
}

Utilisateurs Drupal → Authentification Supabase

Si vos sites Drupal ont l'authentification des utilisateurs (portails patients, connexions étudiantes, etc.), Supabase Auth gère cela avec un support intégré pour email/mot de passe, liens magiques, fournisseurs OAuth et la Sécurité au Niveau des Lignes :

-- Sécurité au Niveau des Lignes : les utilisateurs ne voient que leurs propres données
ALTER TABLE patient_records ENABLE ROW LEVEL SECURITY;

CREATE POLICY "Les utilisateurs voient leurs propres dossiers" ON patient_records
  FOR SELECT USING (auth.uid() = user_id);

Drupal i18n → next-intl + Colonnes Locale

Le système multilingue de Drupal est puissant mais complexe — traduction de contenu, traduction d'interface, traduction de configuration, et détection de langue s'exécutent tous à travers des sous-systèmes séparés. Avec next-intl et Supabase, c'est plus simple :

// Requête de contenu localisé
const { data } = await supabase
  .from('locations')
  .select('*')
  .eq('slug', params.location)
  .eq('locale', params.locale)
  .single()

Taxonomie → Tags/Catégories dans Supabase

Les vocabulaires de taxonomie Drupal deviennent de simples tableaux de consultation avec un tableau de jonction pour les relations plusieurs-à-plusieurs :

CREATE TABLE categories (
  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  vocabulary TEXT NOT NULL, -- 'service_type', 'specialty', etc.
  name TEXT NOT NULL,
  slug TEXT NOT NULL
);

CREATE TABLE location_categories (
  location_id UUID REFERENCES locations(id),
  category_id UUID REFERENCES categories(id),
  PRIMARY KEY (location_id, category_id)
);

Étape 3 : Reconstruire les Modèles dans Next.js + Tailwind

C'est là que se déroule le vrai travail frontend. Nous créons une bibliothèque de composants qui rend les sections de page JSONB de manière dynamique. Chaque modèle Drupal devient un composant React. Nous utilisons Tailwind CSS pour le style, ce qui signifie que vos concepteurs peuvent travailler avec les classes utilitaires au lieu de lutter contre la couche de thème de Drupal.

Étape 4 : Redirection 301 Chaque URL

C'est critique. Les URL Drupal suivent des motifs comme /node/123, /location/dallas-tx, ou tout ce que Pathauto a généré. Chaque URL doit être redirigée en 301 vers son équivalent Next.js. Nous les générons à partir de la base de données Drupal :

// next.config.js
module.exports = {
  async redirects() {
    return [
      // Généré à partir du tableau url_alias Drupal
      { source: '/node/1234', destination: '/locations/dallas', permanent: true },
      { source: '/locations/dallas-tx-clinic', destination: '/locations/dallas', permanent: true },
      // ... des centaines de plus
    ]
  }
}

Étape 5 : Déployer et Décommissionner

Déployez sur Vercel, vérifiez toutes les redirections, confirmez que les métriques SEO sont stables (attendez-vous à 2-4 semaines de fluctuation), puis décommissionnez les serveurs Drupal. Conservez une sauvegarde de base de données — vous ne l'utiliserez jamais, mais vous dormirez mieux.

Industries Quittant Drupal (Et Ce Vers Quoi Elles Migrent)

Universités

L'enseignement supérieur était le bastion de Drupal. Les universités adoraient multi-site car chaque département, collège et programme pouvait avoir son propre site sous un parapluie. Mais les coûts de mise à niveau sont brutaux pour les institutions avec 50-200 sous-sites. Nous voyons des universités passer à Next.js avec des options CMS headless comme Sanity ou Contentful pour l'édition de contenu, ou à notre stack préféré de Next.js + Supabase pour les institutions qui veulent le contrôle complet de leurs données. Notre travail en développement CMS headless couvre exactement ces migrations.

Systèmes Hospitaliers

Les organisations de santé ont besoin de conformité HIPAA, et Drupal sur un hébergement partagé est un casse-tête de conformité. Les stacks modernes avec Supabase (qui offre la conformité SOC 2 Type II et peuvent être auto-hébergés pour les exigences HIPAA) offrent une meilleure posture de sécurité avec moins de frais généraux opérationnels. Chaque page d'emplacement de clinique devient une page générée statiquement sans surface d'attaque du côté serveur.

Agences Gouvernementales

Les sites gouvernementaux ont été des adoptants précoces de Drupal — WhiteHouse.gov fonctionnait autrefois sur Drupal. Mais les exigences de conformité FedRAMP et le processus ATO (Authority to Operate) pour l'hébergement Drupal basé sur serveur sont chers. Les générateurs de sites statiques et les architectures JAMstack réduisent drastiquement la surface de conformité. Plusieurs agences ont migré vers Next.js avec export statique ou vers développement Astro pour les sites informationnels riches en contenu.

Organisations Médias

Les éditeurs ont besoin de vitesse — à la fois dans le chargement de page et dans le flux de travail éditorial. L'expérience éditoriale de Drupal, bien qu'améliorée avec Layout Builder, ne peut pas égaler les expériences d'édition modernes disponibles avec les plateformes CMS headless. Et la différence de performance entre le rendu Drupal et les pages livrées en périphérie depuis un générateur de site statique est la différence entre les lecteurs qui restent et ceux qui rebondissent.

À Quoi Ressemble L'Architecture Après Migration

L'état final pour une entreprise multi-sites ressemble à ceci :

┌─────────────────────────────────────────────┐
│                  Vercel                       │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐    │
│  │ /dallas  │ │ /austin  │ │ /houston │    │
│  │ (SSG)    │ │ (SSG)    │ │ (SSG)    │    │
│  └────┬─────┘ └────┬─────┘ └────┬─────┘    │
│       └─────────────┼─────────────┘          │
│                     │                        │
│            Next.js App Router                │
│            (composants partagés)             │
└─────────────────────┬───────────────────────┘
                      │
              ┌───────┴───────┐
              │   Supabase    │
              │  ┌──────────┐ │
              │  │locations │ │
              │  │staff     │ │
              │  │services  │ │
              │  │reviews   │ │
              │  │media     │ │
              │  └──────────┘ │
              │  + Auth       │
              │  + Storage    │
              │  + Edge Funcs │
              └───────────────┘

Ajouter un nouvel emplacement ? Insérez une ligne dans le tableau locations, ajoutez le contenu des sections de page, et le site se reconfigure via ISR. Pas d'approvisionnement de nouveau site Drupal, pas de configuration DNS, pas de configuration de vhost Apache. Juste des données.

Si cette architecture vous intéresse, nous avons documenté notre approche et nos tarifs pour ces types de migrations à notre page de tarification. Pour une conversation sur votre réseau Drupal spécifique, contactez-nous.

FAQ

Drupal 7 est-il toujours sûr à utiliser en 2026 ?

Non. Drupal 7 a atteint la fin de vie en janvier 2025. Il ne reçoit plus de correctifs de sécurité de l'équipe de sécurité Drupal. Il existe des fournisseurs de support étendu tiers, mais ils sont chers (500 $–2 000 $/mois) et couvrent uniquement le noyau — pas les modules contributés. Si vous êtes toujours sur D7, vous devriez traiter la migration comme urgente, pas optionnelle.

Combien de temps prend une migration de Drupal vers Next.js ?

Pour un seul site, attendez-vous à 4–8 semaines. Pour un réseau multi-site avec 10–20 sites, prévoyez 3–6 mois avec une approche progressive — migrez les sites par lots, en commençant par les emplacements avec le trafic le plus élevé. La bibliothèque de composants partagés signifie que chaque site suivant migre plus vite que le précédent.

Vais-je perdre les classements SEO lors de la migration depuis Drupal ?

Vous verrez une fluctuation temporaire — généralement 2–4 semaines — alors que Google recrawl et réindexe vos pages. Les redirections 301 appropriées sont non négociables. Nous avons vu la plupart des sites récupérer à leurs classements d'avant migration en 30 jours, et beaucoup les dépasser en 60 jours en raison des scores Core Web Vitals améliorés.

Qu'en est-il de l'expérience d'édition de contenu Drupal ? Les éditeurs non techniques ont besoin d'un CMS.

C'est une préoccupation valide. Le tableau de bord de Supabase fonctionne pour les équipes techniques, mais les éditeurs non techniques ont généralement besoin d'une interface plus conviviale. Les options incluent : construire un panneau d'administration personnalisé avec Next.js (2–3 semaines de travail supplémentaire), utiliser un CMS headless comme Sanity ou Contentful comme couche d'édition avec Supabase comme magasin de données, ou utiliser les API auto-générées de Supabase avec un outil comme Retool ou Appsmith pour des interfaces d'administration rapides.

Supabase peut-il gérer la conformité HIPAA pour les organisations de santé ?

Supabase Cloud est conforme à SOC 2 Type II. Pour HIPAA, vous aurez besoin soit d'un accord d'associé commercial (BAA) avec Supabase — contactez leur équipe commerciale — soit d'auto-héberger Supabase sur votre propre infrastructure conforme à HIPAA (AWS GovCloud, Azure Government, etc.). L'auto-hébergement de Supabase ajoute de la complexité opérationnelle mais vous donne le contrôle complet sur la résidence des données et la conformité.

Quelle est la différence réelle de coût entre Drupal multi-site et Next.js + Supabase ?

Pour un réseau de 20 sites sur Acquia ou Pantheon, vous dépensez généralement 12 000 $–36 000 $/an rien que pour l'hébergement. Next.js sur Vercel + Supabase pour le même réseau s'exécute à 540 $–4 800 $/an. Compte tenu du cycle de mise à niveau de Drupal (200 K $–600 K $ tous les 2–3 ans) par rapport aux coûts de mise à niveau quasi nuls avec Next.js, la différence de TCO sur cinq ans est souvent 500 K $+.

Puis-je migrer progressivement, ou doit-ce être d'un seul coup ?

La migration progressive fonctionne bien. Utilisez les réécritures de Vercel pour faire passer par proxy les routes spécifiques vers votre ancien site Drupal tout en servant les pages migrées depuis Next.js. Migrez un emplacement à la fois. Cette approche est moins risquée et vous permet de valider la nouvelle stack avant de vous engager pleinement. Nous avons fait cela avec des réseaux de 30+ sites où une migration big-bang n'était pas réalisable.

Que se passe-t-il pour la fonctionnalité du module Drupal contributif ?

Chaque module correspond à quelque chose dans la nouvelle stack. Webform devient React Hook Form + insertions Supabase. Pathauto devient routes dynamiques Next.js. Metatag devient API de Métadonnées Next.js. Views devient requêtes Supabase. Search API devient recherche en texte intégral Supabase ou un service comme Meilisearch. La fonctionnalité ne disparaît pas — elle se déplace simplement vers une implémentation plus maintenable. Nous avons écrit des cartes de migration pour les 50 modules Drupal les plus courants dans le cadre de notre pratique de migration CMS headless. ```