Aller au contenu
Application web · Next.js2026

Bubblu

Un seul journal pour ce qu’on regarde, lit et joue

Plateforme full-stack API-first : films, séries, animes, livres et jeux dans un même journal, avec une API REST versionnée comme contrat produit.

Statut

En ligne, compte de démonstration ouvert

Application déployée et accessible. La documentation interactive de l'API est publique. Un client mobile est envisagé dans un second temps, il n'existe pas aujourd'hui.

tests unitaires et d’intégration
637tests unitaires et d’intégration
types de médias dans un seul journal
5types de médias dans un seul journal
API externes normalisées
4API externes normalisées

Le problème

Suivre sa vie culturelle impose aujourd'hui de jongler entre cinq services : un pour les films, un pour les séries, un pour les animes, un pour les livres, un pour les jeux. Chacun a son compte, son historique et son bilan annuel. Bubblu remplace l'ensemble par un journal unique : une recherche, un historique, une pile à faire, un récapitulatif.

Mon rôle

Conception produit, architecture, développement full-stack et pilotage : découpage en epics et issues, une branche et une PR par sujet, revue de chaque livraison avant validation de milestone.

Captures

06 écrans

01 / 06·Le journal, tous médias confondus

Le journal de Bubblu : une timeline mêlant films, séries, animes, livres et jeux

Les décisions qui ont façonné le produit.

Décisions produit
  1. Gratuit, sans publicité ni palier payant

    Le produit ne cherche pas à monétiser l'attention. Cela ferme la porte aux mécaniques d'engagement forcé et oriente toute la conception.

  2. Une gamification honnête

    Tout est déclaratif, donc les récompenses sont purement cosmétiques : pas de classement, pas de série à ne pas rompre, pas de FOMO. La monnaie de la boutique s'obtient en jouant, jamais en payant.

  3. Le bilan annuel comme fonctionnalité phare

    Un récapitulatif défilant de l'année, partageable par lien public avec une image générée, consultable sans compte.

  4. Privé par défaut

    Le profil public est une option explicite. Rien n'est exposé tant que l'utilisateur ne l'a pas décidé.

  5. Un compte de démonstration en un clic

    Depuis la page d'accueil, un clic ouvre un compte lisible seul, rempli d'une année d'entrées, de badges et de quêtes. Recréé par un seed idempotent.

Décisions techniques
  1. L'API est le contrat produit

    Les gestionnaires HTTP valident avec Zod, appellent la couche de services et mettent en forme la réponse — aucune logique métier. Le web appelle directement les services, un futur client mobile consommera `/api/v1`.

  2. Une spécification OpenAPI qui ne peut pas dériver

    La spécification OpenAPI 3.1 est générée à partir des mêmes schémas Zod que ceux utilisés pour valider les requêtes. Documentation et validation ne peuvent plus diverger.

  3. Un modèle de média normalisé

    Chaque source externe (TMDB, AniList, Open Library, IGDB) vit derrière un adaptateur qui renvoie une forme unique. Les résultats sont mis en cache en Postgres : une entrée journalisée ne change plus et ne disparaît pas si l'API source évolue.

  4. Autorisation vérifiée deux fois

    Une première fois dans la couche de services, une seconde par les politiques RLS de Postgres. Une erreur applicative ne suffit pas à exposer les données d'un autre utilisateur.

  5. Gamification déterministe

    Courbes d'XP, sélection des quêtes, badges et défis sont des fonctions pures évaluées paresseusement sur un registre idempotent en ajout seul. Aucune tâche planifiée.

  6. i18n imposée par le lint

    Une règle de lint rejette le texte brut dans le JSX. L'anglais est la locale source, le français est intégralement traduit.

Contraintes

  • Hébergement sur les paliers gratuits de Vercel et Supabase.
  • Quatre API externes avec leurs propres limites de débit et conditions d’utilisation.
  • Aucune clé de service côté client : seule la clé publiable est utilisée.
  • La suite E2E conditionne les mises en production.

Stack

  • Next.js App Router
  • TypeScript strict
  • Tailwind CSS
  • monorepo pnpm
  • Supabase
  • PostgreSQL + RLS
  • Zod
  • OpenAPI 3.1
  • Vitest
  • Playwright
  • GitHub Actions
  • Vercel
Ce que ce projet démontre

Ce que ce projet démontre

  • Conception d'une API comme contrat produit, documentée sans risque de dérive.

  • Sécurité applicative défendue à deux niveaux, dont la base de données.

  • Intégration de quatre sources externes hétérogènes derrière un modèle unique.

  • Une discipline de tests réelle, jusqu’au bout de la boucle critique.