Skip to main content
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

  • 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 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 et Stripe Connect.
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.