Sécurité et identifiants
La section Sécurité gère les accès aux services externes et les accès à l'API. Elle apparaît dans le menu à partir du plan Business. Sur un plan inférieur, la limite porte sur le menu : voir la section Navigation du Tableau de bord.
Les pages
| Page | Adresse | Rôle |
|---|---|---|
| Conformité EU | /compliance-dashboard | Matrice de conformité (voir Analytique) |
| Identifiants | /credentials | Secrets de connexion aux services externes |
| Variables | /variables | Valeurs réutilisables dans les workflows |
| Clés API | /api-keys | Création et révocation de clés API (aucune route ne les accepte encore, voir plus bas) |
| Webhooks | /webhooks | Adresses notifiées, et réception des fournisseurs |
Identifiants
Un identifiant contient les informations de connexion à un service (Odoo, n8n, Matomo, un fournisseur de paiement, entre autres). La page est un catalogue de cartes rangées en 21 catégories (IA, ERP/CRM, Automatisation, Paiements EU, Données EU, Sécurité, Connecteurs, entre autres). Chaque carte a ses propres champs. Les cartes OAuth portent un choix de portées et une durée de jeton.
Comment un secret est gardé
- Il est chiffré en AES-256-GCM dans la base, avec une clé propre à chaque identifiant. La clé dérive d'une clé racine « au repos » (variable
AT_REST_ENCRYPTION_KEY) distincte du secret de session quand elle est fournie. Sans elle, le secret de session sert de racine. Le détail des clés est dans Variables d'environnement. - La valeur en clair ne revient jamais dans une réponse de l'API : la liste montre un masque.
- À la modification, la page recharge l'identifiant sans ses valeurs secrètes : chaque champ secret est remplacé par un marqueur avant d'entrer dans l'écran. Les champs secrets sont masqués, avec un bouton pour les afficher le temps de la saisie.
- Un identifiant est lié à un espace de travail. Vous ne voyez que ceux de vos espaces.
Comment un connecteur le lit
Quand un connecteur appelle un service, le serveur déchiffre l'identifiant de l'organisation qui fait la requête, et d'elle seule. Ce mécanisme est décrit dans Conception des connecteurs MCP. Au démarrage, il peut aussi publier les identifiants d'un déploiement à locataire unique comme variables d'environnement.
OpenBao
OpenBao est optionnel. Une organisation peut y garder ses secrets de connecteurs : elle enregistre un identifiant d'AppRole nommé openbaoAppRole. Le serveur lit alors ses secrets dans le coffre, avec la priorité sur ceux de la base. Sans cet identifiant, OpenBao n'est jamais contacté. La carte « OpenBao Secrets » du catalogue sert à un client qui apporte sa propre instance à un connecteur.
Variables
La page a cinq onglets : Toutes, Système, Capture, Statiques, Runtime. Les variables système sont remplies par la plateforme et ne se modifient pas. Une valeur se masque et s'affiche d'un clic. On crée et on modifie les autres. Elles se consomment dans les workflows ; les routes correspondantes sont dans Routes des ressources.
Clés API
Une clé API se crée et se gère depuis cette page ; à ce jour aucune route de l'API ne l'accepte à la place du jeton de session (l'extracteur existe dans le code, sans route consommatrice) : un appel programmatique passe par le jeton obtenu à la connexion, décrit dans Swagger. Le formulaire demande un nom et un espace de travail. La page montre la clé une seule fois à la création, puis, dans la liste, un extrait (8 premiers et 4 derniers caractères) jusqu'au rechargement de la page, et ensuite ****. Supprimer une clé la révoque. L'extracteur prévu à cet effet attend l'en-tête X-Api-Key. Voir aussi Documentation Swagger pour l'authentification de l'API.
La clé est gardée sous forme hachée. La page n'offre ni choix de portées, ni rotation automatique.
Webhooks
La page permet de créer un webhook (nom, adresse, événements parmi 12), de l'activer, de le modifier, de le supprimer et d'envoyer un test. Les 12 événements proposés : conversation démarrée ou terminée, message reçu ou envoyé, intention détectée, transfert demandé, prospect créé, workflow démarré, terminé ou échoué, appel démarré ou terminé.
Ce qui est branché, ce qui ne l'est pas :
- Envoi de test : réel. Le serveur appelle l'adresse (avec un filtre contre les adresses internes) et note la date.
- Émission automatique des événements : non branchée. Le code qui lit la table des webhooks se limite à la gestion et à l'envoi de test.
- Livraisons récentes : aucun journal de livraison n'est enregistré.
- Régénérer le secret : répond
503 FEATURE_PENDING.
En sens inverse, le serveur reçoit les notifications de fournisseurs : paiement (Mollie, PayPlag, Adyen, Stripe, Lyra, SlimPay, Wero), LiveKit, et une entrée générique. Seul Mollie sert à la facturation de la plateforme (voir Tarification) ; les autres routes de paiement existent dans le code.
Voir aussi
- Paramètres : réglages, facturation, compte et gestion des utilisateurs
- OpenBao et secrets : le coffre de secrets optionnel d'une organisation
- Workflows : où les identifiants et variables sont consommés
- Routes des ressources : variables, identifiants et outils par l'API
- Sécurité : principes, secrets et chiffrement côté exploitation
- Architecture de confiance zéro : ce que chaque requête traverse avant d'atteindre un secret