Permissions de partage cloud : au-delà de lecture et écriture
Il y a un moment, dans la vie de toute équipe qui utilise un cloud partagé, où quelqu’un supprime un fichier qu’il ne devait pas toucher. Ce n’est jamais méchant — c’est toujours un clic maladroit ou une incompréhension sur “ce dossier, c’est le mien ou le tien ?”. Et c’est à ce moment-là qu’on découvre que la gestion des permissions du cloud n’est pas un détail d’administration système : c’est la fondation sur laquelle repose toute la collaboration en équipe. La plupart des clouds proposent trois niveaux — lecture, écriture, admin. Le problème, c’est que la réalité des équipes est rarement aussi binaire, et le modèle de contrôle d’accès RBAC le démontre depuis des décennies.
La réponse à “qui peut faire quoi” devrait être granulaire. Peut-il voir ce fichier ? Oui. Peut-il le télécharger ? Non (parce que c’est un document confidentiel qu’on veut montrer mais pas distribuer). Peut-il le partager avec quelqu’un d’autre ? Seulement à l’intérieur de l’équipe. Peut-il le supprimer ? Certainement pas. Ces quatre questions, c’est le minimum pour un espace cloud professionnel. Et pourtant, beaucoup de fournisseurs se contentent encore du triptyque lecture/écriture/admin en espérant que ça suffira.
Le problème des permissions héritées (et pourquoi ça finit toujours mal)
kDrive utilise un système de permissions par dossier avec héritage. Concrètement : si vous donnez accès en écriture à un dossier, tous les sous-dossiers héritent de ce droit sauf configuration contraire. C’est pratique pour la mise en place initiale, mais c’est un piège pour la maintenance. Six mois après la création de l’arborescence, quand quelqu’un ajoute un sous-dossier “Contrats clients” dans un dossier partagé en écriture avec toute l’équipe, ce sous-dossier est accessible en écriture par toute l’équipe — y compris le stagiaire arrivé la semaine dernière.
La solution, c’est la rupture d’héritage : on peut casser la chaîne à n’importe quel niveau et définir des permissions spécifiques pour un sous-dossier. Google Drive fonctionne différemment — chaque fichier et dossier a ses propres permissions, sans héritage automatique — ce qui est plus sûr par défaut mais beaucoup plus fastidieux à configurer quand on a cent dossiers. OneDrive et SharePoint utilisent un modèle hybride avec des groupes SharePoint qui ajoutent une couche d’abstraction (et de complexité).
La co-édition sans permissions, c’est le Far West
Donner à cinq personnes l’accès en édition simultanée sur un document sans avoir réfléchi aux permissions du dossier parent, c’est comme organiser un dîner sans plan de table dans un restaurant en libre-service. Tout le monde se sert, personne ne sait qui a pris quoi, et quelqu’un finit par renverser le plat principal. Les permissions ne sont pas un frein à la collaboration — elles sont le cadre qui la rend possible. C’est d’autant plus vrai quand plusieurs personnes éditent le même document en temps réel et que la moindre modification maladroite est immédiatement propagée.
Quand le partage externe exige un niveau de contrôle supplémentaire
La gestion des permissions prend une autre dimension quand les collaborateurs ne sont pas tous dans la même organisation. Un prestataire externe qui intervient sur un projet a besoin d’accéder aux fichiers du projet — mais certainement pas au dossier RH ni aux contrats des autres clients. kDrive permet d’inviter des utilisateurs externes avec des droits spécifiques par dossier, sans leur donner accès au reste de l’espace. C’est aussi là que la distinction entre envoyer un lien de partage sécurisé et donner un accès permanent devient critique. Le lien, c’est pour l’échange ponctuel. La permission sur le dossier, c’est pour la collaboration au long cours.
Bonnes pratiques : le principe du moindre privilège appliqué au cloud
Le principe du moindre privilège — chaque utilisateur n’a que les droits strictement nécessaires à sa mission — est un classique de la sécurité informatique. Sur un cloud d’équipe, ça se traduit en règles simples : commencer par “lecture seule” et élargir au cas par cas, plutôt que commencer par “accès complet” et restreindre après coup (parce que “après coup” arrive rarement). Créer des groupes de permissions par rôle (direction, équipe projet, externe) plutôt que par personne. Et surtout : auditer les permissions tous les trimestres, parce que les équipes changent, les projets se terminent, et les accès accordés “temporairement” ont une demi-vie plus longue que le plutonium.
La granularité des permissions est l’investissement le moins sexy et le plus rentable d’un cloud d’équipe. Personne ne s’en vante dans les keynotes — mais tout le monde s’en félicite le jour où un ancien collaborateur n’a plus accès aux fichiers qu’il n’a pas à voir.