Title: Que faire après Drupal 7 : nouveau site, migration vers Drupal 11 ou autre CMS ?

Que faire après Drupal 7 reste une question d’actualité en 2026. Le support officiel de Drupal 7 s’est terminé le 5 janvier 2025, mais de nombreux sites tournent encore sur cette version. La décision n’est plus une simple mise à jour de CMS. Il s’agit souvent de choisir une plateforme, un modèle de contenu et la façon dont le site sera maintenu dans les années à venir.

Dans cet article :

• Que signifie vraiment la fin de vie de Drupal 7 ?
• Pourquoi une migration Drupal 7 vers Drupal 11 n’est pas une mise à jour normale ?
• Quelles exigences sont apparues après de nombreux sites Drupal 7 ?
• Quand Drupal 11 ou Drupal CMS est-il le meilleur choix ?
• Quand une migration technique 1:1 suffit-elle ?
• Quand envisager un autre CMS ?
• Astro ou un générateur de site statique peut-il remplacer un CMS ?
• Peut-on rester encore un peu sur Drupal 7 ?
• Que préparer avant un devis de migration ou de nouveau site ?
• Comment présenter les options à la direction ?
• Quelle est la meilleure décision après Drupal 7 ?

Que signifie vraiment la fin de vie de Drupal 7 ?

Drupal 7 a atteint sa fin de vie officielle le 5 janvier 2025. Cela signifie que cette version n’est plus développée selon le modèle standard et ne reçoit plus de mises à jour de sécurité officielles comme les versions Drupal supportées.

En pratique, le problème dépasse une date au calendrier. Le site peut encore charger, les rédacteurs peuvent publier des actualités, les formulaires peuvent envoyer des messages, et les visiteurs ne voient souvent aucune différence. Le risque se situe en dessous : ancien PHP, modules non supportés, hébergement dépassé, absence de mises à jour de sécurité, et coût croissant pour trouver des personnes qui connaissent encore bien Drupal 7.

La question n’est donc plus seulement : « Faut-il faire quelque chose ? » Une question plus utile est : « Que voulons-nous à la place du site actuel pour les 5 à 10 prochaines années ? »

Dans beaucoup d’organisations - surtout dans le secteur public, l’éducation, les services municipaux, les banques locales et les entreprises avec un site de longue date - Drupal 7 fait encore partie du travail quotidien. Ce n’est pas un sujet historique. C’est une décision réelle, qui revient souvent seulement lorsqu’un audit de sécurité, des exigences WCAG, un problème d’hébergement ou un projet de nouveau site arrivent sur la table.

Lire aussi : comment se préparer à la fin de vie de Drupal 7

Pourquoi une migration Drupal 7 vers Drupal 11 n’est pas une mise à jour normale ?

Avec Drupal 7, le mot « migration » est souvent trompeur. Dans beaucoup de systèmes, une mise à jour signifie monter de version, ajuster quelques modules et déployer. Passer de Drupal 7 à Drupal 11 est autre chose.

Drupal 7 et Drupal 11 diffèrent par l’architecture, la construction des modules, le thème, les exigences d’hébergement et les outils de développement. Un thème Drupal 7 doit généralement être reconstruit. Les modules custom doivent être réécrits, remplacés ou retirés. Certaines fonctions qui exigeaient autrefois des modules contrib sont aujourd’hui dans le core ou dans un écosystème de modules plus mature. Certains anciens modules n’ont plus de chemin de mise à niveau raisonnable.

L’analogie la plus simple : passer de Drupal 7 à Drupal 11 ressemble plus à un déménagement dans un nouvel immeuble qu’à la rénovation d’une pièce.

Ce n’est pas une mauvaise nouvelle. Cela signifie que vous pouvez traiter le projet non comme « le patch d’un vieux site », mais comme la construction d’un nouveau site sur un moteur supporté - avec migration du contenu, des URLs, des fichiers et des fonctions qui ont encore de la valeur.

Dans les discussions clients, il aide de séparer quelques termes :

• Mise à jour : monter de version dans une architecture similaire.
• Migration : transférer données, contenu et une partie de la configuration vers un nouveau système.
• Redesign : changer le look et l’expérience utilisateur.
• Rebuild : reconstruire le site ou l’application sur une nouvelle architecture.
• Replatforming : changer de plateforme, par exemple de Drupal vers WordPress, un CMS headless ou un setup statique.

Après Drupal 7, un projet combine souvent plusieurs de ces éléments à la fois.

Lire aussi : Drupal 7 vs Drupal 11 - comment le système et ses fonctionnalités ont changé

Sur des plateformes plus anciennes, la décision suivante est souvent de reconstruire ou de mettre à jour. Consultez nos services de préparation et mise à jour Drupal 10/11 pour planifier les transitions depuis Drupal 8, 9 et 10.

Quelles exigences sont apparues après de nombreux sites Drupal 7 ?

Beaucoup de sites Drupal 7 ont été construits il y a 10 à 15 ans. Les attentes envers un site étaient souvent plus simples : présenter des informations, quelques formulaires, une liste d’actualités, des fichiers à télécharger et un panneau éditorial. Aujourd’hui, le même type de site doit répondre à bien plus d’exigences.

Les nouvelles exigences les plus fréquentes sont :

• Accessibilité numérique et WCAG - particulièrement importantes pour le secteur public, les universités, les institutions, les entreprises municipales et les organisations qui servent un large public.
• Consentement cookies et vie privée - bannière cookies, consentements analytics et marketing, alignement RGPD et ePrivacy.
• Mobile-first et design responsive - le site doit bien fonctionner sur téléphone, pas seulement « s’étirer un peu ».
• Core Web Vitals et performance - vitesse de chargement, stabilité du layout, optimisation des images, cache et CDN influencent le SEO et l’expérience utilisateur.
• Sécurité de l’admin CMS - mots de passe plus forts, 2FA, accès admin restreint, captcha et protection contre le brute force.
• Exigences SEO actuelles - redirections 301, schema.org, métadonnées, structure des titres, indexabilité, canonicals et suivi Search Console.
• Analytics et conversions - GA4, GTM, mesure des formulaires et campagnes, événements et intégration CRM.
• Meilleure UX éditoriale - bibliothèque médias, composants, workflow de publication, versioning, modération et travail quotidien plus simple pour les rédacteurs.
• Formulaires plus sûrs - validation, anti-spam, consentements, notifications et stockage sûr des soumissions.
• Processus DevOps - staging, sauvegardes, déploiement, monitoring, SSL, logs et plan de reprise.
• Intégrations - CRM, newsletter, cartes, paiements, systèmes internes, API, recherche, outils de profil de confiance ou autres systèmes métier.
• Contenu opérationnel - avis urgents, barre d’incident, statut des services, alertes pour les citoyens ou clients.

Tout cela rend un nouveau site en 2026 souvent plus complexe qu’un site de l’époque Drupal 7. En même temps, nous avons aujourd’hui des outils qui n’existaient pas alors.

L’IA et les LLM peuvent accélérer l’analyse de contenu, les premières versions d’architecture d’information, le mapping des champs de migration, la documentation, la QA, les tests de régression et les prototypes. Ils ne retirent pas la responsabilité de l’équipe, mais raccourcissent une partie du travail analytique et de développement.

Dans l’écosystème Drupal, il y a aussi Drupal CMS - un starter prêt pour les nouveaux projets. À l’époque Drupal 7, on partait souvent d’une installation nue et on assemblait les modules à la main. Aujourd’hui, vous pouvez démarrer avec un jeu de fonctions plus complet, ce qui ouvre plus d’options pour construire un nouveau site et peut raccourcir le chemin de la décision au prototype fonctionnel.

La conclusion est simple : si votre site D7 actuel a 10+ ans, migrer sans revoir les nouvelles exigences peut seulement déplacer un vieux problème dans une nouvelle technologie.

Quand Drupal 11 ou Drupal CMS est-il le meilleur choix ?

Drupal 11 ou Drupal CMS a le plus de sens lorsque le site est plus qu’une simple brochure. Si l’organisation a besoin de structure de contenu, de permissions, de formulaires, de plusieurs rôles, de sécurité, de workflow éditorial, de multilinguisme, d’intégrations et de croissance à long terme, Drupal reste un choix solide.

C’est particulièrement important pour les organisations qui ne veulent pas un autre replatforming bientôt. Un backend Drupal bien conçu peut servir 5 à 10 ans. Le frontend et la couche visuelle peuvent être rafraîchis plus souvent - par exemple tous les 2 à 5 ans - pour suivre les tendances UX, les campagnes, le mobile et l’accessibilité. Chaque changement visuel n’oblige pas à remplacer tout le CMS.

Drupal convient particulièrement bien lorsque vous avez besoin de :

• types de contenu et champs complexes,
• plusieurs rôles éditoriaux,
• workflow de publication,
• intégrations avec d’autres systèmes,
• multilinguisme,
• une API stable,
• un modèle de permissions fort,
• des exigences de sécurité élevées,
• un long cycle de vie de plateforme,
• de la marge pour faire évoluer le site en application ou portail.

Ce n’est pas un hasard si Drupal est utilisé par des banques, des gouvernements, des universités, des institutions publiques et de grandes organisations. Pas parce que c’est le CMS le plus simple pour chaque site, mais parce que c’est un moteur solide pour des systèmes qui doivent rester stables, sûrs et adaptables.

Pour des organisations proches des services municipaux, un chemin raisonnable ressemble souvent à ceci : nouveau site sur Drupal 11 ou Drupal CMS, migration du contenu utile, conservation des URLs importantes, améliorations WCAG, formulaires plus clairs, consentement cookies et fonctions opérationnelles comme une barre d’incident.

Quand une migration technique 1:1 suffit-elle ?

Toutes les organisations n’ont pas besoin d’un redesign complet. Parfois l’objectif est surtout de déplacer le site en sécurité de Drupal 7 vers une version supportée, avec un minimum de changements visuels.

Cette option a du sens lorsque :

• le budget est limité,
• le look actuel est acceptable,
• le site a des fonctions précises à conserver,
• l’équipe veut surtout éliminer le risque EOL,
• le projet doit être rapide et aussi prévisible que possible,
• il n’y a pas besoin de concevoir une nouvelle UX.

En pratique, même ce chemin n’est pas « un clic de mise à jour ». Il faut quand même convenir des fonctions à migrer, du contenu à garder, des modules à remplacer et des éléments qu’il ne vaut plus la peine de recréer.

Une migration technique 1:1 peut être un bon pont lorsqu’une organisation veut réduire le risque mais n’est pas encore prête pour un projet de nouveau site complet. Dites clairement que les sujets UX, contenu et design restent alors pour plus tard.

Quand envisager un autre CMS ?

Drupal n’est pas forcément la meilleure réponse pour chaque site après Drupal 7. Parfois le site actuel a été construit sur Drupal parce que c’était un bon choix à l’époque, mais les besoins d’aujourd’hui sont beaucoup plus simples.

Si vous choisissez encore votre plateforme, consultez notre comparatif de 12 systèmes de gestion de contenu avant de trancher entre builder simple, outil headless et Drupal.

Si le site a peu de types de contenu, des mises à jour rares, un panneau éditorial simple, peu de rôles complexes et peu d’intégrations, il vaut la peine de comparer Drupal à d’autres systèmes.

Exemples d’options :

• WordPress - grand écosystème, admin simple, beaucoup de prestataires, bon pour des sites marketing et contenus plus simples.
• Craft CMS - CMS centré contenu avec un modèle de contenu solide.
• TYPO3 - fort en DACH, enterprise et une partie du secteur public.
• Joomla - CMS full-stack classique pour des sites plus simples et des équipes avec un savoir-faire existant.
• Wagtail - CMS Python/Django intéressant pour les équipes compétentes en Python.
• Umbraco - option pour les organisations dans l’écosystème .NET et Microsoft.
• Strapi, Directus, Payload - options headless/API-first lorsque le frontend est une application séparée.
• Ghost - système pour la publication, les newsletters et des sites de contenu plus simples.

Il est aussi utile d’utiliser une comparaison comme CMS Battle, qui compare 15 plateformes CMS, 110 fonctions et 24 catégories. Ce type de matériel fait passer la conversation de « quel CMS aimons-nous ? » à « quel CMS correspond le mieux à nos exigences ? »

Changer de CMS ne supprime pas le travail de migration. Il faut toujours transférer contenu, fichiers, médias, formulaires, URLs, métadonnées, analytics et logique éditoriale. Si l’ancien site a une histoire Google, les redirections 301 et la continuité SEO sont obligatoires, quelle que soit la technologie.

Astro ou un générateur de site statique peut-il remplacer un CMS ?

Un site statique ou hybride - par exemple sur Astro, Next.js, Hugo ou Eleventy - est de plus en plus discuté comme alternative à un CMS classique. Cette approche peut accélérer la livraison et simplifier la maintenance.

Les avantages sont concrets : forte performance, surface d’attaque plus petite, hébergement plus simple, moins de backend, scaling moins cher et bons Core Web Vitals. Pour des sites surtout informatifs et rarement mis à jour, cela peut être une direction très pertinente.

Il y a un vrai trade-off. Créer du contenu dans ce modèle est souvent moins confortable que dans un CMS classique. Un rédacteur peut travailler avec des fichiers Markdown ou MDX, des pull requests, GitHub, GitLab, ou avec l’aide d’une personne technique. Pour une équipe de développement, cela peut paraître rapide et clair. Pour une rédaction qui a travaillé pendant des années dans un panneau CMS, cela peut être un frein.

Vous pouvez l’atténuer avec un CMS headless ou une couche éditoriale comme Tina, Decap, Sanity ou Contentful. Les rédacteurs obtiennent une interface plus confortable, tandis que le frontend reste rapide et moderne. Mais une partie de la complexité que le site statique devait supprimer revient alors.

Astro et des outils similaires méritent donc d’être examinés - mais pas comme réponse par défaut à chaque problème Drupal 7. Vérifiez d’abord qui met à jour le contenu, à quelle fréquence, à quoi ressemble le processus d’approbation, et si l’organisation accepte un workflow de contenu basé sur Git.

Peut-on rester encore un peu sur Drupal 7 ?

Parfois l’organisation n’a pas le budget, la décision de direction ou le temps pour une migration immédiate. Vous pouvez alors préparer un plan par étapes. Ne le confondez pas avec la stratégie cible.

Un plan minimal devrait inclure :

• une copie actuelle des fichiers et de la base de données,
• un test de restauration depuis la sauvegarde,
• une revue de sécurité,
• un accès restreint au panneau d’administration,
• une vérification de la version PHP et de l’hébergement,
• une liste des modules et formulaires critiques,
• un monitoring de disponibilité,
• un plan d’incident,
• une date limite pour la décision de migration ou de replatforming.

Vous pouvez aussi envisager un support étendu pour Drupal 7 si l’organisation a besoin de temps. Un exemple est D7Security, une initiative non officielle indépendante de Drupal.org, qui fournit un support étendu pour certains modules et thèmes Drupal 7 et publie de nouvelles versions pour des projets qui ne peuvent plus revenir au support sur Drupal.org.

Cela peut être un pont de sécurité pratique pour les organisations qui ne sont pas prêtes à migrer tout de suite. Il ne faut pas le traiter comme stratégie de destination. D7Security, un support legacy payant ou d’autres options de type LTS achètent du temps - ils ne répondent pas à la question de savoir quelle plateforme doit faire tourner le site dans les années suivantes.

La pire option est de laisser Drupal 7 sans plan, sans sauvegarde, sans responsable et sans date de décision. Alors le risque grandit en silence.

Que préparer avant un devis de migration ou de nouveau site ?

Sans données de base, chaque devis est une estimation à l’aveugle. Avant de parler à un prestataire, préparez un court dossier d’information.

Les points les plus importants sont :

• l’URL du site actuel,
• la confirmation qu’il s’agit de Drupal 7,
• une copie des fichiers et de la base de données,
• une liste des principaux types de contenu,
• une liste des formulaires,
• une liste des intégrations,
• les informations de langues,
• le nombre de rédacteurs et de rôles,
• les exigences WCAG, confidentialité et cookies,
• le contenu à conserver,
• le contenu à retirer,
• les URLs organiques les plus importantes,
• des exemples visuels qui vous plaisent,
• un budget indicatif,
• la fenêtre de lancement attendue.

Pour les sites plus anciens, un court audit est un très bon premier pas. Ce n’est pas nécessairement un gros document. Souvent, une analyse concise suffit : ce que vous avez, ce qui vaut la peine d’être déplacé, ce qui peut partir, où sont les risques et quelles options sont réalistes.

Lire aussi : mise à niveau de version Drupal vs. migration - préparation, étapes et défis courants

Comment présenter les options à la direction ?

La direction n’a généralement pas besoin d’une liste complète de modules. Elle a besoin d’une décision, du risque, du coût, du calendrier et des conséquences. Au lieu d’une seule réponse - « la migration coûte X » - montrez plusieurs options.

Un tableau de ce type aide à séparer la conversation technologique de la conversation sur l’objectif. L’objectif n’est pas « avoir Drupal 11 ». L’objectif est un site sûr, utilisable, accessible et maintenable, adapté aux besoins réels de l’organisation.

Si une reconstruction est déjà sur la table, confrontez d’abord la décision à une modernisation CMS par phases plutôt qu’à un big bang - plutôt que de tout reconstruire d’un coup.

Quelle est la meilleure décision après Drupal 7 ?

Il n’y a pas de réponse unique pour tout le monde. Chaque organisation doit décider selon ses propres exigences : taille du site, nombre de rédacteurs, besoins WCAG, budget, sécurité, SEO, intégrations, fréquence de publication et plans de croissance.

Pour un site marketing simple, WordPress, Astro ou un autre système plus léger peut convenir. Pour un site de publication, Ghost peut suffire. Pour une équipe .NET, Umbraco peut avoir du sens. Pour une approche API-first, Strapi, Directus ou Payload peuvent convenir.

Si l’organisation a besoin d’un backend stable, d’un modèle de contenu avancé, de permissions, de formulaires, de workflow, de multilinguisme, d’intégrations et de sécurité, Drupal 11 ou Drupal CMS est une direction solide. Cela donne une chance de construire une plateforme que vous n’aurez pas besoin de remplacer bientôt.

C’est particulièrement important après l’expérience Drupal 7. Si vous construisez aujourd’hui un nouveau site sur un backend stable, vous pouvez rafraîchir le frontend, le design, les composants et les campagnes pendant des années sans remplacer tout le moteur. Le backend peut rester ; la couche visuelle peut mûrir avec l’organisation.

C’est pourquoi Drupal est choisi par des banques, des gouvernements, des universités et de grandes institutions. Pas parce que c’est le choix le plus simple pour chaque petit site, mais parce qu’il est solide, sûr, adaptable et éprouvé là où la stabilité compte.

Besoin d’une décision claire pour votre site Drupal 7 ?

Si votre site tourne encore sur Drupal 7, ne commencez pas par « combien coûte la migration ? » Commencez par une courte analyse : ce qui vaut la peine d’être gardé, ce qu’il faut retirer, ce qu’il faut reconstruire, et quel système convient le mieux aux années suivantes.

Nous pouvons aider à préparer cette analyse et comparer des options réelles : migration technique, nouveau site sur Drupal 11 ou Drupal CMS, changement de CMS, approche Astro/statique, ou plan par étapes. Visitez nos services de migration Drupal pour voir comment nous accompagnons les projets Drupal 7.