Combien coûte une migration de Drupal 10 vers Drupal 11 ?
Sur le marché français, le budget constaté pour une montée de version de Drupal 10 vers Drupal 11 se situe entre 3 000 € et 15 000 € HT. À un taux journalier moyen de 800 € à 1 000 € HT, cela représente 3 à 18 jours-homme. L'écart entre ces deux bornes est considérable, et il ne s'explique presque jamais par ce que les clients pensent.
Le nombre de pages, le volume de contenus, le trafic ou la taille de la base de données ne déterminent pas le prix. La raison est technique : depuis Drupal 8, les montées de version majeures ne sont plus des migrations de données. Le passage de Drupal 10 à Drupal 11 est une mise à jour sur place. Le schéma de base reste compatible, les contenus ne sont pas transformés, les configurations sont conservées. Un site de 200 pages et un site de 80 000 pages franchissent la même marche.
Ce qui fait le prix, c'est la couche logicielle autour du cœur :
- L'état de compatibilité des modules contribués installés, module par module.
- Le volume de code spécifique, modules maison et thème, à purger de ses API dépréciées.
- L'état de la pile serveur, puisque Drupal 11 exige PHP 8.3 au minimum.
- L'ampleur de la recette à mener sur les fonctionnalités métier.
D'où une conséquence directe pour un acheteur : une proposition chiffrée sans audit préalable est une estimation à l'aveugle. La question à poser à un prestataire n'est pas « combien coûte une migration Drupal 11 », mais « qu'avez-vous trouvé dans mon composer.json ».
La migration Drupal 11 en quatre repères
fin de vie de Drupal 10, selon le calendrier officiel de Drupal.org
fourchette HT constatée sur le marché français, soit 3 à 18 jours-homme
du temps passé sur les dépendances, les modules contribués et le code spécifique
PHP 8.3
version minimale exigée par Drupal 11, depuis un site déjà en Drupal 10.3.0
Le 9 décembre 2026 : ce qui s'arrête vraiment
La date ne vient pas d'un argumentaire commercial, mais du calendrier officiel des cycles de publication publié sur Drupal.org. Drupal 10.6.0 est la dernière version mineure de la branche 10, et le support de Drupal 10 s'arrête le 9 décembre 2026, la semaine même où sort Drupal 12.
Concrètement, à partir de cette date :
- Le cœur de Drupal 10 ne reçoit plus de correctifs de sécurité. Une faille critique annoncée après l'échéance reste ouverte sur votre site.
- Les modules contribués cessent progressivement de publier des versions compatibles avec la branche 10, puisque leurs mainteneurs suivent le cœur.
- Le socle technique vieillit avec vous : Symfony 6.4, sur lequel repose Drupal 10, arrive en fin de correction de bugs en novembre 2026, son support de sécurité s'arrêtant en novembre 2027.
Pour une administration, une collectivité ou une entreprise soumise à un audit, ce point est rarement négociable : faire tourner un applicatif hors support est un écart relevé en audit de sécurité, et un argument opposable par un assureur cyber.
Migrer vers Drupal 11 alors que Drupal 12 sort au même moment
La question revient systématiquement, et la réponse est non, il ne faut pas attendre. Drupal 11 restera supporté jusqu'à mi ou fin 2028, au moins jusqu'à la sortie de Drupal 13, d'après l'annonce officielle des prérequis de Drupal 12. Surtout, Drupal 12 exige PHP 8.5 et des versions de base de données plus récentes (MariaDB 10.11, PostgreSQL 18). Un site resté en Drupal 10 devrait franchir les deux marches d'un coup, avec un saut de PHP 8.1 ou 8.2 à PHP 8.5.
La trajectoire raisonnable est l'inverse : passer en Drupal 11 maintenant, rester à jour sur les versions mineures, puis aborder Drupal 12 comme une mise à jour de routine et non comme un projet.
La vraie grille de lecture des coûts : les modules et le code spécifique
Pour chiffrer une montée de version, on ne compte pas des pages, on trie des modules. Chaque module contribué installé tombe dans l'une de trois catégories, et le coût n'a rien à voir d'une catégorie à l'autre.
- Déjà compatible Drupal 11 : une ligne dans le
composer.json, quelques minutes. C'est le cas de la grande majorité des modules populaires aujourd'hui. - Compatible via un correctif : un patch existe dans la file d'issues du projet mais n'est pas encore publié dans une version stable. Il faut le récupérer, l'appliquer, le documenter, et surtout le suivre à chaque mise à jour ultérieure.
- Orphelin ou abandonné : plus de mainteneur actif, aucun portage en vue. Il faut alors arbitrer entre reprendre la maintenance du module, le remplacer par un équivalent, réécrire la fonctionnalité en module maison, ou l'abandonner. C'est le poste qui fait exploser les devis.
Le code spécifique suit la même logique. Les modules maison et le thème utilisent des API qui ont pu être dépréciées dans Drupal 10 puis supprimées dans Drupal 11, et un passage à PHP 8.3 ou 8.4 fait remonter ses propres avertissements. Un thème ancien, écrit avant les Single Directory Components, demande souvent plus de travail que le cœur lui-même.
Cas d'école : un devis à 5 jours clôturé à 7 ou 8
Le profil le plus courant : un site corporate sous Drupal 10, une quarantaine de modules contribués, un thème sur mesure, pas de commerce en ligne. Le pré-audit conclut à 5 jours. Le projet se termine à 7 ou 8. Ce décalage n'est pas une dérive commerciale, c'est un effet domino, et il se produit toujours au même endroit.
Composer refuse de résoudre l'arbre de dépendances à cause de deux ou trois modules secondaires non portés. Le blocage ne vient donc pas des modules structurants, correctement maintenus, mais de petits utilitaires installés des années plus tôt pour un besoin ponctuel. Chacun impose un arbitrage, et chaque arbitrage consomme du temps de recette.
Le plugin Composer Drupal Lenient sert d'échappatoire : il assouplit la contrainte de version du cœur pour les paquets qu'on lui désigne explicitement, le temps d'appliquer un correctif communautaire.
# Autoriser un module précis à s'installer malgré sa contrainte de version
composer require mglaman/composer-drupal-lenient
composer config --merge --json extra.drupal-lenient.allowed-list '["drupal/mon_module"]'C'est un outil de transition, pas une solution : un module maintenu de force en mode permissif reste un module non supporté, à retirer du périmètre dès qu'une version stable existe. Une proposition honnête doit le dire, et prévoir le budget de sortie.
Répartition moyenne du temps sur ce type de projet :
- 70 % sur la résolution des dépendances, les modules contribués et le code spécifique.
- 15 % sur la recette de non-régression, c'est-à-dire la vérification fonctionnelle avant mise en production.
- 15 % sur la préparation, l'audit et l'ajustement de la pile serveur, PHP 8.3 au minimum.
Montée de version n'est pas refonte. Passer de Drupal 10 à Drupal 11 ne change ni le design, ni l'arborescence, ni les contenus. Si une proposition mélange les deux, demandez deux lignes budgétaires distinctes : la mise à niveau technique est une obligation de calendrier, la refonte est un projet éditorial qui se décide séparément.
Comment obtenir un chiffrage fiable : exiger un pré-audit outillé
Un devis au forfait sans audit préalable ne protège personne : soit il est gonflé par une marge de sécurité, soit il explose en cours de route. La bonne pratique est de séparer en deux temps : un pré-audit court et facturé, puis un forfait de migration construit sur ses résultats.
Ce que produit le pré-audit
L'outil de référence est le module Upgrade Status, maintenu par la communauté et installé en dépendance de développement. Il vérifie les prérequis d'environnement, l'état de compatibilité de chaque projet contribué et, par une analyse PHPStan, les API dépréciées utilisées par le code spécifique et les gabarits Twig.
# Installer l'outil d'audit en dependance de developpement
composer require --dev drupal/upgrade_status
vendor/bin/drush pm:install upgrade_status
# Analyser tous les projets, y compris le code specifique
vendor/bin/drush upgrade_status:analyze --allLes corrections automatisables sont traitées avec Drupal Rector, qui réécrit une partie des appels dépréciés. Le reste est du travail manuel : c'est précisément ce que le pré-audit sert à quantifier.
Vérifier le point de départ et la pile serveur
Drupal 11 ne s'installe que depuis un site déjà en Drupal 10.3.0 ou plus récent, avec PHP 8.3 au minimum. Beaucoup de sites doivent donc d'abord finir leur parcours en 10.x avant d'envisager la bascule, et l'hébergeur doit confirmer par écrit la disponibilité de la version de PHP visée.
# Verifier le point de depart avant tout engagement
vendor/bin/drush status --field=drupal-version
php -vLes quatre questions à poser avant de signer
- Combien de modules contribués sont déjà compatibles, combien nécessitent un correctif, combien sont orphelins ? Le prestataire doit fournir la liste, pas un pourcentage.
- Quelle est la stratégie prévue pour chaque module orphelin : remplacement, reprise ou abandon ?
- Quel périmètre de recette fonctionnelle est couvert, et par qui ? La recette métier reste souvent à la charge du client.
- Que devient le forfait si un blocage de dépendance apparaît en cours de route ? La réponse doit figurer dans la proposition.
Vous préparez cette échéance ? Akabia réalise ce pré-audit et la montée de version : découvrir notre offre de migration Drupal, ou notre contrat de maintenance TMA Drupal pour rester à jour ensuite.
Questions fréquentes sur la migration de Drupal 10 vers Drupal 11
Drupal 10 s'arrête-t-il vraiment de fonctionner le 9 décembre 2026 ?
Non, le site continuera de fonctionner. Ce qui s'arrête, c'est le support : plus de correctifs de sécurité pour le cœur, et un écosystème contribué qui se détourne progressivement de la branche 10. Le risque n'est pas une panne le jour J, c'est l'accumulation de failles non corrigées à partir de cette date.
Faut-il migrer vers Drupal 11 ou attendre Drupal 12 ?
Il faut passer en Drupal 11. Drupal 12 sort la semaine du 7 décembre 2026 et exige PHP 8.5, MariaDB 10.11 ou PostgreSQL 18. Attendre revient à cumuler deux marches techniques au lieu d'une. Une fois en Drupal 11, supporté jusqu'à mi ou fin 2028, le passage à Drupal 12 devient une mise à jour de routine.
Mes contenus et mon référencement sont-ils affectés par la montée de version ?
Non. Une montée de version de Drupal 10 vers 11 conserve les contenus, les URL et la configuration : il n'y a pas de remigration de données comme lors d'un passage depuis Drupal 7. Les risques SEO apparaissent quand on profite de l'opération pour refondre le site, ce qui est un autre projet.
Pourquoi deux agences peuvent-elles chiffrer la même migration du simple au triple ?
Parce qu'elles ne chiffrent pas la même chose. L'une a audité les modules et intègre le traitement des dépendances orphelines et la recette ; l'autre applique un forfait type sans avoir regardé le composer.json. Demandez le détail par poste : dépendances, code spécifique, recette, environnement serveur.
Combien de temps dure une montée de version Drupal 10 vers 11 ?
Pour un site corporate courant, comptez 3 à 18 jours-homme selon l'état des modules, répartis sur quelques semaines calendaires afin d'intégrer la recette et une fenêtre de mise en production. Le délai dépend surtout de la disponibilité des équipes métier pour valider les fonctionnalités.
Que faire d'un module contribué abandonné qui n'a pas de version Drupal 11 ?
Quatre options, par ordre de coût croissant : le remplacer par un module équivalent maintenu, reprendre la maintenance du module en amont, réécrire la fonctionnalité en module maison, ou abandonner la fonctionnalité. Le plugin Composer Drupal Lenient permet de tenir temporairement, mais ne constitue pas une cible durable.
