# Conception d'une stratégie de basculement de messagerie multicanal

> RCS, WhatsApp, SMS et appels vocaux présentent chacun des défaillances différentes. Une architecture pratique permet de les orchestrer afin qu'un message parvienne à l'utilisateur, quel que soit le canal indisponible.

- URL canonique: https://www.broadnet.me/fr/blog/multi-channel-failover-strategy
- Langue: fr
- Dernière mise à jour: 2026-09-30
- Éditeur: BroadNet (https://www.broadnet.me)

- Publié le: 2026-02-26
- Auteur: BroadNet Engineering

La messagerie monocanal présente un point de défaillance unique. WhatsApp peut être hors service, un utilisateur peut être injoignable via RCS, une route opérateur peut se dégrader, un modèle peut être rejeté en cours de campagne. Une stratégie de basculement multicanal considère l'objectif comme la simple distribution du message à la personne visée, le canal étant un moyen interchangeable. Voici comment concevoir une telle stratégie qui soit réellement fiable.

## Définir l'échelle des canaux par type de message

Il n'existe pas d'ordre universel : la hiérarchie optimale dépend du message. Voici quelques valeurs par défaut judicieuses : pour l'authentification, privilégiez WhatsApp ou RCS (messages riches, personnalisés et rapides), puis les SMS, et enfin le code OTP vocal. Pour les notifications transactionnelles, optez d'abord pour RCS ou WhatsApp afin de garantir une expérience optimale, les SMS servant de solution de repli fiable. Pour les alertes urgentes, privilégiez les SMS pour une couverture maximale et ajoutez la messagerie vocale en cas de besoin. Définissez l'ordre de priorité de manière réfléchie pour chaque type de message et consignez-le par écrit.

## Le basculement doit être conditionnel, et non aveugle.

- Défaillance de la connexion : l’utilisateur est injoignable sur le canal (RCS non configuré, compte WhatsApp inexistant). Interrompez immédiatement ; n’attendez pas.
- Échec de la livraison — le canal a accepté le message, mais le DLR indique qu’il n’a pas été livré. L’envoi est rejeté en raison de l’accusé de réception négatif.
- Échec du délai d'attente — aucune confirmation de livraison positive dans le délai imparti (strict pour les mots de passe à usage unique, plus large pour les notifications). L'envoi est rejeté à l'expiration du délai.
- Panne du fournisseur : le canal est hors service. Détectez-la grâce à la surveillance du taux d’erreur et basculez l’ensemble du canal pour tout le trafic, et non message par message.

## Attention à la double livraison

Le problème subtil inhérent à tout système de basculement est l'envoi du message en double : une première fois sur le canal lent mais fonctionnel, et une seconde fois sur le canal de secours. Pour les mots de passe à usage unique (OTP), ce problème est particulièrement préjudiciable : l'utilisateur reçoit deux codes différents et ne sait pas lequel utiliser. La solution consiste à utiliser une source unique de vérité pour l'état de livraison de chaque message, un enregistrement de chaque envoi (conservez l'identifiant de message renvoyé par l'API et vérifiez son statut avant tout renvoi) afin qu'une nouvelle tentative n'entraîne jamais un second envoi, et – pour les OTP – à générer le code une seule fois et à le réutiliser sur tous les canaux de la hiérarchie, de sorte que chaque message reçu contienne un code valide.

## Le coût et l'expérience se déplacent tous deux vers le bas de l'échelle

Chaque niveau de la chaîne présente des caractéristiques économiques et une expérience utilisateur différentes. Le basculement n'est pas gratuit : il peut impliquer un message moins personnalisé ou un coût unitaire plus élevé. C'est tout à fait normal : un SMS légèrement plus cher, mais qui arrive à destination, vaut mieux qu'un message WhatsApp gratuit qui n'arrive pas. Cela signifie qu'il est important de surveiller votre taux de basculement. Si 40 % du trafic est redirigé vers le dernier niveau, le problème se situe en amont (données de capacité erronées, canal principal mal configuré) et il est préférable de corriger la cause plutôt que de payer pour le symptôme.

> L'API omnicanale de BroadNet implémente l'ensemble des fonctionnalités (vérification des capacités, basculement conditionnel, code OTP partagé et analyses par canal) via un simple appel API, et renvoie un identifiant de message pour chaque envoi afin que vos nouvelles tentatives vérifient le statut au lieu d'envoyer deux fois (voir [idempotence et nouvelles tentatives sûres](https://www.broadnet.me/developers/idempotency)). Vous définissez le message et sa priorité ; la plateforme se charge du reste.

## Tester les voies de défaillance

La raison la plus fréquente pour laquelle une stratégie de basculement ne fonctionne pas en production est que le chemin de basculement n'a jamais été testé : il a été conçu, déployé, mais jamais déclenché avant une panne réelle. Créez des tests synthétiques qui simulent chaque mode de défaillance (désactivation du canal principal, simulation d'un délai d'attente, injection d'un DLR négatif) et vérifiez que le message est bien transmis. Un chemin de basculement non testé est un chemin de basculement inopérant.