Comptes & équipes

Un espace de travail appartient à une organisation. Les personnes y entrent comme membres avec un rôle, partagent workflows et ressources, et le propriétaire contrôle la facturation, le BYO-AI et les réglages de gouvernance des données. Cette page couvre le compte lui-même, les rôles, SSO et SCIM, et le routage des notifications.

compte ▸ profil

Inscription & profil

Inscrivez-vous avec un e-mail et un mot de passe, puis vérifiez votre e-mail — les actions privilégiées restent verrouillées tant que ce n’est pas fait. Votre profil porte votre nom d’affichage, votre avatar, votre langue et vos préférences de notification.

Export & suppression

GET /account/export renvoie un export lisible par machine des données de votre compte. Supprimer le compte exige votre mot de passe actuel, et la suite dépend de votre rôle : un propriétaire seul supprime l’organisation avec lui (une confirmation saisie au clavier est exigée), tandis que le propriétaire d’une organisation à plusieurs membres doit d’abord transférer la propriété à un autre membre — ou supprimer explicitement l’organisation entière.

Voir Confidentialité et le Data Processing Addendum pour le traitement des données, et les sous-traitants pour savoir qui les traite.

rôles ▸ un par membre

Membres & rôles

Invitez vos coéquipiers par e-mail. Chaque membre a exactement un rôle :

Rôle	Peut faire
Owner	Tout, y compris la facturation, les changements de palier, le BYO-AI et la suppression de l’organisation. Un seul owner par organisation ; la propriété est transférable, et l’ancien owner devient membre.
Admin	Gérer les membres, workflows, ressources, surveillants et endpoints. Aucune action destructrice côté facturation.
Member	Créer et exécuter workflows, surveillants et automatisations dans les scopes accordés.

Les invitations et les changements de rôle peuvent attribuer admin ou member ; la propriété ne bouge que par un transfert explicite.

sso ▸ routé par domaine

SSO & vérification de domaine

L’authentification unique se lie à un domaine dont vous prouvez le contrôle : créez un enregistrement DNS TXT sur _writ-sso-verify.{domain} avec la valeur que l’écran de configuration vous donne. Une fois vérifié, les connexions de ce domaine sont routées vers votre fournisseur d’identité. Deux propriétés méritent d’être connues :

sso_enforced (optionnel) : les connexions hors SSO pour ce domaine sont refusées — le mot de passe cesse d’être une porte parallèle.
La découverte SSO ne révèle que le routage. Demander « comment cet e-mail se connecte-t-il ? » ne divulgue jamais si un compte existe.

scim ▸ l’effectif, synchronisé

Provisionnement SCIM

Les organisations peuvent provisionner leurs membres en SCIM 2.0 depuis un fournisseur d’identité. Déprovisionner une personne retire son appartenance, suspend le compte s’il ne lui reste plus aucune appartenance, et révoque immédiatement toute session et tout token actifs — la sortie dans l’IdP est la sortie de Writ, sans rien qui reste connecté.

oauth ▸ plafonné

Les accès OAuth sont plafonnés

Un accès accordé via un flux OAuth est plafonné au rôle operator — quelle que soit l’étendue des scopes demandés, un accès OAuth ne porte jamais admin. Le contrôle administratif reste aux personnes connectées en leur propre nom.

notifications ▸ catégories × canaux

Préférences de notification

Les notifications de la plateforme forment une grille : sept catégories — security, billing, team, runs, agents, marketplace, support — sur six canaux : in_app, email, sms, whatsapp, signal, pushover. Vous choisissez cellule par cellule, avec une exception délibérée : quelques cellules sont verrouillées toujours actives — les alertes de sécurité, les problèmes de paiement et les invitations d’équipe ne peuvent pas être réduites au silence.

org ▸ byo-ai

Organisation & BYO-AI

Les réglages d’organisation couvrent le nom de l’espace, le routage d’agent par défaut et le mode de fournisseur IA. Avec le bring-your-own AI, les appels IA sont servis par un agent détenant les clés fournisseur de l’organisation — les clés restent sur cette machine, et aucune IA gérée n’est facturée pour ces appels.

`byo_ai_mode`	Comportement
`off`	L’IA passe par la passerelle gérée de Writ ; facturée au token.
`prefer`	Utiliser les clés de l’organisation quand un agent qui les détient est en ligne ; sinon, repli sur la passerelle gérée.
`strict`	Clés propres uniquement : l’appel IA échoue plutôt que de se replier, et vos prompts ne touchent jamais les clés de la plateforme.

Writ s’exécute sur vos propres comptes, avec vos propres identifiants et données, sur les sites que vous êtes autorisé à utiliser. Le BYO-AI étend cela à la couche modèle : vos clés fournisseur, vos tokens. Une frontière tient quel que soit le mode : la réparation de sélecteurs par IA est une capacité gérée et n’utilise jamais les clés BYO — voir Où ça s’exécute.

Et ensuite

Personas, secrets et agents : ce que votre équipe partage.
Facturation & usage : le modèle à pool unique, et qui paie.
Authentification : clés API, scopes, rotation.