Un collègue qui maintient une API Symfony avec un panneau d'admin en Angular m'a envoyé une capture d'écran la semaine dernière : deux fichiers ouverts côte à côte, à gauche un `UserRegistrationType` avec onze contraintes, à droite un validateur TypeScript qui n'en avait que neuf. Il en manquait deux. Personne ne savait quel côté avait raison, et le ticket de bug traînait depuis mars. Angular v22 est sorti en juin 2026, on en est à la 22.2.x, et le tampon « stable » posé sur les Signal Forms va rendre ce genre de capture bien plus courant dans les boîtes PHP, sauf si on décide dès maintenant que c'est le côté PHP qui détient les règles.

Quelques faits, pour qu'on parte de la même base. La version 22 est une version de consolidation. Trois API qui étaient expérimentales en v21 deviennent stables : les Signal Forms, les signaux asynchrones construits autour de `resource` pour charger les données serveur, et Angular Aria, un ensemble de primitives accessibles headless. L'équipe a aussi publié des prompts LLM officiels, un serveur MCP dans l'Angular CLI et des agent skills. Pas de réécriture, pas de nouveau modèle mental. La mise à jour passe par `ng update`, comme chaque année.

Alors pourquoi un dev Laravel devrait-il s'intéresser à une sortie côté frontend ? Parce que les API stables sont adoptées par ceux qui attendaient jusque-là, et dans les équipes mixtes, ceux qui attendaient sont en général les gens du backend qu'on embarque sur des tickets frontend un jeudi après-midi. Les Signal Forms te permettent d'exprimer la validation sous forme de simples fonctions TypeScript. C'est très agréable à écrire. C'est aussi le chemin le plus rapide que je connaisse vers une deuxième copie, qui diverge en silence, de chaque règle que tu maintiens déjà dans une FormRequest ou une contrainte Symfony, et cette dérive ne se verra pas dans les tests, parce que chaque côté ne teste que lui-même.

Ma position : traite le backend PHP comme le seul endroit où vit une règle métier, et vois les Signal Forms comme ce qui affiche le verdict. Ton endpoint renvoie déjà un 422 avec un sac d'erreurs structuré sous Laravel, ou une liste de violations issue du composant Validator sous Symfony. Mappe tout ça sur les champs du formulaire, de façon cohérente, à un seul endroit du frontend. Les vérifications côté client restent pour le trivial et le cosmétique : un champ vide, un email sans @. Tout ce qui implique une requête en base, un paramètre de tenant ou une règle de tarification, c'est PHP qui tranche et Angular qui affiche.

Le meilleur argument contre moi, c'est la latence et le ressenti. Attendre un aller-retour pour apprendre qu'un code promo a expiré paraît mou à côté d'une bordure rouge instantanée, et sur une mauvaise connexion mobile, 400 ms par champ transforment un checkout en corvée. C'est vrai. Les gens du produit le remarqueront, et ils auront raison. Ma réponse : tu peux mettre un debounce sur un endpoint de validation, et un message juste mais lent vaut mieux qu'un message rapide mais faux. Le message rapide et faux, c'est celui qui annonce au client que son code est valide, le laisse cliquer sur payer, puis l'envoie ouvrir un ticket au support à 23:40 quand le serveur refuse quand même la commande. Je préfère optimiser un endpoint que réconcilier deux règlements jusqu'à la fin des temps.

La même logique vaut pour `resource`. Maintenant que le chargement des données serveur via les signaux est officiellement supporté, la forme de ton JSON compte d'une manière nouvelle, parce que le frontend le lit directement dans un état réactif au lieu de le faire passer par des couches de transformation écrites à la main. Ça renvoie la pression de conception vers l'API. Si tes classes de resource Laravel ont une nullabilité incohérente, ou si tes groupes de sérialisation Symfony exposent un jeu de champs différent selon la route, une UI pilotée par les signaux affichera chaque incohérence à l'écran. Franchement, j'y vois un cadeau. PHP a passé une décennie à devenir bon en API typées et prévisibles ; c'est l'occasion de s'en servir.

Angular Aria mérite aussi un petit mot, puisqu'il arrive dans la même version. Des primitives accessibles sans style imposé, ça veut dire que le markup que tes templates Blade ou Twig généraient pour les pages rendues côté serveur et celui de l'app Angular peuvent enfin suivre les mêmes patterns d'accessibilité, ce qui aide quiconque a dû passer un audit sur les deux moitiés d'un même produit. Quant au serveur MCP de la CLI, il est utile pour une raison toute bête : il peut orienter un assistant vers la doc à jour plutôt que vers ce qu'il a absorbé pendant son entraînement. Bête, c'est bien. Les gens de Go appelleraient ça idiomatique et passeraient à autre chose.

Alors voilà ce que j'aimerais vraiment savoir, surtout si tu fais tourner une API PHP derrière Angular ou n'importe quel autre frontend à base de signaux : où vivent tes règles de validation aujourd'hui, et as-tu trouvé une façon de les partager par-delà la frontière entre les langages qui ait survécu à plus d'un cycle produit ? Des schémas générés à partir d'attributs PHP, un pipeline OpenAPI, un endpoint de validation dédié, ou tout simplement deux fichiers et beaucoup de discipline ? Raconte-moi ce qui a cassé.