Architecture mutualisée : pourquoi les composeurs automatiques en ont besoin

Si vous gérez une entreprise d'externalisation de processus métier (BPO), une société de revente ou toute autre structure desservant plusieurs clients sur la même plateforme de numérotation automatique, la mutualisation n'est pas un simple atout. C'est le fondement même de votre activité.

Que signifie réellement la multilocation ?

Le multitenant signifie que plusieurs clients indépendants (locataires) partagent la même infrastructure logicielle tout en bénéficiant de données, de configurations et de règles de conformité totalement isolées. Chaque locataire fonctionne comme s'il disposait de son propre système dédié, mais la plateforme sous-jacente est partagée.

Le mot clé est isolationPas de séparation. Pas de filtrage. Isolation.

Pourquoi l'isolement est important

Protection des données. Les contacts, les enregistrements d'appels, les données des agents et les résultats de campagne du client A doivent être invisibles pour le client B. Non seulement masqués, mais aussi prouvés inaccessibles. Si un développeur commet une erreur dans une requête, la base de données doit empêcher tout accès aux données entre clients.

Indépendance en matière de conformité. Le client A peut être soumis à la réglementation TDRA (Émirats arabes unis), le client B à la réglementation CITC (Arabie saoudite) et le client C à la réglementation TCPA (États-Unis). Chaque client doit définir ses propres règles de conformité, listes d'opposition au démarchage téléphonique, plages horaires d'appel et système de suivi du consentement. Une infraction commise par un client n'a aucune incidence sur les autres.

Isolation de l'enregistrement. Les enregistrements d'appels constituent les données les plus sensibles d'un centre de contact. Les enregistrements de chaque client doivent être stockés dans des espaces de stockage isolés, avec des contrôles d'accès spécifiques à chaque client. Une URL signée pour l'enregistrement du client A ne doit jamais fonctionner pour le client B.

Isolation de la facturation. Chaque locataire dispose de son propre nombre d'agents, de ses propres indicateurs d'utilisation et de son propre cycle de facturation. Les données de facturation doivent être exactes pour chaque locataire, sans aucune contamination croisée.

La mauvaise approche : le filtrage au niveau de l’application

De nombreux numéroteurs implémentent la « multi-location » avec une simple OÙ tenant_id = ? Un filtre est intégré au code de leur application. Chaque requête ajoute ce filtre. Cela fonctionne… jusqu’à ce que quelqu’un l’oublie.

Les problèmes :

• Un seul filtre manqué = fuite de données entre locataires
• Les requêtes complexes avec jointures sont faciles à mal interpréter.
• Les requêtes d'agrégation (rapports, tableaux de bord) sont particulièrement risquées.
• Il n'y a pas de filet de sécurité lorsque l'application commet une erreur.

Le filtrage au niveau de l'application n'est pas une isolation. C'est un filtrage approximatif qui repose sur la fiabilité absolue de chaque développeur, pour chaque requête et dans chaque portion de code. Ce n'est pas suffisant.

La bonne méthode : l’isolation au niveau de la base de données

DialerBee utilise la sécurité au niveau des lignes (RLS) de PostgreSQL comme couche de défense en profondeur. Voici comment cela fonctionne :

1. Chaque table appartenant au locataire possède une tenant_id column
2. Les politiques RLS sont activées et FORCÉES sur chaque table locataire
3. Au début de chaque transaction de base de données, nous configurons SET LOCAL app.current_tenant_id = :tid
4. La base de données elle-même filtre chaque requête (SELECT, INSERT, UPDATE, DELETE) afin de ne renvoyer que les lignes correspondant au locataire actuel.
5. L'utilisateur de l'application ne dispose pas de l'autorisation BYPASSRLS ; même le SQL brut ne peut échapper au filtre.

Cela signifie que même si le code de l'application contient un bug (clause WHERE manquante, jointure incorrecte, agrégation sans regroupement), la base de données empêche l'accès aux données entre locataires. Le filtre de l'application constitue la première ligne de défense. La sécurité au niveau des lignes (RLS) sert de filet de sécurité.

Test d'isolement

Affirmer l'isolation ne suffit pas. Il faut le prouver. DialerBee effectue des tests d'isolation adverses sur chaque point de terminaison d'API :

1. Le locataire A crée une ressource (contact, campagne, enregistrement, etc.).
2. Le locataire B tente d'effectuer des opérations GET, PATCH et DELETE sur cette ressource.
3. Toute tentative doit renvoyer une erreur 404 (page introuvable), jamais une erreur 403 (accès interdit).

Pourquoi une erreur 404 au lieu d'une erreur 403 ? Parce que l'erreur 403 (« autorisation insuffisante ») confirme l'existence de la ressource. L'erreur 404 (« ressource introuvable ») ne fournit aucune information. Le locataire B ne devrait même pas savoir que la ressource existe.

Ces tests sont exécutés en intégration continue à chaque modification du code. Si un test échoue, le code n'est pas fusionné.

Ce que les partenaires devraient exiger

Si vous évaluez un numéroteur pour une utilisation en marque blanche ou par un revendeur, posez-vous les questions suivantes :

• L'isolation des locataires est-elle appliquée au niveau de la base de données ou seulement dans le code de l'application ?
• Pouvez-vous me montrer la suite de tests d'isolation adverses ?
• Que se passe-t-il si une requête omet accidentellement le filtre de locataire ?
• Les enregistrements d'appels sont-ils stockés dans des chemins isolés pour chaque locataire ?
• Une infraction au règlement commise par un locataire peut-elle affecter un autre locataire ?
• Si je crée un locataire via le portail partenaire, est-il immédiatement isolé de tous les autres locataires ?

Si la réponse à l'une de ces questions est vague, continuez vos recherches. Une architecture multi-tenant mal conçue est pire que l'absence d'architecture multi-tenant, car elle donne une fausse impression de sécurité.