Chatbot multi-tenants : architecture logicielle recommandée

Concevoir un chatbot WhatsApp multi-tenants — c'est-à-dire capable d'accueillir plusieurs entreprises clientes sur une infrastructure partagée — est un défi technique qui va bien au-delà du simple bot conversationnel. Isolation des données, routage des messages, sécurité, facturation, conformité réglementaire : chaque décision architecturale a des conséquences durables. Voici l'architecture logicielle que l'on recommande généralement pour un déploiement sérieux au Maroc.

Les grands principes à respecter

• Isolation stricte des données entre tenants : un client ne doit jamais accéder aux données d'un autre.
• Scalabilité horizontale : pouvoir absorber un pic de trafic sans dégradation.
• Observabilité par tenant : logs, métriques et facturation traçables individuellement.
• Conformité conformité réglementaire : localisation des données, durée de conservation, droit d'accès et d'effacement.
• Résilience : la défaillance d'un tenant ne doit pas impacter les autres.

La couche d'ingestion : webhooks Meta

Meta pousse tous les messages entrants via des webhooks HTTPS. Dans une architecture multi-tenants, plusieurs numéros WhatsApp (un par tenant, ou plusieurs par tenant) partagent une même URL de callback.

Le routage par phone_number_id

Chaque message contient un phone_number_id qui identifie le numéro destinataire. Un service de routage lit ce champ et associe le message au tenant correspondant via une table de correspondance en base. Ce service doit être ultra-rapide et hautement disponible, car un webhook non répondu dans les 20 secondes est retenté par Meta.

Signature de webhook

Toujours vérifier la signature HMAC-SHA256 fournie par Meta dans le header X-Hub-Signature-256. Cela évite qu'un attaquant injecte des messages arbitraires.

Isolation des données

Modèles possibles

• Base unique, schéma partagé, tenant_id sur chaque table : simple à opérer, mais isolation logique uniquement. Nécessite une discipline stricte au niveau applicatif.
• Base unique, schéma par tenant : meilleure isolation, mais complexité de migration accrue.
• Base par tenant : isolation forte, adaptée aux gros comptes ou aux exigences réglementaires spécifiques.

Pour la majorité des cas au Maroc, l'approche tenant_id avec des politiques Row-Level Security (par exemple sur PostgreSQL) offre le bon compromis entre simplicité et sécurité.

Le cœur conversationnel

Machine à états ou moteur d'intentions

Deux grandes approches coexistent :

• Machine à états déterministe : idéale pour des parcours structurés (prise de rendez-vous, suivi de commande, FAQ guidée).
• Moteur NLU/LLM : plus flexible, permet des conversations libres. Nécessite des guardrails pour éviter les dérives.

Beaucoup de projets combinent les deux : LLM pour comprendre l'intention, machine à états pour exécuter les actions métier.

Configuration par tenant

Chaque tenant doit pouvoir définir son propre parcours conversationnel, ses réponses, ses variables métier. Un modèle déclaratif (JSON, YAML) versionné en base est plus maintenable qu'un code custom par client.

Intégration avec les systèmes tiers

Le chatbot doit pouvoir appeler des APIs externes (CRM, ERP, plateforme e-commerce). Prévoir :

• Un système de secrets par tenant chiffré au repos (Vault, KMS).
• Une couche d'adaptateurs par type de système cible (Dynamics, Salesforce, Odoo, Shopify).
• Des timeouts stricts pour ne pas bloquer une conversation en attente d'une API lente.

Scalabilité et files d'attente

Le traitement doit être asynchrone : le webhook accepte le message et le pousse dans une file (RabbitMQ, SQS, Redis Streams). Des workers consomment la file, appliquent la logique conversationnelle et appellent la Cloud API pour répondre. Cela permet :

• D'absorber les pics sans perte.
• D'isoler les traitements lourds (appels LLM, requêtes externes).
• De rejouer facilement en cas d'erreur transitoire.

Observabilité et facturation

Chaque message doit être journalisé avec tenant_id, direction (in/out), catégorie Meta, coût estimé en MAD, latence. Un dashboard par tenant permet de suivre son usage et de justifier la facturation. Côté opérationnel, des alertes sur les taux d'erreur par tenant et par intégration évitent la dégradation silencieuse.

Conformité conformité réglementaire

Quelques exigences à intégrer dès la conception :

• Consentement stocké par contact avec date, source, canal.
• Durée de conservation configurable par tenant (par ex. 12 ou 24 mois).
• API interne pour l'export et l'effacement des données d'un contact sur demande.
• Localisation des données conforme aux engagements pris par le tenant auprès de la réglementation applicable.

Conclusion

Un chatbot multi-tenants réussi n'est pas un simple bot répliqué N fois — c'est une plateforme. Les choix d'isolation, de routage, de scalabilité et de conformité font la différence entre un produit qui tient à quelques dizaines de clients et un produit capable d'en supporter des centaines dans la durée. Investir dans une architecture propre dès le départ évite les refontes douloureuses une fois la traction acquise.