Drupal 11 : audit de compatibilité de vos modules et thèmes existants

Pourquoi l'audit précède toujours le chiffrage

Un projet de migration estimé sans audit de compatibilité est un projet sous-estimé. La source de dépassement la plus fréquente dans les projets Drupal est exactement celle-là.

La raison est structurelle. L'effort de migration dépend essentiellement de deux facteurs que personne ne peut deviner de l'extérieur :

• L'état réel du parc de modules installés : certains sont compatibles Drupal 11, d'autres nécessitent un travail, d'autres n'ont plus de mainteneur actif.
• La quantité et la qualité du code custom : thème sur mesure, modules développés en interne, hooks personnalisés, préprocesseurs.

Pour un responsable de parc multi-sites, l'enjeu est encore plus fort : sans audit systématique, vous ne pouvez pas prioriser. Quel site migre en premier ? Lequel présente le moins de risques ? Lequel peut partager les développements de mise à niveau avec un autre ?

Étape 1 — Faire l'inventaire de l'écosystème en place

La commande la plus fiable pour lister tous les modules activés :

drush pml --type=module --status=enabled --format=json

Une fois la liste obtenue, classez chaque entrée dans l'une de ces trois catégories :

• Core : modules et thèmes livrés avec Drupal, compatibilité garantie.
• Contrib : modules et thèmes issus de la communauté (drupal.org), à vérifier module par module.
• Custom : code développé en interne ou par votre prestataire, à auditer en profondeur.

Étape 2 — Installer et exécuter Upgrade Status

Upgrade Status (drupal/upgrade_status) est le module officiel pour analyser la compatibilité d'un site Drupal avec une version cible. Il interroge les API drupal.org pour chaque module contrib et analyse le code custom via drupal-check.

composer require drupal/upgrade_status --dev
drush en upgrade_status

Le module génère une liste complète de vos modules et thèmes avec un statut :

• Compatible : une version Drupal 11 existe et est stable.
• Analyse requise : une version est en développement ou la compatibilité n'est pas confirmée.
• Incompatible : aucune version Drupal 11 disponible ou le module utilise des API supprimées.
• Abandonné : le projet n'est plus maintenu sur drupal.org.

Étape 3 — Qualifier l'état de chaque module contrib

Pour les modules en développement, la question est : dans combien de temps la version stable sera-t-elle disponible ? S'il n'y a aucun commit depuis six mois sur la branche 11.x, ne comptez pas sur cette version pour votre fenêtre de migration.

Pour les modules abandonnés, la démarche de remplacement suit toujours le même ordre :

1. Le core Drupal 11 couvre-t-il le besoin ?
2. Existe-t-il un fork maintenu ?
3. Un module alternatif couvre-t-il le même besoin ?
4. Faut-il développer un remplacement sur mesure ?

Étape 4 — Auditer le code custom et les thèmes sur mesure

drupal-check analyse le code PHP d'un module ou d'un thème et liste les usages d'API dépréciées :

composer require --dev mglaman/drupal-check
./vendor/bin/drupal-check web/modules/custom/mon_module/

Points d'attention spécifiques à Drupal 11 :

• CKEditor 4 vers CKEditor 5 : les plugins CKEditor 4 n'ont pas d'équivalent automatique en CKEditor 5, chaque plugin personnalisé doit être porté manuellement.
• jQuery UI supprimé du core : tout code custom qui dépend de widgets jQuery UI doit être migré vers des alternatives.
• Hooks de rendu dépréciés : plusieurs hooks liés au cycle de rendu ont été dépréciés entre Drupal 9 et 11.

Étape 5 — Mettre en place un environnement de test réaliste

Un environnement de test réaliste doit respecter ces conditions :

• Même version PHP que la cible : Drupal 11 requiert PHP 8.3 minimum.
• Même base de données : une copie récente de la base de production, anonymisée si nécessaire.
• Même configuration : les fichiers exportés de production via drush config:export.

Étape 6 — Gérer les extensions abandonnées

Quatre postures possibles face aux modules sans mainteneur :

1. Remplacer par une alternative du core ou contrib : la voie préférable.
2. Devenir co-mainteneur ou fork : pour un module critique avec une base d'utilisateurs encore active.
3. Désactiver et supprimer : si la fonctionnalité n'est plus réellement utilisée.
4. Développer un module de remplacement sur mesure : en dernier recours, lorsqu'aucune alternative n'existe.

Étape 7 — Consolider le rapport d'audit et estimer l'effort

La sortie de l'audit est un document structuré, base de chiffrage. Il doit contenir pour chaque module son statut de compatibilité, la décision prise, et une estimation de l'effort en jours/développeur.

Pour un parc multi-sites, le rapport permet de prioriser l'ordre des migrations selon deux axes : le risque (sites les plus exposés) et l'effort (sites dont la migration sera la moins coûteuse).

Ce que l'audit ne fait pas à votre place

Un audit de compatibilité répond à la question « quoi » et « combien ». Il ne produit pas la migration. Trois éléments restent à décider :

• La stratégie de migration progressive ou en une fois.
• La gestion du contenu pendant la migration.
• La validation fonctionnelle avec les utilisateurs métier.