# Comment gérer les mises à jour majeures sur Drupal ?
Les mises à jour majeures de Drupal représentent un défi technique significatif pour toute organisation utilisant ce CMS open source. Avec l’évolution rapide des technologies web et les exigences croissantes en matière de sécurité, maintenir votre plateforme à jour n’est plus une option mais une nécessité stratégique. La transition entre versions majeures — que ce soit de Drupal 7 vers Drupal 9, ou de Drupal 9 vers Drupal 10 — implique bien plus qu’une simple mise à jour de fichiers. Elle nécessite une planification rigoureuse, une compréhension approfondie de l’architecture du système, et une maîtrise des outils d’automatisation disponibles. Cette complexité s’explique par les changements profonds apportés à chaque version majeure : nouveaux frameworks sous-jacents, API modernisées, dépendances actualisées et parfois même des paradigmes de développement entièrement renouvelés.
Analyse des prérequis techniques avant une migration drupal majeure
Avant d’entamer toute migration majeure de Drupal, une phase d’analyse approfondie s’impose. Cette étape préliminaire conditionne la réussite de l’ensemble du projet et permet d’identifier les obstacles potentiels avant qu’ils ne deviennent problématiques. L’audit technique doit couvrir plusieurs dimensions : l’infrastructure serveur, la compatibilité des modules, la structure des données et l’architecture globale du site. Négliger cette phase d’analyse expose votre projet à des risques considérables : incompatibilités techniques, perte de données, ou encore dégradation des performances post-migration.
Audit de compatibilité des modules contrib et custom avec drupal 10
L’écosystème de modules constitue l’épine dorsale de tout site Drupal. Avant la migration, vous devez recenser exhaustivement tous les modules installés sur votre plateforme actuelle. Le module Upgrade Status s’avère indispensable à cette étape : il analyse automatiquement votre installation et génère un rapport détaillé sur la compatibilité de chaque module avec la version cible. Pour les modules contrib, vérifiez leur page sur Drupal.org pour confirmer l’existence d’une version compatible. Certains modules populaires peuvent avoir été fusionnés dans le core Drupal, tandis que d’autres ont été abandonnés par leurs mainteneurs. Dans ce dernier cas, identifiez rapidement des alternatives viables ou prévoyez le développement d’une solution de remplacement.
Les modules custom nécessitent une attention particulière. Examinez leur code source pour repérer les appels à des API dépréciées, les hooks obsolètes ou les dépendances à des bibliothèques tierces qui pourraient ne plus être supportées. L’outil Drupal Rector peut automatiser une partie de cette refactorisation en identifiant et en corrigeant automatiquement certains patterns de code obsolètes. Documentez précisément les fonctionnalités critiques assurées par ces modules custom afin de garantir leur continuité après la migration.
Vérification de la configuration PHP 8.1+ et des dépendances composer
Drupal 10 impose des exigences techniques strictes concernant l’environnement d’exécution. PHP 8.1 constitue la version minimale requise, bien que PHP 8.2 soit recommandé pour bénéficier des dernières optimisations de performance et correctifs de sécurité. Vérifiez que votre environnement d’hébergement supporte cette version et que toutes les extensions PHP nécessaires sont activées : gd, xml, mbstring, curl,
pdo, json, openssl, tokenizer, entre autres. Profitez-en pour vérifier les limites de mémoire (memory_limit), le temps d’exécution (max_execution_time) et la taille maximale d’upload de fichiers, afin d’éviter les échecs de scripts lors des mises à jour via Composer ou Drush. Un environnement PHP 8.1+ mal configuré peut provoquer des erreurs subtiles liées aux types stricts ou aux warnings promus en exceptions. Enfin, contrôlez votre fichier composer.json : versions des packages, contraintes (^10, ~10.1, etc.), dépôts personnalisés, et présence de drupal/core-recommended, afin de garantir une résolution de dépendances cohérente lors de la montée de version.
Composer est désormais le cœur de la gestion des mises à jour Drupal majeures. Assurez-vous d’utiliser une version de Composer récente (2.x) et que votre environnement dispose de suffisamment de mémoire pour exécuter les commandes intensives (composer update peut consommer plus de 1 Go de RAM). Dans les projets complexes, il est judicieux de lancer d’abord un composer outdated "drupal/*" pour visualiser les écarts de versions du core et des modules contrib. En parallèle, vérifiez la cohérence entre votre composer.lock et le dossier vendor/ (en cas de doute, régénérez le dossier en supprimant vendor/ et en relançant composer install). Vous réduisez ainsi le risque d’incohérences de dépendances au moment critique de la migration Drupal 10 ou 11.
Évaluation de la structure de base de données MySQL 5.7.8 ou MariaDB 10.3.7
La base de données est l’élément le plus sensible d’une mise à jour majeure de Drupal. Officiellement, Drupal 10 recommande MySQL 5.7.8+ ou MariaDB 10.3.7+, mais dans la pratique, viser MySQL 8 ou MariaDB 10.6+ offre de meilleures performances et une longévité accrue. Commencez par identifier la version réelle de votre moteur (SELECT VERSION();) et vérifiez que le mode SQL (sql_mode) est compatible avec les exigences Drupal (évitez par exemple certains modes stricts trop agressifs si votre schéma est ancien). Un audit rapide des index, de la taille des tables et du moteur de stockage (InnoDB recommandé) vous donne une vision claire de la santé de votre base avant la migration.
Profitez de cette phase pour repérer les tables orphelines ou héritées de vieux modules non utilisés. Une base de données « encombrée » complique les scripts de mise à jour et peut rallonger significativement le temps d’exécution des update.php et drush updb. Vous pouvez par exemple : inventorier les tables dont le préfixe ne correspond plus à des modules actifs, repérer les index redondants, ou vérifier la cohérence des clés primaires sur les entités personnalisées. Pensez aussi à tester le dump et la restauration de la base sur un environnement de préproduction : si la restauration échoue ou est trop lente, la fenêtre de migration Drupal majeure risque d’être difficile à tenir.
Documentation de l’architecture multisite et des configurations spécifiques
Les environnements multisites Drupal complexifient considérablement les mises à jour majeures. Avant toute action, cartographiez précisément l’architecture : nombre de sites, répertoires sites/<nom>, partages de code et de modules, spécificités de configuration. Documentez les différences fonctionnelles et techniques entre les sites : certains peuvent utiliser des modules contrib différents, des thèmes custom ou des intégrations tierces qui n’existent pas ailleurs. Cette documentation servira de feuille de route pour déterminer l’ordre de migration et les éventuelles variations de procédure à appliquer par site.
Les configurations spécifiques (reverse proxy, Varnish, CDN, LDAP, SSO, intégrations métier) doivent également être recensées. Par exemple, un site exposé via un CDN avec cache agressif ne réagira pas de la même façon qu’un intranet derrière un VPN lors des opérations de mise à jour. Notez les surcharges de paramètres (settings.php, services.yml, variables d’environnement) et les workflows de déploiement existants (CI/CD, scripts Ansible, etc.). Une migration Drupal réussie ressemble à un déménagement : plus vous étiquetez vos cartons à l’avance, moins vous perdez d’objets en route.
Stratégies de migration : drush, drupal migrate API et méthodes manuelles
Utilisation de drush 11+ pour automatiser les mises à jour de core
Drush est l’allié incontournable des migrations Drupal majeures. Avec Drupal 10, visez Drush 11+ (voire 13+ pour Drupal 11) pour bénéficier d’une compatibilité totale avec les nouvelles API et d’améliorations de performances. La stratégie recommandée consiste à déléguer un maximum d’opérations répétitives à Drush : mise à jour de la base de données (drush updb), vidage des caches (drush cr), export/import de configuration (drush cex/drush cim), et exécution de scripts personnalisés via drush scr. En combinant Composer pour la mise à jour du code et Drush pour la mise à jour de la base, vous obtenez un pipeline de migration plus fiable et reproductible.
Dans le cadre d’une mise à jour majeure de Drupal, il est pertinent d’intégrer Drush dans votre chaîne CI/CD. Par exemple, un pipeline typique peut : cloner le dépôt, exécuter composer install, appliquer les mises à jour du core, lancer drush updb -y, puis drush cr et enfin vos tests automatisés. Vous pouvez également créer des alias Drush pour gérer plus facilement plusieurs environnements (dev, recette, production) et éviter les erreurs humaines. En automatisant ces étapes, vous réduisez les risques d’oubli (un updb oublié peut suffire à casser un site) et garantissez que chaque migration Drupal majeure suit le même scénario éprouvé.
Configuration des plugins migrate pour le transfert de contenu structuré
Lorsque vous migrez d’une ancienne version de Drupal (par exemple Drupal 7) vers Drupal 10 ou 11, la Migrate API devient centrale pour gérer le transfert de contenu structuré. Les plugins source, process et destination vous permettent de définir précisément comment chaque type de contenu, taxonomie, fichier ou utilisateur est extrait, transformé et chargé. Vous décrivez ces règles dans des fichiers YAML de migration, qui documentent noir sur blanc les correspondances entre l’ancien schéma et le nouveau. C’est un peu l’équivalent d’un plan d’architecte pour un chantier : sans plan, les murs risquent de ne pas tomber au bon endroit.
En pratique, l’utilisation des modules migrate_drupal et migrate_drupal_ui permet de générer une partie de ces migrations automatiquement, surtout pour les scénarios Drupal 7 → Drupal 10. Cependant, dès que la structure cible diffère de la structure source (nouveaux types de contenus, champs fusionnés, entités personnalisées), vous devrez adapter ou écrire vos propres plugins process pour gérer les transformations. Pensez à isoler les règles métier spécifiques (par exemple, la transformation d’un champ texte libre en référence d’entité) afin de pouvoir les tester et les faire évoluer indépendamment. Vous limitez ainsi les surprises lors des réimportations.
Gestion des migrations incrémentales avec migrate_tools et migrate_plus
Les modules migrate_tools et migrate_plus enrichissent l’API de migration Drupal avec des commandes et des fonctionnalités avancées, particulièrement utiles pour les projets volumineux. Grâce à migrate_tools, vous pouvez lancer, arrêter, reprendre ou réinitialiser des migrations en ligne de commande (drush migrate:import, migrate:rollback, etc.). Cela ouvre la porte aux migrations incrémentales, où vous importez d’abord un sous-ensemble de données (par exemple, un seul type de contenu), puis vous étendez progressivement la portée. Cette approche par itérations réduit le risque opérationnel et permet de valider chaque brique avant de passer à la suivante.
migrate_plus apporte quant à lui des améliorations de configuration (groupes de migrations, sources externes, plugins supplémentaires) qui simplifient la gestion de scénarios complexes. Vous pouvez, par exemple, regrouper toutes les migrations liées aux utilisateurs dans un même groupe et les déclencher en une seule commande. Dans le contexte d’une mise à jour majeure de Drupal, ces outils vous permettent de concevoir un processus de migration plus souple : vous pouvez rejouer certaines migrations sans repartir de zéro, traiter des volumes importants par lots, ou maintenir deux environnements synchronisés pendant une phase de transition grâce à des imports réguliers.
Scripts personnalisés pour les entités complexes et les champs paragraphs
Les entités complexes et les champs Paragraphs posent souvent problème lors d’une migration Drupal majeure, car ils impliquent des structures de données imbriquées et des relations multiples. Lorsque les plugins Migrate standard ne suffisent plus, vous devrez recourir à des scripts personnalisés en PHP, exécutés via drush scr ou intégrés directement dans des plugins process spécifiques. Ces scripts vous permettent, par exemple, de reconstituer des arborescences de Paragraphs, de fusionner plusieurs champs en un seul, ou de transformer des structures non normalisées en entités pleinement compatibles avec Drupal 10 ou 11.
Imaginez la migration de pages construites avec des Paragraphs imbriqués depuis un site ancien vers un nouveau modèle de mise en page basé sur Layout Builder. Vous devrez parfois « traduire » des configurations très spécifiques en une nouvelle logique plus moderne. Dans ce cas, un script personnalisé peut parcourir chaque nœud, analyser la structure des Paragraphs associés et générer les entités correspondantes dans le nouveau schéma. Cette approche demande du temps et des tests, mais elle offre un contrôle très fin sur le résultat final. Vous évitez ainsi de perdre des contenus riches ou de les simplifier à outrance par manque d’outils adaptés.
Refactorisation du code legacy et mise à jour des dépendances
Adaptation des hooks dépréciés vers le système d’événements symfony
Avec l’évolution de Drupal vers une architecture basée sur Symfony, de nombreux hooks historiques ont été dépréciés au profit du système d’événements. Pour gérer une mise à jour majeure de Drupal sans casser vos modules custom, il est crucial d’identifier ces hooks et de les migrer vers des subscribers d’événements. Concrètement, au lieu d’implémenter hook_entity_insert() dans un fichier .module, vous créez un service qui implémente EventSubscriberInterface et écoute l’événement adéquat. Cette transition renforce l’encapsulation, facilite les tests unitaires et s’aligne sur les bonnes pratiques Symfony.
L’analogie avec l’électricité est parlante : les hooks ressemblent à des fils que vous branchez directement sur la prise, tandis que les événements sont comme un tableau électrique bien organisé, où chaque disjoncteur a un rôle clair. Pour repérer les hooks obsolètes, vous pouvez combiner l’analyse statique (PHPStan, drupal-check) et les outils comme Drupal Rector, qui proposent parfois des refactorisations semi-automatiques. N’oubliez pas de documenter les nouveaux événements utilisés et de mettre à jour vos tests fonctionnels pour vérifier que le comportement métier reste identique après la migration.
Conversion des modules obsolètes utilisant l’API entity vers l’entity API moderne
Les modules personnalisés écrits à l’époque de Drupal 7 ou des premières versions de Drupal 8 reposent souvent sur des patterns Entity API qui ont depuis évolué. Pour assurer une compatibilité complète avec Drupal 10 et 11, vous devrez moderniser la définition de vos entités : annotations à jour, gestion des handlers, plugins, schéma de champs, et respect des interfaces modernes (ContentEntityInterface, ConfigEntityInterface, etc.). Ce travail de conversion peut sembler fastidieux, mais il offre l’occasion d’un grand ménage : suppression de propriétés inutilisées, normalisation des noms de champs, clarification des responsabilités entre entités et services.
Commencez par identifier toutes les entités custom (contenu, config, bundles Paragraphs, etc.) et vérifiez leur définition dans les fichiers *.entity.php ou via les annotations dans les classes. Comparez-les avec la documentation officielle de l’Entity API moderne pour repérer les écarts (utilisation de propriétés baseFieldDefinitions(), gestion des références, formulaires d’édition, etc.). Vous pouvez ensuite progresser entité par entité, en écrivant des tests pour garantir que la conversion n’altère pas les données ni les écrans d’édition. Au final, vos modules seront plus robustes et plus simples à faire évoluer lors des prochaines mises à jour majeures de Drupal.
Migration des layouts display suite vers layout builder natif
Display Suite a longtemps été la référence pour gérer des mises en page avancées dans Drupal, mais l’arrivée de Layout Builder dans le core a rebattu les cartes. Lors d’une migration Drupal 9 vers Drupal 10 ou 11, il est souvent pertinent de profiter de l’opération pour basculer progressivement vers Layout Builder. Cela implique de cartographier vos affichages Display Suite existants (view modes, templates, régions) et de concevoir des variantes équivalentes avec Layout Builder. Le but n’est pas forcément de reproduire à l’identique chaque détail, mais plutôt de tirer parti des nouvelles possibilités offertes par le core (sections, blocs réutilisables, workflows d’édition plus souples).
Cette migration peut se faire par étapes : commencez par un ou deux types de contenus stratégiques, activez Layout Builder dessus, recréez la structure globale, puis comparez visuellement le rendu avec celui de Display Suite. Vous pouvez utiliser des scripts ou des migrations pour automatiser le transfert de certains paramètres (par exemple, des champs mappés sur des blocs). Là encore, pensez à impliquer les équipes métiers et éditoriales : une modification de layout ne se résume pas à un changement technique, elle peut affecter le travail quotidien des contributeurs. En anticipant ces impacts, vous transformez la mise à jour majeure de Drupal en levier d’amélioration de l’expérience d’édition.
Mise à jour des bibliothèques JavaScript et intégration de CKEditor 5
Les versions récentes de Drupal ont profondément modernisé la stack front-end, notamment avec l’intégration de CKEditor 5 et la mise à jour de nombreuses bibliothèques JavaScript. Pour réussir une migration Drupal majeure, vous devez vérifier que votre thème et vos modules custom n’utilisent pas d’APIs JS obsolètes : jQuery non maintenu, plugins CKEditor 4 spécifiques, scripts inline non compatibles avec les politiques de sécurité modernes (CSP). Le passage à CKEditor 5, en particulier, nécessite d’adapter vos plugins custom, boutons d’édition et formats de texte, car l’API a été largement repensée.
Abordez cette migration comme la rénovation d’un moteur : plutôt que de patcher un vieux code JS, profitez-en pour vérifier la pertinence de chaque script, supprimer ceux qui ne sont plus utilisés, et basculer vers des pratiques plus modernes (ES6, bundlers, librairies légères). Pour CKEditor 5, listez les fonctionnalités réellement utilisées (styles, médias, tableaux, plugins personnalisés) et reproduisez-les dans la nouvelle configuration, en vous appuyant sur la documentation officielle. Si vous avez des modules custom qui étendent l’éditeur, prévoyez du temps pour réécrire leurs intégrations. Une fois le chantier terminé, vous disposerez d’un front-end plus performant, plus sécurisé et plus simple à maintenir.
Gestion des configurations avec configuration management et drush config
La gestion de configuration est un axe central des mises à jour majeures de Drupal. Le système Configuration Management, basé sur des fichiers YAML, permet de versionner les réglages du site (types de contenus, vues, permissions, formats de texte, etc.) et de les déployer de façon contrôlée entre environnements. Avant toute migration, assurez-vous que votre projet exploite correctement ce mécanisme : répertoire config_sync configuré dans settings.php, export régulier de la config via drush cex, et intégration de ces fichiers dans votre dépôt Git. Sans cette base, il devient très difficile de reproduire fidèlement un environnement lors d’une montée de version majeure.
Lors de la migration, la séquence idéale consiste à : mettre à jour le code (Composer), exécuter les mises à jour de la base (drush updb), puis importer la configuration attendue (drush cim). Cette approche garantit que la structure de la base est alignée sur les nouvelles entités et schémas avant d’appliquer des changements de configuration. Pour les environnements complexes (multisites, déploiements parallèles), vous pouvez recourir aux modules comme Config Split ou Config Ignore pour gérer des variations locales (par exemple, des modules activés uniquement en dev ou des clés API différentes). En combinant ces outils avec Drush Config, vous transformez la gestion de configuration en véritable pipeline contrôlé, plutôt qu’en série de clics manuels en back-office.
Testing et déploiement : environnements de staging et rollback strategy
Une mise à jour majeure de Drupal ne devrait jamais être testée directement en production. La mise en place d’environnements de staging (préproduction, QA, UAT) est indispensable pour valider le comportement du site dans des conditions proches du réel. Cloner le code, la base de données et les fichiers de production vers un environnement de recette vous permet de simuler la migration complète : exécution des commandes Composer, Drush, scripts de migration, tests fonctionnels et de performance. Vous pouvez ainsi détecter les régressions fonctionnelles, les problèmes d’affichage ou les erreurs de configuration avant qu’ils n’affectent vos utilisateurs finaux.
En parallèle, définissez une stratégie de rollback claire. Que se passe-t-il si la migration échoue en milieu de processus ? Avez-vous une sauvegarde complète (code, base, fichiers) de la production immédiatement avant l’opération ? Le plan de retour arrière doit être documenté et testé, par exemple en restaurant un snapshot sur un environnement isolé. Pour les sites critiques, certaines équipes optent pour une approche « blue/green deployment » : une nouvelle instance du site migré est préparée en parallèle, puis le basculement se fait au niveau du DNS ou du load balancer. De cette manière, il est possible de revenir rapidement en arrière en cas de problème majeur.
Optimisation post-migration : cache redis, CDN et monitoring des performances
Une fois la migration Drupal majeure terminée et stabilisée, l’étape suivante consiste à optimiser les performances de la plateforme. L’activation d’un cache backend comme Redis pour les caches binaires (cache, bootstrap, discovery, etc.) permet de réduire la charge sur la base de données et d’améliorer la réactivité globale. Couplé aux modules redis et à une configuration adaptée dans settings.php, ce dispositif offre un gain significatif sur les sites à fort trafic. Vous pouvez aussi affiner la configuration de Dynamic Page Cache et BigPipe pour tirer parti des nouvelles optimisations de Drupal 10 et 11.
Un CDN (Content Delivery Network) complète ce dispositif en rapprochant les ressources statiques (images, CSS, JS) de vos utilisateurs finaux. Après une mise à jour majeure de Drupal, où les bibliothèques front et les chemins d’accès peuvent avoir changé, vérifiez que votre CDN est correctement configuré : règles de cache, invalidations, headers Cache-Control et ETag. Enfin, mettez en place un monitoring des performances et des erreurs applicatives (New Relic, Blackfire, ELK, etc.) pour détecter rapidement les goulots d’étranglement ou les erreurs résiduelles liées à la migration. Gérer les mises à jour majeures de Drupal ne s’arrête pas au jour du déploiement : c’est un cycle continu d’observation, d’optimisation et d’amélioration progressive de votre écosystème Drupal.