On commence par un Gate::define, on finit avec une forêt de conditions illisibles
Toute application web gère des permissions. Qui peut voir quoi, qui peut faire quoi, dans quel contexte. Le problème, c'est que ces règles s'accumulent rarement selon un plan : une vérification ajoutée ici, un rôle glissé là, un middleware bricolé ailleurs. Deux ans plus tard, personne ne comprend plus le système dans sa globalité, et chaque nouvelle règle métier devient une source d'angoisse.
Cet article s'appuie sur une analyse publiée par Hossein Hezami sur dev.to autour de sept architectures d'autorisation observées en production dans des applications Laravel. Les principes dégagés s'appliquent directement à Symfony, qui propose des mécanismes comparables : voters, security.yaml, expressions, rôles hiérarchiques. L'objectif ici n'est pas de traduire l'article, mais d'en extraire ce qui est utile pour choisir une architecture adaptée à la complexité réelle d'un projet PHP.
Les trois grandes familles d'autorisation
Les permissions plates : simples, mais vite limitées
La forme la plus basique consiste à attacher des permissions directement à des utilisateurs ou à des rôles sans hiérarchie. Un utilisateur a le rôle editor, ce rôle donne accès à la publication d'articles. C'est lisible, rapide à implémenter, et suffisant pour un projet de petite taille.
La limite arrive quand le métier se complexifie. Que se passe-t-il quand un éditeur ne peut publier que ses propres articles ? Ou seulement dans certaines catégories ? On commence alors à multiplier les rôles pour couvrir chaque cas, et la liste devient ingérable.
En Symfony, ce pattern correspond aux rôles définis dans security.yaml avec access_control. Pratique pour les applications CRUD simples, mais insuffisant dès que la logique dépend d'attributs contextuels.
Le RBAC (Role-Based Access Control) : la référence pour les SaaS
Le contrôle d'accès basé sur les rôles organise les permissions autour de rôles métier cohérents : admin, manager, viewer. Chaque rôle hérite d'un ensemble de permissions, et les utilisateurs se voient attribuer un ou plusieurs rôles.
Symfony gère nativement la hiérarchie des rôles :
security:
role_hierarchy:
ROLE_ADMIN: [ROLE_MANAGER, ROLE_USER]
ROLE_MANAGER: ROLE_USER
Ce modèle couvre la plupart des besoins d'une application SaaS classique. Il est lisible, testable, et facile à expliquer à une équipe. Son point faible : il ne gère pas les conditions dynamiques. Un ROLE_MANAGER peut-il modifier une commande déjà expédiée ? Cette règle ne se modélise pas avec un rôle seul.
L'ABAC (Attribute-Based Access Control) : pour la logique métier complexe
L'ABAC évalue des attributs, ceux de l'utilisateur, de la ressource, et du contexte, pour décider si une action est autorisée. C'est le modèle le plus expressif, et le plus exigeant à maintenir.
En Symfony, les voters sont le mécanisme natif pour implémenter ce type de logique :
class OrderVoter extends Voter
{
protected function supports(string $attribute, mixed $subject): bool
{
return $attribute === 'EDIT' && $subject instanceof Order;
}
protected function voteOnAttribute(string $attribute, mixed $subject, TokenInterface $token): bool
{
$user = $token->getUser();
if ($subject->getStatus() === 'shipped') {
return false;
}
return $subject->getOwner() === $user;
}
}
Avec ce pattern, la règle métier est encapsulée dans une classe dédiée, testable unitairement, et indépendante du contrôleur. C'est la bonne réponse quand les décisions d'accès dépendent de l'état d'une ressource.
Comment choisir selon la complexité réelle du projet
L'article source propose une matrice de décision que l'on peut adapter au contexte Symfony/PHP :
- Blog ou site vitrine avec quelques rôles :
access_control dans security.yaml, sans surarchitecturer.
- Application SaaS avec plusieurs niveaux d'accès : RBAC avec hiérarchie de rôles et voters simples pour les cas limites.
- Application multi-tenant où chaque organisation a ses propres règles : voters ABAC avec contexte injecté, potentiellement complété par une couche de permissions en base de données.
- Application fintech ou santé avec des règles d'accès auditables et changeantes : architecture hybride, avec des règles stockées en base, évaluées à l'exécution, et loguées.
Le critère déterminant n'est pas la taille de l'équipe ni le volume de données. C'est la volatilité des règles métier. Si les permissions changent souvent, si elles varient selon le client ou le contexte, si elles doivent être auditées : un RBAC statique devient un frein. Si les règles sont stables et peu nombreuses, une architecture ABAC complète est une complexité inutile.
Ce qu'on paye quand on ne choisit pas
La dérive la plus courante consiste à empiler des vérifications dans les contrôleurs ou dans le modèle utilisateur. Chaque développeur qui touche au code ajoute sa condition sans chercher à comprendre le système global. Le résultat est un ensemble de règles contradictoires, impossibles à tester exhaustivement, et sources régulières de régressions sur des fonctionnalités critiques.
Refactorer un système d'autorisation en production est coûteux. Les permissions touchent à tout : les vues, les API, les commandes, les workers. Partir d'une bonne architecture ne prend que quelques heures de réflexion en début de projet. En corriger une mauvaise peut prendre des semaines.
La bonne pratique est de poser trois questions avant d'écrire la première règle : les permissions vont-elles changer souvent ? Dépendent-elles de l'état des ressources ou seulement du profil utilisateur ? Doivent-elles être auditées ? Les réponses orientent directement le choix de l'architecture.
Conclusion
Il n'existe pas de modèle universel pour l'autorisation dans une application PHP. Ce qui compte, c'est d'aligner l'architecture choisie avec la complexité réelle du domaine métier, et de la documenter pour que l'équipe puisse évoluer dessus sans improviser.
Symfony offre des outils solides à chaque niveau de complexité : des rôles simples aux voters ABAC composables. L'essentiel est de choisir délibérément plutôt que de laisser le code décider à votre place.
Source originale : 7 Authorization Architectures in the Wild par Hossein Hezami sur dev.to.
