The Php Times

Les RFCs de déprécation pour PHP 8.6 sont approuvées. Bien qu'aucun code ne casse dans la nouvelle version, les fonctions obsolètes génèrent des avertissements facilement ignorés—surtout quand les paquets externes les déclenchent dans des chemins de code fréquemment exécutés.

Dans les projets avec logging au niveau Notice (courant dans les configurations Laravel), chaque appel déprécié inonde les logs, augmentant la consommation disque et les coûts d'ingestion. Les équipes diagnostiquent souvent cela comme un problème d'infrastructure plutôt que de modernisation, retardant la correction réelle.

Le point de friction central concerne les paquets externes. Le code personnel se met à jour rapidement, et des outils comme Rector automatisent une grande partie. Les dépendances externes sans versions PHP-8.6-ready continuent à émettre des avertissements jusqu'au correctif du mainteneur—un délai hors du contrôle direct.

Une approche pragmatique : activer E_DEPRECATED comme erreur en CI avant le déploiement. Cela détecte les déprécations lors des tests, pas après leur arrivée en production. Une implémentation minimale convertit les avertissements en exceptions :

error_reporting(E_ALL); set_error_handler(function ($errno, $errstr, $errfile, $errline) { if ($errno === E_DEPRECATED || $errno === E_USER_DEPRECATED) { throw new \ErrorException($errstr, 0, $errno, $errfile, $errline); } return false; });

Ceci transforme les avertissements de déprécation en erreurs de test rigoureux, empêchant qu'ils ne saturent silencieusement les logs de production. Le débat communautaire reste ouvert : implémenter des portes CI strictes pour les déprécations, ou tolérer le bruit en attendant les ressources de correction.