Événements et Listeners Laravel en 2026 : Architecture Event-Driven et Questions d'Entretien

Les événements et listeners Laravel implémentent le pattern Observer, découplant les composants en permettant à différentes parties d'une application de réagir à des actions sans dépendances directes. Lorsqu'un utilisateur passe une commande, l'événement OrderShipped se déclenche, et des listeners séparés gèrent les notifications, l'analytique et les mises à jour d'inventaire de manière indépendante.

Fonctionnement de la Découverte d'Événements dans Laravel 12

Depuis Laravel 11, le EventServiceProvider n'existe plus. Laravel scanne le répertoire Listeners et utilise la réflexion pour déterminer quels événements chaque listener gère, basé sur le type hint de la signature de la méthode handle.

<?php

namespace App\Listeners;

use App\Events\OrderShipped;

class SendOrderConfirmation
{
    public function handle(OrderShipped $event): void
    {
        // Envoyer l'email de confirmation à $event->order->user
    }
}

Le listener ci-dessus est automatiquement enregistré pour les événements OrderShipped. Aucune liaison manuelle dans un service provider. Cette approche réduit le code répétitif et maintient les relations événement-listener proches du code qui les implémente.

Pour vérifier les listeners enregistrés, exécuter php artisan event:list. En production, mettre en cache le manifeste avec php artisan event:cache pour éviter le scan du répertoire à chaque requête.

Création d'Événements et Listeners avec Artisan

Laravel fournit des commandes Artisan pour générer les événements et listeners :

# Générer une classe d'événement
php artisan make:event OrderShipped

# Générer un listener lié à un événement
php artisan make:listener SendShipmentNotification --event=OrderShipped

La classe d'événement générée utilise trois traits : Dispatchable pour la méthode statique dispatch(), InteractsWithSockets pour le broadcasting, et SerializesModels pour sérialiser les modèles Eloquent quand les listeners sont mis en file d'attente.

<?php

namespace App\Events;

use App\Models\Order;
use Illuminate\Foundation\Events\Dispatchable;
use Illuminate\Broadcasting\InteractsWithSockets;
use Illuminate\Queue\SerializesModels;

class OrderShipped
{
    use Dispatchable, InteractsWithSockets, SerializesModels;

    public function __construct(
        public Order $order,
    ) {}
}

La classe d'événement est un conteneur de données. Elle contient le modèle Order et rien d'autre. La logique métier appartient aux listeners, pas aux événements.

Dispatch d'Événements depuis les Controllers et Services

Dispatcher les événements en utilisant la méthode statique dispatch() sur la classe d'événement :

<?php

namespace App\Http\Controllers;

use App\Events\OrderShipped;
use App\Models\Order;
use Illuminate\Http\Request;

class OrderController extends Controller
{
    public function ship(Request $request, Order $order)
    {
        // Logique d'expédition ici...
        
        OrderShipped::dispatch($order);
        
        return redirect()->route('orders.index');
    }
}

Pour un dispatch conditionnel, utiliser dispatchIf() ou dispatchUnless() :

// Dispatcher seulement si la commande a un numéro de suivi
OrderShipped::dispatchIf($order->tracking_number !== null, $order);

Listeners Asynchrones pour les Opérations Lentes

Les listeners qui envoient des emails, appellent des APIs externes ou effectuent des calculs lourds doivent s'exécuter de manière asynchrone. Implémenter ShouldQueue pour pousser le listener dans la file d'attente :

<?php

namespace App\Listeners;

use App\Events\OrderShipped;
use Illuminate\Contracts\Queue\ShouldQueue;

class SendShipmentNotification implements ShouldQueue
{
    public $queue = 'notifications';
    public $delay = 60; // Attendre 60 secondes avant le traitement

    public function handle(OrderShipped $event): void
    {
        // Envoyer la notification à $event->order->user
    }
}

Personnaliser la connexion et le nom de la file avec les propriétés $connection et $queue, ou utiliser des méthodes dynamiques :

public function viaConnection(): string
{
    return 'redis';
}

public function viaQueue(): string
{
    return $this->event->order->priority === 'high' 
        ? 'high-priority' 
        : 'default';
}

Mise en File Conditionnelle avec shouldQueue

Parfois un listener ne doit être mis en file que selon les données de l'événement :

public function shouldQueue(OrderShipped $event): bool
{
    // Mettre en file seulement pour les commandes de plus de 100€
    return $event->order->total >= 10000;
}

Transactions de Base de Données et Timing des Événements

Les listeners mis en file dispatchés à l'intérieur d'une transaction peuvent être traités avant le commit de la transaction, causant des erreurs de données manquantes. Deux solutions existent :

1. Configuration globale dans config/queue.php :

'connections' => [
    'redis' => [
        'after_commit' => true,
    ],
],

2. Par listener avec ShouldQueueAfterCommit :

use Illuminate\Contracts\Queue\ShouldQueueAfterCommit;

class UpdateInventory implements ShouldQueueAfterCommit
{
    public function handle(OrderShipped $event): void
    {
        // Sûr de requêter la commande, transaction commitée
    }
}

Pour les événements eux-mêmes, implémenter ShouldDispatchAfterCommit sur la classe d'événement :

use Illuminate\Contracts\Events\ShouldDispatchAfterCommit;

class OrderShipped implements ShouldDispatchAfterCommit
{
    // L'événement ne se dispatch qu'après le commit de la transaction
}

Listeners Uniques pour Éviter les Doublons

L'interface ShouldBeUnique empêche les listeners dupliqués d'être mis en file pendant qu'un autre est en cours de traitement :

use Illuminate\Contracts\Queue\ShouldBeUnique;
use Illuminate\Contracts\Queue\ShouldQueue;

class ProcessLicenseKey implements ShouldQueue, ShouldBeUnique
{
    public $uniqueFor = 3600; // Le verrou expire après 1 heure

    public function uniqueId(LicensePurchased $event): string
    {
        return 'license:' . $event->license->id;
    }

    public function handle(LicensePurchased $event): void
    {
        // Générer et assigner la clé de licence
    }
}

Si le même ID de licence déclenche plusieurs événements rapidement, seul le premier listener traite. Les tentatives suivantes trouvent le verrou détenu et sautent la mise en file.

Event Subscribers pour les Événements Liés

Quand plusieurs événements liés partagent une logique de traitement commune, les event subscribers regroupent les handlers dans une seule classe :

<?php

namespace App\Listeners;

use Illuminate\Auth\Events\Login;
use Illuminate\Auth\Events\Logout;
use Illuminate\Events\Dispatcher;

class UserActivitySubscriber
{
    public function handleLogin(Login $event): void
    {
        // Logger la connexion réussie, mettre à jour last_login
    }

    public function handleLogout(Logout $event): void
    {
        // Logger la déconnexion, nettoyer les données de session
    }

    public function subscribe(Dispatcher $events): array
    {
        return [
            Login::class => 'handleLogin',
            Logout::class => 'handleLogout',
        ];
    }
}

Les subscribers suivent les règles de découverte automatique. Si les méthodes handler sont dans la classe subscriber avec des paramètres correctement typés, Laravel les enregistre automatiquement.

Écouter Plusieurs Événements avec les Union Types

Un seul listener peut répondre à plusieurs types d'événements en utilisant les union types PHP 8 :

public function handle(OrderShipped|OrderCancelled $event): void
{
    match (true) {
        $event instanceof OrderShipped => $this->notifyShipped($event),
        $event instanceof OrderCancelled => $this->notifyCancelled($event),
    };
}

Ce pattern fonctionne bien pour les notifications qui suivent une logique similaire à travers différents types d'événements.

Différer les Événements avec Event::defer

Laravel 12 a introduit Event::defer() pour retarder le dispatch d'événements jusqu'à la fin d'un bloc de code. Cela garantit que les listeners ont accès à tous les enregistrements liés :

use Illuminate\Support\Facades\Event;

Event::defer(function () {
    $user = User::create(['name' => 'John']);
    $user->posts()->create(['title' => 'Welcome']);
});
// Les événements pour User et Post se dispatchent ici

Si une exception survient à l'intérieur de la closure, les événements différés ne se dispatchent jamais.

Questions d'Entretien sur les Événements et Listeners Laravel

Les entretiens techniques testent fréquemment la compréhension de l'architecture event-driven. Voici des questions qui distinguent les développeurs Laravel expérimentés :

Q : Comment Laravel 12 enregistre-t-il les event listeners sans EventServiceProvider ?

Laravel scanne app/Listeners en utilisant la réflexion. Il lit le type hint sur les méthodes handle() ou __invoke() pour déterminer à quel événement chaque listener répond. Mettre en cache le manifeste en production avec php artisan event:cache.

Q : Quand un listener doit-il implémenter ShouldQueue ?

Chaque fois que l'opération prend plus de quelques millisecondes : envoi d'emails, appels d'APIs externes, génération de rapports, ou traitement de fichiers. Les listeners synchrones bloquent la réponse HTTP.

Q : Quel problème ShouldQueueAfterCommit résout-il ?

Les listeners mis en file peuvent être traités avant le commit de la transaction de base de données. Si le listener requête un enregistrement venant d'être créé, il échoue car les données ne sont pas encore commitées. ShouldQueueAfterCommit retarde le dispatch jusqu'à la fin de la transaction.

Q : Comment éviter le traitement en double pour le même événement ?

Implémenter ShouldBeUnique. Définir uniqueId() pour retourner une clé de cache basée sur les données de l'événement. Le listener acquiert un verrou atomique, et les dispatchs dupliqués sautent si le verrou est détenu.

Q : Quelle est la différence entre un event listener et un event subscriber ?

Un listener gère un type d'événement. Un subscriber est une classe qui enregistre des handlers pour plusieurs événements liés au même endroit, utile pour regrouper les événements d'authentification ou la journalisation d'audit.

Ce que les Événements Laravel Signifient pour les Applications Scalables

• Les événements découplent les composants, permettant aux fonctionnalités comme les notifications et l'analytique d'évoluer indépendamment
• Les listeners mis en file déchargent les opérations lentes, gardant les réponses HTTP rapides
• ShouldQueueAfterCommit prévient les race conditions entre les workers de file et les transactions de base de données
• La découverte automatique dans Laravel 12 supprime la surcharge de configuration, gardant la logique des listeners proche de l'implémentation
• Les event subscribers consolident le traitement d'événements liés, réduisant l'éparpillement de fichiers pour les patterns courants comme le suivi d'activité utilisateur
• Le module /technologies/laravel/interview-questions/events-listeners sur SharpSkill couvre ces patterns avec des questions interactives