En résumé
On se connecte avec un compte local — identifiant et mot de passe conservés par Linkr. Les droits se décrivent par ressource et action (lire, écrire, supprimer, exécuter) et se regroupent en rôles, attribués au niveau d’un espace de travail puis hérités par ses projets, qu’un projet peut redéfinir. Le droit d’exécuter du code est isolé des autres : c’est le plus sensible.
Tout ceci suppose le mode serveur
En mode navigateur, il n’y a ni compte ni authentification : la personne devant l’écran a accès à tout ce que contient son navigateur. Les pages Utilisateurs et Rôles y affichent un message indiquant qu’un serveur est nécessaire.
Se connecter
L’authentification est locale : Linkr conserve les comptes dans sa propre base, et le mot de passe est comparé à une empreinte. Le premier administrateur est créé par l’assistant de démarrage, décrit dans Installation en production.
L'authentification unique n'existe pas encore
LDAP, OIDC et SAML sont prévus — la structure interne les anticipe, un compte pouvant déjà être marqué comme géré par un annuaire extérieur — mais aucun n’est implémenté. N’inscrivez pas Linkr dans votre chaîne d’authentification unique aujourd’hui.
Un utilisateur ne peut pas changer son propre mot de passe
Le bouton existe dans le profil mais n’aboutit pas : la fonction n’est pas disponible côté serveur. En pratique, seul un administrateur réinitialise un mot de passe, depuis la fiche de l’utilisateur.
Il n’y a par ailleurs aucun envoi de courriel : ni réinitialisation par mail, ni invitation. Le mot de passe se transmet par vos propres moyens.
Les comptes
La page Paramètres › Utilisateurs gère les comptes : identifiant, mot de passe, rôle global, nom, prénom, courriel, affiliation, profession et ORCID.
L’ORCID mérite d’être renseigné : il suit l’utilisateur dans tout ce qu’il publie, et c’est par lui qu’une autre instance reconnaît l’auteur d’une entité importée au lieu de créditer celui qui l’a importée.
Les garde-fous
Plusieurs opérations sont refusées par le serveur, et c’est heureux :
- On ne se désactive pas soi-même, et on ne supprime pas son propre compte.
- Le dernier administrateur actif ne peut être ni rétrogradé, ni désactivé, ni supprimé — impossible donc de fermer la porte de l’intérieur.
- Un compte sans mot de passe ne peut pas être activé : il ne pourrait pas se connecter.
- Supprimer un utilisateur ne supprime pas ses contenus. Les projets et entités qu’il a produits restent, avec la trace de leur auteur.
L'annuaire est ouvert à tous les utilisateurs connectés
Pour ajouter quelqu’un à un espace de travail, il faut pouvoir le trouver. Une liste réduite — nom, affiliation, profession, ORCID — est donc lisible par tout utilisateur connecté. Elle ne contient ni courriel, ni rôle, et gérer les comptes reste réservé aux administrateurs.
Les organisations
Paramètres › Organisations tient l’annuaire des institutions de l’instance : hôpital, université, institut de recherche, entreprise, consortium. Chacune porte son nom, son pays, son site, un identifiant de référence — un ROR, un code d’établissement — et des champs libres.
Une organisation sert à deux choses : rattacher un espace de travail à l’institution qui le porte, et co-signer ce que vous publiez. Une entité partagée reste ainsi attribuable à l’établissement dont elle vient, même après plusieurs réutilisations.
Lecture ouverte, écriture protégée
Tout utilisateur connecté peut consulter l’annuaire — c’est une référence partagée. Créer et modifier demandent le droit correspondant, réellement vérifié par le serveur.
Les rôles
C’est le cœur du modèle. Un droit s’écrit ressource : action, et un rôle est une liste de droits.
Les actions
Lecture
Consulter.
Écriture
Créer et modifier.
Suppression
Supprimer.
Exécution
Faire tourner du code. Réservée à quelques ressources.
Toutes les ressources ne portent pas les quatre actions : on ne « supprime » pas une page de synthèse, et seules quelques-unes acceptent l’exécution.
Deux portées
- Les rôles d’espace de travail décrivent ce qu’un membre peut faire dans un espace de travail — et, par héritage, dans ses projets.
- Les rôles globaux portent sur l’administration de l’instance : comptes, rôles, organisations, création d’espaces de travail.
Les rôles livrés
| Rôle | Portée | Ce qu’il permet |
|---|---|---|
| Lecteur | Espace de travail | Consulter, sans rien modifier ni exécuter. |
| Éditeur | Espace de travail | Créer, modifier et exécuter du code. Ne gère ni les membres, ni les modèles d’IA. |
| Propriétaire | Espace de travail | Tout, y compris supprimer et gérer les membres. |
| Administrateur | Global | Tout, partout, sans avoir à être membre. |
| Utilisateur | Global | Aucun droit global. C’est l’appartenance aux espaces de travail qui donne les accès. |
Ces rôles ne se suppriment pas, mais leurs droits restent modifiables : vous pouvez décider qu’un éditeur, chez vous, n’exécute pas de code.
Deux exclusions volontaires du rôle Éditeur
Un éditeur voit la liste des membres mais ne la modifie pas — c’est une responsabilité de propriétaire. Et il ne déclare pas de modèle d’IA, parce que ce choix détermine si des données peuvent quitter l’établissement.
Comment un droit est résolu
L’ordre compte, et il explique la plupart des questions.
L’administrateur passe avant tout
Il contourne le système de permissions. C’est ce qui garantit qu’une erreur dans la matrice des rôles ne peut enfermer personne dehors.
Le rôle défini sur le projet
Il peut élargir ou restreindre le rôle hérité. Réglé sur « aucun », le projet disparaît pour ce membre, même s’il appartient à l’espace de travail.
Le rôle hérité de l’espace de travail
Le cas courant : on est éditeur d’un espace de travail, donc éditeur de ses projets.
Deux droits globaux traversent tout : tous les espaces de travail et tous les projets donnent un accès sans avoir à être membre — commode pour un référent qui doit dépanner, à manier avec discernement.
Créer un espace de travail et modifier un espace de travail sont deux droits distincts
Le premier est global : il autorise à en créer. Le second est propre à un espace de travail donné : il autorise à modifier celui-là. Leur ressemblance de nom prête à confusion ; leur portée n’a rien à voir.
Les comptes et les rôles restent réservés aux administrateurs
La matrice affiche bien des droits sur les utilisateurs et les rôles, mais le serveur exige le rôle administrateur pour ces deux écrans. Accorder ces droits à un rôle personnalisé rendra les onglets visibles sans les rendre utilisables. Les organisations, elles, sont réellement déléguables.
L’exécution de code, à part
C’est le droit le plus sensible : il permet de faire tourner du code arbitraire sur le serveur. Il est donc séparable de tout le reste — un rôle peut tout lire sans rien exécuter.
Linkr distingue deux choses qu’on pourrait confondre :
- Exécuter dans l’IDE — du R, du Python ou du SQL écrit par l’utilisateur. C’est le droit à surveiller.
- Afficher un widget — faire tourner le code d’une analyse déjà définie, au moment de l’affichage. Bien plus limité, et malgré tout distinct du précédent.
La frontière est tenue côté serveur : le rendu d’un composant intégré exécute un programme appartenant à l’application à partir d’une description validée, jamais du code envoyé par le navigateur.
Et l'interrupteur général
Indépendamment des rôles, LINKR_ENABLE_CODE_EXECUTION=false coupe l’exécution sur toute l’instance. Pour un déploiement verrouillé, c’est le réglage le plus utile — voir Configuration.
Ce que voit quelqu’un qui n’a pas le droit
Trois comportements, selon les cas — et dans tous, la vérification réelle est faite par le serveur : l’interface ne fait qu’expliquer.
- Un onglet reste visible, son contenu est remplacé par un encart : « Votre compte n’a pas les droits pour accéder à cette section. » Montrer que la fonction existe vaut mieux que la faire disparaître.
- Un bouton reste visible mais inactif, avec une infobulle expliquant pourquoi.
- Un projet disparaît quand son rôle est réglé sur « aucun » — là, la discrétion est l’intention.
Pour aller plus loin
- Configuration — l’interrupteur d’exécution et les autres réglages d’instance.
- Membres et rôles — attribuer ces rôles au quotidien.
- Installation en production — créer le premier administrateur.
- Fichiers sur le serveur — les droits qui ouvrent le sélecteur serveur.