Tata Élise n'a pas d'email. Et alors ?

Élise a une adresse email. Son fils la lui a créée en 2014 pour un litige avec un assureur. Depuis, elle ne s'y connecte pas, et la dernière fois que je lui ai envoyé un message dessus, je crois bien qu'elle l'a lu un mois après, sur l'ordinateur de la voisine.

Quand on a montré le prototype à ma mère, sa première question n'était pas sur le calendrier. C'était : « et Élise, elle doit s'inscrire ? ». La question avait une vraie tension dedans — elle n'avait ni envie d'être celle qui dit à sa belle-sœur de créer un compte, ni envie qu'on l'écarte du système. J'ai dit non. Pas d'inscription requise.

Du coup la base de données de Superdatcha a des trucs un peu moches. Tu peux poser un séjour pour quelqu'un qui n'a pas de compte — il existe juste comme nom, et c'est l'admin qui assume la responsabilité du séjour. Côté code c'est un cas particulier (un User nullable sur la table Stay, des tests qui en tiennent compte), mais côté usage c'est ce qui permet à la maison de continuer à fonctionner comme avant. Élise dit ses dates à ma mère par téléphone, ma mère les pose, terminé.

Ça paraît évident, dit comme ça. Pourtant la moitié des outils qu'on a regardés avant de coder le nôtre exigent qu'on invite chaque personne avec un lien d'activation. Tu te retrouves à devoir convaincre ta tante de 78 ans qu'elle doit cliquer sur un lien, créer un mot de passe avec une majuscule et un chiffre, et accepter une politique de cookies. Pour qu'au final tu poses ses dates à sa place de toute façon. Aucune chance.

Donc Élise reste hors-ligne, et c'est très bien. Côté API on a aussi un mode invité pour les amis des cousins qui font une demande publique, mais ça c'est un autre sujet.