Qu'est-ce qu'une architecture multi-tenant ?

Le multi-tenant est l'architecture qui rend le logiciel en tant que service (SaaS) économiquement viable. Au lieu de déployer une copie distincte de l'application pour chaque client, un seul déploiement les sert tous, et la séparation entre eux est assurée par le logiciel. Les mises à jour, la charge d'exploitation et le coût par client s'en trouvent considérablement améliorés. La contrepartie : l'isolation devient une propriété qu'il faut construire et défendre, plutôt qu'une chose que le matériel offre gratuitement.

Pour une plateforme de centre de contact, l'enjeu est particulièrement élevé, car les données concernées sont des enregistrements d'appels, des listes de contacts clients, des registres de consentement et des listes d'exclusion. Un BPO qui gère des clients concurrents sur une même plateforme a l'obligation contractuelle, et souvent réglementaire, de les séparer ; une fuite n'est pas un désagrément mais un incident.

Où appliquer l'isolation

L'implémentation courante la plus faible place la frontière dans le code applicatif : chaque requête filtre par tenant, et l'exactitude dépend de chaque développeur qui doit s'en souvenir à chaque fois. Cela fonctionne jusqu'au jour où une requête l'oublie, et rien ne révèle l'erreur avant que quelqu'un ne voie des données qu'il ne devrait pas voir. L'approche plus robuste fait appliquer la règle par la base de données : la politique est attachée aux données plutôt qu'au code qui les lit, et une requête qui omet le filtre de tenant ne renvoie rien au lieu de tout renvoyer. Pour évaluer une plateforme, la bonne question n'est pas de savoir si les tenants sont isolés, mais à quel niveau.

Ce qui doit varier par tenant

• Données et utilisateurs. Campagnes, contacts, enregistrements et comptes, cloisonnés pour qu'un utilisateur n'existe que dans son tenant.
• Configuration de conformité. Listes d'exclusion, plages d'appel et règles de consentement, car les tenants relèvent de régimes différents.
• Conservation. Conservation des enregistrements et des transcriptions selon la politique propre à chaque tenant, avec gel juridique (legal hold) disponible.
• Numéros. Une identité d'appelant appartenant exclusivement à un tenant, et une plage d'extensions qui n'entre pas en collision avec celle d'un autre.
• Image de marque et langue. L'interface que voient les utilisateurs de chaque tenant, y compris leur langue par défaut.
• Facturation et mesure de consommation. Une consommation attribuable à chaque tenant plutôt que regroupée dans un total unique.

Comment DialerBee met en œuvre le multi-tenant

Chez DialerBee, le L'architecture multi-tenant offre à chaque tenant des données isolées, garanties par la sécurité au niveau des lignes (row-level security) de PostgreSQL dans la base de données ; des règles de conformité indépendantes couvrant les listes d'opposition, les horaires d'appel et le suivi du consentement ; des enregistrements d'appels séparés avec stockage par tenant ; une conservation et un gel juridique indépendants ; une facturation par tenant qui suit séparément l'usage, les minutes et les postes ; un contrôle d'accès basé sur les rôles qui cantonne agents et superviseurs à leur tenant ; un réglage de l'IA par tenant ; et la création d'un tenant en quelques minutes via le portail d'administration ou l'API. Le tout est disponible dans 11 langues avec une langue par défaut par tenant.

La frontière se prolonge dans le reste de la plateforme au lieu de s'arrêter à la base de données. Chaque tableau de bord et chaque rapport de l' analyses unifiées est limité au tenant courant : les clients d'un BPO ne voient que leurs propres données, tandis que les propriétaires de la plateforme peuvent accéder à des analyses inter-tenants, et les frontières entre tenants sont appliquées au niveau de la base de données. La propriété d'un numéro présenté est exclusive à un tenant — c'est ce qui empêche un numéro dont vous êtes responsable d'apparaître sur les appels de quelqu'un d'autre — et chaque tenant dispose de ses propres pools de numéros présentés avec règles de rotation et reporting isolés. Les transcriptions sont stockées avec une isolation par tenant via la sécurité au niveau des lignes, avec une durée de conservation configurable par tenant. Dans les déploiements la marque blanche , un administrateur partenaire est propriétaire des tenants qu'il crée, et l'assistant d'intégration attribue à chaque tenant sa propre plage d'extensions et ses propres numéros présentés, car les valeurs par défaut entrent en collision et un trunk partagé n'est pas un numéro présenté.

Questions fréquentes

Quelle est la différence entre multi-tenant et single-tenant ?

En déploiement single-tenant, chaque client dispose de sa propre instance du logiciel et souvent de sa propre infrastructure. En déploiement multi-tenant, les clients partagent l'infrastructure et le code, et sont séparés par l'application et la base de données plutôt que par des copies distinctes. Le multi-tenant est moins coûteux à exploiter et à mettre à jour ; le single-tenant offre une séparation physique à un coût par client bien plus élevé.

Qu'est-ce que la sécurité au niveau des lignes (row-level security) ?

Une fonction de base de données qui attache une politique à une table, de sorte qu'une requête ne peut renvoyer que les lignes que le tenant courant est autorisé à voir. C'est important, car l'alternative — filtrer par tenant dans chaque requête de l'application — dépend de chaque développeur qui doit s'en souvenir à chaque fois. L'appliquer au niveau de la base de données signifie qu'une requête qui oublie le filtre ne renvoie rien au lieu de tout renvoyer.

Le multi-tenant signifie-t-il que mes données sont mélangées à celles d'autres clients ?

Cela signifie qu'elles sont stockées sur une infrastructure partagée avec des frontières garanties, pas que quelqu'un d'autre peut y accéder. La question pratique à poser à un fournisseur n'est pas de savoir si les tables sont partagées, mais où l'isolation est appliquée. Une isolation implémentée uniquement dans le code applicatif est une réponse plus faible qu'une isolation appliquée par la base de données.

Pourquoi chaque tenant a-t-il besoin de sa propre plage d'extensions et de ses propres numéros présentés ?

Parce que les valeurs par défaut entrent en collision. Deux tenants créés avec la même plage d'extensions ou pointant vers le même trunk produisent des appels mal routés et une identité d'appelant qui appartient à la mauvaise entreprise. Attribuer à chaque tenant sa propre plage et ses propres numéros dès sa création évite toute une catégorie de problèmes désagréables à diagnostiquer après coup.

Que doit-on pouvoir configurer par tenant ?

Tout ce qui diffère d'une entreprise utilisatrice à l'autre, c'est-à-dire, dans un centre de contact, presque tout : règles de conformité, horaires d'appel, listes d'exclusion, durées de conservation, langue par défaut, image de marque, numéros et facturation. Un réglage qui ne peut être que global finira par être faux pour quelqu'un.

Termes associés : plateforme de centre de contact en marque blanche, centre de contact BPO, gestion du consentement, numéro présenté et présence locale et SDA (DID).