Acteurs et droits

Un besoin métier multi-profil

JCD Commerce V2 ne pouvait pas proposer les mêmes actions à tous ses utilisateurs. Le portail rassemble plusieurs entreprises clientes, chacune avec ses propres utilisateurs, adresses et documents. À l’intérieur d’un même compte, certains profils administrent l’organisation, tandis que d’autres consultent le catalogue, créent des devis ou transmettent des commandes. La validation ajoute un niveau supplémentaire : elle peut être confiée à une personne uniquement pour un groupe d’adresses donné.

L’enjeu métier était donc double : empêcher tout accès aux données d’un autre compte et limiter chaque action au rôle et au périmètre réellement attribués. Une interface différente selon le profil facilite l’usage, mais elle ne suffit pas à sécuriser l’application ; les règles doivent également être vérifiées par le serveur.

• Opérateur : dispose d’autorisations transverses pour administrer les comptes et accompagner les utilisateurs.
• Administrateur d’entreprise : gère les utilisateurs et les paramètres de son compte.
• Utilisateur : consulte le catalogue et gère les documents auxquels il a accès.
• Validateur local : accepte ou refuse les commandes du groupe d’adresses qui lui est attribué.

Principe des autorisations

J’ai organisé les autorisations en combinant plusieurs critères complémentaires. Le compte détermine d’abord l’espace de données accessible. Le rôle définit ensuite les responsabilités générales de l’utilisateur. Les groupes d’adresses précisent son périmètre local, notamment pour la validation, et le statut du document détermine enfin si une action reste possible à l’étape concernée.

Ce fonctionnement évite de résumer les droits à un unique profil. Un utilisateur peut, par exemple, consulter les documents de son compte sans pouvoir administrer ses collègues, ou valider une commande pour un groupe d’adresses sans obtenir ce droit sur l’ensemble de l’entreprise. Les contrôles sont appliqués lors de chaque opération sensible, indépendamment de ce que l’interface affiche.

Mise en œuvre avec Laravel

Laravel fournit le mécanisme utilisé pour traduire ces règles dans l’application. La notation `can:*` signifie qu’avant d’exécuter une action sensible, la route demande au serveur de vérifier une capacité précise, par exemple le droit de modifier ou de valider un document. Elle constitue donc une mise en œuvre concrète du principe d’autorisation, et non une règle métier à elle seule.

Le droit local de validation est enregistré par `can_validate` dans la relation entre un utilisateur et un groupe d’adresses. J’ai centralisé le calcul du périmètre accessible dans `WorkspaceContext`, afin que les requêtes tiennent systématiquement compte du compte, du rôle et des groupes concernés. Cette organisation limite la dispersion des règles et permet de les vérifier par des tests ciblés.

Le rôle global et le périmètre local deviennent ainsi des invariants contrôlés par le serveur et les tests.