Dans une application Symfony multi-tenant, un rôle PostgreSQL ne possédant aucune table peut néanmoins contourner les politiques Row-Level Security (RLS) s’il hérite des privilèges du propriétaire. L’auteur montre pourquoi un contrôle fondé sur current_user et session_user passe à côté de cette faille et recommande pg_has_role pour inspecter les appartenances. Il détaille une configuration à trois rôles avec GRANT ... WITH INHERIT FALSE, SET TRUE, puis souligne un piège de Doctrine DBAL : SET LOCAL ROLE et le contexte du tenant doivent être appliqués dans une transaction englobant les lectures.

Symfony 8.2 introduit des possibilités de versionnement d'API sans duplication des classes ni transformation manuelle des réponses. Le Serializer permet d'associer #[SerializedName] et #[SerializedPath] à des groupes de sérialisation pour adapter les noms et la structure des champs selon la version. L'option ignored_groups facilite l'exclusion de propriétés. L'article détaille les pièges de configuration, recommande des tests stricts des contrats JSON et précise quand conserver des classes distinctes, notamment lorsque la logique métier ou les validations divergent.

Une architecture logicielle réussie dépend autant des contraintes qu’on accepte d’abandonner que de celles qu’on respecte. Tolérer des données temporairement périmées, des écritures non transactionnelles ou quelques pertes de métriques peut simplifier fortement un système et améliorer ses performances. Ces arbitrages exigent un dialogue entre ingénieurs et responsables produit. Avec les agents de programmation, le risque s’accentue : les LLM ajoutent spontanément des vérifications, verrous et garanties non demandés, produisant une complexité inutile. La revue de code doit donc aussi supprimer ces exigences imaginaires.

Lire l’heure système directement (new DateTimeImmutable(), time()) rend les règles métier difficiles à tester et provoque des tests lents ou instables. PSR-20 standardise l’accès au temps via ClockInterface::now(). Symfony Clock fournit des horloges réelles et simulées (NativeClock, MockClock) : on peut figer ou avancer instantanément le temps, tester les échéances exactes et éviter les attentes réelles. L’article détaille aussi l’injection de dépendances, ClockSensitiveTrait, les différences entre horloges injectées et globales, ainsi que les pièges liés aux fuseaux horaires.