Développer une application métier avec Symfony

Concevoir et développer une application métier avec Symfony : architecture, Doctrine, authentification, gestion des rôles et exposition d'une API REST.

Architecture : séparer les responsabilités

Une application métier Symfony repose sur une séparation claire entre les entités Doctrine (le modèle de données), les repositories (l'accès aux données), les services (la logique métier réutilisable) et les contrôleurs (l'orchestration). Sur SnowTricks (site communautaire de partage de figures de snowboard), cette séparation se traduit par cinq entités aux relations explicites — une figure appartient à une catégorie et à un utilisateur, possède plusieurs médias et plusieurs commentaires — et des services dédiés isolant les responsabilités transverses (authentification, traitement d'image, envoi d'email) du reste du code métier.

Authentification et sécurité

Symfony fournit un système de sécurité complet (authenticators, voters, hachage de mot de passe), mais certains besoins précis demandent du code sur mesure. Sur SnowTricks, la vérification d'email à l'inscription repose sur un service JWT développé à la main — génération et vérification de token avec signature HMAC-SHA256, contrôle d'expiration — pour respecter une contrainte de cahier des charges interdisant les bundles tiers hors génération de données. Les actions sensibles (créer, modifier, supprimer une ressource) sont protégées par rôle au niveau des contrôleurs, en complément de leur masquage côté interface.

Gestion de contenu utilisateur et upload de médias

Beaucoup d'applications métier doivent gérer un CRUD avec upload de fichiers hétérogènes. Sur SnowTricks, chaque figure combine une image à la une, une collection dynamique d'images secondaires et une collection dynamique de vidéos intégrées, via le CollectionType de Symfony (allow_add/allow_delete) couplé à un peu de JavaScript natif pour l'ajout/suppression de champs côté client.

Données de test et démonstration

Pour un développement et une démonstration fiables, les données de départ sont générées avec Faker (via Doctrine Fixtures Bundle) plutôt que saisies à la main — utile en particulier quand un cahier des charges impose un jeu de données initial minimum, comme c'était le cas sur SnowTricks (12 figures générées, réparties sur plusieurs catégories et utilisateurs fictifs).

Note

Cette étude de cas s'enrichira au fil des projets Symfony traités.