Je me souviens encore de la semaine où on a migré un client d'agence vers PHP 7.2 et où chaque appel à each() dans un module de CMS vieillissant s'est mis à laisser des notices. Quelque part dans ce mur de répétitions se cachait un webhook de paiement réellement cassé, et il nous a fallu deux jours pour le repérer parce que le canal d'erreurs s'était transformé en papier peint. Cette semaine-là m'a appris la position que je veux défendre aujourd'hui : une notice de dépréciation qui apparaît dans les logs de production n'est pas un problème PHP, c'est un problème de routage. Le message était adressé à un développeur, et ton process l'a livré à la personne qui se trouvait être d'astreinte.

L'occasion de ressortir cette vieille histoire : les internals ont bouclé le vote sur la grande vague de nettoyage pour PHP 8.6, environ 35 RFC de dépréciation individuelles, et la grande majorité a été approuvée. Pour être clair sur ce que ça signifie en pratique : rien ne cesse de s'exécuter dans 8.6 lui-même. Les appels signalés retournent toujours leurs valeurs, ils laissent juste un mot derrière eux, et la suppression réelle sera le travail d'une future version majeure. C'est le langage qui se comporte exactement comme on dit toujours vouloir que les plateformes se comportent, avec des années de préavis au lieu d'une surprise.

Alors pourquoi un avertissement aussi poli fait-il encore mal aux équipes ? À cause de l'endroit où on choisit de le lire. Un E_DEPRECATED est un message des mainteneurs de PHP à la seule personne capable d'ouvrir le fichier et de changer la ligne. Quand tu le laisses couler à travers Monolog jusqu'à ton agrégation de logs, tu livres ce message en masse, à trois heures du matin, à un opérateur qui ne peut rien en faire. Tu paies deux fois : une fois en stockage et en ingestion pour une information complètement déterministe et reproductible sur n'importe quel laptop, et une fois en attention, parce que l'unique avertissement qui compte vraiment cette nuit-là est enseveli sous dix mille copies identiques.

Ma conclusion est brutale : les dépréciations issues du code que je possède ne devraient jamais survivre assez longtemps pour atteindre un serveur. Je lance la suite de tests sur la nouvelle version de PHP et je la configure pour que toute dépréciation déclenchée depuis mes propres namespaces fasse échouer le run. À partir de là, c'est du travail rouge-vert ordinaire, et une bonne partie est mécanique. Rector réécrira la plupart de ces motifs pour toi automatiquement, avec la limite évidente qu'il n'opère que sur le code qui t'appartient, pas sur ce qui vit sous vendor/.

Maintenant la concession honnête, parce que la version dure de ma propre politique a une vraie faiblesse. Si ta pipeline passe au rouge sur n'importe quelle dépréciation venue de n'importe où, alors le jour où un paquet dont tu dépends est en retard sur 8.6, tes builds échouent aussi longtemps que ce mainteneur en a besoin, ce qui peut durer des mois et échappe totalement à ton contrôle. Une équipe sous pression de livraison ne tolérera pas une pipeline rouge en permanence. Quelqu'un finira par couper le garde-fou, et tu te retrouveras avec moins de protection qu'avant de commencer. Les critiques des barrières strictes sur les dépréciations ont raison précisément sur ce mode d'échec, et prétendre le contraire serait malhonnête.

C'est pour ça que j'atterris sur une baseline plutôt que sur une interdiction, la même astuce que PHPStan a rendue respectable. À ta première exécution contre 8.6, prends un instantané de chaque dépréciation qui provient du code vendor et accepte cette liste comme dette connue. Le garde-fou n'échoue alors que sur la croissance : une nouvelle dépréciation, ou une qui se met à surgir depuis un nouvel endroit. Chaque composer update devient une occasion de faire maigrir le fichier, et le faire maigrir procure une satisfaction que fixer des dashboards de logs ne donnera jamais. Pendant ce temps, la production arrête complètement de logger E_DEPRECATED. Tu ne perds rien à le réduire au silence là-bas, parce que contrairement à un timeout ou une race condition, une dépréciation ne transporte aucun contexte d'exécution qui vaille la peine d'être observé.

Rien de tout ça ne dit que tu dois migrer ce trimestre. PHP 8.5 sera maintenu pendant des années, et une dépréciation n'a pas de deadline tant que la suppression n'est pas réellement livrée. Mais je monterais quand même bientôt une branche jetable contre 8.6, tout simplement parce que l'inventaire coûte un après-midi maintenant et une revue d'incident plus tard. La seule question que je n'ai pas complètement tranchée pour moi-même, c'est la queue récalcitrante : une dépréciation vendor où l'upstream ne répond pas et où aucune release alternative n'existe. Est-ce que tu la gardes en baseline indéfiniment, est-ce que tu maintiens un patch composer, ou est-ce que tu prends ça comme le signal de remplacer le paquet ? J'aimerais sincèrement savoir où ton équipe place cette limite.