Le vote groupé sur les dépréciations de PHP 8.6 est clos : 35 RFC distinctes ont été soumises, et la plupart ont été adoptées. Les fonctions dépréciées continuent de fonctionner dans la version 8.6 — elles se contentent d'émettre des avertissements. Cela semble anodin, mais entraîne deux conséquences pratiques.

Premièrement, le volume de logs devient un problème de coût. Sur un projet Laravel en production avec la journalisation des notices activée, une fonction dépréciée située dans un chemin critique appelé des milliers de fois par minute génère un flux de logs continu et cumulatif : espace disque, ingestion dans des systèmes comme Loki ou ELK, et in fine de l'argent. Le symptôme apparaît sous la forme « les coûts de logging ont augmenté », ce qui conduit souvent à le traiter par la mauvaise équipe, des semaines après la mise en production du code fautif.

Deuxièmement, certaines dépréciations échappent à votre contrôle. Votre propre code se corrige vite — des outils comme Rector automatisent une grande partie du travail — mais les paquets vendors sans version compatible 8.6 continueront de polluer les logs jusqu'à ce que le mainteneur publie un correctif, selon un calendrier qui ne vous appartient pas. Sur un stack riche en dépendances, cela peut signifier des semaines de bruit irréductible.

Rien ne presse : PHP 8.5 reste supporté pendant des années, et les dépréciations ne deviennent bloquantes que lorsqu'elles se transforment en suppressions, souvent des années plus tard. Mais quand la mise à jour arrivera, l'auteur recommande de traiter les dépréciations comme un sujet de CI plutôt que de logging en production : monter la version PHP d'abord en CI, faire échouer le build sur E_DEPRECATED et E_USER_DEPRECATED via un gestionnaire d'erreurs qui lève une ErrorException, corriger son code, mettre à jour ou suivre les paquets vendors — puis seulement déployer le changement de version en production.

Pour les dépréciations vendors récalcitrantes, l'article conseille de vérifier si une version plus récente du paquet est déjà compatible 8.6, si l'appel déprécié est réellement atteignable dans votre usage ou s'il s'agit de code mort supprimable, et — avec parcimonie — s'il est pertinent de masquer cet avertissement précis avec @ au niveau de l'appel tout en suivant le ticket upstream, plutôt que de désactiver entièrement la barrière CI. Au final : un correctif de cinq minutes dans une PR plutôt que l'explication d'une facture d'observabilité en flèche trois semaines plus tard.