Choisir votre modèle de déploiement Mandraki

Pour la plupart des logiciels, « où il s’exécute » est une réponse d’une ligne dans le document d’approvisionnement. Pour les outils de collaboration utilisés par les organisations sous pression réglementaire — fournisseurs de défense, administrations régionales, ministères, réseaux de santé — c’est la question qui décide si l’outil peut être adopté du tout.

Mandraki est livré en quatre modèles de déploiement. Même produit, mêmes protocoles, même modèle de sécurité — limite opérationnelle différente. Cet article explique ce que signifie chaque modèle en pratique et comment choisir celui qui vous convient.

Pourquoi l’isolation du déploiement est une question distincte de la résidence des données

Il est tentant de réduire la question à « mes données sont-elles dans l’UE ». La résidence des données importe, mais ce n’est pas la même chose que l’isolation du déploiement. Un SaaS multi-tenant partagé hébergé à Francfort colocalise toujours vos données, vos clés et vos journaux d’audit avec ceux de tous les autres sur la même infrastructure physique. Pour de nombreuses organisations, c’est acceptable ; pour d’autres — particulièrement celles dont la classification des données ou le cadre d’accréditation interdit explicitement l’infrastructure partagée — ce ne l’est pas.

L’isolation du déploiement répond à une question d’approvisionnement différente : combien du substrat opérationnel est partagé avec d’autres clients et qui y a accès. Les quatre modèles de déploiement Mandraki échangent la complexité opérationnelle contre l’isolation, et la bonne réponse dépend de quel côté de cet échange se trouve votre cadre d’accréditation.

Les quatre modèles

1. SaaS multi-tenant partagé

Notre offre hébergée sur app.mandraki.cloud. Le code applicatif, les bases de données, le stockage d’objets et le routage médias SFU sont partagés entre les organisations, avec isolement logique au niveau organisationnel (chaque ligne de chaque table est scoped à un ID d’organisation, et les gardes d’accès l’appliquent à chaque requête). Les clés, les journaux d’audit et les enregistrements sont chiffrés avec des hiérarchies de clés par organisation — jamais mélangés en texte clair — mais ils se trouvent dans une infrastructure partagée.

Choisissez ceci quand : votre classification des données ne nécessite pas d’isolement physique, vous voulez zéro frais généraux opérationnels, et vous êtes à l’aise avec la séparation logique soutenue par le chiffrement et les gardes d’accès. C’est ainsi que fonctionnent la plupart des clients commerciaux et de nombreuses équipes du secteur public plus petites.

2. Instance single-tenant dédiée

Nous déployons une pile Mandraki complète — API, frontend, SFU, couche de données, console de gestion — dans une infrastructure réservée à votre organisation. Aucun autre tenant ne partage les serveurs d’application, la base de données, le stockage d’objets ou la hiérarchie de clés de chiffrement. Nous l’exploitons ; vous signez l’accord de traitement des données ; tout s’exécute toujours sur l’infrastructure hyperscale européenne.

Choisissez ceci quand : votre cadre d’accréditation exige explicitement une infrastructure single-tenant, vous voulez une limite d’audit dédiée, ou vous anticipez des caractéristiques de performance par tenant (par exemple, une administration nationale avec une large base d’utilisateurs) qui justifient le coût opérationnel. Courant pour les déploiements de fournisseurs de défense et de gouvernement central.

3. Votre propre compte cloud

Nous déployons Mandraki dans une infrastructure que vous contrôlez. Vous possédez le compte cloud ; nous installons, configurons et exploitons la plateforme en son sein. Votre équipe de sécurité conserve le levier opérationnel ultime — vous pouvez auditer notre accès, restreindre l’accès réseau sortant et appliquer vos contrôles de compte cloud existants (journalisation du périmètre, IAM, séquestre des clés) sans que nous soyons en travers du chemin.

Choisissez ceci quand : votre organisation dispose d’un programme de souveraineté cloud qui nécessite que tous les charges de travail de production se trouvent dans des comptes sous votre contrôle contractuel direct avec le fournisseur de cloud — courant pour les ministères disposant d’un cadre cloud souverain établi, ou pour les organisations soumises à une doctrine opérationnelle qui traite la propriété du compte cloud comme la limite de confiance.

4. On-premises

La pile Mandraki s’exécute à l’intérieur de vos propres centres de données ou cloud privé, derrière votre pare-feu. Le produit est le même ; seul le substrat change. Les mises à jour sont livrées sous forme de versions signées ; nous fournissons le support opérationnel, les runbooks et un cadence de mise à jour ; votre équipe d’exploitation possède la boîte.

Choisissez ceci quand : votre environnement est isolé de manière hermétique, votre cadre de classification interdit toute présence cloud externe, ou votre doctrine opérationnelle exige que l’ensemble de la pile — code, données, clés, télémétrie — se trouve dans votre périmètre physique. Courant dans la défense, les travaux adjacents au renseignement et certains opérateurs d’infrastructure critique.

Comment choisir

En pratique, la réponse vient de trois questions :

1. Qu’exige votre cadre d’accréditation ou votre classification des données ? Si le cadre nomme « single-tenant » ou « dédié » comme exigence, le choix est déjà fait. S’il parle uniquement en termes de « résidence des données », le SaaS partagé est généralement suffisant.

2. Où votre équipe de sécurité trace-t-elle la limite de confiance ? Certains traitent le compte cloud comme la limite (alors « votre cloud » est le bon modèle) ; certains traitent le périmètre physique comme la limite (alors on-prem est le bon modèle) ; certains sont à l’aise avec les limites logiques et cryptographiques sur l’infrastructure partagée (alors SaaS est correct).

3. Quels frais généraux opérationnels pouvez-vous absorber ? Le SaaS partagé est zéro. Le single-tenant dédié est faible — nous l’exploitons. Votre cloud est modéré — vous et nous partageons la carte opérationnelle. On-prem est significatif et nécessite une équipe interne pour exploiter la plateforme aux côtés de tout le reste.

Vous ne devez pas vous engager dans un modèle au jour un. De nombreux clients commencent par SaaS partagé pour un pilote, puis passent à dédié ou votre-cloud à mesure que le déploiement se durcit en un système de production régulé. Le modèle de données est portable entre les déploiements ; la migration est engineered, pas improvisée.

Ce qui reste identique dans les quatre

Le produit est identique. La posture de chiffrement de bout en bout est identique. Les choix de protocoles — MLS pour la messagerie, SFrame pour les médias, WebRTC sur mediasoup, chiffrement d’enveloppe trois couches avec BYOK optionnel — sont identiques. La journalisation d’audit, les gardes d’accès, le moteur de politique, les points de terminaison d’export de données : identiques.

Ce qui change, c’est la limite opérationnelle, qui a les mains sur l’infrastructure et où les données vivent physiquement. C’est exactement la surface dont se soucient l’approvisionnement, l’accréditation et la doctrine opérationnelle — et exactement la surface où la plupart des vendeurs de collaboration n’ont rien à offrir au-delà d’une console SaaS partagée.

Si votre organisation évalue Mandraki et a besoin d’aide pour choisir le bon modèle de déploiement, nous serions heureux de le parcourir avec vos équipes de sécurité et d’approvisionnement. La bonne réponse n’est rarement évidente à partir du matériel marketing ; elle émerge généralement d’une conversation d’une demi-journée sur vos contraintes.