La structure d'un projet Laravel 13, dossier par dossier

Ouvrir un projet Laravel pour la première fois donne une impression trompeuse : une dizaine de dossiers à la racine, et à peine trois sous-dossiers dans app/. Ce n'est pas une structure minimaliste par accident — c'est le principe même de Laravel. Le framework n'impose presque aucune contrainte sur l'emplacement d'une classe, à condition que Composer puisse l'autocharger via PSR-4. Le reste de l'arborescence se remplit à l'usage, au fil des commandes make:*.

La racine du projet

Dix dossiers composent la base, chacun avec un rôle précis :

• app/ — le code métier de l'application.
• bootstrap/ — le fichier app.php qui démarre le framework, plus un dossier cache/ pour les fichiers générés (cache des routes, des services).
• config/ — tous les fichiers de configuration, à parcourir intégralement au moins une fois.
• database/ — migrations, factories et seeders.
• public/ — point d'entrée index.php de toutes les requêtes, plus les assets compilés.
• resources/ — vues et sources non compilées (CSS, JS).
• routes/ — les définitions de routes.
• storage/ — logs, sessions fichier, vues Blade compilées, caches framework.
• tests/ — tests Pest ou PHPUnit, exécutables via php artisan test.
• vendor/ — les dépendances Composer.

Le dossier routes/ mérite un détail : par défaut, seuls web.php (routes sous le middleware web, avec session et protection CSRF) et console.php existent. Ce dernier ne contient pas que des commandes Artisan — c'est aussi là que se définissent les tâches planifiées. Les fichiers api.php et channels.php ne sont pas absents par oubli : ils s'installent à la demande via php artisan install:api et install:broadcasting, seulement si l'application en a besoin.

Le dossier app/ : trois sous-dossiers, pas un de plus

Une installation neuve de Laravel 13 ne contient que Http, Models et Providers dans app/. Tout le reste — Console, Events, Jobs, Listeners, Mail, Notifications, Policies, Rules, Broadcasting, Exceptions — n'existe pas tant qu'on n'a pas exécuté la commande Artisan correspondante. make:job crée app/Jobs/, make:policy crée app/Policies/, et ainsi de suite. La documentation officielle formule bien l'intention derrière Http et Console : ce sont deux façons d'envoyer des commandes au cœur de l'application, pas des endroits où loger de la logique métier. Le protocole HTTP et la CLI sont des points d'entrée ; la substance reste ailleurs.

Concrètement, un php artisan list make suffit pour voir tout ce que Laravel sait générer — et donc tout ce qui peut apparaître dans app/ avec le temps :

app/
├── Http/          # contrôleurs, middlewares, form requests
├── Models/        # classes Eloquent
├── Providers/      # service providers (AppServiceProvider dès l'install)
└── Jobs/           # apparaît après `php artisan make:job SendInvoice`

Pourquoi cette arborescence progressive change la lecture d'un projet

Cette logique a une conséquence directe pour quiconque reprend un projet Laravel existant : la simple présence ou absence d'un dossier dans app/ raconte déjà quelque chose. Un app/Jobs/ bien rempli signale une application qui décharge du travail vers des queues ; un app/Policies/ vide de sens signale que l'autorisation passe encore par des vérifications ad hoc dans les contrôleurs plutôt que par des policies dédiées. Lire la structure avant de lire le code donne déjà une idée assez fidèle des choix d'architecture qui ont été faits — ou pas encore faits.

C'est aussi pour ça que la documentation insiste sur la liberté laissée au développeur : Laravel propose une organisation par défaut cohérente, mais rien n'empêche de la faire évoluer (regrouper par domaine plutôt que par type technique, par exemple) tant que l'autoloading Composer suit.