Ce billet présente une méthode pour déployer rapidement des applications Symfony en production grâce à une combinaison d'outils modernes. L'auteur souligne d'abord l'accélération du développement grâce à l'IA, qui permet de créer des prototypes fonctionnels en quelques heures, mais souligne que l'infrastructure doit suivre pour éviter un goulot d'étranglement. Il propose ensuite Once, un outil open source de 37signals, qui automatise le déploiement d'applications Docker sur un seul serveur via un reverse proxy intégré et une gestion automatique des certificats SSL.
L'article détaille l'installation simplifiée de Once, qui repose sur Docker et Kamal, et son fonctionnement avec un wildcard DNS pour attribuer automatiquement un sous-domaine à chaque nouvelle application déployée. Cette approche élimine les configurations manuelles de reverse proxy ou de certificats, permettant un déploiement en quelques minutes après un simple git push.
Enfin, l'auteur explique pourquoi il a adopté FrankenPHP, un runtime PHP intégré à Caddy, qui remplace avantageusement la stack classique (Nginx, PHP-FPM, Mercure) par un seul conteneur. Grâce à l'IA, la génération et le débogage des fichiers Dockerfile sont devenus accessibles, rendant cette solution à la fois performante et simple à mettre en œuvre pour des projets PHP modernes.
Les LiveComponents de Symfony offrent une solution efficace pour créer des interfaces dynamiques sans recourir à des bibliothèques front-end lourdes, en s'appuyant sur des attributs Twig et une stack simple. Leur simplicité d'utilisation, comme l'ajout d'attributs pour des fonctionnalités comme l'édition inline ou le live reload, les rend attractifs pour les développeurs back-end peu enclins au développement front-end. Cependant, leur utilisation intensive révèle des limites, notamment en matière de sérialisation des objets Doctrine complexes, comme les collections ou les relations entre entités.
L'auteur illustre ces limites avec un exemple concret où la sérialisation d'une collection d'entités Loan échoue, obligeant à recourir à des solutions comme l'activation du sérialiseur ou la définition de types concrets. Cette problématique, bien que simplifiée par rapport à une architecture front-end classique, montre que la promesse d'une solution "tout-en-un" s'effrite face à des cas d'usage avancés, comme la gestion de fichiers ou de collections complexes. Les LiveComponents, bien que puissants pour des démonstrations, révèlent des contraintes techniques qui peuvent compliquer leur adoption à grande échelle.
La sortie de Symfony UX 3.0.0 marque une évolution majeure en abandonnant les dépendances obsolètes de la version 2.x et en relevant les exigences minimales à PHP 8.4 et Symfony 7.4. Cette version se concentre sur des composants Twig robustes, une intégration frontend-backend fluide et des standards web natifs, simplifiant ainsi le développement sans JavaScript personnalisé.
L’article propose un tutoriel pratique pour créer une plateforme immobilière moderne en exploitant les nouvelles fonctionnalités, comme les composants Twig, l’autocomplétion pour les commodités et l’outil Cropper.js pour les galeries d’images. L’installation repose sur des packages spécifiques, avec une vérification des composants via la commande debug:twig-component.
Enfin, l’exemple illustre la création d’un composant réutilisable PropertyCard en PHP 8.4, utilisant des attributs et des classes CSS dynamiques via la fonction html_cva de twig/html-extra, pour un rendu optimisé et maintenable.
L’article explique comment optimiser la gestion de gros fichiers JSON dans Symfony pour éviter les problèmes de mémoire, notamment l’OOM killer. L’idée principale repose sur l’utilisation du composant natif symfony/json-streamer de Symfony 7.4, qui permet de parser les données en flux continu plutôt que de charger l’intégralité du fichier en mémoire. Cette approche réduit drastiquement l’empreinte mémoire, évitant les pièges des méthodes traditionnelles comme json_decode() ou le Serializer, qui dupliquent les données en mémoire.
L’auteur détaille les mécanismes sous-jacents, comme le fonctionnement en DOM des méthodes classiques, qui consomment jusqu’à cinq fois plus de RAM que la taille du fichier initial. À l’inverse, le streaming lit les données octet par octet et ne conserve en mémoire que les éléments actuellement traités, grâce à des DTOs (Data Transfer Objects) typés et à l’attribut #[JsonStreamable]. Cette méthode est particulièrement adaptée aux fichiers de plusieurs gigaoctets ou aux webhooks massifs.
Pour implémenter cette solution, l’article recommande d’installer trois composants Symfony (json-streamer, type-info et object-mapper) et d’exploiter leur intégration native. L’architecture repose sur des Generators PHP, qui libèrent automatiquement la mémoire après traitement de chaque objet, garantissant une consommation constante et minimale.
L’étude du codebase d’etcd, un magasin clé-valeur distribué écrit en Go, a inspiré l’auteur à repenser ses pratiques en PHP. Il met en avant des principes d’architecture logicielle applicables quel que soit le langage, comme la définition stricte des contrats d’API via des DTO typés pour éviter les ambiguïtés et les erreurs en production.
L’auteur souligne également l’importance de la séparation des responsabilités, où chaque service ou classe ne doit accomplir qu’une seule tâche, évitant ainsi les contrôleurs monolithiques difficiles à maintenir. Enfin, il compare les intercepteurs d’etcd aux écouteurs d’événements et au système de messages de Symfony, montrant comment une composition modulaire améliore la lisibilité et la maintenabilité du code.
L’article explique comment éviter les race conditions dans Symfony Workflow en production, illustré par un bug où une commande passe simultanément en état "expédié" et "annulé". L’auteur montre que Symfony Workflow seul ne gère pas les accès concurrents, laissant deux processus modifier le même état en parallèle.
La solution repose sur le composant Symfony Lock, qui permet de verrouiller une ressource (comme une commande) pendant une transition. En utilisant Redis comme stockage partagé, le verrou empêche les accès simultanés et garantit qu’un seul processus peut modifier l’état à la fois. L’article détaille la configuration et l’intégration avec Symfony Messenger pour une gestion robuste des conflits.
L’auteur propose une implémentation progressive, partant d’une approche naïve pour aboutir à une solution production-ready, adaptable à tout projet Symfony utilisant des workers asynchrones.
La SymfonyLive Paris 2026 a mis en avant des évolutions concrètes pour Symfony, avec un accent sur la CLI, l'infrastructure et l'intégration de l'IA. Le premier jour a notamment révélé le nouveau composant Symfony Terminal, un toolkit TUI (Text User Interface) permettant de créer des interfaces en ligne de commande avec Twig, des widgets et des styles CSS en PHP pur, reposant sur les PHP Fibers pour une gestion fluide des interactions. Des annonces ont également porté sur le chiffrement des données avec Doctrine tout en conservant leur rechercheabilité, ainsi que sur des optimisations de performance comme le composant JsonStreamer pour l'hydratation d'entités depuis des DTO.
L'événement a aussi souligné l'importance de FrankenPHP, présenté comme un outil clé pour standardiser les environnements de développement via les Development Containers, désormais intégré par défaut dans Symfony Docker. Une nouvelle release d'Ember, un outil d'observabilité pour FrankenPHP, a été annoncée, offrant un niveau de monitoring inédit pour les applications utilisant cette technologie.
Enfin, la conférence a abordé des sujets comme la migration vers Symfony Scheduler, les défis de scalabilité des tâches planifiées, et l'utilisation de code agents PHP pour automatiser des tâches, avec une démonstration mettant en avant l'importance du contexte et de la planification dans l'efficacité des agents.
L’édition 2026 du SymfonyLive Paris a réuni la communauté Symfony à la Cité Universitaire, confirmant l’événement comme un rendez-vous incontournable malgré les évolutions rapides du secteur technologique. JoliCode y était présent et revient sur cette conférence, mettant en lumière l’annonce majeure de Fabien Potencier : Symfony TUI, un nouveau composant conçu pour moderniser les interfaces en terminal.
Symfony TUI, inspiré par l’essor de l’IA, permet une interaction avancée avec les grands modèles de langage (LLMs) directement depuis la console, tout en améliorant l’ergonomie des outils existants comme Symfony Console. Fabien a démontré ses capacités avec un coding agent et un jeu de Tetris fluide, illustrant son potentiel pour des interfaces graphiques modernes en PHP. Le composant repose sur des technologies comme PHP Fibers et Revolt pour des animations asynchrones, et propose trois méthodes de style (CSS-like, classes utilitaires ou inline) ainsi qu’un système de widgets natifs.
Cette innovation ouvre des perspectives pour l’affichage en console et l’intégration de l’IA, tout en s’appuyant sur l’héritage de Symfony Console. Fabien Potencier a également évoqué une approche collaborative future, où les contributeurs pourraient partager des prompts plutôt que des solutions complètes.
ApiKit est un bundle Symfony léger conçu pour simplifier la création d'API REST propres en réduisant le code répétitif dans les contrôleurs. Il automatise des tâches comme la validation des entrées, la normalisation des réponses JSON et la gestion des exceptions, permettant aux développeurs de se concentrer sur la logique métier plutôt que sur l'infrastructure.
Le bundle impose une structure de réponse unifiée, facilitant la maintenance et l'intégration pour les clients (frontend, mobile, microservices). Il gère automatiquement les erreurs de validation et les exceptions, avec des formats cohérents pour les succès et les échecs, tout en restant flexible : les DTO ne sont pas obligatoires, et les dépendances reposent sur des composants Symfony standards.
ApiKit simplifie ainsi le développement d'API en Symfony, réduisant la duplication de code et améliorant la cohérence, sans imposer de contraintes strictes sur l'architecture des projets.
L’article explique comment implémenter une architecture hexagonale dans Symfony 7 pour séparer clairement les couches métier et infrastructure, en combinant des motifs DDD et une approche pilotée par événements. L’idée centrale est de placer le domaine au centre, indépendant du framework, tandis que les dépendances externes (Symfony, Doctrine, etc.) s’interfacent via des ports définis par le domaine. Cela permet une meilleure testabilité, évolutivité et flexibilité, comme illustré par un exemple concret de structure de code organisée en trois couches (Domain, UserInterface, Infrastructure).
L’auteur souligne les limites des architectures traditionnelles en couches, où les services deviennent des "classes-dieu" et les tests complexes. En adoptant cette approche, les commandes, requêtes et événements sont gérés de manière isolée, facilitant les changements techniques (ex : remplacer Doctrine par MongoDB) sans impacter la logique métier. L’intégration de Symfony Messenger renforce le caractère événementiel, permettant une communication asynchrone entre les composants.
Enfin, l’article aborde brièvement la séparation des lectures et écritures (CQRS), bien que le détail soit tronqué. L’accent est mis sur la praticité : une implémentation concrète, adaptable, qui évite les pièges des architectures monolithiques tout en restant compatible avec les outils Symfony existants.
Ce template opinionated et prêt pour la production simplifie le démarrage d’un projet PHP en intégrant Symfony 8, SvelteKit 2 (avec Svelte 5), PostgreSQL 17 et une stack d’outils qualité (PHPStan niveau max, 10 extensions dont phpstan-symfony, phpstan-doctrine et phpat pour les tests d’architecture). L’architecture Same-Origin (via Caddy) évite les complexités CORS et simplifie l’authentification. Infrastructure gérée par OpenTofu sur Hetzner. Idéal pour les petits projets ou équipes solo.
Découvrez comment Symfony simplifie la gestion du temps dans vos applications avec son composant Clock, basé sur la norme PSR-20. L'article explique pourquoi l'accès direct au temps système (new \DateTimeImmutable()) crée des dépendances implicites difficiles à tester, et propose une solution en injectant le temps comme une dépendance explicite via ClockInterface. Un exemple concret avec un service de génération de tokens illustre comment rendre votre code plus robuste et testable. Une lecture utile pour améliorer la maintenabilité de vos projets Symfony ! 🕒
Découvrez comment implémenter une gestion robuste des passkeys et un système de récupération de compte dans Symfony avec WebAuthn. Cet article explique comment créer un tableau de bord utilisateur pour gérer ses clés d'accès (affichage, révocation), générer des codes de récupération uniques et sécurisés, et intégrer ces fonctionnalités via des événements Symfony et Doctrine. Une solution clé pour éviter les failles liées aux liens magiques par email tout en maintenant une expérience utilisateur fluide. Parfait pour renforcer la sécurité d'une application Symfony !
L'auteur partage son expérience de création d'une application de suivi d'habitudes (SmartHabit Tracker) en partant d'un template Symfony/SvelteKit préconfiguré. Le projet met en avant une approche statistique (algorithme MAD) pour des notifications intelligentes, adaptées aux habitudes réelles des utilisateurs, et une synchronisation en temps réel via Mercure. L'architecture évite Firebase au profit de solutions open source (Web Push, ntfy, APNs), avec une attention particulière portée aux tests (PHPStan, mutation testing) et à la scalabilité. Un exemple concret de l'importance des bonnes pratiques dès la conception.
Découvrez comment l'équipe de Benoit Leveque a intégré leur wiki BookStack à des assistants IA (Claude, Cursor) via un serveur MCP basé sur Symfony (symfony/mcp-bundle). L'enjeu ? Permettre aux IA d'accéder directement à la documentation interne tout en conservant une traçabilité précise des actions (qui a modifié quoi). Leur solution évite l'écueil d'un jeton API partagé (qui fausserait les logs) en faisant transiter les identifiants utilisateurs via des en-têtes HTTP dans la configuration MCP. Un exemple concret de l'intérêt du protocole MCP pour l'intégration sécurisée et contextuelle des outils d'IA.
JoliCode explique comment ils ont modernisé une application Symfony 7.4 (avec PHP 8.4 et FrankenPHP) pour l'archéologie, en permettant un déploiement hybride : SaaS en ligne et On-Premise (OP) hors réseau. Leur solution repose sur une stack Docker unifiée (mêmes images pour tous les environnements), pilotée par des tâches Castor pour simplifier le développement local. L'article détaille l'architecture Docker, l'automatisation des builds et le déploiement OP, avec des feature flags via variables d'environnement. Une approche pragmatique pour concilier flexibilité et contraintes métiers.
L'article explore les limites des tâches planifiées via cron dans les applications Symfony et propose une migration vers Symfony Scheduler pour une gestion plus fiable des jobs. Il décrit comment passer d'une commande cron basique à une solution intégrée utilisant Messenger, des verrous (locks) et une gestion d'état, permettant ainsi de gérer les retries, l'idempotence et la continuité des processus métiers. L'auteur souligne que cette approche, bien que plus complexe, offre une meilleure intégration et une responsabilité accrue de la gestion du temps au sein de l'application.
Ce guide explique comment implémenter une authentification sans mot de passe dans Symfony 7.4 en utilisant les passkeys basés sur les standards WebAuthn et FIDO2. Les passkeys remplacent les mots de passe par des paires de clés cryptographiques, stockant la clé privée sur l'appareil de l'utilisateur et la clé publique sur le serveur. L'article détaille l'architecture nécessaire, les dépendances à installer, et les entités à créer pour gérer les utilisateurs et leurs passkeys, éliminant ainsi complètement les mots de passe de l'application.
Marcel Moll partage son expérience avec Symfony Messenger, soulignant des aspects non couverts par la documentation. Il aborde des problèmes rencontrés avec une application e-commerce sous forte charge, comme la gestion de la mémoire, les stratégies de réessai, et la configuration des transports. Il insiste sur l'importance de la version des classes de messages pour éviter les échecs de désérialisation, et recommande des bonnes pratiques pour les déploiements et la gestion des files d'attente. Un guide pratique pour les développeurs expérimentés avec Symfony.
L’article explique comment utiliser le même pool de cache Symfony à la fois dans un contrôleur et dans Twig afin d’éviter de recalculer plusieurs fois les mêmes données. L’idée consiste à injecter le même service de cache (par exemple cache.app) dans le contrôleur pour stocker ou récupérer des données coûteuses, puis à l’utiliser également dans Twig via l’extension de cache pour mettre en cache un fragment de template avec la même clé ou les mêmes tags. Cette approche permet de centraliser la logique de cache, de partager les données mises en cache entre backend et rendu Twig, et de faciliter l’invalidation (par exemple via des tags) lorsque les données changent.