Ce plan en cinq temps répond à cette question, pour les DSI, CTO et tech leads Drupal qui gèrent des sites à forte visibilité.
1. Cadrer l'objectif et le timing avant de toucher à quoi que ce soit
PHP 8.x n'est pas une migration all-or-nothing. La trajectoire recommandée est par palier : stabiliser sur une version 8.x mineure avant de viser PHP 8.5. Chaque palier réduit le périmètre de régression à absorber d'un coup.
Avant de démarrer, posez quatre dates dans le calendrier — les quatre temps forts du projet :
- Audit de compatibilité
- Remédiation code et dépendances
- Montée d'environnement (hors production)
- Bascule et suivi post-mise en ligne
Puis définissez vos critères de go/no-go : quelle couverture de tests minimale est requise ? Quels modules critiques doivent être validés avant la bascule ? Quelles extensions système (OPcache, intl, mbstring) sont disponibles sur l'hébergement cible ?
Ces trois critères ne sont pas des cases à cocher : ce sont les garde-fous qui évitent de basculer dans le vide.
2. Cartographier la compatibilité — Drupal core, contrib, infra
C'est l'étape la plus souvent bâclée. Et c'est là que se joue la suite.
Core et modules contributed. Lancez un composer why-not php ^8.5 sur votre projet. Le résultat liste chaque package qui bloque la montée de version. Pour chaque module critique en décalage : vérifier si une version de développement supporte déjà PHP 8.5 ; ouvrir une issue sur drupal.org si ce n'est pas le cas ; prévoir un fork temporaire si le module ne peut pas attendre, en documentant l'écart pour la reprise ultérieure.
Thèmes et code custom. Identifier les APIs PHP dépréciées entre votre version actuelle et PHP 8.5. Les patterns sensibles à repérer en priorité : les fonctions dépréciées de manipulation de tableaux et de chaînes, les comportements des comparaisons de types entre entiers et chaînes qui ont évolué à partir de PHP 8.0, et les signatures de méthodes incompatibles avec le typage union introduit plus tard.
Hébergement et infrastructure. Vérifiez la disponibilité de PHP 8.5 sur votre environnement cible. Si votre hébergeur ne le supporte pas encore, c'est le moment d'ouvrir la conversation — pas la nuit avant la mise en production.
3. Assainir le code : dépréciations et typage fort
PHP 8.x durcit progressivement le typage et supprime ce qui était toléré dans les versions antérieures. Sur un projet Drupal mature, ce nettoyage est souvent plus long que prévu — et c'est normal.
Sortir les dépréciations. Activez le niveau de rapport d'erreur PHP le plus verbeux sur vos environnements de développement et de test. Chaque Deprecated: dans les logs est une régression en attente. Traitez-les par lot, en commençant par le code custom puis par les modules contributed.
Adopter les types stricts. declare(strict_types=1) en tête de fichier PHP est un choix de qualité : il force le contrat entre les fonctions et leurs appelants. Sur un code existant, l'introduction se fait progressivement, fichier par fichier, pour éviter les régressions en cascade.
Faire tourner Rector. L'outil de refactoring automatique Rector dispose de rulesets spécifiques à Drupal et à PHP 8.x. Il prend en charge la mécanique répétitive — renommage, migration de syntaxe — et laisse les revues humaines sur les cas ambigus. C'est un gain de temps réel sur un volume de code important.
4. Fiabiliser l'environnement : CI/CD, tests et stratégie de rollback
Une migration PHP sans filet est une migration à risque. Ce filet, c'est votre pipeline de CI/CD.
Tester sur la cible avant de migrer. Configurez un job CI qui fait tourner votre suite de tests contre PHP 8.5. Faites-le tourner en parallèle de votre job principal, sans bloquer les déploiements en production : l'objectif est de mesurer l'écart, pas de bloquer la livraison avant d'avoir fini la remédiation.
Couvrir ce qui compte vraiment. Les tests de régression les plus utiles ne sont pas les tests unitaires des fonctions utilitaires : ce sont les tests des parcours critiques (authentification, workflows métier, exports, intégrations API). Si ces parcours ne sont pas couverts, c'est le moment de les écrire — avant la migration, pas après.
Prévoir le rollback. La bascule PHP se fait au niveau de l'infrastructure, pas du code. Avoir un snapshot de votre environnement de production avant la mise à jour, et savoir exactement comment y revenir en moins de quinze minutes, est un impératif. Documentez cette procédure et testez-la en staging — une fois qu'on en a besoin, il est trop tard pour la construire.
5. Piloter la bascule en production et assurer le suivi post-migration
La mise en production se prépare comme une opération chirurgicale : périmètre défini, équipe disponible, critères d'abort identifiés.
La fenêtre de bascule. Choisissez un créneau à faible trafic. Basculez PHP sur l'infrastructure, surveillez les premiers logs d'erreur en temps réel, parcourez les pages critiques, déclenchez une série de tests automatisés en production. Si les indicateurs sont verts au bout d'une demi-heure : vous avez réussi.
Le suivi post-migration. PHP 8.5 apporte des gains de performance mesurables — mais ils ne se mesurent qu'avec les bons indicateurs en place avant la migration. Munissez-vous d'un baseline de vos métriques applicatives (temps de réponse, consommation mémoire, taux d'erreur) avant de basculer. La comparaison avant/après est votre preuve — et votre argument en cas de question de la direction.
Les premières semaines. Maintenez une vigilance renforcée sur les logs et les alertes pendant deux à trois semaines après la bascule. Les régressions tardives arrivent souvent sur des chemins de code peu fréquentés, activés par des workflows métier occasionnels ou des batchs nocturnes.
PHP 8.5 et Drupal : une migration qui se prépare, pas qui s'improvise
La compatibilité PHP 8.5 n'est pas une case à cocher dans un sprint. C'est un projet de fond, avec ses dépendances, ses critères de go/no-go et son propre rythme. Les équipes qui réussissent ce type de montée de version sont celles qui l'ont planifiée comme une migration — pas comme un simple passage de numéro de version.
Si votre socle Drupal mérite ce niveau d'attention, la première étape est un diagnostic honnête de l'état de votre stack : compatibilité réelle, couverture de tests, maturité de votre pipeline CI/CD. Partez de là, pas des spécifications PHP.