Cahier des charges

Contexte et problématique

Le harcèlement en ligne ne ressemble pas à une attaque informatique. Il ne fait pas tomber un serveur, il détruit une personne. Sa forme la plus insidieuse est l'acharnement coordonné : un groupe se ligue contre une cible, souvent pour une raison futile ou par pure malveillance, et détourne les outils mis à disposition par la plateforme pour la faire taire. Les signalements en meute deviennent une arme. Le contenu de la victime est supprimé non pas parce qu'il enfreint une règle, mais parce que le volume de signalements a suffi à déclencher une sanction automatique.

Les grandes plateformes gèrent mal ce cas précis, pour une raison simple : leur modération traite le volume comme un signal de vérité. Cinquante signalements valent, à leurs yeux, cinquante fois plus qu'un seul. Or une meute organisée produit ce volume à la demande. Le système censé protéger se retourne contre la personne visée, pendant que les agresseurs restent impunis.

Vantablvck part du constat qu'aucune modération pilotée par le volume n'est juste. La réponse efficace repose sur un principe inverse : le nombre de signalements ne sert qu'à prioriser une revue humaine, jamais à condamner. Un humain juge le fond, et la plateforme protège d'abord la cible.

Ce qu'est Vantablvck

Vantablvck est un réseau social communautaire, hybride texte, image et vidéo courte. Son architecture est un monorepo unique, hébergeable sur un seul VPS au départ, mais conçue dès le début pour tenir la montée en charge.

Le nom porte une identité culturelle, il ne fixe pas une clause d'accès. Le réseau est ouvert à tout le monde, sans restriction fondée sur l'origine ou la couleur de peau, ce qui serait illégal en France et contraire à l'esprit du projet. Ce qui distingue Vantablvck, ce n'est pas qui peut entrer, c'est comment le réseau est modéré : par des personnes qui ont le sens de la proportionnalité et qui savent reconnaître un acharnement injustifié.

Le différenciateur du produit n'est donc pas le fil d'actualité, c'est le module de confiance et de sécurité. Tout le reste, publier, suivre, réagir, est du réseau social standard.

Ce que Vantablvck n'est pas

• Ce n'est pas un espace réservé à une communauté. L'inscription est ouverte à tous.
• Ce n'est pas une plateforme commerciale. La licence interdit l'usage marchand.
• Ce n'est pas une chambre d'écho non modérée. La modération est le cœur du produit, pas une option.
• Ce n'est pas un clone complet de TikTok. La vidéo est volontairement bornée pour rester hébergeable en solo.

Positionnement et principes

Trois principes gouvernent toute la conception.

1. Proportionnalité. Une sanction se mesure à la gravité réelle d'un acte, jamais au nombre de signalements. Le volume ne fait que prioriser une revue.
2. Protéger la cible d'abord. Face à un acharnement, la première action ralentit les interactions entrantes vers la personne visée, avant même de juger le fond.
3. Transparence. Toute décision de modération est motivée, journalisée dans un registre append-only, et contestable par un appel.

Architecture distribuée

Le système est un monorepo découpé en applications et packages à responsabilité unique, orchestré par Nx sur le runtime Bun.

Le client web est la cible prioritaire, sous forme de PWA. L'application native Expo existe dans le dépôt mais reste gelée tant que le web n'a pas atteint le périmètre du MVP, pour ne pas imposer à une personne seule la maintenance de deux clients.

Le serveur Elysia délègue tout le travail lourd (transcodage vidéo, scan des médias, calcul d'acharnement, fan-out du feed) à un worker via une file de jobs, ce qui garde les requêtes web rapides et permet de scaler les workers indépendamment.

Périmètre fonctionnel

F1. Comptes et authentification

Inscription par email avec vérification obligatoire, connexion par session, double authentification optionnelle, âge minimum contrôlé. L'authentification est auto-hébergée via Better Auth, les identités restent dans la base du projet.

F2. Profil

Chaque compte possède un profil : handle unique, nom affiché, biographie, avatar, bannière. Le profil porte aussi les champs qui servent à la modération : niveau de confiance, rôle et statut.

F3. Publication

Publication de texte, d'image, et de vidéo courte bornée. Réponses et citations sont supportées.

F4. Médias

Les médias sont envoyés directement vers le stockage objet via des URLs pré-signées, jamais à travers l'API. Les images sont normalisées et voient leurs métadonnées EXIF retirées. La vidéo est transcodée par un worker. Rien n'est diffusé avant la fin du scan de conformité.

F5. Fil d'actualité

Fil chronologique inverse par défaut, plus un fil de découverte fondé sur des signaux transparents. Aucun algorithme opaque au MVP. La pagination se fait par curseur ULID, jamais par OFFSET, car le fil est le chemin le plus sollicité.

F6. Graphe social

Suivre, ne plus suivre, bloquer, mettre en sourdine un compte ou un mot-clé. Le blocage est réellement bloquant, sans contournement possible.

F7. Interactions

Like, réponse, repost, citation. Les nouveaux comptes sont bridés sur ces actions tant qu'ils n'ont pas gagné en confiance.

F8. Notifications

Notifications in-app en temps réel léger via SSE au MVP, puis Web Push une fois la PWA complète, ce qui permet des notifications sans passer par un store.

F9. Signalement

Signalement d'une publication, d'un média, d'un utilisateur ou d'un message. Le motif est catégorisé car il détermine la priorité et le circuit de traitement.

F10. Console de modération

File de revue triée par priorité, rôles distincts (utilisateur, signaleur de confiance, modérateur, administrateur), décision documentée obligatoire, et journal d'audit append-only de toutes les actions.

F11. Anti-acharnement

Détection d'un afflux anormal et coordonné d'interactions négatives vers une même cible. La protection ralentit les interactions entrantes des comptes récents ou non liés, le temps qu'un humain regarde. Le poids d'un signalement dépend de la fiabilité et de l'indépendance du signaleur, pas du nombre. Une meute coordonnée pèse donc moins qu'une poignée de signaleurs fiables.

F12. Sanctions graduées et appel

De la plus douce à la plus forte : avertissement, limitation de débit, mise en sourdine, dévisibilisation, suspension, bannissement. Chaque sanction est motivée, notifiée quand cela a du sens, contestable, et journalisée.

F13. Anti-abus

Limitation de débit multi-niveaux, friction renforcée sur les nouveaux comptes, messages privés restreints par défaut aux comptes qui se suivent mutuellement. Le lancement se fait sur invitation, ce qui régule à la fois les fermes de comptes et la charge de modération.

F14. Conformité

Le projet est soumis au statut d'hébergeur (LCEN), au DSA (mécanisme de signalement, décision motivée, appel, transparence), au RGPD, et à l'obligation de détection des contenus pédocriminels dès qu'il y a des médias.

F15. Application web progressive

Installable sur mobile via l'ajout à l'écran d'accueil, notifications Web Push, mode hors-ligne léger. Une seule base de code, pas de dépendance à un store.

Les couches de modération

La modération n'est pas une fonctionnalité annexe, c'est l'architecture centrale. Elle se conçoit avant le fil d'actualité.

1. La charte

Deux catégories nettement séparées. Le contenu illégal (haine raciale, menaces, contenus pédocriminels) déclenche un retrait obligatoire et une procédure légale. Le contenu contraire à la charte mais légal (acharnement, mépris organisé) relève du choix éditorial de la plateforme, qui est pleinement autorisée à le modérer.

2. Le triage

Chaque signalement rejoint une file triée par priorité. La priorité dépend du motif, d'un score de risque automatique, et de la vulnérabilité de la cible. La classification automatique de toxicité assiste ce triage, elle ne juge jamais seule.

3. La pondération anti-meute

C'est le cœur technique du projet. Inspiré du mécanisme de bridging de Community Notes, le poids d'un signalement ne vaut pas une voix. Il dépend de la fiabilité historique du signaleur et de son indépendance vis-à-vis d'une coordination. Un afflux de comptes récents et liés est traité comme un signal d'acharnement contre la cible, pas contre elle.

4. La décision humaine

Un modérateur tranche le fond, avec le principe de proportionnalité en règle absolue. La machine trie et protège, l'humain juge, jamais l'inverse.

Sécurité et conformité

Licence et gouvernance

Le projet est source-available, pas open source au sens strict de l'OSI, car il restreint l'usage commercial. Le code est sous une licence non commerciale de type PolyForm Noncommercial, le contenu sous CC BY-NC-SA. Une politique de marque protège le nom et le logo, ce qui empêche un fork de se faire passer pour le projet officiel. Les contributions passent par un DCO, un code de conduite cohérent avec la mission, et une gouvernance écrite.

Les choix techniques et leurs justifications

Pourquoi Bun et Elysia ?

Le point d'avoir choisi Elysia plutôt qu'un routeur minimal, c'est d'exploiter son écosystème : validation intégrée compatible Zod, macros qui encodent les garde-fous de sécurité directement dans le pipeline du framework, OpenAPI généré depuis les schémas, observabilité via OpenTelemetry. La friction anti-abus et la proportionnalité vivent au niveau du framework, pas dispersées dans les handlers.

Pourquoi Better Auth plutôt que Clerk ?

Vantablvck protège une population qui se fait harceler. Confier le registre de leurs identités à un tiers hébergé aux États-Unis contredit la mission et ajoute une surface de conformité. Better Auth tourne dans la base du projet, les identités restent souveraines, le coût ne dépend pas du nombre d'utilisateurs, et un fork peut s'auto-héberger sans compte tiers.

Pourquoi RustFS pour le stockage ?

RustFS est compatible S3, sous licence Apache, écrit en Rust. Comme le code ne parle que l'API S3, le choix reste réversible : basculer vers un autre fournisseur ne change qu'un endpoint, jamais la logique métier.

Pourquoi une PWA d'abord ?

Une seule base de code, installable sur mobile sans passer par un store, ce qui évite aussi la modération des stores pour une application sensible. L'application native Expo reste prête mais gelée, pour ne pas doubler la charge de maintenance en solo.

Pourquoi des identifiants ULID ?

Les tables métier utilisent des ULID, triables dans le temps et adaptés à la pagination par curseur. Cela évite le piège du OFFSET sur le fil d'actualité, qui s'effondre en quelques semaines d'usage.

Ce que le projet produit

• Un serveur d'API Elysia qui expose les données de façon typée et applique les garde-fous de modération.
• Un worker qui traite l'asynchrone : transcodage, scan des médias, détection d'acharnement, fan-out.
• Une application web progressive, cible principale des utilisateurs.
• Une base de données PostgreSQL avec un schéma métier typé et migré.
• Un site de documentation intégré, celui que vous lisez.

Confidentialité et éthique

Vantablvck héberge des contenus produits par des personnes souvent déjà vulnérables. Cela impose des responsabilités claires. Les données d'identité restent dans l'infrastructure du projet, jamais chez un tiers. La documentation publique ne détaille jamais les paramètres internes de détection, car les trolls lisent la documentation pour la contourner. Et la promesse tient dans une phrase : ici, on sait faire la différence entre une critique légitime et un acharnement injustifié, et on protège la cible.