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.
- L'utilisateur demande un codeConnexion, paiement ou inscription
- Votre application appelle l’API de vérificationUne requête par code
- BroadNet délivre le codeVia le meilleur canal disponibleSolution de secours en cas de non-délivranceSMSWhatsAppVoix
- L'utilisateur saisit le codeVérification par rapport au code émis
- VérifiéAccès accordé
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.
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 idRoutage : 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.
| 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.
| 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 |
| webhook envoyé / livré / lu / échec | envoyé / livré / lu / échec | |
| Résultat en cascade | (composite) | delivered-via-<channel> / exhausted |
Questions fréquemment posées
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.
Spécifications sources
Les normes publiées sur lesquelles repose cette page. S'ouvre dans un nouvel onglet.