PHP 8.5 en prod : array_first(), backtraces fatales et --ini=diff

PHP 8.5 est sorti en version stable le 20 novembre 2025, et la couverture médiatique s'est concentrée — à raison — sur le pipe operator, sur clone with pour les Value Objects immuables, et sur l'extension URI. Ce sont de vraies avancées syntaxiques. Mais une release annuelle de PHP, ce n'est jamais qu'une poignée de features qui font la une : c'est aussi une douzaine de petits ajustements qui changent le quotidien d'un Lead Dev en astreinte ou en revue de configuration. C'est cette seconde catégorie qui nous intéresse ici — les nouveautés utilitaires et de debug de PHP 8.5 qu'on découvre en général au pire moment, en pleine incident de prod, plutôt qu'en lisant le changelog à froid.

array_first() et array_last() : la fin du reset()/end() qui abîme le pointeur interne

Récupérer le premier ou le dernier élément d'un tableau associatif en PHP a toujours été plus pénible que ça ne devrait l'être. reset($array) et end($array) fonctionnent, mais ils déplacent le pointeur interne du tableau — un effet de bord qui casse silencieusement une boucle foreach ou un current() plus loin dans la fonction si tu oublies de le remettre à zéro. L'alternative habituelle, array_values($array)[0] ou array_slice($array, -1)[0], force une réindexation complète du tableau juste pour lire une valeur — un coût O(n) pour une opération qui devrait être O(1).

PHP 8.5 introduit deux fonctions natives qui règlent le problème : array_first(array $array): mixed et array_last(array $array): mixed. Elles retournent respectivement la première et la dernière valeur du tableau, sans toucher au pointeur interne et sans réindexation, et renvoient null si le tableau est vide.

<?php
// Avant PHP 8.5 : reset()/end() déplacent le pointeur interne
function getLatestOrderStatus(array $orderEvents): ?string
{
    // Effet de bord : le pointeur interne de $orderEvents est déplacé
    // à la fin du tableau. Un foreach ($orderEvents as ...) plus loin
    // dans l'appelant repartira du bon endroit (foreach copie),
    // mais un current($orderEvents) direct, lui, sera faussé.
    $last = end($orderEvents);

    return $last['status'] ?? null;
}

// PHP 8.5 : lecture pure, aucun effet de bord
function getLatestOrderStatus(array $orderEvents): ?string
{
    return array_last($orderEvents)['status'] ?? null;
}

// array_first() sur un tableau vide : pas de warning, juste null
$firstItem = array_first([]); // null
$lastItem  = array_last(['a', 'b', 'c']); // 'c'

Le détail qui compte en revue de code : ces fonctions n'acceptent qu'un tableau en argument, sans callback de filtrage — contrairement à ce que certains articles de blog ont laissé entendre pendant la phase RFC. Si tu veux le premier élément qui matche une condition, il faut toujours passer par array_filter() en amont, ou par une boucle explicite avec break. Ce n'est pas une fonction de recherche, c'est un accesseur — et c'est justement ce qui la rend prévisible et rapide sur des tableaux de plusieurs milliers d'entrées, comme un pipeline d'événements Messenger ou une collection Doctrine hydratée en masse.

Backtraces sur les erreurs fatales : le gain de diagnostic le plus sous-estimé de 8.5

Voici le changement qui va probablement t'économiser le plus d'heures en astreinte. Jusqu'à PHP 8.4, une erreur fatale — dépassement de max_execution_time, épuisement mémoire, déclaration de classe dupliquée, erreur de parsing dans un fichier inclus dynamiquement — se terminait par un message d'erreur brut, sans aucune trace d'appel. Tu savais quoi avait échoué, rarement depuis où ni comment on en était arrivé là. En production, sur un worker Messenger qui traite des jobs en série ou une commande Console appelée depuis un cron, cette absence de contexte transforme un debug de cinq minutes en chasse au log de deux heures.

PHP 8.5 introduit la directive INI fatal_error_backtraces, activée par défaut (1) — tu n'as rien à configurer pour en bénéficier. Dès qu'une erreur atteint le niveau E_FATAL_ERRORS, PHP génère et affiche une backtrace complète, avec la même sémantique que les exceptions non catchées : elle respecte le réglage existant zend.exception_ignore_args (pour ne pas fuiter les arguments sensibles dans les logs) et masque les paramètres annotés #[SensitiveParameter].

; php.ini — comportement par défaut en PHP 8.5, rien à activer
fatal_error_backtraces = On

; Pour retrouver l'ancien comportement (pas de backtrace sur fatal error)
; fatal_error_backtraces = Off

; À combiner avec ces réglages existants pour un compromis
; sécurité/diagnostic en prod :
zend.exception_ignore_args = On   ; masque les arguments des frames
log_errors = On
error_log = /var/log/php/fatal.log

En revue de configuration post-montée de version, le réflexe à avoir : vérifier que fatal_error_backtraces n'a pas été désactivé par un php.ini hérité d'une image Docker construite avant novembre 2025, et que zend.exception_ignore_args reste actif en prod pour que ces nouvelles backtraces n'exposent pas des tokens ou des mots de passe passés en argument à une fonction qui a fatalement échoué.

php --ini=diff : auditer une config sans la relire ligne par ligne

Diagnostiquer une différence de comportement entre un environnement de dev et la prod passe presque toujours par une comparaison de php.ini. Jusqu'ici, php --ini se contentait de lister les chemins des fichiers de configuration chargés — libre à toi ensuite de les ouvrir et de repérer, à l'œil, ce qui s'écarte des valeurs par défaut. Sur une image PHP-FPM avec plusieurs fichiers .ini fragmentés dans conf.d/, l'exercice est fastidieux et source d'erreurs.

PHP 8.5 ajoute l'option php --ini=diff, qui n'affiche que les directives dont la valeur diverge des valeurs par défaut intégrées à PHP. C'est un outil de diagnostic ciblé : au lieu de comparer deux fichiers complets, tu obtiens directement la liste des personnalisations effectives, quelle que soit la couche — php.ini principal, fragment conf.d, ou surcharge .htaccess.

# Avant 8.5 : lister tous les fichiers, puis comparer à la main
php --ini
# Configuration File (php.ini) Path: /usr/local/etc/php
# Loaded Configuration File: /usr/local/etc/php/php.ini
# Scan for additional .ini files in: /usr/local/etc/php/conf.d
# Additional .ini files parsed: /usr/local/etc/php/conf.d/opcache.ini,
#   /usr/local/etc/php/conf.d/error_reporting.ini, ...

# PHP 8.5 : uniquement ce qui a été modifié par rapport aux défauts
php --ini=diff
# memory_limit => 512M => 128M
# max_execution_time => 30 => 60
# opcache.enable => On => On
# opcache.jit_buffer_size => 0 => 64M

# Cas d'usage typique : diffé un conteneur de prod vs un conteneur de dev
docker compose exec app php --ini=diff > /tmp/ini-prod.diff
docker compose -f docker-compose.dev.yml exec app php --ini=diff > /tmp/ini-dev.diff
diff /tmp/ini-prod.diff /tmp/ini-dev.diff

C'est exactement l'outil qu'il manquait pour une checklist de revue de configuration avant mise en prod : au lieu de faire confiance à la mémoire de l'équipe sur « ce qu'on a changé par rapport aux valeurs par défaut de l'image officielle », --ini=diff te donne la liste exhaustive, générée par PHP lui-même.

max_memory_limit : empêcher un ini_set() sauvage de faire sauter le conteneur

Un scénario classique en environnement mutualisé, ou dans un monorepo Symfony avec plusieurs équipes : un développeur ajoute ini_set('memory_limit', '2G') dans un script d'import pour contourner une erreur Allowed memory size exhausted, sans se poser la question du budget mémoire du conteneur. Sur un pod Kubernetes limité à 512 Mo, ce genre de réglage local ne fait qu'accélérer l'arrivée de l'OOM killer — avec un message d'erreur qui ne pointe plus du tout vers la cause réelle.

PHP 8.5 introduit la directive max_memory_limit, de type INI_SYSTEM — donc modifiable uniquement en configuration système (php.ini), jamais à l'exécution via ini_set() ni par un utilisateur applicatif. Sa valeur par défaut est -1 (aucun plafond). Une fois positionnée, elle agit comme un plafond dur : si un script tente, via ini_set() ou une directive .htaccess, de pousser memory_limit au-delà de ce plafond, PHP émet un warning et cappe silencieusement la valeur au maximum autorisé plutôt que d'appliquer la valeur demandée.

; php.ini — configuré une fois par l'équipe infra, au niveau système
; Le conteneur tourne avec 512M de RAM allouée (cf. limits Kubernetes)
memory_limit     = 128M   ; valeur par défaut confortable pour la requête HTTP
max_memory_limit = 400M   ; plafond dur, marge de sécurité sous les 512M du pod

; Si une route ou un script tente ini_set('memory_limit', '2G') :
; -> PHP émet un warning et applique 400M, pas 2G
; -> le conteneur ne part plus en OOM sur un réglage local oublié

Le bénéfice concret pour une équipe qui gère plusieurs applications Symfony sur la même infra : max_memory_limit devient une garde-fou posée une seule fois dans l'image de base ou le ConfigMap, qui protège tous les projets contre un ini_set() individuel mal dimensionné — sans avoir à auditer chaque script d'import ou chaque commande Console pour vérifier qu'aucun développeur n'a mis une valeur déraisonnable en dur.

get_error_handler() et get_exception_handler() : introspecter les handlers actifs

Dans une application Symfony, la chaîne des gestionnaires d'erreurs et d'exceptions passe par plusieurs couches : le composant ErrorHandler du framework, potentiellement un handler Sentry ou un handler applicatif custom enregistré via set_error_handler() ou set_exception_handler() dans un bundle tiers. Jusqu'à PHP 8.4, il n'existait aucun moyen natif de savoir quel handler était actuellement actif — la seule façon de le découvrir était l'astuce détournée consistant à appeler set_error_handler() avec un nouveau handler bidon, pour récupérer l'ancien en valeur de retour, puis le restaurer immédiatement.

<?php
// Avant 8.5 : l'astuce set_error_handler() pour "lire" le handler actif
$currentHandler = set_error_handler(static fn () => false);
set_error_handler($currentHandler); // on restaure immédiatement

// PHP 8.5 : lecture directe, sans effet de bord
$currentErrorHandler = get_error_handler();     // ?callable
$currentExceptionHandler = get_exception_handler(); // ?callable

if ($currentErrorHandler === null) {
    // Aucun handler custom : PHP utilise son comportement interne par défaut
    error_log('Aucun error handler applicatif enregistré — vérifier le boot de l\'ErrorHandler Symfony.');
}

L'usage le plus utile en contexte Symfony : un test d'intégration ou une commande de diagnostic (bin/console debug:error-handler, par exemple) qui vérifie explicitement que \Symfony\Component\ErrorHandler\ErrorHandler est bien le handler actif après le boot du kernel, plutôt que de le déduire indirectement par le comportement observé sur une exception provoquée. C'est aussi un outil de debug précieux quand un bundle tiers enregistre son propre handler et écrase silencieusement celui de Symfony — un bug classique dans un stack de bundles mal ordonné, désormais détectable par une simple assertion sur get_exception_handler().

curl_multi_get_handles() : ranger un pool de requêtes cURL asynchrones

Un pattern fréquent dans un worker Symfony qui agrège des appels vers plusieurs API externes — enrichissement de données, webhooks sortants en parallèle — consiste à gérer un CurlMultiHandle auquel on attache et détache des CurlHandle individuels au fil de l'exécution. Le problème classique : au bout de quelques itérations, le code perd la trace de quels handles sont encore attachés au multi handle, en particulier après un refactor où la logique d'ajout est répartie sur plusieurs méthodes.

PHP 8.5 ajoute curl_multi_get_handles(CurlMultiHandle $multi_handle): array, qui retourne la liste des objets CurlHandle actuellement attachés à un handle multi — un tableau vide si aucun n'est attaché. C'est une fonction de housekeeping : elle sert à auditer l'état réel du pool avant de le fermer, ou à détecter une fuite de handle qu'on aurait oublié de retirer via curl_multi_remove_handle().

<?php
// Worker Messenger qui interroge plusieurs endpoints en parallèle
final class ExternalEnrichmentHandler
{
    public function enrichBatch(array $urls): array
    {
        $multiHandle = curl_multi_init();
        $handles = [];

        foreach ($urls as $key => $url) {
            $handle = curl_init($url);
            curl_setopt($handle, CURLOPT_RETURNTRANSFER, true);
            curl_multi_add_handle($multiHandle, $handle);
            $handles[$key] = $handle;
        }

        do {
            curl_multi_exec($multiHandle, $running);
            curl_multi_select($multiHandle);
        } while ($running > 0);

        // PHP 8.5 : vérifier qu'aucun handle n'est resté accroché
        // avant de fermer le multi handle, plutôt que de le supposer
        $remaining = curl_multi_get_handles($multiHandle);
        if ($remaining !== []) {
            error_log(sprintf('Fuite détectée : %d handle(s) cURL non retirés.', count($remaining)));
        }

        foreach ($handles as $key => $handle) {
            curl_multi_remove_handle($multiHandle, $handle);
            curl_close($handle);
        }
        curl_multi_close($multiHandle);

        return $handles;
    }
}

Ce n'est pas une fonction qu'on appelle en boucle chaude — c'est un outil d'assertion et de debug, à réserver aux tests d'intégration du client HTTP maison ou aux points de contrôle avant fermeture d'un pool, exactement comme on vérifierait qu'une connexion PDO a bien été rendue à un pool de connexions avant de le recycler.

Ce qui compte vraiment dans une migration vers PHP 8.5

Aucune de ces six nouveautés ne casse de compatibilité ascendante et aucune n'exige de réécrire du code existant — c'est en cela qu'elles diffèrent des incompatibilités qu'on doit corriger de force lors d'une montée de version majeure. Elles s'activent seules (fatal_error_backtraces), s'utilisent à la demande (array_first(), --ini=diff, get_error_handler()), ou se configurent une fois pour protéger toute une flotte de conteneurs (max_memory_limit). Le vrai travail, en revue de montée de version, consiste à vérifier que ces réglages par défaut sont alignés avec ta politique de sécurité — masquage des arguments sensibles dans les backtraces, plafond mémoire cohérent avec les limites de ressources du cluster — plutôt qu'à les découvrir en pleine astreinte.

Si ta stack Symfony tourne encore sur une version antérieure et que tu veux profiter de ces gains de diagnostic sans mauvaise surprise en prod — dépréciations à traiter, comportements de handlers d'erreurs à revalider, configuration max_memory_limit à calibrer sur tes conteneurs réels — c'est exactement le type d'accompagnement que couvre notre offre Bear Upgrade : un audit de compatibilité, un plan de montée de version étape par étape, et une revue de configuration post-migration pour que ces nouveaux réglages jouent en ta faveur dès le premier déploiement.