Drupal 12 en vue : cartographier vos dépendances avant d'acter la bascule

Pourquoi la date de sortie de Drupal 12 n’est pas votre contrainte principale

Drupal 12 sera compatible Symfony 7 et PHP 8.3+. Le saut technique entre Drupal 11 et Drupal 12 est maîtrisé par le projet : l’initiative Drupal Rector automatise une large partie des dépréciations, et la roadmap « Starshot » continue de simplifier l’écosystème. Sur le cœur, la migration est rarement le problème.

Ce qui crée des projets difficiles, des budgets qui dérapent et des freezes forcés, c’est le reste : les modules contrib qui n’ont pas encore de release compatible, les patches appliqués il y a trois ans sur des modules abandonnés, les modules custom qui appellent des APIs dépréciées, les thèmes construits sur des hooks que Drupal 12 supprime.

L’enjeu réel est donc la visibilité. Pas la version. Avant d’arbitrer sur le calendrier, constituez l’image exacte de vos dépendances.

L’inventaire : ce qu’il faut recenser

Un inventaire utile pour une migration Drupal 12 couvre cinq couches distinctes.

1. Les modules contrib actifs

composer show --no-dev liste tout ce que vous déployez. Ce qui compte, c’est ensuite de croiser cette liste avec l’état réel sur Drupal.org : existe-t-il une release compatible Drupal 12 ? Une issue ouverte pour la compatibilité ? Un abandon de maintenance ? L’inventaire est aussi l’occasion de désactiver les modules fonctionnellement inutiles qui continuent de charger du code.

2. Les patches Composer

Listez tous les patches déclarés dans votre composer.json — section extra.patches. Pour chacun : quel module ? Quel bug corrige-t-il ? Ce patch est-il mergé en amont ? Les patches sont la zone d’ombre par excellence : ils s’accumulent, ils ne se documentent pas, et ils cassent silencieusement lors des mises à jour.

3. Les modules custom et les thèmes personnalisés

Recensez chaque module custom et chaque thème avec ses dépendances d’API. Les points à surveiller : hooks supprimés ou restructurés entre Drupal 11 et 12, appels à des classes ou fonctions dépréciées, usage de l’ancien système de form render. Drupal Rector peut automatiser une partie de cette analyse, mais il ne remplace pas la revue humaine sur la logique métier.

4. Les surcharges et preprocessors de theme

Les fonctions hook_preprocess_*, les overrides de templates Twig, les libraries personnalisées : tout cela constitue une surface de risque invisible dans un inventaire standard. Elle mérite sa propre colonne dans votre tableur de suivi.

5. Les intégrations externes

CRM, ERP, PIM, moteur de recherche, CDN : chaque intégration utilise des mécanismes (REST, GraphQL, Event Subscribers, Queue Workers) dont la compatibilité Drupal 12 doit être vérifiée indépendamment.

Classifier les risques : bloquants, remplaçables, à corriger

Bloquants

Une dépendance sans laquelle le projet ne peut pas fonctionner, et pour laquelle il n’existe pas encore de chemin vers Drupal 12. Les bloquants ne se résolvent pas en changeant de date de migration. Ils demandent une action : contribuer au module, le forker, ou trouver une architecture alternative.

Remplaçables

Une dépendance dont la fonction peut être assurée par un module différent, déjà compatible Drupal 12, sans régression fonctionnelle majeure. Les modules remplaçables sont souvent une opportunité d’éliminer de la dette technique.

À corriger

Un module pour lequel une release Drupal 12 existe — ou est en bonne voie — mais qui nécessite une action de votre côté : porter un patch custom, mettre à jour une configuration, adapter une surcharge. Ce sont les éléments les plus prévisibles à budgéter.

La méthode d’inventaire en pratique

Étape 1 — Automatiser le recensement. composer show --no-dev --format=json, drush pm:list --format=json, Update Manager (/admin/reports/updates), et Drupal Rector (vendor/bin/rector --dry-run) sur le code custom.

Étape 2 — Croiser avec Drupal.org. Pour chaque module contrib : release D12 existante ? Issue de compatibilité active ? Module abandonné ? Cette vérification manuelle est incontournable — aucun outil n’agrège fiablement ces statuts en temps réel.

Étape 3 — Documenter dans un tableur de suivi. Pour chaque dépendance : type, fonction, version actuelle, compatibilité D12, statut Drupal.org, classification, action à mener. Ce tableur devient l’outil de pilotage pour les décisions budgétaires.

Étape 4 — Qualifier les modules custom. Passer Rector en mode analyse, documenter les APIs dépréciées utilisées et les hooks susceptibles de disparaître. Cette analyse conditionne les estimations de charge de migration.

Construire un plan de validation incrémental

Phase 1 — Résoudre les bloquants. Contribuer au module upstream, maintenir un fork privé, ou rearchitecturer pour éliminer la dépendance. Cette dernière option est souvent la meilleure à long terme.

Phase 2 — Préparer l’environnement de validation. Mettre en place un environnement Drupal 12 dès que les bloquants sont identifiés — avant qu’ils soient résolus. Cet environnement sert à tester les substituts candidats et identifier les problèmes tôt.

Phase 3 — Migrer les remplaçables. Substituer les modules remplaçables sur l’environnement de validation. Valider fonctionnellement chaque substitution.

Phase 4 — Corriger les modules à corriger. Appliquer les mises à jour, porter les patches, adapter les surcharges. Phase prévisible, parallélisable sur une équipe.

Phase 5 — Validation de bout en bout. Tests de non-régression, validation des performances, vérification des intégrations. Les tests automatisés (Behat, PHPUnit, Playwright) sont déterminants ici.

Les critères de go/no-go

Zéro bloquant ouvert (ou plan de mitigation documenté et acté)
Suite de tests automatisés passante sur l’environnement Drupal 12
Performances de chargement équivalentes au baseline de production (mesuré, pas estimé)
Toutes les intégrations critiques validées en staging
Tous les parcours utilisateurs critiques validés manuellement
Plan de rollback documenté et testé
Monitoring post-bascule activé

Ces critères se discutent en amont avec toutes les parties prenantes — DSI, responsable applicatif, équipe technique, équipe métier.

Ce que l’inventaire révèle souvent

L’inventaire révèle l’histoire du projet : des patches oubliés appliqués en urgence, des modules jamais désactivés, une dette de surcharges accumulée dans les thèmes, des intégrations fragiles avec des appels synchrones sans timeout ou des tokens codés en dur. Une migration bien conduite rend cette dette visible — et budgétable.

Conclusion

La question n’est pas « Quand est-ce que Drupal 12 sort ? » mais « Quelle est notre image de dépendances aujourd’hui, et que faut-il résoudre pour que la bascule soit un choix plutôt qu’une contrainte ? »

L’inventaire, la classification et le plan de validation incrémental transforment une décision opaque en décision documentée, avec des critères de go/no-go clairs et une estimation de charge réaliste.

Commencer maintenant — même si Drupal 12 en production est encore loin dans votre roadmap — c’est se donner le temps de traiter les bloquants sans urgence. Attendre, c’est se retrouver à les traiter sous contrainte.