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

> Consultez les bonnes pratiques d’Auth0 Events pour gérer de façon fiable les flux d’événements, notamment l’accusé de réception des livraisons, l’utilisation de files d’attente asynchrones, la déduplication et l’ordonnancement des événements, ainsi que le comportement relatif aux nouvelles tentatives et à la désactivation automatique.

# Bonnes pratiques relatives à Events

Pour obtenir les meilleurs résultats lors du développement de flux d’événements, Auth0 recommande de suivre les bonnes pratiques ci-dessous. Ces recommandations peuvent aider à réduire les obstacles, à améliorer l’efficacité et à offrir une expérience événementielle de premier plan.

<div id="use-asynchronous-queues-to-process-events">
  ### Utilisez des files d’attente asynchrones pour traiter les événements
</div>

À la réception d’un événement, renvoyez un code HTTP 2XX OK (p. ex., 200 OK, 202 Accepted, 204 No Content) pour indiquer que l’événement a bien été livré. Sans cette réponse, Auth0 considère la livraison de l’événement comme un échec et réessaiera conformément au comportement décrit dans [Comportement du système en cas d’échec de livraison d’événements](#system-behavior-during-failed-event-deliveries).

Pour éviter les problèmes d’évolutivité, configurez votre gestionnaire pour traiter les événements entrants au moyen d’une file d’attente asynchrone. Si vous traitez les événements de façon synchrone, toute forte hausse des livraisons de webhook (par exemple, au début du mois, lorsque tous les abonnements se renouvellent) risque de surcharger les serveurs qui hébergent vos endpoints. Les files d’attente asynchrones vous permettent de traiter les événements simultanés à un rythme que votre système peut prendre en charge.

<div id="ignore-duplicate-events">
  ### Ignorer les événements en double
</div>

Il peut arriver que les point de terminaison webhook reçoivent le même événement plus d’une fois. Pour éviter de traiter des événements en double, consignez les ID des événements que vous avez déjà traités.

<div id="handle-out-of-sequence-events">
  ### Gérer les événements hors séquence
</div>

Auth0 ne garantit pas que les événements sont transmis dans le même ordre que celui dans lequel ils sont générés. Par exemple, lorsqu’un utilisateur est créé, puis immédiatement mis à jour pour qu’un autre utilisateur y soit lié, vous pourriez recevoir :

* `user.updated (for User 1)`
* `user.created (for User 1)`
* `user.deleted (for User 2)`
* `user.updated (for User 2)`

Pour éviter d’écraser vos données avec des renseignements périmés, comparez l’attribut `time` du webhook entrant à l’horodatage des données de votre système. L’attribut `data.object` dans le payload peut également comprendre les champs `created_at` et `updated_at` pour des horodatages propres à l’opération. Consultez les détails de l’événement dans le [catalogue des événements](/docs/fr-ca/events) pour en savoir plus.

<div id="listen-for-specific-event-types">
  ### Écouter certains types d’événements
</div>

Configurez vos points de terminaison webhook pour recevoir uniquement les types d’événements nécessaires à votre intégration. Recevoir des événements supplémentaires (ou tous les événements) surcharge inutilement votre serveur et n’est pas recommandé.

Vous pouvez modifier les événements qu’un point de terminaison webhook reçoit en [mettant à jour les flux d’événements](/docs/fr-ca/customize/events/create-an-event-stream).

<div id="system-behavior-during-failed-event-deliveries">
  ### Comportement du système lors des échecs de livraison d’événements
</div>

À l’heure actuelle, Auth0 n’autorise qu’un total de quatre tentatives, soit la tentative initiale et trois nouvelles tentatives avec temporisation exponentielle (1s, 2s, 4s). Si vous recevez un code 4XX, l’événement échoue immédiatement, sans nouvelle tentative, puisqu’un nouvel essai a peu de chances de modifier la réponse.

Si votre endpoint ne répond toujours pas correctement après ce délai, l’événement est marqué comme ayant échoué, et Auth0 ne tentera plus de l’envoyer. Pour en savoir plus sur les événements en échec, consultez [Tests, observabilité et reprise après échec des flux d’événements](/docs/fr-ca/customize/events/event-testing-observability-and-failure-recovery).

<div id="disable-failing-event-streams">
  ### Désactiver les flux d’événements défaillants
</div>

Les flux d’événements sont automatiquement désactivés dans les cas suivants :

* Auth0 enregistre 500 échecs d’affilée (c.-à-d. tout ce qui n’est pas un `2XX`).
* Le flux d’événements atteint un total de 5 000 livraisons en échec.
* Auth0 enregistre trois échecs consécutifs de tentative de livraison (c.-à-d. tout ce qui n’est pas un `2XX`).

  * Si vous souhaitez autoriser un plus grand nombre d’échecs de tentative de livraison, soumettez un ticket de soutien en précisant le nombre d’échecs permis, et Auth0 examinera votre demande.

<div id="learn-more">
  ## En savoir plus
</div>

* [Catalogue d’événements](/docs/fr-ca/events)
* [Créer un flux d’événements](/docs/fr-ca/customize/events/create-an-event-stream)
* [Tests, observabilité et reprise après échec des flux d’événements](/docs/fr-ca/customize/events/event-testing-observability-and-failure-recovery)