SymfonyLive Paris 2026 : TUI, Base de données et FrankenPHP
Publié le 09 avril 2026
La SymfonyLive Paris 2026 s'est tenu fin mars, comme chaque année. Pas de blabla conceptuel à l'horizon : on a eu droit à des évolutions pragmatiques et puissantes, avec un focus très net sur la CLI, l'infrastructure et l'intégration de l'IA. Tour d'horizon condensé des annonces principales de ce qu'il ne fallait pas rater durant cette nouvelle édition.
Premier Jour : Le terminal réinventé, sécurité et IA
Dès le jeudi matin, Fabien Potencier a donné le ton en présentant un composant attendu depuis sa première annonce à la SymfonyCon Brussels 2023: le composant Symfony Terminal.
Avec l'essor des code agents, nous passons de plus en plus de temps dans nos consoles. Ce composant offre un toolkit TUI (Text User Interface) particulièrement massif. On y a découvert :
- La gestion du templating via Twig et des widgets (text, input, overlay...) ;
- La possibilité de gérer ses feuilles de style en PHP pur ou même avec des classes type Tailwind ;
- Une démo d'un widget input bluffant en direct, reprenant toutes les fonctionnalités que l'on attend d'un terminal classique.
Le moteur derrière tout ça ? Les PHP Fibers, avec un principe de keybinding géré en PHP pour les actions de l'utilisateur et une boucle d'événements tournant entre 4 et 100 fps. L'ouverture en direct de la Pull Requests pour intégrer le composant à Symfony 8.1 a fait son petit effet, tout comme la mention d'un nouveau composant capable de convertir des images ou des GIF en ASCII art.
Côté sécurité, on a vu comment chiffrer des données avec Doctrine tout en les gardant recherchables. Le concept repose sur une gestion de clés (KMS vers Encryption Key vers base de données) et s'effectue directement au niveau du Type, utilisable dans les attributs Symfony. L'astuce pour la recherche ? Créer des champs hashés agissant comme des tags, hydratés via des listeners Doctrine.
Sur la performance pure, le REX concernant la migration de 100 Crons vers Symfony Scheduler a soulevé des problématiques de scalabilité à partir d'un certain volume. La solution temporaire expliquée consistait à utiliser des Event Listeners pour avoir plusieurs workers. Plus tard dans la matinée, la présentation du JsonStreamer a mis une claque à l'audience (comme à chacune de ses mentions en fait !). L'utilisation de l'attribut JsonStreamable et d'un ObjectMapper pour hydrater des entités depuis un DTO apporte un gain de performances colossal.
L'après-midi, plongée dans la création d'un code agent PHP. La démo avec models.dev couplé à Symfony TUI et Claude Opus a mis tout le monde d'accord. La règle d'or à retenir : le contexte est bien plus important que le prompt en lui-même. Il est fortement conseillé de résumer les actions dans un SKILL.md avant de lui demander la rédaction d'une feature. Le mode existant de planification des agents existe pour ça !
L'obsession de la performance et l'effet FrankenPHP
Difficile de passer à côté de FrankenPHP. Notre coopérateur Kévin Dunglas a démontré comment l'outil s'intègre parfaitement avec les Development Containers (supportés par Claude Code, entre autres) pour avoir un environnement de dev standardisé. Surtout, Symfony Docker inclut maintenant cette évolution par défaut.
C'est aussi durant cette journée que nous avons annoncé l'existence et la première release de Ember durant la session de Lightning Talks. Cet outil permet un niveau d'observabilité et de monitoring encore jamais atteint pour vos applications utilisant FrankenPHP. Vous pouvez retrouver le projet sur GitHub ainsi que notre article de blog d'annonce, expliquant tout ce qu'il y a à savoir sur ce nouveau compagnon à FrankenPHP.
#Second Jour : Maîtriser l'architecture et la donnée
La dynamique du premier jour a été prolongée le vendredi matin avec le concept des sidekicks, présenté par Nicolas Grekas. Face au coût exponentiel d'une requête PHP devant solliciter de multiples services, la solution présentée consiste à écrire les modifications en mémoire grâce à des tâches de fond. Les scripts PHP "frontaux" pourraient alors récupérer ces données sans appel externe. Exemple typique : votre Redis Sentinel pointe vers l'instance maître et change régulièrement. Le sidekick s'occupe d'interroger la sentinelle, et votre code principal à juste à lire le retour du sidekick. L'idée d'avoir ces sidekicks sous forme de bundles semble être la prochaine étape logique. Les PRs sur FrankenPHP sont en cours de review, à suivre donc !
Ensuite, les pendules sont mise à l'heure sur l'héritage avec Doctrine, décortiquant MappedSuperclass et Discriminant. La Single Table Inheritance (STI) stocke tout dans une seule table. Ça reste la stratégie la plus performante malgré des tables qui grossissent vite avec des colonnes inévitablement nulles. À l'inverse, la Class Table Inheritance (CTI) crée une table pour chaque acteur. Le schéma est normalisé, mais les JOIN systématiques cassent les performances sur de gros volumes en lecture. L'occasion de rappeler les bases : utiliser un DiscriminatorMap explicite, des valeurs d'enum, limiter à un seul niveau d'héritage et surtout, indexer ses colonnes.
Enfin, les bases de données ont fermé la marche :
- ClickHouse : une base de données orientée colonnes, taillée pour répondre aux problèmes de coûts de cycles de vie sur les gros projets, avec une meilleur mise à l'échelle que le relationnel
- Une dernière présentation solide sur l'utilisation combinée de JSON et SQL.
Bref, une édition 2026 qui confirme que notre écosystème ne s'endort pas sur ses lauriers. On simplifie l'infra, on pousse les performances de la CLI, et on intègre l'IA intelligemment. On a hâte de voir la suite en prod.
