Depuis le 5 janvier 2025, la communauté Drupal ne publie plus aucun correctif pour Drupal 7. Pour les sites qui tournent encore dessus, l'Association Drupal a mis en place un programme de fournisseurs de support étendu certifiés. Deux sociétés y figurent : HeroDevs et Tag1 Consulting. J'ai déjà présenté les trois options possibles pour un site Drupal 7 dans un article précédent. Ici, je détaille le support étendu lui-même : ce qu'il couvre réellement, ce qu'il ne couvre pas, combien il coûte quand le prix est public, et comment l'utiliser comme transition vers une migration.
Les informations ci-dessous proviennent des pages officielles des deux éditeurs et de drupal.org, vérifiées à la date de rédaction. Les offres évoluent : relisez-les avant de signer.
Les deux fournisseurs certifiés
HeroDevs : « Never-Ending Support for Drupal 7 »
HeroDevs commercialise son offre sous le nom NES (Never-Ending Support) for Drupal 7, en deux éditions :
- NES for Drupal 7, l'édition complète : support dédié par téléphone et e-mail, aide à l'installation, SLA présenté comme conforme FedRAMP, SOC 2, HIPAA et PCI, et support de sécurité PHP proposé en option ;
- NES for Drupal 7: Basic Edition : correctifs de sécurité et analyse de vulnérabilités, sans support dédié, sans aide à l'installation, sans SLA de conformité et sans volet PHP.
Le périmètre annoncé comprend le cœur et les modules contrib disponibles au moment de la fin de vie de Drupal 7. HeroDevs exclut explicitement les modules sur mesure, les modules qui s'appuient sur des API tierces et les modules fermés ou sous licence propriétaire. L'offre se présente comme un remplacement direct du cœur, sans modification du code du site. Les versions publiées suivent une numérotation dérivée de la version communautaire 7.103 (7.103.x) ; la plus récente listée dans les notes de version, au moment de la rédaction, date de septembre 2026.
Prix : non publics, sur devis. La tarification se fait par site (les environnements de développement et de préproduction d'un même site ne sont pas comptés à part).
Durée : le nom le dit, aucune date de fin n'est annoncée.
Tag1 Consulting : « Tag1 D7ES »
Tag1 propose Tag1 D7ES (Drupal 7 Extended Support). Le périmètre couvre le cœur, les modules contrib et les thèmes, avec une nuance importante : Tag1 produit des correctifs pour les projets effectivement utilisés par ses clients payants. Pour les modules contrib, la société suit la politique de l'équipe de sécurité Drupal (versions stables) et étudie les autres projets au cas par cas.
La distribution passe par un module, tag1_d7es, installé sur le site, qui remonte l'inventaire des modules ; une commande Drush est aussi disponible. Les correctifs sont d'abord livrés aux clients, puis publiés en général un mois plus tard ; pour les failles les plus critiques, Tag1 indique viser une publication simultanée.
Prix publics (en dollars US, par site et par mois) :
| Formule | Prix affiché | Contenu principal |
|---|---|---|
| Self-Service | 149,99 $ | Correctifs cœur, contrib et thèmes, à appliquer vous-même |
| Premium Support | 1 499,99 $ | Idem, plus application des correctifs par Tag1 (3 h par mois et par site selon la page de l'offre) |
| Enterprise | sur devis | Arrangements sur mesure, dont la couverture du code spécifique |
Facturation mensuelle ou annuelle, remises possibles à partir de trois sites. La formule Premium impose des prérequis : gestion de sources, sauvegardes testées, instance hors production pour tester les correctifs, cœur et modules Drupal 7 dans leur dernière version.
Durée : pas de date de fin prévue ; elle dépendra de la demande. Tag1 s'engage à prévenir ses clients au moins six mois avant un éventuel arrêt.
Et D7Security ?
Il existe aussi D7Security, une initiative communautaire gratuite hébergée sur GitLab, qui maintient une sélection de modules et de thèmes Drupal 7. Elle ne fait pas partie du programme certifié de l'Association Drupal et ne vend ni engagement de délai ni SLA. Pour un site où la sécurité doit être contractualisée, ce n'est pas un substitut à un fournisseur commercial ; pour un petit site associatif, c'est une ressource à connaître.
La vraie question : PHP
Pour un site Drupal 7 maintenu par un fournisseur, le risque le plus prévisible n'est pas une faille du cœur : c'est le jour où l'hébergeur retire la version de PHP sur laquelle il tourne.
D'après la documentation de drupal.org :
- Drupal 7 fonctionne encore avec d'anciennes versions de PHP, mais seules PHP 8.1, 8.2 et 8.3 sont recommandées ;
- le support de PHP 8.1 est arrivé avec Drupal 7.92, celui de PHP 8.2 avec la 7.94, celui de PHP 8.3 avec la 7.103 (décembre 2024) ;
- PHP 8.4 n'est pas supporté par la branche communautaire, et ne le sera pas.
Or, selon php.net, PHP 8.2 perd son support de sécurité le 31 décembre 2026 et PHP 8.3 le 31 décembre 2027. Un site Drupal 7 communautaire bloqué en 8.3 a donc au mieux un an de marge côté PHP.
Les deux fournisseurs traitent ce point différemment :
- Tag1 a publié fin 2025 une version 7.105 de son cœur, annoncée compatible PHP 8.4, tout en recommandant PHP 8.3 comme cible principale ;
- HeroDevs ne précise pas, dans ses notes de version publiques, la compatibilité de son cœur avec PHP 8.4 ; il propose en revanche, avec l'édition complète, une option de support de sécurité PHP qui permet de rester sur une version de PHP officiellement en fin de vie. Posez la question explicitement lors du devis.
Dans les deux cas, la compatibilité du cœur ne dit rien de vos modules contrib et de votre code sur mesure. Ce sont eux qu'il faut tester après un changement de version de PHP. Avant de souscrire, vérifiez au minimum :
# Drush 8 (la version compatible Drupal 7)
drush status | grep -i php
drush pm-list --type=module --status=enabled --no-core
drush pm-updatestatus
La liste des modules activés est celle que vous devrez confronter au périmètre du fournisseur. Un module contrib « exotique » ou un module sur mesure n'y figurera pas chez HeroDevs, et ne sera traité chez Tag1 que s'il est utilisé par un client ou négocié en Enterprise. Si votre site repose sur plusieurs de ces modules, le support étendu ne vous protège qu'en partie.
Ce que le support étendu ne règle pas
Le support étendu publie des correctifs. Il ne fait rien d'autre, et plusieurs sujets restent entièrement à votre charge :
- L'application des correctifs : en formule d'entrée de gamme, quelqu'un doit les appliquer, tester et déployer. Sans environnement de préproduction ni versionnement, c'est risqué.
- Le code sur mesure : sauf contrat spécifique, il reste hors périmètre.
- Les intégrations : les modules qui dialoguent avec une API externe (paiement, CRM, SSO) sont exclus chez HeroDevs et ne sont jamais garantis quand l'API distante change.
- Les compétences : les développeurs qui interviennent encore sur Drupal 7 se raréfient à mesure que l'écosystème passe aux versions récentes.
- L'écart technique : le site ne bénéficie d'aucune évolution fonctionnelle de Drupal, et la future migration ne se simplifie pas avec le temps.
Quand c'est pertinent, quand ça ne l'est pas
| Situation | Support étendu ? |
|---|---|
| Migration budgétée et planifiée, démarrage dans quelques mois | Oui, pour couvrir la période |
| Site soumis à une politique de sécurité ou à un audit (secteur public, santé, finance) | Oui, si cette politique exige un logiciel maintenu tant que le site est en ligne |
| Migration longue découpée en lots, ancien site encore en production | Oui, jusqu'à la bascule |
| Aucun projet de migration, « on verra » | Non : vous payez pour repousser le problème |
| Site très personnalisé, beaucoup de modules sur mesure ou d'intégrations | Utilité limitée, car le périmètre ne couvre pas l'essentiel du risque |
| Petit site vitrine avec peu de contenus | Souvent plus cher sur un an qu'une reconstruction |
Pour un petit site, le calcul est rapide : 150 $ par mois chez Tag1 en Self-Service, c'est environ 1 800 $ par an, sans compter le temps d'application des correctifs. Sur deux ans, ce budget représente une part significative d'une migration de site simple.
Comment l'articuler avec une migration
Le support étendu a du sens comme assurance pendant la migration, pas comme stratégie. Voici l'enchaînement que je recommande :
- Inventorier le site : modules actifs, code sur mesure, version de PHP, intégrations. C'est aussi ce qui permet de vérifier le périmètre réel du fournisseur.
- Souscrire pour une durée alignée sur le planning de migration, idéalement au mois : Tag1 affiche une facturation mensuelle résiliable à tout moment ; pour HeroDevs, les modalités sont à préciser au devis.
- Stabiliser l'existant : versionnement Git, préproduction, procédure de déploiement, pour appliquer les correctifs sans risque.
- Construire le nouveau site en Drupal 11 et écrire les migrations de données de façon rejouable, pour une dernière synchronisation juste avant la bascule. La méthode est détaillée sur la page migration Drupal 7.
- Résilier le support étendu après la mise en production et une période d'observation.
En parallèle, une TMA Drupal peut assurer l'application des correctifs, la surveillance et les sauvegardes de l'ancien site pendant toute la durée du projet.
Ce qu'il faut retenir
Les deux fournisseurs certifiés couvrent le cœur et une large partie des modules contrib, sans date de fin annoncée. Leur périmètre s'arrête au code sur mesure et, chez HeroDevs, aux intégrations tierces. La contrainte la plus pressante reste PHP : la branche communautaire s'arrête à PHP 8.3, dont le support de sécurité se termine fin 2027.
Si vous hésitez entre souscrire et migrer, commencez par l'inventaire. Un audit flash établit la liste des modules, le volume de code sur mesure et la compatibilité PHP, ce qui permet de chiffrer à la fois la migration et la durée de support étendu nécessaire pendant le projet.