Sur un parc de sites clients hébergés chez plusieurs infogérants différents, la montée de version PHP n’est jamais synchronisée : certains sites tournent encore en PHP 8.1 quand d’autres sont déjà passés en 8.4. Le code partagé entre ces sites doit donc rester compatible avec la version la plus ancienne tout en anticipant les dépréciations des versions les plus récentes, faute de quoi une fonction encore autorisée mais dépréciée en 8.3 devient une erreur fatale bloquante le jour où l’infogérant du client bascule enfin vers 8.4 sans prévenir personne.
Plutôt que de découvrir ces dépréciations via les logs d’erreur d’un client après une montée de version décidée unilatéralement par son hébergeur, nous avons ajouté une vérification statique systématique en amont, qui échoue le pipeline dès qu’une syntaxe ou une fonction dépréciée pour la cible choisie est détectée.
Mettre en place PHPCompatibility ciblé sur une version précise
composer require --dev phpcompatibility/php-compatibility
composer require --dev dealerdirect/phpcodesniffer-composer-installerLa configuration cible explicitement PHP 8.4 comme version de référence pour la détection des dépréciations, même si le code doit encore fonctionner en 8.1 :
<!-- phpcs.xml -->
<ruleset name="Compatibilite-PHP-8-4">
<config name="testVersion" value="8.1-8.4"/>
<rule ref="PHPCompatibility"/>
<file>src/</file>
</ruleset>Exécuter le contrôle et lire un rapport concret
vendor/bin/phpcs --standard=phpcs.xml src/Sur notre plugin de gestion de rendez-vous, cette commande a détecté un appel resté dans le code depuis des années :
FILE: src/Reservation/Formatteur.php
--------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
--------------------------------------------------------------------
47 | ERROR | Implicitly marking parameter $format as nullable is
| | deprecated since PHP 8.4. Use an explicit nullable
| | type instead.
--------------------------------------------------------------------Le code fautif déclarait un paramètre avec une valeur par défaut à null sans type explicitement nullable, une pratique tolérée depuis longtemps mais désormais dépréciée :
// avant : dépréciée en PHP 8.4
function formater_date( DateTime $date, string $format = null ) { /* ... */ }
// après : type explicitement nullable
function formater_date( DateTime $date, ?string $format = null ) { /* ... */ }Intégrer le contrôle au pipeline GitHub Actions
- name: Vérification des dépréciations PHP 8.4
run: vendor/bin/phpcs --standard=phpcs.xml src/
# ce job échoue le pipeline, il ne se contente pas d'un avertissement ignoréLe choix d’échouer le pipeline plutôt que de se contenter d’un avertissement est délibéré : un avertissement noyé dans les logs de build est systématiquement ignoré au bout de quelques semaines, alors qu’un pipeline rouge oblige à traiter le problème avant fusion.
Prioriser les dépréciations selon leur horizon de suppression
Toutes les dépréciations ne se valent pas. Certaines, comme le changement de comportement des propriétés dynamiques déprécié depuis PHP 8.2, ont déjà un horizon de suppression annoncé. D’autres sont plus récentes et laissent plus de marge. On distingue :
- Urgent : dépréciation dont la suppression est prévue dans la prochaine version majeure déjà planifiée.
- À traiter ce trimestre : dépréciation récente, sans annonce de suppression imminente, mais à corriger avant qu’elle ne s’accumule.
- À surveiller : dépréciation touchant un code très peu utilisé, corrigée à l’occasion d’un autre chantier sur le même fichier.
En résumé
Ce contrôle ne traite pas des nouvelles fonctionnalités de PHP 8.4 comme les property hooks, qui relèvent d’un chantier d’adoption volontaire distinct. Il traite uniquement de la détection préventive d’un code qui cesserait de fonctionner sans avertissement à la prochaine montée de version décidée par un hébergeur, un scénario bien plus fréquent qu’on ne le pense sur un parc de sites clients hétérogène où personne côté agence ne contrôle le calendrier de mise à jour de PHP.
