Quarante-huit. C'est le numéro de version corrective atteint cette semaine par Symfony 6.4, et c'est le chiffre que j'aimerais que chaque lead Laravel contemple un instant. Quarante-huit fois, quelqu'un est entré dans une branche de support long terme, a trouvé un problème, l'a corrigé et a posé un tag. La plupart d'entre nous n'ont jamais regardé un seul de ces tags. Je pense que ça doit changer. Si ton appli tourne sous Laravel, une bonne partie du code qui traite tes requêtes et tes commandes artisan vit dans vendor/symfony, et le changelog de ce répertoire a sa place dans ta liste de lecture, juste à côté de celui de Laravel.

Cette semaine, le cas est on ne peut plus concret. Des correctifs de sécurité sont arrivés pour le composant Yaml et pour HttpFoundation. C'est HttpFoundation qui m'empêcherait de dormir. Chaque objet Request que reçoivent tes contrôleurs est une Request Symfony qui porte une veste Laravel : une faille là-dedans est donc une faille dans ton appli, que quelqu'un dans ton équipe ait tapé le mot Symfony cette année ou non. Les correctifs sont sortis sur quatre branches maintenues, ce qui est généreux de la part des mainteneurs, et aussi une manière polie de rappeler que personne ne peut prétendre que sa version était trop ancienne pour être couverte.

Je veux rendre justice au camp d'en face, parce que son argument tient debout. Ton composer.json ne mentionne sans doute pas du tout symfony/http-foundation. Laravel déclare la contrainte, ton fichier lock fige la version exacte, et lancer composer update chaque fois qu'un billet paraît sur le blog Symfony ressemble à un moyen rapide d'embarquer, un vendredi après-midi, des changements que personne n'a relus. Certaines équipes s'y sont brûlé les doigts, et leur prudence vient de ces cicatrices. Laisser l'éditeur du framework faire le tri, c'est une répartition du travail raisonnable pour une équipe de trois.

Voici pourquoi je penche quand même de l'autre côté. Les versions correctives au sein d'une même mineure de Symfony suivent une promesse stricte de rétrocompatibilité : le risque de mettre à jour dans la plage que Laravel autorise déjà est faible, et le fichier lock te permet de voir précisément quels paquets ont bougé avant que quoi que ce soit n'arrive en production. C'est l'attente qui coûte cher. La contrainte de Laravel autorise déjà la version corrigée ; la seule chose qui sépare tes serveurs du correctif, c'est que personne n'a lancé la commande. Un avis de sécurité qui reste trois semaines sans être appliqué parce que l'équipe attendait un signal qui n'allait jamais venir, c'est comme ça que des bugs ordinaires finissent en rapports d'incident.

Les correctifs hors sécurité font passer le même message, plus discrètement. L'un d'eux corrige une dérive du composant Clock autour des changements d'heure. Ça ressemble à un détail jusqu'à ce que tu te rappelles qu'une bonne partie de l'Europe recule ses horloges dans une semaine environ, le 25 octobre, et que quelque part une tâche planifiée s'apprête à se déclencher deux fois à 02:30, ou pas du tout. Un autre règle la façon dont BrowserKit lit les chemins des cookies, typiquement le genre de chose qui rend un test d'intégration instable pour un développeur et vert pour tous les autres. Aucun de ces correctifs n'apparaîtra dans une note de version Laravel, parce que du point de vue de Laravel, rien n'a changé.

Ma position pratique, donc, la voici. Abonne-toi au flux du blog Symfony, ou au moins aux avis de sécurité. Lance composer audit dans ta CI, pour qu'une vulnérabilité connue fasse échouer un build au lieu d'attendre qu'un humain la remarque. Et quand une série de correctifs tombe, lance un composer update symfony/* ciblé sur une branche, lis le diff du lock, laisse la suite de tests le mâcher, puis merge. Sur un projet en bonne santé, ça prend vingt minutes, dont l'essentiel passé à attendre PHPUnit. Les développeurs Go aiment plaisanter en disant que leur bibliothèque standard est leur framework ; nous avons quelque chose d'assez proche gratuitement, maintenu par des gens qui rétroportent des correctifs sur une ligne 6.4 que la plupart des éditeurs auraient abandonnée depuis longtemps.

Il y a aussi une petite question de culture là-dedans. Au bar des conférences, on présente souvent Laravel et Symfony comme des rivaux, et le fichier composer.lock les contredit en silence. Le travail qui garde l'un stable garde l'autre stable, et considérer la maintenance en amont comme l'actualité de quelqu'un d'autre, c'est passer à côté de la moitié de ce qui protège tes utilisateurs. Savoir d'où vient ta classe Request n'a rien d'une trahison envers ton framework. C'est simplement exact.

Ce que j'aimerais vraiment savoir : comment ton équipe gère-t-elle les correctifs en amont aujourd'hui ? Est-ce qu'elle met à jour les composants Symfony à leur propre rythme, avec un outil comme Renovate ou Dependabot, ou attend-elle qu'une version de Laravel les embarque ? Et l'un ou l'autre de ces choix t'a-t-il déjà joué un tour en production ?