# Contrôler qu’aucune fonction dépréciée de PHP 8.4 ne subsiste dans le code > Ajouter une vérification statique en CI qui échoue si le code appelle encore une fonction ou une syntaxe dépréciée par la version cible de PHP, avant qu'elle ne devienne une erreur fatale. - Auteur : Clément Hadrot - Publié le : 2025-07-15 - Mis à jour le : 2025-07-15 - Catégorie : Tests - URL : https://wpmoderne.dev.wordpress-developpement.fr/tests/controler-fonctions-depreciees-php-8-4-ci/ ## L’essentiel - Une dépréciation ignorée aujourd'hui devient une erreur fatale demain - PHPCompatibility détecte l'usage avant l'exécution réelle - Un rapport de dépréciation en CI vaut mieux qu'un log de production 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-installer ``` La 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 : ``` src/ ``` ## Exécuter le contrôle et lire un rapport concret > L'essentiel à retenir : Une dépréciation ignorée aujourd'hui devient une erreur fatale demain ; PHPCompatibility détecte l'usage avant l'exécution réelle ; Un rapport de dépréciation en CI vaut mieux qu'un log de production ``` 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.