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

# Laravel Cloud Hibernation (mise en veille automatique)

> Fonctionnement de la mise en veille automatique de Laravel Cloud : activation, limitations et prévention des réveils inutiles via le Path Blocking.

## Qu'est-ce que Hibernation ?

**Hibernation (mise en veille automatique)** de Laravel Cloud est une ancienne fonctionnalité qui fait passer un environnement en veille lorsqu'aucune requête HTTP n'est reçue pendant une certaine durée.
Sur le nouveau compute Flex, elle est remplacée par **Scale to Zero**, plus rapide.

L'Hibernation Legacy Flex permet d'interrompre la facturation du compute pendant la veille, mais il faut généralement 5 à 20 secondes pour reprendre après réception d'une requête HTTP. Avec le nouveau Scale to Zero, le démarrage descend à **moins de 500 ms**, et même en veille, l'environnement redémarre automatiquement pour les tâches planifiées et le traitement des queues.

<Warning>
  Si vous démarrez tout juste sur Laravel Cloud, il est plus sûr de raisonner en termes de **Scale to Zero** plutôt que d'Hibernation. Pour une vue d'ensemble incluant Managed Queues et les nouveaux plans tarifaires, consultez [Laravel Cloud — le PaaS dédié à Laravel](/fr/blog/laravel-cloud).
</Warning>

```mermaid theme={null}
sequenceDiagram
    participant User as Utilisateur
    participant Cloud as Laravel Cloud
    participant App as Application

    User->>Cloud: Aucune requête (timeout)
    Cloud->>App: Mise en veille<br>(facturation stoppée)
    User->>Cloud: Requête HTTP
    Cloud->>App: Reprise en 5 à 20 s
    App-->>User: Réponse
```

## Ce qui change avec Scale to Zero

Avec Scale to Zero sur le nouveau compute Flex, beaucoup des limitations de l'ancienne Hibernation sont levées.

| Élément                  | Ancienne Hibernation                       | Nouveau Scale to Zero                                |
| ------------------------ | ------------------------------------------ | ---------------------------------------------------- |
| Reprise sur requête HTTP | 5 à 20 s                                   | Moins de 500 ms                                      |
| Tâches planifiées        | Ne tournent pas en veille                  | Démarrent automatiquement pour s'exécuter            |
| Traitement des queues    | Ne tournent pas en veille                  | Démarrent automatiquement. Managed Queues recommandé |
| Usage recommandé         | Économies en environnement Flex historique | Configuration standard actuelle                      |

<Info>
  L'ancienne Hibernation avait pour défaut d'empêcher l'exécution des tâches planifiées et des queues pendant la veille. Scale to Zero résout ce problème, et surtout, les Managed Queues permettent aux traitements de queue de continuer sans risque même quand le cluster App est en sommeil.
</Info>

## Étapes d'activation de l'ancienne Hibernation

<Steps>
  <Step title="Ouvrir le App compute cluster">
    Depuis le tableau de bord infra canvas de l'environnement, cliquez sur le App compute cluster.
  </Step>

  <Step title="Activer Hibernation">
    Basculez le toggle **Hibernation** sur activé.
  </Step>

  <Step title="Sauvegarder et redéployer">
    Cliquez sur **Save and Redeploy** pour appliquer les changements.

    <Warning>
      La modification seule ne suffit pas à activer la fonctionnalité. Save and Redeploy est indispensable.
    </Warning>
  </Step>
</Steps>

<Tip>
  Pour activer cette fonctionnalité dans un environnement récent, utilisez le toggle **Scale to Zero** du App compute cluster. Les limitations ci-dessous s'appliquent principalement à l'ancienne Hibernation / Legacy Flex.
</Tip>

## Limitations pendant la veille (ancienne Hibernation)

Lorsque l'Hibernation est activée et que l'environnement est en veille, les fonctionnalités suivantes ne fonctionnent pas.

| Fonctionnalité                         | Comportement en veille             |
| -------------------------------------- | ---------------------------------- |
| Traitement des requêtes HTTP           | Suspendu (traité après la reprise) |
| Task Scheduler                         | Non exécuté                        |
| Queue Worker                           | Non exécuté                        |
| Processus d'arrière-plan personnalisés | Non exécutés                       |

<Info>
  Ces traitements reprennent automatiquement à la sortie de veille. En revanche, les jobs planifiés « qui auraient dû s'exécuter » pendant la veille ne sont pas rejoués rétroactivement.
</Info>

L'Hibernation présente également les limitations suivantes.

* Seul le compute **Flex** peut être mis en veille. Il n'est pas possible d'activer Hibernation sur du compute Pro.
* La veille se fait **au niveau de l'environnement**. Si le cluster App se met en veille, tous les clusters Worker du même environnement se mettent en veille aussi.

## Causes de réveils inutiles

Toute requête HTTP réveille automatiquement l'environnement, y compris des requêtes non désirées.

* **Bots et crawlers** — moteurs de recherche, scanners de sécurité, etc. qui parcourent les pages automatiquement
* **Aperçus de liens Slack ou Teams** — les messageries accèdent à l'URL pour récupérer les miniatures
* **Scans WordPress** — scans automatiques qui accèdent à `/wp-admin` etc. à la recherche d'un WordPress
* **Attaques ciblant les fichiers `.php`** — scans automatisés visant directement des fichiers PHP

Le domaine `*.laravel.cloud` de Laravel Cloud reçoit l'en-tête `X-Robots-Tag: noindex, nofollow` pour empêcher son indexation, mais si le domaine est découvert d'une manière ou d'une autre, cela ne suffit pas. Les domaines personnalisés n'obtiennent pas cet en-tête `noindex`.

<Tip>
  Utiliser un nom de domaine plus complexe réduit le risque que les bots découvrent votre vanity domain.
</Tip>

## Empêcher les réveils inutiles avec Path Blocking

**Path Blocking** est une fonctionnalité qui bloque les requêtes vers certaines extensions ou chemins sans faire sortir l'environnement de veille. Elle empêche les réveils inutiles causés par les scans WordPress ou les attaques ciblant des fichiers PHP.

Voici les extensions et chemins bloqués par défaut.

**Extensions bloquées :**

```
.php, .php3, .php4, .php5, .php6, .php7, .php8,
.phtml, .pht, .phps, .env, .git
```

**Chemins bloqués :**

```
/wp-admin, /wp-content, /wp-includes, /wp-json
```

Ces requêtes reçoivent une réponse sans réveiller l'application, même quand l'environnement est en veille.

<Info>
  Le routage classique de Laravel n'utilise pas de requêtes avec extension `.php`, donc les bloquer n'affecte pas le fonctionnement de l'application.
</Info>

## Cas d'usage adaptés / inadaptés à l'ancienne Hibernation

<Columns cols={2}>
  <Card title="Cas d'usage adaptés" icon="check">
    * **Environnements de staging / développement** — pas besoin d'être en ligne en permanence, gros gain de coût
    * **Blog personnel / portfolio** — trafic faible
    * **Applications de démo / test** — reprise à la demande suffisante
    * **Outils internes à faible fréquence** — usage limité dans le temps
  </Card>

  <Card title="Cas d'usage inadaptés" icon="xmark">
    * **Usage avec tâches planifiées** — `schedule:run` ne s'exécute pas en veille
    * **Jobs de queue périodiques** — les queues sont aussi arrêtées en veille
    * **Production ne tolérant pas la latence de démarrage** — reprise de 5 à 20 s
    * **Applications WebSocket** — la connexion peut ne pas se maintenir et la veille peut être retardée
  </Card>
</Columns>

<Warning>
  Si vous utilisez le task scheduler pour exécuter des traitements périodiques (envoi d'e-mails, agrégation, etc.), l'activation de l'Hibernation empêchera leur exécution. Pour ce genre d'usage, désactivez l'Hibernation, ou concevez un dispositif où un scheduler externe (GitHub Actions, etc.) envoie des requêtes pour maintenir l'environnement éveillé.
</Warning>

<Info>
  Sur le nouveau Scale to Zero, cette contrainte est allégée. Les tâches planifiées s'exécutent automatiquement en veille et, en utilisant Managed Queues, le traitement des queues n'est pas affecté par la mise en veille du cluster App.
</Info>

## Conclusion

L'Hibernation reste utile pour économiser sur Legacy Flex, mais Scale to Zero est aujourd'hui plus pratique.

* Sur Legacy Flex : facturation uniquement quand l'environnement tourne. Mise en veille automatique après timeout.
* Reprise en 5 à 20 s pour l'ancienne Hibernation.
* Le nouveau Scale to Zero démarre en moins de 500 ms.
* Sur Scale to Zero, les tâches planifiées et Managed Queues fonctionnent même en veille.
* Path Blocking empêche les réveils inutiles causés par des bots.
* Compatible uniquement avec le compute Flex.

## Pages liées

<Columns cols={2}>
  <Card title="Planification" icon="calendar" href="/fr/scheduling">
    Configuration du Task Scheduler et comportement sur Laravel Cloud.
  </Card>

  <Card title="Queues" icon="list" href="/fr/queues">
    Configuration du Queue Worker et exploitation sur Laravel Cloud.
  </Card>

  <Card title="Vue d'ensemble Laravel Cloud" icon="cloud" href="/fr/blog/laravel-cloud">
    Managed Queues, Scale to Zero et les nouveaux plans tarifaires en un coup d'œil.
  </Card>
</Columns>


## Related topics

- [Mises à jour Laravel — mai 2026](/fr/blog/changelog/202605.md)
- [Mises à jour Laravel — mars 2026](/fr/blog/changelog/202603.md)
- [Laravel Cloud — le PaaS dédié à Laravel](/fr/blog/laravel-cloud.md)
- [Mises à jour Laravel — avril 2026](/fr/blog/changelog/202604.md)
- [Mises à jour Laravel — juin 2026](/fr/blog/changelog/202606.md)
