Doveborn : aucune des deux lettres ne s'ouvre tant que les deux ne sont pas scellées

Le contexte

Doveborn, c’est une lettre par semaine entre deux personnes. C’est tout le produit.

Vous écrivez tous les deux. Aucune des deux lettres ne se déverrouille tant que les deux ne sont pas scellées. Si votre partenaire n’a pas écrit la sienne, vous ne regardez rien du tout, peu importe le nombre de fois où vous ouvrez l’app. Quand la seconde est scellée, les deux apparaissent en même temps.

C’est en liste d’attente.

Le problème

J’ai la même conversation avec des gens qui comptent pour moi dans trois apps différentes et rien de tout ça ne s’accumule en quoi que ce soit. La messagerie est optimisée pour l’immédiateté, ce qui veut dire qu’elle est optimisée contre la réflexion. Ce que vous auriez dit correctement avec vingt minutes devant vous se dit mal en vingt secondes, et puis ça défile et ça disparaît.

Le mécanisme précis que je cherchais vient d’avoir regardé comment les gens se comportent quand ils peuvent lire le message de l’autre en premier. Ils s’alignent dessus. Longueur, ton, profondeur, effort. Quelqu’un écrit trois lignes et vous répondez trois lignes, et l’échange se stabilise au plancher plutôt qu’au plafond. Les accusés de lecture aggravent le tout, parce que le silence devient lisible et que vous jouez tous les deux devant lui.

Retirez la possibilité de lire en premier et l’ancrage disparaît. Vous écrivez ce que vous avez, pas ce sur quoi vous vous alignez.

Mon rôle

Seul, comme pour tout chez Nuits. Produit, design d’interaction, ingénierie, textes, le modèle de confidentialité.

Le modèle de confidentialité est la partie que je montrerais. Ce n’est pas un document de politique écrit après coup pour décrire un système. C’est une contrainte autour de laquelle j’ai conçu le système, et elle m’a supprimé des fonctionnalités que je voulais.

L’approche

Le scellage est le produit, donc l’interface existe surtout pour que sceller soit un geste délibéré. L’écriture se fait sur une page plein écran, sans ornement, sans barre de mise en forme et sans compteur de caractères. Il y a une seule action à la fin et elle est irréversible. Cette irréversibilité fait un vrai travail : une lettre modifiable est un brouillon, et un brouillon ne se termine jamais.

L’état d’attente était l’autre problème de design. Une fois que vous avez scellé et que votre partenaire ne l’a pas fait, il n’y a rien à montrer et une forte tentation de remplir l’espace avec des encouragements, des barres de progression ou des relances. Tout ça transforme l’attente en pression, et la pression appliquée à une lettre hebdomadaire produit une mauvaise lettre hebdomadaire. L’écran d’attente est presque vide, exprès.

Il y a des amorces, optionnelles, pour les semaines où vous ouvrez la page et n’avez rien. C’est le seul endroit où un modèle touche le produit.

La construction

TanStack Start avec TanStack Query et React 19, livré en PWA pour qu’il s’installe et se pose sur un écran d’accueil, là où un rituel hebdomadaire survit vraiment. Query gère la synchronisation entre l’état scellé et l’état déverrouillé, ce qui est plus délicat que ça n’en a l’air : deux clients peuvent sceller dans la même seconde, et tous les deux doivent passer de l’attente à la révélation sans que l’un ou l’autre clignote par un état intermédiaire.

Le design de la confidentialité est la décision porteuse. Le modèle qui propose les amorces lit des métadonnées, et rien que des métadonnées. Il sait depuis combien de semaines le duo tient, à peu près quelle longueur font les lettres, combien de temps s’est écoulé depuis le dernier échange, et quels grands thèmes le duo a choisis pour lui-même. Il ne reçoit jamais le corps des lettres. Pas une phrase, pas un extrait, pas un résumé.

Cette contrainte m’a coûté la fonctionnalité que je voulais le plus construire. Un générateur d’amorces qui a lu vos six dernières lettres peut poser une question vraiment bonne. Un générateur d’amorces qui travaille à partir de compteurs et de dates en pose une correcte et générique. J’ai livré la correcte et générique, parce que l’alternative rend la phrase « vos lettres sont privées » fausse d’une façon que la personne qui la lit n’attendrait pas, et je ne suis pas prêt à écrire cette phrase pour ensuite la nuancer discrètement.

Le reste découle de la même règle. Les lettres sont stockées, parce qu’il faut pouvoir les relire, mais rien dans le pipeline ne les analyse. Pas de score de sentiment, pas d’extraction de sujets, pas d’index de recherche construit sur les corps, pas de modèle d’engagement. Il n’y a pas de fil à optimiser, donc il n’y a rien avec quoi l’optimiser.

Les modes de défaillance tournent surtout autour de l’asymétrie. Une personne scelle toutes les semaines et l’autre s’arrête, et l’app doit gérer ça sans se transformer en machine à culpabiliser. Pour l’instant, elle laisse simplement la lettre scellée en attente et ne dit rien. Ce n’est pas un problème résolu ; c’est un refus délibéré de le résoudre mal.

Le résultat

Liste d’attente sur doveborn.com. C’est le statut honnête.

Le mécanisme a tenu lors des tests avec le petit nombre de duos qui l’utilisent. Personne n’a demandé à pouvoir jeter un œil en avance, ce à quoi je m’attendais à moitié comme première requête.

Ce que je ferais autrement

J’ai passé trop de temps sur l’éditeur de lettre et pas assez sur la révélation. La révélation est la charge émotionnelle du produit entier et pour l’instant elle se contente d’afficher deux lettres. Ça devrait être l’écran le plus travaillé de l’app et c’est le moins travaillé.

J’aurais aussi construit le parcours d’invitation du duo avant l’expérience d’écriture. Tout dans Doveborn demande deux personnes, et j’ai construit la moitié solo en premier, ce qui m’a fait découvrir tard les parties inconfortables de l’invitation.