Niv. 2 — Intermédiaire : catalogue avec relations & auth

Objectif : introduire les relations Doctrine, la sécurité et EasyAdmin. On enrichit l’annuaire : chaque prestataire propose des services, et l’admin est protégé.

📋 Cahier des charges

Contexte — Le studio veut, en plus des prestataires, gérer leurs services (nom, durée, prix), et protéger le back-office par un login.

Périmètre inclus

• Entité Service (name, durationMin, priceCents) reliée à Provider (OneToMany / ManyToOne).
• Entité User + login form ; le back-office /admin réservé à ROLE_ADMIN.
• Un voter : un prestataire ne peut éditer que ses services (préparation à la logique fine).
• Un back-office EasyAdmin (prestataires + services) avec le prix en euros.
• Éviter le N+1 sur la liste (services par prestataire).

Périmètre exclu — API/JWT (Niv. 3), temps réel (Niv. 4).

Livrables — un back-office EasyAdmin sécurisé, avec relations.

Critères de réussite

• Un Service appartient à un Provider (FK, helpers de collection).
• /admin redirige vers login si non connecté ; accessible en admin.
• Le prix s’affiche/s’édite en euros (stocké en centimes).
• La liste des prestataires n’a pas de N+1 (vérifié au profiler).

🗺️ Endroits à visiter

🧭 Étapes suggérées

1. make:entity Service + la relation vers Provider (make:entity ajoute la relation interactivement).
2. make:user + make:security:form-login ; access_control: ^/admin ROLE_ADMIN.
3. make:admin:dashboard + make:admin:crud pour Provider et Service ; MoneyField::setStoredAsCents().
4. make:voter ServiceVoter (EDIT réservé au propriétaire ou admin).
5. Optimiser la liste : requête avec join + addSelect (ou un compteur agrégé).
6. Créer un admin en base (une commande app:create-admin, 4.6).

🎁 Bonus : ajoutez une recherche Meilisearch sur les services (6.7).

Projet suivant : Niv. 3 — Avancé (API + Next.js).