Ce que signifie « bêta » pour votre roadmap
Une bêta dans le cycle de Drupal n'est pas une version expérimentale réservée aux enthousiastes. C'est un jalon technique précis : la base fonctionnelle est suffisamment stabilisée pour évaluer l'effort d'adaptation. Les API de rupture (breaking changes) sont posées. L'inventaire des dépréciations est consultable. Il reste des corrections à venir, mais le périmètre d'une migration peut déjà être estimé.
Ce que vous pouvez faire dès maintenant :
- Lancer un inventaire réel de vos dépendances (modules, thèmes, intégrations) contre l'état déclaré de Drupal 12
- Qualifier l'effort de chaque écart : mineur (mise à jour de module), moyen (adaptation de code), bloquant (pas encore de version compatible)
- Identifier les jalons de votre organisation qui contraignent le calendrier : audit de sécurité annuel, campagne marketing, renouvellement de contrat d'hébergement
Ce que vous ne devez pas faire :
- Planifier un déploiement en production à partir d'une bêta — les modules contrib ne sont pas tous stabilisés, et des corrections d'API mineurs restent possibles
- Ignorer le signal parce que « la stable n'est pas là » — chaque semaine gagnée maintenant vaut plusieurs semaines économisées à la veille d'une deadline
Cadrer la décision : périmètre, risques, budget
Avant de définir un plan de tests ou de réserver des environnements, la décision de monter sur Drupal 12 doit être cadrée. Pas de manière définitive — les décisions réversibles sont celles qui se prennent tôt — mais suffisamment pour allouer les ressources qui permettront de la mûrir.
Cartographier le périmètre réel
La première erreur des montées de version est de sous-estimer le périmètre. « Nous avons un Drupal » cache souvent plusieurs réalités : des sites distincts avec des SLA différents, des modules contributeurs parfois abandonnés, des développements custom sans documentation, des intégrations tierces (SSO, DAM, CRM, moteur de recherche) qui communiquent avec Drupal via des API qui peuvent avoir changé.
Dressez un tableau avec une ligne par composant, et pour chacun : la criticité métier, l'état de compatibilité Drupal 12 connu, et le responsable technique.
Évaluer les risques
Les risques principaux à identifier :
- Risque de rupture fonctionnelle : un module critique sans version Drupal 12 compatible au moment du go-live
- Risque de régression : un comportement custom qui repose sur une API dépréciée, silencieusement cassé après la mise à jour
- Risque calendaire : une dépendance externe qui prend du retard sur la compatibilité
- Risque d'exploitation : une fenêtre où la version courante n'est plus maintenue en sécurité
Organiser le bac à sable et la batterie de tests
Un environnement de test spécifique Drupal 12 est la condition préalable à toute décision éclairée. Les étapes pratiques : cloner la base de code et la base de données, mettre à jour Drupal core vers 12.x via Composer, identifier les modules en rupture, puis isoler le périmètre fonctionnel minimal à valider.
Checklist de tests à planifier :
- Authentification et gestion des rôles (SSO inclus si applicable)
- Création, édition, publication et dépublication de contenus dans chaque type de contenu utilisé
- Formulaires : soumission, validation, stockage et notifications
- Intégrations tierces : chaque API connectée testée de bout en bout
- Performance : temps de chargement à chaud et à froid, comportement sous charge
- Accessibilité : si votre site est soumis au RGAA ou à des exigences contractuelles
Suivre l'état de préparation de l'écosystème
Un obstacle fréquent dans les montées de version Drupal, ce ne sont pas les modules custom — c'est un module contributeur critique qui n'est pas encore compatible. Surveillez la page officielle drupal.org, les outils communautaires de suivi de compatibilité, et directement les dépôts des modules stratégiques (Webform, Views, Paragraphs, CKEditor, Search API).
Parmi tous les modules de votre inventaire, identifiez la liste courte des « bloquants absolus ». Pour chacun, définissez un plan B : fork actif, portage interne, alternative compatible. Cette liste doit être re-vérifiée à chaque RC et à la sortie de la stable.
Préparer la bascule : processus, communication, réversibilité
Le plan de déploiement doit être écrit, testé à blanc, et approuvé avant le jour J. Documentez la séquence d'opérations, la fenêtre de déploiement, les critères go/no-go, et les tests de fumée post-déploiement.
Toute migration en production doit avoir un plan de retour arrière : snapshot complet de la base de données avant migration, copie de l'ancien état du code, point de contact disponible, durée de surveillance post-déploiement définie. La réversibilité n'est pas un aveu de faiblesse — c'est ce qui rend les décisions de migration acceptables pour les décideurs non techniques.
Ce que vous pouvez faire cette semaine
Sans attendre une décision formelle de migration, quatre actions concrètes peuvent être lancées dès maintenant, à coût marginal :
- Inventaire des composants : un tableau simple (module, version actuelle, état de compatibilité Drupal 12 connu)
- Identification des bloquants : les modules dont une incompatibilité rendrait la migration impossible
- Création d'un environnement bac à sable : une demi-journée de travail technique suffit pour avoir Drupal 12 bêta sur une branche isolée
- Veille sur les RC : s'abonner aux annonces Drupal.org pour être informé des Release Candidates
DrupaLabs accompagne les montées de version Drupal
Chez DrupaLabs, les montées de version ne sont pas traitées comme des projets de maintenance ordinaires. Elles sont l'occasion d'auditer la dette technique accumulée, de simplifier l'architecture quand c'est possible, et de mettre en place les bases d'un système plus robuste.
Notre approche repose sur un diagnostic initial rigoureux : cartographier le périmètre réel, identifier les risques techniques et calendaires, et produire une estimation honnête avant tout engagement.