Drupal 10 s'arrête le 9 décembre 2026 : migrer vers 11

Le 9 décembre 2026, Drupal 10 cessera de recevoir des correctifs de sécurité, la semaine même où la sortie de Drupal 12 est annoncée. Si votre site vitrine, institutionnel ou corporate tourne encore sur Drupal 10, il vous reste environ cinq semaines pour arrêter une décision : migrer vers Drupal 11, financer un support étendu auprès d'un tiers, ou accepter de laisser en ligne un site qui ne sera plus corrigé. Ce billet détaille le calendrier vérifié, les prérequis techniques, les durées et les ordres de grandeur de coût observés sur le marché, puis la méthode que nous appliquons chez Pulsar Agency pour des sites existants.

Pourquoi ce sujet cette semaine : l'échéance du 9 décembre tombe dans cinq semaines, alors que les migrations de sites institutionnels durent le plus souvent de trois à six mois. Beaucoup d'organisations découvrent donc qu'elles sont déjà en retard, et c'est précisément le moment où un arbitrage clair vaut mieux qu'une migration précipitée. Cet article s'adresse aux dirigeants, aux responsables marketing et communication et aux DSI qui possèdent un ou plusieurs sites Drupal et veulent comprendre ce qu'ils doivent demander à leur prestataire.

Ce qui change le 9 décembre 2026, et ce qui ne change pas

Drupal 10 atteint sa fin de vie le 9 décembre 2026 : après cette date, la communauté Drupal ne publie plus aucun correctif de sécurité pour cette version majeure, y compris pour les failles critiques. Votre site continue de fonctionner normalement, mais chaque vulnérabilité découverte ensuite restera ouverte, sauf si vous souscrivez un support commercial tiers.

Drupal 10 a été publié le 14 décembre 2022. Sa fin de vie obéit à la mécanique habituelle du projet : une version majeure est supportée tant que la version suivante n'a pas pris le relais, et la communauté ne maintient en sécurité que deux versions mineures à la fois. Concrètement, la branche 10.4 n'est plus couverte depuis le 10 décembre 2025, la branche 10.5 a perdu sa couverture de sécurité la semaine du 29 juin 2026, et la branche 10.6 est la seule encore corrigée, jusqu'à la semaine du 7 décembre 2026. Au 16 septembre 2026, la dernière version disponible était la 10.6.17, publiée avec l'avis de sécurité SA-CORE-2026-013. Cet exemple rappelle que les avis de sécurité continuent d'arriver jusqu'à la dernière semaine : arrêter de suivre les mises à jour avant l'échéance, parce que « de toute façon la version va s'arrêter », est une erreur coûteuse.

Un point mérite d'être souligné : la date du 9 décembre est ferme et indépendante du calendrier de Drupal 12. La fenêtre de sortie initialement visée en août 2026 a été abandonnée le 14 mai 2026, et la sortie de Drupal 12.0.0 est désormais ciblée pour la semaine du 7 décembre 2026. Mais si Drupal 12 prenait du retard, la fin de vie de Drupal 10 ne serait pas repoussée pour autant. Votre planning ne doit donc dépendre d'aucune date de sortie : il doit dépendre de la date de fin de vie.

Ce qui ne change pas, en revanche, mérite d'être dit pour éviter les messages alarmistes. Il n'existe aucun mécanisme qui désactive un site Drupal 10 le 10 décembre. Vos pages continueront de s'afficher, vos formulaires de fonctionner et vos contenus de rester en ligne. Le danger est d'une autre nature : il est silencieux et cumulatif. Chaque semaine qui passe sans correctif augmente la probabilité qu'une faille publiée soit exploitée par des robots qui balaient Internet à la recherche de versions connues pour être vulnérables. Un site vitrine n'est pas moins ciblé qu'un autre : les attaques automatisées ne choisissent pas leurs victimes en fonction de leur taille. Pour comprendre l'enchaînement des échéances sur l'ensemble des CMS, vous pouvez lire notre calendrier des fins de support CMS 2026-2027.

Pourquoi on ne peut pas passer directement de Drupal 10 à Drupal 12

On ne peut pas sauter de Drupal 10 à Drupal 12 : Drupal impose de passer par Drupal 11, et Drupal 12 exige au minimum la version 11.3.0 comme point de départ, car les scripts de mise à jour plus anciens ont été retirés du code. Attendre Drupal 12 ne dispense donc jamais de migrer d'abord vers Drupal 11.

C'est l'idée reçue la plus répandue que nous rencontrons : « autant attendre Drupal 12 et faire une seule migration ». Elle est tentante, puisqu'elle promet d'économiser un chantier, mais elle est techniquement fausse. Le chemin de mise à niveau de Drupal passe par chaque version majeure dans l'ordre. Pour installer Drupal 11, le site doit d'abord être à jour en Drupal 10.3 ou supérieur. Pour arriver sur Drupal 12, il doit ensuite se trouver au minimum en Drupal 11.3.0. Attendre Drupal 12 reviendrait donc à rester volontairement sans correctif pendant plusieurs mois, pour effectuer de toute façon la même étape intermédiaire.

La bonne stratégie est de considérer la migration vers Drupal 11 comme l'étape inévitable, puis de planifier Drupal 12 comme une évolution ultérieure, plus légère. Une fois le site sur Drupal 11 avec des modules propres, c'est-à-dire sans API dépréciées, le passage à Drupal 12 devient une opération de maintenance planifiée plutôt qu'un projet. Drupal 11, sorti le 2 août 2024, reste supporté jusqu'à la mi-2028 ou la fin 2028 selon les sources : vous gagnez donc une visibilité de plus de deux ans, le temps d'organiser sereinement la suite. La version 11.5.0 sortira d'ailleurs en même temps que Drupal 12.0.0, ce qui garantit une branche 11 stable et à jour pour accueillir les sites qui ne passeront pas tout de suite sur la version 12.

Cette logique en deux temps a un second avantage, trop rarement évoqué : elle sépare les risques. Une migration vers Drupal 11 touche le cœur, les modules et le code sur mesure. Un passage ultérieur à Drupal 12 touche surtout le socle serveur et quelques modules retirés du cœur. En les menant à des dates différentes, vous savez, en cas de régression, quel changement l'a causée.

Les prérequis techniques : PHP 8.3, base de données et outillage

Drupal 11 exige PHP 8.3 au minimum, MySQL 8.0 ou MariaDB 10.6 au minimum, et PostgreSQL 16 si vous utilisez cette base. Votre hébergement doit donc être mis à niveau avant, ou en même temps, que le code du site. C'est souvent ce point, et non Drupal lui-même, qui bloque un calendrier.

Le minimum PHP 8.3 a été décidé dès janvier 2024 par la communauté Drupal. À cela s'ajoutent des exigences d'outillage : Drush 13 et Composer 2.7.7 ou supérieur, selon la documentation d'un grand éditeur d'hébergement Drupal. Un site Drupal moderne se gère en effet avec Composer, qui résout les dépendances et installe les modules. Un hébergement qui ne permet ni l'accès en ligne de commande ni l'exécution de Composer rend la migration beaucoup plus laborieuse. C'est fréquent sur certaines offres mutualisées : l'absence d'accès SSH et de Composer oblige à travailler en local puis à téléverser l'ensemble du code, une méthode plus lente et plus risquée.

Le cycle de vie de PHP est le second calendrier à surveiller, et il est tout proche. Selon php.net, PHP 8.2 ne reçoit plus de correctifs de sécurité après le 31 décembre 2026, PHP 8.3 jusqu'au 31 décembre 2027 et PHP 8.4 jusqu'au 31 décembre 2028. Un site Drupal 10 qui tourne encore sur PHP 8.2 cumulera donc deux fins de support en moins d'un mois : celle du CMS le 9 décembre et celle du langage le 31 décembre. Pour une cible durable, nous recommandons de viser PHP 8.4 dès la migration, après avoir vérifié la compatibilité de chaque module, afin de disposer de correctifs de sécurité jusqu'à fin 2028. Notre billet consacré à la fin de vie de PHP 8.2 détaille cette échéance.

Côté base de données, vérifiez la version réellement installée sur votre serveur, car beaucoup d'hébergements historiques sont restés sur des versions anciennes de MySQL ou de MariaDB. Une version de MySQL antérieure à la 8.0 doit être remplacée avant la migration, et ce changement doit lui-même être testé : il peut modifier le comportement de certaines requêtes ou de certains types de champs. Planifiez cette étape en premier, car elle est indépendante de Drupal et peut être menée à froid sur un environnement de test.

Ce que Drupal 12 change déjà pour votre migration vers Drupal 11

Drupal 12 relève le minimum à PHP 8.5, aligne le socle sur Symfony 8 et sort six modules du cœur vers la contribution : Ban, Contact, Field Layout, History, Migrate Drupal et Migrate Drupal UI. Ces choix se préparent dès la migration vers Drupal 11, car ils déterminent le serveur et les modules que vous conserverez dans la durée.

Les exigences de Drupal 12 ont été annoncées le 14 janvier 2026 par les responsables du cœur. Côté bases de données, MariaDB passe de 10.6 à 10.11 au minimum et PostgreSQL de 16 à 18, tandis que MySQL 8.0 et SQLite 3.45 restent inchangés. Le serveur web doit être Apache 2.4.7 ou Nginx 1.1 au minimum, et IIS n'est pas supporté. Ces relèvements ont une conséquence pratique : si vous profitez de la migration vers Drupal 11 pour installer une base MariaDB 10.11 plutôt que 10.6, vous évitez une seconde intervention sur l'infrastructure l'année suivante.

Le retrait de modules du cœur concerne directement les sites vitrines. Le module Contact fournit les formulaires de contact simples que beaucoup de sites utilisent encore tels quels. Il ne disparaît pas, il passe en contribution : il faudra donc l'installer comme n'importe quel module externe et suivre ses mises à jour. Il en va de même pour History, qui mémorise les contenus déjà lus par les utilisateurs connectés, et pour Ban, qui permet de bloquer des adresses IP. Les deux modules Migrate Drupal concernent surtout les chantiers de migration depuis Drupal 7 : si votre site a été migré depuis Drupal 7 et qu'il les embarque encore, ils pourront être désinstallés une fois la migration de contenu terminée.

Le message à retenir est simple : lors de l'inventaire initial, ajoutez une colonne « devenir sous Drupal 12 » à chaque module. Un module du cœur qui sera retiré, un module contribué qui n'a aucune version annoncée pour Drupal 12 ou un module abandonné par son mainteneur sont autant de signaux à traiter maintenant, quand le budget est encore souple, plutôt que dans l'urgence de l'année suivante.

Modules contribués et code sur mesure : où se cache le vrai risque

Le risque principal d'une migration de Drupal 10 vers Drupal 11 n'est pas le cœur, c'est l'écosystème autour : modules contribués sans version compatible, code sur mesure qui utilise des API dépréciées, surcharges du thème d'administration. Le module Upgrade Status dresse cet inventaire, et l'outil Drupal Rector automatise une partie des corrections du code.

Le cœur de Drupal est conçu pour que la montée de version soit prévisible : les API qui disparaissent en Drupal 11 ont été signalées comme dépréciées pendant tout le cycle de Drupal 10. Un site qui n'utilise aucune API dépréciée migre donc vite. Les difficultés viennent de ce qui l'entoure. Un site Drupal de PME ou de grand compte embarque typiquement entre quinze et quarante modules contribués, plus un ou plusieurs modules développés pour un besoin précis, plus un thème. Chacun de ces éléments doit être compatible avec Drupal 11 au moment de la bascule.

Trois situations à distinguer pour chaque module

Dans le premier cas, une version compatible Drupal 11 existe : il suffit de la mettre à jour avec Composer, puis de tester. Dans le deuxième cas, le module est maintenu mais la version compatible n'est pas encore publiée : il faut évaluer si un correctif de la communauté peut être appliqué, ou contribuer soi-même le correctif. Dans le troisième cas, le module est abandonné : il faut le remplacer par une alternative maintenue, ou intégrer sa fonction dans un module sur mesure, ce qui engage un coût de développement et de maintenance supplémentaire. C'est ce troisième cas qui fait exploser les budgets, et c'est pourquoi l'inventaire doit précéder tout chiffrage.

Ce que l'automatisation couvre, et ce qu'elle ne couvre pas

Selon les retours publiés autour de Drupal 12, plus de 80 % des API dépréciées sont traitées par des règles Drupal Rector automatiques. Cette proportion s'applique à l'écosystème des modules contribués. Elle est plus faible pour le code sur mesure d'entreprise, qui mélange souvent des conventions maison, des appels directs à des services et des contournements historiques. Retenez donc la règle suivante : plus un site contient de code sur mesure, moins la migration est automatisable, et plus la recette doit être sérieuse. Un module sur mesure qui gère une inscription, un calcul ou une synchronisation avec un outil externe ne doit jamais être validé sur la seule foi d'un outil automatique.

Les surcharges de gabarits Twig du thème méritent une attention particulière. Un thème sur mesure qui redéfinit des gabarits du cœur peut continuer à s'afficher correctement tout en masquant des changements de balisage introduits par la nouvelle version. Après migration, comparez les pages clés visuellement, mais aussi sur le plan de l'accessibilité : un changement de balisage peut dégrader un contraste, un ordre de tabulation ou une étiquette de formulaire sans que personne ne le remarque à l'œil nu.

Enfin, exportez la configuration en fichiers YAML sous gestion de versions avant toute intervention. Cette précaution, qui prend quelques heures, permet de comparer l'état avant et après, de rejouer la configuration sur un environnement de test et de revenir en arrière en cas de problème. Un site dont la configuration n'est pas versionnée se migre à l'aveugle.

Combien de temps et combien coûte une migration Drupal 10 vers 11

Une migration de Drupal 10 vers Drupal 11 demande de un à trois mois pour un site vitrine avec peu de modules contribués, de trois à six mois pour un site institutionnel avec modules sur mesure et circuits éditoriaux, et de sept à douze mois pour une plateforme à fort trafic avec intégrations métier. Ces durées incluent la recette et le plan de reprise, pas seulement le développement.

Ces ordres de grandeur proviennent d'une analyse publiée en avril 2026 par une agence française spécialisée en Drupal, qui mentionne aussi, pour un site vitrine, une fourchette de deux à quatre mois selon la complexité. Il s'agit de durées calendaires, donc du temps écoulé entre le lancement et la mise en production, pas du nombre de jours de travail facturés. L'écart tient aux délais de validation, à la disponibilité des équipes métier pour la recette et aux cycles de déploiement de chaque organisation.

Sur le plan budgétaire, les fourchettes publiées en France sont rares et il faut rester prudent. Une étude britannique estime l'opération autour de 6 000 à 15 000 livres pour un site modérément complexe et bien entretenu, et de 15 000 à 35 000 livres pour un site négligé, soit un facteur d'environ deux à trois entre un site à jour et un site laissé à l'abandon. La même source évalue la reconstruction d'un site Drupal 7 vers Drupal 11 entre 40 000 et 120 000 livres sur trois à six mois. Ces montants reflètent des tarifs d'agences britanniques : ils servent de repère de proportion, non de devis français.

Pour le marché français, les grilles d'agences publiées à l'automne 2026 situent le taux journalier des développeurs entre 450 et 700 € HT, à titre indicatif. Sur cette base, une hypothèse de dix jours de travail pour un petit site bien entretenu donnerait 4 500 à 7 000 € HT. Cet exemple est volontairement arithmétique : le nombre de jours dépend entièrement de l'inventaire des modules et du code sur mesure, et c'est la raison pour laquelle aucun prestataire sérieux ne devrait chiffrer sans avoir regardé votre site.

Ce qui fait réellement varier la facture, c'est l'état du site au départ. Un site dont les mises à jour ont été appliquées régulièrement migre en quelques jours, parce que les modules sont déjà proches de leur dernière version. Un site laissé plusieurs années sans mise à jour cumule les montées de version à rattraper, des modules abandonnés et des correctifs locaux non documentés. C'est le principe de la dette technique : reporter la maintenance ne supprime pas le coût, il l'amplifie au moment de la migration.

Un constat s'impose avec le calendrier actuel. À cinq semaines de l'échéance, seuls les sites les plus simples peuvent être migrés avant le 9 décembre. Pour tous les autres, la décision réaliste consiste à lancer la migration maintenant avec une date de mise en production réaliste, et à couvrir la période intermédiaire par un dispositif de protection. Mieux vaut l'assumer clairement que promettre une date impossible.

Support étendu tiers : un sursis, pas une stratégie

Un support étendu tiers prolonge la fourniture de correctifs de sécurité pendant six à dix-huit mois après la fin de vie officielle, sous contrat annuel dont le tarif dépend de la criticité du site. C'est un sursis administratif pour tenir une migration longue, et non une alternative durable à la migration.

Plusieurs éditeurs proposent ce type de service pour Drupal, et l'analyse d'avril 2026 citée plus haut mentionne une solution de transition permettant de gagner entre six et dix-huit mois. Aucun tarif public n'est affiché : il se négocie selon la criticité et le périmètre. Un autre acteur indiquait, de son côté, qu'aucun programme de support étendu pour Drupal 10 n'avait encore été annoncé au moment de sa publication. Ces deux informations ne se contredisent qu'en apparence : l'offre évolue et il faut vérifier, au moment de signer, ce que couvre exactement le contrat, pour quelles versions de PHP et de modules, avec quels délais d'intervention.

Les limites à vérifier avant de signer

Premièrement, un support étendu ne dispense pas de maintenir le serveur : si votre site Drupal 10 tourne sur PHP 8.2, il faut de toute façon passer à une version de PHP encore supportée avant le 31 décembre 2026. Deuxièmement, le code sur mesure reste sous votre responsabilité : un correctif tiers couvre le cœur et certains modules, pas les modules que vous avez fait développer. Troisièmement, ce service a un coût récurrent qui vient s'ajouter au budget de migration, sans le remplacer. Quatrièmement, il repose sur l'hypothèse que la migration aboutira avant la fin de la période : sans plan daté, le sursis se reconduit chaque année et la dette se creuse.

Le support étendu a donc un usage légitime, étroit : couvrir une plateforme complexe dont la migration est lancée, budgétée et planifiée, mais ne pourra pas aboutir avant la fin de vie. Dans tous les autres cas, il vaut mieux investir directement dans la migration. Pour arbitrer sereinement entre ces options et les inscrire dans votre budget annuel, notre contrat de maintenance web intègre la veille sur les fins de support et le suivi des mises à jour de sécurité.

La méthode en huit étapes pour migrer sans interruption

Une migration de Drupal 10 vers Drupal 11 bien menée suit huit étapes : inventaire, mise à niveau de l'hébergement, passage à Drupal 10.6, correction des modules, migration du code sur mesure, recette, bascule avec plan de retour, puis surveillance après mise en production. La sauvegarde restaurée à blanc avant la bascule est l'étape que l'on regrette le plus d'avoir sautée.

1. Inventaire. Listez les modules contribués, les modules sur mesure, le thème, les versions de PHP et de base de données, et lancez le module Upgrade Status pour obtenir un état de compatibilité. Ajoutez la colonne « devenir sous Drupal 12 ».
2. Mise à niveau de l'hébergement. Installez sur un environnement de test PHP 8.3 ou 8.4, une base compatible et les versions requises de Composer et de Drush. Cette étape est indépendante de Drupal et peut démarrer immédiatement.
3. Passage à Drupal 10.6. Mettez le site à jour vers la dernière version de la branche 10.6, seule branche encore corrigée, pour partir d'une base saine. Ne tentez pas la migration depuis une version 10.2 ou plus ancienne : le prérequis est la version 10.3 au minimum.
4. Correction des modules. Mettez à jour, remplacez ou retirez chaque module selon les trois situations décrites plus haut, en documentant chaque décision.
5. Migration du code sur mesure. Appliquez Drupal Rector, puis relisez manuellement les modules qui portent des règles métier.
6. Recette. Testez les parcours critiques, les formulaires, la recherche, les performances, l'accessibilité et la restauration d'une sauvegarde complète. Faites valider par les équipes métier, pas seulement par les développeurs.
7. Bascule avec plan de retour. Planifiez la mise en production en dehors des pics de trafic, avec une sauvegarde de la base et des fichiers, testée en restauration, et un critère clair de retour arrière.
8. Surveillance. Suivez les journaux d'erreurs, les temps de réponse et l'indexation dans les semaines qui suivent, car certaines régressions n'apparaissent qu'avec le trafic réel.

Cette trame vaut pour un site isolé comme pour un parc. Lorsque plusieurs sites partagent le même socle, il est plus économique de migrer d'abord un site pilote, d'en tirer une liste de pièges et de la rejouer sur les autres. C'est l'un des gains du pilotage de parc digital : une seule méthode, appliquée à tous les sites, au lieu d'autant de migrations improvisées.

Erreurs fréquentes, conformité et plan d'action de la semaine

Les quatre erreurs les plus fréquentes sont d'attendre Drupal 12, de migrer directement en production sans environnement de test, d'ignorer l'hébergement et de traiter la fin de vie comme un sujet purement technique. C'est aussi un sujet de conformité, car le RGPD, le RGAA et l'European Accessibility Act supposent un site maintenu.

La première erreur, attendre Drupal 12, a été expliquée plus haut : elle ne supprime aucune étape. La deuxième est plus lourde de conséquences : migrer directement en production, sans copie fidèle du site, revient à découvrir les incompatibilités devant vos visiteurs. La troisième, ignorer l'hébergement, bloque des projets au dernier moment, lorsque l'on s'aperçoit que le serveur ne peut pas accueillir PHP 8.3 ou que l'accès en ligne de commande est impossible.

La quatrième erreur est la plus insidieuse. Une fin de vie n'est pas seulement une affaire de développeurs, elle engage la responsabilité de l'organisation. L'article 32 du RGPD impose de mettre en œuvre des mesures de sécurité appropriées au regard de l'état des connaissances : exploiter un site collectant des données personnelles, par exemple via un formulaire de contact, sur un logiciel que son éditeur ne corrige plus rend cette position difficile à défendre en cas d'incident. Les analyses françaises sur la fin de vie de Drupal 10 citent aussi le RGAA et l'European Accessibility Act, et, pour le secteur public, le système de design de l'État et l'hébergement souverain. Un site qui n'est plus maintenu ne peut pas non plus intégrer sereinement les corrections d'accessibilité attendues.

Sur le plan de la continuité, la fin de vie rejoint un sujet que nous traitons régulièrement : la capacité à remettre un site en ligne vite après un incident. Si vous ne disposez pas d'une sauvegarde testée en restauration, la migration est le bon moment pour en constituer une. En cas d'incident, notre équipe intervient aussi en dépannage de site internet, y compris pour des sites dont la version n'est plus supportée.

Que faire cette semaine : le plan en cinq décisions

Cette semaine, cinq décisions suffisent à sortir de l'incertitude : identifier la version exacte de chaque site Drupal, vérifier la version de PHP et de la base de données, lancer l'inventaire des modules, choisir entre migration directe et dispositif transitoire, et fixer une date de mise en production. Chacune se traite en quelques jours et conditionne la suivante.

Première décision : recensez vos sites. Beaucoup d'organisations découvrent à cette occasion un site secondaire, un micro-site événementiel ou un extranet oublié, hébergé sur une ancienne version. Ces sites oubliés sont ceux qui sont piratés en premier, car personne ne les surveille. Deuxième décision : relevez les versions de PHP et de base de données de chaque serveur. Troisième décision : confiez ou lancez l'inventaire des modules et du code sur mesure, étape préalable à tout chiffrage fiable. Quatrième décision : arbitrez entre une migration rapide, possible pour un site simple, et un dispositif transitoire pour un site complexe. Cinquième décision : fixez une date de mise en production et un responsable côté métier pour la recette.

Lorsque l'inventaire n'a pas encore été fait, la première prestation utile est un audit de site web : il fournit l'état des versions, des modules, de l'hébergement et des risques, et permet d'obtenir un chiffrage fondé sur des faits plutôt qu'une estimation à l'aveugle. Au-delà de la migration, la montée de version est l'occasion de mettre en place une tierce maintenance applicative régulière, de sorte que la prochaine échéance, Drupal 12 puis Drupal 13 vers 2028, ne soit plus une urgence mais une opération de routine.

Questions fréquentes sur la fin de vie de Drupal 10

Que se passe-t-il si je reste sur Drupal 10 après le 9 décembre 2026 ?

Votre site continue de fonctionner, mais il ne reçoit plus aucun correctif de sécurité de la communauté Drupal. Toute faille découverte après le 9 décembre 2026 restera ouverte, sauf si vous souscrivez un support étendu tiers. Le risque augmente avec le temps, et il s'ajoute à la fin de support de PHP 8.2 le 31 décembre 2026 si votre serveur n'a pas été mis à niveau.

Puis-je passer directement de Drupal 10 à Drupal 12 ?

Non, la mise à niveau doit passer par Drupal 11. Drupal 12 exige de partir au minimum de la version 11.3.0, et Drupal 11 exige lui-même une base en Drupal 10.3 ou supérieur. Attendre Drupal 12 ne supprime donc aucune étape et vous laisse sans correctif de sécurité pendant l'attente.

Combien de temps dure une migration de Drupal 10 vers Drupal 11 ?

La durée dépend de la complexité : de un à trois mois pour un site vitrine avec peu de modules, de trois à six mois pour un site institutionnel avec code sur mesure, de sept à douze mois pour une plateforme à fort trafic. Ces durées calendaires incluent la recette. Un site correctement tenu à jour migre nettement plus vite qu'un site laissé sans mise à jour.

Vaut-il mieux migrer vers Drupal 11 ou changer de CMS ?

Migrer vers Drupal 11 est presque toujours moins coûteux et moins risqué qu'une refonte sur un autre CMS, tant que votre site repose sur une structure de contenus et des modules que vous voulez conserver. Changer de CMS se justifie si le site ne répond plus à vos usages ou si la dette accumulée rend la migration aussi coûteuse qu'une reconstruction. L'audit permet de trancher sur des faits.

Votre site Drupal est-il prêt pour le 9 décembre ? Pulsar Agency maintient et fait évoluer des sites existants depuis 2005, en Île-de-France et dans les Hauts-de-France. Commencez par un audit de votre site web : nous vous indiquons la version, l'état des modules, les prérequis d'hébergement et un plan de migration réaliste avant l'échéance.