3 niveaux d'accès pour partager sans tout donner : la refonte des permissions dans TAMSIV

Marie a invité Camille au classeur "Mariage Léa & Thomas" mardi soir. Elle voulait juste lui montrer la liste des prestataires et l'organisation des invités. Mercredi midi, Camille avait modifié le budget, supprimé deux tâches "par erreur" et renommé le classeur. Pas par malice. Juste parce que le partage était binaire : t'es dedans ou t'es pas dedans, et quand t'es dedans, tu peux tout faire.

Ce scénario revient sans arrêt dès qu'une app collaborative grandit. La granularité d'accès, ce n'est pas un détail technique, c'est ce qui différencie un outil qu'on peut prêter à toute la famille d'un outil qu'on hésite à partager. La version 1.29 de TAMSIV introduit trois niveaux d'accès distincts (lecture, écriture, total) qui s'appliquent à chaque membre d'un partage, sur chaque tâche, mémo, événement et classeur. 1258 lignes ajoutées, 824 supprimées, six langues mises à jour, un chantier qu'on a appelé en interne "Phase A + B refonte permissions".

Points clés

• Trois niveaux d'accès clairs remplacent le partage binaire : Lecture (voir sans modifier), Écriture (voir et modifier le contenu), Total (modifier, supprimer, gérer les assignations).
• Chaque membre d'un classeur partagé reçoit un badge visible (œil gris, crayon bleu, bouclier vert) qui rend l'accès lisible en un coup d'œil pour tout le monde, pas juste pour le propriétaire.
• Les sections "Arborescence" et "Membres" deviennent collapsibles, l'arbre d'accès est redessiné avec des connecteurs continus, des cartes indentées par profondeur et une ligne horizontale étendue par niveau.
• Le composant PermissionLevelPicker centralise la sélection : 186 lignes, modal accessible, descriptions explicites en six langues, état désactivé pour les rôles non éditables.
• Le rôle d'un assigné est résolu dans le contexte du classeur (assigné direct vs. externe), avec des clés roles.assigned et roles.external qui évitent les confusions visuelles.

Pourquoi le partage binaire ne tient plus dès qu'une famille s'en mêle ?

Dans la plupart des apps collaboratives grand public, l'accès se résume à deux états : tu es membre, ou tu ne l'es pas. Quand tu invites quelqu'un, tu lui donnes par défaut le droit de tout faire. Modifier, supprimer, ajouter des participants, changer les dates, renommer. C'est le modèle de Trello pour les boards basiques, de la plupart des shared notes Apple, et de pas mal de listes de courses partagées.

Ce modèle marche tant que tu partages avec une seule personne de confiance, et tant que tout le monde a le même intérêt à respecter le contenu. Dès que tu ajoutes un troisième acteur, ou que la dynamique change, la friction commence. Ton conjoint a besoin de modifier la liste de courses, mais ta belle-mère qui passe le week-end a juste besoin de la voir. Ton équipe peut éditer le brief client, mais le client lui-même devrait juste lire. Ta sœur qui prépare son mariage avec toi a besoin du contrôle total, mais sa belle-sœur qui aide ponctuellement n'a pas besoin de pouvoir supprimer le classeur entier.

L'absence de niveaux d'accès force un choix binaire douloureux : soit tu surinvestis les invités (et tu prends le risque qu'un proche modifie sans le vouloir), soit tu sousinvestis (et la personne ne peut rien faire d'utile, donc elle abandonne). C'est exactement la friction qui pousse les gens à revenir à des captures d'écran WhatsApp et à de la charge mentale éparpillée dans dix outils différents.

Quels sont les trois niveaux d'accès dans TAMSIV ?

La refonte introduit trois niveaux distincts, chacun avec son icône, sa couleur et sa description, accessibles via un sélecteur unifié dans toute l'app.

Lecture (œil gris)

Le membre voit l'intégralité du contenu, mais ne peut rien modifier. Il peut commenter, réagir avec des emoji, recevoir les notifications du classeur, mais pas créer de nouvelle tâche, pas modifier les dates, pas changer les assignations. C'est le niveau parfait pour un proche qu'on tient au courant, un client qu'on consulte, un parent qui veut suivre l'organisation sans risquer de toucher à quoi que ce soit.

Écriture (crayon bleu)

Le membre peut voir et modifier le contenu existant. Il peut créer de nouvelles tâches, modifier des mémos, ajouter des photos, déplacer un événement. Mais il ne peut pas supprimer ce qu'il n'a pas créé lui-même, ni gérer les assignations des autres. C'est le mode collaboration courante, celui qu'on utilise quand on travaille ensemble sur le même projet.

Total (bouclier vert)

Le membre a les mêmes droits que le propriétaire à une exception près : il ne peut pas dissoudre le partage entier. Il peut modifier, supprimer, gérer les assignations, inviter de nouveaux membres, changer les niveaux d'accès des autres. C'est le mode "co-organisateur", parfait pour un conjoint, un associé, un parent à qui on veut tout déléguer sans pour autant transférer la propriété du classeur.

Les trois niveaux sont représentés par un sélecteur visuel cohérent : icône + couleur + label, avec une bulle d'explication au tap. Le sélecteur s'appelle PermissionLevelPicker, il vit dans frontend/src/components/common/ et il est utilisé partout où un niveau d'accès doit être affiché ou modifié. Cette unicité du composant est ce qui garantit qu'un membre Lecture sur le classeur "Mariage" se reconnait visuellement comme Lecture sur la tâche "Réserver salle", sans réinterprétation.

Comment voir qui a quel accès dans un classeur partagé ?

Le second gros morceau de la refonte concerne l'écran qui liste les membres. Avant, on voyait une liste plate d'avatars avec des prénoms. Maintenant, chaque membre est accompagné d'un badge d'accès en couleur, et la liste est triée par niveau (les Total en haut, puis les Écriture, puis les Lecture). En un coup d'œil, le propriétaire voit qui peut faire quoi.

Les sections "Arborescence" et "Membres" du détail d'une tâche, d'un mémo ou d'un événement deviennent maintenant collapsibles. Tu tapes sur le header, le chevron tourne, la section se replie ou se déplie. Sur les écrans avec beaucoup de membres ou des hiérarchies profondes, ça change tout pour la lisibilité.

L'arbre d'accès lui-même a été redessiné. Avant, c'était une liste plate avec deux ou trois indentations approximatives. Maintenant, chaque niveau de profondeur a sa propre cellule, sa propre ligne horizontale qui s'étend, ses propres tree-connectors continus qui dessinent la hiérarchie comme un vrai arbre. Quand un classeur est imbriqué dans un autre, et qu'une tâche est imbriquée dans le classeur enfant, l'arbre rend la chaîne d'héritage visuelle, pas verbale.

Comment fonctionne l'héritage des permissions à travers la hiérarchie ?

TAMSIV permet d'imbriquer des classeurs sur six niveaux. Si tu donnes accès Écriture à quelqu'un sur un classeur parent, il hérite automatiquement de l'accès Écriture sur tous les sous-classeurs et leur contenu. C'est le comportement par défaut, et c'est ce qu'on attend dans 80% des cas.

Mais la nouvelle architecture permet aussi de surcharger un niveau d'accès localement. Un membre Écriture sur le classeur parent peut être limité à Lecture sur un sous-classeur précis, parce que ce sous-classeur contient des informations sensibles. La surcharge est explicite (un badge spécifique apparait dans l'arbre), et elle s'affiche dans le contexte du classeur parent pour rester traçable.

Cet héritage avec surcharge est techniquement complexe. Il s'appuie sur les Row Level Security policies de PostgreSQL, étendues par 31 politiques RLS qui calculent le niveau effectif d'un utilisateur sur un item donné en remontant l'arbre. Le résultat est calculé côté base de données, pas côté client, ce qui évite les drift de permissions et les exploits côté frontend.

Pourquoi cette refonte a touché 15 fichiers et 6 langues ?

Les permissions, c'est un concept transverse. Elles vivent dans le détail d'une tâche (qui peut modifier ?), dans la liste des membres d'un classeur (qui voit quoi ?), dans le sélecteur de partage (à qui je donne accès ?), dans l'écran d'assignation (qui peut être assigné ?), dans l'arbre d'accès (comment l'héritage se calcule ?). Toucher aux permissions, c'est toucher à l'épine dorsale de la collaboration.

La refonte a impliqué 15 fichiers modifiés en frontend, dont les principaux : AssigneesModal.tsx (130 lignes ajoutées, gestion du rôle d'un assigné dans son classeur), GroupMembersModal.tsx (62 lignes ajoutées, badges accès), GroupHierarchySection.tsx (346 lignes refondues, arbre redessiné), TaskAccessTree.tsx (24 lignes ajustées, intégration du badge dans la branche groupe), et le nouveau composant PermissionLevelPicker.tsx (186 lignes, modal réutilisable).

Côté i18n, les nouvelles clés access.read/write/readWrite/full, access.readDescription/writeDescription/fullDescription, access.permissionLevel, roles.assigned/external ont été ajoutées dans les six fichiers de langue (FR, EN, DE, ES, IT, PT). La traduction est passée par notre script automatique OpenRouter avec relecture humaine sur les nuances. Un mauvais label sur "Total" en allemand ou "Écriture" en italien peut suffire à perdre toute la lisibilité de la feature.

Quels usages familiaux et professionnels la granularité débloque ?

Ce qui change dans la vraie vie, ce n'est pas le code. C'est les scénarios d'usage qui deviennent possibles sans contournement.

Une famille avec ado. Tu donnes Total à ton conjoint sur le classeur "Maison", Écriture à ton ado de 15 ans pour qu'il puisse cocher ses propres tâches sans risquer de supprimer celles de toute la famille, Lecture aux grands-parents qui passent le week-end et veulent juste savoir s'ils ont besoin de ramener du pain.

Un freelance avec un client. Tu partages le classeur "Site client X" avec ton client en Lecture (il voit l'avancement, il commente), avec ton sous-traitant en Écriture (il modifie le contenu sans pouvoir te désassigner), avec ton associé en Total (il peut tout gérer si tu pars en congé).

Une association ou un APE. Tu donnes Total au bureau (3 personnes), Écriture aux bénévoles actifs (15 personnes), Lecture aux parents qui veulent suivre l'organisation de la kermesse sans risquer de modifier le planning par accident.

Un mariage à plusieurs. Tu donnes Total à ton conjoint et au témoin principal, Écriture aux quatre demoiselles d'honneur qui aident sur des aspects précis, Lecture aux parents et beaux-parents qui veulent suivre les invités et le planning du jour J sans risquer de tout casser.

Questions fréquentes

Le propriétaire du classeur peut-il changer le niveau d'accès des membres après l'invitation ?

Oui. Depuis l'écran "Membres" du classeur, le propriétaire (et tout membre Total) peut modifier le niveau d'accès de chacun à tout moment, sans réinviter. Le changement est appliqué en temps réel sur tous les appareils via Supabase Realtime, le membre concerné voit son niveau changer dans l'app sans avoir à se reconnecter.

Que se passe-t-il si je donne accès Lecture à quelqu'un qui était Total avant ?

Les contributions passées (tâches créées, photos uploadées, commentaires) restent dans le classeur. La personne perd seulement la capacité d'en modifier ou d'en supprimer. Elle continue de voir tout le contenu, mais les boutons d'édition disparaissent côté interface, et les requêtes côté serveur sont rejetées par les politiques RLS si quelqu'un essaie de contourner via une requête directe.

Puis-je donner Total à quelqu'un sur un sous-classeur sans lui donner Total sur le classeur parent ?

Non, l'héritage descend mais ne remonte pas. Si tu veux que quelqu'un soit Total sur un sous-classeur, il faut qu'il ait au moins Lecture sur le parent (sinon il ne pourra pas naviguer jusqu'au sous-classeur). Tu peux en revanche faire l'inverse : donner Total sur le parent et descendre à Écriture ou Lecture sur un sous-classeur précis pour protéger une partie sensible.

Les niveaux d'accès s'appliquent-ils aussi aux pièces jointes et aux commentaires ?

Oui. Un membre Lecture peut voir les pièces jointes mais pas en uploader. Il peut lire les commentaires mais peut quand même en écrire et réagir avec des emoji (le commentaire est une forme de contribution non-destructive, ouverte à tous les niveaux). Les politiques RLS sont appliquées de manière cohérente sur les six tables impliquées : tâches, mémos, événements, attachments, comments, reactions.

Comment se passe la migration pour les classeurs créés avant la 1.29 ?

Tous les membres existants ont été migrés vers le niveau Total (ce qui correspond au comportement avant la refonte). Aucune action utilisateur n'est requise. Si tu veux profiter de la granularité sur un classeur existant, il suffit d'ouvrir l'écran Membres et d'ajuster le niveau de chaque personne. La modification est instantanée, sans rejet d'invitation ni perte de données.

Et toi, t'as déjà donné un accès trop large à quelqu'un sur une app partagée ?

Si tu lis cet article, c'est probablement parce que tu as déjà vécu la scène au moins une fois. Tu as ajouté un proche à un classeur ou un projet, et tu as découvert quelques jours plus tard que la personne avait modifié, supprimé ou réorganisé un truc auquel tu tenais. Pas par méchanceté. Juste parce que l'app ne te permettait pas de dire "tu peux regarder, mais pas toucher".

La version 1.29 de TAMSIV résout ce dilemme en deux taps. Tu invites, tu choisis le niveau, tu peux le modifier à tout moment. Le partage devient un curseur, plus un interrupteur. Et c'est peut-être ce qui va te donner le courage d'ouvrir tes classeurs à un cercle plus large que les deux personnes que tu invitais avant.

Télécharger TAMSIV gratuitement sur le Play Store et tester les nouveaux niveaux d'accès dès la version 1.29.