OpenClaw Knowledge Base

guide-formateur

21 min de lecture

GUIDE FORMATEUR — Vibe Coding Professionnel

Document confidentiel — Usage interne uniquement

AVANT DE FILMER

Setup technique

  • Écran propre (bureau vide, pas de notifications)
  • Micro vérifié (test audio 30 sec)
  • Résolution : 1920x1080 minimum
  • Navigateur : onglets préparés à l’avance
  • Terminal : propre, police lisible (taille 16+)
  • Supabase : projet DEV créé et configuré
  • Stripe : compte test activé, dashboard ouvert
  • GitHub : repo CourseCredits créé et vide

Ordre de tournage conseillé

Filme dans l’ordre des modules. Si tu bloques, saute et reviens. Chaque vidéo est indépendante.

MODULE 1 — Pourquoi structurer son projet

Vidéo 1 — Les risques du vibe coding non structuré (~15 min)

Introduction (2 min)

“Bienvenue dans cette formation. Avant d’écrire une seule ligne de code, je veux te montrer pourquoi la plupart des projets vibe coding partent dans le mur — et comment éviter ça.”

Point 1 : Le problème des clés API exposées (3 min)

  • Montre un exemple de .env committé sur GitHub (cherche sur GitHub : “stripe_secret_key filename:.env”)
  • “Ça arrive tout le temps. L’IA génère le code, elle met parfois la clé en dur dans le fichier. Tu commit sans regarder. En 2h, quelqu’un a scanné ton repo et charge des trucs sur ton compte Stripe.”
  • Conclure : “On va apprendre à ne jamais avoir ce problème.”

Point 2 : La dette technique qui explose (3 min)

  • “Avec l’IA, on peut générer 500 lignes en 10 minutes. Le problème : si tu n’as pas de structure, dans 3 semaines tu ne comprends plus ton propre code. Et l’IA non plus.”
  • Exemple : montrer un fichier de 800 lignes sans séparation
  • Conclure : “On va organiser ça proprement.”

Point 3 : Tester en production (4 min)

  • “Le classique : le dev teste directement sur l’app en prod. Un bug → vrai client touché. Vrai argent perdu.”
  • “Stripe a une solution magique pour ça. On en parle dans la prochaine vidéo.”
  • Anecdote personnelle si possible

Conclusion (2 min)

“Ces trois problèmes se règlent avec deux choses : une bonne structure de projet, et des environnements séparés. C’est ce qu’on construit ensemble dans cette formation.”

Vidéo 2 — La logique DEV / PRODUCTION (~15 min)

Introduction (1 min)

“Je vais t’expliquer le concept qui change tout : séparer ton environnement de développement de ton environnement de production.”

Explication du concept (4 min)

  • Schéma simple à dessiner en live ou montrer une slide :
    • LOCAL (ton ordi) → DEV/Staging (serveur test) → PRODUCTION (vrai serveur)
  • “Dans cette formation on va travailler avec deux niveaux : LOCAL et PRODUCTION.”
  • “Chaque API qu’on utilise a deux modes : test et live. On commencera toujours en test.”

La carte Stripe (3 min)

  • Ouvrir le dashboard Stripe en mode TEST
  • “Cette carte ne débite personne : 4242 4242 4242 4242, date future, CVC 123”
  • Faire une fausse transaction en direct
  • “En production, tu changes une variable. C’est tout. Le code reste identique.”

Supabase DEV vs PROD (4 min)

  • Montrer deux projets Supabase : un nommé “CourseCredits-DEV”, un “CourseCredits-PROD”
  • “Même structure, données séparées. Tu peux tout casser en DEV, la prod est intacte.”
  • “Et ça, ça se gère avec des fichiers .env.”

Conclusion (2 min)

“Tu vois la logique. Maintenant on va mettre tout ça en place concrètement. Module suivant : on structure le projet.”

MODULE 2 — Structurer son projet

Vidéo 1 — Architecture de fichiers et Git (~15 min)

Introduction (1 min)

“Un projet bien structuré, c’est un projet que tu comprends encore dans 6 mois. Et que l’IA comprend aussi.”

Structure de dossiers (5 min)

Montre en live la création de la structure :

coursecredits/
  src/
    app/           # pages Next.js
    components/    # composants réutilisables
    lib/           # utilitaires, clients Supabase/Stripe
    types/         # types TypeScript
  .env.local       # variables DEV (jamais committé)
  .env.example     # template des variables (committé)
  .gitignore       # inclut .env.local
  CLAUDE.md        # contexte pour l'IA
  README.md

“Chaque dossier a un rôle. L’IA va s’y retrouver.”

Git et branches (5 min)

  • git init, premier commit
  • “Je travaille toujours avec deux branches minimum : main (production) et develop (dev en cours)”
  • git checkout -b develop
  • Convention de commits : feat:, fix:, chore:, docs:
  • “Petit conseil : commite souvent. L’IA fait parfois des conneries. Pouvoir revenir en arrière, c’est vital.”

.gitignore (3 min)

  • Montrer le .gitignore avec .env.local, node_modules, .DS_Store
  • “Si tu commits ton .env.local un jour, tu changes toutes tes clés immédiatement. Stripe, Supabase, tout.”

Vidéo 2 — Workflow Git professionnel : features, merge et production (~20 min)

Introduction (2 min)

“On a notre structure de base. Maintenant je vais te montrer comment les vrais développeurs travaillent : avec des branches. C’est ce qui sépare un projet hobby d’un projet sérieux.”

Schéma à dessiner ou montrer :

main (PROD)
  └── develop (intégration)
        ├── feature/auth
        └── feature/stripe

“Chaque nouvelle fonctionnalité a sa propre branche. On ne touche jamais main directement.”

Étape 1 — Créer les branches feature (4 min)

Situation de départ :

git branch
# * develop
#   main

“On a deux features à développer en même temps : l’authentification et l’intégration Stripe. On crée une branche pour chacune.”

# Créer la branche feature/auth depuis develop
git checkout develop
git checkout -b feature/auth
 
# Travailler sur l'auth... (montre 2-3 fichiers modifiés)
# Exemple : src/app/login/page.tsx, src/lib/supabase-auth.ts
git add src/app/login/
git add src/lib/supabase-auth.ts
git commit -m "feat: add Supabase auth pages (login/register)"
 
# Retour sur develop, créer la branche Stripe
git checkout develop
git checkout -b feature/stripe
 
# Travailler sur Stripe... (montre 2-3 fichiers modifiés)
# Exemple : src/app/api/checkout/route.ts, src/lib/stripe.ts
git add src/app/api/checkout/
git add src/lib/stripe.ts
git commit -m "feat: add Stripe checkout endpoint"

“Deux features en cours. Chacune dans sa bulle. Elles ne se perturbent pas.”

Étape 2 — Voir les différences entre branches (4 min)

“Comment visualiser ce que contient chaque branche ? Deux façons.”

Voir les commits de chaque branche :

# Commits dans feature/auth que develop n'a pas
git log develop..feature/auth --oneline
 
# Commits dans feature/stripe que develop n'a pas
git log develop..feature/stripe --oneline

Voir les fichiers modifiés :

# Quels fichiers sont différents entre feature/auth et develop ?
git diff develop..feature/auth --name-only
 
# Le contenu complet des différences
git diff develop..feature/auth

Dans VS Code (montre en live) :

  • Extension GitLens → voir les branches dans le panneau latéral
  • Source Control → changer de branche → voir les fichiers en attente
  • “Pour les visuels, VS Code c’est imbattable.”
# Ou directement dans le terminal : liste toutes les branches
git branch -a

Étape 3 — Merger feature/auth dans develop (3 min)

“La feature auth est terminée et testée en local. On l’intègre dans develop.”

git checkout develop
git merge feature/auth

Si conflit : (montre un exemple)

CONFLICT (content): Merge conflict in src/lib/supabase.ts
Automatic merge failed; fix conflicts and then commit the result.

# Ouvrir le fichier — VS Code montre les conflits visuellement
# Choisir les bonnes lignes, sauvegarder
git add src/lib/supabase.ts
git commit -m "merge: integrate feature/auth into develop"

“Pas de panique devant un conflit. C’est Git qui te dit ‘deux branches ont modifié le même endroit, choisis ce qu’on garde’. VS Code le visualise parfaitement.”

Tester en local avec la branche develop :

npm run dev
# → tester la page login, l'inscription, le profil

“On valide que l’auth marche. Avant de toucher à autre chose.”

Étape 4 — Merger feature/stripe dans develop (2 min)

“Stripe est prête aussi. On merge.”

git checkout develop
git merge feature/stripe
git commit -m "merge: integrate feature/stripe into develop"

Test combiné :

npm run dev
# → tester l'auth + le checkout Stripe
# → inscription → connexion → achat crédits avec 4242 4242 4242 4242

“Les deux features cohabitent. On teste tout le flux d’un coup. C’est ça, develop : l’intégration de tout ce qui est prêt.”

Nettoyer les branches terminées (bonne pratique) :

git branch -d feature/auth
git branch -d feature/stripe
# "feature/* terminent leur vie après le merge. Develop reste propre."

Étape 5 — Push develop, puis merge en production (3 min)

“On a validé develop en local. On pousse, puis on passe en production.”

# Pousser develop sur GitHub
git push origin develop
 
# Passer sur main (= production)
git checkout main
git merge develop
git push origin main

“GitHub Actions (ou Vercel) détecte le push sur main et déclenche automatiquement le déploiement en production.”

Résultat :

  • feature/auth et feature/stripe : archivées
  • develop : à jour, prête pour les prochaines features
  • main : production déployée automatiquement

Conclusion (1 min)

“Ce workflow s’appelle Gitflow simplifié. Tu peux développer 10 features en parallèle sans jamais casser la prod. Et si une feature est problématique, tu ne la merges pas — elle attend dans sa branche.”

“Dans la vidéo suivante, on configure l’IA pour qu’elle comprenne cette structure dès le départ.”

Vidéo 3 — Modéliser sa base de données avant de coder (~18 min)

Introduction (2 min)

“Avant d’écrire une seule ligne de code, je vais te montrer une étape que la plupart des débutants sautent : modéliser la base de données. Sans ça, tu te retrouves à refaire tes tables 3 fois en cours de route — et à tout casser au passage.”

“L’outil qu’on va utiliser s’appelle un diagramme ERD — Entity-Relationship Diagram. C’est la carte de ton application avant de la construire.”

Étape 1 — Identifier les entités (3 min)

“La première question à poser : qu’est-ce que mon application manipule comme objets ?”

Pour CourseCredits, liste au tableau ou dans l’outil :

Entités :
- users       → les comptes utilisateurs
- formations  → les cours disponibles
- credits     → le solde de chaque user
- achats      → l'historique des transactions

“Chaque entité devient une table dans Supabase. C’est aussi simple que ça.”

Étape 2 — Définir les attributs et types (4 min)

Ouvre dbdiagram.io (ou Supabase Studio → Table Editor) et crée les tables en live :

-- Table users (gérée par Supabase Auth, on ajoute une table profiles)
Table profiles {
  id         uuid [pk, ref: > auth.users.id]
  email      text [not null]
  role       text [default: 'user']  -- 'user' ou 'admin'
  created_at timestamptz [default: now()]
}
 
-- Table formations
Table formations {
  id          uuid [pk, default: gen_random_uuid()]
  titre       text [not null]
  description text
  prix_credits int [not null]          -- en crédits, pas en euros
  categorie   text
  publiee     boolean [default: false]
  created_at  timestamptz [default: now()]
}
 
-- Table credits (solde par user)
Table credits {
  id          uuid [pk, default: gen_random_uuid()]
  user_id     uuid [ref: > profiles.id, not null]
  solde       int [default: 0]
  updated_at  timestamptz [default: now()]
}
 
-- Table achats (historique)
Table achats {
  id              uuid [pk, default: gen_random_uuid()]
  user_id         uuid [ref: > profiles.id, not null]
  formation_id    uuid [ref: > formations.id, not null]
  credits_depenses int [not null]
  created_at      timestamptz [default: now()]
}

“Deux conventions importantes : snake_case pour tous les noms de colonnes, et uuid pour les IDs — jamais des entiers auto-incrémentés en production.”

Étape 3 — Dessiner les relations (3 min)

Dans dbdiagram.io, montre le diagramme généré :

profiles ──── credits       (1:1 — chaque user a un solde)
profiles ──<  achats        (1:N — un user peut avoir plusieurs achats)
formations ──< achats       (1:N — une formation peut être achetée plusieurs fois)

“Ces flèches représentent les clés étrangères. Supabase va enforcer l’intégrité : impossible d’insérer un achat pour un user qui n’existe pas.”

“Avant d’écrire du code, je peux déjà répondre à toutes les questions :

  • Combien de crédits a ce user ? → table credits, filtre user_id
  • Quelles formations a-t-il achetées ? → table achats, jointure formations
  • Quelles formations sont disponibles ? → table formations où publiee = true”

Étape 4 — Anticiper les règles RLS (3 min)

“Row Level Security : qui a le droit de lire ou modifier quoi ? Le bon moment pour y penser, c’est maintenant — pas après avoir codé 10 endpoints.”

Écris les règles en commentaire à côté de chaque table :

profiles  → lecture : soi-même uniquement / écriture : soi-même
formations → lecture : tout le monde (publiée = true) / écriture : admin uniquement
credits   → lecture : soi-même / écriture : serveur uniquement (via service key)
achats    → lecture : soi-même / écriture : serveur uniquement

“La colonne role dans profiles suffit pour distinguer admin et user. Pas besoin d’une table de permissions séparée pour commencer.”

Étape 5 — Exporter et implémenter dans Supabase (2 min)

Deux options :

Option A — via l’IA (recommandé) :

Voici le schéma de ma base de données pour CourseCredits :
[colle le SQL]
Génère les migrations Supabase avec les politiques RLS appropriées.

Option B — Supabase Table Editor :

  • Créer les tables visuellement dans le dashboard
  • Activer RLS sur chaque table
  • Ajouter les politiques via l’interface

“Une fois ce schéma validé, l’IA peut générer tout le code de l’app en cohérence — elle sait exactement ce que la base contient.”

Conclusion (1 min)

“Ce diagramme, c’est 30 minutes de travail maintenant qui t’économisent 5 heures de refactoring plus tard. Et avec l’IA, tu peux lui soumettre ce schéma en contexte — elle ne fera plus jamais une requête sur une colonne qui n’existe pas.”

“Prochaine vidéo : on configure l’IA pour qu’elle ait ce schéma en tête dès le départ.”

Vidéo 4 — Configurer ses outils IA (~12 min)

Introduction (1 min)

“L’IA est ton copilote. Mais un copilote qui ne connaît pas ton projet, ça donne des directions au hasard.”

Rédiger le CLAUDE.md (6 min)

Crée le fichier en live. Contenu minimal :

# CourseCredits
 
## Projet
Mini marketplace de formations avec système de crédits.
 
## Stack
- Next.js 14 (App Router)
- Supabase (auth, db, RLS)
- Stripe (paiements web)
- TypeScript strict
 
## Règles
- Variables d'env : toujours via process.env, jamais en dur
- Pas de console.log en production
- RLS activé sur toutes les tables
- Commits atomiques et descriptifs

“Ce fichier, Claude Code le lit à chaque session. Il connaît ton projet.”

Les règles à poser (4 min)

  • “Dis à l’IA ce qu’elle ne doit PAS faire : pas de clés en dur, pas de bypass de sécurité”
  • “Donne le contexte : stack, conventions, objectifs”
  • “Plus tu es précis, moins tu corriges.”

Vidéo 5 — Variables d’environnement DEV vs PROD (~12 min)

Introduction (1 min)

“Une variable d’environnement, c’est une information secrète que ton app lit au démarrage. Selon où tu déploies, elle change.”

Créer les fichiers .env (5 min)

# .env.local (DEV - jamais committé)
NEXT_PUBLIC_SUPABASE_URL=https://xxx.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=eyJ...
SUPABASE_SERVICE_KEY=eyJ...
STRIPE_SECRET_KEY=sk_test_...
NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY=pk_test_...
STRIPE_WEBHOOK_SECRET=whsec_test_...
 
# .env.example (committé - valeurs vides)
NEXT_PUBLIC_SUPABASE_URL=
NEXT_PUBLIC_SUPABASE_ANON_KEY=
SUPABASE_SERVICE_KEY=
STRIPE_SECRET_KEY=
NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY=
STRIPE_WEBHOOK_SECRET=

“Le .env.example sert de documentation. N’importe qui qui clone ton repo sait quelles variables configurer.”

NEXT_PUBLIC vs variables serveur (3 min)

  • “NEXT_PUBLIC_ = visible dans le navigateur. Utilise pour les clés publiques Stripe/Supabase uniquement.”
  • “Sans préfixe = uniquement côté serveur. Pour les clés secrètes.”

Deux projets Supabase : DEV et PROD (2 min)

  • “Supabase propose 2 projets gratuits. On en crée deux : ‘coursecredits-dev’ et ‘coursecredits-prod’.”
  • “Même structure de tables, données séparées. Tu peux tout casser en DEV, la prod est intacte.”
  • “Les clés changent entre les deux projets, c’est tout.”

💡 Aparté : Supabase Pro et les branches (2 min)

  • “Si tu travailles en équipe ou sur plusieurs features en parallèle, Supabase Pro propose un système de branches — comme Git, mais pour ta base de données.”
  • “Chaque feature branch a sa propre base temporaire. Elle se merge automatiquement quand tu fusionnes ta branche Git.”
  • “C’est ~25$/mois. Pour un projet solo, les 2 projets gratuits suffisent largement.”
  • (Insérer lien d’affiliation Supabase ici si disponible — vérifier sur supabase.com/partners)

En production (1 min)

  • “Tu mets les mêmes variables dans Vercel → Settings → Environment Variables, mais avec les clés du projet PROD.”
  • “C’est le seul changement. Le code ne bouge pas.”

MODULE 3 — Mise en situation

Vidéo 1 — Setup du projet CourseCredits (~20 min)

Introduction (2 min)

“On attaque le concret. Dans les 4 prochaines vidéos, on construit ensemble CourseCredits de A à Z.”

Créer le projet Next.js (5 min)

npx create-next-app@latest coursecredits --typescript --tailwind --app
cd coursecredits

Ouvrir dans le IDE, montrer la structure générée.

Setup Supabase DEV (8 min)

  • Créer projet sur supabase.com → “CourseCredits-DEV”
  • Récupérer les clés → coller dans .env.local
  • Créer les tables avec l’IA : 
    -- Table users_credits
-- Table formations
-- Table achats
  • Activer RLS sur chaque table
  • “Je laisse l’IA générer le SQL, mais je lis chaque ligne avant d’exécuter.”

Push GitHub (3 min)

  • Créer repo sur GitHub
  • git add . → vérifier que .env.local n’est pas inclus
  • git commit -m "feat: initial setup"
  • git push

Vidéo 2 — Développement pages et auth (~20 min)

Stratégie de développement (3 min)

“On développe page par page, en testant à chaque étape. L’IA génère, je valide, je commit.”

Page d’accueil — catalogue (8 min)

  • Demander à l’IA de générer la page avec filtres
  • Montrer le prompt utilisé (important pour les élèves)
  • Ajuster le résultat
  • Brancher les données Supabase (formations fictives en DEV)

Auth Supabase (6 min)

  • Page inscription / connexion
  • “Je n’écris pas l’auth moi-même. Supabase + l’IA gèrent ça en 5 min.”
  • Tester : créer un compte, se connecter

Page compte (3 min)

  • Afficher le solde de crédits
  • Lien vers l’achat de crédits

Vidéo 3 — Intégration Stripe + RevenueCat (~20 min)

Stripe Checkout (8 min)

  • Créer un produit dans Stripe TEST (pack de crédits, ex: 10 crédits = 9,99€)
  • Générer le lien Checkout avec l’IA
  • Tester avec 4242 4242 4242 4242
  • Webhook Stripe → ajouter crédits en DB Supabase
  • “Le webhook, c’est Stripe qui appelle ton app pour dire ‘le paiement est passé’. Sans ça, les crédits ne sont jamais ajoutés.”

Tester le webhook en local (5 min)

  • Stripe CLI : stripe listen --forward-to localhost:3000/api/webhooks/stripe
  • Déclencher un événement test
  • Vérifier en DB que les crédits sont ajoutés

RevenueCat (mobile, introduction) (5 min)

  • “Pour le mobile, on n’utilise pas Stripe directement. Apple et Google imposent leur système de paiement.”
  • “RevenueCat est la couche d’abstraction qui gère iOS et Android avec la même API.”
  • Montrer le dashboard RevenueCat sandbox
  • “La logique est identique : sandbox = test, production = live. On switch les clés.”

Vidéo 4 — Admin et validation (~15 min)

Page admin (7 min)

  • Route protégée : /admin accessible seulement si role = admin en DB
  • CRUD formations : ajouter, modifier, supprimer
  • “RLS Supabase : une politique qui dit ‘seul l’admin peut écrire dans la table formations’”
  • Générer avec l’IA, vérifier les politiques RLS

Tests manuels avant déploiement (5 min)

Checklist à faire en live :

  • Inscription → connexion → profil affiché
  • Achat de crédits (carte test) → crédits visibles
  • Débloquer une formation → accessible
  • Admin : ajouter une formation → visible en accueil
  • Utilisateur normal ne peut pas accéder à /admin

Commit final DEV (2 min)

  • “On a une app qui tourne en local. Prochaine étape : production.”

MODULE 4 — Mise en production

Vidéo 1 — Déploiement web : Git → Netlify (~20 min)

Introduction (2 min)

“On passe de localhost à une vraie URL accessible par tout le monde. Et on va faire ça proprement : chaque push sur main déclenche automatiquement le déploiement. Plus de FTP, plus d’upload manuel — Git devient ton pipeline de déploiement.”

“On va utiliser Netlify, qui s’intègre directement avec GitHub en quelques clics.”

Étape 1 — Connecter le repo GitHub à Netlify (5 min)

  • Aller sur netlify.com → “Add new site” → “Import from Git”
  • Sélectionner GitHub, autoriser l’accès
  • Choisir le repo coursecredits

Configurer le build :

Branch to deploy : main
Build command    : npm run build
Publish directory: .next

“Netlify lit ces paramètres et sait comment construire l’app. Pour Next.js, il détecte souvent la config automatiquement.”

  • Cliquer “Deploy site”
  • Regarder les logs de build en direct : npm install → npm run build → déploiement
  • L’app tourne sur une URL générée automatiquement : https://coursecredits-abc123.netlify.app

Étape 2 — Variables d’environnement sur Netlify (4 min)

“L’app tourne, mais elle ne peut pas se connecter à Supabase ou Stripe — les clés sont dans ton .env.local qui n’est PAS committé. Normal. On les met dans Netlify.”

  • Site settings → Environment variables → “Add variable”
  • Ajouter toutes les variables du .env.local (DEV pour l’instant) : 
    NEXT_PUBLIC_SUPABASE_URL
NEXT_PUBLIC_SUPABASE_ANON_KEY
SUPABASE_SERVICE_KEY
STRIPE_SECRET_KEY
NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY
STRIPE_WEBHOOK_SECRET
  • Deploys → Trigger deploy pour relancer avec les nouvelles variables
  • Tester sur l’URL Netlify : connexion Supabase OK, Stripe OK

Étape 3 — Le déploiement automatique en action (4 min)

“Voilà ce qui rend Netlify puissant : tu n’as plus besoin de revenir ici pour déployer.”

Fais une modif mineure en live (ex: changer un texte sur la page d’accueil) :

git add src/app/page.tsx
git commit -m "feat: update homepage copy"
git push origin main
  • Ouvrir Netlify → onglet Deploys → le build démarre automatiquement en quelques secondes
  • “Tu pushes, Netlify build, Netlify déploie. C’est ça, le CI/CD.”

Bonus — Preview deploys sur develop :

  • Netlify génère une URL de preview pour chaque push sur n’importe quelle branche
  • “Pousse sur develop → tu as une URL de preview unique pour tester avant de merger sur main. C’est parfait pour montrer un truc à un client avant de le mettre en prod.”
git push origin develop
# → https://deploy-preview-7--coursecredits.netlify.app

Étape 4 — Domaine personnalisé (3 min)

  • Netlify → Domain management → “Add custom domain”
  • Entrer ton domaine (acheté sur OVH, Namecheap, etc.)
  • Copier les DNS Netlify dans la zone DNS de ton registrar
  • Netlify génère le certificat SSL automatiquement (Let’s Encrypt — gratuit)
  • “En 10-15 min, ton app est sur https://coursecredits.com avec HTTPS.”

Étape 5 — Lire les logs en cas d’erreur (2 min)

“Les erreurs de build sont différentes des erreurs locales.”

  • Netlify → Deploys → cliquer sur un build → “Deploy log”
  • Les erreurs courantes :
    • Variable d’env manquante → undefined dans les logs
    • Erreur TypeScript qui passe en local mais pas en build strict
    • Dépendance manquante dans package.json
  • “Lis toujours le log du bas vers le haut — l’erreur réelle est souvent cachée sous les warnings.”

Vidéo 2 — Switch TEST → PRODUCTION (~15 min)

Introduction (1 min)

“C’est LE moment critique. On passe du bac à sable au vrai.”

Créer le projet Supabase PROD (4 min)

  • Nouveau projet Supabase : “CourseCredits-PROD”
  • Rejouer les migrations SQL (idéalement via supabase db push)
  • “Les données de DEV ne vont PAS en prod. On repart de zéro.”

Activer Stripe live (4 min)

  • Compléter le profil Stripe (infos bancaires, IBAN)
  • Récupérer les clés LIVE (sk_live_…, pk_live_…)
  • Créer le webhook LIVE (URL de production)
  • Récupérer le webhook secret LIVE

Mettre à jour les variables Netlify (3 min)

  • Netlify → Site settings → Environment variables
  • Remplacer toutes les variables TEST par les variables LIVE (Supabase PROD + Stripe LIVE)
  • Deploys → Trigger deploy pour relancer
  • Faire un vrai paiement test (1€) pour valider

Checklist finale (2 min)

  • Paiement réel passé → crédits ajoutés
  • Email de confirmation reçu
  • Contenu accessible après achat
  • Admin fonctionne en prod

Vidéo 3 ⭐ BONUS — App Store & Google Play (~20 min)

Introduction (2 min)

“Si tu as une app Flutter, voilà comment la publier sur les deux stores. C’est moins compliqué qu’on croit, juste administratif.”

Prérequis iOS (5 min)

  • Compte Apple Developer : 99$/an (obligatoire)
  • Xcode installé sur macOS
  • Identifiant d’app créé sur App Store Connect
  • Certificat de distribution configuré
  • “Sans Mac, impossible de publier sur l’App Store. C’est la contrainte Apple.”

Build et soumission iOS (6 min)

flutter build ipa --release
  • Ouvrir dans Xcode, vérifier les infos
  • Archiver → Distribute App → App Store Connect
  • App Store Connect : remplir les métadonnées, captures d’écran, description
  • Soumettre pour review (3-7 jours en moyenne)

Publication Android (5 min)

flutter build appbundle --release
  • Google Play Console : créer l’app
  • Uploader le .aab
  • Remplir les métadonnées
  • Soumettre (review plus rapide : 1-3 jours)

RevenueCat en production (2 min)

  • Remplacer les clés RevenueCat sandbox par les clés production
  • “Même logique que Stripe. Une variable. C’est tout.”

CONSEILS DE TOURNAGE

Rythme

  • Parle normalement, pas trop vite
  • Les pauses sont bien : elles laissent le temps de noter
  • Si tu fais une erreur en live → ne coupe pas. Montre comment tu la corriges. C’est pédagogique.

Transitions entre vidéos

  • Fin de chaque vidéo : “Dans la prochaine vidéo, on va [sujet].”
  • Début de chaque vidéo : “Dans la vidéo précédente, on a [rappel rapide]. Maintenant on fait [sujet].”

Les erreurs

  • Si une commande plante en live : “Voilà, ça arrive. On regarde le message d’erreur ensemble.”
  • Montre comment tu googles / demandes à l’IA
  • C’est souvent la partie la plus utile pour les élèves

Durée cible par vidéo

  • Module 1 : 12-15 min
  • Module 2 : 12-15 min
  • Module 3 : 18-22 min
  • Module 4 : 15-20 min

Total estimé : ~3h de contenu

STACK TECHNIQUE COMPLÈTE

ServiceUsageEnvironnements
SupabaseAuth + DB + RLSDEV project / PROD project
StripePaiements websk_test_ / sk_live_
RevenueCatPaiements mobileSandbox / Production
Next.jsFrontend web.env.local / Vercel env vars
FlutterMobile iOS + AndroidDebug / Release
VercelHébergement webPreview / Production
GitHub ActionsCI/CDAutomatique sur push main
Claude CodeAssistant IA—

Document confidentiel — Yohann Boulade — Formation Vibe Coding Professionnel

Voir aussi

Vue Graphique

Liens retour