Commencer→
Retour au cours

backend / php-laravel

Premier projet Laravel : structure et configuration

Leçon 71 exercice

Explication

Ce que vous allez apprendre

  • Créer un nouveau projet Laravel et comprendre le rôle de chaque dossier principal
  • Distinguer routes/web.php (avec sessions) de routes/api.php (stateless) dès la structure du projet
  • Comprendre pourquoi .env ne doit jamais être commité, et ce que fait réellement config:cache
  • Découvrir le conteneur d'injection de dépendances (IoC) et le rôle des Service Providers
  • Utiliser les commandes artisan les plus utilisées au quotidien pour générer du code

Dans quel contexte ?

Une développeuse rejoint une équipe qui utilise Laravel pour la première fois. Elle doit rapidement comprendre où se trouvent les contrôleurs, comment la configuration change entre son environnement local et la production, et pourquoi certaines valeurs viennent d'un fichier .env jamais visible dans le dépôt Git. Cette leçon pose les fondations indispensables avant d'écrire la moindre ligne de logique métier dans Laravel.

D'abord, une structure de dossiers pensée pour grandir

Laravel impose une organisation stricte mais logique : les contrôleurs vivent dans app/Http/Controllers/, les modèles dans app/Models/, les vues dans resources/views/. Cette convention n'est pas arbitraire : elle permet à n'importe quel développeur Laravel de retrouver ses repères instantanément sur n'importe quel projet, même qu'il n'a jamais vu.

php artisan serve démarre un serveur de développement local, mais en production, un vrai serveur web (Nginx, Apache) pointera directement vers le dossier public/, seul dossier exposé publiquement — tout le reste du code applicatif reste inaccessible depuis l'extérieur.

Ensuite, deux mondes de routes bien distincts

routes/web.php gère les routes destinées à un navigateur classique : sessions, cookies, protection CSRF activée par défaut. routes/api.php, à l'inverse, est pensé pour des clients stateless (applications mobiles, SPA) : pas de session par défaut, un middleware de limitation de débit (throttle) appliqué automatiquement.

FichierMiddleware par défautCas d'usage typique
routes/web.phpSessions, CSRFPages HTML classiques
routes/api.phpthrottle:api, sans sessionAPI REST, SPA, app mobile

Prérequis

Il est utile d'avoir déjà manipulé Composer (leçon précédente) : Laravel s'installe via composer create-project, et son autoloading PSR-4 fonctionne exactement comme vu précédemment.

Il reste une question de sécurité essentielle : le fichier .env

Toute information sensible ou spécifique à un environnement (mot de passe de base de données, clés d'API) vit dans .env, qui ne doit jamais être commité dans Git. C'est ce fichier qui change entre le poste local d'un développeur, un serveur de staging et la production.

Piège fréquent

php artisan config:cache fige la configuration dans un seul fichier compilé pour la performance — mais après ça, Laravel ignore purement et simplement toute modification du fichier .env tant que le cache n'est pas vidé (config:clear). Ne JAMAIS lancer config:cache en développement local : ça donne l'impression que .env "ne marche plus".

Maintenant, comprendre ce qui rend Laravel si flexible

Au cœur de Laravel se trouve un conteneur d'injection de dépendances (IoC container). Quand du code demande une instance de PaiementService, Laravel peut décider de fournir une implémentation concrète différente (StripePaiementService) sans que le code appelant n'ait besoin de le savoir. Cette liaison se configure dans les Service Providers, comme AppServiceProvider.

Astuce

php artisan make:model Produit -mfs génère en une seule commande le modèle, sa migration, et sa factory — un gain de temps considérable par rapport à quatre commandes make: séparées. Prends l'habitude de combiner les flags dès le début d'un projet.

Maintenant que la structure d'un projet Laravel n'a plus de secret, la prochaine étape naturelle est d'apprendre à définir précisément quelles URLs répondent à quoi : direction la leçon sur le routing.

Commandes & code

Premier projet Laravel : structure et configuration

bash
# Installation d'un nouveau projet Laravel
composer create-project laravel/laravel boutique
cd boutique
php artisan serve                 # serveur de dev sur http://127.0.0.1:8000

# Structure des dossiers essentiels
# app/Http/Controllers/  -> contrôleurs
# app/Models/             -> modèles Eloquent
# routes/web.php          -> routes pour le navigateur (avec sessions)
# routes/api.php          -> routes API (stateless, sans sessions par défaut)
# database/migrations/    -> schéma versionné de la base
# database/seeders/       -> données de test/initiales
# resources/views/        -> templates Blade
# config/                 -> configuration par domaine (database.php, app.php, ...)
# .env                    -> variables d'environnement (jamais commité)
dotenv
# .env : configuration spécifique à l'environnement (dev, staging, prod)
APP_NAME=Boutique
APP_ENV=local
APP_KEY=base64:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=
APP_DEBUG=true
APP_URL=http://localhost

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=boutique
DB_USERNAME=root
DB_PASSWORD=secret

CACHE_STORE=redis
QUEUE_CONNECTION=redis
SESSION_DRIVER=redis
php
<?php
// config/app.php : lu au runtime, peut référencer des variables .env via env()
return [
    'name' => env('APP_NAME', 'Laravel'),
    'env' => env('APP_ENV', 'production'),
    'debug' => (bool) env('APP_DEBUG', false),
    'timezone' => 'Europe/Paris',
    'locale' => 'fr',
    'providers' => [
        // Service providers : point d'enregistrement des services de l'app
        App\Providers\AppServiceProvider::class,
    ],
];

// app/Providers/AppServiceProvider.php : binder des services au conteneur IoC
namespace App\Providers;

use Illuminate\Support\ServiceProvider;
use App\Services\PaiementService;
use App\Services\StripePaiementService;

class AppServiceProvider extends ServiceProvider {
    public function register(): void {
        // Injection de dépendances : quand on demande PaiementService, on reçoit StripePaiementService
        $this->app->bind(PaiementService::class, StripePaiementService::class);
    }

    public function boot(): void {
        // Code exécuté après que tous les providers sont enregistrés
    }
}
bash
# Commandes artisan indispensables au quotidien
php artisan make:controller ProduitController
php artisan make:model Produit -mfs   # -m migration -f factory -s seeder, en une commande
php artisan route:list                # liste toutes les routes enregistrées
php artisan config:cache              # cache la config (prod uniquement, sinon .env ignoré en dev !)
php artisan tinker                    # REPL interactif avec accès à l'app

Résumé

  • Le conteneur d'injection de dépendances (IoC) est le cœur de Laravel : bind() associe une interface à une implémentation.
  • .env ne doit jamais être commité ; config:cache fige sa lecture donc à réserver à la prod.
  • php artisan make:model X -mfs génère modèle, migration, factory et seeder d'un coup.
  • routes/web.php (avec sessions/CSRF) et routes/api.php (stateless) ont des middlewares par défaut différents.

Exercices pratiques

1 disponible
1

Mission : debloquer un .env qui semble ignore

Objectif : Diagnostiquer pourquoi un changement dans .env n'a aucun effet en developpement local, et corriger la configuration du projet.

Contexte

Une developpeuse rejoint l'equipe et modifie DB_DATABASE dans son fichier .env local pour pointer vers sa propre base de test. Rien ne change : l'application continue de se connecter a l'ancienne base. Un collegue lui fait remarquer qu'un ancien script d'installation avait lance php artisan config:cache sur cette machine, "pour aller plus vite" selon son auteur, sans jamais preciser dans quel contexte cette commande est censee etre utilisee.

Résoudre l’exercice →