Quand l'IA expose les limites de nos architectures PHP
Pendant des années, le pattern dominant dans nos applications Symfony était simple et assumé : construire la réponse complète en mémoire, puis l'envoyer d'un bloc. Doctrine charge ses résultats, le serializer produit son JSON, Twig rend son template — et seulement alors, le client reçoit quelque chose. Ce modèle a servi des milliers de projets sans problème... jusqu'à ce que les LLM arrivent en production.
C'est précisément le constat que dressera Mathias Arlaud, Software Engineer chez baksla.sh, lors de sa conférence "Asynchronous PHP & Symfony in High-Performance Systems" à la SymfonyCon Warsaw 2026 (26-27 novembre 2026). Une talk qui promet d'aller au fond des internals pour comprendre pourquoi nos applications bufferisent tout — et comment en sortir.
Le problème du "tout-en-mémoire" mis à nu par les modèles de langage
Les symptômes sont connus de tout développeur qui a mis un projet ambitieux en production : pics mémoire inexplicables sur les exports, time-to-first-byte qui dérive, jobs qui meurent silencieusement faute de ressources. Ces problèmes existaient bien avant les LLM, mais ils restaient tolérables.
Avec l'intégration de modèles de langage, la situation devient intenable. Un LLM peut mettre plusieurs secondes — parfois dizaines de secondes — à produire une réponse. Si votre application attend le retour complet pour commencer à envoyer quoi que ce soit au client, vous condamnez vos utilisateurs à fixer un spinner pendant toute cette durée. Ce n'est plus une question d'optimisation back-end : c'est une régression d'expérience utilisateur majeure.
Le streaming, longtemps considéré comme une feature avancée réservée aux cas exotiques, devient l'architecture de base pour tout système qui intègre de l'IA générative.
Ce que Symfony permet (et ce qu'il faut encore construire)
Symfony dispose déjà de plusieurs primitives utiles pour aborder ce sujet :
- StreamedResponse : envoyer des données au fil de l'eau sans bufferiser la réponse HTTP complète
- Messenger : déporter le travail lourd en tâches asynchrones
- HttpClient avec streaming : consommer des APIs (dont les endpoints OpenAI-compatibles) en flux
Mais ces briques ne suffisent pas à elles seules. Le vrai défi architectural est de changer le modèle mental : passer d'une logique request → process → response à une logique request → open stream → push chunks → close. Cela implique de revoir comment Doctrine charge ses collections (lazy loading vs eager loading), comment le serializer peut opérer sur des itérables plutôt que des tableaux complets, et comment les couches intermédiaires (middlewares, listeners, profiler) se comportent face à une réponse qui ne se termine pas immédiatement.
La conférence de Mathias Arlaud promet justement de "tear down an assumption baked into most Symfony apps" — déconstruire l'hypothèse qu'une réponse doit être entièrement construite avant d'être envoyée. C'est un travail d'architecture autant que d'implémentation.
Pourquoi cet angle est stratégique pour les équipes PHP en 2026
L'intégration des LLM dans les applications métier n'est plus expérimentale. Les équipes qui construisent des assistants, des moteurs de génération de contenu ou des interfaces conversationnelles sur Symfony se heurtent toutes au même mur : PHP a été conçu pour le modèle request/response classique, et sortir de ce paradigme demande un effort délibéré.
Plusieurs pistes sont désormais matures :
- Server-Sent Events (SSE) côté HTTP, supportés nativement par les navigateurs, pour pousser des chunks de texte au fur et à mesure que le LLM répond
- FrankenPHP et son mode worker, qui permettent à PHP de rester en mémoire entre les requêtes et de gérer des connexions longues sans le coût du cold start FPM
- ReactPHP / Swoole pour les équipes qui veulent aller encore plus loin dans l'event loop
- Messenger + Redis Streams pour les cas où le traitement LLM est déporté et le résultat poussé asynchronement
L'enjeu n'est pas de réécrire Symfony en Go. C'est de comprendre précisément où se situent les goulots d'étranglement et d'appliquer les bonnes primitives au bon endroit — ce qui reste tout à fait faisable dans un projet Symfony standard avec les bons patterns.
Conclusion : Warsaw comme point de départ
La SymfonyCon Warsaw 2026 s'annonce comme un moment charnière pour la communauté PHP. La présence d'une session dédiée à l'asynchronisme et à la haute performance dans le contexte des LLM confirme que ces sujets ne sont plus réservés aux équipes "scale-up" avec des infrastructures exotiques : ils concernent désormais tout projet qui veut intégrer de l'IA générative de façon sérieuse.
Si vous travaillez sur des applications Symfony qui consomment ou exposeront des LLM, la talk de Mathias Arlaud est à ne pas manquer. D'ici là, c'est le bon moment pour auditer vos StreamedResponse, vos configs Messenger, et questionner chaque findAll() de vos repositories.
Source originale : Symfony Blog — SymfonyCon Warsaw 2026: Asynchronous PHP & Symfony in High-Performance Systems
