Quitter Drupal multisite : choisir sa voie après Drupal 7 et migrer les sites dans le bon ordre

Un guide pratique pour les équipes qui gèrent de nombreux sites sur Drupal multisite : les trois vraies options après la fin de vie de Drupal 7, comment auditer les types de contenu, les vues et les modules de chaque site, une grille pour savoir quels sites justifient Drupal, et un plan de bascule qui préserve les URL et les archives.

Drupal multisite se trouve surtout dans les universités, les organismes publics et les grandes associations, où une équipe compétente l'a mis en place pour servir des dizaines de sites de départements à partir d'une seule base de code. L'équipe a depuis changé, les sites se sont multipliés, et de nombreux réseaux tournent encore sur Drupal 7, dont le support de sécurité communautaire a pris fin le 5 janvier 2025. Quelle que soit la raison de votre venue, la question est la même : lesquels de ces sites ont vraiment besoin de Drupal, et quelle est la façon la moins risquée de déplacer les autres ? Ce guide traite cette décision, puis la migration elle-même.

Comment est construit Drupal multisite

La documentation de Drupal décrit le multisite comme l'exploitation de sites séparés et indépendants à partir d'une seule base de code, chacun avec sa propre base de données, sa configuration, ses fichiers et son domaine. Sur le disque, chaque site a son propre dossier dans le répertoire sites, qui contient au moins ses fichiers et parfois ses propres modules et thèmes. Deux conséquences orientent toute migration :

Code partagé, données séparées. Une mise à jour du cœur ou d'un module atteint tous les sites à la fois, ce qui faisait l'attrait initial et constitue le risque principal. Un module dont dépend un site ne peut pas être retiré sans vérifier tous les autres.
Chaque site est une migration à part. Comme chaque site a sa propre base de données et sa propre configuration, il n'existe pas d'« export du réseau ». Vous planifiez, déplacez et testez site par site.

Vos trois options, comparées honnêtement

Option	Ce qu'elle implique	Idéale pour	Coût principal
Passer à la version actuelle de Drupal	Construire de nouveaux sites sur la version actuelle de Drupal et y reprendre les contenus avec la Migrate API de Drupal. Depuis Drupal 7, c'est une reconstruction et une migration, pas une mise à jour sur place.	Les sites aux modèles de contenu complexes, qui utilisent beaucoup les vues (Views), des modules sur mesure, des intégrations, ou dont l'équipe connaît bien Drupal	Le temps de développement par site, et la maintenance continue de Drupal
Support étendu payant pour Drupal 7	Continuer à exploiter Drupal 7 avec des correctifs de sécurité fournis par un prestataire du programme Extended Security Support Provider de la Drupal Association (actuellement HeroDevs et Tag1 Consulting)	Gagner du temps pendant qu'une migration est planifiée et financée	Un abonnement récurrent, et la migration reste à faire
Passer à une autre plateforme	Reconstruire les sites sur un autre CMS ou créateur de sites	Les sites vitrines, d'information, d'événements et de départements au contenu simple	Reconstruire chaque site ; perdre les fonctions propres à Drupal que vous utilisiez vraiment

La plupart des grands réseaux finissent par panacher : une poignée de sites complexes restent sur Drupal, la longue traîne passe à quelque chose de plus simple, et certains sont retirés. Le travail consiste à décider quel site va où.

Auditez le modèle de contenu de chaque site

Les sites Drupal diffèrent bien plus les uns des autres que les sites WordPress, parce que les types de contenu, les champs et les vues sont construits site par site. Avant de noter quoi que ce soit, consignez ce que chaque site utilise réellement. Un développeur Drupal peut extraire l'essentiel depuis les écrans d'administration ou avec Drush ; l'objectif est de tout réunir dans un seul tableau.

Élément	Ce qu'il faut consigner	Pourquoi c'est important
Types de contenu	Chaque type, nombre d'éléments, date du dernier élément créé	Beaucoup de types avec peu d'éléments trahissent une construction excessive ; un type de 5,000 éléments exige une migration scriptée
Champs	Champs de référence, collections de champs ou paragraphes, champs de fichiers	Les relations structurées sont ce qu'il y a de plus difficile à porter vers une plateforme plus simple
Taxonomies	Vocabulaires et la façon dont ils pilotent la navigation ou le filtrage	Les listes filtrées doivent avoir un équivalent sur la nouvelle plateforme
Vues	Chaque vue, où elle apparaît, si elle propose des filtres exposés aux utilisateurs	Les filtres exposés (un annuaire du personnel, un moteur de recherche de formations) sont souvent la raison d'être d'un site
Formulaires	Webforms, leurs soumissions, les obligations de conservation	Les soumissions peuvent être des archives que vous devez conserver
Utilisateurs et rôles	Rédacteurs, membres, éventuels comptes publics	Les mots de passe ne peuvent généralement pas être transférés vers une autre plateforme
Modules sur mesure et contribués	Ce que chacun fait pour ce site	Chacun est soit une fonction à reconstruire, soit une dépendance à abandonner
Intégrations	Authentification unique, systèmes de gestion des étudiants ou des membres, paiement, recherche	Ce sont généralement elles qui décident si un site peut quitter Drupal
Trafic et liens	Visites sur 12 mois, principales pages d'entrée, pages recevant des liens externes	Définit le travail de redirection

Notez les sites qui justifient Drupal

Donnez à chaque site un point par « oui » ci-dessous. Le seuil vous appartient, mais en pratique les sites qui obtiennent trois points ou plus ont généralement leur place sur la version actuelle de Drupal ou un autre CMS complet, et ceux qui obtiennent zéro ou un point sont de bons candidats pour un créateur de sites plus simple.

Il contient des contenus structurés que d'autres pages interrogent (un annuaire, un catalogue, un moteur de recherche de formations ou de personnel).
Il propose aux utilisateurs des filtres ou une recherche allant au-delà de la recherche de base.
Il repose sur un module sur mesure qui fait un vrai travail.
Il est intégré à un système de référence interne.
Il a des utilisateurs connectés autres que les rédacteurs.
Son équipe éditoriale a besoin de plusieurs rôles et d'une relecture par étapes.
Il compte plus de quelques centaines de pages activement maintenues.

Notez les sites en présence de leurs responsables. Ils savent souvent que la vue sophistiquée de leur page d'accueil n'a pas été regardée depuis des années, et tout aussi souvent qu'il existe une dépendance dont personne d'autre ne se souvient.

Déplacer les sites qui partent

Contenus

Pour les sites simples, le plus rapide est généralement une copie structurée : explorez le site en ligne pour récupérer chaque page et son URL, puis reconstruisez page par page en réécrivant au passage. Pour les sites qui comptent des centaines d'éléments du même type (actualités, événements), exportez-les en CSV ou en JSON, avec l'aide d'un développeur ou via l'export de données de Views, et importez-les là où la nouvelle plateforme le permet, ou décidez que seules les deux dernières années migrent et que le reste est archivé.

Fichiers

Copiez le dossier de fichiers de chaque site. Vérifiez la présence de fichiers privés (Drupal peut servir des fichiers hors du dossier public), qui contiennent souvent des documents devant rester restreints ; ils exigent une décision réfléchie, pas un import en masse sur un site public.

Adresses

Établissez une table de redirections par site : ancien chemin, nouvelle adresse, redirection permanente. Les sites Drupal ont souvent à la fois un chemin système (node/123) et un alias ; incluez les deux pour les pages qui reçoivent du trafic. Si des sites changent de domaine, conservez les anciens domaines et les redirections pendant de nombreux mois.

Un ordre de bascule qui limite les dégâts

Phase	Sites	Objectif
1. Retirer	Sans responsable, sans trafic	Archiver, rediriger, supprimer. Réduit immédiatement le réseau et la surface d'attaque.
2. Pilote	Deux ou trois sites simples avec des responsables impliqués	Éprouver le processus, les modèles et la méthode de redirection.
3. Longue traîne	Les autres sites à faible score, par vagues selon le responsable	Déplacer le gros des sites tant que le processus est rodé.
4. Complexes	Sites à score élevé	Migrer vers la version actuelle de Drupal ou un autre CMS complet avec un vrai temps de développement.
5. Extinction	L'ancienne installation	Seulement quand plus rien n'en dépend, redirections comprises.

Commencer par retirer des sites semble à l'envers, mais cela fonctionne : chaque site retiré de l'ancien réseau est un site de moins exposé pendant que vous traitez les autres.

La gouvernance de la nouvelle organisation

L'ancien réseau avait probablement un seul gardien technique. La nouvelle organisation ne doit pas recréer ce goulot d'étranglement, mais elle ne doit pas non plus donner à chaque département un bouton de publication sans relecture. Avant que le premier site ne migre, décidez qui est responsable de chaque site, qui peut publier, quels sites exigent une validation avant leur mise en ligne et qui peut ajouter des fonctions comme des formulaires ou une boutique. Notre modèle de politique de gouvernance web et notre guide du circuit de validation des contenus traitent de ces questions.

La place de We.Inc, et ses limites

We.Inc est un créateur de sites en marque blanche pour les organisations qui gèrent de nombreux sites sous une même marque. Il convient aux sites à faible score de votre tableau, pas à ceux à score élevé. Il n'a pas d'outil d'import Drupal, pas d'équivalent des vues avec filtres exposés et pas de types de contenu personnalisés ; les sites sont reconstruits par IA à partir de modèles ou d'une description, puis vérifiés par votre équipe. Ce qu'il apporte pour la longue traîne :

Une marque unique (logo, couleurs, polices) appliquée à chaque site, chaque département étant un client de cette marque.
Des réglages par défaut à l'échelle de la marque pour ce que les sites peuvent faire, modifiables site par site, dont une validation en une étape avant la mise en ligne d'un site.
Des domaines personnalisés par site, et des règles de redirection dans les réglages SEO de chaque site.
Le téléchargement du code en ZIP ou l'export vers GitHub, pour que les contenus que vous déplacez ne soient jamais captifs.

La marque est définie une fois et appliquée à chaque site de département, au lieu d'être imposée par un thème partagé.

Interrupteurs par défaut de la marque intitulés Ce que vos clients peuvent faire, au-dessus d'une liste d'équipe — Les réglages par défaut déterminent ce que chaque nouveau site peut faire, à la place de l'activation module par module.

Une liste En attente de votre validation avec un site et des boutons pour valider et publier ou demander des modifications — Validation en une étape avant la mise en ligne d'un site, pour les départements qui ont besoin d'un contrôle. La demande en attente sur cette marque de démonstration a été mise en scène pour la capture.

Une fenêtre Exporter le projet avec les onglets GitHub, ZIP, Vercel et Domaine et une option de dépôt privé — Chaque site peut être exporté vers un dépôt GitHub ou téléchargé en ZIP.

L'accessibilité n'est pas automatique : les pages construites par IA doivent toujours être testées par votre équipe avant leur mise en ligne, en particulier pour les organismes publics soumis à l'ADA Title II (consultez notre guide de l'échéance du titre II). Si votre tableau d'audit fait apparaître une longue traîne de sites simples, réservez une démo et apportez-le. Pour une comparaison plus large, lisez créateur de sites en marque blanche ou CMS d'entreprise ; si une partie de votre parc est sur WordPress, consultez quitter WordPress multisite.

Sources

Dernière vérification le 2026-10-25.

Drupal.org, Drupal 7 End of Life (fin du support de sécurité, programme Extended Security Support Provider).
Drupal.org, Multisite Drupal.
Drupal.org, Multisite folder structure in Drupal.
Drupal.org, Upgrading Drupal (Migrate API).

Questions fréquentes

Quand Drupal 7 est-il arrivé en fin de vie ?

Drupal.org indique que le support de sécurité de Drupal 7 a pris fin le 5 janvier 2025. Un support de sécurité étendu payant est proposé par les prestataires du programme Extended Security Support Provider de la Drupal Association.

Puis-je mettre à niveau Drupal 7 multisite sur place ?

Pas au sens habituel. Passer de Drupal 7 à une version actuelle signifie construire de nouveaux sites et migrer les contenus, généralement avec la Migrate API de Drupal, site par site puisque chaque site a sa propre base de données.

Quels sites Drupal doivent rester sur Drupal ?

Les sites dont les contenus structurés sont interrogés par d'autres pages, qui proposent des filtres aux utilisateurs, des modules sur mesure faisant un vrai travail, des intégrations à des systèmes internes, des utilisateurs connectés, des équipes éditoriales à plusieurs rôles ou un grand nombre de pages activement maintenues. Les sites d'information simples sont de bons candidats pour une plateforme plus simple.

Dans quel ordre migrer les sites ?

Retirez d'abord les sites sans responsable ni trafic, puis menez un pilote sur deux ou trois sites simples, déplacez la longue traîne par vagues, migrez les sites complexes avec un vrai temps de développement, et n'éteignez l'ancienne installation que lorsque plus rien n'en dépend.

We.Inc peut-il importer des sites Drupal ?

Non. Il n'existe pas d'outil d'import Drupal, et We.Inc n'a ni types de contenu personnalisés ni listes filtrées à la manière des vues. Il convient aux sites simples de départements et d'information, reconstruits à partir de modèles et relus par votre équipe.