Ce chapitre te montre comment se déroule la construction d'une feature complète, minute par minute. L'exemple : un système de streak de publication pour motiver les utilisateurs à publier régulièrement sur un SaaS de génération de contenu. Temps de lecture : 10 minutes.

Le contexte

Tu construis un SaaS pour freelances qui les aide à publier sur LinkedIn. Problème constaté après 3 semaines de beta : 68% de tes utilisateurs créent 1 ou 2 contenus puis abandonnent. Tu veux les motiver à publier régulièrement avec un système de streak (série consécutive), sans que ce soit punitif.

Minute 0-5, brainstorm

Ce que tu tapes :

"Brainstorme un système de streak de publication. Les freelances publient 1-2 fois puis abandonnent. Je veux les motiver à publier régulièrement sans être punitif. Contexte : Next.js 16 + Supabase, déjà auth et dashboard en place."

Ce que Claude propose :

Option 1, streak quotidien (style Duolingo)

Simple mais punitif. Un jour raté = tout perdu. Inadapté aux freelances qui ne publient pas tous les jours.

Option 2, streak hebdomadaire (recommandé)

Plus flexible. "Publie au moins 1 contenu par semaine" → le streak augmente. 14 jours sans publication → le streak repart de zéro. Tolérant sur les jours, exigeant sur la régularité.

Option 3, points et niveaux

Gamification complète mais risque de distraire de l'objectif principal (créer du contenu de qualité).

Ce que tu réponds :

"Va pour le streak hebdomadaire. Bonne intuition sur la tolérance 14 jours."

Minute 5-15, planification

Ce que tu tapes :

"Écris le plan d'implémentation pour le streak hebdomadaire. Table Supabase, Server Action, composant dashboard, tests."

Ce que Claude produit :

Un plan en 6 tâches numérotées avec, pour chacune : le fichier à créer ou modifier, ce que la tâche fait concrètement, la commande de vérification.

Tâche 1 : Migration SQL supabase/migrations/20260420_create_streaks.sql — table streaks (user_id, current_streak, best_streak, last_publication_date, updated_at) + policy RLS + index

Tâche 2 : Régénérer les types TypeScript → src/types/database.types.ts

Tâche 3 : Server Action src/lib/actions/streak.ts — getStreak() et updateStreakAfterPublish()

Tâche 4 : Composant UI src/components/dashboard/publishing-streak.tsx — flamme animée Framer Motion + compteur

Tâche 5 : Intégration dans src/app/(app)/dashboard/page.tsx

Tâche 6 : Tests unitaires tests/unit/actions/streak.test.ts — 4 scénarios

Ce que tu vérifies :

L'ordre est logique ? Oui : BDD, types, logique, UI, intégration, tests
Il manque quelque chose ? Non, c'est complet
Le scope est raisonnable ? Oui, environ 30-40 minutes d'exécution

Ce que tu réponds :

"Le plan est bon. Exécute."

Minute 15-25, exécution (tâches 1-3)

Claude travaille en autonomie. Ce qui se passe dans le chat :

Tâche 1, migration SQL

Claude crée supabase/migrations/20260420_create_streaks.sql :

Table streaks avec les 5 colonnes
Policy RLS (sécurité : chaque utilisateur ne voit que son propre streak)
Index sur user_id pour la performance

Il lance npx supabase migration up --local → migration appliquée en 340ms.

Tâche 2, types TypeScript

Il régénère les types depuis la base de données avec npx supabase gen types typescript --local > src/types/database.types.ts. Le code TypeScript connaît désormais la table streaks et ses colonnes.

Il lance npm run typecheck → aucune erreur.

Tâche 3, Server Action

Il crée src/lib/actions/streak.ts avec la logique métier :

getStreak() : récupère le streak actuel
updateStreakAfterPublish() : appelé après chaque publication
Logique : si la dernière publication date de moins de 14 jours, streak++ ; sinon, streak = 1. Le best_streak est mis à jour si le courant le dépasse.

Il lance npm run typecheck && npm run lint → tout passe.

Minute 25-40, exécution (tâches 4-6)

Tâche 4, composant UI

Claude crée src/components/dashboard/publishing-streak.tsx :

Icône de flamme (lucide-react Flame) qui grossit avec le streak
Compteur "3 semaines consécutives"
Message d'encouragement personnalisé
Animation subtile d'entrée via Framer Motion

Il lance npm run typecheck, RAS.

Tâche 5, intégration dans le dashboard

Il modifie src/app/(app)/dashboard/page.tsx pour intégrer le composant streak en haut de la grille, à côté du widget "Contenus publiés ce mois".

Tâche 6, tests unitaires

Il crée tests/unit/actions/streak.test.ts avec :

Test du calcul normal (streak +1 quand dernière publi < 14 jours)
Test du streak cassé (reset à 1 après 14 jours)
Test du best streak (record personnel préservé)
Test du premier streak (nouvel utilisateur, pas de ligne existante)

Il lance npm run test streak → 4/4 tests passent en 180ms.

Minute 40-50, test visuel et itération

Tu ouvres localhost:3000/dashboard dans ton navigateur et tu vois le résultat.

Ce que tu observes :

Le compteur de streak s'affiche bien dans le dashboard, OK
La flamme est un peu petite à corriger
Le message d'encouragement est générique à améliorer

Ce que tu tapes :

"Le compteur est trop petit. J'aimerais une flamme plus grande (48px au lieu de 24px), et un message d'encouragement différent selon le nombre de semaines : 1 semaine = 'C'est parti !', 2-3 = 'Beau rythme !', 4+ = 'Inarrêtable !'"

Claude ajuste en 2 minutes. Tu rafraîchis le navigateur, parfait.

Minute 50-60, review et commit

Ce que tu tapes :

/review

Claude relit tout le code modifié et signale :

Pas de bug détecté
RLS correctement configuré (sécurité OK)
Types cohérents
Suggestion : ajouter un fallback si la table est vide (nouvel utilisateur qui n'a jamais publié)

Claude corrige la suggestion en ajoutant un ?? { current_streak: 0, best_streak: 0 } dans getStreak(). Puis :

/commit

Claude crée le commit : feat(dashboard): add weekly publishing streak with animated flame

Résumé du timing

Phase	Durée	Qui
Brainstorm	5 min	Claude propose 3 options, tu choisis
Planification	10 min	Claude écrit le plan, tu valides
Exécution	25 min	Claude code 6 tâches, tu observes
Test + itération	10 min	Tu testes, tu demandes des ajustements
Review + commit	10 min	Claude relit et sauvegarde
Total	60 min	Feature complète : BDD + logique + UI + tests

Feature complète en 1 heure. Base de données, logique métier, interface, tests unitaires, commit propre. Pas une seule ligne de code écrite par toi. Ta contribution : la vision produit, le choix de l'approche, et les ajustements visuels.

Le contexte

Minute 0-5, brainstorm

Ce que tu tapes :

"Brainstorme un système de streak de publication. Les freelances publient 1-2 fois puis abandonnent. Je veux les motiver à publier régulièrement sans être punitif. Contexte : Next.js 16 + Supabase, déjà auth et dashboard en place."

Ce que Claude propose :

Option 1, streak quotidien (style Duolingo)

Simple mais punitif. Un jour raté = tout perdu. Inadapté aux freelances qui ne publient pas tous les jours.

Option 2, streak hebdomadaire (recommandé)

Plus flexible. "Publie au moins 1 contenu par semaine" → le streak augmente. 14 jours sans publication → le streak repart de zéro. Tolérant sur les jours, exigeant sur la régularité.

Option 3, points et niveaux

Gamification complète mais risque de distraire de l'objectif principal (créer du contenu de qualité).

Ce que tu réponds :

"Va pour le streak hebdomadaire. Bonne intuition sur la tolérance 14 jours."

Minute 5-15, planification

Ce que tu tapes :

"Écris le plan d'implémentation pour le streak hebdomadaire. Table Supabase, Server Action, composant dashboard, tests."

Ce que Claude produit :

Un plan en 6 tâches numérotées avec, pour chacune : le fichier à créer ou modifier, ce que la tâche fait concrètement, la commande de vérification.

Tâche 1 : Migration SQL supabase/migrations/20260420_create_streaks.sql — table streaks (user_id, current_streak, best_streak, last_publication_date, updated_at) + policy RLS + index

Tâche 2 : Régénérer les types TypeScript → src/types/database.types.ts

Tâche 3 : Server Action src/lib/actions/streak.ts — getStreak() et updateStreakAfterPublish()

Tâche 4 : Composant UI src/components/dashboard/publishing-streak.tsx — flamme animée Framer Motion + compteur

Tâche 5 : Intégration dans src/app/(app)/dashboard/page.tsx

Tâche 6 : Tests unitaires tests/unit/actions/streak.test.ts — 4 scénarios

Ce que tu vérifies :

L'ordre est logique ? Oui : BDD, types, logique, UI, intégration, tests
Il manque quelque chose ? Non, c'est complet
Le scope est raisonnable ? Oui, environ 30-40 minutes d'exécution

Ce que tu réponds :

"Le plan est bon. Exécute."

Minute 15-25, exécution (tâches 1-3)

Claude travaille en autonomie. Ce qui se passe dans le chat :

Tâche 1, migration SQL

Claude crée supabase/migrations/20260420_create_streaks.sql :

Table streaks avec les 5 colonnes
Policy RLS (sécurité : chaque utilisateur ne voit que son propre streak)
Index sur user_id pour la performance

Il lance npx supabase migration up --local → migration appliquée en 340ms.

Tâche 2, types TypeScript

Il lance npm run typecheck → aucune erreur.

Tâche 3, Server Action

Il crée src/lib/actions/streak.ts avec la logique métier :

getStreak() : récupère le streak actuel
updateStreakAfterPublish() : appelé après chaque publication
Logique : si la dernière publication date de moins de 14 jours, streak++ ; sinon, streak = 1. Le best_streak est mis à jour si le courant le dépasse.

Il lance npm run typecheck && npm run lint → tout passe.

Minute 25-40, exécution (tâches 4-6)

Tâche 4, composant UI

Claude crée src/components/dashboard/publishing-streak.tsx :

Icône de flamme (lucide-react Flame) qui grossit avec le streak
Compteur "3 semaines consécutives"
Message d'encouragement personnalisé
Animation subtile d'entrée via Framer Motion

Il lance npm run typecheck, RAS.

Tâche 5, intégration dans le dashboard

Il modifie src/app/(app)/dashboard/page.tsx pour intégrer le composant streak en haut de la grille, à côté du widget "Contenus publiés ce mois".

Tâche 6, tests unitaires

Il crée tests/unit/actions/streak.test.ts avec :

Test du calcul normal (streak +1 quand dernière publi < 14 jours)
Test du streak cassé (reset à 1 après 14 jours)
Test du best streak (record personnel préservé)
Test du premier streak (nouvel utilisateur, pas de ligne existante)

Il lance npm run test streak → 4/4 tests passent en 180ms.

Minute 40-50, test visuel et itération

Tu ouvres localhost:3000/dashboard dans ton navigateur et tu vois le résultat.

Ce que tu observes :

Le compteur de streak s'affiche bien dans le dashboard, OK
La flamme est un peu petite à corriger
Le message d'encouragement est générique à améliorer

Ce que tu tapes :

"Le compteur est trop petit. J'aimerais une flamme plus grande (48px au lieu de 24px), et un message d'encouragement différent selon le nombre de semaines : 1 semaine = 'C'est parti !', 2-3 = 'Beau rythme !', 4+ = 'Inarrêtable !'"

Claude ajuste en 2 minutes. Tu rafraîchis le navigateur, parfait.

Minute 50-60, review et commit

Ce que tu tapes :

/review

Claude relit tout le code modifié et signale :

Pas de bug détecté
RLS correctement configuré (sécurité OK)
Types cohérents
Suggestion : ajouter un fallback si la table est vide (nouvel utilisateur qui n'a jamais publié)

Claude corrige la suggestion en ajoutant un ?? { current_streak: 0, best_streak: 0 } dans getStreak(). Puis :

/commit

Claude crée le commit : feat(dashboard): add weekly publishing streak with animated flame

Résumé du timing

Phase	Durée	Qui
Brainstorm	5 min	Claude propose 3 options, tu choisis
Planification	10 min	Claude écrit le plan, tu valides
Exécution	25 min	Claude code 6 tâches, tu observes
Test + itération	10 min	Tu testes, tu demandes des ajustements
Review + commit	10 min	Claude relit et sauvegarde
Total	60 min	Feature complète : BDD + logique + UI + tests

Cas pratique, une feature de A à Z

Le contexte

Minute 0-5, brainstorm

Minute 5-15, planification

Minute 15-25, exécution (tâches 1-3)

Minute 25-40, exécution (tâches 4-6)

Minute 40-50, test visuel et itération

Minute 50-60, review et commit

Résumé du timing

Cas pratique, une feature de A à Z

Le contexte

Minute 0-5, brainstorm

Minute 5-15, planification

Minute 15-25, exécution (tâches 1-3)

Minute 25-40, exécution (tâches 4-6)

Minute 40-50, test visuel et itération

Minute 50-60, review et commit

Résumé du timing