docs: add audit_production.md + plan_implementation_prod.md; fix admin phone field

apps/admin/src/App.tsx

@@ -161,7 +161,7 @@ function Dashboard() {
         const headers = ['ID', 'User Phone', 'Track Title', 'Status', 'Current Day', 'Started At'];
         const rows = data.enrollments.map(env => [
             env.id,
-            env.user?.whatsappId || 'Unknown',
+            env.user?.phone || 'Unknown',
             env.track?.title || 'Unknown',
             env.status,
             env.currentDay,
@@ -234,7 +234,7 @@ function Dashboard() {
                         <tbody>
                             {data.enrollments.map((env: any) => (
                                 <tr key={env.id} className="border-b border-slate-50 hover:bg-slate-50/50">
-                                    <td className="px-6 py-4 font-medium text-slate-900">{env.user?.whatsappId || 'Unknown'}</td>
+                                    <td className="px-6 py-4 font-medium text-slate-900">{env.user?.phone || 'Unknown'}</td>
                                     <td className="px-6 py-4">{env.track?.title || 'Unknown Track'}</td>
                                     <td className="px-6 py-4">
                                         <span className={`px-2.5 py-1 py-0.5 rounded-full text-xs font-medium

docs/Xamle_System_Spec_Deployment_Sheet.md

@@ -0,0 +1,237 @@
+# XAMLÉ – System Spec & Deployment Sheet (HF + Railway Worker)
+
+Ce document centralise toutes les informations techniques, de configuration et d'architecture de l'infrastructure XAMLÉ (SafeTrack EdTech). Il sert de référence absolue (Single Source of Truth) pour déployer et maintenir le backend scindé entre Hugging Face (API) et Railway (Worker).
+
+---
+
+## 1. Résumé Architecture (Actuelle / Cible)
+
+Le système est construit sur un monorepo Turborepo (pnpm) composé de multiples applications qui se parlent via une base de données et un cache central.
+
+*   **Hugging Face Space (Public Inbound Endpoint) :** 
+    *   Héberge l'application `apps/api`.
+    *   Rôle : Point d'entrée public pour le Webhook Meta (WhatsApp Inbound), les requêtes Stripe, et le back-office Admin.
+    *   C'est ici que l'IA (OpenAI) génère le contenu et que l'utilisateur est enregistré en base. Aucune requête sortante vers Meta n'est émise d'ici à cause des restrictions DNS (ENOTFOUND).
+*   **Railway (Outbound Background Worker) :**
+    *   Héberge **uniquement** l'application `apps/whatsapp-worker`.
+    *   Rôle : Consommer les jobs BullMQ enregistrés dans Redis par Hugging Face, et envoyer physiquement les messages sortants vers l'API WhatsApp Cloud (graph.facebook.com). Contient le Cron (Scheduler) quotidien.
+*   **Neon Postgres :** 
+    *   Rôle : Base de données relationnelle centrale (Prisma) partagée entre HF et Railway (Tables `User`, `Track`, `Enrollment`, `TrackDay`).
+*   **Upstash Redis :** 
+    *   Rôle : Gestion de la file d'attente asynchrone BullMQ (queue `whatsappQueue`). Il agit comme le pont de communication en temps réel entre Hugging Face et Railway.
+*   **Cloudflare R2 :**
+    *   Rôle : Stockage S3 public pour héberger les fichiers générés par l'IA (PDF, Audio, PPTX) afin que Meta puisse les télécharger via des URLs publiques et les envoyer aux utilisateurs WhatsApp.
+*   **OpenAI :**
+    *   Rôle : LLM utilisé dans `apps/api` (sur Hugging Face) pour personnaliser les leçons et générer l'audio (Whisper STT / TTS).
+
+---
+
+## 2. URLs & Endpoints
+
+**URL de base Hugging Face :** `https://safetrack-edtech.hf.space`
+
+### Webhook WhatsApp (Configuration Meta App Dashboard)
+*   **GET Verify (Public) :** `GET https://safetrack-edtech.hf.space/v1/whatsapp/webhook`
+    *   Utilisé par Meta une seule fois lors de la configuration avec `<WHATSAPP_VERIFY_TOKEN>`.
+*   **POST Webhook (Public mais Sécurisé HMAC) :** `POST https://safetrack-edtech.hf.space/v1/whatsapp/webhook`
+    *   L'endpoint où Meta poste les messages des utilisateurs.
+    *   Sécurisé via validation de signature `X-Hub-Signature-256` en utilisant `<WHATSAPP_APP_SECRET>`.
+
+### Utilitaires & Healthchecks (Publics)
+*   `GET /` : Healthcheck basique (`{"ok": true}`).
+*   `GET /health` : Monitoring avec timestamp.
+*   `GET /privacy` : Politique de confidentialité servie en HTML (requise par Meta App Review).
+*   `GET /debug/net` : Teste la connectivité Google (diagnostique Egress).
+*   `GET /debug/graph` : Teste explicitement si la résolution DNS `graph.facebook.com` fonctionne (Diagnostic HF DNS Block).
+
+### Routes Privées (Protégées par `X-API-Key`)
+Les routes suivantes exigent le header `Authorization: Bearer <ADMIN_API_KEY>` :
+*   `/v1/admin/*` : Endpoints pour le frontend Admin (Stats, Enrollments).
+*   `/v1/ai/*` : Génération à la demande de PDF/Audio.
+*   `/v1/payments/*` : Création de sessions Stripe.
+
+---
+
+## 3. Variables & Secrets (Environment)
+
+| Name | Env | Type | Example / Placeholder | Used by | Notes |
+| :--- | :--- | :--- | :--- | :--- | :--- |
+| `WHATSAPP_VERIFY_TOKEN` | HF | Secret | `my_secure_verify_token_123` | `apps/api` | Vérifie le webhook initial de Meta. |
+| `WHATSAPP_APP_SECRET` | HF | Secret | `c2a5...` (32 chars) | `apps/api` | Clé secrète de l'App Meta pour signer (`crypto.createHmac`) les payloads. |
+| `WHATSAPP_ACCESS_TOKEN` | **Railway** & HF | Secret | `EAA...` | `whatsapp-worker` & `api` | Le jeton d'accès permanent System User. Worker (envoi message) / API (téléchargement audio STT). |
+| `WHATSAPP_PHONE_NUMBER_ID` | **Railway** | Public | `5249583...` | `whatsapp-worker` | L'ID Meta du numéro expéditeur. |
+| `DATABASE_URL` | Both | Secret | `postgresql://user:pass@ep-neon.tech/db?sslmode=require` | `api` & `worker` | DSN Neon (Pooler ou direct). |
+| `REDIS_URL` | Both | Secret | `rediss://default:pass@upstash.io:6379` | `api` & `worker` | **Important:** Si Upstash TLS, utiliser `rediss://` (avec 2 's') et non `redis://`. |
+| `ADMIN_API_KEY` | HF | Secret | `sk_admin_12345` | `apps/api` | Sécurise le dashboard et les routes privées. |
+| `OPENAI_API_KEY` | HF | Secret | `sk-proj...` | `apps/api` | Provider IA. |
+| `R2_ACCOUNT_ID` | HF | Public | `a1b2c3d4...` | `apps/api` | Cloudflare Storage. |
+| `R2_BUCKET` | HF | Public | `xamle-edtech-assets` | `apps/api` | Nom du seau Cloudflare. |
+| `R2_PUBLIC_URL` | Both | Public | `https://assets.xamle.com` | `api` & `worker` | URL de diffusion pour que l'App Meta puisse télécharger l'asset. |
+| `R2_ACCESS_KEY_ID` | HF | Secret | `...` | `apps/api` | AWS S3 Compat layer credential. |
+| `R2_SECRET_ACCESS_KEY` | HF | Secret | `...` | `apps/api` | AWS S3 Compat layer credential. |
+| `STRIPE_SECRET_KEY` | HF | Secret | `sk_test_...` | `apps/api` | Paiements et abonnements Premium. |
+| `STRIPE_WEBHOOK_SECRET` | HF | Secret | `whsec_...` | `apps/api` | Signature Webhook Stripe. |
+
+---
+
+## 4. BullMQ / Worker Logic
+
+La file d'attente garantit la résilience.
+*   **Nom de la Queue :** `whatsappQueue`
+*   **Producer (Hugging Face) :** 
+    Quand un webhook Meta arrive, l'API appelle `scheduleMessage(userId, text)` dans `apps/api/src/services/queue.ts`.
+*   **Consumer (Railway) :**
+    Le Worker écoute la queue dans `apps/whatsapp-worker/src/index.ts`. Le handler de la file est instancié avec `new Worker('whatsappQueue', async (job) => { ... })`.
+*   **Job Types (Payload JSON) :**
+    *   Type `send-message` : `{ "userId": "uuid-1234", "text": "Bienvenue !" }`
+    *   Type `send-content` : `{ "userId": "uuid-123", "trackDayId": "day-123" }` (déclenche génération IA et envois médias).
+*   **Logs Attendus sur Railway :** 
+    `Worker: Processing job: send-message 123`
+    `[WhatsApp] ✅ Text message sent to 22177...`
+
+---
+
+## 5. WhatsApp Cloud API
+
+Toutes les requêtes sortantes vers Meta sont centralisées dans `apps/whatsapp-worker/src/whatsapp-cloud.ts`.
+
+*   **URL Exacte :** `https://graph.facebook.com/v18.0/<WHATSAPP_PHONE_NUMBER_ID>/messages` (Forcée via Axios avec un agent HTTP configuré explicitement sur l'IPv4 `family: 4` pour anticiper tout problème de configuration DNS Docker).
+*   **Headers :**
+    ```json
+    {
+      "Content-Type": "application/json",
+      "Authorization": "Bearer <WHATSAPP_ACCESS_TOKEN>"
+    }
+    ```
+*   **Body Type "Text" :**
+    ```json
+    {
+      "messaging_product": "whatsapp",
+      "recipient_type": "individual",
+      "to": "221781476249",
+      "type": "text",
+      "text": { "preview_url": false, "body": "Hello World" }
+    }
+    ```
+
+---
+
+## 6. Sécurité
+
+1.  **Validations Webhook HMAC**
+    La vérification cryptographique est active dans `apps/api/src/routes/whatsapp.ts`.
+    ```typescript
+    const expected = 'sha256=' + crypto.createHmac('sha256', secret).update(rawBody).digest('hex');
+    crypto.timingSafeEqual(Buffer.from(expected), Buffer.from(signature));
+    ```
+2.  **Rate Limiting Global (Hugging Face / Fastify)**
+    Configuré dans `index.ts` avec `@fastify/rate-limit`. Le seuil actuel est de `300 requêtes / minute` par adresse IP (qui protégera l'API si le Webhook fuite mais n'impactera pas l'IP de Meta qui est distribuée).
+3.  **API Key (Admin routes)**
+    Vérification stricte de `Bearer <ADMIN_API_KEY>` sur chaque route admin/backoffice.
+4.  **CORS**
+    CORS est ouvert globalement via `@fastify/cors` pour permettre au dashboard frontal d'intéragir depuis n'importe où.
+
+---
+
+## 7. Repo & Build
+
+Le projet est un monorepo géré avec **pnpm** et ses workspaces.
+
+*   `apps/api/` : Application Fastify (Node).
+*   `apps/whatsapp-worker/` : Processus BullMQ natif (Node).
+*   `packages/database/` : Couche Prisma partagée avec le schéma `schema.prisma`.
+
+**Commandes critiques (Railway Build & Start) :**
+*   Root command (Installation) : `pnpm install`
+*   Génération client : `pnpm --filter @repo/database build` (ou `prisma generate`).
+*   Build du Worker : `pnpm --filter whatsapp-worker build`
+*   Start du Worker (Prod) : `pnpm --filter whatsapp-worker start`
+
+_Note : Le script start de whatsapp-worker utilise actuellement `tsx src/index.ts` en développement. Pour la prod (Railway), il est conseillé de compiler avec `tsc` et lancer `node dist/index.js`._
+
+---
+
+## 8. Plan de Déploiement "Railway Worker Only"
+
+Pour déployer le Worker sur Railway, nous voulons ignorer totalement l'API et le Frontend. La configuration Railway cible le dossier du worker :
+
+1.  **Connect GitHub** : Ajouter le repository Edtech à Railway.
+2.  **Configuration du Service (Settings)** :
+    *   **Root Directory :** Laisser à `/` (car c'est un monorepo pnpm, Railway comprendra les workspaces).
+    *   **Build Command :** `pnpm install && pnpm --filter @repo/database build && pnpm --filter whatsapp-worker build`
+    *   **Start Command :** `pnpm --filter whatsapp-worker start`
+3.  **Injector les Variables (Variables tab)** :
+    *   Coller en Block Import les variables requises signalées en "Railway" ou "Both" dans la section [3].
+    *   Spécialement `DATABASE_URL`, `REDIS_URL`, `WHATSAPP_PHONE_NUMBER_ID`, et `WHATSAPP_ACCESS_TOKEN`.
+4.  **Checklist de validation finale :**
+    *   Envoyer `INSCRIPTION` au numéro WhatsApp.
+    *   Vérifier les logs sur le container de Hugging Face => on y voit la réception `[WEBHOOK] Received webhook event...`.
+    *   Ouvrir les logs de Railway => on y voit le worker prendre la relève `Processing job: send-message`.
+    *   Le téléphone reçoit le message instantanément.
+
+---
+
+## 9. Extraits de code de référence
+
+### A. Producer (Hugging Face) -> `services/queue.ts`
+```typescript
+import { Queue } from 'bullmq';
+import Redis from 'ioredis';
+
+const redisConnection = new Redis(process.env.REDIS_URL!);
+export const whatsappQueue = new Queue('whatsappQueue', { connection: redisConnection });
+
+export async function scheduleMessage(userId: string, text: string, delayMs: number = 0) {
+    await whatsappQueue.add('send-message', { userId, text }, { delay: delayMs });
+}
+```
+
+### B. Consumer (Railway Worker) -> `whatsapp-worker/src/index.ts`
+```typescript
+import { Worker, Job } from 'bullmq';
+import { sendTextMessage } from './whatsapp-cloud';
+
+const worker = new Worker('whatsappQueue', async (job: Job) => {
+    if (job.name === 'send-message') {
+        const { userId, text } = job.data;
+        const user = await prisma.user.findUnique({ where: { id: userId } });
+        if (user?.phone) {
+            await sendTextMessage(user.phone, text); // Appelle Graph API
+        }
+    }
+}, { connection: redisConnection });
+```
+
+### C. Bypass du blocage DNS (whatsapp-cloud.ts)
+```typescript
+import axios from 'axios';
+import https from 'https';
+import dns from 'node:dns';
+
+// Fix global ipv4first
+dns.setDefaultResultOrder('ipv4first');
+
+// Agent de secours
+const httpsAgent = new https.Agent({ family: 4 });
+
+export async function sendTextMessage(to: string, text: string): Promise<void> {
+    const url = `https://graph.facebook.com/v18.0/${process.env.WHATSAPP_PHONE_NUMBER_ID}/messages`;
+    await axios.post(url, body, {
+        headers: { Authorization: `Bearer ${process.env.WHATSAPP_ACCESS_TOKEN}` },
+        httpsAgent // Force le DNS à utiliser une route supportée
+    });
+}
+```
+
+### D. Endpoints de Diagnostique DNS & Egress Hugging Face (`api/src/index.ts`)
+```typescript
+server.get('/debug/net', async (_req, reply) => {
+    const res = await fetch('https://www.google.com', { method: 'GET' });
+    return reply.send({ ok: true, status: res.status }); // ✅ SUCCESS HF
+});
+
+server.get('/debug/graph', async (_req, reply) => {
+    const res = await fetch('https://graph.facebook.com/v18.0', { method: 'GET' });
+    return reply.send({ ok: true, status: res.status }); // ❌ ENOTFOUND HF
+});
+```

docs/architecture_pedagogique_whatsapp.md

@@ -0,0 +1,208 @@
+# Audit & Fonctionnement — Architecture Pédagogique Interactive (WhatsApp & Voix)
+
+Ce document est destiné à l'équipe technique et aux experts pédagogiques. Il détaille la transition de Xamlé d'un bot textuel "statique" vers **un moteur pédagogique interactif** centré sur la voix (`audioUrl` / TTS), les interactions rapides (`buttonsJson`), et le retour intelligent par l'IA (`UserProgress` / OpenAI).
+
+---
+
+## 1. Modèle de Données (Prisma)
+
+Pour soutenir des leçons interactives qui ne se valident que sous l'action de l'étudiant, deux changements majeurs ont été effectués dans `packages/database/prisma/schema.prisma`.
+
+### A. Le Contenu de la Leçon (`TrackDay`)
+L'ancien format texte brut a été enrichi pour supporter les audios et les interactions (boutons, vocaux).
+
+```prisma
+model TrackDay {
+  id                String       @id @default(uuid())
+  trackId           String
+  dayNumber         Int
+  title             String?
+  audioUrl          String?      // URL de l'audio pré-enregistré (sur R2) ou généré par TTS
+  lessonText        String?      // Texte de remplacement de l'audio
+  exerciseType      ExerciseType @default(TEXT) // Type (TEXT, AUDIO, BUTTON)
+  exercisePrompt    String?      // Question de validation à envoyer en texte ou en bouton
+  validationKeyword String?      // (Option) Si la validation nécessite un mot précis
+  buttonsJson       Json?        // Structure du bouton if ExerciseType == BUTTON
+  unlockCondition   String?      // Logique pour débloquer le jour suivant
+  createdAt         DateTime     @default(now())
+  updatedAt         DateTime     @updatedAt
+
+  track             Track        @relation(fields: [trackId], references: [id])
+}
+
+enum ExerciseType {
+  TEXT
+  AUDIO
+  BUTTON
+}
+```
+
+### B. Le Suivi de Mémorisation et Statut (`UserProgress`)
+Au lieu de passer l'enrollement au "jour suivant" immédiatement, nous utilisons désormais un modèle précis pour l'exercice en cours.
+
+```prisma
+model UserProgress {
+  id              String         @id @default(uuid())
+  userId          String
+  trackId         String
+  currentDay      Int            @default(1)
+  score           Int            @default(0) // Permet la gamification
+  lastInteraction DateTime       @default(now())
+  exerciseStatus  ExerciseStatus @default(PENDING) // PENDING -> l'étudiant doit répondre
+  createdAt       DateTime       @default(now())
+  updatedAt       DateTime       @updatedAt
+
+  user            User           @relation(fields: [userId], references: [id])
+  track           Track          @relation(fields: [trackId], references: [id])
+
+  @@unique([userId, trackId])
+}
+
+enum ExerciseStatus {
+  PENDING
+  COMPLETED
+}
+```
+
+---
+
+## 2. Le Moteur d'Envoi côté Worker (`pedagogy.ts`)
+
+La logique d'envoi du contenu (déclenchée par l'inscription ou la validation d'un exercice) a été isolée dans `apps/whatsapp-worker/src/pedagogy.ts`. 
+
+La fonction principale, `sendLessonDay(...)`, structure l'expérience en trois temps :
+1. Envoyer la leçon audio ou texte.
+2. Envoyer la question interactive.
+3. Bloquer l'utilisateur au statut `PENDING`.
+
+```typescript
+// Extrait de pedagogy.ts dans le worker Railway
+export async function sendLessonDay(userId: string, trackId: string, dayNumber: number) {
+    // 1. Envoi Audio (Via R2 ou TTS par défaut)
+    if (finalAudioUrl) {
+        await sendAudioMessage(user.phone, finalAudioUrl);
+    } else if (lessonText) {
+        await sendTextMessage(user.phone, lessonText);
+    }
+
+    // 2. Envoi de l'exercice interactif
+    if (trackDay.exercisePrompt) {
+        if (trackDay.exerciseType === 'BUTTON' && trackDay.buttonsJson) {
+            // Appelle l'API Meta avec le format Interactive Button
+            const buttons = trackDay.buttonsJson as Array<{ id: string; title: string }>;
+            await sendInteractiveButtonMessage(user.phone, trackDay.exercisePrompt, buttons);
+        } else {
+            await sendTextMessage(user.phone, trackDay.exercisePrompt);
+        }
+    }
+
+    // 3. Mise en attente de la réponse de l'utilisateur
+    await prisma.userProgress.upsert({
+        where: { userId_trackId: { userId, trackId } },
+        update: { currentDay: dayNumber, exerciseStatus: 'PENDING', lastInteraction: new Date() },
+        create: { userId, trackId, currentDay: dayNumber, exerciseStatus: 'PENDING' }
+    });
+}
+```
+
+---
+
+## 3. Le Routage Webhook (`WhatsAppMessageSchema` et Interception)
+
+L'API (Hugging Face) écoute les réponses. Si une réponse est reçue avec le statut `PENDING`, elle l'envoie au coach IA.
+De plus, le typage Zod de l'événement entrant a été corrigé pour intercepter les boutons WhatsApp :
+
+```typescript
+// Extrait de apps/api/src/routes/whatsapp.ts
+const WhatsAppMessageSchema = z.object({
+    from: z.string(),
+    type: z.enum(['text', 'audio', 'image', 'video', 'document', 'sticker', 'reaction', 'interactive']),
+    text: z.object({ body: z.string() }).optional(),
+    audio: z.object({ id: z.string(), mime_type: z.string().optional() }).optional(),
+    interactive: z.object({
+        type: z.enum(['button_reply', 'list_reply']),
+        button_reply: z.object({ id: z.string(), title: z.string() }).optional()
+    }).optional()
+});
+
+// Dans le parsing du payload, on convertit un clic bouton en "Text", ou un Audio via STT Whisper :
+if (message.type === 'interactive' && message.interactive) {
+    if (message.interactive.type === 'button_reply' && message.interactive.button_reply) {
+        text = message.interactive.button_reply.id; // L'ID du bouton devient la réponse envoyée à l'IA
+    }
+} else if (message.type === 'audio' && message.audio) {
+    // On télécharge l'audio de Meta et on utilise Whisper pour le transcrire
+    text = await aiService.transcribeAudio(buffer, 'message.ogg');
+}
+```
+
+---
+
+## 4. La Boucle de Correction IA (`whatsapp.ts` et `ai.ts`)
+
+Lorsqu'une réponse (texte ou bouton) est interceptée par l'API alors qu'un exercice est "PENDING", elle sollicite `generateFeedback`.
+
+```typescript
+// Logique d'interception (app/api/src/services/whatsapp.ts)
+const pendingProgress = await prisma.userProgress.findFirst({
+    where: { userId: user.id, exerciseStatus: 'PENDING' },
+    include: { track: true }
+});
+
+if (pendingProgress) {
+    await scheduleMessage(user.id, "⏳ Analyse de votre réponse...");
+    
+    // Génération du feedback IA
+    const feedback = await aiService.generateFeedback(
+        text, // Ce que l'utilisateur a répondu ou cliqué
+        trackDay.exercisePrompt || '', // L'exercice attendu
+        trackDay.lessonText || '' // Le contexte de la leçon
+    );
+    
+    await scheduleMessage(user.id, feedback);
+
+    // ✅ On débloque l'utilisateur
+    await prisma.userProgress.update({
+        where: { id: pendingProgress.id },
+        data: { exerciseStatus: 'COMPLETED', score: { increment: 1 } }
+    });
+}
+```
+
+### Le Prompt Pédagogique (OpenAI GPT-4o-mini)
+L'intelligence est formatée pour un coach bienveillant sénégalais du secteur informel (WhatsApp Native).
+
+```typescript
+// apps/api/src/services/ai/index.ts
+const prompt = `
+Tu es un coach business bienveillant pour des entrepreneurs du secteur informel au Sénégal.
+L'étudiant vient d'écouter cette leçon : "${lessonContent}"
+L'exercice attendu était : "${expectedExercise}"
+Voici la réponse ou action de l'étudiant : "${userInput}"
+
+Ta mission :
+Analyse sa réponse logiquement. Valide-la avec beaucoup d'enthousiasme, et ajoute UN conseil très pratique, précis, ou une mini correction bienveillante.
+Contrainte stricte : MAXIMUM 5 LIGNES. 
+Format WhatsApp : Utilise un langage très simple, direct, des mots courants, une structure aérée avec du *gras* pour les mots clés importants, et des emojis adaptés.
+`;
+```
+
+---
+
+## 5. Fonctionnalités Utiles Ajoutées pour le Déboguage
+
+- **Le mot-clé `INSCRIPTION` (WhatsApp)** : Pour ne pas bloquer les utilisateurs en cours de test, le mot-clé supprime les données "ville" et "activité", et "enrollments" pour **REMETTRE L'ÉTUDIANT À ZÉRO** à la volée.
+- **Le mot-clé `SUITE` (WhatsApp)** : Par défaut, la prochaine leçon (lorsque "COMPLETED" est atteint) n'arrive que le lendemain matin via le Scheduler de BullMQ. Si l'utilisateur envoie `SUITE`, nous forçons le passage immédiat au jour suivant sans attendre 24 heures.
+
+---
+
+## 6. Feedbacks Requis par l'Expert et Axes d'Amélioration (V2)
+
+L'expert observant la codebase doit envisager ces améliorations :
+
+1. **Fallback si Feedback "Négatif"** : Actuellement, le système génère un feedback bienveillant et passe `UserProgress` à `COMPLETED` même si l'étudiant dit une erreur ou envoie un contenu inapproprié. Il faudrait un "score de validation IA" (`true/false`) dans le schéma Zod de l'IA. Si `false`, on laisse le statut à `PENDING`.
+2. **Audio Natifs R2** : Lors de la création d'un "TrackDay", le tableau de bord Admin (pas encore construit sur ce pan) doit pouvoir uploader de vrais MP3 professionnels vers R2, et enregistrer l'URL dans `TrackDay.audioUrl`. Sans quoi le système "fallback" sur la génération automatique (TTS) assez robotique.
+3. **Limites des Boutons WhatsApp** : 
+   - Meta impose un Maximum de 3 boutons interactifs par message. S'il y a 4 questions, il faudra switcher vers l'événement `List_reply` (Menu interactif WhatsApp).
+   - Les titres des boutons sont limités à 20 caractères.
+4. **Vidéos Verticales** : Le schéma BDD ne gère pas encore de champ `videoUrl`. Quand le format Vlog entrera en lice, il suffira de rajouter ce champ dans `TrackDay` et la fonction `sendVideoMessage` au Wrapper API Cloud Meta.

docs/audit_production.md

@@ -0,0 +1,123 @@
+# Audit Complet — État de la Codebase
+*Date : 2026-02-22 — Commit base : `c286b2d`*
+
+---
+
+## 1. Architecture globale
+
+```
+apps/
+  api/            → Fastify REST API (Railway — port 3001)
+  whatsapp-worker/ → BullMQ Worker (Railway — même container)
+  admin/          → Dashboard React (Vite + Tailwind)
+  web/            → Landing page + portail étudiant (Vite + Tailwind)
+
+packages/
+  database/       → Prisma schema (PostgreSQL) + migrations
+  shared-types/   → Types TypeScript partagés
+  tsconfig/       → Config TS commune
+  ui/             → (vide)
+```
+
+---
+
+## 2. Ce qui fonctionne ✅
+
+| Composant | État |
+|---|---|
+| Webhook WhatsApp (GET verify + POST events) | ✅ Implémenté |
+| Onboarding : INSCRIPTION → langue → secteur | ✅ |
+| Menus interactifs LIST (boutons natifs) | ✅ Titre ≤ 24 chars corrigé |
+| Download audio Meta Graph API (Railway) | ✅ |
+| Transcription Whisper via `/v1/ai/transcribe` | ✅ |
+| Feedback AI `generateFeedback()` + 429 fallback | ✅ |
+| Timeout IA 10s (Promise.race) | ✅ |
+| TTS leçon → audio R2 | ✅ |
+| Personnalisation leçon par secteur | ✅ |
+| SUITE / DAY_CONTINUE → jour suivant | ✅ Regex fixé |
+| REPLAY → réécoute leçon | ✅ |
+| EXERCISE → invite réponse | ✅ |
+| Dock génération OnePager PDF + PitchDeck PPTX | ✅ |
+| Paiements Stripe (checkout + webhook) | ✅ Implémenté |
+| Admin dashboard (stats + enrollments + CSV export) | ✅ |
+| Dockerfile combiné API + Worker (Railway) | ✅ |
+| Scheduler cron leçons quotidiennes | ✅ (basique) |
+| Stockage audio R2 via `/v1/ai/store-audio` | ✅ Ajouté |
+
+---
+
+## 3. Problèmes identifiés ❌
+
+### 3.1 Critiques (bloquants en prod)
+
+| # | Fichier | Problème | Solution |
+|---|---|---|---|
+| C1 | `Railway vars` | `WHATSAPP_APP_SECRET` non défini → HMAC skip (warning) | Ajouter la variable |
+| C2 | `Railway vars` | `DISABLE_WHATSAPP_SEND=true` encore présent → aucun envoi | Supprimer la variable |
+| C3 | Base de données | **Aucun contenu (Track/TrackDay) en production** → enrollement impossible | Seed ou admin content manager |
+| C4 | `api/src/services/stripe.ts` | STRIPE_SECRET_KEY et STRIPE_WEBHOOK_SECRET non vérifiés au démarrage | Ajouter à Railway vars |
+| C5 | Meta webhook | URL pas encore validée si container 502 | Corriger après Railway restart |
+
+### 3.2 Importants (fonctionnalités incomplètes)
+
+| # | Composant | Problème |
+|---|---|---|
+| I1 | `apps/admin` | **Pas de gestion de contenu (Tracks/TrackDays)** — impossible de créer des leçons via l'interface |
+| I2 | `apps/admin` | `env.user?.whatsappId` utilisé mais le modèle User a `phone` (pas `whatsappId`) → colonne vide dans le tableau |
+| I3 | `apps/web` | **Portail étudiant `/login` est factice** — `handleLogin` fait un fake `alert` avec `setTimeout`, n'appelle aucune API |
+| I4 | `apps/web` | Pas de page de succès paiement Stripe (`/payment/success`) |
+| I5 | `whatsapp-worker/src/scheduler.ts` | Cron envoie les leçons mais **sans logique de vérification du jour courant** — risque d'envoyer à des utilisateurs déjà complétés |
+| I6 | `apps/api/routes/admin.ts` | Pas de route pour **créer/modifier des Tracks ou TrackDays** API-side |
+| I7 | `packages/ui` | Package vide — prévu pour composants partagés mais non utilisé |
+
+### 3.3 Mineurs (dette technique)
+
+| # | Problème |
+|---|---|
+| M1 | `Enrollment` et `UserProgress` sont deux tables qui trackent le même `currentDay` et `exerciseStatus` — duplication de données |
+| M2 | `admin/src/App.tsx` ligne 108 : import `lucide-react` collé avec une déclaration d'interface (mauvais formatage) |
+| M3 | `Message` modèle Prisma non utilisé nulle part dans le code (payload jamais stocké) |
+| M4 | `web/src` n'a pas de `VITE_API_URL` configuré par défaut → fallback `localhost:3001` en prod |
+| M5 | Pas de gestion du cas où un utilisateur envoie `INSCRIPTION` alors qu'il est déjà inscrit à une formation active |
+
+---
+
+## 4. Variables d'environnement — état complet
+
+### Railway (whatsapp-worker service)
+
+| Variable | Statut | Action |
+|---|---|---|
+| `WHATSAPP_VERIFY_TOKEN` | ✅ | OK |
+| `WHATSAPP_ACCESS_TOKEN` | ✅ | OK |
+| `WHATSAPP_PHONE_NUMBER_ID` | ✅ | OK |
+| `WHATSAPP_APP_SECRET` | ⚠️ Non défini | **Ajouter** (Meta App → Basic Settings → App Secret) |
+| `ADMIN_API_KEY` | ✅ (confirmé) | OK |
+| `DATABASE_URL` | ✅ | OK |
+| `REDIS_URL` | ✅ | OK |
+| `OPENAI_API_KEY` | ✅ | OK |
+| `API_URL` | ✅ | OK (doit pointer vers URL Railway publique) |
+| `DISABLE_WHATSAPP_SEND` | ❌ Présent | **Supprimer** |
+| `STRIPE_SECRET_KEY` | ❓ Non confirmé | Ajouter si Stripe actif |
+| `STRIPE_WEBHOOK_SECRET` | ❓ Non confirmé | Ajouter si Stripe actif |
+| `NODE_ENV` | ✅ | OK |
+| `R2_*` variables | ✅ | OK |
+
+### HuggingFace (api service — inbound webhook désactivé)
+
+| Variable | Statut |
+|---|---|
+| `DISABLE_WHATSAPP_SEND` | ✅ `true` (correct) |
+| `OPENAI_API_KEY` | ✅ |
+| `DATABASE_URL` | ✅ |
+| Autres | Même que Railway |
+
+---
+
+## 5. Déploiements
+
+| Service | Plateforme | URL | État |
+|---|---|---|---|
+| API + Worker (webhook + BullMQ) | Railway | `whatsapp-worker-production-0bc0.up.railway.app` | 🟡 En restart |
+| Landing + Portail | HF / Netlify ? | À confirmer | ❓ |
+| Admin Dashboard | HF / Netlify ? | À confirmer | ❓ |

docs/flow utilisateurs et formation .md

@@ -0,0 +1,641 @@
+# XAMLE – NOUVELLE ARCHITECTURE PÉDAGOGIQUE VOIX & WHATSAPP
+
+> Objectif : transformer Xamle en plateforme EdTech mobile-first ultra intuitive pour le secteur informel, priorisant AUDIO + BOUTONS WHATSAPP + EXERCICES TERRAIN + IA.
+
+---
+
+# 1️⃣ POSITIONNEMENT PÉDAGOGIQUE STRATÉGIQUE
+
+Xamle ne doit pas être un simple bot qui envoie des messages.
+
+Il doit devenir :
+
+→ Un coach business vocal interactif
+→ Un système d’apprentissage terrain progressif
+→ Un moteur IA qui transforme apprentissage → documents concrets
+
+Cible : entrepreneurs secteur informel
+Contraintes :
+- Faible écriture
+- Connexion instable
+- Temps limité
+- Préférence audio
+
+Donc priorité :
+
+✅ Audio court
+✅ Boutons interactifs
+✅ Exercices terrain concrets
+✅ Réponses vocales possibles
+✅ Vidéo courte mobile verticale
+
+---
+
+# 2️⃣ NOUVEAU FLOW UTILISATEUR APRÈS INSCRIPTION
+
+## Étape 1 – Choix langue
+
+1. Français 🇫🇷
+2. Wolof 🇸🇳
+
+## Étape 2 – Choix OBJECTIF PRINCIPAL (UX simplifiée)
+
+🎯 Trouver des clients
+💰 Mieux gagner de l’argent
+🧠 Comprendre son business
+🚀 Lever des fonds / Pitcher
+
+➡ IMPORTANT : Ces choix restent visibles côté utilisateur (langage simple et concret).
+
+⚙️ MAIS en backend, chaque objectif correspond à de vrais modules structurés :
+
+- "Trouver des clients" → Module Marketing + Validation terrain (Design Thinking appliqué)
+- "Mieux gagner de l’argent" → Module Pricing + Business Model
+- "Comprendre son business" → Module Business Model Simplifié
+- "Lever des fonds / Pitcher" → Module Pitch + Pitch Deck
+
+👉 Conclusion :
+On garde les choix orientés PROBLÈME (UX simple)
+Mais on structure les contenus avec de vrais modules entrepreneuriaux (Design Thinking, Business Model, Pitch).
+
+---
+
+# 3️⃣ STRUCTURE DES MODULES D’APPRENTISSAGE (VERSION MVP SANS VIDÉO)
+
+⚠️ Décision :
+Pour la V1, on n’intègre PAS encore les vidéos.
+On se concentre sur : AUDIO + BOUTONS + EXERCICE + FEEDBACK IA.
+Les vidéos seront ajoutées en V2.
+
+Chaque module contient :
+
+1️⃣ Leçon audio (2–3 min max)
+- langage simple
+- voix naturelle locale
+- 1 seul objectif par leçon
+- stockée sur R2
+
+2️⃣ Exercice terrain obligatoire
+Exemples :
+- Parler à 3 clients
+- Calculer son prix réel
+- Observer un problème
+- Faire un mini pitch audio
+
+3️⃣ Interaction WhatsApp
+- Boutons interactifs
+- Validation par chiffre possible
+- Message vocal accepté
+
+4️⃣ Feedback IA
+- Encouragement
+- Correction simple
+- Suggestion pratique
+- Génération automatique si nécessaire
+
+---
+
+Architecture logique d’une journée :
+
+Étape 1 → sendLessonDay()
+Étape 2 → envoi audio
+Étape 3 → envoi boutons
+Étape 4 → attente réponse utilisateur
+Étape 5 → sauvegarde DB
+Étape 6 → feedback IA
+Étape 7 → déblocage jour suivant
+
+
+---
+
+# 4️⃣ STRUCTURE PROGRESSIVE DES MODULES (STRUCTURE HYBRIDE RECOMMANDÉE)
+
+⚠️ Décision stratégique :
+
+On ne doit PAS opposer :
+- Objectifs simples (Trouver clients, Gagner argent…)
+- Modules structurés (Design Thinking, Business Model, Pitch)
+
+On combine les deux.
+
+---
+
+## NIVEAU 1 – MODULES VISIBLES (Langage simple UX)
+
+Ce que l’utilisateur voit :
+
+1️⃣ Comprendre son business
+2️⃣ Trouver des clients
+3️⃣ Mieux gagner de l’argent
+4️⃣ Structurer son activité
+5️⃣ Pitcher son projet
+
+---
+
+## NIVEAU 2 – STRUCTURE ACADÉMIQUE INTERNE (Backend)
+
+Ces modules sont en réalité construits sur :
+
+### MODULE A – Design Thinking Terrain
+- Observer problème
+- Tester solution
+- Ajuster
+
+### MODULE B – Business Model Simplifié
+- Client
+- Proposition de valeur
+- Revenus
+- Coûts
+- Partenaires
+
+### MODULE C – Pricing & Rentabilité
+- Coût réel
+- Marge
+- Prix stratégique
+
+### MODULE D – Marketing Terrain
+- Où trouver clients
+- Message simple
+- Test terrain
+
+### MODULE E – Pitch Simple
+- Problème
+- Solution
+- Client
+- Différence
+
+### MODULE F – Pitch Deck (avancé)
+- Histoire
+- Marché
+- Traction
+- Besoin financier
+
+---
+
+## Progression pédagogique recommandée
+
+Phase 1 – Survie & Cash
+→ Comprendre business
+→ Trouver clients
+→ Fixer prix
+
+Phase 2 – Structuration
+→ Business Model
+→ Marketing terrain
+
+Phase 3 – Croissance
+→ Pitch
+→ Pitch deck
+
+---
+
+🎯 Conclusion stratégique :
+
+UX = langage problème (simple)
+Architecture = vrais frameworks entrepreneuriaux
+
+C’est la meilleure combinaison entre accessibilité et crédibilité.
+
+---
+
+# 5️⃣ UX WHATSAPP RECOMMANDÉE
+
+Après chaque leçon :
+
+1️⃣ Réécouter 🎧
+2️⃣ Voir vidéo ▶️
+3️⃣ Faire exercice 📝
+4️⃣ Continuer ➡️
+
+Réponses possibles :
+- Boutons interactifs
+- Message vocal
+- Chiffre (1/2/3/4)
+
+---
+
+# 6️⃣ ADAPTATION BASE DE DONNÉES RECOMMANDÉE
+
+Nouvelle structure recommandée pour track_days :
+
+- id
+- track_id
+- day_number
+- title
+- audio_url
+- video_url
+- lesson_text
+- exercise_type (audio / texte / photo / bouton)
+- exercise_prompt
+- validation_keyword
+- buttons_json
+
+Ajouter :
+
+- user_progress (score, last_activity)
+- media_storage_url
+- exercise_status
+
+---
+
+# 7️⃣ FAISABILITÉ TECHNIQUE AVEC INFRA ACTUELLE
+
+Infra actuelle :
+
+✅ Neon Postgres
+✅ Railway Worker
+✅ Redis Upstash
+✅ R2 Cloudflare
+✅ WhatsApp Cloud API
+
+Conclusion :
+
+✔ Audio sortant = possible
+✔ Boutons interactifs = possible
+✔ Messages vocaux entrants = possible
+✔ Vidéos = possible
+✔ Stockage média = possible via R2
+
+Aucun changement d’infrastructure nécessaire.
+
+Le blocage n’est pas technique.
+Il est pédagogique et UX.
+
+---
+
+# 8️⃣ CE QUE L’HUMAIN DOIT DÉFINIR
+
+1️⃣ Scripts audio simples (langue locale validée)
+2️⃣ Exercices terrain réels
+3️⃣ Progression pédagogique cohérente
+4️⃣ Vocabulaire accessible secteur informel
+
+---
+
+# 9️⃣ PROMPT À DONNER À ANTIGRAVITY POUR INTÉGRATION RAILWAY + BACKEND
+
+Utilise le prompt ci-dessous :
+
+---
+
+Tu es architecte senior Node.js + Prisma + WhatsApp Cloud API.
+
+Contexte :
+Nous transformons le WhatsApp Worker actuel en moteur pédagogique interactif vocal (sans vidéo pour la V1).
+
+Stack existante :
+- Node.js
+- Prisma + Neon Postgres
+- Redis Upstash
+- Railway
+- R2 Cloudflare
+- WhatsApp Cloud API
+
+⚠️ Ne pas modifier l’architecture globale.
+⚠️ Ne pas supprimer le système actuel d’onboarding.
+⚠️ Ajouter uniquement la couche pédagogique.
+
+---
+
+OBJECTIFS TECHNIQUES
+
+1️⃣ Adapter le modèle Prisma :
+
+Model TrackDay {
+  id
+  trackId
+  dayNumber
+  title
+  audioUrl
+  lessonText
+  exerciseType
+  exercisePrompt
+  validationKeyword
+  buttonsJson
+  unlockCondition
+}
+
+Créer table UserProgress :
+
+Model UserProgress {
+  id
+  userId
+  trackId
+  currentDay
+  score
+  lastInteraction
+  exerciseStatus
+}
+
+---
+
+2️⃣ Créer fonction principale :
+
+async function sendLessonDay(userId: string, dayNumber: number)
+
+Elle doit :
+- Charger TrackDay
+- Envoyer audio WhatsApp
+- Envoyer message interactif avec boutons
+- Sauvegarder état progression
+
+---
+
+3️⃣ Modifier Webhook WhatsApp
+
+Le webhook doit :
+- Détecter message texte
+- Détecter message vocal
+- Détecter bouton interactif
+- Mapper réponse vers exercice
+- Sauvegarder réponse
+- Déclencher feedback IA
+
+---
+
+4️⃣ Gestion des exercices
+
+Si exerciseType = "audio"
+→ Télécharger media WhatsApp
+→ Stocker sur R2
+→ Sauvegarder URL
+
+Si exerciseType = "text"
+→ Sauvegarder texte
+
+Si exerciseType = "button"
+→ Mapper reply.id
+
+---
+
+5️⃣ Feedback IA
+
+Créer fonction :
+
+async function generateFeedback(userInput, context)
+
+Utiliser OPENAI_API_KEY existante
+Retourner feedback court (max 5 lignes)
+
+---
+
+6️⃣ Scoring
+
+- +1 point par exercice validé
+- Mise à jour UserProgress
+- Si dernier jour → trigger génération document (pitch / onepager)
+
+---
+
+Livrables attendus :
+
+- Schéma Prisma complet
+- Migration SQL
+- Exemple JSON bouton WhatsApp
+- Code complet sendLessonDay()
+- Code webhook mis à jour
+- Plan de migration base existante
+
+---
+
+IMPORTANT :
+
+Ne pas ajouter vidéo pour la V1.
+Concentrer la logique sur audio + interaction + progression.
+
+---
+
+Retourner le code prêt à intégrer sur Railway.
+
+---
+
+
+---
+
+# 🔟 MON AVIS STRATÉGIQUE
+
+Ce que vous avez fait jusqu’ici est faisable.
+
+L’infrastructure est solide.
+
+Le vrai chantier maintenant est :
+
+➡ UX pédagogique
+➡ Structuration des modules
+➡ Interaction intuitive
+
+La proposition "Voix + Boutons + Terrain" est excellente.
+
+C’est différenciant.
+C’est adapté au secteur informel.
+C’est scalable.
+
+Et surtout : c’est réaliste techniquement avec votre stack actuelle.
+
+---
+
+# 🚀 PROCHAINE ÉTAPE RECOMMANDÉE
+
+Décision : programme de 1 mois (4 semaines) avec terrain.
+
+Pour la V1 WhatsApp, on recommande :
+- 3 leçons / semaine (lun-mer-ven) → 12 leçons / mois
+- Chaque leçon : audio 2–3 min + 1 exercice terrain + 1 réponse simple
+- Les jours "OFF" : l’apprenant applique sur le terrain (sans surcharge)
+
+✅ Objectif : apprentissage réel + action terrain + progression mesurable.
+
+---
+
+# 11️⃣ MODULE 1 (1 MOIS) – COMPRENDRE SON BUSINESS (SECTEUR INFORMEL)
+
+## 11.1 Résultat attendu à la fin du mois
+
+À la fin du Module 1, l’apprenant doit pouvoir :
+- Décrire son activité en 1 phrase (simple)
+- Identifier 1 client principal + où le trouver
+- Expliquer le problème client qu’il résout
+- Énoncer son offre (produit/service) clairement
+- Donner un prix de base cohérent (premier test)
+- Construire un mini pitch vocal de 30–45 secondes
+
+⚠️ Ce module n’est pas théorique : chaque semaine impose des tests terrain.
+
+---
+
+## 11.2 Règles UX WhatsApp (V1)
+
+- Réponses autorisées :
+  - 1/2/3/4 (chiffres)
+  - audio (recommandé)
+  - texte très court
+- Longs formulaires interdits.
+- Toujours proposer des choix via boutons quand possible.
+
+### Boutons standard (après chaque leçon)
+1️⃣ Réécouter 🎧
+2️⃣ Faire l’exercice 📝
+3️⃣ Envoyer ma réponse 🎙️
+4️⃣ Continuer ➡️
+
+---
+
+## 11.3 Structure d’une leçon (TrackDay)
+
+Chaque TrackDay doit contenir :
+- title
+- audioUrl (R2)
+- lessonText (résumé très court)
+- exercisePrompt (terrain)
+- exerciseType (audio|text|button|photo)
+- buttonsJson (interactive)
+- validationKeyword (ex: FAIT, OK, DONE) + acceptation audio
+- unlockCondition (complétion jour)
+
+---
+
+## 11.4 Calendrier – 4 semaines / 12 leçons
+
+> Note : l’apprenant reçoit la leçon le matin (ex: 08:00) mais peut répondre quand il veut.
+
+### Semaine 1 – Clarifier l’activité (ce que je fais vraiment)
+
+**Jour 1 (Lun) – "Mon activité en 1 phrase"**
+- Objectif : clarifier ce que tu vends (sans jargon)
+- Audio (script FR – simple) :
+  - "Dis-moi simplement : tu aides QUI à faire QUOI, et comment tu gagnes de l’argent. Exemple : Je vends du jus bissap aux étudiants devant l’université."
+- Exercice terrain : écrire ou dire une phrase :
+  - "Je vends [offre] à [client] à [lieu]" (ou audio)
+- Réponse attendue : audio 10–20s (ou texte 1 ligne)
+- Feedback IA : reformule en phrase plus claire
+
+**Jour 2 (Mer) – "Ce que le client achète vraiment"**
+- Objectif : différencier produit vs bénéfice
+- Audio :
+  - "Le client n’achète pas un produit, il achète un résultat. Exemple : il n’achète pas du savon, il achète la propreté."
+- Exercice terrain : demander à 2 clients :
+  - "Pourquoi tu achètes ça ?" → noter 2 réponses
+- Réponse : 1 audio (20s) avec les 2 raisons
+- Feedback IA : extrait 1 bénéfice principal
+
+**Jour 3 (Ven) – "Mon client principal"**
+- Objectif : choisir un client prioritaire (pas "tout le monde")
+- Audio :
+  - "Si tu essaies de vendre à tout le monde, tu vends à personne. On choisit 1 client principal." 
+- Exercice : choisir 1 client principal parmi 3 options (boutons)
+  - A) Jeunes
+  - B) Femmes
+  - C) Commerçants
+  - D) Autre (texte court)
+- Réponse : bouton + (si Autre) texte
+- Feedback IA : confirme le persona simple
+
+### Semaine 2 – Problème client (ce que je résous)
+
+**Jour 4 (Lun) – "Le problème n°1"**
+- Objectif : identifier 1 douleur forte
+- Audio : "Quel problème ton client veut éviter ?"
+- Exercice terrain : parler à 3 personnes du client choisi et demander :
+  - "C’est quoi ton plus gros problème sur ça ?"
+- Réponse : audio 30s résumant les 3 réponses
+- Feedback IA : synthèse en 1 problème
+
+**Jour 5 (Mer) – "Quand le problème arrive"**
+- Objectif : comprendre contexte et moment
+- Audio : "À quel moment ton client a le problème ?"
+- Exercice : choisir un moment (boutons)
+  - Matin / Midi / Soir / Tout le temps
+- Réponse : bouton + 1 phrase (option)
+- Feedback IA : propose une phrase de positionnement
+
+**Jour 6 (Ven) – "Comment ils le résolvent aujourd’hui"**
+- Objectif : concurrence = solutions actuelles
+- Audio : "Avant toi, le client fait comment ?"
+- Exercice : écrire 2 solutions actuelles (texte court) ou audio
+- Feedback IA : clarifie ton avantage
+
+### Semaine 3 – Offre (solution) & preuve terrain
+
+**Jour 7 (Lun) – "Mon offre simple"**
+- Objectif : décrire l’offre en mots simples
+- Audio : "Dis ta solution en une phrase." 
+- Exercice : phrase offre + 1 exemple réel
+- Réponse : audio 20s
+- Feedback IA : reformule en offre claire
+
+**Jour 8 (Mer) – "Promesse et limite"**
+- Objectif : éviter promesses irréalistes
+- Audio : "Promets petit, livre grand." 
+- Exercice : choisir 1 promesse parmi 3 (boutons)
+  - Rapide / Moins cher / Plus fiable
+- Feedback IA : propose promesse adaptée au contexte
+
+**Jour 9 (Ven) – "Test terrain 1"**
+- Objectif : valider l’intérêt
+- Audio : "Parle à 5 personnes et propose ton offre en 10 secondes." 
+- Exercice :
+  - Dire à 5 personnes : "Je fais X pour Y" 
+  - Noter combien disent OUI/NON
+- Réponse : chiffre (ex: OUI=2, NON=3)
+- Feedback IA : conseil pratique (améliorer phrase)
+
+### Semaine 4 – Argent (premier prix) & mini pitch
+
+**Jour 10 (Lun) – "Prix de base"**
+- Objectif : fixer un premier prix cohérent
+- Audio : "Ton prix doit couvrir tes coûts + marge." 
+- Exercice :
+  - écrire 2 coûts principaux + prix actuel
+- Réponse : texte court (ou audio)
+- Feedback IA : suggère marge minimale
+
+**Jour 11 (Mer) – "Ton avantage"**
+- Objectif : différenciation simple
+- Audio : "Pourquoi toi plutôt qu’un autre ?" 
+- Exercice : choisir 1 avantage (boutons)
+  - Qualité / Rapidité / Confiance / Proximité
+- Feedback IA : phrase d’avantage
+
+**Jour 12 (Ven) – "Mini pitch audio"**
+- Objectif : sortir un pitch 30–45s
+- Audio : guide pitch :
+  1) Je suis…
+  2) J’aide…
+  3) Parce que…
+  4) Je vends… à …
+- Exercice : envoyer pitch vocal 30–45s
+- Réponse : audio obligatoire
+- Feedback IA : 3 conseils max + version texte du pitch
+
+---
+
+## 11.5 Sorties IA après Module 1 (automatiques)
+
+Après Jour 12 complété :
+- Générer :
+  - Pitch texte 30s
+  - One-liner activité
+  - Mini fiche (1 page) "Mon activité" (option)
+
+⚠️ Pitch deck complet = V2 (ou Module Pitch dédié).
+
+---
+
+## 11.6 Notes d’implémentation (pour Antigravity)
+
+- Créer Track "MODULE1_COMPRENDRE_BUSINESS" (FR + WO)
+- Seeder : insérer 12 TrackDays
+- sendLessonDay() :
+  - envoyer audio (media)
+  - envoyer interactive buttons
+- Webhook :
+  - accepter chiffres + boutons + audio
+- Exercice terrain :
+  - validationKeyword = {"FAIT","OK","DONE"} ou audio reçu
+- Progression :
+  - currentDay++ après validation
+
+---
+
+Fin du document.
+

docs/plan technique solution .md

@@ -0,0 +1,592 @@
+# 12. PLAN COMPLET DE LA SOLUTION (TECHNIQUE)
+
+> Objectif : développer une plateforme EdTech **mobile-first** centrée sur WhatsApp + contenus sociaux, avec une brique IA pour générer des documents (pitch, pitch deck, one-pager, mini business plan, logo basique).
+
+## 12.1 Produits livrables (MVP → V1)
+
+### MVP (6–8 semaines)
+
+- WhatsApp Learning Track (7–14 jours) : inscription, séquençage, exercices, suivi de complétion
+- Admin dashboard : cohortes, progression, export CSV, tags, statistiques de base
+- Générateur IA v0 : **Pitch (30s + 2min)** + **One-pager PDF** (1 page)
+- Landing page : inscription, FAQ, contact
+
+### V1 (8–16 semaines)
+
+- Générateur IA v1 : Pitch deck (8–10 slides PPTX) + mini business plan (2–4 pages)
+- Bibliothèque de templates (deck / one-pager) + styles
+- Scoring pédagogique (auto-évaluation) : maturité business (non-financier complexe)
+- Paiement (Wave / Orange Money) pour cohortes présentiel
+
+### V2 (16–24 semaines)
+
+- Personnalisation par filière (livreur, artisanat, commerce, transformation)
+- Multi-langue (Wolof + Français)
+- Data products (anonymisés) : tableaux de bord d’insights pour partenaires
+
+---
+
+# 13. ARCHITECTURE (SIMPLE, SCALABLE)
+
+## 13.1 Vue d’ensemble
+
+**Canaux**
+
+- TikTok / Instagram : acquisition (contenus + CTA)
+- WhatsApp : parcours structuré (learning track)
+- Web : inscription + paiement + téléchargement documents
+
+**Back-end**
+
+- API principale (auth, learning, admin)
+- Service WhatsApp (webhooks + envoi messages)
+- Service IA (génération texte + génération PDF/PPTX)
+
+**Données**
+
+- Base Postgres (users, tracks, réponses, documents)
+- Stockage fichiers (PDF/PPTX) : S3 compatible (ex: Cloudflare R2 / AWS S3 / OVH Object Storage)
+
+## 13.2 Recommandation repo Git
+
+✅ Démarrage conseillé : **Monorepo** (plus simple au début)
+
+Structure type :
+
+- `/apps/api` : API (Node/TS ou Python)
+- `/apps/whatsapp-worker` : worker WhatsApp (queues + scheduling)
+- `/apps/admin` : dashboard admin (Next.js)
+- `/apps/web` : landing + paiement + portail apprenant
+- `/packages/shared` : types, templates, prompts, contenu pédagogique
+
+➡️ Séparer en plusieurs repos uniquement si l’IA devient un produit autonome.
+
+---
+
+# 14. STACK TECH RECOMMANDÉ
+
+## 14.1 Front-end
+
+- **Next.js** (React) : admin + web portal
+- UI : TailwindCSS + component library (shadcn/ui)
+
+## 14.2 Back-end
+
+Option A (très simple, robuste) : **Node.js + TypeScript**
+
+- Framework : Fastify ou NestJS
+- Validation : Zod
+
+Option B (si équipe plus Python) : **Python + FastAPI**
+
+## 14.3 Base de données
+
+- **PostgreSQL** (Neon / Supabase / OVH / RDS)
+- ORM : Prisma (Node) ou SQLModel (Python)
+
+## 14.4 Messaging / Jobs
+
+- Queue : **BullMQ (Redis)** ou **Cloud Tasks**
+- Objectif : envoi WhatsApp programmé, génération documents asynchrone
+
+## 14.5 WhatsApp
+
+- Recommandé : **WhatsApp Cloud API (Meta)**
+- Alternative : Twilio (plus simple mais coûts + dépendances)
+
+## 14.6 IA / Document generation
+
+- Génération texte : via LLM (prompts + garde-fous)
+- Génération PDF : HTML → PDF (Playwright) ou ReportLab
+- Génération PPTX : PptxGenJS (templates) ou python-pptx
+- Logos : au MVP, générer **logo basique** (icône + typographie) ou proposer 3 styles (pas de promesse “brand pro”)
+
+---
+
+# 15. CHARTE GRAPHIQUE – DESIGN SYSTEM PROPOSÉ
+
+Objectif : créer une identité visuelle moderne, crédible, inclusive et technologique, adaptée au secteur informel africain mais suffisamment institutionnelle pour parler à des bailleurs et partenaires.
+
+## 15.1 Positionnement visuel
+
+Le design doit transmettre :
+
+- Inclusion
+- Modernité
+- Technologie accessible
+- Confiance financière
+- Éducation structurée
+
+Le style est :
+
+- Mobile-first
+- Clair et lisible
+- Peu chargé
+- Orienté impact
+
+---
+
+## 15.2 Palette Couleurs (proposition stratégique)
+
+### 🎯 Couleur primaire – Vert Structuration
+
+`#1C7C54`
+
+Signification : croissance, stabilité, transformation progressive. Utilisation : boutons principaux, titres, éléments forts, KPI.
+
+---
+
+### 🎯 Couleur secondaire – Bleu Profondeur
+
+`#1B3A57`
+
+Signification : crédibilité, sérieux institutionnel, tech. Utilisation : header, footer, dashboard admin, slide de couverture.
+
+---
+
+### 🎯 Accent – Orange Activation
+
+`#F4A261`
+
+Signification : énergie, entrepreneuriat, action. Utilisation : CTA, highlights, icônes actives, progression.
+
+---
+
+### 🎯 Gris neutres
+
+- Gris clair fond : `#F5F7F9`
+- Gris texte secondaire : `#6B7280`
+- Noir texte principal : `#111827`
+
+---
+
+## 15.3 Typographie
+
+### Titres
+
+**Montserrat Bold / SemiBold**
+
+- Moderne
+- Lisible
+- Impact visuel fort
+
+### Texte courant
+
+**Inter / Poppins Regular**
+
+- Optimisé mobile
+- Lecture fluide
+- Compatible PDF & PPT
+
+Fallback system :
+
+- Arial / Helvetica
+
+---
+
+## 15.4 Tokens Design (à utiliser dans le code)
+
+```ts
+export const theme = {
+  colors: {
+    primary: '#1C7C54',
+    secondary: '#1B3A57',
+    accent: '#F4A261',
+    background: '#F5F7F9',
+    textPrimary: '#111827',
+    textSecondary: '#6B7280'
+  },
+  radius: {
+    card: '12px',
+    button: '8px'
+  },
+  shadow: {
+    soft: '0 4px 12px rgba(0,0,0,0.08)'
+  }
+}
+```
+
+---
+
+## 15.5 UI Components Standards
+
+### Boutons
+
+- Primary : fond vert `#1C7C54`, texte blanc
+- Secondary : fond bleu `#1B3A57`, texte blanc
+- Accent : fond orange `#F4A261`, texte noir
+
+Hover : légère augmentation luminosité + shadow soft.
+
+---
+
+### Cards
+
+- Fond blanc
+- Border radius 12px
+- Ombre douce
+- Padding généreux (16–24px)
+
+---
+
+### Dashboard Admin
+
+- Sidebar bleu foncé
+- KPI cards vertes
+- Alerts orange
+- Graphiques simples (bar / line)
+
+---
+
+## 15.6 Style Documents Générés (PDF / PPT)
+
+One-pager :
+
+- Header bleu profond
+- Titres verts
+- Accent orange pour chiffres clés
+- Icônes simples outline
+
+Pitch deck :
+
+- Slide couverture : fond bleu + titre blanc
+- Slides contenu : fond blanc + titres verts
+- Graphiques en vert + orange
+
+---
+
+## 15.7 Ton visuel global
+
+Pas trop “startup Silicon Valley”. Pas trop “ONG traditionnelle”.
+
+→ Tech africaine inclusive. → Sérieuse mais accessible.
+
+---
+
+# 16. WHATSAPP LEARNING TRACK – COMMENT LE CODER
+
+WHATSAPP LEARNING TRACK – COMMENT LE CODER
+
+## 16.1 Logique pédagogique
+
+- Track = 7 ou 14 jours
+- Chaque jour :
+  - 1 audio (1–3 min)
+  - 1 visuel (option)
+  - 1 exercice (réponse texte/voice)
+  - 1 validation (mot-clé “OK”, “SUIVANT”, bouton)
+
+## 16.2 Parcours utilisateur
+
+1. L’utilisateur envoie “INSCRIPTION”
+2. Le bot demande : prénom, activité, ville, langue
+3. Inscription au Track
+4. Envoi Jour 1
+5. Sauvegarde réponses + progression
+6. Relance automatique si inactif (J+1)
+7. Checkpoints (J7/J14) : mini pitch + données business
+
+## 16.3 Modèle de données (minimum viable)
+
+Tables :
+
+- `users(id, phone, name, language, city, created_at)`
+- `tracks(id, name, duration_days, language)`
+- `track_days(id, track_id, day_number, content_type, content_url, prompt_text)`
+- `enrollments(id, user_id, track_id, status, current_day, started_at, completed_at)`
+- `responses(id, enrollment_id, day_number, text, media_url, created_at)`
+- `messages(id, user_id, channel, direction, payload_json, created_at)`
+
+## 16.4 Endpoints API (exemple)
+
+- `POST /webhooks/whatsapp` : réception messages
+- `POST /enroll` : créer inscription
+- `POST /send/day` : envoyer contenu du jour N
+- `GET /admin/metrics` : stats
+
+## 16.5 Exemple (Node/TS) – Webhook WhatsApp (simplifié)
+
+```ts
+import Fastify from 'fastify'
+
+const app = Fastify()
+
+app.post('/webhooks/whatsapp', async (req, reply) => {
+  const payload: any = req.body
+  // 1) extraire phone + message
+  const phone = payload?.entry?.[0]?.changes?.[0]?.value?.messages?.[0]?.from
+  const text = payload?.entry?.[0]?.changes?.[0]?.value?.messages?.[0]?.text?.body?.trim()?.toUpperCase()
+
+  if (!phone) return reply.code(200).send({ ok: true })
+
+  // 2) router simple
+  if (text === 'INSCRIPTION') {
+    // TODO: créer user + enrollment
+    // TODO: répondre avec questions profil
+  }
+
+  // TODO: progression track
+  return reply.code(200).send({ ok: true })
+})
+
+app.listen({ port: 3000, host: '0.0.0.0' })
+```
+
+---
+
+# 17. IA – GÉNÉRATION PITCH / ONE-PAGER / DECK
+
+## 17.1 Par quoi commencer (recommandation)
+
+1. **Pitch (30s + 2min)**
+2. **One-pager PDF (1 page)** ➡️ Ensuite seulement : Pitch deck PPTX
+
+## 17.2 Inputs (collectés via WhatsApp + formulaire web)
+
+- Activité
+- Client cible
+- Problème
+- Solution
+- Prix / revenus
+- Coûts principaux
+- Preuves (photos, témoignages, traction)
+- Besoin (montant, équipement, stock)
+
+## 17.3 Sorties (MVP)
+
+- Pitch 30 secondes (wolof/fr)
+- Pitch 2 minutes (wolof/fr)
+- One-pager PDF : 6 blocs (problème, solution, marché, modèle, traction, besoin)
+
+## 17.4 Templates & garde-fous
+
+- Templates de contenu (structure fixe)
+- Pas de promesses irréalistes
+- Toujours demander 1 preuve (même simple)
+- Mentionner types de financement informel (microcrédit, crédit équipement, etc.)
+
+## 17.5 Exemple (pseudo-code) – endpoint docgen
+
+```ts
+app.post('/ai/onepager', async (req, reply) => {
+  const input = req.body // validated
+  // 1) appeler modèle texte → sections
+  const sections = await generateSectionsWithLLM(input)
+  // 2) rendre HTML template
+  const html = renderOnePagerHTML(sections)
+  // 3) convertir en PDF
+  const pdfUrl = await htmlToPdfAndUpload(html)
+  return reply.send({ pdfUrl })
+})
+```
+
+---
+
+---
+
+## 17.6 AI SLIDES ENGINE – VERSION “GENSPARK-LIKE”
+
+Objectif : ne pas seulement générer du texte, mais produire un **pitch deck complet, designé, prêt à envoyer (PPTX/PDF)** avec :
+
+- Couleurs appliquées automatiquement (charte interne)
+- Icônes cohérentes
+- Hiérarchie visuelle
+- Mise en page intelligente
+
+### Architecture recommandée
+
+Le système ne repose pas uniquement sur un prompt texte. Il repose sur 3 couches :
+
+### 1️⃣ LLM → Structure JSON avancée
+
+Le modèle doit produire une structure riche, par exemple :
+
+```json
+[
+  {
+    "type": "cover",
+    "title": "Nom du projet",
+    "subtitle": "Pitch court",
+    "themeVariant": "primary"
+  },
+  {
+    "type": "problem",
+    "title": "Problème",
+    "bullets": ["...", "..."],
+    "icon": "alert-circle",
+    "highlightStat": "80% des clients..."
+  }
+]
+```
+
+Le LLM ne génère pas seulement du texte. Il génère une **intention de layout**.
+
+---
+
+### 2️⃣ Slide Renderer Engine
+
+Un moteur interne transforme cette structure en slides réelles :
+
+- Mapping automatique des types (`cover`, `problem`, `solution`, `market`, etc.)
+- Application des couleurs selon le `themeVariant`
+- Injection des icônes (Lucide / Heroicons / custom SVG)
+- Placement automatique des blocs (grille 2 colonnes, full width, etc.)
+
+Avec **PptxGenJS** :
+
+- Création slide
+- Ajout titre
+- Ajout shape colorée
+- Ajout icône SVG
+- Ajout bullets stylisées
+
+---
+
+### 3️⃣ Design System Binding
+
+Le moteur doit utiliser les tokens définis section 15 :
+
+- Primary → #1C7C54
+- Secondary → #1B3A57
+- Accent → #F4A261
+
+Chaque type de slide a une règle :
+
+- Cover → fond bleu profond
+- Problem → bande accent orange
+- Solution → titre vert
+- Financial → chiffres en accent
+
+Ainsi, le rendu est cohérent automatiquement.
+
+---
+
+### 4️⃣ Auto-Layout Rules
+
+Le moteur doit :
+
+- Limiter à 5 bullets max
+- Couper les phrases trop longues
+- Ajuster taille police selon longueur
+- Éviter slide surchargée
+
+Ce n’est pas seulement du texte. C’est une logique produit.
+
+---
+
+### 5️⃣ Pipeline complet
+
+1. Collect inputs utilisateur
+2. Générer JSON structuré via LLM
+3. Valider JSON (Zod schema)
+4. Mapper vers template engine
+5. Générer PPTX
+6. Stocker fichier (S3)
+7. Retourner lien WhatsApp
+
+---
+
+### Important
+
+Pour obtenir un résultat niveau Genspark :
+
+- Toujours utiliser output JSON structuré (pas texte libre)
+- Toujours passer par un renderer interne
+- Toujours appliquer un design system cohérent
+
+Le rendu final doit être :
+
+"Document prêt à envoyer à un financeur"
+
+et non
+
+"Texte copié-collé dans PowerPoint"
+
+---
+
+# 18. ADMIN DASHBOARD (IGNITE.E / ÉQUIPE)
+
+Fonctionnalités admin MVP :
+
+- Liste des inscrits (WhatsApp)
+- Progression par track
+- Taux de complétion J1/J7/J14
+- Export CSV
+- Gestion des contenus (track\_days)
+- Gestion des cohortes présentiel
+- Paiements (V1)
+
+---
+
+# 19. SÉCURITÉ, DONNÉES & CONFORMITÉ
+
+- Consentement explicite à l’inscription (WhatsApp) : utilisation pédagogique + données anonymisées
+- Pseudonymisation : séparer identité (phone) des analytics
+- Stockage chiffré des médias (si possible)
+- Règles d’accès : admin role-based
+- Journalisation (logs) + monitoring
+
+---
+
+# 20. PLAN D’EXÉCUTION (PHASÉ)
+
+## Phase 0 – Préparation (1 semaine)
+
+- Finaliser 2 tracks (Business Model 7j + Pitch 7j)
+- Écrire scripts audios wolof + exercices
+- Définir templates one-pager
+
+## Phase 1 – MVP WhatsApp Track (2–3 semaines)
+
+- Webhook WhatsApp + parsing
+- Enrollment + progression
+- Scheduling envoi jour N
+- Dashboard metrics minimal
+- Pilote 50–100 utilisateurs
+
+## Phase 2 – IA v0 (2–3 semaines)
+
+- Collect inputs
+- Générer pitch + one-pager PDF
+- Retour WhatsApp (lien)
+
+## Phase 3 – V1 (4–8 semaines)
+
+- Paiement cohorte présentiel
+- Pitch deck PPTX
+- Auto-évaluation (scoring pédagogique)
+
+---
+
+# 21. LISTE DES FONCTIONNALITÉS (CHECKLIST)
+
+## Apprenants
+
+- Inscription WhatsApp
+- Parcours 7/14 jours
+- Exercices + feedback
+- Documents générés (liens)
+
+## Admin
+
+- Gestion contenus
+- Stats complétion
+- Exports
+- Cohortes + paiements (V1)
+
+## IA
+
+- Pitch 30s / 2min
+- One-pager PDF
+- Pitch deck PPTX (V1)
+- Logo basique (V1/V2)
+
+---
+
+# 22. NOTES IMPORTANTES
+
+- Commencer simple : WhatsApp Track d’abord, puis IA.
+- Le “logo IA” est optionnel au MVP.
+- Mettre l’accent sur la qualité pédagogique + tracking.
+- Les documents générés doivent rester réalistes et adaptés au financement informel.
+

docs/plan_implementation_prod.md

@@ -0,0 +1,97 @@
+# Plan d'Implémentation Production
+*Priorité : du plus bloquant au moins urgent*
+
+---
+
+## Phase 1 — Déploiement Railway opérationnel (immediat)
+
+> Objectif : Railway répond, webhook Meta validé, premiers messages reçoivent une réponse.
+
+### Étape 1.1 — Variables Railway (manuel, 5 min)
+1. **Supprimer** `DISABLE_WHATSAPP_SEND`
+2. **Ajouter** `WHATSAPP_APP_SECRET` (Meta App → Basic Settings → App Secret)
+3. Vérifier que `API_URL` = `https://whatsapp-worker-production-0bc0.up.railway.app`
+
+### Étape 1.2 — Valider le webhook Meta (manuel, 2 min)
+1. Attendre fin du redéploiement Railway (logs : `Server listening on http://0.0.0.0:3001`)
+2. Tester : `curl https://whatsapp-worker-production-0bc0.up.railway.app/` → `{"ok":true}`
+3. Meta Developers → WhatsApp → Configuration → Webhook → Retenter la validation
+
+### Étape 1.3 — Créer le contenu pédagogique (base de données)
+Le flow complet nécessite au moins **1 Track avec 3+ TrackDays**. À insérer via l'endpoint seed existant (`SEED_DATA`) ou directement en base :
+- Envoyer `SEED_DATA` depuis WhatsApp (déclencheur existant dans `whatsapp.ts`)
+
+---
+
+## Phase 2 — Corriger les bugs d'interface (1-2 jours)
+
+### Étape 2.1 — Fix Admin App : champ `whatsappId` → `phone`
+**Fichier** : `apps/admin/src/App.tsx` lignes 164, 237
+
+```diff
+- env.user?.whatsappId || 'Unknown'
++ env.user?.phone || 'Unknown'
+```
+
+### Étape 2.2 — Fix Web App : portail étudiant factice
+**Fichier** : `apps/web/src/App.tsx` — fonction `handleLogin`
+
+Implémenter l'authentification réelle :
+- Appel API avec le numéro de téléphone
+- Retour des documents générés (OnePager, PitchDeck) via liens R2
+
+### Étape 2.3 — Page de succès Stripe
+Créer une page `/payment/success` dans `apps/web` qui :
+- Confirme le paiement à l'utilisateur
+- Affiche un lien vers WhatsApp pour commencer
+
+---
+
+## Phase 3 — Gestion de contenu admin (3-5 jours)
+
+### Étape 3.1 — API backend : routes Track/TrackDay
+**Fichier** : `apps/api/src/routes/admin.ts`
+
+Ajouter :
+```typescript
+POST /v1/admin/tracks          // Créer un track
+PUT  /v1/admin/tracks/:id      // Modifier
+POST /v1/admin/tracks/:id/days // Ajouter un TrackDay
+PUT  /v1/admin/tracks/:id/days/:dayId
+DELETE /v1/admin/tracks/:id
+```
+
+### Étape 3.2 — Interface admin : Content Manager
+**Fichier** : `apps/admin/src/App.tsx`
+
+Ajouter une vue "Content" dans le sidebar :
+- Liste des Tracks avec bouton Créer/Modifier
+- Pour chaque Track : liste des jours avec éditeur de texte + upload audio
+
+---
+
+## Phase 4 — Améliorations qualité (optionnel)
+
+### Étape 4.1 — Unifier Enrollment / UserProgress
+Les deux tables doublonnent `currentDay`. Migrer vers `UserProgress` uniquement et retirer `currentDay` de `Enrollment`.
+
+### Étape 4.2 — Logger les messages entrants (modèle Message)
+Le modèle `Message` en base n'est jamais rempli. Ajouter un `prisma.message.create()` dans `handleIncomingMessage`.
+
+### Étape 4.3 — Scheduler : vérification état avant envoi
+Dans `scheduler.ts`, avant d'envoyer la leçon du jour, vérifier que l'enrollment est `ACTIVE` et que le `currentDay` correspond.
+
+### Étape 4.4 — Variables VITE_API_URL dans les apps frontend
+S'assurer que `VITE_API_URL` est configuré dans les `.env` de production de `apps/admin` et `apps/web`.
+
+---
+
+## Résumé des priorités
+
+```
+✅ FAIT        → API + Worker Railway, todos les bugs WhatsApp fixés
+🔴 CRITIQUE    → Supprimer DISABLE_WHATSAPP_SEND, ajouter WHATSAPP_APP_SECRET
+🟠 IMPORTANT   → Valider webhook Meta, créer contenu (SEED_DATA)
+🟡 SOON        → Fix admin phone field, portail étudiant réel
+🟢 OPTIONNEL   → Stripe live, content manager admin, Message logging
+```