Des conversations qui savent disparaître
Des conversations qui savent disparaître
Trois espaces de discussion, une purge automatique 48 h après la soirée, une notification par couple et non par personne, et un déclencheur de base de données qui fait sonner votre téléphone. Épisode consacré à la messagerie.
Les quatre premiers épisodes ont traité l’architecture, le Débriefing, la géographie et la réputation. La messagerie est la pièce qui les relie et celle où la question « combien de temps garde-t-on ça ? » se pose le plus crûment.
Trois espaces, trois durées de vie
Il y a trois lieux où l’on écrit dans l’app et ce ne sont pas trois habillages de la même table. Chacun a son propriétaire, sa portée et sa date de péremption.
Pourquoi le fil de match n’a-t-il pas réutilisé le fil de soirée ?
La tentation était grande : une table de discussions existait déjà, il suffisait d’y brancher les matchs. Nous ne l’avons pas fait, pour deux raisons écrites noir sur blanc dans la migration.
D’abord, le fil hôte ↔ invité est asymétrique par construction : il a un côté qui organise et un côté qui demande. Un match n’a pas de côté fort : les deux parties y sont exactement au même rang. Plier l’un dans l’autre aurait imposé une hiérarchie là où il n’en faut pas.
Ensuite et surtout, les fils de soirée sont purgés 48 h après l’événement, alors qu’un fil de match doit survivre. Partager la table, c’était accepter qu’un jour une tâche de nettoyage un peu trop large efface une vraie conversation.
Deux données qui doivent mourir à des dates différentes ne peuvent pas vivre dans la même table.
La purge et pourquoi elle vit hors de la base
Effacer un fil de soirée ne consiste pas seulement à supprimer des lignes. Les gens s’envoient des photos : un plan d’accès, un lieu, une tenue. Ces fichiers vivent dans un espace de stockage séparé et une fonction de base de données ne sait pas les supprimer d’elle-même.
La purge est donc une tâche planifiée côté application, exécutée automatiquement chaque jour : elle efface les messages et les images. Une colonne marque chaque soirée déjà nettoyée, avec un index qui ne couvre que celles restant à traiter : la tâche ne rescanne jamais l’historique complet. C’est un détail d’index et c’est ce qui fait qu’une purge quotidienne le restera dans deux ans.
« Effacé » veut donc dire effacé : plus de ligne, plus de fichier. Pas un drapeau « masqué » posé côté interface sur des données qui dorment toujours quelque part.
Le fil de match, lui, a sa propre règle de ménage, plus prudente : un match resté totalement muet peut être nettoyé, un fil où au moins un message a été échangé ne l’est jamais. Et sa fermeture reste un geste humain, décidé par l’une des deux parties, comme raconté dans l’épisode 02.
Le bug qui rendait les couples sourds
Voici le bug le plus embarrassant de la série et il découle directement du choix du premier épisode : le couple est une entité, pas deux comptes côte à côte. Une notification adressée à un couple porte donc un identifiant de couple, pas celui d’une personne.
Deux erreurs se cumulaient. La table exigeait que cet identifiant corresponde à un compte utilisateur réel, ce qu’un identifiant de couple n’est pas : toute notification adressée à un couple était rejetée à l’insertion. Et les règles de lecture comparaient littéralement « l’identifiant du couple » à « l’identifiant de la personne connectée », condition qui ne pouvait être vraie que sous une ancienne convention bancale. Autrement dit : ces notifications ne s’inséraient pas et, quand elles s’inséraient, aucun des deux membres ne pouvait les lire.
Visites de fiche, candidatures reçues par un hôte en couple, invitations de soirée : rien n’arrivait. Le correctif remplace la comparaison par une vraie résolution, l’identifiant de couple du profil qui demande, tout en conservant l’ancienne comparaison pour que les notifications déjà en base restent lisibles. C’est le prix d’une convention changée en cours de route : on ne réécrit pas l’historique, on le supporte.
Le temps réel et les tables que l’on avait oubliées
Les messages arrivent sans rafraîchir la page : la base pousse ses changements vers les clients connectés. Encore faut-il l’avoir demandé pour chaque table. Les discussions étaient bien branchées ; les invitations de soirée, les retours des bêta-testeurs et, précisément, les notifications ne l’étaient pas. Elles n’apparaissaient donc qu’au prochain chargement complet.
Le correctif est administratif plus que conceptuel : déclarer ces tables dans la publication temps réel. C’est le genre d’oubli qui ne casse rien : il rend juste l’app sourde, ce qui est pire, parce qu’on croit que ça marche.
Du déclencheur en base à votre écran verrouillé
Le temps réel ne suffit pas : il exige que l’app soit ouverte. Pour l’app installée sur l’écran d’accueil, il faut une notification push. La mécanique tient en une phrase : chaque nouvelle notification enregistrée en base déclenche, depuis la base elle-même, un appel vers un petit service qui retrouve vos appareils et leur envoie le message.
Deux détails comptent. Cet appel est asynchrone : si le service d’envoi est lent ou indisponible, l’enregistrement de la notification n’est pas ralenti d’une milliseconde. La notification existe toujours dans l’app, même quand le push échoue : l’un ne doit jamais dépendre de l’autre.
Et le secret qui authentifie cet appel n’est pas dans le code. Il est stocké dans un coffre côté serveur, provisionné à la main et la migration le dit explicitement pour que personne ne soit tenté de l’écrire dans un fichier suivi par Git. Si le secret n’est pas encore en place, le déclencheur passe son tour au lieu de faire échouer la notification. Un composant absent ne doit pas casser le composant principal.
Un membre peut avoir plusieurs appareils, chacun avec son abonnement et chacun n’est lisible et supprimable que par son propriétaire. Se désabonner, c’est supprimer la ligne et non cocher une case qui laisse l’abonnement actif dans un coin.
Le réglage qui n’existait pas
Petite anecdote qui vaut mieux que n’importe quel plaidoyer sur les tests : la page Paramètres proposait depuis un moment un interrupteur « notifications push » et un choix de thème. Les deux colonnes correspondantes n’existaient pas en base. Le bouton « Enregistrer » échouait donc en silence : l’app affichait un réglage qu’elle n’avait jamais enregistré.
C’est le pire scénario possible pour une préférence de confidentialité : donner l’illusion du contrôle. Les colonnes ont été créées en même temps que le push, avec leurs valeurs par défaut. Depuis, le réglage fait ce qu’il annonce.
Ce que ça vous garantit
Ce que vous écrivez pour organiser une soirée disparaît deux jours après, images comprises, sans que vous ayez à y penser. Ce que vous écrivez à quelqu’un après un match reste et vous pouvez l’effacer pour de bon quand vous voulez. Une notification adressée à un couple est une notification, pas deux. Et un réglage de notifications qui affiche « désactivé » signifie désactivé.
Prochain épisode : la certification et le contrôle d’entrée. Le code à scanner, ce qu’il contient et surtout ce qu’il ne contient pas.
Questions fréquentes sur la messagerie et les notifications
Combien de temps les messages d'une soirée sont-ils conservés ?
Les fils du salon de soirée et du fil hôte-invité sont automatiquement effacés, messages et images compris, 48 heures après l'événement. Seul le fil de match, entre deux personnes à égalité, n'a pas de limite de durée et se referme sur décision humaine.
Pourquoi les fils de match sont-ils séparés des fils de soirée ?
Parce que le fil hôte-invité est asymétrique (un côté organise, l'autre demande) alors qu'un match met les deux parties au même rang, et surtout parce que les fils de soirée sont purgés après 48h alors qu'un fil de match doit survivre.
Une notification adressée à un couple part-elle en double ?
Non, une seule notification est envoyée pour le couple, pas une par personne : c'est un choix d'architecture délibéré, qui a nécessité un correctif pour que les deux partenaires puissent bien la recevoir.
Que se passe-t-il si le service d'envoi des notifications push est indisponible ?
L'enregistrement de la notification dans l'application n'est jamais ralenti ni bloqué : l'appel vers le service d'envoi est asynchrone, donc la notification reste toujours visible dans l'app même quand le push échoue.
