Maîtrisez l'accès à vos données

Data Fair offre un contrôle fin de qui peut accéder, modifier et publier des données, au sein d'une organisation comme entre organisations partenaires. La plateforme combine authentification, autorisation et traçabilité, depuis l'open data complètement ouvert jusqu'aux données strictement confidentielles réservées à un groupe restreint.

Organisations et comptes

Une organisation est l'espace de travail principal mis à disposition d'un client : elle correspond à une entité juridique ou fonctionnelle (collectivité, entreprise, établissement public…) et regroupe des membres avec des rôles et permissions différents. Un utilisateur peut appartenir à plusieurs organisations, chacune restant cloisonnée.

La politique de la plateforme limite le stockage de données personnelles au strict nécessaire : seule l'adresse e-mail est obligatoire. Le renouvellement de mot de passe suit les recommandations de la CNIL, les comptes inactifs depuis plus de trois ans sont supprimés automatiquement, et l'authentification à deux facteurs peut être activée.

Rôles et permissions

Trois rôles sont disponibles par défaut dans une organisation :

  • Utilisateur : accède uniquement aux ressources qui lui sont ouvertes, principalement pour consulter des données en close data ;
  • Contributeur : édite les ressources qui lui sont ouvertes et propose de nouvelles versions (brouillons de pages ou de visualisations à valider) ;
  • Administrateur : gère les jeux de données, visualisations, portails, membres, permissions et paramètres.

En complément, des permissions précises peuvent être définies pour chaque ressource, y compris pour des utilisateurs externes désignés par leur adresse e-mail. Il est ainsi possible d'autoriser une personne à mettre à jour un jeu de données spécifique sans lui donner le rôle de contributeur.

Permissions à la ligne

L'accès peut descendre jusqu'à la ligne d'un jeu de données, via un jeu virtuel et une colonne portant le concept « identifiant de compte ». Cette colonne peut être multivaluée : les permissions sont alors attribuées à des comptes individuels, des organisations ou des départements.

Éditer des permissions et journal d'audit

Départements et cloisonnement

Les utilisateurs peuvent être organisés en groupes, appelés départements, pour faciliter la gestion des permissions des organisations de taille importante. Un utilisateur peut appartenir à plusieurs départements et hérite automatiquement des droits associés à chacun.

  • Un contributeur de département ne met à jour que les ressources de son département ; celles qu'il crée y sont rattachées automatiquement.
  • Un administrateur de département ne gère que les ressources et utilisateurs de son département.
  • Un administrateur général gère toutes les ressources de l'organisation.

Ce cloisonnement convient aux structures décentralisées : une communauté de communes peut créer un département par commune membre, un pôle universitaire un département par organisme, un groupe multi-établissements un espace par entité tout en consolidant l'ensemble au niveau central.

Partenaires et partage entre organisations

Un partenaire est une autre organisation avec laquelle on échange des données en lecture ou en écriture. L'invitation est adressée à l'un de ses administrateurs, qui gère ensuite les utilisateurs habilités : les droits restent configurables par ressource et suivent les changements d'équipe, sans duplication des données.

Deux cas d'usage fréquents : mettre à disposition des données sensibles pour des agents répartis dans de nombreux services, ou collecter des données auprès de plusieurs partenaires dans un schéma commun et consolider le tout dans une vue unique.

SSO et fédération d'identité

L'interconnexion SSO est particulièrement utile pour les portails close data : les agents accèdent au portail avec leurs identifiants habituels. La plateforme supporte OpenID Connect (recommandé, compatible Azure AD), OAuth 2.0, SAML v2 et LDAP.

La liaison peut créer automatiquement les comptes avec le rôle « utilisateur » et un département par défaut. L'administrateur ajuste ensuite les rôles et les affectations après la première connexion.

Comptes de service (identités non humaines)

Certaines opérations sont réalisées par un système et non par une personne : traitement planifié, agent IA, application déployée sur un cluster. Un compte de service leur donne une identité propre, sans adresse e-mail ni mot de passe : il s'authentifie avec un jeton de courte durée émis par un fournisseur d'identité que l'organisation déclare digne de confiance (le service de jetons d'un cluster Kubernetes, ou tout fournisseur OpenID Connect).

Un administrateur le crée en fixant l'émetteur et le sujet acceptés, puis lui attribue un rôle et, si besoin, un département : il reçoit des droits comme un membre humain. Il reste volontairement plus limité :

  • Cantonné à une seule organisation : sans accès au portail d'une autre, et sans privilège d'administration de la plateforme ;
  • Hors des parcours e-mail : ni invitation, ni réinitialisation de mot de passe, ni liaison SSO ;
  • Sessions courtes et non renouvelables : d'une durée plafonnée, qu'il suffit de redemander.

Deux options facultatives resserrent encore l'usage : restreindre les adresses depuis lesquelles une session peut être obtenue, et lier la session à l'adresse qui l'a demandée, ce qui rend un jeton dérobé inutilisable ailleurs.

Traçabilité et audit

Le journal d'audit conserve une trace complète de qui a fait quoi et quand : création, modification et suppression de ressources (jeux de données, visualisations, pages…), avec l'utilisateur, l'action, la date et le détail des changements avant/après. Les actions d'administration, comme la création d'utilisateurs ou la modification de permissions, sont enregistrées de la même manière. La rétention par défaut est d'un an, configurable, et les administrateurs consultent les traces directement dans la plateforme.

Pour aller plus loin