Créer un système d’authentification avec Laravel

Créer un système d’authentification avec Laravel, ce n’est pas seulement ajouter un formulaire de connexion et une page d’inscription. C’est construire la porte d’entrée de toute application sérieuse, celle qui protège les données, organise les permissions, rassure les utilisateurs et donne une structure propre à votre projet. Quand on débute avec Laravel, on découvre rapidement que le framework fait déjà une grande partie du travail. Et c’est précisément ce qui fait sa force : il vous permet de partir vite, sans sacrifier la qualité. Mais entre “ça marche” et “c’est propre, sécurisé, maintenable et évolutif”, il y a toute une vraie démarche qu’il vaut la peine de comprendre.

Dans cet article, on va prendre le temps de construire un système d’authentification solide, en partant des bases jusqu’aux bonnes pratiques avancées. On va voir comment installer une solution moderne, comment personnaliser le processus de connexion, comment protéger des routes, comment gérer les rôles, comment sécuriser les accès, et même comment penser l’authentification dans une logique plus professionnelle. Le but n’est pas seulement de suivre des commandes, mais de comprendre ce qui se passe réellement dans votre application. Parce qu’en développement, comprendre donne toujours plus de liberté que copier-coller.

Laravel propose plusieurs façons de mettre en place l’authentification. Selon la version et le type de projet, vous pouvez utiliser Laravel Breeze, Jetstream, Fortify, ou même construire le tout manuellement. Pour un projet classique, Laravel Breeze est souvent le meilleur point de départ. Il installe un système simple, moderne et lisible, basé sur Blade, Tailwind CSS et des routes prêtes à l’emploi. Jetstream, lui, apporte plus de fonctionnalités, comme la gestion de profil, la sécurité renforcée, les équipes ou l’authentification à deux facteurs. Quant à Fortify, il se concentre sur la logique d’authentification sans imposer l’interface. Le choix dépend donc de votre besoin réel, pas d’un effet de mode.

Avant d’entrer dans le code, prenons une minute pour poser les bases. Un système d’authentification répond à une question simple : “Qui est cet utilisateur ?”. L’autorisation, elle, répond à une autre question : “A-t-il le droit de faire cela ?”. Ces deux notions sont liées, mais elles ne sont pas identiques. Dans Laravel, l’authentification est souvent gérée par le système auth, tandis que l’autorisation passe par les gates, les policies, les rôles ou les permissions. Cette distinction est importante, car beaucoup de projets débutants mélangent les deux et finissent par créer des règles difficiles à maintenir.

Comprendre le fonctionnement de l’authentification dans Laravel

Laravel repose sur un système de guards et de providers. Cela peut sembler un peu abstrait au début, mais l’idée est simple. Le guard détermine comment l’utilisateur est authentifié, par exemple via une session web ou via un token API. Le provider, lui, définit où sont récupérées les données de l’utilisateur, généralement dans la base de données. Dans la plupart des projets web, vous utiliserez le guard web, qui repose sur les sessions et les cookies.

Le modèle utilisateur par défaut est généralement App\Models\User. Laravel s’appuie sur ce modèle pour charger l’utilisateur connecté, vérifier le mot de passe, gérer les sessions, et fournir les méthodes utiles comme auth()->user() ou Auth::check(). Si vous partez d’un projet neuf, vous disposez déjà d’une bonne base. Le vrai travail consiste ensuite à personnaliser le flux selon votre application.

Prenons un exemple simple. Si un utilisateur est connecté, vous pouvez récupérer ses informations ainsi :

use Illuminate\Support\Facades\Auth;

$user = Auth::user();

if ($user) {
    echo $user->name;
}

Ou encore :

if (auth()->check()) {
    return "Utilisateur connecté";
}

Ces petites lignes sont très utiles, mais elles ne représentent que la surface visible du système. Le cœur du sujet, c’est la manière dont Laravel gère l’identification sécurisée, la persistance de la session et la protection des pages sensibles.

Installer un système d’authentification avec Laravel Breeze

Pour beaucoup de projets modernes, Laravel Breeze est le point de départ idéal. Il est léger, clair, facile à personnaliser et suffisamment complet pour la majorité des sites web. Il fournit l’inscription, la connexion, la déconnexion, la réinitialisation du mot de passe, la vérification par email et une base d’interface propre.

Si votre projet Laravel est déjà créé, l’installation est simple. Voici le flux habituel :

composer require laravel/breeze --dev
php artisan breeze:install
php artisan migrate
npm install
npm run dev

Si vous utilisez Blade, Breeze vous donnera une structure simple et efficace. Si vous utilisez React, Vue ou API, d’autres options existent, mais l’idée reste la même : Laravel vous prépare les fondations, puis vous adaptez.

Après l’installation, les routes d’authentification sont généralement déjà présentes. Vous trouverez des fichiers comme routes/auth.php, des contrôleurs dédiés, des vues pour la connexion et l’inscription, ainsi que des composants pour les champs du formulaire. Ce qui est agréable avec Breeze, c’est la lisibilité. Rien n’est caché derrière une magie excessive. On peut tout lire, tout modifier, tout comprendre. Pour un développeur qui apprend ou qui veut garder le contrôle, c’est rassurant.

Les routes d’authentification

Les routes sont le point d’entrée de votre système. En général, Breeze ajoute des routes comme celles-ci :

use App\Http\Controllers\Auth\AuthenticatedSessionController;
use App\Http\Controllers\Auth\RegisteredUserController;
use Illuminate\Support\Facades\Route;

Route::get('/register', [RegisteredUserController::class, 'create'])
    ->middleware('guest')
    ->name('register');

Route::post('/register', [RegisteredUserController::class, 'store'])
    ->middleware('guest');

Route::get('/login', [AuthenticatedSessionController::class, 'create'])
    ->middleware('guest')
    ->name('login');

Route::post('/login', [AuthenticatedSessionController::class, 'store'])
    ->middleware('guest');

Route::post('/logout', [AuthenticatedSessionController::class, 'destroy'])
    ->middleware('auth')
    ->name('logout');

Ces routes illustrent une logique importante. Les utilisateurs non connectés, ou guest, peuvent accéder aux pages de connexion et d’inscription. En revanche, la déconnexion nécessite que la personne soit authentifiée. C’est simple, mais fondamental. Une application bien pensée doit toujours filtrer les accès dès le niveau des routes, et pas seulement au niveau des vues.

Dans un projet réel, vous pouvez regrouper des routes protégées avec un middleware auth :

Route::middleware(['auth'])->group(function () {
    Route::get('/dashboard', function () {
        return view('dashboard');
    });

    Route::get('/profile', function () {
        return view('profile');
    });
});

Cette logique vous évite de répéter les mêmes conditions partout. Laravel devient alors votre garde du corps silencieux, celui qui vérifie avant de laisser passer.

Créer un formulaire de connexion

Le formulaire de connexion est généralement simple, mais il doit être propre, accessible et sécurisé. Voici un exemple de vue Blade :

<form method="POST" action="{{ route('login') }}">
    @csrf

    <div>
        <label for="email">Adresse e-mail</label>
        <input id="email" type="email" name="email" value="{{ old('email') }}" required autofocus>
        @error('email')
            <p>{{ $message }}</p>
        @enderror
    </div>

    <div>
        <label for="password">Mot de passe</label>
        <input id="password" type="password" name="password" required>
        @error('password')
            <p>{{ $message }}</p>
        @enderror
    </div>

    <div>
        <label>
            <input type="checkbox" name="remember">
            Se souvenir de moi
        </label>
    </div>

    <button type="submit">Se connecter</button>
</form>

La partie la plus importante ici n’est pas l’apparence, mais la structure. Le champ email et le champ password sont envoyés à la route de connexion. Le token @csrf protège le formulaire contre les attaques CSRF. Les messages d’erreur permettent d’améliorer l’expérience utilisateur. Et le champ “Se souvenir de moi” active une session plus durable.

Du côté du contrôleur, Laravel simplifie énormément la connexion :

use Illuminate\Http\Request;
use Illuminate\Support\Facades\Auth;

public function store(Request $request)
{
    $credentials = $request->validate([
        'email' => ['required', 'email'],
        'password' => ['required'],
    ]);

    if (Auth::attempt($credentials, $request->boolean('remember'))) {
        $request->session()->regenerate();

        return redirect()->intended('/dashboard');
    }

    return back()->withErrors([
        'email' => 'Les identifiants fournis sont incorrects.',
    ])->onlyInput('email');
}

Cette méthode est très importante à comprendre. Auth::attempt() vérifie les identifiants fournis. Si l’utilisateur existe et que le mot de passe correspond, Laravel crée une session valide. Ensuite, session()->regenerate() protège contre la fixation de session. Enfin, redirect()->intended() redirige l’utilisateur vers la page qu’il voulait visiter avant d’être invité à se connecter. C’est un détail d’UX, mais un détail précieux.

Créer un système d’inscription

L’inscription suit une logique similaire. L’utilisateur remplit un formulaire, les données sont validées, un utilisateur est créé, puis la personne est connectée automatiquement.

Voici un exemple de formulaire :

<form method="POST" action="{{ route('register') }}">
    @csrf

    <div>
        <label for="name">Nom</label>
        <input id="name" type="text" name="name" value="{{ old('name') }}" required autofocus>
        @error('name')
            <p>{{ $message }}</p>
        @enderror
    </div>

    <div>
        <label for="email">Adresse e-mail</label>
        <input id="email" type="email" name="email" value="{{ old('email') }}" required>
        @error('email')
            <p>{{ $message }}</p>
        @enderror
    </div>

    <div>
        <label for="password">Mot de passe</label>
        <input id="password" type="password" name="password" required>
        @error('password')
            <p>{{ $message }}</p>
        @enderror
    </div>

    <div>
        <label for="password_confirmation">Confirmer le mot de passe</label>
        <input id="password_confirmation" type="password" name="password_confirmation" required>
    </div>

    <button type="submit">Créer mon compte</button>
</form>

Et voici le contrôleur correspondant :

use App\Models\User;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Auth;
use Illuminate\Support\Facades\Hash;

public function store(Request $request)
{
    $validated = $request->validate([
        'name' => ['required', 'string', 'max:255'],
        'email' => ['required', 'string', 'email', 'max:255', 'unique:users'],
        'password' => ['required', 'confirmed', 'min:8'],
    ]);

    $user = User::create([
        'name' => $validated['name'],
        'email' => $validated['email'],
        'password' => Hash::make($validated['password']),
    ]);

    Auth::login($user);

    return redirect('/dashboard');
}

Le point essentiel ici, c’est le hachage du mot de passe. On ne stocke jamais un mot de passe en clair dans la base de données. Jamais. Laravel fournit Hash::make() pour créer un hash sécurisé. Ainsi, même si la base de données est compromise, le mot de passe réel n’est pas directement lisible.

Cette règle peut paraître évidente, mais elle mérite d’être répétée. Une application sérieuse commence par un stockage sûr des mots de passe. C’est une question de respect envers les utilisateurs. Ils vous confient quelque chose de fragile, et votre travail consiste à le protéger avec soin.

La déconnexion propre et sécurisée

La déconnexion est souvent sous-estimée, alors qu’elle mérite autant d’attention que la connexion. Dans Laravel, elle ressemble à ceci :

use Illuminate\Http\Request;
use Illuminate\Support\Facades\Auth;

public function destroy(Request $request)
{
    Auth::logout();

    $request->session()->invalidate();
    $request->session()->regenerateToken();

    return redirect('/');
}

Pourquoi invalider la session et régénérer le token CSRF ? Parce qu’il ne suffit pas de déconnecter l’utilisateur au niveau logique. Il faut aussi vider proprement les informations de session et empêcher qu’un ancien token soit réutilisé. C’est ce genre de détail qui fait la différence entre une implémentation correcte et une implémentation vraiment propre.

Protéger les routes avec le middleware auth

Dès que vous avez des pages réservées, vous devez les protéger. Laravel met à votre disposition le middleware auth, qui bloque l’accès aux utilisateurs non connectés. C’est probablement l’un des mécanismes les plus importants d’un système d’authentification.

Route::middleware('auth')->group(function () {
    Route::get('/dashboard', function () {
        return view('dashboard');
    });

    Route::get('/account', function () {
        return view('account');
    });
});

Si un visiteur non connecté tente d’accéder à ces routes, Laravel le redirige automatiquement vers la page de connexion. Ce comportement est très pratique, surtout pour garder une bonne expérience utilisateur. Vous pouvez aussi définir une redirection personnalisée dans le middleware ou dans la logique d’authentification, selon votre version et votre architecture.

Il existe aussi d’autres middlewares utiles, comme guest, verified ou encore des middlewares personnalisés pour les rôles. Par exemple, si vous voulez exiger qu’un email soit vérifié avant l’accès à un tableau de bord, vous pouvez faire :

Route::middleware(['auth', 'verified'])->group(function () {
    Route::get('/dashboard', function () {
        return view('dashboard');
    });
});

Cette approche est élégante et lisible. Elle exprime clairement les conditions d’accès à une ressource.

Vérification de l’adresse e-mail

La vérification de l’email est une excellente pratique. Elle permet de s’assurer que l’adresse fournie appartient bien à la personne qui s’inscrit. Cela réduit les fausses inscriptions, améliore la qualité des comptes et facilite la communication plus tard.

Laravel supporte cela très bien. Il faut généralement que le modèle User implémente l’interface MustVerifyEmail :

use Illuminate\Contracts\Auth\MustVerifyEmail;

class User extends Authenticatable implements MustVerifyEmail
{
    // ...
}

Ensuite, le framework peut envoyer un lien de vérification et protéger les routes avec le middleware verified. L’utilisateur recevra un email contenant un lien unique. Lorsqu’il clique dessus, son compte est marqué comme vérifié. C’est simple pour lui, mais très utile pour vous.

Dans une vraie application, cette étape peut sembler secondaire au début, mais elle devient vite essentielle dès que l’on gère des comptes clients, des actions sensibles ou des communications importantes. On aime tous croire qu’un email est valide, mais dans la pratique, mieux vaut le confirmer.

Réinitialisation du mot de passe

La perte d’un mot de passe arrive à tout le monde. Une bonne application doit prévoir ce scénario sans stress et sans friction. Laravel propose un système de réinitialisation du mot de passe très pratique, avec demande de lien par email, formulaire de réinitialisation et mise à jour sécurisée du mot de passe.

Un utilisateur peut cliquer sur “Mot de passe oublié ?”, saisir son email, recevoir un lien temporaire, puis choisir un nouveau mot de passe. Derrière ce parcours simple se cache une logique bien pensée : token temporaire, vérification de validité, expiration, sécurisation de la mise à jour.

Voici un exemple de logique côté contrôleur :

use Illuminate\Http\Request;
use Illuminate\Support\Facades\Password;

public function sendResetLinkEmail(Request $request)
{
    $request->validate([
        'email' => ['required', 'email'],
    ]);

    $status = Password::sendResetLink(
        $request->only('email')
    );

    return $status === Password::RESET_LINK_SENT
        ? back()->with('status', __($status))
        : back()->withErrors(['email' => __($status)]);
}

Et pour mettre à jour le mot de passe :

use Illuminate\Http\Request;
use Illuminate\Support\Facades\Hash;
use Illuminate\Support\Facades\Password;
use Illuminate\Support\Str;

public function reset(Request $request)
{
    $request->validate([
        'token' => ['required'],
        'email' => ['required', 'email'],
        'password' => ['required', 'confirmed', 'min:8'],
    ]);

    $status = Password::reset(
        $request->only('email', 'password', 'password_confirmation', 'token'),
        function ($user, $password) {
            $user->forceFill([
                'password' => Hash::make($password),
                'remember_token' => Str::random(60),
            ])->save();
        }
    );

    return $status === Password::PASSWORD_RESET
        ? redirect()->route('login')->with('status', __($status))
        : back()->withErrors(['email' => [__($status)]]);
}

Ce mécanisme est très propre parce qu’il gère à la fois la sécurité et l’ergonomie. L’utilisateur se sent pris en charge, et vous évitez d’écrire vous-même une logique fragile autour des tokens temporaires.

Personnaliser l’authentification

Dans un vrai projet, vous ne garderez pas toujours les messages par défaut. Vous voudrez peut-être afficher un texte plus humain, plus cohérent avec votre marque, ou plus clair pour vos utilisateurs. Laravel vous laisse le faire facilement. Vous pouvez personnaliser les messages d’erreur, les redirections après connexion, les vues, les validations et même la logique d’authentification elle-même.

Par exemple, si vous voulez modifier le message de validation du mot de passe, vous pouvez le faire dans le contrôleur ou via les règles de validation :

$request->validate([
    'email' => ['required', 'email'],
    'password' => ['required'],
], [
    'email.required' => 'Veuillez saisir votre adresse e-mail.',
    'email.email' => 'Le format de l’adresse e-mail est invalide.',
    'password.required' => 'Le mot de passe est obligatoire.',
]);

Vous pouvez aussi changer le nom de la colonne utilisée pour le login. Par défaut, la plupart des applications utilisent l’email, mais certaines utilisent un identifiant, un numéro de téléphone, ou un username. Laravel permet de s’adapter à ce besoin. Il suffit souvent de modifier le champ dans le formulaire, dans la validation et dans la méthode Auth::attempt().

Par exemple, si vous voulez un login par username :

$credentials = $request->validate([
    'username' => ['required', 'string'],
    'password' => ['required'],
]);

if (Auth::attempt($credentials)) {
    $request->session()->regenerate();
    return redirect()->intended('/dashboard');
}

C’est ce genre de souplesse qui rend Laravel si agréable. Le framework ne vous enferme pas dans un schéma unique. Il vous donne une structure solide, puis vous laisse la liberté d’en faire quelque chose qui ressemble à votre produit.

Gérer les rôles et les permissions

L’authentification dit qui est connecté. L’autorisation dit ce qu’il a le droit de faire. Dans une petite application, vous pouvez parfois vous contenter de quelques conditions simples. Mais dès que votre projet grandit, vous aurez besoin de rôles, de permissions ou de policies.

Un exemple simple consiste à ajouter un champ role dans la table users :

Schema::table('users', function (Blueprint $table) {
    $table->string('role')->default('user');
});

Puis, dans vos contrôleurs ou vues, vous pouvez vérifier le rôle :

if (auth()->user()->role === 'admin') {
    // accès admin
}

Cette méthode fonctionne, mais elle devient vite limitée si le système grossit. Une solution plus robuste consiste à utiliser des policies ou un package de gestion des rôles et permissions. L’idée générale reste la même : ne mélangez pas tout dans un seul contrôleur. Les permissions doivent être centralisées, lisibles et faciles à faire évoluer.

Une policy simple peut ressembler à ceci :

public function update(User $user, Post $post)
{
    return $user->id === $post->user_id;
}

Ici, seul le propriétaire d’un post peut le modifier. Laravel permet ensuite d’utiliser cela dans vos contrôleurs ou vos vues avec des méthodes élégantes. Cette approche vous aide à garder une logique métier claire, ce qui est précieux lorsque l’application devient plus sérieuse.

Authentification avec Jetstream

Si votre application a besoin de plus qu’un simple login, Jetstream peut être un bon choix. Il apporte des fonctionnalités avancées comme la gestion de profil, la mise à jour du mot de passe, la suppression de compte, la vérification renforcée et l’authentification à deux facteurs. Il s’intègre bien avec Livewire ou Inertia, selon le style de projet que vous choisissez.

Jetstream est plus riche que Breeze, mais il est aussi un peu plus structuré. Pour certains projets, c’est exactement ce qu’il faut. Pour d’autres, cela peut sembler trop lourd. Le bon choix dépend du niveau de sophistication attendu. Si vous démarrez un produit SaaS, une plateforme collaborative ou un dashboard complexe, Jetstream peut vous faire gagner du temps. Si vous construisez un site plus léger, Breeze suffira largement.

L’essentiel n’est pas de choisir “le plus complet”, mais le plus adapté. Un système d’authentification doit servir votre projet, pas l’inverse. C’est une leçon que beaucoup de développeurs apprennent avec l’expérience.

Authentification API avec Sanctum

Aujourd’hui, beaucoup d’applications Laravel ne se limitent pas à des pages web classiques. Elles servent aussi des frontends séparés, des applications mobiles ou des clients API. Dans ce cas, l’authentification ne passe plus seulement par des sessions, mais souvent par des tokens. Laravel Sanctum est parfait pour ce besoin.

Sanctum permet de protéger des routes API et d’émettre des tokens d’accès personnels. C’est une solution plus légère que Passport dans de nombreux cas. Elle convient très bien aux applications modernes qui veulent une authentification simple pour SPA, mobile ou API.

Un exemple de création de token :

use Illuminate\Http\Request;
use Illuminate\Support\Facades\Hash;
use App\Models\User;

public function login(Request $request)
{
    $request->validate([
        'email' => ['required', 'email'],
        'password' => ['required'],
    ]);

    $user = User::where('email', $request->email)->first();

    if (! $user || ! Hash::check($request->password, $user->password)) {
        return response()->json([
            'message' => 'Identifiants invalides.'
        ], 401);
    }

    $token = $user->createToken('api-token')->plainTextToken;

    return response()->json([
        'token' => $token,
        'user' => $user,
    ]);
}

Ensuite, pour protéger une route API :

Route::middleware('auth:sanctum')->get('/user', function (Request $request) {
    return $request->user();
});

Cette approche est très pratique pour une application découplée. Vous pouvez ainsi garder Laravel comme backend robuste, tout en branchant un frontend moderne dessus. Là encore, la force de Laravel est sa capacité à s’adapter à plusieurs architectures sans perdre sa cohérence.

Sécurité : les bonnes habitudes à ne jamais négliger

Un système d’authentification n’est jamais seulement une question de fonctionnalités. C’est aussi une question de sécurité. Et dans ce domaine, les mauvaises habitudes coûtent cher. Il ne faut jamais stocker de mot de passe en clair, jamais oublier le @csrf, jamais exposer des données sensibles sans contrôle, jamais supposer qu’un utilisateur “ne fera pas ça”.

Laravel vous aide beaucoup, mais il reste important d’appliquer des réflexes simples. D’abord, hachez toujours les mots de passe avec Hash::make(). Ensuite, utilisez les protections CSRF sur les formulaires. Pensez à régénérer la session après connexion. Vérifiez les autorisations avant toute action sensible. Limitez les tentatives de connexion si nécessaire. N’exposez pas d’informations trop précises dans les messages d’erreur, afin d’éviter de faciliter la vie d’un attaquant.

Voici un exemple de limitation des tentatives de connexion avec le rate limiting intégré :

use Illuminate\Support\Facades\RateLimiter;

$key = strtolower($request->input('email')).'|'.$request->ip();

if (RateLimiter::tooManyAttempts($key, 5)) {
    return back()->withErrors([
        'email' => 'Trop de tentatives. Réessayez plus tard.',
    ]);
}

RateLimiter::hit($key, 60);

Ce type de protection peut sembler secondaire, mais il est très utile contre les attaques par force brute. Même un petit projet mérite une attention minimale sur ce point. La sécurité ne doit pas être un luxe réservé aux grandes plateformes.

Tests du système d’authentification

Tester l’authentification est une excellente habitude. Cela vous évite de casser un comportement essentiel lors d’une modification future. Les tests permettent aussi de documenter implicitement le fonctionnement attendu.

Voici un exemple de test de connexion :

use App\Models\User;
use Illuminate\Foundation\Testing\RefreshDatabase;
use Tests\TestCase;

class AuthenticationTest extends TestCase
{
    use RefreshDatabase;

    public function test_user_can_login_with_correct_credentials(): void
    {
        $user = User::factory()->create([
            'password' => bcrypt('password123'),
        ]);

        $response = $this->post('/login', [
            'email' => $user->email,
            'password' => 'password123',
        ]);

        $response->assertRedirect('/dashboard');
        $this->assertAuthenticated();
    }
}

Et un test pour s’assurer qu’un invité ne peut pas accéder à une route protégée :

public function test_guest_cannot_access_dashboard(): void
{
    $response = $this->get('/dashboard');

    $response->assertRedirect('/login');
}

Les tests ne sont pas une contrainte inutile. Ils sont une façon de dormir plus tranquillement quand votre application grandit. Le jour où vous modifiez une règle de connexion, ajoutez un champ ou refondez le design, vous serez heureux d’avoir ces filets de sécurité.

Structurer proprement son code

Plus votre système d’authentification devient riche, plus il est important d’éviter le chaos. Le code d’authentification ne doit pas se disperser dans dix fichiers sans logique claire. Il est préférable de garder une structure stable : les routes dans les fichiers dédiés, la logique métier dans les contrôleurs ou les actions, les validations dans des form requests si nécessaire, les vues dans un répertoire cohérent.

Par exemple, au lieu de garder trop de logique dans un contrôleur, vous pouvez utiliser une Form Request :

php artisan make:request LoginRequest

Puis, dans cette classe :

public function rules(): array
{
    return [
        'email' => ['required', 'email'],
        'password' => ['required'],
    ];
}

Et dans le contrôleur :

public function store(LoginRequest $request)
{
    $credentials = $request->validated();

    if (Auth::attempt($credentials, $request->boolean('remember'))) {
        $request->session()->regenerate();
        return redirect()->intended('/dashboard');
    }

    return back()->withErrors([
        'email' => 'Les identifiants sont incorrects.',
    ]);
}

Cette séparation rend le code plus lisible et plus simple à faire évoluer. Quand on travaille longtemps sur un projet, on mesure vite la valeur d’une bonne organisation. Ce n’est pas seulement du “clean code” pour faire joli. C’est une manière de garder la main.

Ajouter une touche humaine à l’expérience utilisateur

Un bon système d’authentification n’est pas seulement correct techniquement. Il doit aussi être rassurant, simple et agréable. Les utilisateurs veulent comprendre ce qui se passe. Ils veulent des messages clairs, des erreurs utiles et une interface qui ne les juge pas. Un mot de passe oublié n’est pas un drame. Une mauvaise saisie ne doit pas donner l’impression d’un échec brutal.

Vous pouvez améliorer l’expérience avec des messages plus naturels :

return back()->withErrors([
    'email' => 'Nous n’avons pas pu vous identifier avec ces informations.',
]);

Ou encore :

return redirect()->route('login')
    ->with('status', 'Votre mot de passe a bien été mis à jour. Vous pouvez vous connecter.');

Ces petits détails changent beaucoup de choses. Ils donnent une tonalité plus humaine à votre application. Et dans un monde où beaucoup d’outils paraissent froids ou mécaniques, cette attention fait vraiment la différence.

Exemple d’un flux complet d’authentification

Imaginons un scénario simple. Un utilisateur arrive sur votre site, clique sur “Créer un compte”, remplit le formulaire, reçoit un email de vérification, confirme son adresse, puis accède à son tableau de bord. Plus tard, il se déconnecte, oublie son mot de passe, utilise le lien de réinitialisation, et se reconnecte. Tout ce parcours doit être fluide, sécurisé et cohérent.

Le schéma logique ressemble à ceci :

// 1. Inscription
$user = User::create([
    'name' => $data['name'],
    'email' => $data['email'],
    'password' => Hash::make($data['password']),
]);

// 2. Connexion
Auth::login($user);

// 3. Accès protégé
Route::middleware('auth')->group(function () {
    Route::get('/dashboard', fn () => view('dashboard'));
});

// 4. Déconnexion
Auth::logout();

// 5. Réinitialisation du mot de passe
Password::reset(...);

Ce pseudo-flux cache beaucoup de travail réel, mais il montre bien la logique générale. Une fois que vous comprenez cette chaîne, vous êtes capable d’adapter l’authentification à presque n’importe quel projet Laravel.

Bonnes pratiques finales

Un système d’authentification bien construit repose sur quelques habitudes simples, mais non négociables. Gardez le code lisible. Validez toujours les entrées. Hachez les mots de passe. Protégez les formulaires. Régénérez les sessions. Séparez authentification et autorisation. Écrivez des tests. Pensez à l’expérience utilisateur. Et surtout, ne considérez jamais l’authentification comme un bloc secondaire qu’on ajoute à la fin du projet. Elle fait partie du cœur de l’application.

Laravel vous facilite énormément la tâche. C’est probablement l’un des frameworks les plus agréables pour mettre en place un système d’authentification propre sans réinventer la roue. Mais comme toujours, la qualité finale dépend de la manière dont vous assemblez les pièces. Breeze, Jetstream, Sanctum, middleware, policies, validation, tests : tout cela n’est pas une collection de gadgets, mais une boîte à outils cohérente. Une fois qu’on apprend à l’utiliser avec méthode, on gagne du temps, on évite des erreurs et on construit des applications plus solides.

Ce qui est vraiment beau avec Laravel, c’est qu’on peut commencer simplement puis grandir proprement. On peut lancer un projet avec quelques routes, quelques vues, un contrôleur et une base de données bien pensée. Puis, au fil du besoin, ajouter la vérification email, les rôles, l’API tokenisée, les tests et la sécurité renforcée. C’est une progression naturelle, sans rupture brutale. Et dans la vie d’un développeur, cette capacité à évoluer avec son projet vaut de l’or.

Si vous débutez, commencez par une authentification simple avec Breeze. Comprenez bien le flux. Regardez comment Laravel gère la session, les erreurs et la protection des pages. Puis ajoutez petit à petit ce dont votre application a besoin. Si vous êtes déjà plus avancé, essayez de structurer votre authentification comme un vrai module applicatif : claire, testée, maintenable, pensée pour durer. C’est souvent dans ces détails que se cache la qualité d’un produit.

Au final, créer un système d’authentification avec Laravel, ce n’est pas seulement “faire fonctionner un login”. C’est bâtir une expérience de confiance autour de votre application. C’est dire à vos utilisateurs : “Votre compte est entre de bonnes mains.” Et pour un développeur, il n’y a pas beaucoup de compliments plus beaux que celui-là.