14:00 UTC, le 21 octobre. C'est l'heure à laquelle l'équipe sécurité de PHP avait programmé une release d'urgence pour deux vulnérabilités distinctes, chacune notée 9.2 au CVSS. Plus tôt le même jour, Laravel avait publié 12.68.0 et 13.29.0 pour boucher un trou dans le guard des tokens d'API qui permettait à un attaquant de s'authentifier sur le compte de quelqu'un d'autre avec MySQL et MariaDB. Donc si tu faisais tourner une API Laravel sur une base MySQL, ta liste de tâches tenait en deux lignes : une mise à jour du framework et une mise à jour du runtime, toutes les deux critiques, à faire avant que ton café refroidisse.

Ça fait huit jours. J'aimerais sincèrement voir la répartition du temps qu'il vous a fallu à chacun pour mettre les deux en production, parce que je soupçonne qu'elle se coupe en deux groupes, avec presque rien au milieu. Le premier groupe a mergé un composer update, regardé la CI passer au vert, reconstruit l'image avec la nouvelle version corrective de PHP, puis il est rentré chez lui. Le second groupe est encore dans un fil de ticket à demander qui est responsable de l'environnement de staging.

Ce qui sépare ces deux groupes, ce n'est pas la rigueur. Tout le monde a lu le même bulletin. Personne autour de moi n'a haussé les épaules devant un contournement d'authentification. Ce qui fait la différence, c'est de savoir si l'équipe croit vraiment à sa suite de tests. Si un run vert veut dire « on est bons », une montée de version mineure du framework, c'est un quart d'heure de boulot. Si un run vert veut dire « sans doute bons, mais souviens-toi de la fois où les crons ont cassé », la même montée de version prend une semaine, parce qu'il faut maintenant qu'un humain clique dans l'appli à la main, que les humains sont occupés, et que c'est comme ça qu'une faille déjà corrigée reste active dans ta stack des jours après la publication du correctif.

Le meilleur contre-argument mérite d'être entendu honnêtement : c'est en se précipitant qu'on casse la prod, et un patch qu'on n'a pas fait passer par le staging est un pari en soi. Les versions correctives changent parfois le comportement. Les gens de l'ops qui exigent une période d'observation en staging ont des cicatrices qui le justifient, et je ne vais pas prétendre qu'un diff de deux lignes dans composer.lock est sans risque. Mais regarde à quoi sert réellement cette période d'observation. Elle remplace la confiance que tu n'as pas construite dans ta suite. Le staging attrape ce que tes tests ne couvrent pas, donc plus ton déploiement est lent, plus il te renseigne sur les trous de ta couverture, et pas sur le patch.

Du coup, le lien le moins glamour de la revue d'actu de ce jour-là est aussi le plus utile. Rob Allen a expliqué comment repérer tes tests PHPUnit les plus lents en demandant à PHPUnit d'écrire un log JUnit XML avec --log-junit, pour obtenir des durées par test que tu peux trier, et il a précisé que PHPUnit 13 sait produire une sortie Open Test Reporting dans le même but. Ça ressemble à du ménage. En réalité, c'est du travail de sécurité. Un pipeline qui prend quarante minutes, on le lance moins souvent, on le saute quand on est sous pression, et personne ne prend le temps d'ajouter le test de non-régression qui aurait rendu le jour du patch parfaitement ennuyeux.

Il y a une deuxième leçon, plus discrète, dans le bug de Laravel lui-même, qui ne touchait que les installations MySQL et MariaDB. Si ta CI exécute tout sur du SQLite en mémoire parce que c'est rapide, tu aurais eu une suite au vert sur une base qui n'était pas concernée, pendant que ta prod tournait sur une base qui l'était. La vitesse compte, mais il faut que ce soit de la vitesse sur ta vraie stack. Un MySQL conteneurisé dans le pipeline te coûte quelques secondes ; un contournement d'authentification propre à ta base que tu ne peux pas reproduire dans tes tests te coûte bien plus que ça.

Rien de tout ça n'est une pique contre l'écosystème. Les mainteneurs de Laravel ont livré des correctifs pour deux branches majeures rapidement, l'équipe PHP a annoncé la fenêtre de release à l'avance pour qu'on puisse s'organiser, et c'est exactement à ça que ressemble un projet mature. Le goulot d'étranglement du 21 octobre n'était pas en amont. Il se trouvait entre « un correctif existe » et « mes serveurs le font tourner », et cet espace-là, il est à nous. Les devs Go adorent se vanter de livrer un unique binaire statique ; nous, on peut se vanter d'un composer update et d'une mise à jour de l'image de base, à condition de pouvoir faire confiance au résultat.

Alors voilà ce que j'aimerais vraiment savoir, en commentaire : combien de temps réel s'est écoulé entre le bulletin et la mise en production sur ta principale appli PHP, mesuré honnêtement le 21 octobre, et quel est le seul point de ton pipeline que tu corrigerais en premier pour diviser ce temps par deux ?