> ## Documentation Index > Fetch the complete documentation index at: https://docs.ouraicalling.com/llms.txt > Use this file to discover all available pages before exploring further. # Locataires et marque blanche > La hiérarchie des rôles, les espaces de travail en marque blanche et l'usurpation d'identité La plateforme est multi-tenant par conception : les agences et revendeurs (« locataires ») exploitent leur propre instance de marque sur leur propre domaine, avec leurs propres utilisateurs, plans et tarifs. ## Hiérarchie des rôles ```text theme={null} Platform admin (the operator) ├── Tenants (white-label customers: own domain & branding) │ └── Tenant users (the tenant's end customers) └── Direct users (no tenant; use the main domain) ``` * **Une seule connexion pour tous** — le rôle détermine ce que voit chaque utilisateur. * Les **administrateurs de plateforme** gèrent l'ensemble des utilisateurs, des locataires, des plans de plateforme et le catalogue de modèles depuis `/admin`. * **Les administrateurs de locataire** (propriétaire ou administrateur d'un locataire) disposent d'un espace d'administration dédié : tableau de bord avec les KPI du locataire, historique des appels de leurs utilisateurs, gestion des utilisateurs, modèles de prompt, plans, facturation, migration de données et paramètres de marque. ## Marque blanche L'espace de travail d'un locataire fonctionne entièrement sous sa propre identité : * **Domaine** — l'application, la connexion, l'API (`/api/v1`) et même le [point de terminaison MCP](/api/mcp) tournent sous le domaine du locataire. * **Image de marque** — logo, favicon, couleurs et nom de l'application ; appliqués à l'application, à l'onglet du navigateur, aux pages de connexion et d'inscription, ainsi qu'aux écrans de consentement OAuth. Les domaines des locataires utilisent leur propre favicon et reviennent à celui de la plateforme si aucun n'est configuré. * **E-mail d'assistance** — affiché aux utilisateurs du locataire. * **Plans et tarifs** — les locataires définissent leurs propres plans et tarifs ; voir [Plans et limites](/admin/plans-and-limits) et [Stripe Connect](/admin/stripe). L'administration de la marque blanche est conditionnée par une option de plan de plateforme (`whitelabel_enabled`), un module complémentaire de plateforme souscrit (`feature_key=whitelabel`), une clause d'antériorité Domaine/Connect, ou une dérogation au niveau de l'espace de travail administrateur. Les plans de revente des locataires ne peuvent ni accorder ni revendre la marque blanche. ### Vérification du domaine personnalisé Ajoutez le nom d'hôte complet dans **Administration locataire → Paramètres**, par exemple `app.famulor.io`. La plateforme le rattache alors à sa couche de routage et vérifie deux exigences indépendantes : 1. **Propriété** — si une vérification est demandée, publiez l'enregistrement TXT exact indiqué sur la page des paramètres. 2. **DNS et TLS** — publiez l'enregistrement A recommandé pour un domaine racine (apex), ou l'enregistrement CNAME pour un sous-domaine. La page lit la configuration DNS en direct et n'active le domaine qu'une fois le routage correct et le certificat TLS émissible. Utilisez **Vérifier le DNS** après chaque modification. La propagation DNS peut prendre du temps. Le statut n'est jamais déduit d'une simple case cochée : la plateforme revérifie la configuration en direct et ne synchronise `custom_domain_verified` que lorsque les deux vérifications réussissent. Supprimer le domaine le détache et désactive immédiatement le routage des locataires basé sur l'hôte. Ce même cycle de vie est accessible via `GET`, `POST` et `DELETE /api/v1/custom-domain`, avec `POST /api/v1/custom-domain/verify` pour relancer une vérification, ainsi que via les outils MCP correspondants. ## Comptes gratuits Les locataires peuvent autoriser les **inscriptions gratuites** avec des limites par défaut configurables (par exemple 1 assistant, 5 campagnes, 1 numéro) et un tarif à la minute pour un usage à la consommation. Le même mécanisme existe au niveau de la plateforme pour les utilisateurs directs. Une inscription sur le domaine d'un locataire crée automatiquement l'appartenance à ce locataire avec ces valeurs par défaut. ## Usurpation d'identité (« Vue utilisateur ») Les administrateurs peuvent se connecter \*\*sous l'identité d'\*\*un utilisateur pour voir exactement ce qu'il voit — c'est le cœur du workflow de support : * Les administrateurs de plateforme peuvent usurper l'identité de n'importe quel utilisateur ; les administrateurs de locataire, uniquement celle des utilisateurs de leur propre locataire. * Une bannière affiche en permanence « Vous êtes connecté en tant que X — retour à l'administration ». * Chaque usurpation d'identité est **journalisée dans l'audit**. ## Modèles de prompt Les administrateurs de plateforme gèrent les modèles **globaux** dans `/admin/prompt-templates` (visibilité : tous les espaces de travail, ou uniquement les espaces de travail racine de la plateforme). Les administrateurs de locataire gèrent les modèles d'espace de travail dans `/tenant-admin/prompt-templates` — visibles par les membres de cet espace de travail ainsi que par les espaces de travail des clients du revendeur. Les utilisateurs finaux ouvrent **Choisir un modèle** lors de la création d'un assistant ou depuis la carte Prompt système (mode Prompt) : ils filtrent par langue / thème / branche, prévisualisent, puis appliquent (copie à la sélection dans `system_prompt` et, en option, dans `first_message`). Même liste que : `GET /api/v1/prompt-templates` et l'outil MCP `list_prompt_templates`. ## Migration de données Les administrateurs de locataire peuvent transférer des ressources (assistants, outils, bases de connaissances, numéros) **d'un utilisateur à un autre** au sein du locataire — utile lorsqu'une agence construit sur un utilisateur de préproduction avant de transmettre le compte au client. Les administrateurs de plateforme peuvent le faire à l'échelle de toute la plateforme.