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.

L’article explique comment améliorer les performances d’une application Symfony en envoyant les journaux d’audit de manière asynchrone plutôt que synchronisée : dans une approche classique, chaque opération Doctrine déclenche la génération et l’insertion immédiate d’un audit log en base de données, ce qui peut fortement ralentir les requêtes (par exemple en passant d’environ 10 ms à 30–50 ms avec une base distante). La solution proposée consiste à utiliser Symfony Messenger et AuditTrailBundle pour sérialiser les informations d’audit dans un message envoyé vers une file (RabbitMQ, Redis ou Doctrine), puis traité par un worker en arrière-plan qui écrit le log en base, ce qui découple la logique métier des contraintes de conformité et réduit quasiment à zéro l’impact sur le temps de réponse de l’application.

Pour les applications utilisant le composant Symfony Intl, certains territoires comme le Kosovo ne sont pas inclus par défaut car leur code pays (XK) n’est pas un code officiel ISO 3166 mais un code “user-assigned”. Par conséquent, des appels comme Countries::getNames() ou Countries::getName('XK') ne retournent rien ou déclenchent une erreur. Il suffit d’activer la variable d’environnement SYMFONY_INTL_WITH_USER_ASSIGNED=true pour que Symfony reconnaisse ces codes non officiels, permettant alors d’obtenir correctement les codes alpha-2 (XK), alpha-3 (XKK) et le code numérique 983 pour le Kosovo.

La décoration de services dans Symfony est présentée comme un levier architectural puissant mais souvent sous-utilisé, permettant d’étendre ou modifier le comportement d’un service existant sans changer son implémentation ni casser les dépendances, en enveloppant ce service dans un décorateur qui appelle l’original puis ajoute une logique supplémentaire. Cette approche facilite la séparation des responsabilités et l’évolution du code dans les projets matures, par exemple pour ajouter du logging, du caching ou des règles métier sans alourdir le service initial. L’article insiste sur le fait que cette technique permet de maintenir des services simples et modulaires tout en composant progressivement des comportements plus riches, notamment grâce à la possibilité d’empiler plusieurs décorateurs autour d’un même service.

L’article explique comment créer des commandes console puissantes dans Symfony pour automatiser des tâches comme les imports, les scripts de maintenance ou les opérations administratives, en utilisant le composant Symfony Console qui permet de définir des commandes exécutables via php bin/console. Il montre notamment comment structurer une commande en classe avec un nom, une description, des arguments et des options, puis implémenter la logique dans la méthode d’exécution, tout en utilisant les outils du framework pour gérer l’interaction utilisateur, afficher des messages et organiser proprement le flux d’exécution.

L’article explique qu’une application qui récupère des URLs fournies par des utilisateurs (pour des aperçus de liens, webhooks ou flux RSS) peut être vulnérable à des attaques de type SSRF, où un attaquant force le serveur à accéder à des ressources internes comme 127.0.0.1 ou l’endpoint de métadonnées AWS. Pour appliquer facilement le principe de programmation défensive avec Symfony, il suffit d’envelopper le client HTTP existant avec un décorateur comme NoPrivateNetworkHttpClient, qui bloque automatiquement les requêtes vers les réseaux privés sans modifier le reste du code. Cette approche illustre comment Symfony HttpClient permet d’ajouter des protections de sécurité simples et réutilisables grâce à son architecture basée sur des décorateurs.

Ce tutoriel explique comment réaliser du web scraping avec une commande Symfony Console, une approche propre et adaptée à la production. L'auteur, Marvelous Akpotu, souligne que le scraping est une tâche longue, susceptible d'échouer, souvent planifiée et automatisée, ce qui en fait une tâche idéale pour les commandes Symfony Console. L'article détaille les étapes pour scraper des données de pays, les parser avec DomCrawler, les trier et les afficher dans un tableau CLI propre. Les packages nécessaires sont symfony/http-client, symfony/dom-crawler et symfony/css-selector. L'auteur met en avant les avantages de cette méthode, comme la séparation des préoccupations, la planification par cron, l'architecture propre, la réutilisabilité et la facilité de refactorisation en jobs asynchrones. Des conseils pour le scraping en production sont également fournis, comme le respect des conditions d'utilisation et du fichier robots.txt, et l'ajout de délais entre les requêtes. Le code source complet est disponible sur GitHub.

L’auteur explique comment optimiser Doctrine ORM pour éviter non seulement le problème classique du N+1, où l’accès aux relations dans une boucle génère des dizaines voire centaines de requêtes, mais aussi le piège du produit cartésien qui survient lorsqu’on tente de tout charger en une seule requête avec de nombreux LEFT JOIN : bien que n’affichant qu’une requête dans le profiler, ce type de jointures multiplie les lignes SQL retournées (chaque combinaison de collections), ralentit la page et surcharge Doctrine lors de l’hydratation des objets. La solution proposée repose sur une hydratation en plusieurs étapes en chargeant d’abord les entités principales avec une relation, puis en « primeant » séparément les autres relations via des requêtes successives utilisant l’Identity Map de Doctrine, ce qui aboutit à quelques requêtes légères et prévisibles sans explosion des résultats.