> ## Documentation Index
> Fetch the complete documentation index at: https://kawax.biz/llms.txt
> Use this file to discover all available pages before exploring further.

# Cycle de vie d'une requête

> Comment sont traitées les requêtes HTTP et les commandes de console dans une application Laravel.

## Introduction

Utiliser un outil dans le monde réel est plus rassurant lorsqu'on comprend son fonctionnement. Il en va de même pour le développement d'applications : comprendre le fonctionnement de vos outils vous rend plus productif et confiant.

Cette page présente à haut niveau le fonctionnement du framework Laravel. Une bonne compréhension du framework dans son ensemble démystifie la « magie » et renforce votre confiance pour construire vos applications.

## Cycle de vie d'une requête HTTP

### Vue d'ensemble

```mermaid theme={null}
flowchart TD
    A[Requête HTTP du navigateur] --> B[public/index.php]
    B --> C[Chargement de l'autoloader Composer]
    C --> D[bootstrap/app.php]
    D --> E[Création de l'instance de l'application<br>Conteneur de services]
    E --> F[Kernel HTTP]
    F --> G[Exécution des bootstrappers<br>Gestion des erreurs / Logs / Détection d'environnement]
    G --> H[Enregistrement et démarrage des service providers<br>register → boot]
    H --> I[Traversée de la pile de middlewares]
    I --> J[Routage]
    J --> K[Exécution du contrôleur / closure]
    K --> L[Génération de la réponse]
    L --> I
    I --> M[Envoi de la réponse au navigateur]
```

### Première étape

Le point d'entrée de toute requête vers une application Laravel est `public/index.php`. Toutes les requêtes y sont redirigées par la configuration du serveur web (Apache / Nginx). Ce fichier contient peu de code : c'est le point de départ pour charger le reste du framework.

`index.php` charge les définitions d'autoloader générées par Composer, puis récupère l'instance de l'application Laravel depuis `bootstrap/app.php`. La première chose que fait Laravel est de créer l'instance de l'application / [conteneur de services](/fr/service-container).

### Kernel HTTP

Ensuite, la requête reçue est envoyée au kernel HTTP (`Illuminate\Foundation\Http\Kernel`) via la méthode `handleRequest` de l'instance de l'application.

Le kernel HTTP définit un tableau de **bootstrappers** exécutés avant que la requête ne soit traitée. Ils s'occupent de :

* Configurer la gestion des erreurs
* Configurer les logs
* [Détecter l'environnement de l'application](/fr/installation)
* Effectuer d'autres tâches préalables au traitement

Le kernel HTTP est également responsable de faire passer la requête dans la pile de middlewares. Ceux-ci gèrent la lecture/écriture de la [session HTTP](/fr/session), le contrôle du mode maintenance, la [vérification du token CSRF](/fr/middleware), etc.

La signature de la méthode `handle` du kernel HTTP est simple : elle reçoit une `Request` et retourne une `Response`. Considérez le kernel comme une grande boîte noire représentant l'ensemble de votre application. Vous lui donnez une requête HTTP, elle vous rend une réponse HTTP.

### Service providers

L'une des opérations les plus importantes du kernel est de charger les [service providers](/fr/service-providers). Ils sont responsables de l'initialisation des composants du framework : base de données, files d'attente, validation, routage, etc.

Laravel itère sur la liste des providers, en crée une instance de chacun. Puis la méthode `register` de tous les providers est appelée. Ensuite, une fois tous enregistrés, la méthode `boot` de chacun est appelée. Ainsi, au moment où `boot` s'exécute, tous les bindings du conteneur sont enregistrés et disponibles.

<Info>
  Enregistrez vos service providers personnels ou tiers dans `bootstrap/providers.php`.
</Info>

### Routage

Une fois l'application démarrée et tous les service providers enregistrés, la `Request` est passée au routeur pour dispatch. Le routeur dispatche la requête vers une route ou un contrôleur, et exécute aussi les middlewares propres à la route.

Les middlewares offrent un moyen pratique de filtrer ou d'inspecter les requêtes HTTP entrantes. Par exemple, un middleware inclus vérifie si l'utilisateur est authentifié ; sinon, il redirige vers l'écran de connexion. S'il est authentifié, la requête est autorisée à poursuivre.

Une fois passée tous les middlewares assignés à la route correspondante, la route ou la méthode de contrôleur est exécutée et retourne une réponse.

### Retour de la réponse

Quand la route ou la méthode retourne une réponse, celle-ci remonte à travers les middlewares de la route, ce qui permet à ces derniers de la modifier ou de l'inspecter.

Enfin, une fois la réponse sortie de tous les middlewares, la méthode `handle` du kernel HTTP renvoie l'objet réponse à `handleRequest` de l'instance de l'application, qui appelle la méthode `send` de la réponse. `send` envoie le contenu au navigateur de l'utilisateur. Le cycle de vie d'une requête Laravel se termine ainsi.

## Cycle de vie d'une commande Console

### Vue d'ensemble

```mermaid theme={null}
flowchart TD
    A[Exécution d'une commande artisan] --> B[artisan]
    B --> C[Chargement de l'autoloader Composer]
    C --> D[bootstrap/app.php]
    D --> E[Création de l'instance de l'application<br>Conteneur de services]
    E --> F[Kernel Console<br>handleCommand]
    F --> G[Enregistrement et démarrage des service providers<br>register → boot]
    G --> H[Chargement des commandes<br>app/Console/Commands]
    H --> I[Exécution de la commande]
    I --> J[Retour du code de sortie]
```

### Point d'entrée artisan

Le point d'entrée des commandes console est le fichier `artisan` à la racine du projet. Comme pour HTTP, l'autoloader Composer est chargé et l'instance de l'application Laravel est créée.

Ensuite, le traitement est délégué au kernel Console via la méthode `handleCommand` de l'instance d'application.

### Kernel Console et exécution de la commande

Le kernel Console, comme le kernel HTTP, charge les service providers. Après leur enregistrement et démarrage, les commandes du répertoire `app/Console/Commands` sont chargées et la commande spécifiée est exécutée.

```shell theme={null}
php artisan make:controller UserController
```

Cette commande est traitée ainsi :

1. Le fichier `artisan` charge l'autoloader Composer
2. L'instance d'application est créée depuis `bootstrap/app.php`
3. Le kernel Console charge les service providers
4. La commande `make:controller` est recherchée et exécutée
5. Un code de sortie est retourné

## Se concentrer sur les service providers

Les service providers sont vraiment la clé de l'initialisation d'une application Laravel. Instance d'application créée, service providers enregistrés, requête transmise à l'application démarrée. C'est tout.

Comprendre en profondeur comment votre application se construit et démarre via les service providers a beaucoup de valeur. Vos service providers utilisateur sont stockés dans `app/Providers`.

<Info>
  Le `AppServiceProvider` par défaut est presque vide. C'est l'endroit idéal pour ajouter vos initialisations et bindings de conteneur. Dans les grandes applications, il est recommandé de créer plusieurs service providers spécialisés pour organiser l'initialisation par service.
</Info>

### Différence entre register et boot

Un service provider possède deux méthodes principales.

| Méthode    | Moment                                                   | Rôle                                                                       |
| ---------- | -------------------------------------------------------- | -------------------------------------------------------------------------- |
| `register` | Appelée pour tous les providers après leur instanciation | Enregistrer uniquement des bindings dans le conteneur                      |
| `boot`     | Appelée après que tous les `register` ont été exécutés   | Enregistrer view composers, listeners d'événements, autres initialisations |

<Warning>
  N'enregistrez pas d'écouteurs d'événements, de routes ou d'autres fonctionnalités dans `register`. Vous pourriez utiliser par erreur des services fournis par des providers qui ne sont pas encore chargés.
</Warning>

## Prochaines étapes

<Card title="Conteneur de services" icon="box" href="/fr/service-container">
  Comprenez l'injection de dépendances et le fonctionnement du conteneur de services.
</Card>

<Card title="Service providers" icon="plug" href="/fr/service-providers">
  Apprenez à initialiser votre application à l'aide des service providers.
</Card>


## Related topics

- [⚡Introduction à Livewire 4 — créer des UI réactives sans JavaScript](/fr/blog/livewire-introduction.md)
- [Événements de cycle de vie de session](/fr/packages/laravel-copilot-sdk/session-lifecycle-event.md)
- [Introduction à Eloquent](/fr/eloquent.md)
- [Génération d'URL](/fr/urls.md)
- [Service providers](/fr/service-providers.md)
