Introduction
Dans les premiers stades d’un projet logiciel, la gestion des accès est souvent simple. Une application peut fonctionner avec quelques rôles standards :
- Admin
- Editor
- User
Ce modèle fonctionne très bien dans un prototype, un outil interne ou une petite application.
Cependant, lorsque le logiciel devient une plateforme métier utilisée par plusieurs équipes, départements ou organisations, cette approche atteint rapidement ses limites.
Dans les logiciels développés pour les entreprises, les besoins sont beaucoup plus complexes :
- certains utilisateurs peuvent voir certaines données mais pas les modifier
- certains managers peuvent approuver des opérations
- certaines équipes doivent accéder uniquement à leurs propres données
- certaines informations doivent rester confidentielles
Autrement dit, les rôles seuls ne suffisent plus.
Les applications professionnelles nécessitent une architecture d’autorisations structurée permettant de gérer :
- des permissions granulaires
- plusieurs rôles par utilisateur
- des règles dynamiques
- une isolation entre entreprises
- une traçabilité des actions
- une architecture maintenable dans le temps
Ce guide présente les principes utilisés chez Tekru pour concevoir une architecture d’autorisations robuste dans des applications Node.js / TypeScript.
Ce contenu est notamment inspiré par la réflexion présentée dans cette vidéo pédagogique :
https://www.youtube.com/watch?v=AAEnEKT0GhY
Dans ce guide, vous allez découvrir
Dans ce guide, nous allons parcourir pas à pas les principes permettant de concevoir une architecture d’autorisations robuste pour des applications métiers à grande échelle.
L’objectif est de comprendre comment passer d’un simple système de rôles à une architecture d’accès complète, capable de supporter la croissance d’un logiciel professionnel.
Voici ce que nous allons explorer :
1. Comprendre pourquoi les systèmes de rôles classiques deviennent rapidement insuffisants
Nous verrons pourquoi un modèle simple basé sur admin / editor / user fonctionne dans un petit projet mais devient rapidement limitant dans une application métier.
2. Les quatre dimensions fondamentales du contrôle d’accès
Nous analyserons les questions clés que doit résoudre un système d’autorisations moderne :
qui accède, quelles actions sont autorisées, sur quelles ressources, et dans quel contexte.
3. Le modèle RBAC comme fondation de l’architecture
Nous expliquerons comment structurer les rôles et permissions pour construire un système clair, maintenable et évolutif.
4. La conception de la base de données pour gérer les permissions
Nous détaillerons les tables nécessaires pour structurer correctement les utilisateurs, rôles, permissions et leurs relations.
5. L’organisation des permissions et les conventions de nommage
Nous verrons pourquoi structurer les permissions sous la forme ressource.action simplifie énormément la maintenance et la lisibilité du système.
6. L’isolation entre entreprises dans les applications multi-tenant
Nous expliquerons comment concevoir une architecture permettant à plusieurs organisations d’utiliser la même plateforme tout en gardant leurs données complètement isolées.
7. Les policies d’autorisation pour gérer les règles métier complexes
Nous verrons comment introduire des règles dynamiques basées sur le contexte : propriété d’un document, état d’une ressource ou périmètre d’équipe.
8. Le pipeline de décision d’accès dans une application professionnelle
Nous décrirons les différentes étapes qu’une requête traverse avant d’être autorisée ou refusée.
9. Les stratégies de performance et de cache pour les permissions
Nous verrons pourquoi les permissions doivent être mises en cache et comment éviter des requêtes inutiles vers la base de données.
10. L’audit logging et la traçabilité des actions
Nous expliquerons comment enregistrer les actions sensibles afin de garantir la sécurité, la transparence et la conformité.
11. Les bonnes pratiques de sécurité pour les architectures d’autorisations
Enfin, nous présenterons plusieurs principes essentiels pour maintenir un système sécurisé sur le long terme.
À la fin de ce guide, vous disposerez d’une vision claire et structurée de l’architecture d’autorisations utilisée dans les applications professionnelles modernes, et des principes permettant de l’implémenter proprement dans une architecture Node.js / TypeScript.
1. La différence entre un système simple et un système enterprise
Dans un projet simple, la gestion des accès se résume souvent à quelques rôles.
Exemple d’un système simple
| Rôle | Capacité |
|---|---|
| Admin | Accès complet |
| Editor | Modifier le contenu |
| User | Lecture uniquement |
La logique d’accès peut alors se limiter à une condition simple :
si utilisateur est admin → autoriser
Ce modèle est rapide à implémenter mais devient fragile lorsque le logiciel évolue.
Exemple d’un système enterprise
Dans une application métier, les autorisations doivent être beaucoup plus précises.
Par exemple :
- un utilisateur peut consulter des rapports
- un manager peut approuver certaines opérations
- un analyste peut exporter certaines données
- un auditeur peut uniquement consulter certaines informations
Les permissions deviennent alors explicites :
- users.create
- users.update
- reports.view
- finance.approve
- analytics.export
Chaque permission décrit une action précise sur une ressource précise.
Cette granularité permet de sécuriser l’application tout en restant flexible.
2. Les quatre dimensions de l’accès dans une application métier
Un système d’autorisations professionnel doit répondre à quatre questions fondamentales.
Qui accède au système
La première dimension est l’identité.
Le système doit identifier :
- l’utilisateur
- son organisation
- son département
- ses rôles
Cette étape correspond à l’authentification.
Quelles actions sont autorisées
Chaque action doit être définie explicitement.
Les actions les plus fréquentes sont :
- create
- read
- update
- delete
- approve
- export
- validate
Une bonne architecture transforme ces actions en permissions structurées.
Exemples :
users.create
users.read
users.update
users.delete
Sur quelles ressources
Dans beaucoup d’applications métiers, l’accès dépend du périmètre des données.
Un utilisateur peut :
- modifier uniquement ses propres documents
- consulter les données de son équipe
- accéder à toutes les données
Cette notion est essentielle pour éviter des accès trop larges.
Dans quel contexte
Certaines autorisations dépendent également du contexte métier.
Par exemple :
- un document ne peut être modifié que s’il est en brouillon
- une demande doit être approuvée par un manager
- certaines opérations sont limitées à certaines équipes
Ces règles nécessitent une logique d’autorisation dynamique.
3. RBAC : la base de l’architecture d’autorisations
La plupart des architectures d’autorisations reposent sur RBAC (Role Based Access Control).
Le principe est simple.
Un utilisateur possède un ou plusieurs rôles.
Un rôle possède plusieurs permissions.
Le flux logique devient :
Utilisateur → rôles → permissions
Cette structure simplifie énormément la gestion des accès.
Au lieu d’attribuer des permissions directement aux utilisateurs, elles sont regroupées dans des rôles.
Exemple
Rôle Admin
- users.create
- users.update
- users.delete
- finance.approve
Rôle Analyst
- reports.read
- analytics.view
Rôle Viewer
- reports.read
Si un utilisateur change de fonction, il suffit de modifier son rôle.
4. Architecture de base de données recommandée
Une architecture RBAC repose généralement sur plusieurs tables principales.
Tables principales
users
roles
permissions
Ces tables représentent :
- les utilisateurs
- les rôles
- les permissions disponibles
Tables pivot
Certaines relations nécessitent des tables intermédiaires.
user_roles
role_permissions
Ces tables permettent :
- plusieurs rôles par utilisateur
- plusieurs permissions par rôle
Permissions directes
Dans certains cas, un utilisateur doit recevoir une permission spécifique.
Une table supplémentaire peut être utilisée :
user_permissions
Cela permet de gérer :
- des exceptions
- des accès temporaires
5. Organisation des permissions
Pour maintenir une architecture lisible, les permissions doivent suivre une convention.
La convention la plus utilisée est :
ressource.action
Exemples :
users.create
users.read
users.update
users.delete
reports.view
reports.export
finance.approve
Cette approche permet :
- une meilleure lisibilité
- une gestion plus simple côté API
- une intégration claire avec le front-end
6. Isolation entre entreprises (multi-tenant)
Même lorsqu’un logiciel est développé pour un client spécifique, il est fréquent que plusieurs entités utilisent la plateforme :
- filiales
- partenaires
- franchises
- départements indépendants
- entreprises clientes d’un groupe
Dans ce cas, il est important d’introduire la notion de multi-tenant.
Chaque entreprise possède :
- ses utilisateurs
- ses rôles
- ses données
- ses permissions
Pour garantir cette isolation, une table supplémentaire est utilisée :
tenants
La plupart des tables critiques contiennent ensuite une colonne :
tenant_id
Chaque requête doit inclure ce filtre.
Cette approche garantit qu’aucune donnée ne peut être visible entre deux entreprises différentes.
7. Authorization policies
Les rôles et permissions ne suffisent pas toujours.
Certaines règles dépendent de la logique métier.
On utilise alors des policies d’autorisation.
Une policy est une fonction ou une classe qui détermine si une action est autorisée.
Exemple : ownership
Un utilisateur peut modifier uniquement les documents qu’il a créés.
Exemple : état d’une ressource
Un document ne peut être modifié que s’il est en statut brouillon.
Exemple : périmètre d’équipe
Un manager peut approuver uniquement les demandes de son équipe.
Ces règles introduisent une logique métier dans l’autorisation.
8. Pipeline de décision d’accès
Dans une architecture professionnelle, une autorisation ne dépend pas d’une seule vérification.
Elle passe par plusieurs étapes.
1 authentification de l’utilisateur
2 récupération des rôles
3 récupération des permissions
4 ajout des permissions directes
5 vérification du tenant
6 application des policies
Si une étape échoue, l’accès est refusé.
Ce pipeline garantit un contrôle robuste.
9. Performance et cache
Dans une application importante, les vérifications de permissions sont très fréquentes.
Chaque requête API peut nécessiter plusieurs vérifications.
Sans optimisation, cela peut provoquer :
- un grand nombre de requêtes SQL
- des ralentissements
- une mauvaise scalabilité
La solution consiste à utiliser un cache des permissions.
Les permissions sont chargées lors de l’authentification et stockées en mémoire.
Les vérifications suivantes ne nécessitent plus de requête base de données.
Des systèmes comme Redis permettent d’obtenir des temps de réponse extrêmement rapides.
10. Audit logging et traçabilité
Dans les applications professionnelles, la traçabilité est essentielle.
Un système d’audit doit enregistrer :
- l’utilisateur
- l’action
- la ressource
- l’heure
- l’adresse IP
- l’entreprise concernée
Ces informations permettent :
- d’identifier des activités suspectes
- de répondre aux exigences réglementaires
- d’analyser l’usage du système
- de résoudre des incidents
Sans audit logging, un système n’est pas considéré comme production ready.
11. Bonnes pratiques de sécurité
Certaines pratiques sont indispensables pour maintenir un système sécurisé.
Principe du moindre privilège
Chaque utilisateur doit recevoir uniquement les permissions nécessaires.
Éviter les vérifications codées en dur
Les conditions comme :
si rôle = admin
doivent être évitées.
Elles rendent le système difficile à maintenir.
Journaliser les actions sensibles
Certaines actions doivent toujours être enregistrées :
- modification des permissions
- export de données
- approbation financière
Vérifier toutes les routes API
Chaque endpoint doit vérifier :
- l’authentification
- les permissions
- la validité des données
12. Implémentation typique dans une architecture Node.js / TypeScript
Dans une architecture moderne Node.js, l’autorisation est généralement structurée en plusieurs couches.
Couche middleware
Le middleware vérifie :
- l’authentification
- les permissions de base
Couche policy
Une couche policy applique les règles métier.
Couche service
La logique métier est exécutée uniquement si les vérifications précédentes sont validées.
Exemple de flux
Request API
↓
Middleware (authentification)
↓
Middleware (permission check)
↓
Policy (ownership ou règles métier)
↓
Service métier
Cette séparation garantit :
- un code maintenable
- une sécurité claire
- une architecture évolutive
Conclusion
Une architecture d’autorisations professionnelle repose sur plusieurs couches complémentaires :
- rôles
- permissions
- policies
- isolation multi-entreprises
- audit logging
- cache des autorisations
Lorsqu’elles sont correctement combinées, ces couches permettent de construire des applications :
- sécurisées
- évolutives
- maintenables
- adaptées aux environnements métiers complexes
Chez Tekru, ce type d’architecture est fréquemment utilisé dans des plateformes manipulant des volumes importants de données, des règles métier avancées et des accès multi-organisations.
Une bonne architecture d’autorisations n’est pas seulement une question technique.
C’est une fondation essentielle pour construire des logiciels robustes et durables.
