Rôles et permissions dans EmDash : donner accès sans tout ouvrir

Le premier réflexe quand un deuxième contributeur arrive est de lui donner les identifiants existants. C’est rapide, et c’est ce qui rend impossible toute traçabilité par la suite : plus personne ne sait qui a publié quoi, ni qui a cassé la mise en page.

Structurer les accès prend un quart d’heure, une fois.

Le principe : le moindre privilège

La règle vaut ici comme partout : on accorde ce qui est nécessaire, rien de plus. Non par méfiance envers l’équipe, mais parce qu’un accès qui n’existe pas ne peut pas être détourné, ni utilisé par erreur.

Trois questions suffisent à situer un contributeur :

• A-t-il besoin de publier, ou seulement de proposer ?
• Doit-il pouvoir modifier le contenu des autres ?
• Doit-il toucher à la configuration : plugins, thème, réglages, comptes ?

La troisième est la plus discriminante. La configuration est l’endroit où une erreur casse le site entier, alors qu’une erreur de contenu se corrige en deux minutes.

Les niveaux d’accès à distinguer

Quelle que soit la façon dont on les nomme, quatre niveaux couvrent l’immense majorité des besoins d’une équipe éditoriale.

Niveau	Peut faire	Ne peut pas
Lecture seule	Consulter les contenus et l’administration	Modifier quoi que ce soit
Rédaction	Créer et modifier ses propres contenus, les soumettre	Publier, toucher aux contenus des autres
Édition	Publier, modifier tous les contenus, gérer les médias	Toucher à la configuration, aux plugins, aux comptes
Administration	Tout	—

Le niveau rédaction est celui qui manque le plus souvent dans les organisations improvisées. Il permet à un contributeur externe — pigiste, stagiaire, expert invité — de travailler sans qu’on lui confie les clés du site. Ce qu’il produit passe par une relecture avant publication, ce qui est aussi un filet de sécurité éditorial.

Le niveau administration doit rester rare. Deux personnes suffisent dans la plupart des structures : un titulaire et un secours.

Ce que les plugins changent

C’est le point spécifique à EmDash, et il mérite d’être compris avant d’ouvrir des accès.

Les plugins s’exécutent dans un environnement isolé, avec des capacités déclarées — c’est le fondement du modèle de sécurité décrit dans la sécurité des plugins et dans les limites du bac à sable. Un plugin ne peut faire que ce qu’il a déclaré vouloir faire.

Mais installer un plugin est un acte d’administration, pas de contenu. Celui qui peut installer un plugin peut lui accorder des capacités, donc étendre ce que le site fait. C’est pour cette raison que cette action ne doit jamais figurer dans un rôle éditorial, aussi confiant soit-on dans l’équipe.

La même logique vaut pour le serveur MCP : autoriser un agent à agir sur le contenu est une décision d’administration, et elle mérite d’être prise en connaissance de cause. Le sujet est traité dans le serveur MCP intégré.

Mettre en place, concrètement

1. Recensez qui fait quoi. Listez les personnes qui accèdent au site et notez, pour chacune, ce qu’elle a réellement besoin de faire dans le mois. La liste est presque toujours plus courte que les accès existants.

2. Créez un compte nominatif par personne. Pas de compte partagé, pas de compte « rédaction » utilisé par trois personnes. Sans nominatif, l’historique ne sert à rien.

3. Attribuez le niveau minimal. On peut toujours élargir ensuite ; réduire un accès accordé est socialement plus difficile.

4. Réservez l’administration à deux personnes. Une seule est un risque de blocage en cas d’absence ou de départ ; trois ou plus dilue la responsabilité.

5. Sécurisez les comptes d’administration. Ce sont eux qui comptent. EmDash gère l’authentification par clés d’accès, dont la mise en œuvre est décrite dans l’authentification par passkeys — nettement plus robuste qu’un mot de passe partagé par message.

Le nettoyage, qui n’est jamais fait

C’est le point faible de toutes les installations qui ont quelques années.

Les comptes s’accumulent : le prestataire de la refonte, le stagiaire de l’an dernier, l’agence qui ne travaille plus avec vous. Chacun reste actif, souvent avec des droits élevés parce qu’on n’avait pas pris le temps de les ajuster.

Prenez l’habitude de revoir la liste des comptes deux fois par an :

• Supprimer les comptes des personnes parties.
• Réduire les accès qui ne se justifient plus.
• Vérifier qu’aucun compte d’administration n’est resté ouvert « au cas où ».

Un compte inutilisé n’est pas neutre : c’est une porte ouverte que personne ne surveille.

Ce que l’historique doit vous dire

Des comptes nominatifs n’ont d’intérêt que si l’on peut retracer les actions. Vérifiez que vous êtes en mesure de répondre à trois questions le jour où c’est nécessaire.

Qui a publié ce contenu, et quand ? C’est la base, et cela règle la plupart des discussions internes.

Qui a modifié ce réglage ? Un site qui change de comportement sans raison apparente a presque toujours vu un réglage modifié par quelqu’un qui ne mesurait pas l’effet.

Quand ce compte s’est-il connecté pour la dernière fois ? C’est ce qui permet de repérer les comptes dormants lors de la revue semestrielle.

Le cas des contributeurs occasionnels

Pour une contribution ponctuelle — un article invité, une relecture externe —, la tentation est de créer un compte et de l’oublier ensuite.

Deux pratiques évitent l’accumulation. Créer le compte avec une échéance connue, notée quelque part, et le supprimer à la fin de la mission. Ou récupérer le contenu autrement : un fichier Markdown envoyé et intégré par un membre de l’équipe, ce qui évite de créer un accès pour deux textes.

Cette dernière option est souvent la plus simple, et elle s’intègre naturellement au fonctionnement d’EmDash, dont le contenu vit dans des fichiers structurés — comme le rappelle le guide de l’architecture.

À retenir

Un site à un seul contributeur n’a pas besoin de tout ceci. Un site à trois contributeurs en a besoin, et il vaut mieux le mettre en place quand tout va bien plutôt qu’après un incident.

Le coût est d’un quart d’heure. Le bénéfice est de savoir, dans six mois, qui a fait quoi — et de ne pas avoir à changer un mot de passe partagé chaque fois que quelqu’un quitte l’équipe.

Le flux de relecture, ce que les rôles permettent réellement

Distinguer rédaction et publication n’est pas seulement une précaution de sécurité : c’est ce qui rend possible un circuit éditorial.

Le schéma qui fonctionne dans une petite équipe :

1. Le rédacteur crée son contenu et le soumet. Il n’a pas la main pour publier.
2. L’éditeur relit, corrige si nécessaire, et publie.
3. L’administrateur n’intervient pas dans ce flux — il n’a rien à y faire.

Ce circuit a un avantage discret : il rend la relecture obligatoire par construction, sans avoir à s’appuyer sur la discipline de chacun. Dans les organisations où tout le monde peut publier, la relecture finit toujours par sauter quand ça presse.

Il en a un second : la trace. On sait qui a écrit, qui a validé, et quand. Sur un site qui engage une structure, c’est ce qui permet de répondre sereinement à une contestation sur un contenu publié.

Ce qui ne relève pas des rôles

Trois protections sont parfois attendues du système de permissions alors qu’elles se traitent ailleurs.

La sauvegarde. Aucun réglage de droits n’empêche une suppression accidentelle par quelqu’un qui en avait légitimement le pouvoir. La réponse est une sauvegarde régulière et testée, sujet traité dans sauvegarder son site EmDash.

L’historique de version du contenu. Savoir qui a modifié quoi est utile ; pouvoir revenir en arrière l’est davantage. Sur une installation gérée par dépôt, l’historique du versionnement joue ce rôle — c’est l’un des intérêts de l’approche décrite dans l’architecture d’EmDash.

L’accès à l’hébergement. Les droits applicatifs ne disent rien des accès à l’infrastructure : compte Cloudflare, dépôt de code, base de données. Ces accès-là sont souvent les plus sensibles et les moins gérés. Ils méritent le même inventaire, et la même revue semestrielle.

Une check-list de mise en place

À dérouler une fois, en un quart d’heure, sur une installation existante.

Contrôle	Attendu
Comptes partagés	Aucun
Comptes nominatifs	Un par personne active
Comptes d’administration	Deux, pas plus
Comptes de prestataires partis	Supprimés
Rôle de chaque compte	Le niveau minimal utile
Authentification des administrateurs	Clés d’accès plutôt que mot de passe
Accès à l’hébergement et au dépôt	Inventoriés, au même titre
Date de la prochaine revue	Notée quelque part

La dernière ligne est celle qui fait la différence entre une mise en ordre ponctuelle et une pratique. Sans échéance notée, la revue n’a jamais lieu.