Le support de Drupal 7 est terminé. Les sites qui tournent encore dessus n'ont plus de correctifs de sécurité officiels, et chaque mois qui passe augmente le risque et le coût de la bascule. Pourtant, des milliers de sites français, notamment dans le secteur public, sont encore sous Drupal 7. Voici comment j'aborde ces migrations depuis plusieurs années.
Une migration, pas une mise à jour
Premier point, celui qui surprend le plus : passer de Drupal 7 à Drupal 10 ou 11 n'est pas une mise à jour, c'est une reconstruction. L'architecture a entièrement changé entre Drupal 7 et Drupal 8 : programmation orientée objet, composants Symfony, moteur de templates Twig, gestion de configuration. Le thème est à refaire, les modules contribués ont parfois disparu ou changé de périmètre, et les modules custom sont à réécrire.
La bonne nouvelle : le contenu, lui, se migre bien. Drupal fournit des outils de migration robustes (Migrate API) qui permettent de transférer contenus, utilisateurs et taxonomies de manière fiable et rejouable.
La méthode en cinq étapes
1. L'audit
On inventorie tout : types de contenu, vocabulaires, modules contribués et custom, fonctionnalités réellement utilisées. C'est le moment de vérité : sur la plupart des sites Drupal 7, une partie significative des modules installés ne sert plus. Migrer, c'est aussi faire le tri.
2. La cartographie
Pour chaque élément de l'inventaire, on décide : migrer tel quel, remplacer par un équivalent moderne, ou abandonner. Chaque module custom est évalué : sa fonctionnalité existe-t-elle désormais dans le cœur de Drupal ou dans un module contribué maintenu ?
3. La migration des données
On écrit et on rejoue les migrations de contenu jusqu'à ce qu'elles soient parfaites. L'avantage de la Migrate API, c'est qu'on peut la relancer autant de fois que nécessaire pendant que l'ancien site reste en production.
4. Le thème et les fonctionnalités
Le thème est reconstruit en Twig, idéalement en profitant de l'occasion pour moderniser le design et intégrer l'accessibilité RGAA dès le départ plutôt qu'après coup. Les modules custom indispensables sont réécrits.
5. La recette et la bascule
Recette complète sur un environnement de préproduction, migration finale des contenus fraîchement publiés, bascule DNS, et surveillance rapprochée les premiers jours. Avec une bonne préparation, l'interruption de service se compte en minutes.
Les pièges classiques
- Sous-estimer les modules custom : c'est presque toujours là que se cache la complexité réelle du projet
- Vouloir migrer à périmètre identique : reproduire à l'identique un site de dix ans, c'est payer pour reconstruire ses défauts
- Négliger les redirections : chaque URL qui change sans redirection 301 est du référencement perdu
- Oublier les médias : la gestion des fichiers a beaucoup changé, et les bibliothèques d'images mal migrées se paient longtemps
- Reporter l'accessibilité à plus tard : l'intégrer pendant la refonte du thème coûte bien moins cher qu'un audit correctif ensuite
Combien de temps ça prend
Tout dépend du nombre de types de contenu, de modules custom et de la complexité du thème. Un site éditorial simple se migre en quelques semaines. Un site institutionnel riche, avec des dizaines de types de contenu et des fonctionnalités métier, se compte en mois. L'audit initial permet de donner un chiffrage fiable : c'est un petit investissement qui sécurise tout le reste.
Et Drupal 10 ou Drupal 11 ?
Si vous migrez aujourd'hui, visez directement la dernière version stable. L'écart entre Drupal 10 et 11 est faible, et les montées de version mineures sont désormais simples : c'est tout l'intérêt de quitter Drupal 7. Une fois sur une version moderne, les mises à jour redeviennent un non-événement, à condition d'avoir une maintenance sérieuse derrière.
J'accompagne des organisations publiques et privées sur ces migrations depuis plusieurs années, de l'audit initial à la bascule, comme sur le portail vie-publique.fr. Si votre site est encore sous Drupal 7, le bon moment pour en parler, c'était hier; le deuxième bon moment, c'est maintenant.
