Votre moteur de recherche de programmes expire après 8,2 secondes. Encore une fois. C'est la semaine d'inscription et le portail étudiant est au bord de l'effondrement — 40 000 étudiants actualisent la même recherche défaillante, votre queue de support déborde de tickets, votre VP des admissions voit les taux de conversion chuter en temps réel. Les correctifs de sécurité Drupal 7 se terminent dans six mois. Vous avez 200+ pages de programme, un CMS hérité que votre équipe comprend à peine, et une exigence non négociable : zéro interruption. Au début de 2024, une grande université d'État nous a confié exactement ce problème. Ils avaient besoin d'une migration complète vers Next.js avant que Drupal 7 ne disparaisse — et ils avaient besoin que leur moteur de recherche de programmes cesse de perdre des étudiants. Voici comment nous avons reconstruit l'intégralité de leur portail en 26 semaines, réduit le temps de réponse du moteur de recherche à 340 ms, et déployé sans prendre le site hors ligne ne serait-ce qu'une minute.

Voici l'histoire de la façon dont nous avons migré l'ensemble vers Next.js avec un backend CMS headless, réduit les temps de chargement des pages de 73%, et livré à temps. Je vais partager les décisions architecturales que nous avons prises (et celles que nous aurions presque mal faites), le processus de migration réel, les benchmarks de performance, et les leçons qui s'appliquent à toute migration CMS de grande envergure.

Table des matières

Étude de cas : Migration d'un portail universitaire de Drupal vers Next.js

Le point de départ : avec quoi nous travaillions

Laissez-moi dresser le tableau. La présence numérique de l'université était construite sur Drupal 7, lancée à l'origine autour de 2014. Au cours de la dernière décennie, elle avait accumulé :

  • ~12 000 nœuds de contenu à travers les programmes, cours, profils de professeurs, articles d'actualités et événements
  • 200+ pages de programmes académiques chacune avec des relations de taxonomie complexes (niveau de diplôme, département, collège, format de livraison, statut d'accréditation)
  • Un moteur de recherche de programmes personnalisé construit comme une recherche Drupal Views avec des filtres exposés — fonctionnel mais lent
  • Un portail étudiant avec accès authentifié aux outils de conseil, audits de diplômes, liens d'inscription et tableaux de bord personnalisés
  • 47 modules Drupal personnalisés, dont 19 ne sont plus maintenus
  • 3 couches de thème différentes empilées les unes sur les autres à partir de redesigns successifs

Le site était hébergé sur deux machines virtuelles vieillissantes derrière un équilibreur de charge institutionnel. Pendant les pics d'inscription (août et janvier), le moteur de recherche de programmes expirait régulièrement. L'équipe marketing avait résolu le problème en publiant une liste PDF des programmes en sauvegarde. Cela vous dit tout.

Les Core Web Vitals étaient mauvais :

Métrique Drupal 7 (avant) Cible
LCP 6,2 s < 2,5 s
FID 380 ms < 100 ms
CLS 0,31 < 0,1
TTFB 2,8 s < 0,8 s
Chargement du moteur de recherche de programmes 8,4 s < 1,5 s

Le paysage des parties prenantes

Les projets web universitaires sont uniquement difficiles en raison du nombre de parties prenantes. Nous travaillions avec :

  • IT centrale — responsable de l'intégration SSO, de la conformité en matière de sécurité et de l'hébergement
  • Marketing et communications — propriétaires de la marque, de la stratégie de contenu et de l'analytique
  • Le bureau du registraire — propriétaires des données de programme et du système d'information étudiant (SIS)
  • Collèges et départements individuels — chacun ayant ses propres éditeurs de contenu (plus de 80 personnes ayant accès au CMS)
  • Gouvernement étudiant — qui a plaidé avec force pour une conception mobile-first (à juste titre)

Obtenir l'alignement de tous ces groupes a pris les trois premières semaines du projet. Nous avons organisé un design sprint pour établir les priorités partagées et les exigences non négociables.

Pourquoi Next.js (et pourquoi pas Drupal 10)

La question évidente : pourquoi ne pas simplement passer à Drupal 10 ? L'équipe IT de l'université avait en fait commencé sur cette voie six mois avant de nous contacter. Ils l'ont abandonné après avoir découvert que 23 de leurs 47 modules personnalisés n'avaient aucun équivalent Drupal 10 et devraient être complètement réécrits.

Le calcul réel ressemblait à ceci :

Facteur Migration Drupal 10 Reconstruction Next.js
Calendrier estimé 8-10 mois 6 mois
Réécriture de modules personnalisés 23 modules N/A (reconstruits en tant qu'API/composants)
Reformation des éditeurs de contenu Modérée (nouvelle interface admin) Modérée (nouveau CMS)
Plafond de performance Amélioration modérée Amélioration dramatique
Flexibilité d'hébergement LAMP traditionnel/similaire Déploiement edge, CDN-first
Pool d'embauche de développeurs En baisse (spécialistes Drupal) En augmentation (React/Next.js)
Coût de maintenance à long terme ~180 K$/an ~95 K$/an

La différence de coût de maintenance a été l'élément déterminant pour l'administration. Les développeurs Drupal ayant une expérience institutionnelle devenaient plus difficiles à trouver et plus coûteux à retenir. L'équipe IT de l'université elle-même avait trois développeurs React et zéro spécialistes Drupal après la retraite de son développeur Drupal senior.

Nous avons choisi Next.js spécifiquement (plutôt que Gatsby, Remix ou Astro) pour plusieurs raisons :

  1. Rendu hybride — les pages de programme pourraient être générées de manière statique, tandis que le portail étudiant avait besoin du rendu côté serveur avec authentification
  2. Routes API — nous pourrions construire des middlewares pour l'intégration SIS sans un service backend séparé
  3. Régénération statique incrémentale (ISR) — les données du programme changent hebdomadairement, pas toutes les heures. ISR avec une fenêtre de revalidation d'une heure était parfait
  4. L'équipe de l'université connaissait React — ils maintendraient cela après la remise

Si vous pesez des options similaires, notre page sur nos capacités de développement Next.js couvre les spécificités techniques de ce que nous construisons généralement.

Décisions architecturales

Sélection du CMS headless

Nous avons évalué cinq options de CMS headless par rapport aux exigences de l'université : 80+ éditeurs de contenu, relations de contenu complexes, permissions basées sur les rôles, et un modèle de tarification raisonnable par siège.

Nous avons choisi Sanity pour ce projet. Les facteurs clés :

  • Les requêtes GROQ ont géré les relations de taxonomie complexes entre programmes, départements et collèges bien mieux que GraphQL pour ce cas d'usage
  • Collaboration en temps réel — plusieurs éditeurs pouvaient travailler simultanément sans conflits
  • Composants d'entrée personnalisés — nous avons construit un mappeur de prérequis de programme directement dans le studio
  • Tarification — le plan Enterprise à ~949$/mois était bien dans le budget, et le coût par utilisateur était prévisible

La modélisation du contenu a pris environ deux semaines. Nous avons défini 14 types de documents et 8 types de référence. Le schéma du programme seul avait 34 champs, y compris des données structurées pour le balisage schema.org EducationalOrganization et Course.

Pour plus d'informations sur notre approche de l'architecture CMS, consultez notre page sur le développement CMS headless.

Infrastructure

Nous avons déployé sur Vercel pour le frontend Next.js (le plan Enterprise, requis pour la conformité FERPA et les exigences SSO). Les routes authentifiées du portail étudiant utilisent le rendu côté serveur avec gestion de session via le CAS (Central Authentication Service) SSO existant de l'université.

Le flux de données ressemble à ceci :

[Sanity CMS] → [Next.js sur Vercel] → [CDN Edge]
                    ↕
           [API SIS universitaire]
                    ↕
           [CAS SSO / LDAP]

Les pages de programme statiques sont pré-rendues au moment de la construction et revalidées toutes les heures via ISR. Le moteur de recherche de programmes utilise une combinaison de données pré-récupérées (chargées dans le client au moment de la construction en tant qu'index JSON) et filtrage en temps réel — aucun appel serveur nécessaire pour les opérations de recherche.

La couche API

Le système d'information étudiant (Ellucian Banner, si vous êtes curieux — c'est toujours Banner) exposait une API SOAP. Oui, en 2024. Nous avons construit une couche de traduction en utilisant les routes API Next.js qui consommaient les points de terminaison SOAP et exposaient des points de terminaison REST propres au frontend :

// /app/api/programs/[programId]/route.ts
import { NextRequest, NextResponse } from 'next/server';
import { fetchFromBanner } from '@/lib/banner-client';
import { transformProgramData } from '@/lib/transforms';

export async function GET(
  request: NextRequest,
  { params }: { params: { programId: string } }
) {
  const bannerData = await fetchFromBanner(
    'PROGRAM_DETAIL',
    { programCode: params.programId }
  );
  
  const program = transformProgramData(bannerData);
  
  return NextResponse.json(program, {
    headers: {
      'Cache-Control': 'public, s-maxage=3600, stale-while-revalidate=86400',
    },
  });
}

Cette couche de traduction était l'une des pièces les plus précieuses du projet. Elle a découplé le frontend des spécificités de Banner et a donné à l'université une API propre qu'elle pourrait utiliser pour des projets futurs (une application mobile était déjà en discussion).

Étude de cas : Migration d'un portail universitaire de Drupal vers Next.js - architecture

Le moteur de recherche de programmes : reconstruire la fonctionnalité clé

Le moteur de recherche de programmes était la page la plus importante de tout le site. L'analytique a montré qu'il représentait 34% de tout le trafic de recherche organique et était le #1 point d'entrée pour les étudiants potentiels. Faire une erreur ici n'était pas une option.

L'ancienne approche (et pourquoi elle était lente)

La version Drupal utilisait Views avec des filtres exposés. Chaque changement de filtre déclenchait un appel serveur complet, réinterrogeait la base de données et re-rendait la page entière. Avec 200+ programmes et 6 dimensions de taxonomie (niveau de diplôme, collège, département, format de livraison, domaine d'intérêt et recherche par mot-clé), la requête était coûteuse.

La nouvelle approche

Nous avons pré-construit un index de recherche au moment de la construction. Les 200+ programmes ont été sérialisés dans un fichier JSON d'environ 180 Ko (compressé à ~22 Ko) qui est livré avec la page. Le filtrage se fait entièrement côté client en utilisant un crochet personnalisé :

// hooks/useProgramSearch.ts
import { useMemo, useState } from 'react';
import Fuse from 'fuse.js';
import { Program, ProgramFilters } from '@/types';

const fuseOptions = {
  keys: [
    { name: 'title', weight: 0.4 },
    { name: 'description', weight: 0.2 },
    { name: 'keywords', weight: 0.3 },
    { name: 'department', weight: 0.1 },
  ],
  threshold: 0.3,
};

export function useProgramSearch(programs: Program[]) {
  const [filters, setFilters] = useState<ProgramFilters>({});
  const fuse = useMemo(() => new Fuse(programs, fuseOptions), [programs]);

  const results = useMemo(() => {
    let filtered = programs;

    if (filters.degreeLevel) {
      filtered = filtered.filter(p => p.degreeLevel === filters.degreeLevel);
    }
    if (filters.college) {
      filtered = filtered.filter(p => p.college === filters.college);
    }
    if (filters.deliveryFormat) {
      filtered = filtered.filter(p => 
        p.deliveryFormats.includes(filters.deliveryFormat!)
      );
    }
    if (filters.searchQuery) {
      const fuseResults = fuse.search(filters.searchQuery);
      const fuseIds = new Set(fuseResults.map(r => r.item.id));
      filtered = filtered.filter(p => fuseIds.has(p.id));
    }

    return filtered;
  }, [programs, filters, fuse]);

  return { results, filters, setFilters };
}

Nous avons utilisé Fuse.js pour la recherche textuelle floue et le filtrage JavaScript simple pour les facettes. Le résultat : les résultats de recherche apparaissent en moins de 50 ms. Pas de spinners de chargement. Pas d'appels serveur. Les utilisateurs peuvent appuyer sur les filtres aussi vite qu'ils le souhaitent.

Chaque résultat de programme renvoie à une page de détail générée statiquement avec un balisage schema.org complet, ce qui a considérablement amélioré l'apparence de l'université dans les fonctionnalités de recherche liées à l'éducation de Google.

Migration du portail étudiant

Le portail étudiant était la partie la plus délicate. Il nécessitait une authentification, une personnalisation et des données en temps réel de Banner. Nous ne pouvions pas le générer statiquement.

Flux d'authentification

L'université utilise CAS pour la connexion unique sur tous les systèmes institutionnels. Nous avons intégré CAS avec Next.js en utilisant un flux d'authentification personnalisé :

  1. L'utilisateur non authentifié accède à /portal → redirection vers la connexion CAS
  2. CAS redirige avec un ticket de service
  3. Notre route API valide le ticket par rapport au serveur CAS
  4. Nous créons un JWT signé stocké dans un cookie httpOnly
  5. Les demandes ultérieures utilisent le JWT pour la gestion de session

Nous avons utilisé next-auth (maintenant Auth.js) avec un fournisseur CAS personnalisé que nous avons écrit à partir de zéro, car aucun fournisseur CAS maintenu n'existait à l'époque.

Fonctionnalités du portail

Le portail étudiant comprenait :

  • Tableau de bord personnalisé avec les dates d'inscription à venir, les obstacles et les informations du conseiller
  • Résumé d'audit des diplômes tiré de Banner en temps réel
  • Liens rapides vers le LMS (Canvas), la messagerie et les systèmes de bibliothèque
  • Ressources spécifiques au programme basées sur la majeure déclarée de l'étudiant

Toutes les pages du portail utilisent le rendu côté serveur. Nous mettons en cache agressivement les réponses de l'API Banner (TTL de 30 secondes pour la plupart des points de terminaison, TTL de 5 minutes pour les audits de diplômes) pour éviter de surcharger leur système.

Stratégie de migration du contenu

La migration de 12 000 nœuds de contenu de Drupal vers Sanity a nécessité une approche systématique. Nous avons construit un pipeline de migration personnalisé :

# Pipeline de migration simplifié
1. Exporter les nœuds Drupal → JSON via des commandes Drush personnalisées
2. Transformer JSON → format de document Sanity via des scripts Node.js
3. Traiter les fichiers médias → télécharger vers Sanity CDN
4. Importer les documents → API de migration Sanity
5. Valider → vérifications automatisées pour les références cassées

La migration médias était la partie la plus fastidieuse. La gestion des fichiers de Drupal stocke les fichiers avec des chemins internes et des références de base de données. Nous avons écrit un script qui :

  1. Téléchargeait chaque fichier du répertoire de fichiers Drupal
  2. Le téléchargeait vers le pipeline d'actifs Sanity
  3. Mappait les anciens ID de fichiers Drupal aux nouvelles références d'actifs Sanity
  4. Mettait à jour tout le contenu rich text pour pointer vers les nouvelles références d'actifs

Ce script a fonctionné pendant environ 14 heures sur l'ensemble des données. Nous l'avons exécuté trois fois au cours du projet : une fois pour les tests initiaux, une fois au point médian pour rafraîchir la mise en scène, et une fois pour la coupure finale.

Stratégie de gel du contenu

Nous avons mis en œuvre un gel de contenu en deux phases :

  • Semaines 1-20 : Les éditeurs de contenu travaillent dans Drupal comme d'habitude. Nous migrons des snapshots vers la mise en scène hebdomadairement.
  • Semaines 21-23 : Entrée double. Le nouveau contenu entre dans Drupal et Sanity. Les éditeurs ont été formés au nouveau CMS.
  • Semaine 24 : Coupure complète. Drupal devient lecture seule, puis hors ligne.

La période d'entrée double était douloureuse mais nécessaire. Nous avions 80+ éditeurs, et ils devaient développer la mémoire musculaire avec Sanity avant que ce soit leur seule option.

Calendrier de 6 mois

Mois Phase Livrables clés
Mois 1 Découverte et architecture Alignement des parties prenantes, sélection du CMS, configuration de l'infrastructure, modélisation du contenu
Mois 2 Développement principal Système de conception, modèles de pages, pages de détail des programmes, navigation
Mois 3 Moteur de recherche et recherche de programmes Index de recherche, interface de filtrage, pipeline de données de programmes, balisage SEO
Mois 4 Portail étudiant Intégration CAS, couche API Banner, tableau de bord, affichage d'audit des diplômes
Mois 5 Migration du contenu et formation Scripts de migration, formation des éditeurs (6 sessions), QA de mise en scène
Mois 6 QA, performance, lancement Test de charge, audit d'accessibilité, gel du contenu, coupure DNS

Notre équipe comprenait 4 développeurs, 1 designer et 1 chef de projet. L'université a fourni un propriétaire de produit dédié plus un représentant informatique pour le travail d'intégration Banner/CAS.

Nous avons rencontré deux problèmes majeurs :

  1. Mois 3 : L'API SOAP de Banner avait une limite de taux non documentée de 100 requêtes/minute. Notre moteur de recherche de programmes était conçu pour récupérer par lots toutes les données du programme pendant la construction. Nous avons dû mettre en œuvre un système de file d'attente et répartir la construction sur plusieurs lots.

  2. Mois 5 : L'audit d'accessibilité a trouvé 34 violations WCAG 2.1 AA. La plupart provenaient de la conception (contraste de couleur insuffisant sur les boutons secondaires, indicateurs de focus manquants sur les filtres du moteur de recherche de programmes). Nous avons passé 8 jours non prévus sur la correction.

Résultats de performance

Voici ce que les chiffres ressemblaient après le lancement :

Métrique Drupal 7 (avant) Next.js (après) Amélioration
LCP 6,2 s 1,1 s 82% plus rapide
FID / INP 380 ms 45 ms 88% plus rapide
CLS 0,31 0,02 94% meilleur
TTFB 2,8 s 0,12 s 96% plus rapide
Chargement du moteur de recherche de programmes 8,4 s 0,8 s 90% plus rapide
Score Lighthouse 34 97 +63 points
Temps de construction (complet) N/A 4m 12s —
Coût d'hébergement mensuel ~2 400 $ ~1 100 $ 54% inférieur

Mais les chiffres qui importaient le plus pour l'université étaient ceux-ci :

  • L'utilisation du moteur de recherche de programmes a augmenté de 156% au premier semestre suivant le lancement
  • Le taux de rebond mobile a chuté de 67% à 31%
  • Le trafic de recherche organique vers les pages de programme a augmenté de 43% dans les 4 mois (balisage schema.org + améliorations des Core Web Vitals)
  • Les tickets de support relatifs au portail ont baissé de 62% — en grande partie parce que les pages se chargeaient réellement de manière fiable
  • Zéro interruption pendant l'inscription en automne — la première fois en trois ans

Leçons apprises

1. Commencer l'intégration CAS/SSO tôt

Nous avions programmé l'intégration CAS pour le mois 4. Nous aurions dû commencer une preuve de concept au mois 1. Les équipes IT universitaires se déplacent délibérément (lisez : lentement) via les examens de sécurité. Obtenir l'approbation de l'architecture SSO a pris trois semaines d'allers-retours avec leur bureau de sécurité.

2. La modélisation du contenu est une architecture

Nous avons passé deux semaines complètes sur la modélisation du contenu avant d'écrire un code frontal. Cela semblait lent à l'époque. C'était le meilleur investissement que nous ayons fait. Quand vous avez 200+ programmes avec des relations complexes entre départements, collèges, niveaux de diplôme, concentrations et formats de livraison, bien comprendre le schéma au départ économise des centaines d'heures de refactorisation.

3. Former les éditeurs tôt, pas juste avant le lancement

Nous avions initialement planifié la formation des éditeurs pour le mois 5. Nous l'avons déplacée au mois 4 selon les commentaires du propriétaire du produit. Cela a donné aux éditeurs six semaines pour se familiariser avec Sanity au lieu de deux. La qualité du contenu saisi pendant la période d'entrée double était considérablement meilleure grâce à cela.

4. Banner est Banner

Si vous travaillez avec Ellucian Banner (et si vous êtes dans l'enseignement supérieur, vous probablement), budgétisez du temps supplémentaire pour l'intégration API. La documentation est clairsemée, les points de terminaison SOAP sont incohérents, et chaque institution a personnalisé différemment son instance Banner. Notre couche de traduction était essentielle.

5. Budgétiser l'accessibilité dès le jour 1

Nos 34 violations WCAG au mois 5 étaient presque entièrement évitables. Nous exécutons maintenant des vérifications axe-core dans notre pipeline CI sur chaque pull request. Si vous construisez pour une université publique, la conformité WCAG 2.1 AA n'est pas optionnelle — c'est une exigence légale en vertu de la section 508.

Si vous faites face à un défi de migration similaire, nous serions heureux de discuter des spécificités. Vous pouvez nous contacter directement ou consulter notre page de tarification pour savoir comment nous évaluons généralement ces projets.

FAQ

Combien de temps faut-il pour migrer un site web universitaire de Drupal vers Next.js ?

Pour un site de cette échelle — 12 000 nœuds de contenu, 200+ programmes, portail étudiant authentifié — six mois est réaliste avec une équipe dédiée de 4-6 personnes. Les sites institutionnels plus petits (moins de 2 000 pages, sans portail) peuvent souvent être réalisés en 3-4 mois. Le calendrier est moins impulsé par la construction du frontend que par la migration du contenu, l'alignement des parties prenantes et l'intégration aux systèmes institutionnels comme Banner ou PeopleSoft.

Quel CMS headless est le meilleur pour les sites web de l'enseignement supérieur ?

Cela dépend de la taille et du confort technique de votre équipe éditoriale. Nous avons choisi Sanity pour ce projet en raison de sa collaboration en temps réel, de sa modélisation de contenu flexible et de son langage de requête GROQ. Contentful et Storyblok sont également d'excellentes options. Pour les universités avec très grandes équipes de contenu (100+ éditeurs), le modèle de flux de travail et de permissions de Contentful peut être avantageux. Pour les petites équipes qui veulent plus de personnalisation, Sanity tend à gagner.

Next.js peut-il gérer les portails étudiants authentifiés ?

Absolutement. Next.js supporte le rendu côté serveur pour les pages authentifiées, et les composants serveur du routeur d'application rendent directe la récupération des données spécifiques à l'utilisateur sans les exposer au bundle client. Nous avons intégré CAS (Central Authentication Service) en utilisant Auth.js avec un fournisseur personnalisé. Le portail a géré 40 000 étudiants sans problèmes de performance.

Combien coûte une migration Drupal vers Next.js pour une université ?

Un projet de cette portée — moteur de recherche de programmes, portail étudiant, 200+ programmes, migration complète du contenu, configuration du CMS et formation — s'évalue généralement entre 250 000 $ et 450 000 $ selon la complexité. Cependant, les économies à long terme sont importantes. Cette université a réduit ses coûts de maintenance annuels d'environ 180 K$ à 95 K$, ce qui signifie que le projet se rentabilise en 3-4 ans même à l'extrémité supérieure de la fourchette budgétaire.

Qu'advient-il du référencement lors d'une migration CMS de grande envergure ?

C'est une préoccupation légitime. Nous avons mis en œuvre une carte de redirection complète (plus de 2 400 redirections 301), préservé autant que possible toutes les structures d'URL existantes, et ajouté des données structurées schema.org que le site Drupal n'avait pas. Le trafic organique a chuté d'environ 8% dans les deux premières semaines suivant le lancement (normal pour toute migration majeure), puis s'est rétabli et a dépassé le baseline de 43% dans les quatre mois.

Drupal 10 est-il un meilleur choix que d'aller headless pour les universités ?

Il peut l'être, selon la situation. Si votre équipe a une forte expertise Drupal, vos modules personnalisés ont la compatibilité Drupal 10, et vous n'avez pas besoin des caractéristiques de performance d'un site statique/hybride, Drupal 10 est un chemin parfaitement valide. Dans notre cas, l'université avait perdu son expertise Drupal, avait 23 modules incompatibles, et avait besoin d'améliorations drastiques de performance. L'approche headless était clairement le meilleur choix.

Comment gérez-vous la migration de contenu de Drupal vers un CMS headless ?

Nous utilisons des scripts Node.js personnalisés qui exportent le contenu Drupal via des commandes Drush, transforment les données pour correspondre au nouveau schéma CMS, gèrent la migration des fichiers médias et importent le tout via l'API de migration du CMS. Le processus s'exécute généralement 3 fois : une fois pour les tests initiaux, une fois pour le rafraîchissement de la mise en scène, et une fois pour la coupure finale. Le contenu rich text avec des médias intégrés est la partie la plus difficile — vous devez remapper chaque référence de fichier interne.

Pouvez-vous exécuter Drupal et Next.js simultanément lors de la migration ?

Oui, et nous le recommandons. Lors de notre migration, Drupal a continué à servir le site de production tandis que nous construisions et testions la version Next.js sur un domaine de mise en scène. Nous avons utilisé une période d'entrée double de trois semaines où le contenu entrait dans les deux systèmes. La coupure finale était un changement DNS qui a pris environ 15 minutes, avec Drupal conservé en mode lecture seule pendant 30 jours comme secours.