Le Débriefing du Lendemain Midi : anatomie d'un vote secret

Journal de développeur · 02

21 août 2026 / L'équipe technique / 7 minutes

Dans le premier épisode, nous disions que la règle doit vivre dans la base et non dans l'écran. Le Débriefing du Lendemain Midi en est l'illustration la plus nette : c'est la fonctionnalité la plus intime de l'app, et il n'y a pas une seule ligne de sa logique dans votre navigateur.

Le principe, d'abord. Le lendemain d'une soirée, à midi, chaque personne qui y était peut se prononcer discrètement sur les autres présents. Trois choix, pas plus. Si deux profils se sont mutuellement mis un coup de cœur, et seulement dans ce cas, une discussion privée s'ouvre. Sinon, personne n'apprend jamais rien.

Pourquoi midi, et pourquoi 48 heures

La fenêtre de vote s'ouvre le lendemain de la soirée à midi, heure de Paris — pas « 24 heures après », ce qui aurait réveillé les gens en pleine nuit avec une décision à prendre. Elle se ferme 48 heures après le début de la soirée. Cette combinaison n'est pas décorative : elle donne à tout le monde une matinée pour dormir, puis un vrai jour et demi pour se décider, week-end compris.

Le calcul est une petite fonction de base de données qui retourne les deux bornes, et son commentaire vérifie explicitement le pire cas : une soirée qui commence à minuit ouvre son débriefing 36 heures plus tard — toujours avant la clôture à 48 heures. Une fenêtre négative, c'est-à-dire un débriefing impossible à utiliser, ne peut pas exister. Ce genre de vérification écrite noir sur blanc à côté du code vaut mieux qu'un test qu'on oublie d'écrire.

Vous pouvez changer d'avis tant que la fenêtre est ouverte : un second vote sur la même personne remplace le premier au lieu de s'y ajouter. Après la clôture, la base refuse — avec un message explicite, pas un silence.

Qui a le droit de voter sur qui

Deux conditions, vérifiées des deux côtés à chaque vote : il faut avoir été présent à la soirée — présence constatée au scan à l'entrée — ou être l'hôte, ou le partenaire de l'hôte. Et la cible doit remplir la même condition. On ne peut donc pas voter sur quelqu'un qui n'y était pas, ni depuis un compte qui n'y était pas. Voter sur soi-même, ou sur son propre couple, est refusé : ça a l'air évident, mais c'est le premier cas limite qu'un système de vote croisé oublie de traiter.

La capture ci-dessous montre d'où vient cette présence, et ce qui l'entoure. Tout part de Participants & présence : l'hôte scanne l'entrée, et chaque arrivée est horodatée. Ce scan n'est pas un geste d'accueil décoratif — c'est lui qui rend éligible aux deux mécaniques d'après-soirée, l'évaluation et le débriefing. Sans scan, pas de vote : ni sur vous, ni par vous.

Juste en dessous, Évaluer les voyageurs présents est une mécanique distincte du Débriefing, et il est important de ne pas les confondre. L'évaluation reste ouverte pendant sept jours après la soirée, porte sur trois critères notés — respect du cadre & consentement, savoir-vivre & hygiène, fiabilité & ponctualité — chacun avec un commentaire facultatif, et c'est elle qui alimente la réputation et les paliers. Elle est destinée au système, pas à l'autre personne.

Le même formulaire porte les red flags, optionnels, regroupés par famille plutôt qu'en liste à plat : non-respect du consentement — signalé comme le point le plus critique, et volontairement placé en premier —, non-respect du cadre et du lieu, attitude « supermarché » et ego mal placé, problèmes de sécurité et d'hygiène. Chaque item a son point d'interrogation : un catalogue de descriptions est stocké en base, parce qu'un signalement mal compris est un signalement injuste. Le tout part en une action, « Envoyer la notation », et les cas les plus graves déclenchent une escalade vers la modération sans passer par nous.

Et enfin, tout en bas, le Débriefing du Lendemain Midi — le sujet de cet épisode. Deux voisins sur le même écran, deux intentions opposées : la notation dit ce qui s'est passé, le débriefing dit ce qu'on voudrait qui arrive ensuite. La première est publique dans ses effets, le second est secret par construction.

Le cas du couple : c'est le vote le plus prudent qui compte

Un couple vote avec deux têtes, et les deux ne sont pas forcément d'accord. Il fallait trancher. Nous avons choisi la règle la plus réservée : le vote effectif d'un couple envers un profil est le plus prudent des votes de ses deux membres. Un coup de cœur d'un côté, « pas mon style » de l'autre : le couple dit « pas mon style ». Il faut les deux voix pour qu'un coup de cœur soit un coup de cœur.

Un match qui ne convient qu'à la moitié d'un couple n'est pas un match. C'est un malaise programmé.

Techniquement, l'ordre est encodé : pas mon style vaut 1, simple affinité 2, coup de cœur 3, et la base garde le minimum. Ce n'est pas une moyenne — une moyenne aurait fait « à peu près » plaisir à tout le monde, ce qui est exactement ce qu'il ne faut pas ici.

Le match, la discussion, et le droit de tout effacer

Quand les deux coups de cœur effectifs se rencontrent, trois choses arrivent dans la même transaction : le match est créé, un fil de discussion vierge lui est attaché, et une notification part vers chaque partie — une seule par couple, pas une par membre, comme expliqué dans l'épisode précédent. Si le match existait déjà, rien n'est dupliqué.

Et l'inverse est aussi important : l'un ou l'autre peut fermer cette discussion définitivement, à tout moment. Nous n'avons pas fait un « fil masqué » côté interface — nous supprimons le match, et le fil et les messages disparaissent avec lui, en base. Rien ne reste dans un coin. Si les deux se recroisent à une autre soirée et revotent coup de cœur, un nouveau match, et un nouveau fil vierge, pourront se créer.

Aucune de ces tables n'accepte d'écriture directe. Tout passe par des fonctions qui vérifient elles-mêmes que l'appelant fait bien partie du match visé. C'est plus long à écrire qu'un simple bouton « supprimer », et c'est la seule version dont on peut garantir le comportement.

Le bug de la semaine

Pour n'envoyer qu'une notification par couple, il faut choisir un membre « représentant ». Nous demandions donc à Postgres le plus petit identifiant du couple. Sauf que Postgres ne sait pas comparer ce type d'identifiant de cette façon — la fonction n'existe pas pour ce type de données — alors que la comparaison directe entre deux valeurs, utilisée trois lignes plus haut dans la même fonction, marche parfaitement. Résultat : chaque clic sur « Coup de cœur » levait une erreur, découverte en test manuel.

Le correctif tient en un mot : on convertit en texte pour l'opération, puis on reconvertit. L'ordre lexicographique n'a aucun sens ici, et c'est précisément le point — on ne veut pas un ordre significatif, on veut un représentant stable. Une migration entière du dépôt existe pour ça, commentaire compris. Nous préférons garder la trace de nos erreurs plutôt que de les réécrire proprement dans l'histoire.

Ce que ça dit du produit

Le Débriefing pourrait être un simple bouton « j'aime ». Il a pris une bonne dizaine de migrations, plusieurs correctifs et une règle de couple discutée longuement, parce que le sujet ne pardonne pas l'approximation : un vote qui fuit, c'est une soirée gâchée et parfois davantage. La lenteur est ici une fonctionnalité.

Prochain épisode : la carte et le calcul des distances — comment montrer qu'il y a du monde autour de vous sans jamais dire précisément où.