Pourquoi la modélisation des rôles passe avant le développement
Dans un extranet, les erreurs de permissions ne sont pas des bugs comme les autres. Un champ visible par le mauvais utilisateur, un document accessible sans habilitation, un formulaire soumissible sans le bon rôle — ce sont des incidents de sécurité, pas des anomalies d'affichage.
La source de ces incidents est presque toujours identique : les permissions ont été ajoutées au fil du développement, case à cocher après case à cocher, sans modèle cohérent. On a codé d'abord, on a réfléchi à l'accès ensuite.
Le résultat est prévisible : une matrice de permissions informelle, mémorisée par le développeur qui a tout construit, introuvable dans la documentation, et impossible à auditer.
Drupal 10 et 11 offrent un système de rôles et de permissions remarquablement puissant. Mais ce système ne fait qu'appliquer ce qu'on lui demande. Si le modèle d'accès est flou dans les têtes, il sera flou dans le code.
La règle est simple : modéliser les rôles et les habilitations avant d'écrire une ligne de code. Pas comme une formalité, mais comme le premier livrable du projet.
La matrice rôles-permissions : le livrable de départ
Une matrice rôles-permissions est un tableau qui croise, sur un axe, les types d'utilisateurs de l'extranet, et sur l'autre, les actions possibles dans le système. Chaque intersection est une décision : autorisé, refusé, ou conditionnel.
Ce tableau n'est pas un document technique réservé aux développeurs. C'est un outil de décision que le commanditaire doit valider avant le démarrage du développement. Parce que c'est lui qui porte les connaissances métier : qui peut voir les contrats ? Qui peut modifier une commande ? L'acheteur junior a-t-il accès aux tarifs négociés ?
Un extranet typique implique plusieurs types d'utilisateurs :
- des utilisateurs internes (équipe commerciale, service client, administration) avec des niveaux d'accès différents selon la fonction ;
- des utilisateurs externes (clients, partenaires, revendeurs) dont le périmètre est souvent limité à leurs propres données ;
- des administrateurs fonctionnels qui gèrent les contenus sans toucher à la configuration technique ;
- et parfois des utilisateurs tiers (auditeurs, prestataires ponctuels) avec des accès temporaires et restreints.
Chacun de ces profils correspond à un rôle Drupal. Chaque rôle Drupal agrège des permissions. Dessiner la matrice, c'est transformer cette logique métier en une spécification directement implémentable.
Le modèle d'accès dans Drupal 11 : ce que le système sait faire nativement
Drupal 11 dispose d'un modèle de contrôle d'accès à plusieurs niveaux. Savoir ce qu'il sait faire nativement évite de réinventer des mécanismes que le cœur offre déjà.
Rôles et permissions globales
Le système de rôles natif de Drupal est basé sur des permissions atomiques assignées à des rôles. Un utilisateur hérite des permissions de tous ses rôles. Ce modèle couvre la majorité des besoins d'un extranet standard : accès à des types de contenu, capacité à créer ou modifier des entités, visibilité des menus d'administration.
Contrôle d'accès au niveau des nœuds (node access)
Pour les extranets où la règle n'est pas « le rôle A peut voir les articles » mais « l'utilisateur X peut voir uniquement ses propres commandes », le contrôle d'accès au niveau des nœuds est indispensable. Des modules comme Content Access, Domain Access ou une implémentation custom de hook_node_access permettent de descendre à la granularité de l'enregistrement individuel.
C'est ici que la matrice rôles-permissions doit être la plus précise : les règles d'accès conditionnelles (un revendeur ne voit que les clients qui lui sont rattachés, un acheteur ne voit que ses propres commandes) sont celles qui coûtent le plus cher à changer après coup.
Accès aux champs
Drupal permet de contrôler la visibilité et l'édition d'un champ individuel par rôle, via le module Field Permissions. Cette granularité est précieuse dans un extranet où un même formulaire est vu par plusieurs rôles, mais où certains champs (prix, marges, commentaires internes) ne doivent être accessibles qu'à une partie d'entre eux.
Accès aux vues (Views)
Les listes et tableaux de bord d'un extranet sont presque toujours construits avec le module Views. Chaque vue peut être filtrée par rôle, et chaque filtre contextuel peut être basé sur l'identité de l'utilisateur connecté. La logique d'accès doit être pensée avant d'être configurée : une liste « mes commandes » filtrée sur l'UID de l'utilisateur courant est triviale à construire si c'est prévu dès le départ, et coûteuse à rétrofiter si elle ne l'a pas été.
Les pièges classiques à éviter
Le rôle fourre-tout
Le rôle authenticated user est accordé à tout utilisateur connecté, quelle que soit sa nature. Dans un extranet multi-organisations, ce rôle est souvent utilisé comme base commune — et ses permissions s'accumulent au fil du projet jusqu'à devenir ingérables. La règle : le rôle authenticated user ne reçoit que les permissions minimales partagées par tous les utilisateurs connectés. Chaque profil métier dispose de son propre rôle, avec des permissions explicites.
Les permissions accordées par commodité
Pendant le développement, il est tentant d'élargir les permissions pour débloquer un blocage technique. « On verra pour restreindre plus tard. » Ce « plus tard » n'arrive jamais. La règle du moindre privilège — chaque rôle reçoit uniquement les permissions dont il a strictement besoin — doit être appliquée dès le départ, pas rétroactivement.
L'absence de tests de régression des permissions
Une modification de rôle peut avoir des effets de bord inattendus sur d'autres rôles ou d'autres contextes. Sans tests automatisés des accès, ces régressions passent inaperçues jusqu'à ce qu'un utilisateur signale qu'il voit quelque chose qu'il ne devrait pas. Des tests d'accès automatisés — vérifier, scénario par scénario, que chaque rôle accède à ce qu'il doit et ne voit pas ce qu'il ne doit pas — sont une assurance indispensable dans un extranet en production.
La gestion manuelle des habilitations temporaires
Un auditeur externe, un prestataire ponctuel, un accès de démonstration : les accès temporaires mal gérés laissent des comptes actifs bien après leur date de péremption. La gestion des habilitations temporaires doit être un processus explicite, avec une date d'expiration systématique et un mécanisme de révocation automatique.
Sécurité complémentaire : ce qui dépasse les permissions
La gestion des rôles et des permissions est le cœur de la sécurité d'un extranet, mais elle ne couvre pas tout.
L'authentification forte est la première ligne de défense. Dans un extranet qui donne accès à des données sensibles, l'authentification à deux facteurs n'est pas optionnelle. Des modules comme TFA (Two-factor Authentication) ou l'intégration avec un SSO d'entreprise (SAML, OAuth2) permettent d'aller bien au-delà du simple couple login/mot de passe.
Le chiffrement des données sensibles en base et des échanges (HTTPS partout, sans exception) est un prérequis, pas une option.
La journalisation des accès — qui s'est connecté, quand, depuis quelle IP, quelles actions a-t-il effectuées — permet de détecter des comportements anormaux et de constituer un audit trail en cas d'incident. Drupal dispose du module Syslog et de l'API de journalisation, mais une intégration avec un SIEM externe peut être nécessaire dans les contextes les plus exigeants.
Les mises à jour de sécurité enfin, sont un processus, pas un événement. Drupal publie des correctifs de sécurité selon un calendrier prévisible. Un extranet en production sans contrat de maintenance applicative est un extranet dont les vulnérabilités connues restent ouvertes. La fin de vie de Drupal 10 en décembre 2026 est une échéance concrète : les extranets sur Drupal 10 devront avoir migré vers Drupal 11 avant cette date pour rester couverts.
Ce que ça change de partir du bon pied
Un extranet dont le modèle d'accès a été conçu avant le développement est, en pratique, radicalement différent d'un extranet où les permissions ont été ajoutées au fil de l'eau.
La matrice rôles-permissions devient le contrat entre le métier et la technique. Elle documente chaque décision d'accès. Elle permet d'embarquer un nouveau développeur sans transmission orale. Elle rend les audits de sécurité possibles. Et elle permet d'évoluer — ajouter un rôle, modifier une habilitation — sans risquer de tout casser.
Le coût de cette modélisation est marginal au démarrage. Son absence coûte très cher dans la durée.