Rester sur Drupal 7 : les vrais risques

Si votre site tourne encore sur Drupal 7 en 2026, vous n'êtes pas seul, et vous n'êtes pas en faute. Drupal 7 a été une excellente version : robuste, flexible et particulièrement durable. Beaucoup de sites lancés il y a dix ou douze ans fonctionnent toujours sans incident majeur. C'est précisément cette fiabilité qui explique pourquoi tant d'organisations ont repoussé la question de la migration. Le site fonctionne, les utilisateurs sont satisfaits et d'autres priorités passent devant.

Le problème n'est donc pas que votre site soit mauvais. C'est que le contexte autour de Drupal 7 a profondément changé, et qu'il continue de changer. Cet article fait le point, factuellement, sur ce que signifie aujourd'hui le maintien d'un site en production sur Drupal 7, et pourquoi la migration mérite d'entrer dans votre feuille de route, non pas dans l'urgence, mais comme un investissement structurant.

La fin du support communautaire est actée

Le point de bascule est connu et public : la communauté Drupal a mis fin au support officiel de Drupal 7 en janvier 2025. Cette date n'est pas une recommandation ni un avertissement, c'est une réalité opérationnelle. Concrètement, cela signifie que le projet Drupal ne publie plus de correctifs de sécurité pour le core Drupal 7 ni pour les modules contribués hébergés sur drupal.org.

Ce que ça change au quotidien. Tant que le support était actif, une faille découverte dans le core ou dans un module populaire était corrigée par la communauté, souvent en quelques jours, et l'équipe de sécurité publiait un avis (Security Advisory) accompagné d'un patch. Ce mécanisme s'est arrêté. Une vulnérabilité découverte aujourd'hui dans Drupal 7 ne sera pas corrigée par les canaux officiels.

Il faut le dire clairement et sans dramatiser : un site Drupal 7 ne devient pas vulnérable du jour au lendemain le 6 janvier 2025. Mais l'écart entre le risque réel et le risque couvert s'élargit mois après mois. C'est une dérive lente, pas une rupture brutale, ce qui la rend d'autant plus facile à sous-estimer.

Le support étendu existe, mais il a ses limites

La communauté a anticipé cette transition, et des prestataires proposent un support étendu (Extended Support) pour Drupal 7. Tag1 Consulting, notamment, offre un programme de Drupal 7 Extended Support qui fournit des correctifs de sécurité au-delà de la fin du support communautaire. C'est une option légitime, et pour certaines organisations elle a tout son sens comme solution de transition.

Il faut cependant en comprendre les limites avant d'en faire une stratégie de long terme.

Une couverture ciblée. Le support étendu se concentre sur le core et sur un ensemble de modules contribués les plus utilisés. Si votre site repose sur des modules de niche, peu téléchargés ou abandonnés, ils ne sont pas nécessairement couverts. Or ce sont souvent ces modules périphériques qui portent les vulnérabilités les plus discrètes.

Une logique de prolongation, pas de pérennité. L'objectif d'un programme de support étendu est de donner du temps, pas de figer indéfiniment une version obsolète. C'est un pont vers la migration, conçu comme tel. Bâtir une stratégie à cinq ans sur un support étendu revient à reporter le problème en payant pour ne pas le résoudre.

Une dépendance supplémentaire. Vous dépendez désormais d'un prestataire tiers pour votre sécurité de base, sur une version que l'écosystème global a quittée. C'est viable à court terme, fragile à long terme.

Le support étendu est donc un excellent filet pendant la planification d'une migration. Il devient un piège s'il sert d'excuse pour ne jamais la lancer.

Les failles non corrigées et la surface d'attaque

Un CMS est par nature exposé : il sert des pages publiques, gère des formulaires, traite des sessions utilisateur et expose une zone d'administration. Drupal 7 a connu au fil des années des vulnérabilités critiques, dont certaines très médiatisées, qui ont toutes été corrigées rapidement tant que le support était actif.

Le changement de paradigme est là : une faille équivalente découverte aujourd'hui ne bénéficie plus de ce réflexe communautaire. Au-delà du core, le risque se loge dans l'ensemble de la stack qui entoure Drupal 7, à commencer par les versions de PHP. Drupal 7 a été conçu pour des versions de PHP qui ne reçoivent elles-mêmes plus de correctifs de sécurité. Faire tourner Drupal 7 sur une version de PHP récente est techniquement délicat et n'est pas garanti. Vous vous retrouvez donc souvent avec un empilement de composants (PHP, bibliothèques, modules) dont aucun n'est plus activement maintenu.

La bonne approche n'est pas la panique, c'est la lucidité. Tant que votre site est sur Drupal 7, une maintenance Drupal rigoureuse (durcissement du serveur, pare-feu applicatif, surveillance, sauvegardes testées) réduit significativement l'exposition. C'est une mesure de protection pendant la transition, à condition de la considérer comme transitoire et non comme une fin en soi.

L'érosion du pool de développeurs

Voici un risque souvent sous-estimé parce qu'il ne se mesure pas dans un scan de sécurité : la disponibilité des compétences. Les développeurs Drupal qualifiés se forment et travaillent désormais sur Drupal 10 et Drupal 11. L'écosystème, les conférences, les formations, la documentation récente, tout converge vers les versions modernes basées sur Symfony.

Ce que ça implique pour vous. Trouver un développeur capable d'intervenir efficacement sur Drupal 7 devient progressivement plus difficile, et cette tendance ne fera que s'accentuer. Les profils qui maîtrisent l'architecture spécifique de Drupal 7 (hooks procéduraux, système de thème PHPTemplate, API d'une époque antérieure à Symfony) sont de moins en moins nombreux à vouloir y rester. Les nouveaux arrivants dans l'écosystème, eux, n'apprennent tout simplement plus Drupal 7.

Le résultat est mécanique : sur un marché où la compétence se raréfie, l'intervention sur votre site demande davantage de temps de recherche, davantage d'effort d'adaptation et une connaissance qui ne se renouvelle plus. La question n'est pas seulement de sécurité, elle est aussi de continuité opérationnelle : qui interviendra sur votre site dans trois ans, et dans quelles conditions ?

Le coût croissant d'une stack obsolète

L'argument financier est souvent celui qui retient la décision : migrer représente un coût, alors que rester ne coûte rien de plus. Cette lecture mérite d'être nuancée, car le maintien d'une stack obsolète génère un coût réel, simplement diffus et croissant.

La maintenance devient plus lourde. Chaque intervention sur un environnement non maintenu (modules figés, PHP ancien, dépendances gelées) demande plus de précautions et plus de temps. Ce qui prendrait une heure sur une stack moderne en prend davantage sur une stack qu'on ne peut plus mettre à jour sans tout risquer de casser.

Les compromis s'accumulent. Impossibilité d'utiliser des outils modernes, hébergeurs qui imposent des versions de PHP incompatibles, intégrations tierces qui cessent de supporter les anciennes API : chaque nouvelle contrainte de l'écosystème se traduit par un contournement à concevoir et à maintenir.

La dette technique se capitalise. Plus on attend, plus l'écart entre Drupal 7 et la version cible se creuse, et plus la migration future demande d'analyse. À l'inverse, le coût d'une migration aujourd'hui est connu et maîtrisable. Le coût de l'inaction, lui, augmente de façon continue.

Autrement dit, l'argument "rester ne coûte rien" est comptablement séduisant et techniquement faux. Le coût existe, il est juste réparti dans le temps et invisible sur une facture.

"Ça fonctionne" : confrontons cet argument

L'objection la plus fréquente, et la plus légitime en apparence, est simple : "notre site fonctionne très bien, pourquoi changer ?" C'est vrai, et c'est le crédit qu'il faut accorder à Drupal 7. Mais "ça fonctionne" décrit l'état présent, pas la trajectoire.

Un site qui fonctionne sur une plateforme dont le support a pris fin, dont les compétences se raréfient et dont la stack technique ne peut plus évoluer, fonctionne sur du temps emprunté. Tout va bien jusqu'au jour où un incident survient : une faille exploitée, un hébergeur qui force une montée de PHP, une intégration tierce qui se coupe. Le jour où "ça fonctionne" devient "ça ne fonctionne plus", vous découvrez en situation d'urgence ce que vous auriez pu planifier sereinement.

La bonne décision n'est donc pas de réagir à un incident, c'est de choisir le moment de la migration plutôt que de le subir. C'est exactement la différence entre un investissement maîtrisé et une dépense d'urgence.

La migration est un investissement gérable

Voici la partie positive, et c'est la plus importante : migrer depuis Drupal 7 est aujourd'hui une opération bien balisée. L'écosystème a énormément investi dans les outils de migration Drupal, et le chemin de Drupal 7 vers Drupal 10 ou 11 est éprouvé sur des milliers de projets.

Ce n'est pas une réécriture à l'aveugle. Le Migrate API, intégré au core des versions modernes, permet de transférer contenus, utilisateurs, taxonomies et configurations de façon structurée et répétable. On migre, on valide, on ajuste, on rejoue, jusqu'à ce que le résultat soit conforme. Le processus est itératif et contrôlé.

C'est l'occasion de remettre à plat. Une migration n'est pas qu'un déménagement technique. C'est le moment idéal pour retirer les modules devenus inutiles, repenser une architecture de contenu qui a vieilli et repartir sur des fondations sur lesquelles vous bâtirez sereinement pendant les dix prochaines années.

Le résultat est durable. Drupal moderne s'appuie sur Symfony, sur Composer et sur un cycle de versions prévisible. Une fois sur Drupal 10 ou 11, les montées de version suivantes sont incrémentales et beaucoup moins lourdes que le saut depuis Drupal 7. Vous sortez définitivement de la logique de migration de rupture.

La migration mérite d'être vue pour ce qu'elle est : un investissement qui sécurise votre présence en ligne, réduit votre coût de maintenance à terme et vous redonne accès à un écosystème actif. Ce n'est ni une urgence à traiter dans la panique ni une dépense à fonds perdu, c'est une décision de gestion à planifier au bon moment, avec les bonnes compétences.

Chez Noyau, on accompagne ce type de transition au quotidien, en travaillant aussi bien directement avec les équipes internes qu'en complément des prestataires déjà en place. La première étape est rarement technique : c'est un diagnostic clair de votre existant et un plan de migration adapté à vos contraintes.

Votre site est encore sur Drupal 7 et vous voulez y voir clair sur vos options ? Parlons de votre projet : on vous propose un diagnostic et une feuille de route concrète, sans engagement.