Développeur Symfony Freelance – Expert Backend PHP

Ces outils qui ont résolu un problème… et en ont créé un autre

API Platform – quand le framework dans le framework prend le dessus

API Platform a été une vraie révolution à son époque. Exposer une API REST documentée en quelques annotations, avec pagination, filtres et validation intégrés – c’était impressionnant. Beaucoup de projets Symfony ont adopté l’outil sans hésiter.

Sauf qu’API Platform n’est pas un simple bundle. C’est un framework dans le framework, avec son propre vocabulaire, ses propres abstractions, ses State Providers et Processors qui finissent par piloter l’organisation du code. Dans une architecture hexagonale, ça crée une tension réelle : les ressources API commencent à influencer le modèle de domaine, alors que c’est censé être l’inverse. Et quand un besoin sort des sentiers battus – permissions complexes, réponses non standard, logique métier riche – on passe plus de temps à contourner l’outil qu’à coder le domaine.

En 2026, un LLM génère une spec OpenAPI propre et maintenue à jour à partir de controllers Symfony classiques. L’argument « documentation automatique » a perdu beaucoup de son poids. Je détaille mon approche de conception d’APIs REST orientées use cases sur une page dédiée.

Sonata Admin – le CRUD qui ne reste jamais simple

Sonata suit la même logique, avec une ironie supplémentaire. Il était là pour éviter d’écrire du CRUD. Sauf qu’un CRUD d’administration ne reste jamais simple longtemps – un champ s’ajoute, une règle métier arrive, une interface spécifique est demandée. Et là commence la vraie douleur : faire rentrer un besoin qui a évolué dans les contraintes d’un outil qui n’a pas prévu ce cas.

Sans parler des migrations. Sonata est l’une des raisons les plus fréquentes pour lesquelles des projets restent bloqués sur Symfony 3 ou 4 – sa cascade de dépendances rend toute montée de version particulièrement pénible. Pour un outil utilisé à 80% comme un simple générateur de formulaires.

FOSUserBundle, FOSRestBundle, JMSSerializer – l’inertie des dépendances

La liste est longue d’outils qui répondaient à un vrai manque à une époque où Symfony ne couvrait pas ces besoins nativement. La gestion des utilisateurs, l’exposition REST, la sérialisation avancée – autant de problèmes que Symfony a depuis absorbés dans son cœur.

Les projets, eux, gardent souvent la dépendance par inertie. Pas par mauvais choix – simplement parce qu’un projet qui tourne n’a pas toujours le temps ni le budget pour se désendetter au fil des releases.

Ce que ça dit du cycle de vie d’un projet Symfony

Ce n’est pas une question de mauvais choix initiaux. C’est simplement ce qui arrive quand un framework mature absorbe progressivement son écosystème. Les outils tiers qui comblaient les manques d’hier deviennent les dettes techniques d’aujourd’hui. Identifier lesquels freinent vraiment l’évolution du projet – et dans quel ordre s’en défaire – c’est souvent là que se joue la différence entre un projet qui avance et un projet qui subit. Je décris mes stratégies de refactoring et modernisation legacy en détail.