Bloquer, signaler, cumuler

Journal de développeur · 07

Après la certification et le contrôle d’entrée, voici la face la moins agréable du produit et sans doute la plus révélatrice de ce qu’il est. Trois dispositifs distincts cohabitent : le blocage, qui est un geste privé, le signalement de compte, qui s’adresse à l’administration, et le red flag de fin de soirée, qui pèse sur la réputation. Ils ne se déclenchent jamais les uns les autres par accident.

Le blocage est silencieux

La personne que vous bloquez ne l’apprend jamais. Ce n’est pas une pudeur d’interface, c’est une propriété de la base : la table des blocages n’a aucune règle de lecture qui autorise la personne bloquée à voir la ligne qui la concerne. Il n’existe donc aucun chemin, aucune requête, aucune fuite possible par une page mal écrite. Le silence est garanti par le socle, pas par la discipline du code d’affichage.

En revanche, l’effet est à double sens. Bloquer quelqu’un vous retire aussi de sa vue : vous disparaissez de sa recherche d’invités et de sa carte, comme elle disparaît de la vôtre. Nous avons hésité, puis tranché : un blocage à sens unique laisse la personne gênante continuer de vous observer, ce qui est exactement le contraire de ce qu’on venait chercher.

Et le blocage est synchronisé par couple. Si vous bloquez une personne en couple, les deux membres sont couverts, dans les deux sens, y compris votre partenaire. La raison est simple : dans une soirée, un couple arrive ensemble. Bloquer une moitié de couple n’aurait aucun sens pratique.

Un blocage ne se négocie pas. Il n’a donc pas besoin d’être annoncé.

Et la soirée déjà partagée ?

C’est le cas qui a demandé le plus de discussion. Vous bloquez quelqu’un et vous êtes tous les deux inscrits à la même soirée dans dix jours. Que fait le code ?

Si vous êtes simplement co-invités, rien. Ce n’est pas au blocage de décider qui reste sur la liste d’un hôte : la soirée appartient à l’hôte, pas à nous. Vous savez désormais que la personne y sera et vous restez libre d’annuler.

Si, en revanche, l’un des deux reçoit, la règle est mécanique : on ne peut pas désinscrire un hôte de sa propre soirée, donc c’est l’autre partie qui la quitte. Le retrait est propre, pas juste un masquage : les compteurs d’inscrits par catégorie et les quantités promises en logistique sont décrémentés, et la place se libère pour quelqu’un d’autre. Le fil privé hôte-invité lié à cette soirée est supprimé, sans notification à personne. Un blocage reste silencieux même quand il a des conséquences visibles.

Les garde-fous sont côté serveur, pas côté bouton

Retirer une conversation d’une liste ne l’empêche pas d’exister. Nous avons donc doublé chaque interdiction au niveau de la base. Impossible d’ouvrir un nouveau fil de discussion avec une personne bloquée : la règle d’écriture le refuse. Et pour les fils ouverts avant le blocage, un déclencheur vérifie chaque message à l’insertion et le rejette. C’est la ceinture après les bretelles et elle a sa raison : un client peut être ancien, un onglet peut rester ouvert des heures.

Même chose pour les inscriptions. Les trois fonctions qui acceptent une candidature ou une invitation vérifient toutes la même chose avant d’aller plus loin. Les messages d’erreur sont volontairement plats : « Conversation indisponible », « Inscription impossible ». Ils ne disent jamais qu’un blocage existe, ni dans quel sens. Une erreur trop bavarde révélerait précisément ce que le blocage silencieux protège.

Le déblocage suit la même logique de propriété : il ne retire que les blocages que vous avez posés, vous ou votre partenaire. Si la personne vous a bloqué de son côté, ce blocage-là lui appartient et reste en place. Vous ne pouvez pas vous rendre visible à quelqu’un qui a choisi de ne plus vous voir.

Le signalement était un e-mail. C’était une erreur.

Pendant longtemps, signaler un compte envoyait un courriel à l’équipe. Cela marchait, au sens où le message arrivait. Mais il n’y avait ni trace en base, ni statut, ni compteur et rien dans le Centre d’administration : impossible de savoir si un signalement avait été traité, ni si un même compte revenait trois fois. Un dispositif de sécurité qui vit dans une boîte de réception n’est pas un dispositif de sécurité.

Les signalements sont désormais une table, avec le même vocabulaire de statut que le reste du back-office (nouveau, en cours, résolu, fermé), une notification poussée aux administrateurs à la seconde et une file unique où arrivent les trois provenances possibles : un signalement direct, un signalement joint à un blocage ou un refus de lien de couple. Le badge en tête de chaque fiche indique laquelle.

Point important : bloquer ne signale pas. Le code n’écrit dans les signalements que si vous cochez explicitement « signaler également ». Fusionner les deux serait pratique pour nous et malhonnête envers vous : beaucoup de blocages ne sont pas des accusations, seulement des incompatibilités.

Le red flag : qui peut signaler qui

Le red flag est le seul des trois qui touche à la réputation, il est donc le plus encadré. Il porte sur un comportement du catalogue, neuf en tout, écrits en langage clair plutôt qu’en jargon : insister après un refus, toucher sans avoir demandé, s’incruster dans une interaction en cours, dévisager comme de la marchandise, se braquer après un râteau, négocier le préservatif, manquer d’hygiène, sortir son téléphone, ignorer le dress code.

Les conditions sont strictes et vérifiées en base, pas dans l’interface. Seul l’hôte peut signaler un Voyageur et uniquement quelqu’un qui a été scanné présent à sa soirée. Seul un participant scanné présent peut signaler l’hôte et uniquement l’hôte de cette soirée-là. Un commentaire est obligatoire, plafonné à mille caractères : un signalement sans motif ne peut pas être instruit. Et on ne signale qu’une fois la même personne pour le même motif sur la même soirée, la base rejette le doublon sans le compter deux fois.

L’escalade que personne ne déclenche

Un red flag isolé peut être une soirée qui s’est mal passée, un malentendu ou une personne susceptible. Trois red flags en trois mois glissants, venant de personnes différentes et de soirées différentes, ce n’est plus un malentendu : c’est un motif.

Au troisième, le code ouvre de lui-même une escalade de compte, qui apparaît dans la file d’administration avec le décompte et la fenêtre observée. Un détail qui a demandé une deuxième passe : tant qu’une escalade est encore ouverte pour ce compte, aucune nouvelle n’est créée. Sans cette précaution, un compte problématique aurait généré une fiche par signalement supplémentaire et noyé la file au moment précis où elle devait être lisible.

L’administration voit aussi, sur chaque fiche, combien de membres ont bloqué le compte concerné. Un nombre, jamais les identités. Un compte que dix personnes ont bloqué en silence raconte quelque chose qu’aucun signalement n’a formulé et nous voulions ce signal sans transformer le blocage privé en dénonciation publique.

Ce que le code ne fait pas

Il ne suspend aucun compte tout seul. Aucun seuil, aucun cumul, aucune escalade ne coupe l’accès à quiconque : l’escalade ouvre un dossier, elle ne rend pas de jugement. Un bannissement automatique serait à la fois plus simple à écrire et impossible à défendre, parce qu’un signalement peut être injuste et qu’un système qui punit sans instruction est un système qu’on peut retourner contre quelqu’un.

Et il ne retourne jamais un signalement contre celui qui le porte. Une personne signalée ne voit pas le red flag qui la concerne, ne sait pas d’où il vient et n’a aucun moyen de le découvrir : les règles de lecture ne l’exposent qu’à son auteur et à l’administration, qui, elle, a besoin du nom pour instruire honnêtement les deux versions. La seule perte de points visible est la sienne. C’est le minimum pour que signaler reste un geste possible.

Prochain épisode : les quotas de soirée, comment un hôte décrit qui il souhaite recevoir et pourquoi le compteur de places est plus difficile à écrire qu’il n’y paraît.