Ce billet relate la migration vers Pest 5 d’une suite de tests Symfony, révélant les failles cachées derrière une apparence de succès (suite "verte"). L’auteur découvre que des outils comme PHPStan ou Rector n’étaient pas correctement configurés, des fichiers de test exclus des analyses, et des attributs PHPUnit obsolètes ignorés. La migration a aussi mis en lumière des problèmes de dépendances entre tests, des violations d’accessibilité détectées par un vrai navigateur, et un ralentissement important causé par Xdebug activé dans le container de développement.

L’enquête montre que la fiabilité d’une suite de tests dépend fortement de son environnement d’exécution et de sa configuration, bien au-delà du simple passage des tests. Les outils modernes comme Pest 5 peuvent exposer des incohérences passées inaperçues, même dans des projets matures. L’auteur souligne l’importance de réévaluer régulièrement son infrastructure de test pour éviter les faux positifs.

Enfin, la migration a permis d’optimiser la suite en identifiant des goulots d’étranglement, comme des tests trop lents ou des dépendances mal gérées, améliorant ainsi la qualité globale du projet.

L’article explique comment concevoir des gestionnaires de messages idempotents dans Symfony Messenger pour éviter les effets indésirables lors de la réception de messages en double, notamment dans des environnements distribués comme Kubernetes avec des files SQS. L’idée centrale repose sur la création d’effets métiers "effectivement uniques" malgré des livraisons multiples, en s’appuyant sur des identifiants stables (comme eventId), des contraintes d’unicité dans la base de données et des mécanismes de déduplication. L’auteur souligne que la fiabilité ne peut être garantie par les simples configurations de tentatives de renvoi, mais nécessite une approche systémique intégrant la gestion des clés d’idempotence et des transactions atomiques.

L’analyse détaille les risques liés à l’absence de transaction atomique entre la validation en base de données et la suppression du message de la file, illustrant comment un crash peut entraîner des doublons ou des pertes. Pour y remédier, il propose des solutions comme l’utilisation de contraintes uniques PostgreSQL, de tables de déduplication ou du Outbox Pattern pour sécuriser la production des messages. Ces méthodes permettent de garantir que, même en cas de livraisons multiples, l’effet métier ne se produit qu’une seule fois, tout en reconnaissant que cette approche ne couvre pas les systèmes externes (API, paiements, etc.), qui nécessitent leurs propres mécanismes d’idempotence.

Les DTO (Data Transfer Objects) dans Symfony sont des objets simples dont le rôle est de transporter des données entre les couches d'une application, notamment entre le contrôleur HTTP et la couche métier. Contrairement aux entités Doctrine, qui gèrent la persistance et la logique métier, les DTO se concentrent uniquement sur la structure des données nécessaires à un cas d'usage spécifique, sans logique ni dépendances. Par exemple, un DTO comme CreateProductInput peut inclure des annotations de validation pour garantir l'intégrité des données avant qu'elles n'atteignent le domaine métier.

L'utilisation des DTO apporte plusieurs avantages, notamment une meilleure sécurité en évitant les attaques par sur-assignation (mass assignment), une séparation claire entre l'API publique et le modèle de persistance, et une validation précoce des données. Ils améliorent également la maintenabilité en documentant explicitement les besoins d'un cas d'usage et en permettant une évolution indépendante des entités et des DTO. Par ailleurs, les DTO favorisent la testabilité, car ils sont faciles à instancier dans des tests unitaires sans dépendre de comportements spécifiques à l'ORM.

Pour une implémentation efficace, les DTO doivent être simples, explicites et immuables, de préférence en utilisant des classes final readonly en PHP 8.2+. Ils peuvent être adaptés à différents besoins, comme les entrées (input) et les sorties (output), qui peuvent avoir des exigences distinctes. En évitant de mélanger les responsabilités des entités et des DTO, les développeurs réduisent les risques de problèmes de sécurité et de couplage serré entre l'API et la base de données.

L’article critique l’usage des entités Doctrine dans Symfony, notamment leur double rôle de modèle de données et de formulaire, qui crée des incohérences entre les contraintes PHP, les validateurs et la base de données. Par exemple, une propriété marquée comme obligatoire (#[Assert\NotBlank], colonne SQL non nullable) peut être définie comme optionnelle en PHP (?string $name = null), permettant la création d’objets invalides qui ne seront rejetés qu’au moment du flush(). Cette approche fragilise la cohérence du code, notamment en violant les principes SOLID et DDD, et retarde la détection des erreurs.

L’auteur illustre ce problème par un cas concret où une commande d’import en production échoue à cause d’un champ vide dans un fichier CSV, alors que les tests et PHPStan passaient. Le code PHP autorise temporairement des données incomplètes (pour les formulaires), mais la base de données impose des contraintes strictes, révélant une contradiction entre les couches applicatives. Cette dualité entraîne des invariants non protégés, un modèle anémique et des vérifications redondantes de null dans le code métier.

Pour résoudre ces problèmes, l’article suggère de séparer clairement les responsabilités : utiliser des entités Doctrine strictes pour la persistance et des DTO (Data Transfer Objects) pour les interactions avec les formulaires. Cela permet de garantir la validité des données dès leur création et d’éviter les incohérences entre les types PHP, les validateurs et le schéma de la base de données.

L’article explique comment générer automatiquement la documentation AsyncAPI pour les événements Symfony, en s’inspirant de la génération d’OpenAPI pour les API REST. L’idée centrale est d’utiliser le bundle zeusi/asyncapi-bundle pour extraire les contrats des événements (messages, canaux, payloads) directement depuis le code, via des attributs PHP, évitant ainsi une documentation manuelle sujette aux erreurs.

AsyncAPI standardise la description des systèmes asynchrones (AMQP, Kafka, etc.), offrant des avantages similaires à OpenAPI : interface navigable, validation des schémas et source unique de vérité. Le bundle repose sur l’hypothèse que chaque message est représenté par une classe DTO annotée avec #[AsyncApiMessage], permettant de déduire la structure des données et le canal associé.

La configuration minimale se limite à l’installation du bundle et à la définition des métadonnées du document AsyncAPI. Les messages sont déclarés via des attributs, simplifiant la maintenance et garantissant la cohérence entre le code et la documentation générée.

L’auteur présente la création d’un serveur MCP (Model Context Protocol) intégré à une application Symfony, permettant à une IA comme Claude d’interagir avec un tableau de bord interne de suivi de projets. Ce serveur, sécurisé par OAuth des deux côtés (client et serveur), utilise l’authentification Google Workspace pour restreindre l’accès aux membres de l’organisation. Les outils MCP, définis comme des classes invocables avec des attributs dédiés, exposent des fonctionnalités comme la liste des projets ou des alertes de sécurité, avec des paramètres typés et des schémas JSON générés automatiquement à partir des signatures PHP.

L’implémentation repose sur le bundle MCP de Symfony AI, configuré via YAML pour définir les transports (stdio pour le développement, HTTP pour la production) et les instructions destinées à l’IA. Chaque outil, comme list-projects, est conçu comme un service Symfony minimaliste, exploitant l’injection de dépendances et des annotations pour décrire ses capacités. Les paramètres, contraints par des attributs comme #[Schema], permettent une interaction structurée avec les données du tableau de bord.

Cette approche illustre une intégration fluide entre Symfony et les protocoles modernes d’IA, offrant une alternative sécurisée aux requêtes manuelles tout en exploitant les mécanismes existants de l’application. L’auteur souligne la réutilisation des bonnes pratiques Symfony (services, configuration, typage) pour un serveur MCP fonctionnel et maintenable.

Symfony 8.2 introduit une fonctionnalité permettant de générer des URLs signées à usage unique grâce à un jeton d'état intégré dans le HMAC via le paramètre version. Contrairement aux versions précédentes où les liens signés pouvaient être réutilisés jusqu'à expiration, cette méthode les rend invalides après leur premier usage sans nécessiter de stockage côté serveur. Le mécanisme repose sur la concaténation discrète de ce jeton à l'URI avant le calcul de la signature, garantissant une invalidation automatique lorsque la valeur du jeton évolue (par exemple, un hash de mot de passe après une réinitialisation).

Cette approche se distingue des solutions alternatives comme login_link ou des implémentations maison, en offrant une sécurité renforcée contre les réutilisations frauduleuses tout en simplifiant la gestion des liens temporaires. Cependant, son efficacité dépend entièrement de la capacité à faire varier le jeton de manière fiable après chaque utilisation, ce qui peut poser des limites dans certains cas d'usage.

Symfony Flex est un plugin Composer qui automatise la configuration des projets Symfony lors de l'installation de dépendances. Il utilise des recipes pour appliquer mécaniquement les tâches répétitives comme l'activation de bundles, la création de fichiers de configuration ou la mise à jour des variables d'environnement, évitant ainsi les étapes manuelles fastidieuses. Par exemple, l'alias composer require messenger déclenche automatiquement l'installation du vrai package symfony/messenger et applique sa configuration via une recette dédiée.

Flex repose sur un système d'alias centralisé dans un fichier index.json, où chaque alias (comme messenger) est mappé à un package Composer réel (ex: symfony/messenger). Ces alias sont résolus avant même que Composer ne traite les dépendances, simplifiant la syntaxe pour les développeurs. Le plugin s'intègre à Composer via des hooks d'événements, comme POST_UPDATE_CMD, pour appliquer les recettes après l'installation des packages.

Une recette est un ensemble d'instructions (fichiers et configurations) qui guide Flex dans la mise en place des éléments nécessaires au bon fonctionnement d'un package Symfony. Contrairement à Composer, qui gère uniquement les dépendances PHP, Flex étend ses fonctionnalités via une API publique de plugins, rendant l'automatisation possible sans modifier le cœur de Composer.

La page d'exception de Symfony a été repensée avec une timeline cliquable remplaçant l'affichage empilé des exceptions, facilitant la navigation vers la cause racine. Un bouton « Copy as text » a également été ajouté pour formater automatiquement la stack trace et les logs en texte structuré, optimisé pour être collé directement dans un assistant IA, reflétant l'évolution des habitudes de débogage.

Cette refonte marque un changement de cible pour la page d'erreur, passant d'un outil conçu pour l'œil humain à une interface adaptée aux machines. Le texte copié est organisé en sections claires (stack trace et logs), avec une hiérarchie préservée, évitant les manipulations manuelles souvent nécessaires auparavant.

La discussion publique autour de cette PR a déjà permis des ajustements, comme la modification de la couleur du header, illustrant une approche collaborative dans l'itération du design. Cette évolution soulève aussi des questions sur la standardisation des formats d'erreur comme contrats d'API.

L’article explique comment utiliser les macros Twig dans Symfony, des fragments réutilisables similaires à des fonctions, avec des arguments optionnels et une gestion flexible des paramètres surnuméraires. Il détaille trois méthodes d’importation (via import, from ou _self) et souligne leur impact sur la lisibilité et la portée des macros.

Le piège principal réside dans la portée limitée des macros : elles n’ont pas accès aux variables du template appelant, ce qui peut causer des bugs silencieux comme des conditions toujours fausses. L’auteur illustre ce problème avec un exemple où une variable current_route n’est pas visible dans la macro, entraînant un rendu incorrect.

Enfin, l’article recommande de remplacer les macros par des Twig Components dans les projets modernes, plus adaptés pour éviter ces écueils et optimiser la maintenance des templates Symfony.

La RFC 10008, publiée le 15 juin 2026 et désormais en Proposed Standard, introduit le nouveau verbe HTTP QUERY pour simplifier la gestion des requêtes complexes dans les API REST. Ce protocole répond à un problème récurrent : les URLs surchargées avec de nombreux paramètres de filtrage (couleurs, tailles, prix, etc.), souvent contourné en utilisant la méthode POST, pourtant conçue pour des actions modifiant l’état du serveur. QUERY permet de structurer ces requêtes de manière plus propre et sémantique, en s’inspirant de la syntaxe des requêtes POST tout en restant conforme aux principes des méthodes HTTP.

L’article illustre son utilisation via un exemple concret en PHP, avec une API de timbres offrant des filtres avancés (pays, année, couleur) et une pagination. Contrairement à GET, où les paramètres s’ajoutent à l’URL sous forme de chaîne, QUERY les transmet dans le corps de la requête, évitant ainsi les limites de longueur et améliorant la lisibilité. Symfony a déjà intégré cette méthode dès sa version 7.4, bien avant sa standardisation finale, démontrant son utilité pratique.

Enfin, l’auteur souligne la simplicité de mise en œuvre de QUERY, avec une réponse serveur incluant des en-têtes personnalisables (comme un cache) et un corps JSON structuré, facilitant l’intégration côté client. Ce nouveau verbe HTTP marque une évolution majeure pour les API, offrant une alternative plus adaptée aux requêtes de lecture complexes que GET ou POST.

Ce billet explique comment optimiser les performances d’un blog Symfony utilisant Doctrine et PostgreSQL 16 en analysant les requêtes avec l’outil EXPLAIN. L’auteur détaille l’utilisation de EXPLAIN (ANALYZE, BUFFERS) pour examiner les plans d’exécution, identifier des problèmes comme le N+1 masqué par le cache, et vérifier l’efficacité des index via pg_stat_user_indexes. Sur les 47 index de la base, seuls 14 sont réellement utilisés, illustrant l’importance de cibler les optimisations.

L’article montre comment interpréter les plans d’exécution, comme un Index Scan pour une requête par slug ou un Seq Scan inefficace pour une jointure de catégorie. Il souligne que PostgreSQL privilégie la stratégie la moins coûteuse, même si un index existe, et met en lumière des fonctionnalités comme Memoize pour éviter des lectures redondantes. L’analyse révèle aussi des requêtes mal optimisées, comme une jointure forçant un parcours complet de table.

Enfin, le billet insiste sur la nécessité de combiner EXPLAIN et les outils de profilage Symfony pour corriger les requêtes problématiques avant de vérifier en production. L’exemple concret du flux RSS démontre comment PostgreSQL optimise automatiquement certaines opérations, tout en rappelant que chaque index doit justifier son existence par une utilisation réelle.

L’article explique comment appliquer correctement le pattern MVC en Symfony pour séparer la logique métier des contrôleurs et des vues, afin d’améliorer la maintenabilité du code. Il souligne que le Model ne se résume pas à une seule classe, mais se répartit entre entités, repositories et services, chacun ayant un rôle précis : les entités définissent la structure des données, les repositories gèrent les requêtes à la base de données, et les services encapsulent la logique métier.

L’auteur illustre cette séparation avec un exemple concret de contrôleur Symfony qui délègue la récupération d’un article à un repository et affiche les données via une vue Twig. Il met en garde contre l’illusion d’un MVC "propre" en rappelant que la logique métier ne doit pas être dispersée dans les contrôleurs ou les templates, mais centralisée dans des services dédiés.

Enfin, le billet insiste sur l’importance de cette discipline pour éviter un code désorganisé, tout en reconnaissant que la séparation idéale est souvent compromise dans la pratique. Il conclut que le MVC est davantage un vocabulaire commun qu’un plan rigide, et que sa mise en œuvre repose sur une réflexion constante sur l’architecture.

Un développeur explique comment il a utilisé un système RAG (Retrieval-Augmented Generation) sur son propre blog pour l'aider à écrire, plutôt que de générer du contenu à sa place. L'objectif était de vérifier si des idées similaires avaient déjà été abordées ou si des contradictions existaient dans ses anciens billets, en s'appuyant sur une recherche dans son corpus plutôt que sur la mémoire d'un modèle d'IA.

Le RAG fonctionne en deux étapes : d'abord, les documents sont transformés en vecteurs (embeddings) et stockés dans une base de données vectorielle ; ensuite, lors d'une requête, la question est également vectorisée et les documents les plus proches sont récupérés pour enrichir le prompt du modèle. L'auteur détaille une implémentation concrète avec Symfony AI, utilisant PostgreSQL avec pgvector, un vectorizer pour calculer les embeddings, et un indexeur qui découpe les articles en morceaux pour une recherche plus précise.

L'auteur rejette l'idée d'un chatbot public pour son blog, principalement pour des raisons économiques (coût des appels au modèle) et parce qu'il préfère utiliser le RAG comme outil personnel pour relire et vérifier ses écrits, plutôt que comme un générateur de contenu pour les visiteurs.

Ce tutoriel explique comment créer un filtre personnalisé pour EasyAdmin dans Symfony, lorsque les filtres natifs ne suffisent pas. L'auteur prend l'exemple concret d'un filtre "À la une" pour les billets d'un blog, qui nécessite une logique complexe (plage de dates active avec opérateurs combinés). Il détaille le processus en deux étapes : d'abord l'implémentation de l'interface FilterInterface avec la méthode apply() pour construire la requête SQL, puis la création d'un FilterType pour le formulaire.

L'article souligne que les filtres natifs (comme ChoiceFilter ou NullFilter) couvrent la plupart des cas simples, mais qu'un filtre custom devient nécessaire pour des conditions SQL avancées. Il montre comment structurer la classe du filtre en utilisant le FilterTrait et une méthode statique new() pour la configuration, tout en illustrant avec un exemple complet de filtre gérant à la fois des états binaires et des plages de dates.

Ce billet explique comment sécuriser un back-office EasyAdmin sans utiliser setPermission(), en s'appuyant sur trois couches de sécurité natives à Symfony. L'approche combine access_control par host, l'attribut #[IsGranted] au niveau des contrôleurs et des gardes personnalisées dans les actions sensibles, offrant une sécurité robuste et indépendante d'EasyAdmin.

La première couche repose sur access_control dans la configuration Symfony, restreignant l'accès à l'admin via un sous-domaine dédié (ex: admin.lecodeestdanslepre.fr) avec le rôle ROLE_ADMIN. Cette méthode agit comme un premier filet de sécurité avant même l'arrivée de la requête au contrôleur. La deuxième couche utilise #[IsGranted('ROLE_ADMIN')] sur chaque contrôleur pour doubler la vérification côté Symfony, garantissant que seules les actions autorisées sont exécutées.

Enfin, une troisième couche de sécurité est implémentée directement dans les actions métier pour des contrôles plus fins, comme la validation CSRF ou la vérification de l'état d'une entité. Ces trois niveaux de sécurité, tous issus de Symfony, assurent une protection complète tout en restant modulaires et adaptables à d'autres solutions que EasyAdmin.

WebMCP permet d'exposer des actions typées sur une page web, facilitant l'interaction entre agents IA et sites web. Contrairement aux méthodes traditionnelles où les agents doivent analyser le contenu visuel, WebMCP déclare les actions via un contrat clair (nom, description, schéma JSON), simplifiant ainsi les échanges. Cette approche expérimentale, encore en draft au W3C et testée via un origin trial dans Chrome, offre deux méthodes d'intégration : impérative (via JavaScript) ou déclarative (via attributs HTML), sans nécessiter de serveur dédié.

L'article explique comment tester WebMCP localement en activant un flag dans Chrome et en utilisant une extension dédiée, permettant de visualiser et manipuler les outils exposés. Pour une intégration avec Symfony et Stimulus, il suffit de créer une façade JavaScript qui réutilise des endpoints existants, évitant ainsi de dupliquer la logique métier. L'authentification repose sur les cookies du navigateur, garantissant que l'agent dispose des mêmes droits que l'utilisateur humain.

Bien que prometteur, WebMCP reste une technologie émergente, dépendante des évolutions de la spécification et de l'adoption par les navigateurs. Son utilisation actuelle se limite principalement à Gemini dans Chrome, et son avenir dépendra de la stabilité de la spécification et de l'intérêt des développeurs.

Ce billet explique comment intégrer un serveur MCP (Model Context Protocol) dans un projet Symfony en utilisant le bundle symfony/mcp-bundle. L'objectif est d'exposer des outils via un endpoint HTTP standardisé, permettant à des clients comme Claude d'interagir dynamiquement avec ces outils sans nécessiter une API REST classique. La configuration repose sur un fichier YAML minimal, où l'on précise notamment le transport HTTP (plutôt que stdio) et les répertoires à scanner pour découvrir les outils, un point crucial souvent omis dans la documentation officielle.

L'auteur détaille ensuite la création d'un outil MCP via une méthode PHP annotée avec #[McpTool], où la description et les paramètres typés définissent le comportement exposé. Cependant, il souligne des limites actuelles du bundle, comme l'absence de schéma de sortie typé, obligeant à gérer manuellement la sérialisation des réponses. La sécurité est également abordée, avec une recommandation d'isoler la route MCP sur un sous-domaine dédié pour limiter les risques liés à l'exécution de code privilégié.

Enfin, le billet met en garde contre les pièges spécifiques à la production, notamment les comportements encore instables des versions 0.x du bundle et du SDK MCP, ainsi que les différences entre la version du serveur exposée et celle du bundle. L'auteur insiste sur l'importance de bien configurer le transport HTTP et de sécuriser l'endpoint pour éviter des vulnérabilités dans un environnement partagé.

Symfony 8.1 introduit un kernel HTTP-less conçu pour simplifier les projets neufs sans composants HTTP, comme des outils en ligne de commande ou des microservices. Cette version extrait ServicesBundle et ConsoleBundle de FrameworkBundle, permettant un conteneur léger avec injection de dépendances et commandes CLI, sans surcharge HTTP.

En revanche, cette approche n’est pas adaptée aux workers existants (comme ceux de Messenger), car FrameworkBundle reste nécessaire pour configurer des fonctionnalités comme le routage ou la messagerie. Réimporter FrameworkBundle annulerait les gains de légèreté, rendant le kernel HTTP-less inutile dans ce contexte.

Pour les applications full-stack existantes, aucune action n’est requise : FrameworkBundle intègre déjà les nouveaux bundles via des attributs #[RequiredBundle], maintenant ainsi la compatibilité sans modification.

Ce tutoriel explique comment implémenter le chiffrement au niveau des champs dans Symfony avec Doctrine, afin de protéger les données sensibles stockées en base. L’idée centrale est d’encrypter uniquement certains champs d’entités Doctrine (comme des notes privées ou des clés API) plutôt que l’ensemble de la base, permettant ainsi à l’application de continuer à manipuler des valeurs lisibles en PHP tout en stockant des données chiffrées dans la base. L’auteur recommande cette approche pour limiter les risques en cas de fuite de sauvegardes ou d’accès non autorisé à la base, tout en évitant les inconvénients du chiffrement global (perte de fonctionnalités comme les recherches ou tris).

L’article détaille les cas d’usage pertinents (champs contenant des données personnelles ou critiques) et les compromis à considérer, comme la complexité accrue pour les opérations de requêtage. Il présente également un exemple concret avec le bundle doctrine-encryption-bundle, illustrant comment un champ comme privateNote est chiffré en base tout en restant accessible normalement dans le code PHP. L’outil utilisé, disponible via Composer, simplifie l’intégration de cette fonctionnalité dans un projet Symfony.