Rôles utilisateurs et permissions dans Drupal : comment les universités contrôlent qui peut modifier quoi

Une plateforme web universitaire peut compter plusieurs centaines d'éditeurs : administrateurs de faculté, secrétaires de département, chargés de communication, bibliothécaires et étudiants assistants. Drupal regroupe ce que chacun d'eux peut faire en rôles, et accorde les permissions à ces rôles plutôt qu'aux individus. Dans cet article, nous présentons une structure de rôles qui correspond à l'organisation d'un campus, comment donner à chaque département un contrôle éditorial sur ses propres pages, quelles permissions accordent bien plus que leur nom ne le laisse penser, et comment retirer les accès quand des personnes quittent l'institution.

La plupart des guides sur ce sujet expliquent correctement la mécanique, puis s'arrêtent sur un exemple générique. Cela laisse sans réponse la question la plus difficile : comment traduire une organisation composée de facultés, de départements, de centres de recherche et de personnel étudiant en rotation permanente, en un système de permissions qu'une petite équipe centrale peut réellement maintenir ? Nous détaillons ci-dessous cette traduction, en nommant les permissions essentielles et les modules contribués impliqués à chaque étape.

Comment fonctionnent les rôles et les permissions dans Drupal

Chaque action sur un site Drupal est régie par une permission. Chaque permission couvre une action ou un petit groupe d'actions, et les permissions sont définies par les modules qui fournissent ces actions. Plutôt que d'accorder des permissions à des comptes individuels, Drupal les regroupe en rôles et accorde le rôle.

Cette distinction compte à l'échelle d'une université. Lorsqu'une secrétaire de département quitte son poste, vous retirez un rôle d'un compte plutôt que d'auditer une liste de permissions individuelles. Lorsque le service communication décide que les éditeurs ne doivent plus pouvoir supprimer de pages, vous modifiez un seul rôle et la décision s'applique à tous ceux qui le détiennent.

Les trois rôles avec lesquels démarre chaque site

Un nouveau site Drupal dispose d'un rôle utilisateur anonyme pour les visiteurs non connectés et d'un rôle utilisateur authentifié que reçoit automatiquement tout compte connecté. Selon le profil d'installation, il existe aussi souvent un rôle administrateur auquel sont attribuées toutes les permissions du site.

Deux bonnes pratiques en découlent. Les permissions accordées au rôle utilisateur authentifié s'appliquent à tout compte que vous créerez à l'avenir, ce rôle doit donc rester quasiment vide sur une plateforme comptant des centaines d'éditeurs. Et le rôle administrateur doit être traité comme un petit groupe nommément identifié, plutôt que comme une solution de facilité pour quiconque doit régler rapidement un problème.

Le compte utilisateur 1, et pourquoi personne ne devrait y travailler

Le premier compte créé lors de l'installation porte l'identifiant interne 1, et il est différent de tous les autres comptes. Quels que soient les rôles qu'il détient ou non, l'utilisateur 1 peut effectuer n'importe quelle action sur le site : consulter et modifier tout le contenu, modifier n'importe quel compte, changer la configuration, installer et désinstaller des modules, et exécuter le script de mise à jour. La documentation officielle de Drupal le compare au compte root d'un serveur Linux. Il ne peut pas non plus être supprimé via l'interface d'administration.

La documentation de Drupal donne quatre raisons de créer des comptes administratifs distincts plutôt que de partager celui-ci, et chacune pèse plus lourd dans une université que sur un petit site.

• Les actions effectuées sur le site sont journalisées. Si toute l'équipe web partage un même compte, le journal ne peut pas indiquer qui a modifié la page d'accueil.
• Le rôle administrateur peut être configuré de façon plus sûre que l'utilisateur 1, de sorte qu'un clic malencontreux ne puisse pas désinstaller un module.
• Les responsabilités des personnes évoluent. Des rôles peuvent être ajoutés ou retirés d'un compte ordinaire ; des identifiants partagés, eux, ne peuvent pas être révoqués pour une seule personne.
• La paternité du contenu est enregistrée et souvent affichée. Les comptes partagés rendent impossible de savoir qui a rédigé une page.

La règle pratique consiste à conserver les identifiants de l'utilisateur 1 dans le coffre-fort de mots de passe de l'institution, à ne les utiliser que pour la récupération et la maintenance de la plateforme, et à donner à chaque administrateur un compte nommément identifié avec le rôle administrateur.

Les rôles s'additionnent, ils ne se soustraient jamais

Un utilisateur peut détenir plusieurs rôles à la fois, et les permissions de ces rôles s'accumulent. Le noyau de Drupal ne dispose d'aucun mécanisme permettant à un rôle de retirer une permission accordée par un autre.

Cela prend régulièrement les équipes au dépourvu. Un site dispose d'un rôle éditeur pouvant supprimer du contenu, et quelqu'un décide que les nouveaux collaborateurs ne devraient rien pouvoir supprimer, alors on crée un rôle éditeur restreint qu'on assigne en plus du rôle existant. La personne détient désormais les deux, et la permission de suppression est toujours là. Le seul moyen de refuser une permission est de construire un rôle qui ne l'a jamais eue. Lorsqu'un système commence à nécessiter une logique de « soustraction », c'est le signal qu'il faut repenser les rôles plutôt qu'en ajouter un de plus.

Un modèle de rôles qui correspond au fonctionnement réel d'une université

Les structures de rôles sur un campus échouent généralement dans l'une de deux directions. Soit il n'existe que quatre rôles et chaque faculté se plaint de ne pas pouvoir accomplir son propre travail, soit il en existe soixante, créés un par un au fil des demandes, et plus personne ne se souvient de ce que la moitié d'entre eux accorde réellement.

Une structure qui tient dans la durée sépare généralement deux questions que l'on confond facilement. Quel type de travail cette personne effectue-t-elle, et dans quelle partie du site l'effectue-t-elle ? Les rôles Drupal répondent bien à la première question et mal à la seconde, d'où la section consacrée au territoire éditorial ci-dessous.

Pour la première question, cinq niveaux couvrent la plupart des institutions :

• Administrateur de la plateforme. Un groupe nommément identifié de deux à quatre personnes au sein de la DSI centrale, détenant le rôle administrateur et responsables de la configuration, des modules et des mises à jour.
• Éditeur central. Le personnel communication et marketing qui publie sur l'ensemble du site, y compris la page d'accueil et les pages au niveau de l'institution.
• Éditeur d'unité. Le personnel de faculté et de département qui crée et publie du contenu dans son propre périmètre. C'est de loin le groupe le plus important.
• Contributeur. Universitaires, étudiants assistants et contributeurs occasionnels qui rédigent du contenu qu'une autre personne publie.
• Lecteur. Des comptes créés pour accéder à des pages restreintes plutôt que pour les modifier, comme des documents de politique interne réservés au personnel.

Deux tests méritent d'être appliqués avant d'ajouter un sixième niveau. Un nouveau rôle différerait-il d'un rôle existant par plus de deux permissions ? Et quelqu'un d'autre que le demandeur le détiendra-t-il un jour ? Un rôle créé pour une seule personne n'est en réalité qu'une attribution de permission avec des étapes supplémentaires, et il restera en place des années après le départ de cette personne.

Donner à chaque département son propre territoire éditorial

Les rôles répondent à ce qu'une personne peut faire, mais pas à l'endroit où elle peut le faire. Un rôle éditeur d'unité qui accorde la permission de modifier n'importe quelle page permettra au département de biologie de modifier les pages d'admission. Résoudre ce problème nécessite une seconde couche, et Drupal propose deux approches éprouvées.

Un accès par sections avec Workbench Access

Le module Workbench Access crée un contrôle d'accès éditorial basé sur une hiérarchie déjà existante, typiquement une taxonomie de facultés et de départements ou la structure de menu du site. Le contenu est placé dans une section éditoriale lors de sa création, les utilisateurs sont affectés à des sections par compte ou par rôle, et ils ne peuvent agir que sur le contenu de leurs propres sections ou des sections situées en dessous. La version 2.0.5 est sortie en septembre 2026 et prend en charge Drupal 9, 10 et 11. Environ huit mille sites déclarent l'utiliser, et son développement a été sponsorisé par Palantir.net avec le soutien de la Charles Darwin University.

Deux limites, mentionnées dans sa propre documentation, méritent d'être lues attentivement avant de construire quoi que ce soit autour. Le module n'accorde pas de privilèges éditoriaux ; il se contente de restreindre le contenu sur lequel un utilisateur peut agir, ce qui signifie que les permissions de création et de modification sous-jacentes doivent toujours être accordées via les rôles. Et il ne contrôle que l'accès en modification, pas qui peut consulter le contenu publié.

C'est précisément la hiérarchie qui rend cette approche adaptée à l'enseignement supérieur. Un chargé de communication de faculté affecté à la section de sa faculté hérite de tous les départements situés en dessous, tandis qu'une secrétaire de département affectée à un seul département ne voit que celui-ci. Lorsqu'un nouveau centre de recherche est créé, il est ajouté à la hiérarchie plutôt que de nécessiter un nouveau rôle.

Quand Group convient mieux que les sections

Le module Group adopte une approche différente. Plutôt que de placer le contenu dans une hiérarchie, il crée des collections dotées de leur propre adhésion et de leurs propres rôles internes. Une personne peut être administratrice d'un groupe et simple membre d'un autre, et les rôles de groupe sont distincts des rôles applicables à l'ensemble du site. Il est utilisé sur environ dix-huit mille sites.

Group convient aux cas où la frontière relève de l'adhésion plutôt que de la position organisationnelle : un projet de recherche avec des collaborateurs nommément désignés issus de trois facultés, un comité de conférence, une communauté d'anciens élèves avec du contenu privé. Là où la frontière suit l'organigramme, les sections sont plus simples à exploiter.

Le choix de la version demande de l'attention fin 2026. Les branches 2.x et 3.x prennent en charge Drupal 10 et 11, la branche 8.x-1.x a atteint sa fin de vie en même temps que Drupal 10 mi-2026, et une branche 4.x pour Drupal 11.4 et au-delà est en alpha. Une plateforme qui démarre maintenant ne devrait pas partir sur la branche la plus ancienne.

Les rôles sur une plateforme multisite

Sur une plateforme où chaque faculté exploite son propre site à partir d'une base de code commune, les rôles et les utilisateurs ne sont par défaut pas partagés entre ces sites. Chaque site possède ses propres comptes et sa propre configuration de rôles, ce qui constitue un avantage pour l'autonomie et une contrainte pour la cohérence : une définition de rôle améliorée sur un site ne s'améliore nulle part ailleurs. Exporter la configuration des rôles et la déployer sur l'ensemble des sites permet de garder des définitions identiques, même si les comptes restent distincts. Nous avons détaillé les arbitrages plus larges de cette architecture dans la gestion des sites web universitaires avec Drupal multisite.

C'est aussi le point où le choix entre multisite et sections devient visible. Si les départements ont besoin de sites distincts, les rôles vivent au niveau de chaque site. S'ils ont besoin d'un territoire distinct au sein d'un même site, ce sont les sections qui font le travail.

Des permissions qui accordent discrètement tout

Certaines permissions se lisent comme de simples facilités administratives de portée limitée, mais reviennent en pratique à céder le site tout entier. Drupal signale lui-même les plus dangereuses : une permission peut être déclarée avec un indicateur d'accès restreint dans la définition de son module, ce qui fait afficher sur la page des permissions un avertissement de sécurité standard à ses côtés. Le noyau l'utilise notamment pour des permissions comme la gestion des formats de texte et des filtres.

Sur une page comportant plusieurs centaines de cases à cocher, cet avertissement est facile à faire défiler sans le remarquer ; ces permissions méritent donc d'être nommées explicitement.

• Administrer les permissions. Quiconque la détient peut s'accorder à lui-même, ou accorder à quiconque, n'importe quelle permission du site, y compris celle-ci.
• Administrer les utilisateurs. Permet de modifier n'importe quel compte. Combinée à la permission précédente, ou sur un site où un compte administrateur peut être modifié, c'est une voie vers un contrôle total.
• Administrer les formats de texte et les filtres. Contrôle quel code HTML est autorisé et quels rôles peuvent utiliser quel format. Assouplir un format est le moyen par lequel une injection de script s'introduit dans un site via l'éditeur.
• Contourner le contrôle d'accès au contenu. Annule toute autre permission liée au contenu, y compris tout ce qu'appliquent Workbench Access ou Group.
• Administrer la configuration du site. Touche à des paramètres qui affectent l'ensemble de la plateforme, et non une seule section du site.
• Administrer les modules. Installer du code est le chemin le plus direct vers l'exécution de code arbitraire sur le serveur.

La règle qui en découle est simple. Ces permissions appartiennent au rôle d'administrateur de la plateforme, et nulle part ailleurs. Lorsqu'une demande arrive pour l'une d'entre elles, la réponse utile consiste à demander ce que la personne essaie réellement de faire, car la réponse est presque toujours une permission plus restreinte ou une affectation de section.

Il convient de corriger une affirmation qui circule dans des écrits plus anciens sur ce sujet : celle selon laquelle les modules contribués seraient intrinsèquement moins sûrs que le noyau. Les modules contribués disposant de versions stables sont couverts par la politique de bulletins de sécurité de Drupal, et tous les modules mentionnés dans cet article bénéficient de cette couverture. Ce qui varie réellement, c'est le statut de maintenance, indiqué sur la page de chaque projet, et c'est précisément ce qu'il faut vérifier.

Laisser les départements gérer leur propre personnel

Avec quelques centaines d'éditeurs, chaque changement de compte passant par la DSI centrale devient une file d'attente. Un département recrute une administratrice en septembre et attend une semaine pour obtenir un accès en modification. La solution instinctive consiste à donner au chef de département la capacité de gérer les utilisateurs, ce qui implique d'accorder les permissions « administrer les utilisateurs » et « administrer les permissions », ce qui signifie que le chef de département peut désormais s'accorder n'importe quoi.

C'est précisément pour cela qu'existe le module Role Delegation. Il crée une permission d'attribution distincte pour chaque rôle du site, de sorte qu'un administrateur de faculté puisse se voir accorder la capacité d'attribuer le rôle contributeur, et rien d'autre. Ces personnes voient un widget d'attribution de rôle dans les formulaires de compte et dans les opérations groupées de la liste des utilisateurs, sans jamais détenir la permission « administrer les permissions ». Il est signalé sur plus de cinquante mille sites, et sa version actuelle prend en charge Drupal 10.3 et 11.

La délégation fonctionne mieux avec une règle claire sur les rôles délégables : éditeur d'unité et contributeur, oui ; éditeur central et administrateur de la plateforme, non. Cela permet de garder l'intégration quotidienne du personnel au niveau local, tandis que les rôles porteurs d'un pouvoir réel restent entre les mains de l'équipe centrale.

Attribuer les rôles depuis le système d'identité du campus

L'attribution manuelle ne passe pas à l'échelle sur un campus, et n'a pas besoin de le faire. Lorsque le personnel se connecte via le fournisseur d'identité de l'institution, les attributs transmis lors de cette connexion peuvent directement piloter l'attribution des rôles, de sorte que l'appartenance à un groupe d'annuaire devienne un rôle Drupal sans que personne n'ait à toucher au compte. Nous avons traité le volet authentification dans l'intégration du SSO avec SAML, Shibboleth, LDAP et CAS ; voici ce qui se passe une fois l'identité arrivée.

Deux familles de modules répondent à ce besoin. Le module simpleSAMLphp Authentication propose un provisionnement de compte à la demande (just-in-time) et une attribution automatique de rôle à partir des attributs SAML, et reste largement déployé. Sa page de projet affiche désormais un statut « maintenance minimale », et son propre mainteneur recommande d'évaluer plutôt le module SAML Authentication, dont la chaîne de dépendances est bien plus réduite. Ce second module gère l'attribution des rôles via son sous-module dédié aux rôles utilisateurs, et un module complémentaire fait correspondre les attributs SAML à l'appartenance à un Group pour les institutions qui utilisent des groupes plutôt que des sections.

Quel que soit le chemin choisi, trois décisions de conception comptent davantage que le choix du module lui-même. Décider quel attribut fait autorité, généralement un groupe d'annuaire plutôt qu'un champ intitulé de poste. Décider ce qui se produit à chaque connexion : les rôles sont-ils recalculés à chaque fois, ce qui rend le retrait automatique, ou attribués une seule fois à la création du compte, ce qui ne l'est pas. Et conserver un petit ensemble de rôles en dehors du mappage automatisé, car le rôle d'administrateur de la plateforme devrait résulter d'un acte délibéré plutôt que d'une conséquence d'un changement dans l'annuaire.

La partie que la plupart des institutions négligent : le retrait des accès

Les systèmes de permissions sont conçus au lancement, puis seulement complétés par la suite. Les accès s'accumulent : l'étudiant assistant diplômé, le chargé de communication muté vers une autre faculté, l'agence qui a construit le site il y a trois ans. Chacun de ces comptes reste une porte d'entrée.

Une université connaît une version particulière de ce problème, car le turnover y est saisonnier et prévisible. Le personnel étudiant change chaque semestre. Les fonctions administratives académiques tournent chaque année. Des départements fusionnent. Rien de tout cela ne génère automatiquement de notification pour l'équipe web.

Trois bonnes pratiques couvrent l'essentiel du risque.

• Relier la désactivation au système d'identité. Si les comptes sont provisionnés à partir de l'annuaire et que les rôles sont recalculés à chaque connexion, une personne qui perd son groupe d'annuaire perd ses droits de modification sans que personne n'ait à déposer de demande.
• Réviser les rôles selon le calendrier universitaire plutôt qu'à une date arbitraire. Un contrôle en début de chaque semestre permet de détecter la rotation des étudiants alors que le changement est encore récent.
• Bloquer les comptes plutôt que de les supprimer. Le blocage retire l'accès tout en préservant la paternité du contenu, de sorte que l'historique de qui a écrit quoi soit conservé.

Une courte liste des personnes détenant les rôles d'administrateur de la plateforme et d'éditeur central, révisée une fois par semestre par une personne nommément désignée, vaut davantage que n'importe quel volume de documentation de politique.

Données personnelles et couche de permissions

Dès qu'un site héberge des formulaires de candidature, des inscriptions à des événements ou des dossiers étudiants importés d'un autre système, le système de permissions cesse d'être une simple facilité éditoriale pour devenir un dispositif de protection des données.

Aux États-Unis, le FERPA distingue les dossiers scolaires des informations d'annuaire, et déterminer quels champs relèvent de quelle catégorie est une décision qui revient au bureau de la scolarité, et non à l'équipe web. Dans l'Union européenne et au Royaume-Uni, le principe de minimisation des données du RGPD va dans le même sens : les personnes ne devraient accéder qu'aux données que leur travail exige, et pas davantage.

Trois points pratiques en découlent. Le contrôle des permissions au niveau du champ permet à un formulaire de collecter un champ que la plupart des éditeurs ne pourront pas relire, ce qui convient tout à fait aux coordonnées de contact d'un formulaire de demande d'information. L'accès aux données soumises devrait être un rôle distinct de la capacité à modifier la page contenant le formulaire, car la personne qui gère une page de programme d'études a rarement besoin de consulter les candidatures reçues. Et la permission de consulter le contenu non publié est plus large qu'il n'y paraît, puisque les brouillons contiennent souvent précisément le contenu qui n'a pas encore été validé pour publication.

Réviser et tester un système de permissions

Un système de permissions relève de la configuration, ce qui signifie qu'il peut être exporté, révisé de la même manière que du code, et déployé plutôt que ajusté par des clics directement sur le site en production. Les institutions qui l'abordent ainsi peuvent, des mois plus tard, répondre précisément à la question de ce qui a changé et quand.

Les tests constituent l'étape que l'on saute le plus souvent. La seule vérification fiable consiste à conserver un compte de test pour chaque rôle, à s'y connecter et à tenter d'effectuer les actions que ce rôle ne devrait pas pouvoir réaliser. Lire la page des permissions vous indique ce que vous avez configuré ; utiliser le compte vous indique ce que vous avez réellement construit. Il est utile de conserver, pour cette seule finalité, un compte de test dormant par rôle sur la plateforme.

Une distinction mérite d'être clairement posée, car elle prête souvent à confusion. Les permissions déterminent ce qu'une personne est autorisée à faire. Le workflow éditorial détermine dans quel état se trouve un contenu et qui le fait passer à l'état suivant. Qu'un contributeur puisse créer une page mais pas la publier relève d'une décision de permission ; qu'une page reste en relecture jusqu'à ce qu'un éditeur l'approuve relève d'une décision de workflow. Les deux fonctionnent ensemble, et nous avons traité le second point dans les workflows d'approbation de contenu pour les universités.

Planifier sa structure de rôles

Le travail qui détermine si un système de permissions tiendra dans la durée n'est pas la configuration elle-même. C'est de décider quelles unités possèdent quelles parties du site, qui peut publier sans relecture, quels rôles une faculté peut attribuer elle-même, et ce qui se passe lorsque quelqu'un quitte l'institution. Ces réponses viennent de l'institution, et Drupal se contente ensuite de les faire appliquer.

Une séquence raisonnable consiste à cartographier d'abord la propriété existante des contenus, à définir le plus petit ensemble de rôles couvrant le travail à accomplir, à ajouter une hiérarchie de sections pour que ces rôles ne s'appliquent qu'au sein d'une unité, à déléguer les deux rôles les plus bas aux facultés, à relier l'attribution au système d'identité, et à fixer une date de révision dans le calendrier universitaire avant la mise en production de la plateforme, et non après.

Les plateformes Drupal que l'équipe Drupal4edu chez Drupart a construites pour des institutions telles que l'université Sabancı, la METU et l'université technique Yıldız sont conçues précisément autour de cette couche, où une petite équipe centrale maintient la cohérence de la plateforme tandis que chaque faculté modifie ses propres pages. Vous pouvez en savoir plus sur notre approche sur la page Drupal pour l'éducation.

Questions fréquentes sur les rôles et permissions Drupal

Dernière mise à jour: 18.09.2026 16:13