Oui. Dès qu'une application décrite nécessite une connexion, elle embarque une gestion de comptes réelle, pas un mot de passe unique partagé : l'administrateur peut créer d'autres comptes, avec un rôle qui modifie ou un rôle en lecture seule, chacun avec son propre identifiant. La création se fait depuis l'écran Paramètres, avec un mot de passe provisoire à usage unique que la personne change à sa première connexion.
Ce que « plusieurs utilisateurs » signifie concrètement
Une application générée qui nécessite une connexion porte trois rôles distincts : administrateur, utilisateur et lecture seule. L'administrateur gère les comptes en plus d'utiliser l'application ; l'utilisateur crée, modifie et supprime des données comme l'administrateur, mais ne gère pas les comptes ; le rôle lecture seule consulte sans pouvoir écrire. Chaque personne se connecte avec son propre identifiant — ce n'est pas un mot de passe unique partagé entre toute l'équipe, ce qui veut dire qu'une action reste traçable jusqu'à la personne qui l'a faite.
Ce n'est pas une fonctionnalité à activer séparément : dès que la description de votre projet implique une connexion (un accès réservé à votre équipe, par opposition à une page publique), la gestion de comptes fait partie de ce que le builder génère.
Comment un compte est créé
Depuis l'écran Paramètres, un administrateur saisit un identifiant et choisit le rôle (modification ou lecture seule), puis valide. L'application répond avec un mot de passe provisoire, affiché une seule fois — il n'est jamais relisible ensuite, ni par l'administrateur ni par personne d'autre. La personne s'en sert pour se connecter et doit le remplacer par le sien dès la première connexion.
Un compte peut être désactivé — la désactivation se fait en deux temps (un clic pour armer, un second pour confirmer), jamais via une boîte de dialogue native du navigateur, qui gèlerait l'interface sous certains outils d'automatisation. Un administrateur ne peut désactiver ni son propre compte ni le dernier compte administrateur actif : il resterait sinon impossible de gérer à nouveau les accès.
Ce que le rôle « lecture seule » empêche réellement
La restriction n'est pas seulement visuelle. Un compte en lecture seule qui tente une création, une modification ou une suppression — même en contournant l'interface, requête API directe comprise — se voit refuser la requête au niveau du serveur, avant que la moindre écriture n'ait lieu. Ce n'est donc pas un bouton simplement masqué : c'est un garde-fou appliqué à chaque appel, peu importe comment il est déclenché.
Ce qui n'y est pas
Deux limites, dites sans détour. D'abord, les rôles sont globaux à l'application : il n'existe pas de permission fine par entité ou par section (« ce compte voit les clients mais pas la facturation ») — c'est modification ou lecture seule, sur l'ensemble. Ensuite, il n'y a pas d'authentification à deux facteurs sur les comptes d'une application générée : le mot de passe provisoire à usage unique et le renouvellement obligatoire à la première connexion sont la protection prévue, pas un second facteur. Si votre activité a besoin de permissions plus fines ou de 2FA, le code étant du Next.js et du Prisma standard et exportable, un développeur peut les ajouter à partir de ce qui existe déjà.