Autorisation

L’autorisation définit ce que les utilisateurs peuvent et ne peuvent pas faire après leur authentification. Aptli combine deux couches indépendantes : des droits d’administrateur permissifs (ce que vous pouvez faire) et des restrictions de rôle restrictives (ce que vous ne pouvez pas voir). Ensemble, elles offrent aux administrateurs un contrôle précis tant sur les capacités que sur la visibilité des données.

Présentation du modèle d’autorisation

Le modèle de sécurité complet d’Aptli comporte trois couches :

Authentification — Qui vous êtes (abordé dans la section Authentification)
Droits d’administrateur — Ce que vous POUVEZ modifier (autorisations permissives)
Restrictions liées aux rôles — Ce que vous NE POUVEZ PAS voir (filtres restrictifs)

Toutes les restrictions sont appliquées au niveau du serveur — aucune donnée non autorisée n’est jamais envoyée à votre navigateur, quelles que soient vos tentatives via l’interface utilisateur, l’API ou les exportations.

Ce modèle offre une flexibilité exceptionnelle tout en garantissant la sécurité.

Droits d’administrateur (permissifs)

Les droits d’administrateur accordent l’autorisation de modifier des informations ou de changer un statut. Sans ces droits, les utilisateurs peuvent uniquement consulter les données et modifier leur propre profil.

Les droits d’administrateur constituent un ensemble à la carte, propre à chaque utilisateur (user.admin). Chaque entrée correspond à un nom de droit unique ; il n’y a pas de regroupement en lots. Les droits sont accordés directement à l’utilisateur, ils ne sont jamais hérités d’un rôle.

Droits d’administrateur courants :

usersUpdate - Modifier les profils d’autres utilisateurs (nom, fonction, service - PAS l’e-mail ni le mot de passe)
usersLogout - Forcer la déconnexion ou verrouiller définitivement les comptes
usersDelete - Supprimer des comptes utilisateurs
usersCreate - Créer de nouveaux utilisateurs ou restaurer des comptes supprimés
featureCreate, featureUpdate, featureDelete - Modifier des éléments cartographiques (points, lignes, polygones)
allowCommits - Valider des versions de carte en production (sinon, le bouton « Soumettre » envoie une demande de validation par l’administrateur)
jobsCreate, jobsUpdate, jobsDelete - Gérer les tâches (unités de travail planifiées)
workOrdersCreate, workOrdersUpdate, workOrdersDelete - Gérer les ordres de travail
reportsCreate, reportsUpdate, reportsDelete - Soumettre et gérer les rapports de travail
validationsCreate, validationsUpdate, validationsDelete - Validation qualité des rapports
activitiesCreate, activitiesUpdate, activitiesDelete - Gestion du catalogue des activités (types de tâches)
projectsCreate, projectsUpdate, projectsDelete - Gestion des projets
transactionsCreate - Créer des transactions de stock (le registre est en mode « insertion uniquement » — il n’y a pas de droit de modification ni de suppression)
canFacilitatePickups - Remettre du matériel à une personne via un code QR de retrait en son nom
canTransferStock - Transférer des stocks entre des sites (les sites correspondent aux transferts, les personnes aux enlèvements)

Pour soumettre une demande d’aide, aucun droit n’est nécessaire : tout utilisateur authentifié peut en créer une. La disponibilité de l’assistant IA relève d’un paramètre applicable à l’ensemble du déploiement, et non d’un droit individuel par utilisateur.

Super-droits (qui prévalent sur tous les autres) :

appSettingSchemasModify - Modifier les paramètres au niveau de l’application (domaines, délais d’expiration, sécurité)
adminRightsModify - Attribuer des droits d’administrateur à d’autres utilisateurs
viewDeleted - Consulter les enregistrements supprimés (presque universel, partiellement supplanté par les restrictions liées aux rôles)

Vérification des droits d’administrateur d’un utilisateur :

Accédez à Admin → Utilisateurs
Ouvrez le profil de l’utilisateur
La section « Droits d’administrateur » répertorie toutes les autorisations accordées

Restrictions liées aux rôles (restrictives)

Les rôles sont des ensembles de restrictions qui empêchent la consultation et la modification d’enregistrements présentant certaines caractéristiques. Un rôle ne contient qu’un nom et une liste de restrictions — rien d’autre. Les rôles n’ont ni membres, ni propriétaire, ni droits d’administrateur. L’appartenance à un rôle dépend de l’utilisateur : chaque utilisateur dispose d’une liste de rôles, et toutes les restrictions de ces rôles s’appliquent à cet utilisateur.

Pour attribuer un rôle, ajoutez-le à l’utilisateur depuis son profil (ou définissez-le comme rôle par défaut pour les nouveaux utilisateurs). Pour répertorier les membres d’un rôle, recherchez les utilisateurs dont la liste roles inclut ce rôle.

Composants d’un rôle :

Nom - Une étiquette lisible par l’utilisateur
Restrictions du rôle - Des filtres au niveau des champs masquant des données spécifiques

Les rôles ne concernent que la visibilité et les restrictions. Ils n’accordent jamais la possibilité d’effectuer des actions — c’est à cela que servent les droits d’administrateur.

Structure des restrictions de rôle

Chaque restriction définit :

Modèle (target_model) - Le type de données concerné (utilisateur, fonctionnalité, rôle, etc.)
Champ - La propriété sur laquelle filtrer (propriétaire, statut, catégorie, champs personnalisés)
Comparaison - Comment effectuer la correspondance. L’une des options suivantes : eq, ne, gt, gte, lt, lte, in, nin
Valeur de filtrage - La valeur à comparer (une valeur unique ou un tableau pour in/nin)
Autorisations - Un tableau des opérations qui sont refusées lorsqu’un enregistrement correspond. Chaque entrée correspond à l’une des valeurs suivantes : read, edit, create, delete. Mettre une opération dans cette liste la bloque ; ne pas la mentionner l’autorise.

L’interface utilisateur d’administration des rôles présente ces éléments sous forme de colonnes « modèle », « action » et « chemin ».

Exemple de cas d’utilisation : séparation des sous-traitants

Scénario : Empêcher le sous-traitant A de voir le travail du sous-traitant B

Configuration :

Créer un rôle : « Prestataire A »
Ajouter une restriction de rôle :
- Modèle : feature
- Champ : owner
- Comparaison : eq
- Valeur du filtre : Prestataire B
- Autorisations (refusées) : read, edit, create, delete (les quatre sont bloquées)
Attribuer le rôle « Prestataire A » aux utilisateurs correspondant au prestataire A (depuis le profil de chaque utilisateur)

Résultat :

Les membres du groupe « Prestataire A » ne peuvent voir aucune fonctionnalité dont le propriétaire est « Prestataire B »
Pas seulement masqué dans l’interface utilisateur : l’API renvoie les données comme si les enregistrements n’existaient pas
Impossible de les consulter accidentellement via une capture d’écran, un appel API ou une exportation
Entièrement appliqué côté serveur

Cas d’utilisation supplémentaires

Par étape de travail : Empêcher les agents de terrain de consulter les rapports de validation du contrôle qualité :

Role: "Field Workers"
Restriction:
  Model: validation
  Field: status
  Comparison: ne
  Filter Value: "" (any value)
  Permissions (denied): read

Les agents de terrain ne peuvent en aucun cas consulter les validations.

Par type d’actif : Séparer les équipes chargées des infrastructures (poteaux/conduites vs équipements actifs) :

Role: "Civil Team"
Restriction:
  Model: feature
  Field: category
  Comparison: eq
  Filter Value: "Active Equipment"
  Permissions (denied): read, edit, create, delete

L'équipe des travaux publics ne peut ni voir ni modifier les entités d’équipements actifs.

Par nature physique/logique : Séparation de l’accès aux données de bureau (relations de capacité vs. emplacements des bureaux) :

Role: "Capacity Analysts"
Restriction:
  Model: feature
  Field: layer
  Comparison: eq
  Filter Value: "Office Locations"
  Permissions (denied): edit, create, delete

Les analystes peuvent visualiser les bureaux mais ne peuvent pas modifier leurs emplacements (lecture seule — la lecture n’est pas refusée).

Combinaison des droits d’administrateur et des restrictions de rôle

Comportement par défaut : Tous les utilisateurs peuvent tout voir mais ne peuvent rien modifier (sans droits d’administrateur).

Ajout d’un accès en écriture avec des restrictions :

Exemple : Les agents de terrain peuvent modifier leur propre travail mais pas celui des autres

Admin Rights:
  - reportsCreate: true
  - reportsUpdate: true

Role Restrictions:
  Model: report
  Field: submittedBy
  Comparison: ne
  Filter Value: [current user ID]
  Permissions (denied): edit

Résultat :

Les collaborateurs peuvent créer des rapports (droit d’administrateur accordé)
Les collaborateurs peuvent modifier UNIQUEMENT leurs propres rapports (la restriction de rôle exclut les autres)
Impossible de consulter ou de modifier les rapports des autres collaborateurs

Application côté serveur

Fonctionnement :

Toutes les requêtes sont filtrées avant le renvoi des données
Les restrictions de rôle sont appliquées au niveau du serveur (il ne s’agit pas simplement d’un masquage dans l’interface utilisateur)
Les utilisateurs ne peuvent pas contourner ces restrictions via des appels API directs, des outils de navigateur ou des exportations
Les données n’existent tout simplement pas pour les utilisateurs non autorisés

Implications en matière de sécurité :

Une capture d’écran de l’écran d’une autre personne ne servira à rien (les données ne s’afficheront pas pour vous)
Impossible d’exporter des données restreintes (le serveur applique les filtres)
Impossible de « deviner » les identifiants d’enregistrements (filtrés avant la recherche d’identifiant)
Les enregistrements hors de votre périmètre d’autorisations sont renvoyés comme « introuvables », même si vous connaissez l’identifiant

Gestion des rôles

Création de rôles :

Accédez à Admin → Rôles
Cliquez sur « Créer un rôle »
Saisissez le nom du rôle
Ajoutez des restrictions au rôle (vous pouvez en avoir plusieurs)
Enregistrez

La création d’un rôle nécessite le droit d’administrateur rolesCreate.

Modification des rôles :

Nécessite le droit d'administration rolesUpdate
Permet de modifier les restrictions
Permet de supprimer un rôle avec rolesDelete (ce qui libère les membres de ces restrictions)

Les rôles ne disposent pas de liste de membres à modifier ici — l'appartenance est définie au niveau de l'utilisateur, et non au niveau du rôle.

Appartenance à un rôle :

L’appartenance est associée à l’utilisateur (user.roles) ; ajoutez ou supprimez des rôles du profil d’un utilisateur
Les utilisateurs peuvent occuper plusieurs rôles (les restrictions s’additionnent)
Départ de l’organisation : supprimez tous les rôles de l’utilisateur avant de supprimer son compte

Personnalisation des autorisations pour les nouveaux utilisateurs

Configuration des paramètres de l’application (nécessite appSettingSchemasModify) :

Accédez aux paramètres de l’application
« Rôles par défaut » : les rôles attribués automatiquement aux nouveaux comptes
Enregistrez

Il n’existe pas de paramètre « droits d’administrateur par défaut » : les nouveaux utilisateurs ne disposent d’aucun droit d’administrateur au départ. Attribuez les droits à chaque utilisateur depuis son profil une fois le compte créé.

Configurations types :

Collaborateur de terrain :

Rôles par défaut : ["Field Workers"]
Droits d’administrateur attribués à l’utilisateur après la création : reportsCreate

Coordinateur administratif :

Rôles par défaut : aucun
Droits d’administrateur attribués à l’utilisateur après la création : workOrdersCreate, stockItemsCreate, stockItemsUpdate

Pas d’attribution automatique (vérification manuelle) :

Rôles par défaut : aucun
Les administrateurs attribuent manuellement les rôles et les droits après vérification du compte.

Affichage des autorisations effectives

Pour un utilisateur spécifique :

Accédez au profil de l’utilisateur
Section « Droits d’administrateur » : ce qu’il PEUT faire
Section « Rôles » : ce qu’il NE PEUT PAS voir (en raison des restrictions)
La vue combinée affiche les autorisations effectives

Tester les autorisations :

Connectez-vous en tant qu’utilisateur (ou vous faire passer pour lui avec des droits d’administrateur)
Naviguez normalement
Les données restreintes n’apparaissent tout simplement pas
Les actions nécessitant des droits d’administrateur sont désactivées/masquées

Bonnes pratiques

Commencez par des restrictions, accordez des droits au fur et à mesure des besoins :

Les nouveaux utilisateurs reçoivent des autorisations minimales
Ajoutez des droits d’administrateur en fonction des besoins liés aux rôles
Il est plus facile d’accorder des droits que de les révoquer (ce qui évite la « dérive des autorisations »)

Utiliser les rôles pour la visibilité des données :

Séparer les sous-traitants (pour empêcher l’accès aux informations concurrentielles)
Séparer les étapes de travail (contrôle qualité par rapport aux intervenants sur le terrain)
Séparer les types d’actifs (infrastructures par rapport aux équipements en service)

Utiliser les droits d’administrateur pour définir les capacités :

Qui peut créer des missions ?
Qui peut modifier l’inventaire ?
Qui peut accorder des autorisations ?

Documenter l’objectif des rôles :

Nom de rôle clair (« Sous-traitant A » est préférable à « Rôle 1 »)
Une description expliquant les restrictions
Cela aide les futurs administrateurs à comprendre l’intention

Audits réguliers des autorisations :

Révision trimestrielle des droits d’administrateur des utilisateurs
Suppression des droits inutilisés (changement de rôle de l’utilisateur)
Vérification de l’appartenance aux rôles (utilisateurs ayant quitté l’organisation)

Surveiller les tentatives d’accès :

Enregistrer les tentatives d’autorisation échouées
Une série de refus indique qu’un utilisateur tente un accès non autorisé
Enquêter et ajuster les autorisations ou former l’utilisateur

Principe du moindre privilège :

Accorder le minimum d’autorisations nécessaires à l’exercice de la fonction
Accès temporairement étendu pour les projets (à supprimer par la suite)
Droits super-administrateurs (adminRightsModify) réservés aux administrateurs de confiance