Aller au contenu

Module Paramètres

Chemin : Gestion du Système → Configuration.

Ce module couvre la configuration système : général (nom de l’application, fuseau horaire, format date/heure, langue, thème), gardes (quotas, repos, autorisations), sécurité (session, mot de passe, verrouillage), chaînes d’approbation et synchronisation externe (régions, structures, types de structures). Les préférences de notifications sont gérées par utilisateur dans le module Notifications.

En bref : que faire dans ce module ?

Objectif Où aller Guide pas à pas
Paramètres généraux (nom, fuseau, langue, thème) Configuration → Général Paramètres
Paramètres des gardes (quotas, repos) Configuration → Gardes Paramètres
Sécurité (session, mot de passe) Configuration → Sécurité Paramètres
Chaînes d'approbation / Sync externe Configuration → onglets correspondants Paramètres

1. Paramètres généraux

Aspects fonctionnels implémentés

  • Formulaire : nom de l’application, fuseau horaire (ex. Europe/Paris, Africa/Ouagadougou), format de date (ex. JJ/MM/AAAA), format d’heure (12 h / 24 h), langue (fr, en), thème (clair / sombre), sons activés ou non.
  • Sauvegarde : envoi au backend via l’endpoint dédié (ex. PATCH /api/system-config/general) ; payload structuré selon le schéma OpenAPI (settings.general, settings.appearance).
  • Application immédiate : après sauvegarde, la langue et le thème peuvent être appliqués immédiatement dans l’interface.
  • Validation : champs obligatoires et formats validés côté client et backend.

2. Paramètres des gardes

Aspects fonctionnels implémentés

  • Formulaire : nombre max de gardes par mois, repos minimal entre deux gardes (heures), nombre max de gardes consécutives, autorisation des gardes week-end, autorisation des gardes de nuit, approbation obligatoire ou non, affectation automatique ou non.
  • Sauvegarde : envoi via l’endpoint dédié (ex. PATCH /api/system-config/guard) ; payload (maxGuardsPerMonth, minRestHours, allowWeekendGuards, etc.).
  • Cohérence : ces paramètres sont utilisés pour la validation des plannings et des affectations (35 h minimum hebdo, 24 h de repos après garde de nuit, etc.) ; la source de vérité reste le backend (GET /system-config/workload, /guard-duty).
  • Affichage : les valeurs actuelles sont chargées au démarrage de l’écran (GET configuration).

3. Paramètres de sécurité

Aspects fonctionnels implémentés

  • Formulaire : durée de session (minutes), authentification à deux facteurs (activée ou non), longueur minimale du mot de passe, caractères spéciaux obligatoires, nombre de tentatives de connexion avant verrouillage, durée du verrouillage (minutes).
  • Sauvegarde : envoi via l’endpoint dédié (ex. PATCH /api/system-config/security) ; payload (sessionTimeout, requireTwoFactor, passwordMinLength, loginAttempts, lockoutDuration, etc.).
  • Politique de mot de passe : respect des règles configurées côté backend (Keycloak ou API) ; l’interface reflète les options modifiables par l’admin.
  • Sécurité : les mots de passe ne sont jamais affichés ni stockés en clair dans l’interface.

4. Chaînes d’approbation

Aspects fonctionnels implémentés

  • Liste : consultation des chaînes d’approbation par type de structure (CHU, CHR, AGSP, CNTS, SAMU, etc.).
  • Détail : pour chaque type, affichage des étapes (initiation, préapprobation, approbation, validation) et des acteurs par étape.
  • Import : chargement d’un fichier Excel ou JSON pour importer ou mettre à jour les chaînes ; format : feuille ou objet par type, colonnes Initiation, Préapprobation, Approbation, Validation.
  • Validation : vérification de la cohérence (ordre des étapes, acteurs, étape validation obligatoire) avant enregistrement ; appel à l’API (ex. POST /approval-chains/import, POST /approval-chains/validate).
  • Export : export des chaînes en JSON ou Excel pour sauvegarde ou modification hors ligne.
  • Provisioning : les rôles Keycloak peuvent être provisionnés selon les acteurs (géré côté backend).

5. Synchronisation externe

Aspects fonctionnels implémentés

  • Onglet / section : dédiée à la synchronisation des données organisationnelles depuis une API externe (régions, structures, types de structures, services).
  • Actions : synchroniser les régions, synchroniser les structures, synchroniser les types de structures, synchroniser les services, ou synchronisation globale (toutes les entités).
  • Statut : affichage du statut de la dernière sync par type d’entité (date, succès/échec, nombre d’enregistrements créés/mis à jour).
  • Historique : liste des synchronisations passées (date, type, statut, durée, erreurs éventuelles) si fournie par l’API.
  • Configuration : URL de l’API externe, fréquence (manuel, horaire, quotidien, hebdomadaire), règles de conflit (ex. priorité externe / locale), entités activées (selon ce que l’API expose).
  • Erreurs : en cas d’échec (timeout, API indisponible, données invalides), message clair et possibilité de relancer.
  • Audit : les opérations de sync sont tracées (audit log).

6. Structure des données et endpoints

Aspects fonctionnels implémentés

  • Schéma OpenAPI : les paramètres sont persistés selon le schéma SystemConfiguration ; pas d’envoi des champs gérés par le backend (id, updatedAt, updatedBy).
  • Mise à jour partielle : utilisation des endpoints par section (general, guard, security) pour des mises à jour ciblées ; ou PATCH /configuration pour une mise à jour globale.
  • Chargement : GET /api/system-config/configuration (ou équivalent) pour charger la configuration complète au chargement de l’écran Paramètres.
  • Réinitialisation : bouton « Réinitialiser aux valeurs par défaut » (POST /api/system-config/reset) si prévu par l’API.

Droits

  • Accès : réservé aux rôles administrateurs (ex. ADMIN, CHEF_STRUCTURE selon les règles métier) ; les autres utilisateurs n’ont pas accès au menu Paramètres.
  • Modification : certaines sections peuvent être restreintes (ex. sécurité réservée au super-admin).

Voir aussi