Comprendre la structure d'un projet Symfony est l'étape qui sépare le développeur qui "bidouille" de celui qui maîtrise son environnement. Si l'organisation peut sembler dense au premier abord, elle répond à une logique implacable de séparation des responsabilités.
Comme toute architecture robuste, qu'elle soit logicielle ou immobilière, chaque espace a une fonction précise. Visitons ensemble cet édifice.
/bin : Le centre opérationnel
C'est ici que résident les exécutables de votre application. Le fichier le plus important est sans conteste console.
Considérez-le comme votre chef de chantier ou votre majordome de confiance. Interagir avec Symfony se fait majoritairement par son biais. Il ne se contente pas d'exécuter vos ordres ("Vider le cache", "Créer un controller"), il orchestre également les tâches de fond.
En version 8.5+, l'outil gagne en autonomie avec des capacités d'auto-diagnostic et de gestion de versions améliorées, rendant l'expérience développeur plus fluide que jamais.
/config : La salle des machines
Souvent redouté, ce répertoire est pourtant le plus rationnel. C'est ici que vous définissez le comportement de votre application, indépendamment de son code.
routes.yaml: Le plan de circulation.services.yaml: L'injection de dépendances et le câblage interne.packages/: La configuration spécifique à chaque librairie tierce (Doctrine, Security, etc.).
Le format YAML y est roi. Sa syntaxe épurée le rend plus humainement lisible que le XML ou le JSON, mais attention : il ne pardonne aucune approximation d'indentation. Une espace manquante, et c'est tout le système qui s'arrête.
/public : La vitrine sécurisée
C'est le seul dossier exposé au monde extérieur via le serveur web. Il contient :
index.php: Le contrôleur frontal (Front Controller). Il intercepte 100% des requêtes HTTP, initialise le noyau Symfony, et renvoie la réponse. C'est le gardien de l'entrée.- Les assets : Images, feuilles de styles compilées, scripts JavaScript publics.
Tout ce qui n'est pas dans ce dossier est invisible depuis un navigateur, garantissant une sécurité structurelle par défaut.
/src : L'atelier de code
C'est votre espace de travail principal, où réside la logique métier spécifique à votre projet. L'organisation standard suit le pattern MVC revisité :
Controller
La réception de l'hôtel. Le contrôleur accueille la requête, comprend l'intention de l'utilisateur, appelle les services compétents, et retourne une réponse (souvent une vue). Il doit rester "maigre" : pas de logique métier complexe ici.
Entity
La représentation objet de vos données. Si vous utilisez Doctrine, chaque classe ici correspond généralement à une table en base de données. C'est le cœur de votre modèle de données.
Repository
Si l'Entité est la donnée, le Repository est le bibliothécaire. C'est lui qui sait comment formuler les requêtes SQL (via DQL ou QueryBuilder) pour retrouver les objets que vous cherchez.
Service
Les "travailleurs" spécialisés. Envoi d'email, calcul de factures, transformation de données... Dès qu'une logique est complexe ou réutilisable, elle doit être encapsulée dans un Service. C'est le garant d'un code découplé et testable.
Subscriber / Listener
Les espions et observateurs. Ils permettent d'agir sur des événements système (ex: "utilisateur connecté", "commande payée") sans modifier le code qui déclenche ces événements. Puissant, mais à utiliser avec discernement pour ne pas rendre le flux d'exécution opaque.
/templates : La couche de présentation
Ici règne Twig, le moteur de templating de Symfony. Plus qu'un simple générateur de HTML, Twig apporte sécurité (échappement automatique des variables) et modularité (hértiage de templates). Il sépare proprement la logique d'affichage du code PHP.
/tests : L'assurance qualité
Un projet sérieux ne vit pas sans tests. Ce dossier miroir de /src contient :
- Tests Unitaires : Vérifient le bon fonctionnement d'une classe isolée (souvent vos Services).
- Tests Fonctionnels : Simulent des requêtes HTTP pour vérifier que l'application répond correctement dans son ensemble.
/var : La zone technique
C'est la mémoire vive et l'archivage de Symfony.
cache/: Pour la performance, Symfony compile sa configuration. N'y touchez jamais, mais n'hésitez pas à le vider (php bin/console cache:clear) en cas de comportement étrange.log/: La boîte noire. En cas de crash, c'est le premier endroit où regarder.
/vendor : La dépendance externe
Géré exclusivement par Composer, ce dossier contient le code des autres (Symfony lui-même, Doctrine, Monolog...). Vous ne devez jamais modifier un fichier dans ce dossier, car vos changements seraient écrasés à la prochaine mise à jour.
Fichiers racines essentiels
composer.json: Le plan d'architecte. Il déclare quelles bibliothèques sont nécessaires.composer.lock: L'état des lieux certifié. Il fige les versions exactes pour garantir que la production est identique au développement..env: Les variables d'environnement. C'est ici que l'on configure ce qui change d'une machine à l'autre (identifiants de base de données, clés API...), souvent surchargé par un.env.localnon versionné pour les secrets.
Maîtriser cette anatomie, c'est arrêter de subir le framework pour commencer à l'exploiter pleinement. Chaque fichier a sa place, chaque dossier sa raison d'être.