Symfony et Drupal : anticiper les dépréciations dans vos modules custom

Pourquoi les dépréciations Symfony brisent silencieusement vos modules Drupal

Drupal intègre Symfony comme dépendance Composer. Chaque version majeure de Drupal vient avec une version majeure de Symfony : Drupal 9 avec Symfony 4/5, Drupal 10 avec Symfony 6, Drupal 11 avec Symfony 7. Ce couplage est géré par la core team — mais vos modules custom, personne ne les maintient à part vous.

PHP signale les dépréciations via des notices E_USER_DEPRECATED. Ces messages n'interrompent pas l'exécution. En développement, si votre configuration error_reporting ne capture pas ce niveau, vous ne voyez rien. En production, ces notices partent dans les logs système. Quand la méthode dépréciée est supprimée dans la version suivante de Symfony, votre code lève une erreur fatale. Et c'est seulement là que vous réalisez que le problème existait depuis des mois.

Les composants les plus souvent en cause dans les modules custom : EventDispatcher (signature des écouteurs), DependencyInjection (nommage des services), HttpFoundation (méthodes sur Request, Response, Session), Console (signature de Command::execute()), et Serializer.

Étape 1 — Inventaire : cartographier les usages Symfony dans votre code

La commande la plus directe :

grep -rn "use Symfony\\" web/modules/custom/ --include="*.php" | sort | uniq

Vous obtenez la liste exhaustive de chaque import Symfony dans votre code custom. Complétez avec le module contrib Upgrade Status, disponible sur Drupal.org :

composer require drupal/upgrade_status --dev
drush en upgrade_status -y

Rendez-vous sur /admin/reports/upgrade-status pour le tableau de bord. Ajoutez Drupal Rector (palantirnet/drupal-rector) pour la détection et la correction automatisée des patterns dépréciés les plus courants :

vendor/bin/rector process web/modules/custom/ --dry-run

Consolidez les résultats dans une matrice de risque : module, composant Symfony, méthodes concernées, version de suppression, priorité. Cette matrice devient votre backlog technique.

Étape 2 — Détecter les dépréciations actives à l'exécution

L'inventaire statique ne suffit pas — certaines dépréciations ne se manifestent qu'à l'exécution. En environnement de développement, redirigez les dépréciations vers un log dédié :

set_error_handler(function ($errno, $errstr) {
  if ($errno === E_USER_DEPRECATED || $errno === E_DEPRECATED) {
    error_log('[DEPRECATED] ' . $errstr . PHP_EOL, 3, '/tmp/drupal_deprecations.log');
  }
  return false;
}, E_ALL);

Pour les tests automatisés, symfony/phpunit-bridge transforme les dépréciations détectées pendant l'exécution des tests en échecs de test — ce qui vous permet d'intégrer la détection dans votre pipeline CI.

composer require --dev symfony/phpunit-bridge

Complétez avec drush core:requirements pour les vérifications de compatibilité intégrées à Drupal core.

Étape 3 — Tests de non-régression : verrouiller ce qui fonctionne

Corriger une dépréciation sans test de non-régression, c'est risquer de casser autre chose. Pour chaque module custom identifié dans votre matrice de risque, ciblez en priorité :

• Les EventSubscribers : vérifier que vos abonnés aux événements sont appelés et produisent l'effet attendu
• Les services injectés : tester l'interface publique de chaque service custom qui délègue à Symfony
• Les routes et contrôleurs HTTP : tester les réponses attendues avec BrowserTestBase

Configurez votre pipeline CI pour que les nouvelles dépréciations fassent échouer la suite de tests. L'objectif : qu'aucun code porteur de dépréciation non corrigée ne puisse atteindre la branche principale. Concentrez les efforts sur les chemins critiques (authentification, soumission de formulaires, synchronisation de données) plutôt que sur la couverture exhaustive.

Étape 4 — Calendrier d'exécution : transformer l'analyse en plan d'action

Drupal publie ses dates de fin de support sur drupal.org. Ces dates sont fermes. Une migration de version majeure implique une montée de Symfony : toute dépréciation marquée pour suppression dans la version cible de Symfony doit être corrigée avant de lancer la montée de version Drupal.

Séquence de travail typique pour un parc de 3 à 5 modules custom :

• Sprint 1 (1-2 jours) : scan complet, matrice de risque, scoring critique / élevé / faible
• Sprint 2 (1-2 semaines) : corrections critiques avec Rector + tests de non-régression
• Sprint 3 (1-2 semaines) : corrections élevées, code review, documentation interne
• Sprint 4 (1 semaine) : staging avec la version Drupal cible, tests fonctionnels, validation métier

Après la migration, instaurez un scan trimestriel : relancer Rector en dry-run sur les modules custom, relancer Upgrade Status après chaque mise à jour Drupal core, consulter les changelogs des composants Symfony utilisés.

Ce que cette méthode vous évite concrètement

Sans démarche structurée, les organisations se retrouvent dans l'un de ces deux scénarios. Le premier : la découverte en prod. La montée de version est testée sur staging avec l'ancienne stack, puis déployée — et ce n'est qu'en production que les modules custom lèvent des erreurs fatales. Le second : la dette qui s'accumule. Personne ne gère les dépréciations parce que le site fonctionne, jusqu'à ce que la migration devienne inévitable avec un coût démultiplié.

La méthode présentée ici transforme un risque à gérer dans l'urgence en un travail continu à faible coût unitaire.

Ce qu'il faut retenir

Les dépréciations Symfony dans vos modules Drupal custom ne se gèrent pas à la veille d'une migration — elles se gèrent en continu, avec des outils adaptés et un calendrier ancré sur les dates de release officielles. Les quatre étapes sont séquentielles et complémentaires : inventaire, détection à l'exécution, tests de non-régression, calendrier d'action.

Si vous voulez évaluer l'exposition de vos modules custom avant votre prochaine montée de version, demandez un diagnostic.