Checklist technique pour une montée de version Drupal 11 sans interruption

Pourquoi Drupal 11 exige une approche structurée

Drupal 11 introduit des ruptures de compatibilité significatives : abandon des dépendances Symfony héritées de Drupal 10, suppression des API dépréciées depuis plusieurs cycles, exigences PHP 8.3+ et changements dans la gestion des hooks. Un module contrib non mis à jour peut suffire à bloquer l'ensemble du site après l'upgrade.

La bonne méthode n'est pas d'attendre que tout soit parfait. C'est de cartographier les risques avant d'agir, puis de neutraliser chaque point de blocage dans l'ordre.

Phase 1 — Avant la migration : les points de contrôle critiques

1.1 Audit de compatibilité des modules et thèmes

• Lancez composer audit pour identifier les dépendances avec des vulnérabilités connues.
• Utilisez le module Upgrade Status (drupal/upgrade_status) pour scanner l'ensemble de votre base de code : modules contrib, modules custom, thèmes.
• Exportez le rapport et triez par criticité : bloquant, à adapter, compatible avec avertissement.
• Pour les modules custom, recensez les appels à des API supprimées en Drupal 11.

1.2 Inventaire des dépendances PHP et infrastructure

• Vérifiez la version PHP active : Drupal 11 requiert PHP 8.3 minimum.
• Listez les extensions PHP utilisées et vérifiez leur compatibilité avec la cible.
• Validez que votre serveur web et votre base de données respectent les pré-requis officiels (MariaDB 10.6+ ou MySQL 8.0+).

1.3 Snapshot complet et stratégie de rollback

• Sauvegarde complète de la base de données (fichier exporté, daté, testé en restauration).
• Snapshot du système de fichiers.
• Branche git dédiée à l'upgrade, partant d'un état propre synchronisé avec la production.
• Plan de rollback documenté : qui décide, en combien de temps, quel seuil d'incident déclenche le retour arrière.

1.4 Gel des fonctionnalités en cours

• Identifiez les branches de développement non mergées.
• Gelez les déploiements non liés à l'upgrade au moins 48 h avant l'opération.
• Informez les équipes métier de la fenêtre de maintenance prévue.

1.5 Revue de la configuration active

• Exportez la configuration (drush cex) et archivez-la dans git.
• Vérifiez les surcharges de configuration : elles doivent être compatibles avec les nouveaux schémas Drupal 11.

Phase 2 — Pendant la migration : séquence et points de contrôle

2.1 Environnement de staging identique à la production

Ne jamais tester un upgrade uniquement en local. Répliquez la base de données et les fichiers de production sur le staging. L'objectif : que la migration en staging soit le dry-run de la migration en production.

2.2 Séquence d'upgrade Composer

Mettez à jour le core avec composer require drupal/core-recommended:^11.x --update-with-all-dependencies, vérifiez les conflits avant d'appliquer, puis résolvez les modules contrib non compatibles un par un. N'appliquez jamais un composer update global sans contrôler ce qui change.

2.3 Exécution des mises à jour de base de données

Exécutez drush updb --yes, puis drush cim --yes et drush cr. Vérifiez les logs Drush après updb : chaque hook_update_N doit passer sans erreur.

2.4 Tests fonctionnels sur le staging

Avant de toucher à la production, validez : connexion administrateur et utilisateur standard, formulaires critiques, flux d'authentification SSO/OAuth si présents, appels API sortants, affichage des contenus typiques, performances de base et absence d'erreurs PHP dans les logs.

2.5 Déploiement en production : mode maintenance et séquence

Activez le mode maintenance, exécutez dans l'ordre : composer install → drush updb → drush cim → drush cr → désactivation du mode maintenance. Durée cible : moins de 15 minutes. Monitorez les logs en temps réel pendant les 30 premières minutes.

Phase 3 — Après la migration : vérification et stabilisation

3.1 Surveillance post-déploiement (les 72 premières heures)

• Activez les alertes sur le taux d'erreurs HTTP 5xx et les erreurs PHP.
• Vérifiez les logs Watchdog quotidiennement pendant 3 jours.
• Contrôlez les performances et les intégrations tierces.

3.2 Validation du bon état du cache et des configurations

• Vérifiez que les stratégies de cache Drupal sont actives et fonctionnelles.
• Contrôlez les règles de purge côté CDN si applicable.

3.3 Mise à jour de la documentation TMA

Si la plateforme est sous contrat de TMA Drupal, documentez la version Drupal active, les modules mis à jour, remplacés ou supprimés, les nouvelles exigences infrastructure et les points d'attention pour les prochains cycles.

3.4 Revue de sécurité post-migration

• Relancez composer audit sur le nouveau lockfile.
• Vérifiez les avis de sécurité Drupal publiés depuis votre dernière revue.
• Contrôlez les permissions des fichiers sensibles (settings.php, services.yml).

Ce que cette checklist ne remplace pas

Une checklist est un garde-fou, pas un substitut à l'expérience. La connaissance du contexte applicatif — modules custom, intégrations tierces non documentées, logique métier enfouie — reste irremplaçable. Et la décision de quand faire l'upgrade ne se reporte pas indéfiniment : Drupal 10 est en fin de vie en décembre 2025.