> ## Documentation Index
> Fetch the complete documentation index at: https://documentation.onesignal.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Messages de secours : Assurer la livraison sur tous les canaux
> Implémentez une stratégie de secours avec OneSignal pour garantir que les messages critiques sont livrés par email ou SMS lorsque les notifications push échouent. Apprenez à configurer la messagerie multi-canal en utilisant Journeys, les API et la segmentation pour un engagement utilisateur fiable.
## Pourquoi utiliser une méthode de secours ?
Un message peut ne pas toujours être envoyé ou reçu via un canal donné. Les raisons courantes incluent :
* L'utilisateur n'a pas ce canal disponible (par exemple, pas d'adresse email ou de numéro de téléphone, ou n'est pas abonné au push)
* Le message n'a pas pu être envoyé en raison d'erreurs de livraison ou de jetons invalides
* Les utilisateurs désactivant ou révoquant les permissions
* Les appareils étant hors ligne ou dans des états restreints (par exemple, Mode Concentration iOS)
* Applications désinstallées ou jetons push expirés
OneSignal prend en charge le secours sur **tous les canaux**—Push, In-App, Email et SMS—afin que vous puissiez vous assurer que les communications critiques atteignent toujours les utilisateurs, quel que soit le canal d'origine.
***
## Vue d'ensemble de la stratégie de secours
Tentez de livrer le message via votre canal préféré (par exemple, Push, Email ou SMS).
Utilisez les données de livraison ou la logique basée sur les événements pour déterminer si le message a été livré, cliqué ou ouvert avec succès. Dans Journeys, cela se produit automatiquement en utilisant les [nœuds Wait Until](./journeys-actions#wait-until).
Si le message n'a pas signalé une [livraison confirmée](./confirmed-delivery) ou n'a pas été cliqué/ouvert, envoyez le même message via un autre canal disponible (par exemple, Email, SMS ou Push).
***
## Exigences
* [ID externe](./users#external-id)
* Les utilisateurs doivent avoir au moins un [abonnement](./subscriptions) valide pour chaque canal (email, téléphone, jeton push)
***
## Exemples de configuration
### Option 1 : OneSignal Journeys
Utilisez [OneSignal Journeys](./journeys-overview) pour automatiser visuellement la logique de secours sans code.
* Interface glisser-déposer
* Prend en charge la confirmation de livraison (avec [Livraison confirmée](./confirmed-delivery))
* Combine Push, In-App, Email et SMS
* Automatise le secours sans intégration API
#### Configuration recommandée
Au lieu d'un branchement oui/non, utilisez un nœud [**Wait Until**](./journeys-actions#wait-until) :
Configurez-le pour **attendre jusqu'à ce que le message soit livré**
*(la livraison confirmée s'applique uniquement au push)*, **cliqué** ou **ouvert** *(email uniquement)*.
* Définissez une **période d'expiration** pour éviter les attentes indéfinies
* Après expiration, envoyez le message de secours via un autre canal
La Livraison confirmée doit être activée par plateforme. Voir [Livraison confirmée](./confirmed-delivery).
***
### Option 2 : Flux de travail de secours personnalisé (Avancé)
Vous pouvez créer un système de secours en utilisant l'[API REST OneSignal](/reference/create-message) et l'[API View Message](/reference/view-message), mais cela nécessite une implémentation soignée.
Envoyez une notification à un seul utilisateur en utilisant son `external_id` et le canal cible.
```json json theme={null}
POST https://onesignal.com/api/v1/notifications
{
"include_aliases": {
"external_id": ["user123"]
},
"target_channel": "push",
"contents": { "en": "Your order has shipped!" }
}
```
Interrogez l'[API View Message](/reference/view-message) en utilisant le `notification_id` pour déterminer s'il a été livré.
```json json theme={null}
GET https://onesignal.com/api/v1/notifications/{notification_id}
```
Si le message a échoué ou affiche `"received": 0`, préparez-vous à renvoyer via un autre canal.
Avant de renvoyer, vérifiez les canaux disponibles de l'utilisateur en récupérant son enregistrement (via l'[API View User](/reference/view-user)).
Ensuite, envoyez le message à nouveau via le prochain canal disponible (Email, SMS ou Push).
Cette méthode est complexe et **non recommandée** pour la plupart des cas d'usage. Elle nécessite un suivi au niveau des messages, des recherches d'utilisateurs et la gestion manuelle de la logique de secours.
***
### Option 3 : Event Streams
Utilisez [Event Streams](./event-streams) pour surveiller les événements de message en temps réel. Cela permet aux systèmes externes de réagir automatiquement lorsqu'un message échoue.
Flux courant :
1. Envoyez une notification push ou email
2. Capturez les événements `notification_failed` ou `delivery_failed` via Event Streams
3. Déterminez si l'utilisateur peut recevoir un autre canal (en vérifiant ses abonnements disponibles et activés via l'[API View User](/reference/view-user))
4. Envoyez un message de secours via le prochain canal disponible
> Event Streams fournit des informations de livraison en temps réel mais n'émet pas d'événement pour "non envoyé", car les messages non envoyés n'ont pas d'événement. Utilisez ceci uniquement pour gérer les échecs, clics, ouvertures et désabonnements.
***
### Option 4 : Détecter et segmenter les utilisateurs désabonnés
Vous pouvez taguer les utilisateurs qui se sont désabonnés de canaux spécifiques et les recibler manuellement via un autre.
Utilisez l'observateur SDK [`addPermissionObserver()`](./mobile-sdk-reference#addpermissionobserver-push) pour détecter les changements de permission push.
Lorsque la permission est révoquée, taguez l'utilisateur (par exemple, `unsubscribed_from_push: true`).
Dans le tableau de bord OneSignal, créez un segment :
* `unsubscribed_from_push = true`
* ET possède un abonnement email ou SMS
Ensuite, ciblez ce segment avec votre campagne de secours.
> Il s'agit d'une option manuelle et non idéale pour l'automatisation, mais elle fonctionne pour les campagnes de secours périodiques.
***
## Meilleures pratiques
* **Choisissez le canal de secours en fonction de la priorité du message.**
* Utilisez le **SMS** pour les alertes urgentes (par exemple, sécurité ou temps d'arrêt).
* Utilisez **Email ou In-App** pour les mises à jour non urgentes.
* **Journeys est la méthode la plus simple et la plus fiable** pour gérer le secours.
* **Ajoutez des expirations** aux nœuds Wait Until pour éviter les attentes indéfinies.
* **La Livraison confirmée** est requise pour déclencher un véritable secours basé sur la livraison.
* **Évitez les doublons multi-canal** en vous assurant que les messages de secours référencent le statut de livraison.
***
## Exemples de cas d'usage
### Alerte de sécurité
Si une alerte de sécurité push échoue, envoyez immédiatement une alerte SMS.
### Mise à jour de livraison de commande
Envoyez un push avec des informations de suivi. Si non livré, envoyez la même mise à jour par Email.
### Notification d'échec de paiement
Si un push échoue, envoyez un SMS exhortant l'utilisateur à réessayer le paiement.
### Rappel d'événement
Si un rappel par email n'est pas livré, envoyez une notification Push à la place.
### Alerte de temps d'arrêt système
Si le push échoue, le secours par SMS garantit que les utilisateurs restent informés en temps réel.
### Avis de facturation
Si la livraison par email échoue, envoyez un rappel push ou SMS.
### Notification de vente flash
Si le push n'est pas livré, envoyez un SMS avec les détails de la promo et un lien vers la boutique.
Besoin d'aide ?
Discutez avec notre équipe d'assistance ou envoyez un e-mail à `support@onesignal.com`
Veuillez inclure :
* Les détails du problème que vous rencontrez et les étapes de reproduction si disponibles
* Votre OneSignal App ID
* L'External ID ou le Subscription ID le cas échéant
* L'URL du message que vous avez testé dans le OneSignal Dashboard le cas échéant
* Tous les [journaux ou messages d'erreur](/docs/en/capturing-a-debug-log) pertinents
Nous serons ravis de vous aider !
***