Deux métiers différents portent le nom d'« orchestration », et les confondre est ce qui bloque les projets multicanaux. L'orchestration de parcours décide s'il faut contacter quelqu'un, quand, pourquoi et par quel canal : c'est de la logique métier. Les opérations de livraison exécutent une décision déjà prise : choix de l'expéditeur et de la route, adaptateurs, tentatives et repli au sein d'un canal. Elles ont des propriétaires, des tests et des modes d'échec différents.
Modéliser l'état du client, pas le workflow par canal
La décision la plus déterminante est de savoir si le système conserve un état canonique du processus — cette facture est impayée, ce rendez-vous n'est pas confirmé — ou des séquences distinctes par canal qui s'ignorent mutuellement. Avec un état canonique, chaque tentative sur chaque canal agit sur ce même enregistrement, qui décide de la suite.
Événements déclencheurs et fraîcheur de la preuve
Les événements se périment : la facture déjà payée, le rendez-vous déjà confirmé. Il faut relire l'état juste avant l'envoi, pas seulement au moment de la planification, et transporter un horodatage de fraîcheur avec la requête pour rejeter les décisions obsolètes.
Règles d'éligibilité évaluées au moment de l'envoi
Consentement avec preuve récupérable, suppression propagée entre canaux et fournisseurs, disponibilité réelle du canal, identité vérifiée, langue et fuseau horaire local, horaires silencieux évalués en heure locale, plafonds de fréquence et classe de trafic : tout cela s'évalue au moment de l'envoi, pas à l'inscription.
Politique de décision : quel canal, et pourquoi
Canal préféré, urgence et échéance, sensibilité du contenu — le SMS ordinaire doit être considéré comme non chiffré en transit et visible sur écran verrouillé, donc sans identifiants ni données sensibles —, risque, coût comme une entrée parmi d'autres de la politique, et capacité du canal doivent être couchés dans un tableau par cas d'usage.
Idempotence, état de la tentative et repli
La déduplication doit se faire au niveau de l'état, avec une référence propre enregistrée avant l'envoi. Chaque tentative a besoin d'un état explicite — créée, soumise, statut final du fournisseur, expirée par délai, remplacée — distinguant un échec définitif d'une simple absence de confirmation. Le repli doit se déclencher sur des échéances propres au processus et sur des signaux fiables (rejet explicite, destination invalide), en traitant avec prudence la seule absence d'accusé. Il lui faut une limite de canaux et de tentatives, et un chemin pour la chaîne épuisée.
Conditions d'arrêt, réponses et attribution
Chaque parcours a besoin de conditions d'arrêt explicites — résultat atteint, changement d'état, désinscription ou plainte, échéance dépassée, plafond de fréquence, coupe-circuit opérationnel — vérifiées au moment de l'envoi. Les réponses entrantes et désinscriptions doivent atteindre la machine à états et se propager entre canaux. Un identifiant de parcours unique sur toutes les tentatives, clics et résultats permet de savoir ce qui a fonctionné, plutôt que de laisser chaque canal s'attribuer le mérite.
Où vit chaque couche
Les opérations de livraison — adaptateurs, routage, identité d'expéditeur, tentatives, réconciliation et escalade — sont la partie qu'aucune équipe ne devrait construire deux fois. Flowstates fournit et exploite des canaux et des routes, prend en charge les fournisseurs propres du client via le BYOV, et prend en charge les déploiements hybrides comme cette couche managée. L'orchestration est plus variable et vit généralement là où réside déjà l'état canonique du métier : dans l'application elle-même, dans un CRM, ou dans un flux pris en charge par Flowstates.