Si vous exécutez toujours Drupal 7 en production, je vais être direct : vous vivez sur du temps emprunté. Drupal 7 a atteint sa fin de vie officielle le 5 janvier 2025, après plusieurs prolongations remontant à la date limite initiale de novembre 2021. Cela signifie plus de correctifs de sécurité, plus de support communautaire, et plus de possibilité de prétendre que la migration peut attendre jusqu'au trimestre prochain. J'ai accompagné plusieurs équipes d'entreprise dans cette situation exacte au cours des dernières années, et celles qui ont attendu jusqu'à la dernière minute ont toujours payé plus — en argent, en stress et en dette technique. Ce guide est tout ce que j'aurais aimé pouvoir remettre à chaque VP d'Engineering qui exécute encore Drupal 7.

Table des matières

Drupal 7 End of Life 2025: Migration Guide for Enterprise Teams

Ce que la fin de vie de Drupal 7 signifie réellement

Soyons précis sur ce que « fin de vie » signifie en pratique, car j'ai vu beaucoup de confusion à ce sujet :

  • Plus de mises à jour de sécurité. L'équipe de sécurité de Drupal n'émettra plus d'avis ou de correctifs pour le noyau Drupal 7 ou les modules contrib. Si une vulnérabilité critique d'injection SQL est découverte demain, vous êtes seul.
  • Plus de corrections de bogues. Tout ce qui est cassé reste cassé.
  • Les responsables des modules contrib s'en vont. La plupart l'ont déjà fait. De nombreux modules Drupal 7 populaires n'ont pas reçu de mise à jour depuis des années.
  • Les fournisseurs d'hébergement abandonneront le support. Pantheon, Acquia et Platform.sh ont tous annoncé des calendriers pour déprécier les environnements d'hébergement Drupal 7. Acquia a prolongé son support Drupal 7 jusqu'en 2026 pour les clients existants, mais c'est un module complémentaire payant, pas une solution à long terme.
  • Les problèmes de compatibilité PHP s'accumuleront. Drupal 7 a été construit pour PHP 5.x. Il s'exécute sur PHP 8.1 avec des correctifs, mais PHP 8.1 lui-même atteint la fin de vie en décembre 2025. Vous empilerez des logiciels non supportés sur d'autres logiciels non supportés.

Le risque de sécurité seul devrait suffire à déclencher une action. Si votre organisation traite toute forme de PII, de données financières ou d'informations de santé, exécuter un Drupal 7 sans correctifs est une responsabilité de conformité. PCI DSS, HIPAA, SOC 2 — ils exigent tous que vous mainteniez un logiciel patché et supporté.

Pourquoi les équipes d'entreprise ont continué à repousser

J'ai eu cette conversation des dizaines de fois. Les raisons sont toujours une variation de :

  1. « Notre site Drupal 7 fonctionne bien. » C'est vrai. Jusqu'à ce que ça ne soit pas le cas. Le code ne cessera pas de fonctionner le 6 janvier, mais le profil de risque change dramatiquement.
  2. « La migration vers Drupal 8/9/10 n'est pas une simple mise à niveau. » C'est en fait vrai. Contrairement au chemin de mise à niveau Drupal 6→7, passer de Drupal 7 à Drupal moderne est essentiellement une reconstruction. L'architecture est fondamentalement différente — basée sur Symfony, gestion de la configuration, modèles Twig. Vos modules personnalisés ne porteront pas.
  3. « Nous avons 15 ans de contenu et de fonctionnalités personnalisées. » Les sites Drupal 7 d'entreprise ont tendance à être fortement personnalisés. Modules personnalisés, configurations Views, structures de taxonomie complexes, intégrations aux systèmes hérités. La portée de la migration est véritablement grande.
  4. « Le budget n'a pas été approuvé. » La réponse la plus honnête et la plus courante.

Aucune de ces raisons n'a disparu, mais la date limite est arrivée. Parlons donc de ce qu'il faut réellement faire.

Vos options de migration en 2025

Vous avez quatre chemins réalistes à suivre. Chacun a des compromis. Permettez-moi de les détailler honnêtement.

Option Délai Fourchette de coûts Idéal pour Niveau de risque
Drupal 10/11 6-18 mois 200 K-1 M $+ Équipes investies dans l'écosystème Drupal Moyen
Frontend Headless + Backend Drupal 4-12 mois 150 K-600 K $ Équipes voulant une UX moderne avec un CMS familier Moyen
Migration CMS Headless 3-9 mois 100 K-500 K $ Équipes prêtes à quitter Drupal entièrement Moyen-Élevé
Fournisseur de support étendu Immédiat 30 K-100 K $/an Équipes ayant besoin de 6-18 mois de temps de planification supplémentaires Faible (court terme)

Drupal 7 End of Life 2025: Migration Guide for Enterprise Teams - architecture

Option 1 : Migrer vers Drupal 10/11

Drupal 10 est la version stable actuelle en 2025, avec Drupal 11 sortie en mid-2024 et gagnant en adoption. Si votre équipe connaît Drupal, que votre modèle de contenu est solide et que vous voulez rester dans l'écosystème, c'est le chemin le plus direct.

Mais « direct » ne signifie pas « facile ».

Ce que la migration implique réellement

Drupal fournit une API Migrate qui peut extraire du contenu d'une base de données Drupal 7 vers un site Drupal 10/11. D'après mon expérience, elle gère environ 60-70% d'une migration typique. Le reste est des plugins de migration personnalisés pour :

  • Types de champs personnalisés
  • Références d'entités complexes
  • Paragraphes (si vous avez utilisé le module Paragraphs)
  • Assets de fichiers et de médias
  • Alias d'URL et redirections
  • Comptes d'utilisateurs et rôles

Vos modules personnalisés doivent être réécrits. Pas portés — réécrits. Drupal 10/11 utilise une architecture complètement différente. Si vous aviez un module personnalisé qui s'accrochait à hook_node_view(), vous écrivez maintenant des souscripteurs d'événements et des plugins.

// Drupal 7 - basé sur les hooks
function mymodule_node_view($node, $view_mode, $langcode) {
  if ($node->type == 'article') {
    $node->content['custom_field'] = array(
      '#markup' => '<div>' . custom_logic($node) . '</div>',
      '#weight' => 10,
    );
  }
}

// Drupal 10/11 - OOP, basé sur Symfony
namespace Drupal\mymodule\EventSubscriber;

use Drupal\core_event\NodeViewEvent;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;

class NodeViewSubscriber implements EventSubscriberInterface {
  public static function getSubscribedEvents() {
    return [NodeViewEvent::class => 'onNodeView'];
  }
  
  public function onNodeView(NodeViewEvent $event) {
    $node = $event->getNode();
    if ($node->bundle() === 'article') {
      // Votre logique ici
    }
  }
}

La couche de templage Twig est également complètement différente de PHPTemplate. Chaque thème personnalisé doit être reconstruit.

Délai réaliste

Pour un site d'entreprise de taille moyenne (500-5 000 pages, 10-20 types de contenu, 5-10 modules personnalisés), comptez 9-15 mois. Cela comprend la découverte, la modélisation du contenu, le développement, la migration du contenu, l'assurance qualité et le lancement.

Option 2 : Aller Headless avec un frontend moderne

C'est là que les choses deviennent intéressantes, et honnêtement, c'est l'approche que je recommande le plus souvent pour les équipes d'entreprise en 2025. Gardez Drupal comme votre backend de contenu (mis à niveau vers Drupal 10/11), mais construisez le frontend avec un framework JavaScript moderne.

Drupal 10/11 a un excellent support JSON:API intégré au noyau. Vous pouvez exposer votre contenu en tant que données structurées et le consommer avec Next.js, Astro ou n'importe quel framework frontend.

Pourquoi cette approche fonctionne bien

  • Votre équipe éditoriale garde l'interface d'administration de Drupal. Elle la connaît. Elle est productive dedans. Enlever ça cause de la douleur organisationnelle.
  • Votre frontend devient dramatiquement plus rapide. Génération statique, mise en cache edge, optimisation d'image moderne — des choses qui sont douloureuses à boulonner à la couche de rendu de Drupal.
  • Vous pouvez migrer progressivement. Mettez en place le nouveau frontend à côté de l'ancien site et migrez les sections une à la fois.

Nous avons construit plusieurs frontends Drupal headless avec Next.js et Astro, et les améliorations de performance sont substantielles. Un client a vu son Largest Contentful Paint chuter de 4,2 s à 0,8 s après avoir migré vers un frontend Next.js avec ISR (Incremental Static Regeneration).

// Page Next.js récupérant depuis JSON:API de Drupal
export async function getStaticProps({ params }) {
  const res = await fetch(
    `${process.env.DRUPAL_BASE_URL}/jsonapi/node/article?filter[field_slug]=${params.slug}&include=field_image,field_tags`
  );
  const data = await res.json();
  
  return {
    props: {
      article: data.data[0],
      included: data.included,
    },
    revalidate: 60, // ISR : régénération tous les 60 secondes
  };
}

Le paquet next-drupal (maintenu par Chapter Three) rend cela encore plus facile avec un support intégré pour le mode aperçu, l'authentification et le mappage des types de contenu.

Le bémol

Vous devez toujours migrer Drupal 7 vers Drupal 10/11 sur le backend. Vous n'évitez pas ce travail. Mais vous découuplez la reconstruction du frontend, ce qui vous donne plus de flexibilité dans la séquençage.

Option 3 : Passer entièrement à un CMS Headless

Parfois, le bon mouvement est de quitter complètement Drupal. Si votre équipe n'a pas une forte expertise Drupal, si vous avez du mal à embaucher des développeurs Drupal (et c'est le cas — le vivier de talents Drupal s'est considérablement réduit depuis 2020), ou si votre modèle de contenu a dépassé ce que Drupal fait bien, un CMS headless pourrait être le bon choix.

Cibles de migration populaires

CMS Tarification (2025) Idéal pour Content API Courbe d'apprentissage
Contentful 300-2 500 $/mo+ Grandes équipes éditoriales GraphQL + REST Moyen
Sanity 99-949 $/mo+ (enterprise personnalisé) Équipes menées par des développeurs GROQ + GraphQL Faible-Moyen
Storyblok 109-449 $/mo+ Besoins d'édition visuelle REST + GraphQL Faible
Strapi (auto-hébergé) Gratuit (auto-hébergé) / 29 $/mo+ (cloud) Équipes voulant du contrôle REST + GraphQL Moyen
Payload CMS Gratuit (auto-hébergé) / 35 $/mo+ (cloud) Équipes orientées TypeScript REST + GraphQL Moyen

Nous travaillons avec plusieurs d'entre eux via notre pratique de développement CMS headless. Le bon choix dépend des compétences techniques de votre équipe, de la complexité du contenu et du budget.

Migration de contenu de Drupal 7 vers un CMS headless

C'est en fait plus facile que migrer vers Drupal 10/11 à certains égards. Vous n'êtes pas limité par le framework de migration de Drupal. L'approche typique :

  1. Exporter le contenu de Drupal 7 via Drush ou des requêtes de base de données directes
  2. Transformer les données dans le modèle de contenu de votre CMS cible en utilisant des scripts (Python et Node.js fonctionnent tous deux bien)
  3. Importer via l'API de gestion du CMS
  4. Vérifier et corriger les références, les médias et les relations
# Export de contenu simple de Drupal 7 via base de données
import mysql.connector
import json

db = mysql.connector.connect(
    host="localhost",
    user="drupal",
    password="yourpassword",
    database="drupal7_db"
)

cursor = db.cursor(dictionary=True)
cursor.execute("""
    SELECT n.nid, n.title, n.created, n.changed, n.status,
           fdb.body_value, fdb.body_summary
    FROM node n
    LEFT JOIN field_data_body fdb ON n.nid = fdb.entity_id
    WHERE n.type = 'article' AND n.status = 1
    ORDER BY n.created DESC
""")

articles = cursor.fetchall()

with open('articles_export.json', 'w') as f:
    json.dump(articles, f, default=str, indent=2)

print(f"Exported {len(articles)} articles")

La partie difficile n'est pas l'export. C'est de mapper le modèle de contenu de Drupal 7 (avec son système de champs, ses références d'entités, ses termes de taxonomie et ses Paragraphes) aux structures de données d'un nouveau CMS. Prévoyez que cela prenne un temps d'analyse significatif.

Option 4 : Fournisseurs de support étendu (Acheter du temps)

Si vous avez vraiment besoin de plus de temps — et parfois c'est le cas, notamment avec les cycles budgétaires et les priorités organisationnelles — les fournisseurs de support étendu peuvent maintenir votre site Drupal 7 patchié pendant que vous planifiez.

Fournisseurs clés offrant un support étendu Drupal 7

  • Tag1 Consulting — L'un des plus établis. Ils rétroportent les correctifs de sécurité et fournissent une maintenance continue. La tarification varie en fonction de la complexité du site mais attendez-vous à 30 K-80 K $/an.
  • Acquia — Offre un support Drupal 7 étendu via sa plateforme, actuellement jusqu'en 2026 pour les clients entreprise.
  • mySociety / D7 LTS Contributors — Support étendu piloté par la communauté via le programme de support étendu Drupal 7.

C'est une stratégie de transition légitime, pas une solution à long terme. Je la plafonnerais à 12-18 mois maximum. Chaque mois où vous restez sur Drupal 7 augmente votre complexité de migration à mesure que l'écart entre D7 et les plates-formes modernes s'élargit.

Planification de la migration : un cadre étape par étape

Voici le cadre que j'utilise avec chaque migration d'entreprise. Ce n'est pas glamour, mais ça marche.

Phase 1 : Audit (2-4 semaines)

  • Audit de contenu : Combien de types de contenu ? Combien de nœuds par type ? Quelle est la complexité du modèle de contenu ? Utilisez-vous des Paragraphes, Field Collections, Entity Reference ?
  • Audit des modules : Lister chaque module contrib et personnalisé. Catégorisez comme : a un équivalent D10, nécessite un remplacement personnalisé, peut être éliminé. J'utilise drush pm:list --status=enabled et je fais une référence croisée avec drupal.org.
  • Audit d'intégration : Avec quel système externe Drupal communique ? Passerelles de paiement, CRM, marketing automation, fournisseurs d'authentification unique ?
  • Baseline de trafic et de performance : Documentez les métriques de performance actuelles. Vous en aurez besoin pour la comparaison.
  • Audit des rôles d'utilisateurs : Combien de flux éditoriaux existent ? Quelles permissions sont importantes ?

Phase 2 : Décision architecturale (2-3 semaines)

Sur la base de votre audit, décidez laquelle des quatre options est la bonne. C'est une véritable décision architecturale qui devrait impliquer le leadership en ingénierie, les intervenants en contenu et celui qui contrôle le budget.

Phase 3 : Preuve de concept (3-6 semaines)

Avant de vous engager dans une migration complète, construisez une preuve de concept qui couvre :

  • 2-3 types de contenu migrés vers la nouvelle plateforme
  • Le flux de travail éditorial le plus complexe reproduit
  • Une intégration critique connectée
  • Benchmarks de performance sur la nouvelle pile

C'est là où vous découvrirez les choses que personne n'a mentionnées lors de l'audit. Il y a toujours quelque chose.

Phase 4 : Migration complète (3-12 mois)

C'est le travail réel. Priorisez sans pitié. Pas tout de Drupal 7 ne doit venir. D'après mon expérience, 20-30% du contenu et des fonctionnalités sur un site Drupal 7 d'entreprise typique peuvent être éliminés lors de la migration.

Phase 5 : Assurance qualité et lancement (2-4 semaines)

Les redirections sont critiques. Chaque URL sur votre site Drupal 7 qui a de la valeur de recherche a besoin d'une redirection 301 vers le nouveau site. Utilisez les exports des modules path_redirect et globalredirect comme point de départ, puis parcourez l'ancien site avec Screaming Frog pour construire une carte de redirection complète.

Stratégie de migration du contenu

La migration du contenu mérite sa propre section car c'est là que la plupart des migrations deviennent problématiques.

Le problème du champ body

Les champs body de Drupal 7 sont généralement un désordre de HTML. Vous trouverez des styles inline, des chemins d'images codés en dur, des iframes intégrées et occasionnellement du PHP brut (si quelqu'un a activé le module PHP filter — une vraie horreur de sécurité). Avant de migrer, vous devez décider : nettoyer ou porter le désordre ?

Ma recommandation : nettoyer. Écrivez des scripts de transformation qui :

  • Enlèvent les styles inline
  • Convertissent les balises <img> en références de médias appropriées
  • Corrigent les liens internes pour utiliser la nouvelle structure d'URL
  • Convertissent les tokens de médias WYSIWYG intégrés au nouveau format

Migration des médias

Les sites Drupal 7 gèrent les médias de façons très différentes. Certains utilisent le module Média (1.x ou 2.x), certains utilisent des champs de fichiers simples, certains utilisent des tokens de médias intégrés dans les champs body. Mappez chaque modèle de gestion des médias avant de commencer à écrire du code de migration.

Si vous passez à un CMS headless, vous devrez aussi décider où vivent les fichiers de médias. La plupart des CMS headless ont une gestion des assets intégrée, ou vous pouvez utiliser un DAM comme Cloudinary ou imgix.

Contenu multilingue

Si votre site Drupal 7 utilise i18n, entity_translation ou content_translation, la complexité de la migration double approximativement. Le système multilingue Drupal 7 était... appelons ça « créatif ». Les structures de données sont incohérentes et nécessitent un mappage soigneux.

Estimations des coûts et délais

Je vais vous donner des chiffres réels basés sur des projets auxquels j'ai participé ou dont j'ai connaissance directe.

Complexité du site Migration Drupal 10/11 Migration CMS Headless Frontend Headless + Backend Drupal
Petit (5-10 types de contenu, <1K pages, 2-3 modules personnalisés) 80 K-150 K $, 3-6 mois 60 K-120 K $, 2-4 mois 100 K-180 K $, 3-6 mois
Moyen (10-20 types de contenu, 1K-10K pages, 5-10 modules personnalisés) 200 K-500 K $, 6-12 mois 150 K-350 K $, 4-8 mois 200 K-450 K $, 5-10 mois
Large (20+ types de contenu, 10K+ pages, 10+ modules personnalisés, multilingue) 500 K-1,5 M $+, 12-24 mois 300 K-800 K $, 6-14 mois 400 K-1 M $+, 8-18 mois

Il s'agit de coûts totaux incluant la découverte, le développement, la migration, l'assurance qualité et la gestion de projet. Vos résultats varieront en fonction de la composition de l'équipe (interne vs. agence), de la localisation géographique et du nettoyage que vous faites par rapport à porter tel quel.

Vous voulez obtenir une estimation plus spécifique pour votre situation ? Nous effectuons des évaluations de migration qui vous donnent une image claire de la portée et du coût.

Erreurs courantes que j'ai vues des équipes commettre

Essayer de faire une récréation 1:1. Votre site Drupal 7 a accumulé 10+ ans de bric-à-brac. Ne migrez pas tout. Utilisez la migration comme une occasion de simplifier.

Sous-estimer l'effort de redirection. J'ai travaillé sur une migration où l'équipe a oublié les redirections jusqu'à deux semaines avant le lancement. Ils avaient 45 000 URL à mapper. Ne soyez pas cette équipe.

Ne pas impliquer les intervenants éditoriaux assez tôt. Les personnes qui utilisent le CMS quotidiennement auront des opinions fortes sur le nouveau système. Impliquez-les à la phase 1, pas à la phase 4.

Choisir une plateforme basée sur les fonctionnalités, pas sur la capacité de l'équipe. Le meilleur CMS est celui que votre équipe peut réellement maintenir. Si vous n'avez pas d'expertise Drupal, migrer vers Drupal 10/11 sans embaucher pour cela est préparer le terrain pour une répétition de cette situation dans 5 ans.

Exécuter des systèmes parallèles trop longtemps. Fixez une date de cutover difficile. Exécuter l'ancien et le nouveau en parallèle est coûteux et confus.

Sauter le gel du contenu. Pendant la dernière poussée de migration, vous avez besoin d'un gel du contenu sur l'ancien site. Prévoyez-le. Communiquez-le. Les auteurs de contenu le détestent, mais c'est nécessaire pour s'assurer que rien n'est perdu.

FAQ

Que se passe-t-il si je continue à exécuter Drupal 7 après la fin de vie ?

Votre site ne cessera pas soudainement de fonctionner. Mais vous ne recevrez aucun correctif de sécurité, ce qui signifie que toute vulnérabilité nouvellement découverte restera non patchée indéfiniment. C'est un vrai risque — les sites Drupal sont des cibles fréquentes pour les attaques automatisées. Vous ferez également face à des problèmes de compatibilité croissants à mesure que les versions PHP avancent et que les fournisseurs d'hébergement abandonnent le support des anciennes versions de PHP. Pour toute organisation ayant des exigences de conformité (PCI, HIPAA, SOC 2, RGPD), exécuter un logiciel non supporté est une violation directe.

Puis-je mettre à niveau directement de Drupal 7 vers Drupal 11 ?

Oui, l'API Migrate prend en charge la migration directe de Drupal 7 vers Drupal 10 ou 11. Vous n'avez pas besoin de passer par Drupal 8 et 9. Cependant, ce n'est pas une « mise à niveau » au sens traditionnel — c'est une reconstruction de votre site sur la nouvelle plateforme avec contenu migré. Vos thèmes, modules personnalisés et configurations ne se transfèrent pas directement.

Combien de temps prend une migration Drupal 7 typique ?

Pour un site d'entreprise de taille moyenne, prévoyez 6-12 mois du coup d'envoi au lancement. Les sites plus petits avec une fonctionnalité personnalisée limitée peuvent être réalisés en 3-4 mois. Les sites grands et complexes avec contenu multilingue, des intégrations étendues et une personnalisation lourde peuvent prendre 12-24 mois. La phase d'audit vous donnera une estimation beaucoup plus précise pour votre situation spécifique.

Vaut-il la peine de migrer vers Drupal 10/11, ou devrais-je changer de plate-forme CMS ?

Cela dépend de votre équipe et de vos besoins. Si vous avez l'expertise Drupal en interne, que votre modèle de contenu convient bien au système d'entités de Drupal, et que vous avez besoin des forces de Drupal (permissions complexes, multilingue, multi-site), alors rester dans l'écosystème a du sens. Si vous avez du mal à embaucher des développeurs Drupal, que votre site est principalement un site marketing sans flux de travail éditoriaux complexes, ou que vous voulez passer à une architecture headless, un CMS différent pourrait être un meilleur investissement.

Quelle est l'option la moins chère pour migrer hors de Drupal 7 ?

Le support étendu d'un fournisseur comme Tag1 (30 K-80 K $/an) est l'option la moins chère à court terme, mais cela ne résout pas le problème sous-jacent. Pour une migration réelle, passer à un CMS headless comme Sanity ou Storyblok avec un frontend statique tend à être le chemin le plus rentable pour les sites plus simples, commençant autour de 60 K-120 K $. Consultez notre page tarifaire pour plus de détails sur la façon dont nous structurons les projets de migration.

Mon classement SEO sera-t-il affecté par la migration ?

Cela peut l'être, mais une planification appropriée minimise l'impact. Les facteurs critiques sont : maintenir les structures d'URL (ou implémenter des redirections 301 appropriées pour chaque URL indexée), préserver les métadonnées et le balisage de données structurées, s'assurer que le nouveau site se charge au moins aussi vite que l'ancien (idéalement plus rapide) et soumettre les plans de site mis à jour à Google Search Console. J'ai vu des migrations bien exécutées entraîner des améliorations SEO grâce à une meilleure vitesse de page et à une meilleure expérience mobile. J'ai aussi vu des migrations ratées faire chuter le trafic de 50% parce que quelqu'un a oublié les redirections.

Puis-je migrer le contenu progressivement ou cela doit-il être tout à la fois ?

La migration progressive est possible et souvent préférable pour les grands sites. Avec une architecture headless, vous pouvez mettre en place le nouveau frontend et migrer les sections du site une à la fois, en utilisant des règles de proxy inverse pour router le trafic vers le bon backend. Cela réduit le risque et vous permet de valider chaque section avant de continuer. Le compromis est une complexité opérationnelle accrue pendant la période de migration.

Devrais-je considérer WordPress comme cible de migration ?

WordPress est une option viable pour les sites plus simples, mais je serais prudent pour les cas d'usage d'entreprise. Si votre site Drupal 7 a des types de contenu complexes, des permissions granulaires ou des flux de travail éditoriaux sophistiqués, WordPress semblera être un pas en arrière. Le modèle de contenu de WordPress (posts, pages et custom post types) est plus simple que le système d'entités de Drupal. Pour les équipes d'entreprise, je regarderais plus sérieusement Drupal 10/11 ou un véritable CMS headless. Cela dit, WordPress avec ACF Pro et un frontend headless peut bien fonctionner pour les sites axés sur le marketing.