Jusqu’au Forum PHP 2026, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils ou elles aborderont lors de leur conférence !

La conférence

Ce que coûte vraiment `return new Response()` La plupart des applications Symfony bufferisent tout : résultats Doctrine, objets sérialisés, JSON, exports... Puis elles construisent une réponse complète avant de l'envoyer au client. Ça fonctionne. Jusqu'au jour où ça ne fonctionne plus : mémoire qui explose, time-to-first-byte qui grimpe, exports qui tombent en production. De plus, avec l'arrivée des LLM dans nos produits, cette approche montre encore plus ses limites. Quand un modèle met plusieurs secondes à générer sa réponse, attendre le return signifie afficher un spinner pendant tout ce temps. Le streaming n'est plus une optimisation back-end. C'est devenu le socle d'une expérience utilisateur moderne. Dans ce talk, nous allons démonter une idée profondément ancrée dans nos applications : celle qu'une réponse doit être entièrement construite avant d'être envoyée. Nous repenserons le flux de données d'une application Symfony de bout en bout : StreamedResponse, encodage JSON incrémental avec le composant JsonStreamer, sources de données itérables avec Doctrine, Server-Sent Events et EventStreamResponse pour le temps réel. Vous apprendrez à produire les données au fil de l'eau, alimenter des interfaces en direct, générer des exports de plusieurs millions de lignes et maintenir une consommation mémoire stable grâce aux outils déjà présents dans Symfony.

Joan Clarke - HJK 09/10/2026 09:45-10:25

Est-ce qu'un outil comme Mercure peut apporter quelque chose de complémentaire aux réponses streamées dont tu vas nous parler dans ta conférence ?

Oui, et j'en parle justement dans mon talk. Les deux technologies sont complémentaires parce qu'elles répondent à deux problèmes différents. Une réponse streamée, c'est du pull : le client demande quelque chose, et le serveur lui envoie la réponse au fur et à mesure qu'elle est produite. Mercure, en revanche, répond à une autre question : comment prévenir un client qu'un événement s'est produit ailleurs ? Par exemple, lorsqu'un job s'exécute en arrière-plan ou lorsqu'un autre utilisateur vient de modifier une ressource.

Il y a aussi une différence importante au niveau de l'infrastructure. Une réponse en streaming maintient un worker PHP occupé pendant toute la durée du stream. Pour un export, c'est exactement ce qu'on veut : le worker produit le résultat progressivement.

En revanche, si je veux afficher la progression d'un job à mille personnes, je peux me retrouver avec mille connexions qui occupent des workers PHP. Et pendant ce temps-là, il peut ne plus rester suffisamment de workers pour servir une simple page de login. C'est justement là que Mercure devient intéressant : il permet de gérer ces connexions longues en dehors de PHP.

On peut donc utiliser le streaming pour répondre progressivement à une requête, et Mercure pour pousser un événement à des clients qui n'ont rien demandé. Les deux approches ne s'opposent donc pas : elles sont complémentaires.

Tu es le créateur du composant TypeInfo permettant d'extraire des informations sur les types PHP. Quelle a été la réflexion ayant menée à cette création ?

Ça n'est pas parti de "je vais créer un composant sur les types". Je travaillais sur la sérialisation, et notamment sur ce qui est devenu JsonStreamer. Or, pour streamer des données ou générer du code, il y a une contrainte fondamentale : on ne peut pas attendre d'avoir la donnée pour deviner ce qu'on doit en faire. Il faut connaître son type à l'avance.

Symfony avait déjà une abstraction pour ça dans PropertyInfo, avec le Type. Mais cette abstraction avait été conçue une dizaine d'années plus tôt pour répondre à un besoin plus limité. Elle décrivait essentiellement le type d'une propriété, plutôt qu'un type en tant que concept. Et pour les nouveaux usages que nous avions, notamment la génération de code, elle avait plusieurs limitations.

Je me suis donc dit qu'il fallait repartir d'un concept plus fondamental : un type mérite son propre objet, indépendant de la propriété qui le contient, avec une vraie algèbre de types et une représentation suffisamment précise pour être exploitée par d'autres composants. C'est de cette réflexion qu'est né TypeInfo.

Et désormais, le plus satisfaisant, c'est que personne ne fait ""composer require symfony/type-info"". C'est probablement le meilleur compliment qu'on puisse lui faire : s'il disparaît derrière JsonStreamer, ObjectMapper ou d'autres composants, c'est qu'il fait son travail parfaitement.

À la fin de l'année dernière, Symfony fêtait ses 20 ans. Comment vois-tu les prochaines années pour le projet ?

Ce qui m'impressionne le plus, ce n'est pas la longévité de Symfony, c'est sa constance. La rétrocompatibilité, une version tous les six mois, une roadmap lisible plusieurs années à l'avance... Tout cela peut sembler ennuyeux, mais c'est ennuyeux dans le très bon sens du terme. Pour une entreprise qui construit son système d'information sur Symfony depuis quinze ans, cette stabilité est probablement l'une des fonctionnalités les plus importantes du framework.

En revanche, ce qui a beaucoup évolué, c'est le niveau d'abstraction. Il y a dix ans, Symfony était surtout une boîte à outils autour du HTTP. Aujourd'hui, on voit apparaître des composants comme Scheduler, ObjectMapper, JsonPath ou JsonStreamer, et même toute une stack autour de l'IA. Je pense que cette évolution va continuer, notamment autour de deux sujets.

Le premier, c'est l'IA. PHP a une vraie place à prendre ici, parce qu'une grande partie du travail consiste à orchestrer des appels, gérer de l'I/O et traiter des flux de données. Ce sont justement des choses que PHP sait très bien faire.

Le second, c'est le modèle d'exécution. Avec FrankenPHP et le worker mode, on commence à sortir du modèle mental "un process par requête". Cela change notre façon de penser les performances, l'état de l'application et les connexions longues. Et c'est entre autres pour ça que je fais ce talk : le streaming ne devrait pas être une technique avancée. Il devrait devenir une façon normale de construire des applications web.

Une conférence présentée par

Mathias ARLAUD

Mathias Arlaud est co-fondateur de baksla.sh et membre de la Core Team Symfony. Contributeur actif de l’écosystème open source, il est le créateur des composants JsonStreamer et TypeInfo, et travaille essentiellement sur la sérialisation et la performance. Conférencier régulier (API Platform Conference, SymfonyLive, SymfonyCon, Forum PHP, AFUP Day), il partage son expertise autour de Symfony et du développement d’API.

Autres interviews

• La parole est aux speakers : Gaël CRISPYN
• La parole est aux speakers : Antoine Bluchet
• La parole est aux speakers : Guillaume Lours
• La parole est aux speakers : Kévin Martins
• La parole est aux speakers : Pierre Tondereau
• La parole est aux speakers : Kévin Dunglas
• La parole est aux speakers : Jori STEIN
• La parole est aux speakers : Thomas Dutrion
• La parole est aux speakers : Charlotte Chaumet
• La parole est aux speakers : Benjamin Eberlei
• La parole est aux speakers : Alexandre Daubois
• La parole est aux speakers : Michaël Benhaïm
• La parole est aux speakers : Sebastian Bergmann
• La parole est aux speakers : Yoann Blot
• La parole est aux speakers : Niels Ackermann
• La parole est aux speakers : Jean-François Lépine