Paramètres système

Les paramètres système régissent le comportement global de l'application : qui peut s'inscrire, la durée des sessions, la durée de conservation des enregistrements supprimés et les autorisations dont disposent les nouveaux utilisateurs dès leur inscription. Les paramètres sont gérés sous Admin → Paramètres de l'application et nécessitent le droit d'administrateur appSettingSchemasModify.

Architecture de sécurité

Aptli utilise un modèle de sécurité à quatre niveaux, appliqué côté serveur :

Couche 1 : Authentification

Qui vous êtes — vérifie l'identité de l'utilisateur avant l'accès.

Connexion par mot de passe (avec des exigences de complexité)
Fournisseurs OAuth (GitHub, Google)
Authentification à deux facteurs (TOTP)
Validation par e-mail requise
Gestion des sessions avec expiration
Verrouillage définitif après plusieurs tentatives infructueuses

Couche 2 : Droits d'administrateur (permissifs)

Ce que vous POUVEZ modifier - octroi explicite de permissions.

Permissions de création/mise à jour/suppression par modèle
Super-droits : appSettingSchemasModify, adminRightsModify, viewDeleted
Limité aux actions (peut créer mais pas supprimer)
Par défaut : accès en lecture seule

Couche 3 : Restrictions de rôle (Restrictif)

Ce que vous NE POUVEZ PAS voir - filtres de données au niveau des champs.

Filtres modèle + champ + comparaison + valeur
Appliqués côté serveur avant la requête de base de données
Impossible à contourner via des appels API, des exportations ou des captures d'écran
Combinaison de plusieurs restrictions (logique ET)

Couche 4 : Application côté serveur

Les restrictions sont appliquées sur le serveur — les données non autorisées ne sont jamais envoyées à votre navigateur.

Pourquoi est-ce important :

Filtrage côté client : données envoyées au navigateur, masquées par JavaScript (contournables via les outils de développement)
Filtrage côté serveur : données jamais envoyées aux utilisateurs non autorisés (sécurisé)

Aptli applique tous les filtres sur le serveur — les données non autorisées n'atteignent jamais le client.

Paramètres de l'application

Accès requis : appSettingSchemasModify droit d'administrateur

Accédez à : Admin → Paramètres de l'application

Paramètres d'authentification

Domaines autorisés :

Liste des domaines de messagerie pouvant créer des comptes
Exemple : ["company.com", "contractor.com"]
Seuls les e-mails provenant de ces domaines peuvent s'inscrire
Par défaut : votre domaine de déploiement

Autoriser l'inscription :

true - Les utilisateurs peuvent s'inscrire eux-mêmes si le domaine correspond
false - L'administrateur doit créer manuellement les comptes
Par défaut : false (accès contrôlé)

Méthodes de connexion actives :

Nom d'utilisateur/mot de passe (case à cocher)
GitHub OAuth (case à cocher)
Google OAuth (case à cocher)
Au moins une méthode doit être activée
Par défaut : nom d'utilisateur/mot de passe uniquement

Exiger l'authentification à deux facteurs :

true - Tous les utilisateurs doivent activer l'authentification à deux facteurs (période de grâce configurable)
false - Authentification à deux facteurs facultative
Par défaut : false

Sécurité de la session

Nombre maximal de tentatives de connexion :

Nombre de tentatives de connexion infructueuses avant le verrouillage définitif
Plage valide : 3 à 10 tentatives
Par défaut : 5

Délai de déconnexion automatique :

Délai d'inactivité en secondes
La lecture/écriture de données réinitialise le compte à rebours
Plage valide : 1 heure à 7 jours
Par défaut : 86400 (1 jour)

Délai d'expiration de la session serveur :

Délai d'expiration de la session serveur en minutes
Force une nouvelle connexion quelle que soit l'activité
Plage valide : 1 heure - 4 semaines
Par défaut : 10080 (1 semaine)

Expiration de la session :

Durée maximale absolue de la session
S'aligne sur le jeton CSRF pour les utilisateurs utilisant un seul appareil
Les utilisateurs multi-appareils peuvent avoir des durées d'expiration différentes
Par défaut : 10080 minutes (1 semaine)

Conservation des données

Conservation des enregistrements supprimés temporairement :

Durée pendant laquelle les enregistrements supprimés temporairement restent dans la base de données
Options : 30 jours, 90 jours, 1 an, indéfiniment
Par défaut : 90 days
S'applique aux affectations, rapports, utilisateurs, fonctionnalités (lorsque deletedAt est défini)

Calendrier de compression des versions :

Fréquence de compression des anciennes versions des fonctionnalités
Options : hebdomadaire, mensuelle, trimestrielle
Par défaut : Monthly
Les versions compressées restent reconstituables (compression sans perte)

Historique des transactions :

Les transactions d'inventaire ne sont jamais supprimées (piste d'audit immuable)
Peut être archivé dans une base de données distincte (configuration avancée)

Paramètres par défaut pour les nouveaux utilisateurs

Rôles pour les nouveaux utilisateurs :

Tableau d'identifiants de rôle attribués automatiquement
Tableau vide = aucune restriction automatique
Par défaut : [] (attribué manuellement par l'administrateur)

Droits d'administrateur pour les nouveaux utilisateurs :

Tableau de chaînes de droits d'accès
Tableau vide = accès en lecture seule
Par défaut : [] (pas de droits d'écriture)

Exemples de configurations :

Paramètres par défaut pour les agents de terrain :

{
  "roles": ["field_worker_role_id"],
  "adminRights": ["reportsCreate"]
}

Paramètres par défaut pour les coordinateurs de bureau :

{
  "roles": [],
  "adminRights": ["assignmentsCreate", "ordersCreate", "stockItemsView"]
}

Clés API

Les clés API permettent à un système externe d'appeler Aptli sans connexion humaine — pour la synchronisation ArcGIS/Postgres, l'export vers un entrepôt de données ou vos propres outils. Gestion dans Admin → Paramètres de l'application → Clés API. Nécessite appSettingSchemasModify.

Limites

Maximum 3 clés par déploiement. Révoquez une clé existante avant d'en créer une nouvelle.
Chaque clé dispose de son propre compteur de limitation de débit isolé (mêmes seuils qu'un utilisateur interactif : ~2 700 requêtes/minute en lecture, ~900/minute en écriture). Une intégration très active ne peut pas bloquer les quotas d'une autre clé ni des utilisateurs humains.

Clés en lecture seule

Lors de la création d'une clé, vous pouvez activer Lecture seule. Une clé en lecture seule est bloquée pour toutes les requêtes d'écriture (POST / PUT / PATCH / DELETE) au niveau de la session — même si des droits d'écriture ont été accordés.

Création d'une clé

Admin → Paramètres de l'application → Clés API → Générer une clé
Donnez un nom à la clé (ex. Synchronisation ArcGIS).
Choisissez les droits d'administration à accorder. Vide = aucun droit d'écriture (recommandé sauf si l'intégration doit écrire).
Activez Lecture seule si l'intégration ne fait que lire.
Copiez la clé — elle est affichée une seule fois et ne peut pas être récupérée.

Révocation d'une clé

Cliquez sur Révoquer à côté de la clé dans le tableau. La révocation est immédiate.

Santé des communications

La page des paramètres comprend une section repliée Santé des communications (entre la liste Environnement et la Zone de danger). Ouvrez-la pour voir l'état en direct des pipelines de messagerie :

Livraison E-mail / SMS / Push — indique si les identifiants du fournisseur sont configurés, et combien de messages sont en attente ou en cours de nouvelle tentative dans chaque file. Une clé de fournisseur manquante ne produit pas d'erreurs : les messages s'accumulent silencieusement dans la file indéfiniment, et c'est dans ce panneau que cela devient visible.
Quota SMS — quand un plafond mensuel de SMS est défini pour le déploiement, la ligne SMS affiche utilisés/plafond pour le mois en cours et passe à l'orange quand le plafond est atteint.
Backend de file d'attente — indique si le magasin de tâches (Valkey) est connecté ; un avertissement de repli en mémoire signifie que les messages en file seront perdus au redémarrage.
Destinataires des alertes de sécurité — le nombre d'adresses qui recevront les alertes de verrouillage de compte et de quota. Zéro signifie que ces alertes ne sont envoyées nulle part ; configurez les destinataires sur cette même page.
Couverture des domaines e-mail — quand une liste de domaines autorisés est active, le nombre d'utilisateurs actifs dont le domaine e-mail est sorti de la liste (ils ne peuvent recevoir aucun e-mail tant que la liste n'est pas mise à jour ou qu'ils ne sont pas archivés).

Les lignes affichent une coche verte quand tout est sain et un avertissement orange dans le cas contraire. Utilisez Actualiser pour relancer l'interrogation après avoir modifié la configuration de l'environnement.

Déploiement auto-hébergé

Pour les instructions de déploiement auto-hébergé, consultez le Guide de l'administrateur système.

Bonnes pratiques de sécurité

SSL/TLS requis :

Utilisez HTTPS en production (pas HTTP)
Certificats gratuits : Let's Encrypt
Refuser les connexions HTTP (rediriger vers HTTPS)

Configuration du pare-feu :

Autoriser : HTTPS (443), SSH (22)
Refuser : les ports de base de données depuis l'Internet public
Restreindre : les pages d'administration au VPN ou à une liste blanche d'adresses IP

Sécurité des sessions :

Les clés de signature de session doivent être longues, aléatoires et renouvelées tous les trimestres
Utilisez une durée d'expiration de session courte dans les environnements hautement sécurisés
Consultez le Guide de déploiement pour la configuration des sessions côté serveur

Sécurité de la base de données :

Authentification de la base de données activée
Identifiants utilisateur distincts (pas root)
Connexions à la base de données chiffrées
Sauvegardes régulières (automatisées, restauration testée)

Secrets OAuth :

Stocker dans des variables d'environnement (et non dans le code)
Renouveler tous les trimestres
Révoquer les applications OAuth inutilisées

Sécurité du téléchargement de fichiers :

Analyse des fichiers activée en production
Limites de taille des fichiers appliquées
Types de fichiers autorisés restreints
Mise en quarantaine des fichiers suspects

Surveillance :

Tentatives de connexion échouées (détection des attaques par force brute)
Échecs d'autorisation (détection des tentatives d'accès non autorisées)
Modèles d'utilisation inhabituels de l'API
Échecs de connexion à la base de données

Considérations relatives à la conformité

Résidence des données : Le mode auto-hébergé permet de contrôler l'emplacement des données :

Hébergement dans une région géographique spécifique
Respect des exigences réglementaires (RGPD, HIPAA, etc.)
Contrôle physique de l'accès aux données

Piste d'audit : Aptli conserve des pistes d'audit pour :

Les tentatives d'authentification (réussites/échecs)
L'utilisation des droits d'administrateur (qui a modifié quoi)
Les modifications des restrictions de rôle
L'historique des transactions (mouvements de stock)
L'historique des versions (modifications des fonctionnalités)
Les suppressions temporaires (qui a supprimé quoi, quand)

Exportation des données : Toutes les données sont exportables à des fins de conformité :

Exportation CSV pour les données non géographiques
Exportation GeoJSON pour les entités (via le bouton « Transfert de données » dans la barre d'outils de la carte)
Rapports de transactions (audit des stocks)
Journaux d'accès des utilisateurs

Conservation des données : Politiques de conservation configurables :

Durée de conservation des suppressions temporaires
Compression des versions (sans perte)
Historique des transactions (immuable - jamais supprimé)
Journaux d'audit (archivage configurable)