Symfony sans HttpKernel ? À première vue, c’est comme un burger sans pain : techniquement possible, mais est-ce que ça a encore du sens ? Pourtant, l’idée d’un Symfony « HTTP-less » fait son chemin, portée par des développeurs qui veulent s’affranchir des contraintes du web pour des usages en CLI, en queue de tâches, ou même en… microservices (oui, encore eux). Alors, révolution ou simple exercice de style ? Spoiler : un peu des deux, mais surtout une bonne occasion de se demander si on a vraiment besoin d’un framework pour tout.
HttpKernel, ce mal-aimé qui fait pourtant le job
Depuis des années, HttpKernel est le cœur battant de Symfony. C’est lui qui transforme une requête HTTP en réponse, qui gère les middlewares, les événements, et toute la tuyauterie qui fait qu’un framework est un framework. Sauf que, comme tout composant central, il a ses détracteurs. Trop lourd, trop web-centric, trop lent pour des usages qui n’ont rien à voir avec le HTTP. Et c’est là que le bât blesse : pourquoi embarquer tout un système conçu pour le web quand on veut juste exécuter une commande en arrière-plan ?
La réponse classique, c’est : « Parce que Symfony est un framework full-stack, et que HttpKernel en fait partie. » Sauf que cette réponse, elle sent un peu le dogme. Symfony a toujours mis en avant sa modularité, alors pourquoi ne pas pousser le concept jusqu’au bout ? C’est exactement ce que propose l’approche HTTP-less : virer HttpKernel et ses dépendances pour ne garder que ce dont on a vraiment besoin. Un Symfony light, en somme. Mais light à quel point ?
Le syndrome du « tout-en-un » (ou comment Symfony est devenu un couteau suisse)
Symfony, à l’origine, c’était un framework pour le web. Puis sont arrivés les composants, les bundles, les outils CLI, et aujourd’hui, on peut presque tout faire avec : des APIs, des workers, des commandes, des websockets… Bref, Symfony est devenu un couteau suisse. Le problème, c’est qu’un couteau suisse, ça reste un couteau suisse : pratique pour bricoler, mais pas toujours adapté à un usage précis. Et c’est là que l’approche HTTP-less prend tout son sens : et si, au lieu d’utiliser Symfony comme un tout, on le désossait pour n’en garder que les morceaux utiles ?
Prenons un exemple concret : une commande CLI qui traite des données en arrière-plan. Avec Symfony classique, on va utiliser Console, mais on va aussi traîner derrière nous tout l’écosystème HTTP, même si on ne s’en sert pas. Avec une approche HTTP-less, on peut se contenter de DependencyInjection, EventDispatcher, et Console, sans le reste. Moins de dépendances, moins de mémoire utilisée, et surtout, moins de code à charger pour rien. En théorie, c’est génial. En pratique, c’est un peu plus compliqué.
Les pièges de l’HTTP-less : quand la simplicité devient un casse-tête
Parce que oui, désosser Symfony, ça a un coût. D’abord, il faut accepter de perdre une partie de l’écosystème. Plus de HttpKernel, donc plus de middlewares, plus de gestion fine des requêtes, et surtout, plus de compatibilité avec les bundles qui s’appuient dessus. Ensuite, il faut réinventer une partie de la roue : comment gérer les événements sans HttpKernel ? Comment structurer son code sans les conventions imposées par le framework ?
Un exemple ? Voici à quoi pourrait ressembler un bootstrap minimaliste pour une application HTTP-less :
$container = new ContainerBuilder();
$loader = new YamlFileLoader($container, new FileLocator(__DIR__.'/config'));
$loader->load('services.yaml');
$dispatcher = $container->get('event_dispatcher');
$dispatcher->dispatch(new MyEvent(), MyEvent::NAME);
$command = $container->get(MyCommand::class);
$command->execute();
Simple, non ? Sauf que derrière cette simplicité apparente se cachent des questions pas si triviales : comment gérer les erreurs ? Comment logger proprement ? Comment s’assurer que les services sont bien initialisés dans le bon ordre ? Bref, on se retrouve vite à réécrire des morceaux de HttpKernel sans s’en rendre compte. Et là, le gain de performance ou de légèreté devient discutable.
HTTP-less : pour qui, pour quoi ?
Alors, à qui s’adresse vraiment cette approche ? Clairement pas aux projets web classiques, où HttpKernel fait parfaitement le job. En revanche, pour des usages spécifiques comme :
- Des workers ou des queues de tâches qui tournent en arrière-plan, sans interaction HTTP.
- Des scripts CLI qui ont besoin de la puissance de Symfony (DI, événements) sans le poids du web.
- Des microservices ultra-légers où chaque milliseconde compte (même si, soyons honnêtes, si vous en êtes là, vous avez probablement déjà basculé sur Go ou Rust).
Dans ces cas-là, l’HTTP-less peut être une solution élégante. Mais attention à ne pas tomber dans le piège du « parce que c’est possible ». Symfony reste un framework conçu pour le web, et sortir de ce cadre, c’est accepter de perdre une partie de ses avantages. La question n’est pas tant « peut-on faire du Symfony sans HttpKernel ? » que « est-ce que ça vaut le coup ? ».
Conclusion : l’HTTP-less, une mode ou une vraie avancée ?
L’approche HTTP-less n’est ni une révolution ni une hérésie. C’est simplement une réponse à un besoin réel : celui de pouvoir utiliser Symfony en dehors du contexte web, sans traîner des dépendances inutiles. Est-ce que ça va devenir la nouvelle norme ? Probablement pas. Est-ce que ça peut être utile dans certains cas ? Sans aucun doute. Mais comme toujours en développement, la réponse n’est pas binaire : tout dépend de votre projet, de vos contraintes, et surtout, de votre tolérance à la complexité.
Se passer de HttpKernel, ce n’est donc pas casser Symfony : c’est simplement utiliser ses composants autrement, loin du traditionnel cycle requête-réponse.