Projets et organisations

Stib sépare administration globale du serveur, propriété de l’organisation et travail projet. Placez un réglage dans la portée la plus étroite qui doit l’hériter.

Organisations

Une organisation regroupe projets, membres, labels, identifiants, clés API et journal d’audit. Ses admins gèrent membres et paramètres de cette portée ; les administrateurs globaux conservent leur accès hérité.

Une organisation peut posséder plusieurs projets. Déplacer un projet transfère boards, cartes, sessions et données liées et exige des droits d’administration sur l’organisation cible.

Vues d’espace de travail et ordre du sélecteur

Une vue d’espace de travail rassemble des projets de plusieurs organisations sous un nom et une couleur ; on la choisit dans le sélecteur d’organisation de la barre de titre. Elle ne donne jamais accès à un projet : chaque projet garde ses propres membres, et chacun ne voit dans une vue que les projets auxquels il a déjà accès.

Sa visibilité dit qui la voit en plus de vous :

• Personnelle — vous seul.
• Personnes choisies — les personnes que vous ajoutez en les cherchant par nom ou par e-mail. Pour chacune, la fenêtre indique combien de projets de la vue elle verra réellement.
• Tout le monde — toute personne qui a accès à au moins un de ses projets, aujourd’hui ou plus tard. Une personne qui n’en voit aucun ne la reçoit pas.

Seul le propriétaire modifie une vue partagée. Chez les autres, elle apparaît en lecture seule dans la section Partagées avec moi, avec le nom de son propriétaire dans le sélecteur. On peut la copier en vue personnelle (la copie ne reprend que les projets qu’on voit), la retirer de sa liste si elle a été partagée avec soi, ou la masquer si elle est ouverte à tous ; une vue masquée se retrouve dans la section repliée Masquées de la fenêtre, d’où on la réaffiche. Les changements arrivent en direct ; si la vue dans laquelle vous êtes ne vous est plus partagée, vous revenez à l’organisation du projet ouvert.

Gérer les organisations et les vues…, en bas du sélecteur, ouvre une seule fenêtre pour les deux :

• Vues — créer une vue, la renommer, changer sa couleur, cocher ses projets et la supprimer. Une vue enregistre chaque modification au fil de l’eau ; une nouvelle vue est créée à la validation. Choisissez sa visibilité. Glissez les vues (ou Alt+↑ / Alt+↓ sur l’une d’elles) pour fixer l’ordre du sélecteur ; les vues partagées avec vous se rangent aussi, dans votre ordre à vous. Supprimer la vue dans laquelle vous êtes vous ramène à l’organisation du projet ouvert. Le crayon à côté d’une vue, dans le sélecteur, ouvre la même fenêtre sur elle.
• Organisations — glissez-les dans votre propre ordre. Il ne change rien pour les autres membres, et les raccourcis numérotés le suivent. Le nom, la couleur et les membres d’une organisation restent dans ses paramètres.

Projets

Un projet pointe vers un dossier de dépôt visible du serveur. Ses paramètres couvrent :

• identité, icône/couleur, description et chemin du dépôt ;
• boards et modèles ;
• politique de worktree, branche de base par défaut et nommage des branches par IA (onglet Git) ;
• scripts projet ;
• labels et partage/membres ;
• skills projet et chargement de .mcp.json (agents Claude Code uniquement : les autres runners ne lisent pas ce fichier) ;
• identifiant par défaut, modèle par runner, runners et identifiants autorisés, et clés API limitées ;
• disponibilité du sandbox et rétention ;
• historique, export, transfert et suppression.

Transfert et suppression vivent tous deux dans la zone de danger, en bas de l’onglet Général, et exigent des droits d’administration sur le projet. La suppression retire le projet, ses boards, ses cartes et ses conversations d’agents, interrompt les agents en cours et nettoie les espaces de travail et branches créés par Stib. Le dépôt lui-même n’est jamais touché. La confirmation demande de saisir le nom du projet ; exportez-le d’abord si vous voulez en garder une copie.

Changer le chemin du dépôt affecte les futures opérations Git et agent. Vérifiez accessibilité et détection Git avant d’enregistrer, surtout sous Docker où les chemins conteneur diffèrent de ceux de l’hôte.

Rôles projet

Le modèle d’accès actuel distingue :

Rôle	Accès typique
Admin	Contrôle complet du projet, de ses paramètres et membres
Contributeur	Création et exécution de cartes sans administration du projet
Product owner	Création, modification et suppression de cartes dans les colonnes qui lui sont ouvertes ; lecture seule partout ailleurs
Lecteur	Lecture du board et des conversations, commentaires compris

Un product owner voit l’intégralité du board, quelles que soient les colonnes : son rôle ne restreint que l’écriture. Le backlog produit lui est ouvert d’office ; toute autre colonne peut l’être par un réglage — c’est ainsi qu’on lui donne une colonne où un agent l’aide à rédiger ses specs. Il ne peut jamais sortir une carte des colonnes qui lui sont ouvertes, ni archiver, verrouiller ou relancer un agent. Voir Rôle de la colonne.

Un lecteur peut commenter : commenter n’est pas modifier le produit. Tout le reste lui est refusé, et l’interface ne lui propose aucune action d’écriture.

Les administrateurs globaux et d’organisation peuvent hériter de l’administration projet.

Boards privés

Un projet peut autoriser les boards privés (plan Max, désactivé par défaut, dans Paramètres du projet › Boards). Contributeurs et admins créent alors des boards qu'eux seuls peuvent ouvrir, dans la limite du plafond fixé par membre (1 à 5). Un admin voit qu'un board privé existe (nom, propriétaire, nombre de cartes), jamais son contenu, et peut le supprimer. Quand le propriétaire quitte le projet, perd le rôle contributeur ou supprime son compte, le board devient orphelin : invisible pour tous, conservé jusqu'à ce qu'un admin le supprime ou le convertisse en board partagé. Réintégrer le membre le lui rend.

Boards et vues

Les boards appartiennent à un projet et définissent un workflow. Les vues enregistrées peuvent traverser plusieurs projets et appliquer filtres, regroupement et mise en page. Utilisez un autre board pour un workflow distinct, un groupe pour des lignes dans le même workflow et une vue pour observer les mêmes cartes autrement.

Partage et invitations

Le partage projet affecte directement membres et rôles. Les invitations d’organisation gèrent l’adhésion à l’organisation. Liens et sièges peuvent expirer ou être révoqués ; authentification ou licence peuvent empêcher l’accès malgré un rôle projet existant.

Suite : Paramètres et Audit & Collaboration.