Drupal 7 en fin de vie : un risque cyber et opérationnel majeur en 2025 / 2026

- Publié 24/03/2026 - 11:00, mis à jour à 24/03/2026 - 11:00 Drupal

Article rédigé par Yanmar - Lead Dev Drupal

Contexte : fin de vie officielle de Drupal 7

Drupal 7 a officiellement atteint sa fin de vie (End of Life) le 5 janvier 2025, quatorze ans après sa sortie initiale.
Depuis cette date, le noyau Drupal 7 ainsi que ses modules contribués ne bénéficient plus d’aucune mise à jour de sécurité, de correctifs de compatibilité ou d’améliorations de performance publiés sur — https://new.drupal.org/home.

Le support communautaire officiel est donc définitivement clos.

“Drupal 7 core version has reached end of life, 14 years after its original release, and is no longer community supported on Drupal.org.“

—https://www.drupal.org/about/announcements/blog/drupal-7-has-reached-end-of-life-psa-2025-01-06

Cette évolution marque un tournant important pour l’ensemble des organisations qui exploitent encore des sites reposant sur cette version.

La fin de vie de Drupal 7 entraîne en effet une exposition accrue aux vulnérabilités de sécurité, une incompatibilité progressive avec les environnements techniques modernes (notamment les versions récentes de PHP et les plateformes d’hébergement Cloud), ainsi qu’une détérioration progressive de la conformité vis-à-vis des exigences réglementaires et normatives (RGPD, ANSSI, accessibilité, etc.).

Dans ce contexte, il devient indispensable pour les DSI et responsables applicatifs de préparer dès à présent un plan de migration vers une version plus récente du CMS, telle que Drupal 10 ou 11.

Au-delà de l’aspect technique, cette démarche s’inscrit dans une logique de maîtrise des risques, de pérennité et d’optimisation des coûts.

En effet, le maintien en conditions opérationnelles d’un site Drupal 7 représente désormais un investissement croissant : correctifs spécifiques, dépendances obsolètes, absence de support communautaire, et nécessité de sécuriser manuellement le socle applicatif.

Le présent document a donc pour objectif de sensibiliser les directions des systèmes d’information aux risques techniques, financiers et opérationnels liés au maintien de Drupal 7, tout en exposant les bénéfices et perspectives d’évolution qu’offre une migration planifiée vers les versions modernes du CMS.

1. Fin de vie de Drupal 7 : un risque structurel

La Drupal Association a officiellement annoncé la fin du support communautaire de Drupal 7 le 5 janvier 2025.

Cela signifie qu’aucune mise à jour de sécurité, de compatibilité ou de performance ne sera plus publiée sur Drupal.org, que ce soit pour le noyau ou pour les modules contribués.

Dès lors, toute vulnérabilité nouvellement découverte restera exploitable sans correctif, et les environnements d’exécution modernes (PHP 8.2+, MySQL 8, services Cloud, etc.) cesseront progressivement d’être compatibles.

Cette situation place les DSI face à un risque majeur de rupture de service et à une perte de conformité réglementaire (RGPD, sécurité ANSSI, accessibilité RGAA).

2. Risques techniques et opérationnels

2.1 Sécurité et vulnérabilités non corrigées

Absence de correctifs officiels

Dès la fin de vie (EOL) de Drupal 7, le “Drupal Security Team” ne publiera plus de mises à jour ni pour le noyau, ni pour les modules contrib.
Autrement dit, toute faille découverte restera, dans la plupart des cas, sans patch officiel, ce qui met en péril les données, l’intégrité des environnements et la confiance des utilisateurs.

Publicité des vulnérabilités

Des vulnérabilités peuvent être rendues publiques (via des bases de vulnérabilités ou des forums spécialisés) sans qu’une correction soit disponible. Une fois révélées, elles peuvent être exploitées massivement (phishing, injection SQL, XSS, prise de contrôle). Cela expose l’organisation à des attaques zero-day (failles non encore connues ou sans correctif) ou des attaques ciblées.

Dépendances tierces et extensions obsolètes

Les modules contrib (ou bibliothèques tierces) que Drupal 7 utilise peuvent eux-mêmes avoir atteint leur fin de vie ou ne plus être maintenus. Une faille dans une extension tierce peut suffire à compromettre l’ensemble du site.
Par exemple, les modules Drupal 7 ne recevant plus de correctifs, certaines API externes peuvent évoluer et rendre les modules incompatibles ou dangereux.

Surface d’attaque accrue

À mesure que le CMS vieillit sans évolutions de sécurité, le “surface d’attaque” (bibliothèques, points d’intégration, modules obsolètes) augmente, facilitant la découverte d’un chemin d’attaque.
Dans ce contexte, même des vulnérabilités “mineures” peuvent être combinées pour obtenir un accès complet.

2.2 Compatibilité technique et ruptures dans l’environnement

Incompatibilités avec les versions récentes de PHP

Drupal 7 a été conçu originellement pour des versions de PHP plus anciennes (PHP 5.x, puis PHP 7). Bien que certaines versions de Drupal 7 (à jour) supportent PHP 8.x, le support n’est pas garanti pour chaque module contrib.

— https://www.drupal.org/docs/7/system-requirements/php-requirements-for-drupal-7

Ruptures d’intégration / dépendances externes

Les sites Drupal 7 sont souvent connectés à des systèmes externes (CRM, ERP, API, services tiers). Si l’API de l’un de ces systèmes évolue (changement de version, fin de support), le module Drupal 7 qui assurait l’intégration pourrait devenir incompatible ou cesser de fonctionner.
Cela peut générer des ruptures de service subites, des anomalies fonctionnelles ou des arrêts partiels de fonctionnalités critiques.

2.3 Dette technique & coûts d’exploitation croissants

Perte d’expertise et rareté des compétences

À mesure que Drupal 7 vieillit, les développeurs et agences orientent leurs compétences vers les versions les plus modernes (Drupal 9/10/11). Il devient difficile de trouver des profils compétents pour intervenir sur D7, ce qui entraîne des surcoûts horaires ou des délais de maintenance plus longs.

Maintenance “Sur mesure” et solutions ad hoc

On est souvent conduit à recourir à des correctifs manuels, des patches ad hoc, ou des contournements pour pallier des anomalies ou vulnérabilités — ce qui complique la maintenance, rend le code peu lisible et augmente les risques d’interaction entre correctifs.
De plus, plus la période de maintien est longue, plus les interventions deviennent complexes (interdépendances croissantes).

Surcoûts liés à l’infrastructure

Pour compenser l’obsolescence logicielle, certaines organisations peuvent devoir conserver des versions serveur obsolètes (ancienne version OS, PHP, modules Apache/Nginx), ce qui peut imposer des hébergements spécialisés, coûteux ou “legacy”.
Elles peuvent également être contraintes de surdimensionner les ressources ou d’utiliser des mesures de sécurité complémentaires (WAF, isolation plus stricte), ce qui augmente le coût global d’exploitation.

VOUS AVEZ DES QUESTION SUR DRUPAL ?
> Parler à un expert Drupal

3. Risques économiques et coûts de maintien

La fin du support communautaire de Drupal 7 transforme un risque technique en risque budgétaire et organisationnel direct.

L’absence de maintenance officielle induit une dérive continue du coût total de possession (TCO : Total Cost of Ownership ), ainsi qu’une exposition accrue aux coûts réglementaires et opérationnels.

3.1. Hausse du coût de maintenance applicative

Depuis la fin du support communautaire en janvier 2025, la maintenance de Drupal 7 repose exclusivement sur des correctifs manuels.

Chaque faille identifiée dans le noyau ou dans un module contribué doit être analysée, reproduite et corrigée au cas par cas, sans pouvoir s’appuyer sur la chaîne de publication officielle de Drupal.org.

Cette approche entraîne une augmentation structurelle des coûts de maintenance :

Développement de correctifs sur mesure : chaque vulnérabilité ou anomalie nécessite une intervention spécifique, souvent sans base de référence communautaire.
Tests et intégration non automatisés : l’absence d’outils standard (Composer, CI/CD, Drush à jour) impose des procédures manuelles chronophages.
Risque de régression : les correctifs ne bénéficiant d’aucune validation inter-projets, les risques d’incompatibilité entre modules augmentent.
Surveillance renforcée : les DSI doivent assurer elles-mêmes la veille de sécurité (Drupal SA, CVE, bibliothèques tierces) et vérifier la persistance des vulnérabilités non couvertes.
Compétences limitées : la baisse du nombre de développeurs familiers de Drupal 7 entraîne une hausse moyenne des coûts journaliers.

De plus, le maintien d’un environnement technique ancien (versions de PHP 7.x, dépendances obsolètes, modules Apache/Nginx anciens) nécessite :

un hébergement spécifique non mutualisable,
une supervision accrue (surveillance des logs, durcissement applicatif, WAF),
et des actions récurrentes de mise à niveau partielle.

Ces contraintes se traduisent par une hausse globale du budget de maintenance.

Enfin, les failles de sécurité non couvertes représentent un risque financier implicite :
une seule compromission peut engendrer des coûts de reprise et de remédiation supérieurs à plusieurs années de maintenance préventive.

3.2. Coûts de conformité et d’audit

Le maintien d’un CMS non supporté compromet la conformité vis-à-vis de plusieurs cadres réglementaires :

RGPD – article 32 : obligation de garantir la sécurité “à l’état de l’art”.

Exploiter un CMS non maintenu (fin de vie) rend difficile de démontrer le respect de l’art. 32 (mesures « à l’état de l’art » et tests réguliers) et expose à des écarts de conformité.

— https://www.cnil.fr/sites/cnil/files/2024-03/cnil_guide_securite_personnelle_2024.pdf

Recommandations ANSSI – Sécuriser un site web (2023) : usage exclusif de composants maintenus.

Ces recommandations présupposent l’usage de composants maintenus et la capacité à appliquer rapidement des correctifs. Un socle en fin de vie contrevient à cette exigence (pas de correctifs officiels, dépendances anciennes)

— https://cyber.gouv.fr/publications/securiser-un-site-web

Accessibilité – RGAA v4 / WCAG 2.1 : absence de compatibilité des thèmes et modules D7.

Les WCAG (Web Content Accessibility Guidelines) sont les normes internationales publiées par le W3C (World Wide Web Consortium), dans le cadre de l’initiative WAI (Web Accessibility Initiative). Elles fixent les règles techniques permettant à un site web d’être accessible aux personnes handicapées (déficiences visuelles, auditives, motrices, cognitives, etc.).

Drupal 7 et ses thèmes/modules historiques ont été conçus avant l’alignement général sur WCAG 2.1 et la conformité RGAA v4 n’est pas fournie par défaut.

— https://www.ecologie.gouv.fr/sites/default/files/documents/RGAA-v4.0.pdf

Ces écarts se traduisent, lors des audits de sécurité ou de conformité, par :

la mise en œuvre de mesures compensatoires (WAF, durcissement réseau, supervision avancée) .
des audits de remédiation récurrents .
et parfois des refontes imposées en cas de constat de non-conformité.

Les coûts cumulés de ces actions dépassent généralement ceux d’une migration planifiée.

3.3. Dégradation de la valeur applicative et du patrimoine SI

Le maintien sur Drupal 7 dégrade la valeur du patrimoine applicatif sur plusieurs axes :

Non-intégrabilité : impossibilité d’interfacer efficacement le site avec les outils modernes du SI (SSO, CI/CD, API REST standard).
Non-mutualisation : les briques applicatives Drupal 7 ne peuvent être réutilisées dans les projets Drupal 10/11.
Non-transférabilité : la reprise ou la sous-traitance devient difficile, car la technologie est obsolète et les profils disponibles rares.

Ces contraintes se traduisent par une baisse mesurable de la valeur de remplacement du site et une perte de maîtrise de la trajectoire applicative au sein du système d’information.

4. Bénéfices et perspectives de migration vers Drupal 10 / 11

La migration vers Drupal 10 ou 11 ne se limite pas à une opération technique. Elle constitue une mise à niveau structurelle du socle applicatif, alignée sur les standards actuels de sécurité, d’accessibilité et d’exploitation.

Les nouvelles versions de Drupal ont été conçues pour offrir un cycle de vie pérenne, des mises à jour continues et une réduction significative du coût de maintenance.

4.1. Socle technique modernisé

Drupal 10 repose sur :

le framework Symfony 6.
le langage PHP 8.2+ .
un modèle d’autoloading PSR-4 et une gestion des dépendances via Composer.

Cette architecture confère au CMS :

Une meilleure maintenabilité du code.
Une intégration native avec les pipelines CI/CD.
Une compatibilité renforcée avec les environnements d’hébergement contemporains (Docker, Kubernetes, Platform.sh, etc.).

Le modèle modulaire permet également d’adopter des composants standards du monde Symfony et de réduire la complexité du code custom.

4.2. Sécurité et conformité intégrées

Drupal 10 bénéficie d’un support de sécurité continu assuré par la Drupal Security Team :

Publication proactive de correctifs.
Gestion centralisée des dépendances via composer.lock.
Compatibilité avec les politiques de chiffrement modernes (TLS 1.3).
Support natif de l’authentification forte (OAuth2, OpenID Connect).

Ces mécanismes garantissent un niveau de conformité aligné sur :

Le RGPD – art. 32 (sécurité « à l’état de l’art »).
Les recommandations ANSSI (Sécuriser un site web, 2023).
Les normes WCAG 2.1 / RGAA v4 pour l’accessibilité.

Le durcissement applicatif (CSP, SameSite, Trusted Host, cookie secure) est désormais activable nativement, sans recourir à des modules externes.

4.3. Expérience utilisateur et productivité

Les évolutions majeures de l’interface favorisent la productivité des contributeurs :

CKEditor 5 : nouvel éditeur ergonomique, accessible et compatible ARIA, offrant une expérience proche des suites bureautiques modernes.
Layout Builder : création visuelle de gabarits et pages par glisser-déposer.
Media Library : gestion centralisée des images, vidéos et documents.
Thème Claro (administration) et thème Olivero (front-end) : design responsive, conformité WCAG 2.1 AA.
Amélioration du workflow de publication : révisions, modération, planification native.

Ces outils réduisent les coûts de formation et de support éditeur, tout en améliorant la qualité éditoriale.

4.4. Interopérabilité et alignement SI

Les versions 10 et 11 sont conçues selon une logique API First :

Services REST, JSON:API et GraphQL intégrés.
Intégration facilitée avec les systèmes d’information : SSO (Azure AD, Keycloak, LDAP), CRM, ERP, DAM, etc.
Compatibilité native avec les outils de supervision (Elastic, Prometheus, Datadog).
Support complet des pratiques DevSecOps : containerisation, pipeline automatisé, revue de code et monitoring applicatif.

L’application devient ainsi pleinement intégrable dans un écosystème SI moderne, répondant aux exigences d’interopérabilité et d’observabilité imposées par les politiques de sécurité des grandes organisations.

4.5. Pérennité économique et réduction du coût global

L’approche de maintenance évolue vers un cycle continu sans refonte :

Passage de Drupal 10 → 11 → 12 par simples mises à jour incrémentales ;
Fin des migrations lourdes et coûteuses.
La mutualisation des compétences (toutes les agences Drupal sont désormais centrées sur les versions 10 / 11) et la disponibilité de correctifs communautaires garantissent une réduction du coût de maintenance.

Conclusion

La fin de vie de Drupal 7, effective depuis le 5 janvier 2025, met fin à plus de quatorze années de support communautaire.

Cette échéance transforme un socle historiquement stable en une source de vulnérabilités, de non-conformité et de dérive budgétaire pour l’ensemble des organisations qui l’exploitent encore.

Les analyses techniques et réglementaires menées montrent que :

Les vulnérabilités non corrigées du cœur et des modules exposent directement les systèmes d’information.
La dette technique et la rareté des compétences accroissent le coût et le délai de toute maintenance.
La non-conformité aux exigences RGPD, ANSSI et RGAA peut engager la responsabilité de l’organisation en cas d’incident.
Le TCO global d’un site Drupal 7 en maintien interne excède rapidement celui d’une migration planifiée vers un socle moderne.

À l’inverse, Drupal 10/11 apporte :

Un socle technique pérenne (Symfony 6, PHP 8.2+, Composer) et aligné sur les standards actuels du marché.
Une sécurité nativement intégrée (correctifs continus, durcissement applicatif, gestion centralisée des dépendances).
Une expérience utilisateur et éditoriale modernisée (CKEditor 5, Layout Builder, thèmes Claro / Olivero) ;
Une interopérabilité complète avec les outils SI actuels (API REST, SSO, CI/CD, observabilité) ;
Une réduction du coût total de maintenance.

En résumé

La fin du support communautaire de Drupal 7 depuis le 5 janvier 2025 expose les sites encore basés sur cette version à des risques critiques de sécurité, d’obsolescence et de non-conformité réglementaire (RGPD, ANSSI, accessibilité RGAA).

Sans correctifs officiels, les failles de sécurité, les dépendances non maintenues et la rareté croissante des compétences techniques Drupal 7 entraînent une hausse significative des coûts de maintenance et une fragilisation opérationnelle.

À l’inverse, la migration vers Drupal 10 ou 11 offre un socle moderne, sécurisé et pérenne, conforme aux standards techniques et réglementaires actuels.

Ces versions s’appuient sur un écosystème d’expertise actif et en croissance, garantissant la disponibilité de prestataires, la maintenabilité du code et l’évolutivité du système.

La migration permet ainsi une réduction mesurée du coût total de possession, une amélioration de la productivité éditoriale et de la sécurité applicative, ainsi qu’une meilleure intégration dans les environnements SI modernes.

La mise en œuvre d’un plan de migration avant fin 2025 constitue donc une priorité stratégique pour maîtriser les risques, sécuriser les plateformes et garantir la continuité opérationnelle à long terme.