Tu modifies une règle de validation dans un FormRequest. La CI mouline consciencieusement quatre mille tests pendant onze minutes, dont trois environ avaient une vraie raison de tourner. On a tous accepté ça comme le prix de la confiance. Pest 5 est la première version majeure de notre coin de l'écosystème qui traite ce prix comme négociable — et, plus intéressant encore, la première qui assume ouvertement qu'une partie des diffs qui atterrissent dans ton repo n'a jamais été tapée par un humain.

Ma position, cash : cette hypothèse est juste, et construire un framework de test autour d'elle est le bon choix, même si certaines parties vieilliront mal. Une suite qui ne parle qu'aux humains est déjà en retard sur la façon dont le code s'écrit en 2026. Les fonctionnalités les plus débattues de Pest 5 — le plugin Agent et les Evals — ne sont pas de la déco marketing. C'est l'aveu que le deuxième utilisateur de ta suite de tests est une machine, et que cette machine a besoin qu'on lui dise quand elle se trompe, aussi franchement qu'à un dev junior sur sa première pull request.

D'abord, l'inventaire à froid, parce que le changelog se lit facilement de travers. La version minimale de PHP passe à 8.4. En dessous, tu es désormais sur PHPUnit 13. La Test Impact Analysis sélectionne le sous-ensemble de tests liés à ton diff au lieu de tout déclencher. PHPStan et Rector sont braqués sur ton code de test, historiquement le code le moins analysé de tous les repos Laravel que j'ai touchés. Ce qui n'est pas une histoire Pest 5 : les tests navigateur sont arrivés avec Pest 4, et le sharding équilibré par durée remonte à la 4.6. Si ton argumentaire de montée de version auprès de l'équipe s'appuie sur ces deux-là, quelqu'un te le fera remarquer en review, à raison.

La Test Impact Analysis mérite à la fois les applaudissements et une étiquette d'avertissement. En local, elle transforme l'habitude de lancer-les-tests-après-chaque-sauvegarde d'un fantasme en quelque chose que tu feras vraiment, et une habitude tenue vaut mieux qu'un rituel esquivé. Mais pense à tout ce qui, dans une appli Laravel, se câble à l'exécution : bindings du conteneur permutés dans un service provider, listeners enregistrés dans un EventServiceProvider, comportements pilotés par la config ou une morph map. Aucune sélection basée sur le diff ne peut voir tout ça. Ma règle : tests impactés à chaque sauvegarde, suite complète avant merge. Traite la voie rapide comme un éclaireur, pas comme le verdict.

Le plugin Agent, c'est là que les avis se déchirent au bar des confs. L'idée : un assistant de code ne devrait pas noter sa propre copie en relisant son diff — il devrait pouvoir vérifier ses affirmations contre une application démarrée. Cette migration a-t-elle vraiment ajouté la colonne ? Le job est-il réellement dans la queue après la requête ? Ce n'est pas de l'idolâtrie de l'IA ; c'est appliquer la plus vieille règle qu'on ait — ne fais pas confiance, vérifie — à un nouveau type de contributeur. Les Evals étendent la même honnêteté à la sortie du modèle elle-même : quand la réponse varie légitimement d'une exécution à l'autre, tu asserts des propriétés et des bornes au lieu de faire semblant qu'un assertSame() règle la question.

Maintenant, le meilleur argument contre moi, présenté honnêtement. Un : l'exigence de PHP 8.4 est un vrai mur. Plein d'équipes tournent en 8.2 ou 8.3 en production pour des raisons qui n'ont rien à voir avec la paresse — images fournisseur, gels de conformité, cette extension que personne n'ose recompiler. Pour elles, Pest 5 est une conversation pour 2027, et c'est très bien. Deux : les frameworks de test ont la mémoire longue, et greffer des outils taillés pour le workflow de cette année, c'est risquer de traîner du poids mort dans cinq ans. Peut-être que les Evals ne survivront pas sous leur forme actuelle. Je prends quand même ce risque, parce que l'alternative — une stratégie de test qui ignore comment les patches sont réellement produits dans mon équipe en ce moment — me coûte plus cher ce trimestre qu'un plugin déprécié ne me coûtera plus tard.

Ce à quoi je reviens sans cesse, c'est que rien de tout ça ne change ce qu'est un test. Ça change qui lit la croix rouge. Quand le lecteur est un humain, un échec est un feedback. Quand le lecteur est un agent, un échec est un garde-fou — la seule chose qui se dresse entre un patch au ton assuré et ta branche main. Je préfère un framework qui prend ce second rôle au sérieux plutôt qu'un framework qui fait comme si on était encore en 2019.

Alors, chers collègues, deux questions dont je veux vraiment les réponses en commentaires : accepterais-tu un jour de conditionner un merge aux seuls tests impactés — ou la suite complète avant main est-elle non négociable chez toi, quelle que soit la qualité de la sélection ? Et as-tu déjà laissé un assistant lancer tes tests sans surveillance, ou est-ce toujours un humain qui appuie sur le bouton ? Dis-moi où passe ta ligne, et pourquoi.