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

Le modèle mutualisé rend le logiciel en tant que service (SaaS) économiquement viable. Au lieu de déployer une instance distincte de l'application pour chaque client, un seul déploiement les dessert tous, et l'isolation entre eux est assurée par le logiciel. La facilité de mise à jour, la charge opérationnelle et le coût par client s'en trouvent considérablement réduits. En contrepartie, l'isolation devient une propriété à construire et à préserver, et non plus une caractéristique intrinsèque du matériel.

Pour une plateforme de centre de contact, les enjeux sont particulièrement élevés, car les données concernées sont les enregistrements d'appels, les listes de contacts clients, les enregistrements de consentement et les listes d'exclusion. Un prestataire BPO gérant plusieurs clients sur une même plateforme a l'obligation contractuelle, et souvent réglementaire, de les maintenir séparés ; une fuite de données est donc considérée non pas comme un simple désagrément, mais comme un incident grave.

Où l'isolement devrait être appliqué

L'implémentation courante la plus faible place la limite dans le code applicatif : chaque requête est filtrée par locataire, et la correction repose sur la mémorisation systématique de chaque développeur. Ce système fonctionne jusqu'à ce qu'une requête échoue, et l'erreur n'est détectée que lorsqu'une donnée inappropriée est consultée. L'approche plus robuste intègre l'application de la politique de confidentialité à la base de données ; ainsi, la politique est liée aux données et non au code qui les lit, et une requête omettant le filtre de locataire ne renvoie aucun résultat. Lors de l'évaluation d'une plateforme, la question pertinente n'est pas de savoir si les locataires sont isolés, mais à quel niveau.

Ce qui doit varier selon le locataire

• Données et utilisateurs. Campagnes, contacts, enregistrements et comptes, délimités de sorte qu'un utilisateur n'existe que dans son locataire.
• Configuration de conformité. Listes d'exclusion, fenêtres d'appel et règles de consentement, car les locataires opèrent sous des régimes différents.
• Rétention. La conservation des enregistrements et des transcriptions est régie par la propre politique de chaque locataire, avec possibilité de blocage légal.
• Nombres. Un numéro d'appelant appartenant exclusivement à un seul locataire, et une plage de numéros de poste qui n'entre pas en conflit avec celle d'un autre locataire.
• Image de marque et langage. L'interface visible par les utilisateurs de chaque locataire, y compris leur langue par défaut.
• Facturation et comptage. L'utilisation est imputable à chaque locataire plutôt que d'être regroupée en un seul total.

Comment DialerBee met en œuvre le multi-tenant

DialerBee architecture multi-locataires Ce système offre à chaque client des données isolées, protégées par une sécurité au niveau des lignes PostgreSQL au niveau de la base de données. Il propose également des règles de conformité indépendantes (listes d'opposition au démarchage téléphonique, horaires d'appel et suivi du consentement), des enregistrements d'appels séparés avec stockage dédié, conservation et mise sous séquestre légale indépendantes, une facturation par client avec suivi de l'utilisation, des minutes et des postes distincts, un contrôle d'accès basé sur les rôles (agents et superviseurs affectés à leur client), un paramétrage de l'IA par client et un provisionnement des clients en quelques minutes via le portail d'administration ou l' API. Il est disponible en 11 langues, avec des langues par défaut pour chaque client.

La limite s'étend à l'ensemble de la plateforme et ne s'arrête pas à la base de données. Chaque tableau de bord et chaque rapport dans analytique Le périmètre d'accès est limité au locataire actuel, de sorte que les clients BPO ne voient que leurs propres données tandis que les propriétaires de la plateforme peuvent accéder aux analyses inter-locataires. Les limites entre locataires sont appliquées au niveau de la base de données. L'identification de l'appelant est exclusive à un seul locataire, ce qui empêche qu'un numéro dont vous êtes responsable apparaisse sur les appels d'un autre utilisateur. Chaque locataire dispose de ses propres pools d'identification de l'appelant avec des règles de rotation et de reporting isolées. Les données de transcription sont stockées avec une isolation par locataire grâce à une sécurité au niveau des lignes, la durée de conservation étant configurable pour chaque locataire. marque blanche Lors des déploiements, un administrateur partenaire est propriétaire des locataires qu'il crée, et l'assistant d'intégration définit la propre plage d'extensions et les propres identifiants d'appelant de chaque locataire, car les valeurs par défaut entrent en conflit et une ligne partagée n'est pas un identifiant d'appelant.

Foire aux questions

Quelle est la différence entre un modèle multi-locataire et un modèle mono-locataire ?

Dans un déploiement mono-locataire, chaque client dispose de sa propre instance du logiciel et souvent de sa propre infrastructure. Dans un déploiement mutualisé, 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. La mutualisation est moins coûteuse à exploiter et à mettre à niveau ; le mono-locataire offre une séparation physique, mais à un coût beaucoup plus élevé par client.

Qu'est-ce que la sécurité au niveau des lignes ?

Une fonctionnalité de base de données qui associe une politique à une table afin qu'une requête ne renvoie que les lignes auxquelles le locataire actuel est autorisé à accéder. C'est important car l'alternative, qui consiste à filtrer par locataire dans chaque requête de l'application, repose sur la mémorisation systématique de cette politique par chaque développeur. L'application de cette politique au niveau de la base de données garantit qu'une requête qui oublie le filtre ne renverra rien au lieu de tout renvoyer.

Le terme « mutualisation » signifie-t-il que mes données sont mélangées à celles d'autres clients ?

Cela signifie que les données sont stockées dans une infrastructure partagée avec des limites strictes, et non que quiconque 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 solution moins efficace qu'une isolation appliquée par la base de données.

Pourquoi chaque locataire a-t-il besoin de sa propre plage de numéros de poste et de son propre identifiant d'appelant ?

En effet, les configurations par défaut peuvent entrer en conflit. Deux locataires configurés avec la même plage de numéros ou pointant vers la même ligne téléphonique génèrent des erreurs d'acheminement des appels et des identités d'appelant attribuées à la mauvaise entreprise. Attribuer à chaque locataire sa propre plage de numéros et ses propres numéros lors de la configuration permet d'éviter ce type de problème, souvent difficile à diagnostiquer ultérieurement.

Quelles options devraient être configurables par locataire ?

Tout élément qui diffère d'une entreprise à l'autre utilisant la plateforme, et dans un centre de contact, cela concerne la plupart des aspects : 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 paramètre uniquement global finira forcément par ne pas convenir à certains utilisateurs.

Termes associés : plateforme de centre de contact en marque blanche, centre de contact BPO, gestion du consentement, identification de l'appelant et présence locale et DID.