WikiStudent

Les memes du campus, en cartes.

Chaque école a ses running gags : la machine à café en panne, l’amphi de 8 h, le chat qui traîne sur le campus. WikiStudent en fait un jeu de cartes à collectionner propre à chaque école. Les étudiants proposent des cartes, le BDE les modère, tout le monde ouvre des boosters pour compléter son classeur.

Le modèle économique est volontairement simple : le BDE paie une fois (20 € pour une promo, 30 € jusqu’à cinq) et ses étudiants jouent gratuitement.

Cartes de l’école de démo, illustrations générées.

Une spec, puis des agents.

J’ai d’abord écrit un cahier des charges complet : offres, rôles, règles de tirage, économie de pièces, modération, droit à l’image, pages légales, design system. Il a été pensé pour qu’un agent de code puisse construire l’app d’une traite.

Le développement s’est ensuite fait avec Claude Code et plusieurs sous-agents en parallèle, chacun sur sa branche (jeu, espace BDE, paiement, app native, pages légales), puis fusionnés. Mon travail : découper, cadrer chaque agent, relire, tester et arbitrer. Les choix sont consignés dans un journal de décisions.

• Règles du projet écrites pour les agents : aucune règle de jeu côté client, aucun any, chaque fonctionnalité livrée avec ses tests.
• Un commit par étape logique, pour pouvoir relire et revenir en arrière.

De l’école au premier booster.

1. Le BDE crée l’école. Il paie via Stripe (ou entre en bêta sur invitation) et obtient un code d’invitation par promo.
2. Les étudiants rejoignent. Code d’invitation, e-mail confirmé, et ils peuvent appartenir à plusieurs écoles et basculer de l’une à l’autre.
3. Ils proposent des cartes. Photo recadrée et compressée dans le navigateur, consentement obligatoire à l’envoi.
4. Le BDE modère. Il accepte, choisit la rareté, et la carte entre dans les tirages.
5. On ouvre des boosters. Ils se rechargent avec le temps ; les doublons se défaussent en pièces, qui servent à ouvrir des boosters bonus ou à échanger sur le marché.

Les règles vivent dans la base.

Le choix structurant : aucune règle de jeu, de pièces ou de rôle côté client. Tout passe par des fonctions SQL dans Postgres, appelées en RPC. Un joueur qui modifie le JavaScript de la page ne peut donc ni se créer des pièces ni forcer un tirage.

Autour : Supabase Auth, Stripe pour les écoles, RevenueCat pour les achats in-app, des crons Vercel pour les tâches de nuit.

Ce qui demandait de la rigueur.

Des probabilités honnêtes.

Extrait de lib/odds.ts : seules comptent les raretés qui ont encore au moins une carte tirable, exactement comme dans la fonction SQL open_booster.

export function boosterOdds(rarities: OddsRarity[], cards: OddsCard[]): Odds[] {
  // Une rareté unique déjà trouvée n’est plus tirable
  const drawable = rarities.filter(
    (r) => cards.some((c) => c.rarity_id === r.id && (!r.is_unique || !c.found_by))
      && (r.weight ?? 0) > 0,
  )
  const total = drawable.reduce((s, r) => s + Number(r.weight ?? 0), 0)
  return drawable.map((r) => ({
    label: r.label, color: r.color,
    pct: total ? (Number(r.weight) / total) * 100 : 0,
  }))
}

Casser avant de vendre.

Avant d’ouvrir aux BDE, j’ai fait auditer tout le code en cherchant à tricher. Chaque faille trouvée a d’abord été rejouée sur une base locale (création de pièces, booster rendu deux fois, école activée par un inconnu), puis corrigée par une migration et couverte par un test SQL.

• Un test lance 20 ouvertures de boosters simultanées pour vérifier qu’aucune pièce ni carte n’est comptée deux fois.
• Les images masquées ou refusées deviennent illisibles pour les membres ordinaires, et leurs liens expirent.
• Migrations rejouables sans erreur, contrôlées en production par un script en lecture seule.

Ce qui a été livré.

Les premières écoles.

L’app est en bêta sur invitation. Le lancement passe par les BDE : une école de démo prête à visiter, des reels et une prospection directe. Cinq écoles sont offertes au lancement.

Les acquis.

• Avec des agents IA, le travail qui compte devient la spec, le découpage et la relecture.
• Mettre les règles dans la base plutôt que dans le client, dès qu’il y a de l’argent ou de la triche en jeu.
• Penser juridique dès la v1 : droit à l’image, RGPD, probabilités affichées, pages légales.