+147
−0
+46
−0
Loading
Rien ne corrigeait l'identité d'un compte : ni la personne, ni un
administrateur, ni la console d'instance. Les seules écritures étaient le mot
de passe, le second facteur et la désactivation. On se mariait, l'entreprise
changeait de domaine, et le seul chemin était de retirer le compte et d'en
ouvrir un autre — ce qui coupait la personne de tout ce qu'elle avait consigné
sous l'ancien.
Les deux gestes n'ont pas le même poids, et le code les sépare pour cela. Un
nom s'affiche ; une adresse connecte.
Le nom est journalisé sans motif : l'exiger pour une faute de frappe serait une
cérémonie.
L'adresse est l'identifiant de connexion. Un administrateur qui la remplacerait
par la sienne prendrait le compte, et rien dans le produit ne l'en empêche — le
droit d'inviter au rôle de propriétaire le lui donne déjà. Ce qu'on peut faire,
et qu'on fait, c'est que cela se voie : l'ancienne adresse reçoit un courriel
disant qu'elle ne connecte plus et à qui le signaler, la nouvelle repart non
vérifiée avec son lien, et le journal retient les deux adresses et le motif.
Les envois sont au mieux : une instance sans relais de courriel doit pouvoir
corriger une faute de frappe dans une adresse. Ce qui est parti, et ce qui ne
l'est pas, est dit plutôt que tu.
── Deux garanties qui ne prouvaient rien
« Elle repart non vérifiée » portait sur un compte qui n'avait jamais vérifié
son adresse : le contrôle était vrai avant même le changement.
« Une adresse déjà prise est refusée » se contentait de n'importe quelle
erreur, et la contrainte d'unicité en base suffisait à le verdir — l'exploitant
aurait lu « duplicate key value violates unique constraint ». Les refus
attendus sont maintenant nommés.
Co-Authored-By:
Claude Opus 5 <noreply@anthropic.com>