La migration Drupal fait partie de ces projets qui restent confortablement dans le plan du trimestre suivant jusqu’à ce qu’une date les rende urgents. Deux dates jouent ce rôle en ce moment, et une seule est encore à venir.

Drupal 7 a perdu son support officiel le 5 janvier 2025. Tout site qui l’exécute encore tourne sans couverture de sécurité depuis plus d’un an. Drupal 10 atteint sa fin de vie le 9 décembre 2026, la semaine même où sort Drupal 12, après quoi il ne recevra plus aucune publication. Si vous êtes sur l’une de ces versions, la question n’est plus de savoir s’il faut bouger, mais quel chemin prendre et ce qu’il coûtera.

Où vous en êtes : de Drupal 10 vers Drupal 11, c’est une vraie mise à niveau, le même site mis à jour sur place, en général deux à six semaines. De Drupal 7 vers Drupal 11, ce n’est pas du tout une mise à niveau ; c’est une reconstruction avec une migration de contenu attachée, et cela prend en général trois à six mois. Confondre les deux est l’erreur la plus coûteuse du domaine, parce que les sites Drupal 7 sont chiffrés comme des mises à niveau puis dérapent d’un facteur quatre.

Deux migrations très différentes

Le mot migration recouvre deux travaux qui ne partagent presque rien au-delà du nom.

De Drupal 10 à 11, c’est une mise à niveau. L’architecture est la même. Vos entités, champs, vues et configuration passent. Le travail relève surtout de la gestion des dépendances : s’assurer que chaque module contribué dispose d’une version compatible Drupal 11, purger les appels d’API dépréciés de votre code sur mesure, et passer à une version de PHP supportée. C’est méthodique plutôt que difficile, et un site bien entretenu se traite en une quinzaine de jours.

De Drupal 7 à Drupal 11, c’est une reconstruction. Drupal 8 a réécrit la plateforme sur des composants Symfony, remplaçant l’API des modules, la couche de thèmes et le système de configuration. Rien ne passe automatiquement sauf le contenu, et encore par un processus de migration dédié plutôt qu’un script de mise à niveau. Vos modules n’existent plus, votre thème doit être réécrit en Twig, et votre code sur mesure doit être réimplémenté sur une architecture différente.

Ce second cas explique pourquoi les sites Drupal 7 se sont attardés si longtemps. La formulation honnête, c’est que vous ne mettez pas un site à niveau, vous en construisez un nouveau et vous emportez le contenu.

Ce que coûte chaque chemin de migration Drupal

Les chiffres ci-dessous supposent des tarifs d’agence britannique et un site de complexité modérée. La complexité désigne ici le nombre de types de contenu, de modules contribués et de modules sur mesure, pas le nombre de pages.

Drupal 10 vers 11, site bien entretenu. Deux à quatre semaines, environ 6 000 à 15 000 livres. C’est le cas heureux : les modules sont à jour, le code sur mesure est réduit, et l’essentiel du travail est le test.

Drupal 10 vers 11, site négligé. Quatre à huit semaines, environ 15 000 à 35 000 livres. Ici les blocages sont des modules contribués sans version Drupal 11, du code écrit contre des API depuis supprimées, et une version de PHP qui doit également bouger. Chaque module abandonné devient une décision : trouver un remplaçant, en reprendre la maintenance, ou réimplémenter son comportement.

Drupal 7 vers Drupal 11. Trois à six mois, couramment 40 000 à 120 000 livres, et davantage pour les sites volumineux ou fortement personnalisés. La fourchette est large parce qu’il s’agit en réalité d’un budget de reconstruction. La migration de contenu est souvent la plus petite moitié ; le thème, les fonctionnalités sur mesure et les intégrations forment la plus grande.

Drupal 7 vers une autre plateforme. Parfois la bonne réponse. Si la raison initiale du choix de Drupal ne s’applique plus, le site étant devenu un site vitrine avec un blog, alors partir vers quelque chose de plus simple peut coûter moins qu’une migration interne à Drupal et réduire les coûts de fonctionnement ensuite. Notre comparaison entre WordPress et le développement sur mesure situe cette limite, et le guide du développement web Drupal dit honnêtement quand Drupal n’est pas la réponse.

Pourquoi les modules contribués décident de votre calendrier

Presque toute estimation de mise à niveau Drupal se joue sur l’audit des modules contribués, et c’est la première chose à faire.

Listez chaque module contribué utilisé par le site, puis vérifiez pour chacun l’existence d’une version stable compatible avec votre version cible. Ce que vous trouverez se répartit en quatre groupes. Certains ont une version compatible et ne demandent rien. Certains ont une version candidate ou un correctif dans la file des tickets que vous pouvez appliquer via Composer. Certains ont été abandonnés, et il faut trouver un remplaçant, adopter le module vous-même, ou remplacer sa fonction par du code sur mesure. Et certains ont été absorbés dans le cœur de Drupal, ce qui est la bonne surprise de l’exercice.

Cet audit transforme un projet vague en projet chiffrable. Tant qu’il n’est pas fait, tout devis est une conjecture, et un prestataire qui vous donne un prix ferme sans l’avoir mené soit gonfle largement, soit s’apprête à multiplier les avenants.

La même logique vaut pour les modules sur mesure, avec un autre outil. L’outillage de dépréciation de Drupal analyse le code sur mesure et signale les appels à des API supprimées ou vouées à l’être, ce qui transforme « nous avons du code sur mesure » en une liste précise de fichiers et de numéros de ligne.

Ce qui se passe mal en pratique

Certains modes de défaillance reviennent dans presque toutes les migrations Drupal.

La dérive de configuration entre environnements. Si des changements ont été faits directement dans l’administration de production plutôt qu’exportés vers des fichiers de configuration, votre préproduction n’est pas une copie fidèle et vos tests valent moins que vous ne le croyez. Le découvrir en cours de migration est fréquent et coûte toujours du temps.

Un contenu jamais aussi structuré que tout le monde le croyait. Les sites Drupal 7 ont fréquemment accumulé du contenu de façons que personne n’a documentées : des champs détournés pour autre chose, un vocabulaire de taxonomie jouant le rôle d’un état de workflow, du HTML collé dans des champs de corps avec des styles en ligne. Une migration fait tout remonter d’un coup, et chaque cas demande une décision de quelqu’un qui sait à quoi sert le contenu.

La gestion des médias et des fichiers. La gestion des médias dans Drupal a beaucoup changé après Drupal 7. Fichiers, styles d’images et médias intégrés se correspondent rarement un pour un, et les sites dotés de grandes médiathèques doivent budgéter ce poste spécifiquement plutôt que de le supposer inclus.

La continuité des URL et du référencement. C’est le point qui abîme l’activité plutôt que le calendrier. Si les alias d’URL changent sans redirections, vous perdez le positionnement gagné par l’ancien site. Toute migration exige un inventaire complet des URL, une table de redirections et une vérification après lancement. Notre guide sur la migration d’un site sans perdre de trafic détaille ce processus, et il s’applique aux changements de plateforme autant qu’aux changements de domaine.

Le contenu multilingue. Si le site fonctionne en plusieurs langues, attendez-vous à une migration nettement plus longue. La gestion des langues a été reconstruite après Drupal 7, et le contenu traduit, la configuration traduite et les schémas d’URL par langue réclament chacun leur attention.

Comment ordonner le travail

L’ordre compte plus que la plupart des équipes ne l’imaginent, et se tromper provoque des reprises.

Commencez par l’audit des modules contribués et du code sur mesure, avant toute estimation. Puis amenez le site sur une version de PHP supportée et sur la dernière publication de sa version majeure actuelle, car cela retire toute une catégorie de bruit de la mise à niveau proprement dite. Ensuite seulement, tentez le passage de version majeure.

Construisez le nouvel environnement à côté de l’ancien plutôt que de mettre à niveau sur place. Cela vous donne un endroit où répéter la migration de contenu, ce dont vous aurez besoin, car les migrations sont exécutées de nombreuses fois avant d’être exécutées une fois pour de bon.

Traitez la migration de contenu comme du code. Le framework de migration de Drupal permet de définir les migrations en configuration et de les rejouer, ce qui vous laisse réinitialiser, ajuster le mappage et recommencer. Les équipes qui corrigent le contenu à la main dans le nouveau site plutôt que de corriger la définition de migration finissent incapables de la rejouer, et le moindre changement de contenu dans l’ancien site devient une réconciliation manuelle.

Enfin, prévoyez un gel de contenu vers la fin, et gardez-le court. Les gels longs poussent les rédacteurs à vous contourner, ce qui produit exactement la dérive que vous cherchiez à éviter.

Faut-il quitter Drupal complètement ?

La question est légitime et mérite une réponse honnête plutôt que défensive.

Restez sur Drupal quand les raisons de l’avoir choisi tiennent toujours : modélisation de contenu complexe, permissions fines, besoins multilingues, flux éditoriaux lourds, ou obligations d’accessibilité et de secteur public. Drupal reste réellement fort sur tous ces points et le chemin de mise à niveau est désormais stable, avec un cycle de version majeure prévisible tous les deux ans.

Envisagez de partir quand le site s’est éloigné de ces besoins. Beaucoup de sites Drupal 7 sont aujourd’hui, dans les faits, un site vitrine avec des actualités et un formulaire de contact. Migrer cela au sein de Drupal revient à payer des prix de reconstruction pour une capacité que vous n’utilisez plus.

La décision doit se jouer sur le modèle de contenu et la charge éditoriale, pas sur la plateforme que préfère votre développeur. Si personne ne sait formuler ce que Drupal vous apporte qu’une plateforme plus simple ne pourrait pas, c’est une information.

Faites l’audit avant de demander un devis

Mecanik prend en charge les mises à niveau et migrations Drupal dans le cadre de nos services de développement web . Nous commençons par l’audit des modules contribués et du code sur mesure, parce que c’est ce qui transforme un projet ouvert en périmètre fixe, et cela vaut la peine même si vous confiez ensuite le travail ailleurs.

Pour les sites Drupal 10, la démarche sensée est de planifier le passage à Drupal 11 maintenant plutôt qu’en novembre, quand tout le monde s’y mettra. Pour les sites Drupal 7, la position de sécurité est déjà l’argument. Si votre contrainte est la capacité plutôt que l’expertise, notre guide sur le recrutement d’un développeur Drupal explique quoi rechercher.

Dites-nous sur quelle version vous êtes et combien de modules contribués et sur mesure le site utilise, et nous vous dirons lequel des chemins ci-dessus vous attend réellement.

Articles en relation: Modernisation PHP legacy : guide 2026 , Symfony vs Laravel en 2026 : quel framework PHP ? , Sécurité des API : protéger une API publique , Sites web médicaux et de santé au Royaume-Uni 2026 .

Questions fréquentes

Quand Drupal 10 cesse-t-il d’être supporté ? Drupal 10 atteint sa fin de vie le 9 décembre 2026, la semaine même où sort Drupal 12. Après cette date, il ne reçoit plus aucune publication, correctifs de sécurité compris, si bien que tout site qui y reste tourne sans support.

Combien coûte une migration Drupal ? Une mise à niveau de Drupal 10 vers 11 sur un site bien entretenu coûte typiquement 6 000 à 15 000 livres, montant à 15 000 à 35 000 quand modules et code sur mesure sont négligés. De Drupal 7 vers Drupal 11, c’est une reconstruction avec migration de contenu, couramment 40 000 à 120 000 livres ou davantage.

Pourquoi Drupal 7 vers Drupal 11 coûte-t-il tellement plus cher ? Parce que ce n’est pas une mise à niveau. Drupal 8 a reconstruit la plateforme sur des composants Symfony, remplaçant l’API des modules, la couche de thèmes et le système de configuration. Les modules doivent être remplacés, les thèmes réécrits en Twig et le code sur mesure réimplémenté, le contenu étant repris par une migration dédiée.

Combien de temps prend une mise à niveau de Drupal 10 vers 11 ? Deux à quatre semaines pour un site dont les modules contribués sont à jour et le code sur mesure réduit, et quatre à huit semaines lorsqu’il faut contourner des modules abandonnés ou des API supprimées. C’est l’audit des modules contribués en amont qui rend l’estimation fiable.

Puis-je migrer de Drupal vers WordPress à la place ? C’est parfois le bon choix, en particulier quand un site Drupal 7 est devenu un simple site vitrine sans modélisation de contenu complexe, sans permissions fines ni besoins multilingues. Fondez la décision sur votre modèle de contenu et votre charge éditoriale plutôt que sur une préférence de plateforme.