Après Drupal 7 : nouveau site, migration vers Drupal 11 ou changement de CMS ?

Ce que signifie vraiment la fin de vie de Drupal 7

Drupal 7 a atteint sa fin de vie officielle le 5 janvier 2025. Concrètement, cette version ne bénéficie plus du développement standard ni des mises à jour de sécurité officielles selon le même modèle que les versions supportées de Drupal.

Le piège, c'est que le problème est invisible en surface : le site continue de s'afficher, les contributeurs publient, les formulaires envoient des messages et les visiteurs ne voient aucune différence. Le risque est sous-jacent : version de PHP obsolète, modules non maintenus, hébergement vieillissant, absence de correctifs de sécurité, et coût croissant pour trouver des profils qui maîtrisent encore Drupal 7.

La bonne question n'est donc plus « devons-nous faire quelque chose ? », mais plutôt : « que voulons-nous à la place du site actuel pour les 5 à 10 prochaines années ? ». Dans beaucoup d'organisations — secteur public, éducation, services municipaux, banques locales, entreprises avec un site historique — Drupal 7 fait encore partie du quotidien, et le sujet ne revient souvent sur la table qu'à l'occasion d'un audit de sécurité, d'exigences d'accessibilité, d'un problème d'hébergement ou d'un nouveau projet web.

Pourquoi passer de Drupal 7 à Drupal 11 n'est pas une mise à jour classique

Avec Drupal 7, le mot « migration » est souvent trompeur. Dans beaucoup de systèmes, une mise à jour consiste à monter de version, corriger quelques modules et déployer. Le passage de Drupal 7 à Drupal 11 est d'une autre nature : les deux versions diffèrent par leur architecture, la construction des modules, le theming, les prérequis d'hébergement et l'outillage développeur.

Un thème Drupal 7 doit généralement être reconstruit. Les modules custom doivent être réécrits, remplacés ou supprimés. Certaines fonctionnalités qui nécessitaient autrefois des modules contribués sont désormais intégrées au cœur de Drupal ou disponibles dans un écosystème de modules récents et matures ; d'autres modules anciens n'ont tout simplement plus de chemin de mise à niveau viable.

L'analogie la plus parlante : passer de Drupal 7 à Drupal 11, c'est déménager dans un nouveau bâtiment, pas rénover une pièce. Ce n'est pas une mauvaise nouvelle : cela permet de traiter le projet non pas comme un rafistolage de l'ancien site, mais comme la construction d'un nouveau site sur un moteur supporté, en migrant les contenus, URL, fichiers et fonctionnalités qui ont encore de la valeur.

Clarifier le vocabulaire du projet

Dans les échanges avec les parties prenantes, il est utile de distinguer plusieurs termes qui, après Drupal 7, se cumulent souvent dans un même projet :

• Mise à jour : montée de version au sein d'une architecture similaire.
• Migration : transfert des données, contenus et d'une partie de la configuration vers un nouveau système.
• Refonte graphique (redesign) : changement d'apparence et d'expérience utilisateur.
• Reconstruction (rebuild) : reconstruction du site ou de l'application sur une nouvelle architecture.
• Replatforming : changement de plateforme, par exemple de Drupal vers WordPress, un CMS headless (CMS découplé du front-end) ou un site statique.

Les exigences apparues depuis la construction des sites Drupal 7

Beaucoup de sites Drupal 7 ont été construits il y a 10 à 15 ans, à une époque où les attentes étaient plus simples : présenter de l'information, quelques formulaires, une liste d'actualités, des fichiers téléchargeables et un back-office éditorial. Aujourd'hui, le même type de site doit répondre à bien plus d'exigences :

• Accessibilité numérique et WCAG (référentiel international d'accessibilité web) : particulièrement critique pour le secteur public, les universités, les institutions et les organisations grand public.
• Consentement cookies et vie privée : bandeaux de consentement, conformité RGPD et ePrivacy pour l'analytics et le marketing.
• Mobile-first et responsive design : le site doit fonctionner réellement bien sur mobile, pas seulement « s'adapter tant bien que mal ».
• Core Web Vitals et performance : vitesse de chargement, stabilité de l'affichage, optimisation des images, cache et CDN, avec impact direct sur le SEO et l'expérience utilisateur.
• Sécurité du back-office : mots de passe renforcés, double authentification (2FA), restriction des accès administrateur, protection contre les attaques par force brute.
• SEO moderne : redirections 301, schema.org, métadonnées, structure de titres, canonicals, monitoring via Search Console.
• Analytics et conversions : GA4, GTM, mesure des formulaires et campagnes, événements, intégration CRM.
• Meilleure expérience éditoriale : médiathèque, composants, workflow de publication, versioning, modération.
• Formulaires sécurisés : validation, anti-spam, recueil des consentements, stockage sécurisé des soumissions.
• Processus DevOps : environnements de préproduction, sauvegardes, déploiement, monitoring, SSL, plan de reprise.
• Intégrations : CRM, newsletter, cartographie, paiement, systèmes internes, API, moteurs de recherche.
• Contenus opérationnels : alertes urgentes, bandeaux d'incident, statut de service.

Résultat : un nouveau site en 2026 est souvent plus complexe qu'un site de l'ère Drupal 7. Mais les outils ont aussi évolué. L'IA et les LLM (grands modèles de langage) peuvent accélérer l'analyse des contenus, les premières ébauches d'architecture de l'information, le mapping des champs de migration, la documentation et les tests de non-régression — sans supprimer la responsabilité de l'équipe, mais en raccourcissant certaines phases analytiques et de développement.

L'écosystème propose également Drupal CMS, un starter prêt à l'emploi pour les nouveaux projets : là où, à l'époque de Drupal 7, on partait souvent d'une installation nue en assemblant les modules à la main, on démarre aujourd'hui avec un socle fonctionnel plus complet, ce qui raccourcit le chemin entre la décision et un prototype opérationnel.

Le message est simple : si votre site Drupal 7 a plus de 10 ans, migrer sans revisiter les nouvelles exigences risque de simplement déplacer un vieux problème vers une nouvelle technologie.

Quand Drupal 11 ou Drupal CMS est le meilleur choix

Drupal 11 ou Drupal CMS s'impose lorsque le site est plus qu'une simple vitrine. Si l'organisation a besoin de contenus structurés, de permissions fines, de formulaires, de rôles multiples, 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 vrai pour les organisations qui ne veulent pas revivre un replatforming à court terme : un back-office Drupal bien conçu peut servir 5 à 10 ans, tandis que le front-end et la couche visuelle peuvent être rafraîchis plus souvent — tous les 2 à 5 ans par exemple — pour suivre les tendances UX, les campagnes, les besoins mobiles et l'accessibilité. Tout changement visuel n'implique pas de remplacer le CMS.

Drupal est particulièrement adapté quand vous avez besoin de :

• types de contenus et champs complexes ;
• rôles éditoriaux multiples et workflow de publication ;
• intégrations avec d'autres systèmes ;
• support multilingue et API stable ;
• modèle de permissions robuste et exigences de sécurité élevées ;
• longue durée de vie de la plateforme et capacité à évoluer vers une application ou un portail.

Ce n'est pas un hasard si Drupal équipe des banques, des gouvernements, des universités et de grandes organisations : non parce que c'est le CMS le plus simple pour tous les sites, mais parce que c'est un moteur solide pour des systèmes qui doivent rester stables, sécurisés et adaptables.

Pour des organisations de type services publics ou municipaux, un chemin raisonnable ressemble souvent à ceci : un nouveau site sur Drupal 11 ou Drupal CMS, avec migration des contenus à valeur, préservation des URL importantes, améliorations WCAG, formulaires assainis, consentement cookies et fonctionnalités opérationnelles.

Comment cadrer la décision

Avant tout chiffrage de migration ou de nouveau site, la décision gagne à être posée en termes de trajectoire à 5-10 ans plutôt que de simple mise à niveau technique. Trois grandes familles d'options se dessinent :

• Nouveau site sur Drupal 11 ou Drupal CMS : le choix le plus pérenne pour les sites complexes, avec migration sélective de l'existant.
• Migration technique à périmètre constant : envisageable lorsque le site actuel répond encore bien aux besoins et que seul le moteur doit changer.
• Replatforming vers un autre CMS ou une architecture statique : à étudier lorsque les besoins réels sont devenus plus simples que ce que Drupal apporte, ou au contraire très spécifiques.

Dans tous les cas, un audit préalable des contenus, des fonctionnalités réellement utilisées, des intégrations et des exigences réglementaires (accessibilité, RGPD) est la première étape pour comparer les options sur des bases factuelles et présenter un arbitrage clair à la direction.