Authentification et contrôle d’accès : sécuriser un back-office multi-rôles

Cet article fait partie d’une série consacrée aux back-offices Angular de Rezo Pouce. Après avoir présenté les deux applications et leur architecture commune puis l’architecture de l’espace d’administration, ce volet aborde la sécurité : comment authentifier les utilisateurs, protéger les routes et adapter l’interface en fonction des droits de chacun. Les articles suivants détailleront la gestion des territoires, le pilotage du service Rezo Séniors et la cartographie.

Le problème

Un back-office d’administration n’est pas une application ouverte. Chaque utilisateur ne doit accéder qu’aux données qui relèvent de sa responsabilité. Un référent Séniors d’un territoire donné n’a pas à consulter les trajets d’un autre territoire. Un consultant peut visualiser des données sans pouvoir les modifier. Un gestionnaire national supervise l’ensemble du réseau là où un gestionnaire local ne voit que son périmètre.

Cette granularité impose un système de sécurité à plusieurs niveaux : d’abord vérifier que l’utilisateur est bien authentifié, puis qu’il possède le rôle requis pour la page demandée, et enfin qu’il a accès au territoire ou au module concerné. Le tout sans que cette mécanique ne soit visible pour l’utilisateur — quand tout fonctionne, la sécurité est transparente.

L’authentification JWT

L’application utilise une authentification par JSON Web Token (JWT). L’utilisateur saisit son identifiant et son mot de passe sur la page de connexion. Ces informations sont envoyées à l’API Rezo Pouce, qui authentifie l’utilisateur en croisant les données de deux API — la sienne et celle de Mobicoop — avant de retourner un token. Ce token est stocké côté navigateur et sera automatiquement joint à chaque requête HTTP ultérieure.

La session a une durée de vie de huit heures. Ce choix correspond à une journée de travail : un référent se connecte le matin et peut travailler toute la journée sans être interrompu. Au-delà de huit heures, le token expire et l’utilisateur est redirigé vers la page de connexion. La déconnexion manuelle supprime le token et ramène à l’écran d’identification.

Les intercepteurs HTTP

Deux mécanismes invisibles travaillent en arrière-plan sur chaque requête HTTP émise par l’application.

Le premier intercepte les requêtes sortantes pour y injecter automatiquement le token d’authentification. Sans ce mécanisme, chaque service Angular devrait gérer manuellement l’ajout du token — une répétition source d’erreurs et d’oublis. L’intercepteur centralise cette responsabilité : dès qu’un token existe, il est ajouté à chaque requête sans que le développeur n’ait à y penser.

Le second intercepte les réponses entrantes pour gérer les cas d’erreur. Si l’API retourne une erreur d’authentification — token expiré ou invalide —, l’utilisateur est automatiquement déconnecté et redirigé vers la page de connexion. Si l’API retourne une erreur de droits insuffisants, une notification discrète informe l’utilisateur. Les erreurs serveur sont également interceptées et affichées de manière compréhensible. Ce traitement centralisé évite de dupliquer la gestion d’erreurs dans chaque composant de l’application.

Un service complémentaire suit en temps réel les requêtes en cours. Il sert deux objectifs : afficher des indicateurs de chargement quand une opération est en attente, et empêcher la fermeture accidentelle de la page pendant qu’une sauvegarde est en cours — une précaution appréciable quand un référent vient de remplir un formulaire complexe.

La hiérarchie des rôles

Le système de rôles reflète l’organisation réelle de Rezo Pouce. Chaque acteur du réseau possède un rôle qui détermine ce qu’il peut voir et ce qu’il peut faire dans le back-office.

Pour la gestion des territoires, la hiérarchie distingue plusieurs niveaux. Le consultant accède aux données en lecture seule. L’animateur local gère l’animation de son territoire. L’animateur national a la même capacité sur l’ensemble des territoires. Le gestionnaire de territoire administre la configuration de son périmètre — communes, points d’arrêt, paramètres. Le gestionnaire national supervise tous les territoires et peut intervenir sur n’importe lequel.

Pour le service Rezo Séniors, la structure est plus simple : un consultant qui peut visualiser les données, un gestionnaire de territoire qui administre le service localement, et un gestionnaire national qui a la main sur l’ensemble des territoires et qui gère les éléments transversaux comme les chartes du service.

Au sommet de cette hiérarchie, l’administrateur hérite de l’ensemble des droits de tous les rôles — une commodité pour le support technique, pas un rôle de travail quotidien.

Le principe d’héritage est central : un gestionnaire national possède automatiquement tous les droits d’un gestionnaire local, qui possède lui-même les droits d’un consultant. Il n’est pas nécessaire d’attribuer chaque rôle individuellement — un seul rôle suffit, et la hiérarchie détermine les droits effectifs.

Les guards : protéger les routes

Angular, offre un mécanisme de guards — des vérifications exécutées avant qu’une page ne s’affiche. L’application en utilise plusieurs, organisés en cascade.

Le premier niveau vérifie l’authentification : l’utilisateur possède-t-il un token valide et sa session n’a-t-elle pas expiré ? Si ce n’est pas le cas, il est redirigé vers la page de connexion. C’est la protection de base, appliquée à toutes les routes de l’application.

Le deuxième niveau vérifie le rôle : l’utilisateur possède-t-il le rôle requis pour accéder à cette section de l’application ? Un utilisateur qui ne possède aucun rôle lié aux territoires ne pourra pas accéder au module de gestion des territoires, même s’il est correctement authentifié. En cas de rôle insuffisant, il est redirigé vers le tableau de bord avec une notification explicite.

Le troisième niveau est contextuel. Pour le module territoires, un guard vérifie que l’utilisateur a effectivement accès au territoire spécifié dans l’URL — être gestionnaire de territoire ne suffit pas, il faut être gestionnaire de ce territoire. Pour le module séniors, un guard équivalent vérifie l’accès au territoire concerné par les données consultées.

Cette cascade garantit qu’un utilisateur ne peut pas contourner les protections en saisissant directement une URL dans le navigateur. Chaque niveau filtre indépendamment, et tous doivent autoriser l’accès pour que la page s’affiche.

Adapter l’interface aux droits

Protéger les routes ne suffit pas. L’interface elle-même doit refléter les droits de l’utilisateur. Un consultant qui accède à une fiche de territoire ne doit pas voir de bouton de modification. Un gestionnaire local ne doit pas voir les options réservées à l’administration nationale.

Chaque module fonctionnel dispose de son propre service de contrôle des droits qui détermine, en fonction du rôle de l’utilisateur connecté, ce qui doit être affiché ou masqué. Les boutons d’édition n’apparaissent que pour les utilisateurs autorisés à modifier. Les formulaires de paramétrage ne sont accessibles qu’aux gestionnaires. Certaines sections entières de l’interface sont conditionnées au rôle.

Cette adaptation ne remplace pas la protection côté API — les vérifications de droits existent aussi côté serveur. Mais elle évite de présenter à l’utilisateur des actions qu’il ne pourra pas exécuter, ce qui rend l’interface plus lisible et réduit la confusion.

Ce que ce système illustre

L’authentification et le contrôle d’accès d’un back-office multi-rôles sont un travail d’architecture qui se joue à trois niveaux : le transport (le token JWT injecté automatiquement), la navigation (les guards qui protègent les routes), et l’affichage (l’adaptation de l’interface aux droits).

La difficulté n’est pas dans chaque mécanisme pris isolément — un intercepteur HTTP, un guard Angular, un service de vérification de rôle sont des patterns bien documentés. La difficulté est dans leur coordination : s’assurer que chaque couche joue son rôle sans empiéter sur les autres, que la hiérarchie des rôles est respectée partout de la même manière, et que l’expérience utilisateur reste fluide malgré ces contrôles permanents.

C’est aussi un cas où la modélisation des rôles a été dictée par l’organisation humaine du réseau, pas par des contraintes techniques. Les rôles de consultant, d’animateur, de gestionnaire local et national correspondent à des fonctions réelles au sein de Rezo Pouce. Le système technique ne fait que traduire cette organisation en règles d’accès.