L’article explique la migration d’un outil de génération de PDF, wkhtmltopdf, vers Gotenberg dans une application Symfony legacy, en évitant de perturber les endpoints existants. L’idée principale est de découpler la génération de PDF du conteneur API pour améliorer les performances et la maintenabilité, car wkhtmltopdf consommait trop de ressources CPU et reposait sur des dépendances locales (fichiers, polices, images). Le processus a nécessité de refactoriser l’architecture pour externaliser le rendu HTML vers un conteneur dédié, tout en gérant les différences de rendu entre les moteurs (problèmes de polices, de mise en page ou de chemins d’accès).

La migration a révélé des défis techniques, comme la gestion des chemins de fichiers (remplacement des références locales par des URLs accessibles) et les écarts de rendu entre wkhtmltopdf et Chromium (Gotenberg), entraînant des modifications de mise en page inattendues. L’approche adoptée a consisté à migrer progressivement, type de document par type de document, pour limiter les risques et permettre des ajustements fins. L’objectif était de préserver la compatibilité des endpoints tout en améliorant l’infrastructure.

L’article propose une solution pour tester efficacement le JavaScript dans Symfony Asset Mapper, souvent confronté à des erreurs comme ERR_MODULE_NOT_FOUND en raison de l’incompatibilité entre l’importmap.php de Symfony et les outils Node.js. L’auteur suggère d’utiliser des liens symboliques pour faire correspondre les fichiers Symfony (dans assets/vendor ou vendor) avec la structure attendue par Node.js dans node_modules, évitant ainsi de dupliquer ou modifier les imports.

Un script PHP automatise la création de ces liens symboliques en analysant l’importmap.php, permettant à Node.js de résoudre les modules comme en production. Cette méthode s’intègre via un pretest dans le package.json, exécutant le script avant chaque test. L’approche privilégie le test runner natif de Node.js (depuis la version 20) pour sa simplicité, sa rapidité et son absence de configuration complexe, tout en testant les fichiers réels utilisés en production.

Twig 3.24.0, sorti avec Symfony 7.4, introduit des fonctionnalités avancées pour simplifier la création de composants UI réutilisables, répondant aux besoins des systèmes de design modernes et des frameworks comme Tailwind. Parmi les nouveautés, la fonction html_attr, la stratégie d'échappement html_attr_relaxed et les opérateurs null-safe améliorent la gestion des attributs HTML et des données dynamiques, réduisant ainsi la complexité des templates.

L'article explique comment abandonner les tableaux non structurés pour des DTOs strictement typés et validés, combinés à des attributs PHP 8.x et à Symfony 7.4's #[MapRequestPayload], afin de transmettre des données propres et validées directement aux templates Twig. Cela renforce la robustesse des applications tout en maintenant une bonne expérience de développement.

Pour utiliser ces fonctionnalités, il est nécessaire d'installer les packages twig/html-extra, symfony/serializer et symfony/validator, et de vérifier que Twig 3.24.0 ou supérieur est bien installé. L'article détaille également la configuration requise et présente un exemple concret de création d'un composant Button avec des DTOs stricts.

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.