Isolé par défaut. Auditable par conception.
Chaque espace de travail est cloisonné au niveau de la base de données grâce à la sécurité au niveau des lignes de Postgres — FORCE + WITH CHECK sur chaque table dépendant d’un locataire — pour qu’un locataire ne puisse jamais lire, écrire, ni même compter les données d’un autre. Les rôles, les secrets, le MFA et un journal d’audit complet sont des propriétés de ce moteur, pas des lignes sur un devis — ils sont identiques sur un espace de travail d’essai et sur Enterprise.
Sécurité au niveau des lignes, pas des promesses applicatives
Le multi-tenant fait correctement : l’isolation est une garantie de la base de données, pas un filtre que votre code doit se souvenir d’appliquer. Chaque table dépendant d’un locataire porte une politique FORCE + WITH CHECK liée au locataire courant — pour que la frontière tienne même quand le code applicatif ne le fait pas.
- FORCE ROW LEVEL SECURITY + WITH CHECK sur chaque table dépendant d’un locataire — pas un indicateur optionnel qu’un développeur peut oublier.
- 58 tables portent la frontière d’isolation au niveau du moteur de base de données, pas dans le middleware applicatif.
- Une clause WHERE manquante, une requête qui fuit, ou un bug dans le code applicatif ne peuvent toujours pas renvoyer les lignes d’un autre locataire.
- Les comptes de service et les tâches de fond s’exécutent dans le même jeu de politiques — il n’existe aucun chemin de contournement privilégié.
Secrets scellés au repos, clés que vous pouvez faire tourner
Aucun identifiant ne repose sur le disque sous une forme lisible. Les clés API ne sont stockées que sous forme d’empreinte SHA-256 à sens unique : il n’y a donc rien à voler. Les jetons OAuth et les identifiants de connecteurs sont chiffrés avec Fernet avant d’être écrits, déchiffrés uniquement en mémoire par le service qui en a besoin, et limités en portée pour qu’un seul identifiant compromis ne compromette pas l’espace de travail.
- Les clés API sont stockées sous forme d’empreinte SHA-256 à sens unique — affichées une seule fois à la création, jamais récupérables depuis la base de données.
- Les secrets ne sont déchiffrés qu’en mémoire, à la demande, par le service qui en a besoin — jamais consignés en clair.
- Les clés sont limitées en portée et rotatives, pour qu’un identifiant compromis puisse être révoqué sans toucher au reste de votre espace de travail.
- Les jetons OAuth et les secrets de connecteurs (Mailjet, webhooks) sont chiffrés avec Fernet au repos, avec une clé rotative.
Ce que votre équipe sécurité va demander
Les contrôles qui transforment un pilote en déploiement — des propriétés du moteur sur lequel tourne chaque espace de travail, pas un forfait de sécurité à négocier séparément.
TOTP à deux facteurs pour les utilisateurs, OTP par e-mail pour les opérateurs, plus une vérification d’e-mail obligatoire à l’inscription.
Chaque changement significatif est enregistré — qui a fait quoi, quand, et sur quelle fiche — exportable pour examen.
Les rôles propriétaire, admin, gestionnaire, membre et lecteur verrouillent chaque action, avec une console d’administration dédiée aux utilisateurs et permissions.
Les comptes et les départs restent gouvernés par votre IdP grâce à SCIM. L’authentification unique SAML / OIDC est disponible sur demande — parlez-nous de vos délais.
Les workflows d’export et de suppression transforment les demandes des personnes concernées en un simple bouton, pas un projet.
Le consentement est enregistré par contact et par canal : votre équipe voit l’état d’adhésion directement sur la fiche avant tout envoi.
Le TLS couvre chaque saut — du navigateur à l’API jusqu’au worker en arrière-plan — sans aucun tronçon non chiffré.
Des durées de session configurables maintiennent les jetons d’accès à courte durée de vie : le rayon d’impact d’une session compromise est donc borné par l’horloge.
L’interface du produit — navigation, écrans, formulaires et e-mails transactionnels — est localisée en anglais, français, espagnol et japonais. Chaque personne choisit sa langue, enregistrée dans son profil, qui la suit ainsi d’un appareil à l’autre ; les nouveaux utilisateurs démarrent dans la langue par défaut de votre espace de travail.
Un seul moteur, de nombreux locataires, aucun croisement. Vos données vous appartiennent, séparées au niveau des lignes, scellées au repos, provisionnées depuis votre fournisseur d’identité, et journalisées de bout en bout.
Les questions que votre équipe se posera.
Chaque table dépendant d’un locataire applique la sécurité au niveau des lignes de Postgres avec FORCE + WITH CHECK — l’isolation est appliquée au niveau de la base de données, pas de la couche applicative. Un bug dans le code applicatif, une clause WHERE manquante ou une requête qui fuit ne peuvent toujours pas traverser les locataires.
De deux façons différentes, délibérément. Une clé API n’est jamais stockée sous une forme récupérable — nous n’en conservons qu’une empreinte SHA-256 à sens unique, si bien qu’une base de données divulguée ne livre aucune clé exploitable. Les jetons OAuth et les identifiants de connecteurs doivent, eux, pouvoir être rejoués : ils sont donc chiffrés avec Fernet au repos et déchiffrés uniquement en mémoire, à la demande, par le service qui en a besoin.
Oui — TOTP à deux facteurs pour les utilisateurs, OTP par e-mail pour les opérateurs, plus une vérification d’e-mail obligatoire à l’inscription et des pistes d’audit complètes sur chaque événement d’authentification.
Chaque changement significatif — création de fiche, modifications, suppressions, changements de permissions, connexions — avec qui, quand, et ce qui a changé, exportable pour votre propre examen ou une demande de conformité.
L’accès basé sur les rôles (propriétaire, admin, gestionnaire, membre, lecteur) verrouille chaque action, avec un panneau d’administration pour les utilisateurs, les paramètres de sécurité, l’application du MFA et les journaux d’audit.
Le provisioning, oui — SCIM garde les arrivées, les mobilités et les départs alignés sur votre fournisseur d’identité plutôt que sur une feuille de calcul, si bien qu’un départ se règle en une seule action dans le système auquel vous faites déjà confiance. L’authentification unique SAML / OIDC est disponible sur demande ; indiquez-nous vos délais et nous la cadrerons avec vous.
Les workflows d’export et de suppression RGPD transforment une demande de personne concernée en un simple bouton plutôt qu’en projet, et le consentement est enregistré par contact et par canal : votre équipe voit l’état d’adhésion sur la fiche avant tout envoi.
Oui — le TLS couvre chaque saut, du navigateur à l’API jusqu’aux workers en arrière-plan, en plus du chiffrement au repos pour les données et secrets stockés.