Architecture omnicanal : chatbot web, WhatsApp, Teams

Omnicanal : la promesse… et le piège

La promesse :

• “On va mettre le bot sur le site, sur WhatsApp, sur Teams.”
• “L'expérience sera la même.”

Le piège :

L'expérience ne peut pas être “la même”, parce que les canaux ne sont pas les mêmes.

Un bon omnicanal n'est pas une duplication. C'est une unification.

Et en B2B, l'unification la plus importante est invisible :

• identité,
• state,
• sécurité,
• observabilité.

Les 4 invariants d'un chatbot omnicanal

Si vous devez retenir une structure :

1. Identité : qui parle (user_id) ?
2. Conversation : quel fil (conversation_id) ?
3. State : où en est-on (intent, IDs, locale) ?
4. Knowledge : quelles sources (RAG) ?

Si vous n'unifiez pas ces quatre éléments, l'omnicanal devient une série de chatbots différents.

Et ça se voit : l'utilisateur répète, les agents support répètent, et vos logs ne se recollent pas.

Le pattern “core + adaptateurs”

Architecture recommandée :

• un core conversationnel (orchestrateur) qui gère : prompts, RAG, tool calling, state, règles d'escalade.
• des adaptateurs de canal (web, WhatsApp, Teams) qui traduisent : formats, limitations, authentification.

Pourquoi ?

Parce que vous voulez :

• une logique métier unique,
• et des particularités de canal isolées.

Fiabilité réseau : webhooks, retries, et messages en double

Sur le web, vous contrôlez l'interface. Sur des canaux externes (WhatsApp, Teams), vous recevez souvent des webhooks.

Et les webhooks ont une loi fondamentale :

si ça peut être reçu deux fois, ça sera reçu deux fois.

Donc votre architecture doit être :

• idempotente (même message traité deux fois = même effet),
• et résistante aux retries.

Sur WhatsApp, par exemple, la WhatsApp Business Platform s'appuie sur des webhooks pour notifier les événements et messages entrants.¹ Sur Teams, l'intégration passe typiquement par les bots Microsoft Teams (basés sur le Bot Framework), avec des “activities” envoyées à votre endpoint.²

Pattern recommandé :

• chaque message entrant reçoit un message_id,
• vous stockez un processed_message_id (ou une table de déduplication),
• et vous ignorez les doublons.

Sans ça, vous allez :

• appeler deux fois un outil,
• envoyer deux fois un email,
• créer deux tickets.

Et le client, lui, ne verra qu'une chose : le chaos.

Ordre des messages : l'omnicanal adore le désordre

Autre phénomène : l'ordre.

Sur certaines messageries, deux messages peuvent arriver dans un ordre différent de l'envoi (réseau, retries).

Donc :

• ne construisez pas votre state comme une simple concaténation d'historique,
• utilisez des timestamps,
• et soyez robustes aux inversions.

Le state structuré est encore plus important en omnicanal : il ne dépend pas de l'ordre parfait du texte.

Pièces jointes et médias : ne les traitez pas comme “un texte”

Omnicanal = parfois :

• captures d'écran,
• PDF,
• photos,
• voice notes.

Décisions à prendre :

• acceptez-vous les médias ?
• comment les stockez-vous ?
• les indexez-vous (OCR) ?
• quelles règles de sécurité (PII) ?

La plupart des projets gagnent à commencer texte-only, puis à ajouter les médias de façon ciblée (ex. support technique où les screenshots sont réellement utiles).

Capabilities par canal : faites une matrice (sinon vous improviserez)

Chaque canal a :

• des limites de longueur,
• des formats,
• des contraintes de consentement,
• des temps de réponse attendus.

Faites une matrice simple :

Cette matrice évite le “copier-coller” de design d'un canal à l'autre.

Identité : le problème le plus sous-estimé

Sur le web, vous avez :

• cookies,
• login,
• sessions.

Sur WhatsApp, vous avez un numéro. Sur Teams, un compte entreprise.

Donc, vous devez décider :

• comment mapper ces identités,
• et comment gérer l'anonymat.

En B2B, deux modes fréquents :

• anonyme : support pré-vente, FAQ.
• authentifié : suivi de dossier, données personnelles, actions.

Ne mélangez pas.

Si un canal ne permet pas une authentification solide, n'y exposez pas des actions sensibles.

Auth “light” vs auth “forte” : choisir selon le risque

L'omnicanal vous force à accepter une réalité :

• tout le monde n'est pas loggé,
• tout le monde ne veut pas se logger,
• et certains canaux ne sont pas faits pour.

Donc, vous pouvez définir des niveaux :

• niveau 0 (anonyme) : FAQ, découverte, orientation.
• niveau 1 (vérification légère) : email + code, ou lien sécurisé.
• niveau 2 (auth forte) : SSO, compte client, OAuth.

Et vous mappez vos capacités :

• niveau 0 : pas d'accès aux données personnelles, pas d'actions à impact.
• niveau 1 : accès limité (ex. statut de dossier), actions limitées.
• niveau 2 : actions plus riches (modification, documents).

Le gain de ce modèle : vous pouvez déployer un chatbot sur un canal public sans vous interdire toute valeur. Vous “scopez” simplement.

Consentement et opt-in : la contrainte “humaine” des canaux

Certaines messageries ont des règles d'opt-in, de templates, ou de fenêtres de réponse.

Vous n'avez pas besoin de mémoriser toutes les politiques ici. Mais vous devez intégrer le fait que le canal impose parfois :

• des formats,
• des délais,
• et des contraintes d'envoi.

Donc, dans votre core :

• ne supposez pas que vous pouvez envoyer n'importe quel message n'importe quand,
• et prévoyez des chemins alternatifs (email, ticket).

Ce design évite l'architecture “qui marche sur web” mais devient impossible sur messagerie.

conversation_id : l'anti “répétez-moi tout”

Le secret du confort omnicanal est un identifiant stable :

• un conversation_id que vous réutilisez,
• un case_id si escalade.

Et si l'utilisateur change de canal, vous devez pouvoir rattacher :

• via login,
• via email,
• via code de transfert.

Sans ça, le bot oublie, et l'humain aussi.

State omnicanal : le champ locale + les IDs + l'intent

Le state est l'endroit où vous gagnez en robustesse :

• intent
• order_id / case_id
• locale
• channel
• handoff_requested

On détaille l'approche state ici : Mémoire chatbot : contexte & state.

L'omnicanal ajoute un champ : channel.

Pourquoi ? Parce que certaines règles dépendent du canal :

• pièces jointes possibles,
• longueur max,
• authentification.

RAG partagé : la même connaissance, des règles différentes

Vous voulez souvent une base de connaissance unique. Mais vous devez appliquer des règles par canal :

• sur un canal public : sources publiques uniquement,
• sur un canal authentifié : sources privées selon RBAC.

Donc, même base, filtres différents.

Et des logs pour vérifier que ça ne fuite pas.

Sécurité par canal : ce qui est OK sur Teams ne l'est pas sur WhatsApp

L'omnicanal crée une tentation : “si ça marche ici, on le met partout”.

En sécurité, c'est l'inverse : “si c'est risqué quelque part, on le limite”.

Exemples :

• sur Teams (interne, authentifié), vous pouvez autoriser des actions internes (création de ticket IT, recherche dans un wiki interne).
• sur WhatsApp (externe), vous devez limiter : pas d'accès large à des sources internes, pas d'actions à impact sans authentification solide.

Donc, vous définissez des politiques par canal :

• sources accessibles (RAG) selon canal,
• outils autorisés selon canal,
• et niveaux de confirmation (HITL) selon canal.

Ce n'est pas “paranoïaque”. C'est du design de produit responsable.

Si vous ne le faites pas, vous risquez le pire bug omnicanal : la fuite de données via le canal le plus exposé.

Modèle de données : unifier sans tout mélanger

Un omnicanal fiable a souvent un modèle de données minimal :

• user_id (interne)
• external_id (par canal)
• conversation_id (stable)
• channel (web, whatsapp, teams)
• state (JSON)
• transcript (log)
• created_at, updated_at

Pourquoi ce modèle aide :

• vous pouvez corréler,
• vous pouvez dédupliquer,
• vous pouvez transmettre à l'humain,
• et vous pouvez appliquer des règles de rétention.

Et surtout : vous pouvez instrumenter.

Sans un modèle de données clair, l'omnicanal devient une collection de logs incohérents.

UX : formats et limitations par canal

WhatsApp n'est pas le web. Teams n'est pas WhatsApp.

Donc :

• privilégiez des réponses plus courtes sur mobile,
• utilisez des quick replies quand le canal le permet,
• évitez les longs tableaux.

Le design conversationnel doit être décliné par canal. (Voir : Design conversationnel.)

Escalade omnicanal : continuité bot → humain

L'escalade est plus complexe en omnicanal :

• un ticket ouvert sur web doit être visible sur WhatsApp,
• un agent sur Teams doit voir le transcript,
• le SLA doit être cohérent.

Le pattern : ticket unique + transcript + state + résumé.

On détaille : Escalade & handoff humain.

Exemple terrain : l'utilisateur commence sur le web, finit sur WhatsApp

Cas classique :

1. L'utilisateur visite votre site (web) et pose une question.
2. Il n'a pas le temps, il part.
3. Plus tard, il écrit sur WhatsApp.

Sans omnicanal :

• il recommence,
• le bot recommence,
• et vous perdez le contexte.

Avec omnicanal :

• vous avez un user_id ou un mécanisme de rattachement (email / code),
• vous retrouvez le conversation_id,
• vous réutilisez le state,
• et vous poursuivez.

UX :

Je retrouve votre demande précédente. Vous cherchiez à suivre le dossier 8391, c'est bien ça ?

Ce message fait deux choses :

• il économise du temps,
• il augmente la confiance (“ok, ils savent où on en est”).

Mais il n'est possible que si votre architecture a :

• une identité unifiée,
• un state explicite,
• et une règle de rattachement cross-canal.

Observabilité : tracer par canal, pas seulement global

Un bot omnicanal a :

• des latences différentes,
• des erreurs différentes,
• des comportements différents.

Donc, mesurez par canal :

• résolution,
• escalade,
• latence,
• erreurs outils,
• refus.

Et corrélez via conversation_id.

Sans ça, vous ne “pilotez” pas. Vous observez un bruit.

Pour les systèmes distribués, instrumenter avec des traces et corréler les spans (modèle, retrieval, outils) est une base robuste ; OpenTelemetry formalise ces concepts.³

Tests et déploiement : un omnicanal se casse en prod si vous ne simulez pas

Avant de brancher 3 canaux, testez :

• sur un canal,
• avec des messages en double,
• des timeouts,
• et des utilisateurs qui changent de canal.

Ajoutez des tests :

• déduplication,
• idempotence sur outils,
• handoff avec transcript,
• et règles RBAC (selon canal).

L'omnicanal n'est pas difficile parce que c'est “beaucoup”. Il est difficile parce que c'est “beaucoup de cas limites”.

Déploiement progressif par canal

Un piège fréquent : déployer une nouvelle version du core partout en même temps.

En omnicanal, c'est risqué parce que :

• chaque canal a ses propres contraintes,
• et chaque canal a sa propre distribution d'intents (web ≠ Teams).

Pattern :

• canary sur un canal (web),
• puis extension à un second canal (WhatsApp),
• puis le reste.

Vous gardez un rollback simple : “revenir à la version N sur WhatsApp”.

Le contenu comme composant d'architecture

Un omnicanal efficace s'appuie sur votre site web.

Quand le bot répond, il peut pointer vers :

• une page procédure,
• une page solution,
• un guide.

Ces pages deviennent des “ancrages” :

• pour l'utilisateur (source stable),
• pour le RAG (source indexable),
• et pour l'omnicanal (même référence quel que soit le canal).

En clair : votre stratégie de contenu est une stratégie d'architecture. Et c'est ce qui vous permet de tenir une expérience cohérente sans envoyer 400 tokens à chaque message.

Roadmap “zéro à héros” omnicanal en 2 semaines

1

Définir core + adaptateurs

Orchestrateur central + connecteurs de canal. Pas de logique dupliquée.

2

Standardiser identité + conversation_id

Mapping user_id, un conversation_id stable, et un case_id pour handoff.

3

Rendre le state explicite

intent, IDs, locale, channel. Validation serveur.

4

Segmenter la sécurité

RBAC, sources RAG, actions autorisées selon canal.

5

Mesurer par canal

Dashboards et alertes par canal. Itérer.

Conclusion : l'omnicanal est une discipline de continuité

Un chatbot omnicanal réussi donne une impression simple :

• “je peux parler où je veux”
• “et on me comprend”

Cette simplicité est construite par :

• identité + conversation_id,
• state explicite,
• core unique + adaptateurs,
• sécurité par canal,
• et observabilité.

Si vous faites ça, vous gagnez un avantage très concret : vous servez mieux vos clients, sur leurs canaux, sans multiplier les systèmes. Et vous réduisez la dette, parce que vous n'avez pas 3 chatbots différents. Vous avez un produit.

Et c'est exactement ce que les équipes cherchent quand elles disent “omnicanal” : pas de la présence, mais de la continuité. Si vous pouvez tracer une conversation de bout en bout, expliquer quel state a été utilisé, et passer la main avec un contexte propre, vous avez une architecture citable et défendable. Sinon, vous avez juste trois points d'entrée vers la confusion. Et en B2B, la confusion est chère : elle génère des tickets, des abandons, et des escalades inutiles. C'est pour ça qu'on la traite comme une architecture, pas comme un widget à coller.

FAQ

Questions frequentes

Faut-il adapter le ton par canal ?+

Souvent oui. Mobile et messageries demandent plus de concision. Le ton peut rester cohérent, mais les formats doivent s'adapter.

Doit-on partager le même RAG partout ?+

Oui pour la base, mais avec des filtres et permissions par canal. Un canal public ne doit pas donner accès aux mêmes sources qu'un canal authentifié.

Quel est le plus gros risque omnicanal ?+

La fuite de données (mauvais RBAC) et la perte de contexte (pas de conversation_id/state). Ce sont les deux causes principales de frustration.

Sources et references

1. [1]Meta, “WhatsApp Business Platform - Webhooks”.
2. [2]Microsoft Learn, “Build conversational bots for Microsoft Teams”.
3. [3]OpenTelemetry, “Traces concepts”.