Drupal 7 et Drupal 10 en fin de vie : que faire de votre site ?

Si votre site tourne sous Drupal 10, vous avez jusqu'au 9 décembre 2026 pour passer en Drupal 11, et cette mise à jour se fait sans reconstruire le site. S'il tourne encore sous Drupal 7, 8 ou 9, il ne reçoit plus de correctifs de sécurité officiels, et en sortir demande une reconstruction, que vous restiez sur Drupal ou non. Ce guide reprend les dates, les risques réels, les cinq options possibles et la façon de préparer la suite. Les dates et les faits ont été vérifiés le 30 octobre 2026.

L'essentiel en bref

• Drupal 7, 8 et 9 ne reçoivent plus aucun correctif de sécurité officiel. Drupal 7 est le cas le plus répandu et le plus exposé.
• Drupal 10 perd son support le 9 décembre 2026. Le passage à Drupal 11 se fait sans reconstruire le site, à condition que vos modules suivent.
• Sortir de Drupal 7 demande une reconstruction, que l'on reste sur Drupal ou non. Le chantier a la même ampleur dans les deux cas.
• Cinq options existent : support étendu payant, Backdrop CMS, Drupal 11, WordPress ou Wagtail. Le bon choix dépend de votre version, de votre équipe et de ce que fait votre site.

Les dates de fin de support de Drupal

Depuis Drupal 10, le projet suit un rythme régulier : une version majeure tous les deux ans environ, et Drupal 10 aura été maintenu quatre ans. Drupal 11 demande au minimum PHP 8.3 sur le serveur. Le calendrier officiel est publié sur drupal.org.

Faire le point sur votre site Drupal

Avant de choisir, il faut savoir d'où l'on part. Six vérifications suffisent, et la plupart se font depuis l'administration du site :

• La version de Drupal : elle figure en tête du rapport d'état (Rapports, puis Rapport d'état, à l'adresse /admin/reports/status).
• La version de PHP : elle est indiquée dans le même rapport. Elle dit combien de temps votre serveur peut encore être maintenu.
• Les modules sans support : le rapport des mises à jour disponibles (/admin/reports/updates) signale les modules abandonnés et les correctifs de sécurité en attente.
• Les modules sur mesure : tout ce qui a été développé pour vous devra être réécrit, quelle que soit l'option retenue. Comptez-les.
• La date de la dernière mise à jour : un site resté longtemps sans mise à jour a souvent accumulé des correctifs manqués, bien avant sa fin de support.
• Qui a la main : accès à l'hébergement, au code et au nom de domaine. Une migration bloque souvent sur un ancien prestataire injoignable ou des accès perdus.

Notez aussi ce que fait vraiment votre site au-delà des pages : espace membre, annuaire, agenda, formulaires d'inscription, paiement des cotisations, newsletter, recherche. Ce sont ces fonctions, bien plus que le nombre de pages, qui pèsent dans le choix et dans le coût.

Ce que la fin de support change concrètement

Le jour J, rien ne se voit : le site s'affiche comme la veille. Ce qui s'arrête, ce sont les correctifs. L'équipe de sécurité de Drupal ne publie plus d'avis ni de mise à jour pour la version abandonnée, et les responsables des modules contribués cessent de maintenir leur branche pour cette version. Chaque faille découverte ensuite reste ouverte.

Des effets plus lents suivent. Les développeurs qui connaissent encore Drupal 7 se font rares, chaque intervention coûte plus cher, et un audit de sécurité ou le questionnaire d'un partenaire signalera tôt ou tard un logiciel hors support.

Ce que les failles Drupalgeddon ont appris

Le 15 octobre 2014, l'équipe de sécurité de Drupal publie le correctif d'une faille critique du cœur de Drupal 7, vite surnommée Drupalgeddon. Deux semaines plus tard, elle publie un avertissement public : les propriétaires doivent partir du principe que tout site Drupal 7 non corrigé dans les sept heures qui ont suivi l'annonce a été compromis. Des robots avaient commencé à exploiter la faille presque aussitôt, et la mise à jour ne suffisait pas à nettoyer un site déjà infecté : il fallait le restaurer depuis une sauvegarde antérieure.

En mars 2018, Drupalgeddon 2 (CVE-2018-7600) touche Drupal 7 et 8. Les premières attaques arrivent quelques heures après la publication d'un code d'exploitation, pour installer des portes dérobées et des logiciels de minage de cryptomonnaie. Une troisième faille de la même famille suit en avril.

Ces épisodes ont touché des versions encore supportées : le correctif existait, et tout se jouait en heures. Sur une version hors support, la prochaine faille de ce type n'aura pas de correctif officiel du tout.

L'impasse PHP de Drupal 7

Drupal 7 fonctionne jusqu'à PHP 8.3 depuis sa version 7.103, publiée fin 2024. Il ne prendra pas en charge PHP 8.4, indique drupal.org. Or, selon le calendrier officiel de PHP, PHP 8.2 ne reçoit plus de correctifs de sécurité après le 31 décembre 2026, et PHP 8.3 après le 31 décembre 2027. Sauf si le support étendu prend le relais sur ce point, un site Drupal 7 tournera donc à partir de 2028 sur une version de PHP elle-même abandonnée. Nous avons montré avec la faille PHP2Shell ce que cela peut coûter.

Les données de vos membres

Un site d'association conserve souvent des comptes, des adresses électroniques, parfois des informations d'adhésion ou de paiement. Le RGPD (article 32) demande des mesures de sécurité adaptées au risque pour ces données. Un logiciel qui ne reçoit plus de correctifs rend cette obligation difficile à défendre en cas d'incident, face à vos membres comme face à l'autorité de protection des données.

Pourquoi tant d'associations européennes sont sur Drupal

Drupal a longtemps été le choix naturel des organisations qui publient beaucoup, en plusieurs langues, avec plusieurs équipes. À Bruxelles, l'effet d'entraînement a été fort : la Commission européenne a bâti sa plateforme web Europa sur Drupal au milieu des années 2010, et beaucoup d'acteurs proches des institutions (fédérations, ONG, réseaux financés par l'Union, agences) ont fait le même choix.

Beaucoup de ces sites datent de l'époque de Drupal 7, avec de nombreux modules et des développements sur mesure. Ils arrivent en même temps au même mur. Entre-temps, Drupal s'est positionné sur les grands projets et équipe aujourd'hui moins de 1 % des sites web selon W3Techs : les prestataires qui maîtrisent encore Drupal 7 deviennent difficiles à trouver.

Option 1 : rester sur Drupal 7 avec un support étendu

Deux sociétés sont certifiées par Drupal pour continuer à corriger Drupal 7 après sa fin de vie : HeroDevs et Tag1. Leur service est payant, demande d'être sur la dernière version de Drupal 7, et ne couvre pas forcément tous les modules installés sur votre site. Les clients de l'hébergeur Pantheon en bénéficient gratuitement jusqu'au 5 janvier 2027.

Pour : aucun chantier immédiat. Contre : un coût récurrent, une couverture partielle des modules, la question de PHP à partir de 2028, et le problème de fond reste entier. C'est une solution d'attente, utile le temps de préparer la suite.

Option 2 : Backdrop CMS, la continuité de Drupal 7

Backdrop CMS est une branche de Drupal 7 maintenue par sa propre communauté. Il reprend directement une base de données Drupal 7, sans migration de contenu : les pages, les comptes et les taxonomies restent en place. Les modules et le thème doivent en revanche exister en version Backdrop, ou être adaptés. Il faut le vérifier module par module avant de s'engager.

Pour : le chemin le plus léger pour un site Drupal 7 simple. Contre : une communauté et un choix de modules bien plus réduits que ceux de Drupal ou de Wagtail, et moins de prestataires pour vous accompagner.

Option 3 : passer en Drupal 10 ou 11

Depuis Drupal 10, la mise à jour vers Drupal 11 est une évolution : on met à jour le code, les modules et PHP, le site reste le même. Depuis Drupal 8 ou 9, il faut passer les versions une à une (8, puis 9, puis 10, puis 11), en remplaçant les modules abandonnés en chemin.

Depuis Drupal 7, c'est une reconstruction. Drupal 8 a remplacé toute l'architecture : modèles de contenu, thème et modules sont à refaire, et les contenus passent par les outils de migration de Drupal. Point important : ces outils de migration depuis Drupal 6 et 7 sont retirés du cœur dans Drupal 12. Un site Drupal 7 qui veut rester sur Drupal doit donc migrer vers Drupal 11, puis suivre la mise à jour normale vers Drupal 12.

Drupal a aussi changé de visage. Depuis janvier 2025, le projet propose « Drupal CMS », une version prête à l'emploi pensée pour les équipes non techniques. Sa version 2.0, sortie début 2026, ajoute un éditeur visuel de pages (Drupal Canvas), des modèles de site et des fonctions d'intelligence artificielle optionnelles.

Pour : une équipe qui connaît Drupal garde ses repères, et le contenu structuré reste un point fort. Contre : depuis Drupal 7, le chantier a la taille d'un changement de CMS, puis une montée de version majeure revient tous les deux ans.

Option 4 : passer à WordPress

WordPress fait tourner une grande partie du web, avec un choix immense d'extensions et de prestataires. Pour un site vitrine simple, géré par une ou deux personnes, il fait l'affaire.

Pour une association européenne, deux besoins demandent des extensions supplémentaires : le multilingue (WPML ou Polylang, par exemple) et les circuits de validation en plusieurs étapes. Chaque extension ajoute des mises à jour à suivre et, parfois, une licence annuelle.

Pour : un écosystème énorme et des coûts de départ bas. Contre : la dépendance aux extensions, qui concentrent l'essentiel des failles, et un modèle moins adapté aux contenus très structurés. Nous détaillons ces différences dans Wagtail vs WordPress.

Option 5 : passer à Wagtail

Wagtail est un CMS open source construit sur Django (Python), développé depuis 2014 et utilisé notamment par le NHS britannique, la Mozilla Foundation, Google pour plusieurs de ses publications, et l'État français pour les sites de son administration. C'est l'outil le plus proche de Drupal dans sa logique : types de pages avec leurs champs, blocs de contenu (l'équivalent des Paragraphs), taxonomies, droits par équipe, circuits de validation en plusieurs étapes et multilingue natif.

Son rythme de mise à jour est prévisible : une version à support long (LTS) sort chaque année et reçoit les correctifs de sécurité pendant environ dix-huit mois. La 7.4 LTS, par exemple, est maintenue jusqu'en novembre 2027 (voir Wagtail LTS). Un site se met donc à jour une fois par an, de LTS en LTS.

Pour : une interface d'édition plus simple pour des équipes non techniques, moins de dépendances tierces, un rythme de mise à jour prévisible. Contre : depuis Drupal, c'est aussi une reconstruction, et Wagtail compte moins de modules prêts à l'emploi : les fonctions particulières se développent sur mesure, ce qui demande une équipe qui connaît Django.

Les cinq options comparées

Ce qui fait varier le coût d'une migration

Le nombre de pages compte peu : un import automatique traite cent pages comme dix mille. Le coût dépend surtout de ces éléments :

• Le nombre de types de contenu : chacun devient un modèle à concevoir, avec son design.
• Les langues : chaque langue ajoute des traductions à réconcilier et à vérifier.
• Les fonctions sur mesure : espace membre, annuaire, agenda, paiement. C'est souvent le poste le plus lourd.
• La qualité du contenu existant : un contenu propre se migre seul, des années de copier-coller depuis Word demandent un nettoyage.
• Le tri : chaque page qu'on décide de ne pas migrer est une page de moins à vérifier.
• Les intégrations : CRM, outil d'emailing, paiement, connexion unique avec d'autres outils.

C'est pourquoi une estimation sérieuse passe par un audit du site existant plutôt que par un prix au nombre de pages.

Préparer la migration, quel que soit le CMS choisi

• 1. L'inventaire : toutes les adresses du site (via le plan du site ou un outil d'exploration), les types de contenu et les volumes par langue.
• 2. La mesure du trafic : dans la Search Console et vos statistiques, les pages qui apportent des visites et des liens. Elles se traitent en priorité.
• 3. Le tri : garder, fusionner ou archiver chaque contenu.
• 4. Le plan de redirections : chaque ancienne adresse vers sa nouvelle page, y compris les /node/123 et les anciens alias.
• 5. Les comptes et les données personnelles : quels comptes migrer, quelles données conserver, et ce qu'en dit votre registre des traitements.
• 6. Le calendrier de bascule : gel des publications quelques jours, dernier import des changements, mise en ligne, puis suivi du référencement pendant plusieurs semaines.

Notre méthode pour garder ses positions dans Google est détaillée dans migrer un site sans perdre son référencement.

Les erreurs fréquentes

• Attendre une faille pour décider : le projet se fait alors dans l'urgence, au pire moment et au prix fort.
• Migrer tout sans trier : on paie la migration de pages que personne ne lit plus.
• Oublier les redirections : les liens externes et le référencement accumulés depuis des années disparaissent du jour au lendemain.
• Sous-estimer les traductions : Drupal 7 stockait les traductions de deux façons différentes selon les modules utilisés, parfois sur le même site.
• Découvrir une fonction en cours de route : un espace membre ou un formulaire oublié à l'audit fait dériver le planning.
• Reproduire l'ancien site à l'identique : une migration est l'occasion de simplifier les modèles de contenu et l'arborescence.

Comment choisir

• Votre site est en Drupal 10 et vous convient : passez en Drupal 11 avant le 9 décembre.
• Vous êtes en Drupal 7 et il vous faut du temps : un support étendu couvre la période, le temps de décider.
• Votre site Drupal 7 est simple et vous voulez le garder tel quel : regardez Backdrop.
• Vous devez reconstruire de toute façon : comparez Drupal 11 et Wagtail sur ce qui compte pour vous, à commencer par le confort de vos éditeurs et le coût de maintenance sur cinq ans.
• Petit site vitrine, une ou deux personnes pour l'éditer : WordPress ou une solution plus légère peut suffire.

Si Wagtail vous intéresse, notre page migration de Drupal vers Wagtail détaille les étapes, le circuit de validation et les points délicats d'une migration.