Étude de cas · Product Owner
Dripper
Le guide des coffee shops de spécialité en France
Une application web progressive qui référence les coffee shops français selon un critère unique : la qualité de la tasse, et non la décoration ou l'ambiance. J'ai porté l'ensemble du cycle de vie — vision, cadrage du MVP, arbitrage du backlog, développement, mise en production et suivi — puis décliné le produit en applications natives iOS et Android.
26
shops publiés
13
labellisés Sélection
7
villes couvertes
125
commits
11
pull requests
18
migrations SQL
36
visiteurs / 30 j
0
avis déposés
Données réelles issues de la base de production, de Vercel Analytics et de l'historique Git, arrêtées au 15 septembre 2026.
// Cadrage
Le problème
La troisième vague du café progresse en France, mais l'expérience de recherche reste fragmentée. Google Maps mélange indistinctement les établissements : beaucoup de « coffee shops » mettent en avant le latte art, la décoration ou le coworking au détriment de la qualité du café. L'amateur exigeant ne dispose d'aucune source de confiance pour identifier les adresses réellement sérieuses sur le grain, la torréfaction et l'extraction.
La solution
Une application web installable qui qualifie les coffee shops selon des critères centrés sur la tasse, avec un positionnement éditorial assumé — inspiré de Raisin pour le vin naturel ou du Guide Michelin.
// Marché
Analyse concurrentielle
Quatre acteurs analysés au cadrage. Aucun ne filtre sur la qualité du café : c'est l'espace que Dripper occupe.
Google Maps
Avis grand public, couverture exhaustive
→ Aucun filtre sur la qualité du café
Roasters App
Découverte mondiale des torréfacteurs
→ Pas de curation française, pas de ligne éditoriale
European Coffee Trip
Curation manuelle à l'échelle européenne
→ Faible ancrage dans la communauté française
Cappuccin
Passeport café gamifié
→ Critères de qualité non transparents
// Décisions produit
Ce que j'ai retiré, et pourquoi
Le rôle du Product Owner ne consiste pas à tout livrer, mais à maximiser la valeur avec un minimum de travail. Sept éléments du périmètre initial ont été retirés ou reportés ; une fonctionnalité prévue en v2 a été avancée pour lever un blocage réel.
Revendication de fiche
prévu : v2 → Avancé au MVPJe ne détiens pas les droits sur les photos des établissements : le gérant doit les fournir lui-même, ce qui lève le risque juridique.
Double notation Tasse / Expérience
prévu : MVP → Réduit à la note ExpérienceTrop d'informations à saisir : friction sur le dépôt d'avis. La note Tasse a été supprimée jusque dans la base de données.
Carnet de dégustation
prévu : MVP → RetiréRecentrer la v1 sur l'essentiel.
Annuaire des torréfacteurs
prévu : v1.5 → RetiréHors du périmètre prioritaire.
Lien magique (magic link)
prévu : MVP → Remplacé par email + mot de passeMoins d'étapes à l'inscription comme à la connexion.
Abonnement Pro
prévu : v1.5 → ReportéLe service reste gratuit tant que la valeur n'est pas démontrée.
PostHog, Umami, Sentry
prévu : MVP → Remplacés par Vercel AnalyticsUn seul outil pour la v1.
Géolocalisation
prévu : Non prévu → Ajouté en septembreBesoin identifié à l'usage, en déplacement.
// Livraison
Neuf itérations, reconstituées depuis Git
MVP complet en production en moins de deux semaines, du 19 avril au 2 mai 2026, puis des itérations d'amélioration continue.
Sprint 0
19 avr.
Poser les fondations
Design system, outillage, intégration continue
Sprint 1
20 – 21 avr.
Rendre le cœur du MVP utilisable
Schéma BDD, authentification, carte, fiche shop, back-office, avis, favoris, recherche
Sprint 2
22 – 25 avr.
Simplifier et ouvrir aux gérants
Flux de revendication, emails transactionnels, pages légales, PWA ; retrait de la note Tasse et du blog
Sprint 3
28 – 30 avr.
Préparer l'ouverture publique
Guides, conformité RGPD, mesure d'audience, correctifs sécurité Supabase
Sprint 4
1 – 2 mai
Performance et robustesse
Chargement différé de la carte, optimisation des images, rate limiting, pagination, tests
Sprint 5
23 – 28 mai
Expérience mobile et back-office
Menu mobile éditorial, back-office responsive, notification admin des revendications
Sprint 6
2 juin
Perception de rapidité
Écrans de chargement, préchargement tactile, pied de page
Sprint 7
Septembre
Trouver un café à proximité
Géolocalisation, distances, bouton « M'y rendre » (PR #11)
Sprint 8
24 – 28 oct.
Passer sur mobile natif
Apps iOS et Android : carte, annuaire, fiche shop, compte, avis, favoris, espace pro ; tests et CI
La cadence est très soutenue au lancement puis ralentit après mai — caractéristique d'un projet mené en parallèle d'autres activités. Cela plaide pour un rythme de sprint fixe et protégé plutôt que des itérations opportunistes. Le passage au mobile natif, en octobre, a été mené comme un sprint court et cadré.
// Technique
Architecture
Architecture serverless : aucun serveur administré directement. Écritures via Server Actions plutôt que routes d'API publiques, et Row Level Security active sur chaque table.
Framework
Next.js 16 (App Router), React 19, TypeScript strict
Pages, rendu serveur, logique applicative
Interface
Tailwind CSS 4, shadcn/ui (Radix)
Design system accessible, mode clair et sombre
Base de données
Supabase — PostgreSQL + PostGIS
Données métier et géolocalisation
Authentification
Supabase Auth
Comptes email + mot de passe, rôles
Cartographie
Mapbox GL JS + API de géocodage
Carte interactive, autocomplétion d'adresses
Emails
Resend + React Email
Emails transactionnels (revendication, validation)
Protection
Upstash Redis
Limitation du nombre de requêtes
Mobile
Expo SDK 58, React Native, Expo Router, TanStack Query
Apps iOS et Android, même backend Supabase que le site
Hébergement
Vercel
Déploiement, CDN, préproductions, mesure d'audience
// Mobile
Applications iOS et Android
Le site reste la porte d'entrée SEO ; l'application sert l'usage en déplacement, celui qui avait justifié la géolocalisation en septembre. Une seule base de code Expo, mais une interface pensée pour chaque plateforme, branchée sur le même projet Supabase que le site.
5
jours, du scaffold à la v1
21
commits
2
plateformes
0
migration SQL côté mobile
Un backend, deux clients
Le schéma et ses migrations restent dans le dépôt web ; l'app ne fait que consommer les types générés depuis Supabase. Aucune clé secrète dans le binaire : uniquement la clé publishable, protégée par la Row Level Security déjà en place.
iOS d'abord, en vrai natif
Onglets et piles natifs, Liquid Glass récupéré automatiquement sur iOS 26, SF Symbols, Sign in with Apple, aperçu au appui long sur les fiches. La palette chaude et la serif éditoriale du site sont conservées : c'est la marque, pas le chrome.
Android : refléter plutôt que réinterpréter
Une première version Android « à la Material » a été abandonnée au profit d'un portage fidèle des écrans iOS, validés en premier. Le code Android vit dans des fichiers .android.tsx (gluestack-ui), que Metro ne charge que pour Android : le bundle iOS n'en contient pas une ligne.
Accessibilité vérifiée, pas supposée
Le composant natif d'aperçu masquait les cartes de shops à VoiceOver : aucun établissement n'était atteignable. Quand un lecteur d'écran est actif, la carte devient un lien simple avec un libellé descriptif.
Des tests communs aux deux plateformes
Tests unitaires Jest sur les filtres, labels et calculs de distance ; parcours e2e Maestro identiques sur iOS et Android (lancement, annuaire, recherche, connexion). La CI GitHub Actions bloque chaque PR sur typecheck, lint et tests.
// Résultats
Objectifs à 6 mois, confrontés au réalisé
La traction reste faible et l'indicateur principal est à zéro. Ces chiffres sont présentés tels quels : ce sont eux qui ont orienté la suite du projet.
Shops publiés
objectif 150 · réalisé 26
Seeding manuel chronophage ; 62 % des fiches à Lyon
Utilisateurs inscrits
objectif 1 000 · réalisé 1
Aucune action d'acquisition menée
Avis déposés
objectif 300 · réalisé 0
Pas d'incitation ; trafic insuffisant
Visites / mois
objectif 10 000 · réalisé 36
Indexation lente ; pas de contenu SEO par ville
Revendications de fiche
objectif — · réalisé 1 réelle, validée
Parcours gérant validé de bout en bout, sans sollicitation
// Enseignements
Ce que ce projet m'a appris
Livrer n'est pas valider
Un MVP techniquement abouti, livré en deux semaines, ne génère pas d'usage sans démarche d'acquisition et de discovery. Le produit a été construit avant d'avoir été validé auprès de ses utilisateurs.
Simplifier est une décision produit
Retirer la note Tasse, le carnet de dégustation ou l'annuaire a rendu le produit plus lisible et plus facile à maintenir. Supprimer une fonctionnalité déjà codée coûte cher à court terme, mais réduit la charge cognitive de l'utilisateur.
Les contraintes réelles priment sur la roadmap
La question des droits sur les photos a justifié d'avancer la revendication de fiche de la v2 au MVP. Une contrainte juridique a réordonné le périmètre.
Les KPI doivent suivre les décisions
La North Star initiale — les avis qualifiés avec note Tasse — est devenue caduque dès que cette note a été supprimée. Un indicateur doit évoluer avec le produit.
Le volume de trafic détermine les méthodes
Détecter une hausse de 5 % en A/B test demanderait 4 400 visiteurs ; au rythme actuel, plus de dix ans. Sans trafic, les entretiens qualitatifs sont plus rapides et plus instructifs.
// Suite
Plan à 90 jours
La priorité n'est plus d'ajouter des fonctionnalités, mais de mesurer, interroger les utilisateurs et amorcer l'acquisition.
Mois 1
Plan de marquage analytics ; relevé Search Console et Lighthouse ; 6 entretiens amateurs et 4 entretiens gérants
Données de référence ; personas validés ou révisés
Mois 2
Optimisation SEO (contenus par ville, données structurées) ; +30 shops ; QR codes dans les shops Sélection
×5 visiteurs mensuels ; premiers avis
Mois 3
Relance d'avis ; test de Sean Ellis sur les utilisateurs actifs ; revue de la roadmap
Décision argumentée : poursuivre, pivoter ou réorienter