Utilisateurs & rôles

À quoi ça sert

Trois écrans qui répondent à une seule question — qui peut faire quoi :

• les membres : qui a accès à votre organisation ;
• les rôles : ce que chacun peut faire ;
• les permissions : le catalogue des clés que le produit connaît.

La règle tient en une phrase : on ne donne pas de permission à une personne, on lui donne un rôle. Le rôle est un paquet de permissions ; c'est lui qu'on attribue, et c'est lui qu'on modifie quand les besoins changent — pour tout le monde à la fois.

Les écrans

Les membres

Où cliquer — dans le menu, section Administration ▸ Utilisateurs.

_{Adresse directe : /utilisateurs · chemin repris du menu du produit, régénéré.}

Voir qui a accès à votre Pilotiz, et avec quels droits.

Ce que le produit décide

• Un utilisateur ne détient aucun droit par lui-même : tout vient des RÔLES qu’on lui donne.
• Le PROPRIÉTAIRE de l’organisation fait exception : il contourne toute vérification de droit, et voit donc tout. Ce n’est pas un réglage, c’est sa nature.

Ce qui est exigé à la saisie

• Aucune saisie sur cet écran.
• Créer un utilisateur demande le droit correspondant : sans lui, le bouton n’apparaît pas.

Ce qui précède, ce qui suit

• Un clic sur une ligne ouvre la fiche de l’utilisateur.
• Les droits ne se donnent pas ici : on attribue un RÔLE, et c’est le rôle qui porte les permissions.

_{Texte repris de l'aide affichée dans le produit (clé utilisateurs-liste) — régénéré, ne pas modifier ici.}

1. Nouvel utilisateur — un membre reçoit ses accès par courriel, ou un mot de passe que vous lui remettez. Un membre doit porter au moins un rôle : sans rôle, il pourrait se connecter et ne rien faire.
2. Les membres — nom, adresse, rôle et statut. Le propriétaire est marqué : il conserve tous les droits, et aucun rôle ne peut les lui retirer. Poste, service et activité se lisent sur la fiche, en cliquant la ligne.

_{Capture du 2026-09-09 · pilotiz.izwebservices.ma · version affichée Pilotiz v1.0.0 · dépôt 7f1d87f9}

Ajouter un membre

Où cliquer — depuis la liste, bouton Nouvel utilisateur.

_{Adresse directe : /utilisateurs/add}

Ouvrir un accès à quelqu’un : son identité, son adresse, et la façon dont il recevra ses accès.

Ce que le produit décide

• L’ADRESSE E-MAIL est le seul chemin vers ce compte : invitation, réinitialisation de mot de passe, notifications passent toutes par elle. Une adresse fausse crée un compte où personne ne peut jamais entrer.
• Par défaut, l’utilisateur reçoit un courriel pour définir son mot de passe. On peut aussi en fixer un directement.
• Poste, service, téléphone et langue sont facultatifs : ils servent à l’organisation, pas à l’accès.

Ce qui est exigé à la saisie

• Obligatoires : l’ADRESSE E-MAIL, le PRÉNOM et le NOM.
• L’adresse doit être une VRAIE adresse. Le produit refuse désormais les formes invalides — sans destinataire, sans domaine, avec deux arobases ou une espace : cinq d’entre elles avaient été acceptées et stockées telles quelles avant que la garde n’existe.

Ce qui précède, ce qui suit

• Le compte créé n’a encore AUCUN droit : il faut lui attribuer au moins un rôle.
• Si l’envoi du courriel est demandé, il dépend de la configuration SMTP de votre organisation, comme tout autre envoi.

_{Texte repris de l'aide affichée dans le produit (clé utilisateurs-formulaire) — régénéré, ne pas modifier ici.}

La fiche d'un membre

Où cliquer — un clic sur une ligne de la liste.

_{Adresse directe : /utilisateurs/:id}

Ce qu’une personne peut faire, et ce qu’elle fait : ses rôles, ses projets, ses tâches et son activité.

Ce que le produit décide

• L’onglet RÔLES est le seul endroit où se décident ses droits. Retirer un rôle retire tout ce qu’il portait, immédiatement.
• Les projets et les tâches montrés ici sont ceux dont cette personne est responsable : c’est la vue « charge de travail » d’un collaborateur.

Ce qui est exigé à la saisie

• Chaque onglet porte ses propres règles.
• Modifier les rôles d’un utilisateur demande le droit correspondant.

Ce qui précède, ce qui suit

• On arrive ici par un clic sur une ligne de la liste des utilisateurs.
• Un changement de rôle prend effet à la prochaine ouverture de session de la personne concernée.

_{Texte repris de l'aide affichée dans le produit (clé utilisateurs-fiche) — régénéré, ne pas modifier ici.}

Les rôles

Où cliquer — dans le menu, section Administration ▸ Rôles.

_{Adresse directe : /roles · chemin repris du menu du produit, régénéré.}

Définir des ensembles de droits — « Commercial », « Comptable » — plutôt que d’accorder les permissions une par une à chaque personne.

Ce que le produit décide

• Trois rôles SYSTÈME existent d’office : Admin, Manager et User. Ils ne se suppriment pas.
• Vos propres rôles s’ajoutent à côté, et se suppriment — à une condition : qu’ils ne soient plus attribués à personne.

Ce qui est exigé à la saisie

• Aucune saisie sur cet écran.
• Supprimer un rôle SYSTÈME est refusé : « Impossible de supprimer un rôle système par défaut ».
• Supprimer un rôle encore attribué est refusé aussi : « Ce rôle est encore assigné à des utilisateurs. Retirez-le d’abord. »

Ce qui précède, ce qui suit

• Un clic sur une ligne ouvre la fiche du rôle.
• Les droits d’un rôle s’accordent sur son écran dédié, pas ici.

_{Texte repris de l'aide affichée dans le produit (clé roles-liste) — régénéré, ne pas modifier ici.}

1. Nouveau rôle — un rôle est un paquet de permissions qu'on donne d'un coup. On ne donne pas de permission à une personne : on lui donne un rôle.
2. Les rôles — chacun porte le nombre de permissions qu'il accorde et le nombre de membres qui le détiennent. Un rôle encore attribué ne se supprime pas.

_{Capture du 2026-09-09 · pilotiz.izwebservices.ma · version affichée Pilotiz v1.0.0 · dépôt 7f1d87f9}

Les permissions d'un rôle

Où cliquer — un clic sur un rôle, puis l'onglet Permissions.

_{Adresse directe : /roles/:id/permissions}

Décider, permission par permission, ce que ce rôle autorise.

Ce que le produit décide

• Une permission autorise une ACTION sur un domaine — voir des clients, créer une facture, encaisser un paiement.
• Ce que l’on retire ici disparaît immédiatement de l’écran des personnes concernées : les boutons d’une action interdite ne s’affichent pas.
• L’affichage n’est toutefois que la moitié de la protection : c’est le SERVEUR qui refuse réellement une action non autorisée. Masquer un bouton ne suffirait pas.
• Le PROPRIÉTAIRE de l’organisation n’est concerné par aucune de ces cases : il contourne toute vérification.

Ce qui est exigé à la saisie

• Modifier les droits d’un rôle demande le droit de gérer les rôles.

Ce qui précède, ce qui suit

• Un changement prend effet à la prochaine ouverture de session des personnes concernées.
• Pour savoir qui est affecté, consultez l’onglet Utilisateurs du rôle AVANT de modifier.

_{Texte repris de l'aide affichée dans le produit (clé roles-permissions) — régénéré, ne pas modifier ici.}

Le catalogue des permissions

Où cliquer — dans le menu, section Administration ▸ Permissions.

_{Adresse directe : /permissions · chemin repris du menu du produit, régénéré.}

Consulter la liste des droits que le produit connaît, et ce que chacun autorise.

Ce que le produit décide

• Cet écran RECENSE les permissions ; il n’en accorde aucune. Un droit se donne toujours par un RÔLE.
• Les permissions sont nommées par domaine et par action, ce qui permet de retrouver celle qui manque quand un bouton n’apparaît pas.

Ce qui est exigé à la saisie

• Aucune saisie sur cet écran.

Ce qui précède, ce qui suit

• Quand quelqu’un ne voit pas une action, cherchez ici la permission correspondante, puis accordez-la sur son rôle.

_{Texte repris de l'aide affichée dans le produit (clé permissions-catalogue) — régénéré, ne pas modifier ici.}

1. Les permissions, par domaine — ce sont les clés que le produit connaît : lire un client, créer une facture, gérer le catalogue. Cet écran les liste, il ne les distribue pas.
2. C'est ici qu'on comprend un refus. Un bouton absent n'est pas une panne : c'est une permission que votre rôle ne porte pas. Le nom affiché ici est celui que l'administrateur cherchera dans le rôle.

_{Capture du 2026-09-09 · pilotiz.izwebservices.ma · version affichée Pilotiz v1.0.0 · dépôt 7f1d87f9}

Parcours guidés

1. Accueillir quelqu'un dans l'organisation

1. Dans /utilisateurs, cliquez Nouvel utilisateur.
2. Renseignez son identité et son adresse — c'est par elle qu'il recevra ses accès, et c'est le seul chemin vers son compte.
3. Donnez-lui au moins un rôle. Le produit l'exige, et pour une bonne raison : sans rôle, il pourrait se connecter et ne rien faire.
4. Choisissez : lui envoyer ses accès par courriel, ou définir un mot de passe que vous lui remettez vous-même.

2. Ajuster ce que quelqu'un peut faire

1. N'ajustez pas la personne, ajustez son rôle — ou donnez-lui un autre rôle.
2. Pour changer ce qu'un rôle permet : /roles, ouvrez-le, onglet Permissions.
3. Le changement vaut aussitôt pour tous les membres qui portent ce rôle. C'est l'intérêt, et c'est aussi la précaution à prendre : vérifiez combien de personnes sont concernées avant.

3. Comprendre un refus

Un bouton absent, un écran qui renvoie vers « accès refusé » : ce n'est pas une panne.

1. Ouvrez /permissions et repérez le nom de la permission qui correspond à l'action.
2. Ouvrez /roles, puis le rôle de la personne, onglet Permissions.
3. Si la permission n'y est pas, c'est la réponse. Ajoutez-la au rôle, ou donnez à la personne un rôle qui la porte.

Ce qu'il faut savoir

Un membre doit porter au moins un rôle. Le produit refuse de créer un compte sans rôle : un utilisateur qui peut se connecter sans rien pouvoir faire n'est pas un compte, c'est un piège.

Le propriétaire ne se désactive pas. C'est le compte qui a créé l'organisation ; il conserve tous les droits, et aucun rôle ne peut les lui retirer. Sans cela, une erreur de manipulation pourrait fermer l'organisation à tout le monde.

Un rôle encore attribué ne se supprime pas. Retirez-le d'abord de ses membres — le produit vous dit combien en portent chacun.

Les permissions ne se distribuent pas depuis leur catalogue. L'écran /permissions liste ce qui existe ; l'attribution se fait toujours par un rôle.

Désactiver n'est pas supprimer. Un membre désactivé ne peut plus se connecter, mais tout ce qu'il a créé — devis, factures, tâches — reste en place et lui reste attribué. C'est voulu : l'historique ne se réécrit pas.

Si quelque chose ne va pas

Ce que vous voyez	Faites d'abord
« Un utilisateur doit porter au moins un rôle »	Choisissez-en un : le compte ne peut pas être créé sans
Le membre ne reçoit pas ses accès	Vérifiez son adresse, puis /parametres → SMTP : c'est votre serveur qui envoie
Impossible de supprimer un rôle	Il est encore attribué : retirez-le de ses membres d'abord
Un bouton manque à quelqu'un	Comparez la permission attendue (/permissions) avec celles de son rôle
Le propriétaire n'est pas modifiable	C'est la règle : il conserve tous ses droits, par sécurité
Un membre parti garde ses documents	Normal : désactivez-le. L'historique reste, et c'est voulu