« On se passera le mot de passe »
Le compte partagé n'est pas un choix, c'est ce qui reste quand l'outil n'offre rien d'autre. Il marche très bien pendant quelques mois, puis il présente sa facture, et toujours au mauvais moment.
Trois conséquences, mécaniques. Retirer l'accès à une seule personne oblige à changer le mot de passe de TOUT LE MONDE, donc à rebriefer une équipe entière le jour d'un départ — c'est-à-dire le jour où l'on a le moins envie de s'en occuper. Ensuite, plus personne ne peut répondre à « qui a modifié cette ligne ? », puisque tout le monde est la même personne aux yeux de l'application. Enfin, on ne peut pas donner un accès partiel : celui qui vient juste consulter un chiffre reçoit exactement les mêmes pouvoirs que celui qui facture.
L'enjeu n'est donc pas la sécurité au sens spectaculaire du terme — personne n'attaque une application de quinze personnes. C'est l'irréversibilité : un compte partagé ne se démêle pas, il se remplace, et plus on attend, plus le remplacement est lourd.
- Retirer l'accès à une personne = changer le mot de passe de tout le monde.
- Aucune réponse possible à « qui a fait ça ? » : un seul compte, une seule identité.
- Pas d'accès en lecture seule : consulter et modifier donnent les mêmes droits.
Trois rôles, et la frontière exacte entre eux
Dès que l'application demande une connexion, elle embarque de vrais comptes séparés et trois rôles. Ils sont peu nombreux, et c'est volontaire : un système de droits qu'on ne comprend pas d'un coup d'œil est un système qu'on configure mal.
L'administrateur fait tout, et lui seul gère les comptes : il en crée, en désactive, réinitialise un mot de passe. L'utilisateur travaille dans l'application — il crée, modifie, supprime des données — mais ne voit pas la gestion des comptes. Le rôle lecture seule consulte : il navigue partout, ouvre les fiches, lit les tableaux de bord, et ne peut rien écrire.
Le point qui compte n'est pas la liste, c'est où le refus est posé. Pour le rôle lecture seule, le blocage n'est pas un bouton qu'on aurait masqué à l'écran : toute requête d'écriture est refusée avant d'atteindre la route, par le middleware, avec un code 403. Un bouton caché se contourne avec le clavier ou un outil de développement ; un refus posé en amont, non. C'est la différence entre une interface qui suggère et une application qui tient.
Le rôle voyage dans le cookie de session signé, ce qui permet cette vérification sans interroger la base à chaque requête. Et un visiteur sans session ne traverse rien : les pages le renvoient vers l'écran de connexion en mémorisant où il allait, et les appels d'API reçoivent un 401.
- Administrateur — tout, plus la gestion des comptes.
- Utilisateur — crée, modifie, supprime les données ; pas d'accès aux comptes.
- Lecture seule — navigue et consulte ; toute écriture refusée en 403 avant la route.
- Sans session — 401 sur l'API, redirection vers la connexion sur les pages.
Ouvrir un accès : un identifiant, un rôle, un mot de passe provisoire
La création d'un compte tient en trois informations, et aucune n'est une adresse e-mail. L'administrateur saisit un identifiant (de 2 à 31 caractères : lettres, chiffres, point, tiret, tiret bas), choisit le rôle, et l'application génère elle-même un mot de passe provisoire.
Ce mot de passe est affiché une seule fois, à ce moment-là. Il n'est pas relisible ensuite — ni dans la liste des comptes, ni ailleurs : seule son empreinte est conservée. S'il est perdu avant d'avoir été transmis, l'administrateur en régénère un, ce qui est une manipulation de dix secondes. Le compte est par ailleurs marqué comme devant changer de mot de passe : la personne est obligée de choisir le sien à sa première connexion, donc l'administrateur ne connaît pas le mot de passe de ses collègues.
Aucun e-mail n'est envoyé, et il faut le savoir avant de s'organiser : l'application ne dispose d'aucun service d'envoi. C'est à l'administrateur de transmettre l'identifiant et le mot de passe provisoire par ses propres moyens. Le corollaire est plus gênant en pratique que l'absence d'e-mail elle-même — il n'y a pas de « mot de passe oublié » en autonomie : quelqu'un qui perd le sien passe par l'administrateur, qui le réinitialise.
Le tout premier compte, lui, est créé avec l'application : identifiant « admin », mot de passe « admin », et le même changement obligatoire à la première connexion. C'est un mot de passe de mise en route, pas un mot de passe — et l'application ne vous laissera pas le garder.
- Identifiant + rôle : c'est tout ce que l'administrateur saisit.
- Mot de passe provisoire généré par l'application, montré UNE fois.
- Changement obligatoire à la première connexion — l'administrateur ne le connaît pas ensuite.
- Aucun e-mail : la transmission et les réinitialisations passent par l'administrateur.
Fermer un accès sans trouer l'historique
Un compte ne se supprime pas, il se désactive — et se réactive. Ce n'est pas une facilité d'implémentation, c'est le même arbitrage que la corbeille des données : un enregistrement supprimé pour de bon emporte avec lui tout ce qui s'y rattachait, et on ne s'en aperçoit que des mois plus tard, quand on cherche quelque chose qui n'existe plus.
Deux refus sont posés dans le code, et ce sont ceux qui évitent de se retrouver dehors. On ne peut pas désactiver son propre compte — le geste le plus facile à faire par inadvertance en nettoyant une liste. Et on ne peut pas désactiver le dernier administrateur actif : une application sans administrateur est une application dont plus personne ne peut ouvrir un accès, y compris à soi-même. Le refus est explicite, il ne se contente pas d'échouer.
Un départ se traite donc en un geste, sans toucher aux mots de passe des autres, et sans effacer une trace. Un remplacement se traite en deux : on désactive, on crée.
- Désactivation réversible plutôt que suppression.
- Impossible de désactiver son propre compte.
- Impossible de désactiver le dernier administrateur actif.
- Réinitialisation d'un mot de passe par l'administrateur, à tout moment.
Ce que ça ne fait pas, et il vaut mieux le savoir avant
Les droits sont globaux à l'application. Un compte porte un rôle, et ce rôle ne se rattache ni à une entité, ni à une section, ni à un champ. Il n'existe donc aucun moyen d'exprimer « ce commercial ne voit que ses propres clients », « cette personne accède aux interventions mais pas à la facturation », ou « ce champ est masqué pour les non-cadres ». Trois rôles couvrent bien la question « consulter ou modifier », et pas du tout la question « quelle partie ».
L'application enregistre QUAND une donnée a changé, jamais QUI. Chaque enregistrement porte automatiquement sa date de création et sa date de dernière modification, mais aucune colonne ne retient l'auteur. Des comptes séparés répondent donc à « qui peut entrer », et pas à « qui a écrit cette ligne » — ce sont deux questions différentes, et seule la première est traitée. C'est la limite la plus facile à confondre avec une capacité livrée, parce qu'avoir des comptes nominatifs donne l'impression d'avoir une traçabilité.
La connexion se fait par identifiant et mot de passe, et rien d'autre. Pas de connexion via un compte Google ou Microsoft, pas d'authentification unique d'entreprise, pas de second facteur. Pour une équipe qui gère déjà ses identités ailleurs, cela veut dire une liste de comptes de plus à tenir.
Ces quatre limites ne sont pas des oublis à contourner : ce sont les bornes de ce qui est livré, et les écrire est plus utile que de les laisser découvrir. Elles ont toutes le même recours, qui est la raison d'être du produit — le code de l'application vous appartient. C'est un projet Next.js et Prisma standard, exportable en ZIP ou poussé sur votre dépôt : ajouter une colonne d'auteur, un cloisonnement par équipe ou une authentification d'entreprise est un travail de développement ordinaire, sur du code que vous détenez, et qu'aucun éditeur ne peut vous refuser. Et si le cloisonnement est structurel à votre métier, il se décrit dès le départ — c'est votre texte qui fixe les entités et leurs liens.
- Droits globaux : aucun cloisonnement par entité, par section ou par champ.
- Date de modification enregistrée, auteur non enregistré.
- Identifiant + mot de passe seulement : ni SSO, ni connexion tierce, ni second facteur.
- Recours commun : le code est à vous, ces extensions sont du développement ordinaire.