# Fallback de canal et orchestration omnicanale

> L'orchestration de canaux remet un même message logique sur plusieurs canaux par enchaînement : vérifier la capacité, tenter le canal riche préféré (RCS ou WhatsApp), et retomber sur le SMS en cas de non-capacité, d'échec ou d'expiration. Le routage équilibre le moindre coût et la meilleure expérience, les règles de reprise et d'expiration bornent chaque étape, et un DLR unifié réconcilie le statut entre les canaux.

- URL canonique: https://www.broadnet.me/fr/reference/channel-fallback-and-orchestration
- Langue: fr
- Dernière mise à jour: 2026-07-18
- Éditeur: BroadNet (https://www.broadnet.me)

Comment la remise omnicanale s'enchaîne entre les canaux : vérifications de capacité, fallback RCS→SMS et WhatsApp→SMS, routage au moindre coût ou à la meilleure expérience, règles de reprise et d'expiration, et une vue de rapport de remise unifiée qui réconcilie le statut sur tous les canaux.

## Pourquoi l'orchestration existe

Aucun canal ne joint tout le monde, et chacun présente un coût, une richesse et des caractéristiques de remise différents — de sorte qu'une entreprise qui veut à la fois de la portée et de l'expérience doit utiliser plusieurs canaux pour un même message logique. L'orchestration omnicanale est la logique qui transforme une intention (« dire à ce client que sa commande est expédiée ») en la bonne séquence de tentatives de canal pour ce destinataire précis : tenter le canal le plus riche et le plus marqué que le terminal peut recevoir, et retomber par des canaux progressivement plus simples jusqu'à ce que l'un remette. L'orchestrateur masque cette complexité derrière un envoi unique, de sorte que l'émetteur exprime l'intention et la politique tandis que la plateforme gère la capacité, le routage, les reprises et la réconciliation.

## L'enchaînement : vérification de capacité puis fallback

Un enchaînement est une liste ordonnée de canaux avec une règle pour passer au suivant. Il commence par une vérification de capacité — ce terminal est-il joignable en RCS, cet utilisateur a-t-il opté pour WhatsApp — car envoyer vers un canal injoignable ne fait que gaspiller une étape. L'orchestrateur tente le premier canal éligible et passe au suivant sur un déclencheur défini : le canal n'est pas capable, l'envoi est rejeté, ou la remise n'est pas confirmée dans un délai d'expiration. Les enchaînements courants sont RCS→SMS (riche et de marque d'abord, texte universel comme plancher), WhatsApp→SMS (canal applicatif opt-in d'abord, SMS sinon) et RCS→WhatsApp→SMS. Le SMS se trouve presque toujours au bas de l'échelle car c'est le plancher universel, toujours joignable.

*Enchaînement RCS → WhatsApp → SMS avec garde-fous de capacité et d'expiration*

```text
deliver(order_shipped, +15551234567):
  if rcsCapable(msisdn):
      send RCS rich card;  await DLR up to T_rcs
      if delivered: DONE
  if whatsappOptedIn(msisdn):
      send WhatsApp template; await status up to T_wa
      if delivered/read: DONE
  send SMS (universal fallback);  await DLR up to T_sms
  record final status on the unified message id
```

## Routage : moindre coût vs meilleure expérience

Choisir l'ordre de la cascade est une décision de routage, et deux objectifs s'opposent. Le routage au moindre coût privilégie le canal et la route les moins chers qui assureront la livraison — utile pour le trafic à haut volume et faible urgence où un frais RCS par conversation, un frais WhatsApp par message ou une route SMS moins chère l'emporte. Le routage par meilleure expérience privilégie le canal le plus riche, le plus marqué et le plus fiable que le destinataire puisse recevoir — utile lorsque l'engagement, l'image de marque ou l'interactivité comptent plus que le coût unitaire. La plupart des politiques mélangent les deux par classe de message : les reçus transactionnels peuvent optimiser l'expérience et la marque, tandis que les notifications de masse optimisent le coût. L'orchestrateur applique la politique en conjonction avec les capacités et les règles par marché (enregistrement de l'ID expéditeur, catégories WhatsApp, disponibilité RCS) pour choisir le premier saut effectif.

*Objectifs de routage et où chacun s'inscrit*

| Objectif | Préfère | Idéal pour |
|---|---|---|
| Moindre coût | Canal/route compatible le moins cher | Notifications à volume élevé et à faible urgence |
| Meilleure expérience | Canal compatible vérifié le plus riche | Messages de marque, interactifs et axés sur l'engagement |
| Priorité fiabilité | Canal offrant la meilleure garantie de remise | OTP, alertes critiques/urgentes |
| Conformité requise | Seuls les canaux autorisés sur le marché | Destinations réglementées, règles d'identification de l'expéditeur |

## Reprise, expiration et déduplication

Chaque étape d'un enchaînement a besoin d'un comportement borné pour que l'ensemble de la remise soit déterministe et ne facture jamais deux fois le destinataire. Un délai d'expiration par canal définit combien de temps attendre la confirmation avant de passer à la suite — assez long pour une remise légitime, assez court pour que le fallback arrive encore utilement (un OTP qui arrive une heure trop tard ne vaut rien). Les reprises au sein d'un canal gèrent les défaillances transitoires, mais doivent distinguer un rejet permanent (passer immédiatement à la suite) d'un rejet transitoire (réessayer, puis passer). Et parce qu'un message peut avoir été envoyé sur un canal riche pendant qu'un fallback se déclenche, l'orchestrateur déduplique par rapport à un identifiant de message logique unique afin que le client ne reçoive pas deux fois la même notification. Les clés d'idempotence sur l'envoi rendent les reprises sûres.

## Rapports de remise unifiés entre les canaux

Chaque canal rend compte de la remise différemment — le SMS renvoie un rapport de remise SS7/SMPP, WhatsApp poste des webhooks sent/delivered/read/failed, le RCS émet des événements de remise et de lecture — de sorte qu'un envoi orchestré a besoin d'un DLR unifié qui les fait tous correspondre à un modèle de statut unique par rapport à l'identifiant de message logique. Cela permet à un émetteur de poser une seule question, « ce message a-t-il atteint le client, et comment », et d'obtenir une seule réponse qui nomme le canal ayant finalement remis, les canaux tentés et écartés, et le signal de lecture/engagement là où le canal le fournit. La vue unifiée est aussi ce qui alimente l'analytique de routage — quels enchaînements remettent, à quel coût, sur quels marchés — bouclant la boucle de la politique au résultat.

*Statut par canal ramené à un modèle unifié*

| Canal | Statut natif | Statut unifié |
|---|---|---|
| SMS | Rapport de livraison SMPP/SS7 | envoyé / livré / échec |
| RCS | Événements de livraison et de lecture | envoyé / livré / lu / échec |
| WhatsApp | webhook envoyé / livré / lu / échec | envoyé / livré / lu / échec |
| Résultat en cascade | (composite) | delivered-via-<channel> / exhausted |

## Questions fréquentes

### Qu'est-ce que le fallback de canal ?

Le fallback de canal remet un même message logique en tentant les canaux dans l'ordre et en passant au suivant lorsque l'un est indisponible ou ne confirme pas la remise. Un enchaînement typique est RCS→SMS ou WhatsApp→SMS : tenter d'abord le canal riche et de marque, et retomber sur le SMS — le plancher universel — en cas de non-capacité, de rejet ou d'expiration.

### Comment l'orchestrateur décide-t-il quel canal tenter en premier ?

Il combine une vérification de capacité (le terminal est-il joignable en RCS, l'utilisateur a-t-il opté pour WhatsApp) avec une politique de routage. Le routage au moindre coût privilégie le canal capable le moins cher ; le routage à la meilleure expérience privilégie le plus riche et vérifié ; la priorité à la fiabilité privilégie la remise garantie. Les règles par marché comme l'enregistrement de sender ID et les catégories WhatsApp restreignent davantage les canaux éligibles.

### Qu'est-ce que le routage au moindre coût vs à la meilleure expérience ?

Le routage au moindre coût choisit le canal et la route les moins chers qui remettront, adapté à un trafic à fort volume et faible urgence. Le routage à la meilleure expérience choisit le canal le plus riche, le plus marqué et le plus fiable que le destinataire peut recevoir, adapté aux messages axés sur l'engagement. La plupart des politiques mélangent les deux par classe de message — les reçus pour l'expérience, les alertes en masse pour le coût.

### Comment le fallback évite-t-il d'envoyer deux fois le même message ?

En liant chaque étape à un identifiant de message logique unique et en dédupliquant par rapport à lui, avec des délais d'expiration par canal et des clés d'idempotence pour que les reprises soient sûres. Un rejet permanent passe immédiatement au canal suivant ; une défaillance transitoire est réessayée avant de passer. Le destinataire voit la notification une seule fois, sur le canal qui a finalement remis.

### Quel délai d'expiration chaque étape de canal doit-elle utiliser ?

Assez long pour permettre une confirmation de remise légitime, assez court pour que le fallback arrive encore utilement. Un code à usage unique qui arrive une heure trop tard ne vaut rien, aussi ses délais d'expiration par étape sont-ils courts ; une notification non urgente peut attendre plus longtemps sur un canal riche avant de retomber sur le SMS.

### Qu'est-ce qu'un DLR unifié ?

Un rapport de remise unifié fait correspondre le statut natif de chaque canal — rapports de remise SMS, webhooks WhatsApp sent/delivered/read/failed, événements de remise et de lecture RCS — à un modèle de statut unique par rapport à l'identifiant de message logique. Il permet à un émetteur de poser une seule question sur le fait qu'un message a atteint le client et comment, et alimente l'analytique de routage.

## Sources

- [GSMA — RCS Business Messaging and capability discovery](https://www.gsma.com/solutions-and-impact/technologies/networks/rcs/)
- [WhatsApp Business Platform — message status webhooks](https://developers.facebook.com/docs/whatsapp/cloud-api/webhooks)
- [3GPP TS 23.040 — SMS status reports](https://www.3gpp.org/dynareport/23040.htm)

## Voir aussi

- [Omnicanal](https://www.broadnet.me/fr/products/omnichannel)
- [RCS vs SMS vs WhatsApp](https://www.broadnet.me/fr/reference/rcs-vs-sms-vs-whatsapp-channels)
- [RCS Business Messaging et MaaP](https://www.broadnet.me/fr/reference/rcs-business-messaging-maap)
- [WhatsApp Business Cloud API](https://www.broadnet.me/fr/reference/whatsapp-business-cloud-api)
- [API SMS](https://www.broadnet.me/fr/products/sms-api)
- [Plateforme CPaaS](https://www.broadnet.me/fr/platforms/cpaas)