La situation

De nombreuses organisations exploitent des plateformes partagées sur lesquelles plusieurs parties travaillent sur les mêmes données relatives aux infrastructures. Une entreprise de services publics dispose d’équipes internes, d’un maître d’œuvre principal et de deux ou trois sous-traitants sur le même réseau. Une collectivité locale dispose de son propre personnel et fait appel à des bureaux d’études externes. Des parties qui se font concurrence finissent souvent par travailler au sein de la même application.

Chaque utilisateur doit disposer d'un identifiant. L'identifiant indique au système qui il est. La séparation nécessite une deuxième information : ce que chaque personne est autorisée à voir.

Ce dont une séparation a besoin

La séparation sur une plateforme partagée nécessite quatre propriétés.

Une plateforme commune. Les parties collaborent sur la majeure partie des données, établissent des rapports à partir de celles-ci et travaillent sur une seule carte. La séparation concerne uniquement la partie sensible.

Contrôle à la source. Les données soumises à des restrictions restent sur le serveur. Le navigateur, l'API et toute exportation ne reçoivent que les informations que l'utilisateur est autorisé à consulter.

Toutes les règles en un seul endroit. Une fois définie, une règle s'applique à tous les modes de lecture des données, y compris les fonctionnalités ajoutées ultérieurement.

Des données actualisées pour tout le monde. Chaque partie travaille sur les données en temps réel.

Aptli répond à ces quatre critères grâce à ses deux couches.

Le modèle à deux niveaux

Notre approche divise l'autorisation en deux couches indépendantes qui se complètent.

Les droits d'administrateur sont permissifs. Ils définissent ce qu'une personne est autorisée à faire : créer un bon de travail, modifier un rapport, supprimer un article en stock. Une personne ne disposant pas de droits d'administrateur ne peut consulter que les données auxquelles son rôle lui donne accès.

Les restrictions de rôle sont contraignantes. Chacune d'entre elles désigne un type d'enregistrement (éléments, ordres de travail, rapports), un champ de celui-ci (balises, statut, catégorie), une comparaison et une valeur. Les membres du rôle ne peuvent pas effectuer les actions choisies (créer, lire, modifier, supprimer) sur les enregistrements correspondants, et chaque restriction est formulée sous la forme d’une phrase simple.

Ces deux niveaux fonctionnent de manière indépendante. Un collaborateur sur le terrain peut disposer du droit de modifier les rapports, tandis qu’une restriction liée au rôle masque les rapports aux autres utilisateurs. Le droit d’administrateur accorde cette capacité, et la restriction liée au rôle en délimite la portée. Cette indépendance garantit la solidité du modèle à mesure que le produit évolue.

Application au niveau du serveur

Aptli applique des restrictions liées aux rôles sur le serveur, avant que les données ne quittent la base de données :

Le filtre s'applique à tous les modes de consultation des données : pages d'enregistrements, listes, API, exportations et carte.
Une personne qui colle l'identifiant d'un enregistrement qu'elle n'est pas autorisée à consulter obtient une erreur 404 « Not Found ».
Un lien partagé par une autre personne n'ouvre que ce que les rôles de cette personne lui permettent de consulter.
Les nouvelles fonctionnalités héritent de ces règles, car elles accèdent à la même couche de données du serveur.

À chaque requête, le système répond à une question : cet enregistrement correspond-il à la règle ?

Un exemple détaillé

Deux prestataires travaillent sur le même chantier de déploiement de fibre optique. Tous deux utilisent la même carte et les mêmes couches de base partagées, et chacun consigne ses rapports en fonction de ses propres travaux. Les entités de chaque prestataire portent son identifiant : contractor-a ou contractor-b.

Créez un rôle intitulé Prestataire A avec une seule restriction :

Type d'enregistrement : Élément
Champ : tags
Comparaison : est l'un des suivants
Valeur : contractor-b
Actions bloquées : Créer, Lire, Modifier, Supprimer

La fenêtre « Rôles » affiche la description suivante : Les membres du rôle « Prestataire A » peuvent effectuer toutes les actions, à l'exception de la création, de la lecture, de la modification et de la suppression d'enregistrements de « Feature » dont le champ « tags » contient « contractor-b ». Attribuez ce rôle au personnel du Prestataire A, puis configurez le miroir pour le Prestataire B à l'aide de contractor-a. La configuration s'arrête là.

Les équipes de l'entrepreneur A voient désormais leurs propres éléments ainsi que les couches partagées. Une liste d'éléments exclut ceux de l'entrepreneur B, une exportation au format CSV est filtrée et un identifiant collé renvoie une erreur 404 « Not Found ». L'entrepreneur B voit la situation à l'envers. Chaque partie voit ses propres travaux, leur emplacement et la date de leur modification.

Les infrastructures de base communes (chemins de câbles, poteaux, réseaux de gaines) ne portent aucune des deux étiquettes et restent visibles pour les deux parties. Celles-ci collaborent lorsqu'elles le souhaitent et restent indépendantes lorsque cela s'impose.

Lorsque les parties ne partagent rien

Deux parties qui n'ont rien en commun, ne collaborent jamais et doivent, pour des raisons réglementaires, disposer d'infrastructures physiquement distinctes, utilisent des instances distinctes. Aptli gère une instance et une base de données par client, et chaque partie peut disposer de la sienne.

Le critère est simple : les parties qui bénéficient des mêmes couches de base, des mêmes rapports et de la même carte doivent être regroupées sur une seule et même plateforme, la séparation étant assurée au niveau du serveur.

Résumé

Plusieurs entités, parfois concurrentes, partagent souvent une même plateforme dans les secteurs des services publics, des télécommunications et des services municipaux.
Un identifiant permet d’identifier chaque utilisateur. Un deuxième niveau de contrôle détermine ce que chaque utilisateur peut voir.
La séparation nécessite une plateforme commune, une application des règles à la source, des règles centralisées et des données à jour pour tous.
Les deux niveaux d’Aptli sont les droits d’administrateur (ce qu’une personne est autorisée à faire) et les restrictions liées au rôle (les enregistrements auxquels elle n’a pas accès), appliqués au niveau du serveur.
Les enregistrements soumis à restriction restent sur le serveur et ne figurent pas dans les listes, l’API, les exportations ni les liens copiés.
La configuration mise en œuvre consiste à attribuer un rôle par prestataire, limitant l’accès à l’étiquette de l’autre, les couches partagées étant visibles par les deux.
Les parties qui ne partagent rien et ont besoin d’une infrastructure distincte utilisent des instances distinctes.