# CoreDeskAI — Document d'architecture (ébauche pour validation)

> **Statut : ÉBAUCHE — à valider ensemble.** · **Auteur : Hamdi** (avec l'aide de Claude) · **Date : 2026-06-16**
> **Objet :** poser le *socle* technique (workflow, architecture du code sur Git, API, choix
> structurants) afin de stabiliser une version viable, en revoir la robustesse, et orienter la suite
> des travaux.
>
> _Note de lecture : la narration est en français ; les **tableaux de code** (noms de modules, routes
> d'API, identifiants techniques) restent en anglais pour coller exactement aux identifiants du dépôt._

---

## 0. Comment lire ce document

Ce document décrit **ce qui existe aujourd'hui** (l'état réel du code), pas une cible idéale. Les
sections sont :

1. Vue d'ensemble du produit — §1
2. Architecture en plans (modèle mental) — §2
3. **Le workflow** : parcours d'un message / d'un appel de bout en bout — §3
4. **L'architecture du code sur Git** : monorepo, responsabilités par dossier — §4
5. **Les API** : routes HTTP + conventions des fonctions Convex — §5
6. Le modèle de données — §6
7. **Les choix structurants** faits jusqu'à présent (avec justification) — §7
8. Sécurité & gouvernance — §8
9. **Robustesse & stabilisation** (la demande explicite : version viable) — §9
10. État actuel & blocages — §10
11. Points à valider ensemble & suite proposée — §11

Documents compagnons (**documents de travail internes, hors de ce dépôt** — disponibles sur demande) :
`COREDESKAI.md` (contexte complet), `COREDESKAI-TASKS.md` (backlog), `COREDESKAI-MCP-ARCHITECTURE.md`
(plan d'intégration / outils), `COREDESKAI-SELECTIVE-RAG-DESIGN.md` (RAG), `LIVEKIT_VOICE_MIGRATION.md` +
`LIVEKIT_VOICE_TOOL_CONTRACT.md` (voix). Les autres noms de fichiers entre backticks dans ce document
désignent ces mêmes documents internes.

---

## 1. Vue d'ensemble du produit

CoreDeskAI est une **plateforme multi-tenant d'automatisation du support client et de la voix sortante**.
Chaque organisation dispose :

- de **conversations omni-canal** — widget web, voix (téléphone), Telegram, WhatsApp (texte), et (différé)
  Instagram / Messenger / WhatsApp Cloud ;
- d'un **agent IA configurable** — ton, langues, instructions, règles d'escalade / repli / hors-périmètre,
  personas par rôle et modèles d'agent prédéfinis ;
- de **workflows** — automatisations multi-étapes (appel d'outils HTTP ou Convex, confirmation humaine,
  branchements, collecte d'entités, journalisation) ;
- d'une **base de connaissances** (KB) — ingestion de fichiers + récupération sélective vectorielle (RAG) ;
- de **campagnes de voix sortante** — appel d'une liste de contacts, script de qualification, extraction
  des réponses, écriture en retour vers la source ;
- d'une couche de **gouvernance / ops** — politiques d'approbation, quotas, journaux d'exécution,
  rapports d'évaluation, marketplace d'outils.

**Principe de bout en bout :** message client → extraction de contexte/sécurité → (workflow / KB / chat
agent) → fil de conversation persisté + journaux.

Multi-tenancy : presque chaque ligne de données est clé par `organizationId`.

---

## 2. Architecture en plans (modèle mental)

L'architecture se raisonne en **six plans**. Ce découpage est le fil conducteur de la modularité.

```
   ┌──────────────────────────────────────────────────────────────────────┐
   │  CANAUX     widget · téléphone · Telegram · WhatsApp · (Meta différé)  │
   └───────────────────────────────┬──────────────────────────────────────┘
                                    ▼
   ┌──────────────────────────────────────────────────────────────────────┐
   │  ORCHESTRATION   messageProcessor (chat/voix)  +  state machine        │
   │                  (sélection workflow, routage récupération)            │
   └───────────────┬───────────────────────────────┬──────────────────────┘
                   ▼                                 ▼
   ┌───────────────────────────┐     ┌──────────────────────────────────────┐
   │  CONNAISSANCE (KB / RAG)   │     │  INTÉGRATION (outils read/write/admin) │
   │  Voyage + @convex-dev/rag  │     │  CData/MCP · HTTP custom · ConvexDB     │
   └───────────────────────────┘     └──────────────────────┬───────────────┘
                                                             ▼
   ┌──────────────────────────────────────────────────────────────────────┐
   │  GOUVERNANCE   authz · politiques · approbations · quotas · audit      │
   ├──────────────────────────────────────────────────────────────────────┤
   │  OBSERVABILITÉ   logs par étape · métriques d'appel · system_events    │
   └──────────────────────────────────────────────────────────────────────┘
```

| Plan | Rôle | Primitives existantes |
|---|---|---|
| **Canal** | Entrée/sortie des messages par canal | `lib/*ChannelAdapter.ts`, `system/incomingMessage.ts`, `system/channelMessaging.ts` |
| **Orchestration** | Transformer un message en réponse / piloter un workflow | `system/messageProcessor.ts`, `orchestration/pipeline.ts`, `lib/actionExecutor/` |
| **Intégration** | Appeler des systèmes externes (lecture/écriture) | `lib/mcpClient.ts`, `lib/customApiToolExecutor.ts`, `system/convexTools.ts` |
| **Connaissance** | Récupération ancrée (RAG) | `system/ai/rag.ts`, `system/ai/selectiveRag.ts`, `system/fileChunks.ts` |
| **Gouvernance** | Autorisation, politiques, approbations, quotas | `lib/auth.ts`, `lib/policyEngine.ts`, `humanInTheLoop.ts`, `system/quotas.ts` |
| **Observabilité** | Journaux, métriques, événements d'évaluation | `system/executionLogger.ts`, `evaluation/`, `system_events` |

> **Pourquoi ce découpage compte pour le boss :** la modularité demandée se traduit ici — chaque plan a
> ses modules dédiés, ce qui permet de remplacer un composant (ex. : moteur de voix, moteur de sync)
> sans toucher aux autres. C'est exactement ce qui a permis le remplacement Vapi → Telnyx → LiveKit
> sans réécrire l'orchestration.

---

## 3. Le workflow — parcours de bout en bout

### 3.1 Parcours d'un message texte (widget / Telegram / WhatsApp)

```
Client ──message──► Adaptateur de canal ──► /webhooks/* (HTTP) ──► incomingMessage
                                                                        │
                                                                        ▼
                                                   system/messageProcessor.processMessage
   1. Charger widgetSettings (persona, règles)
   2. processMessage (actions/) → contexte sémantique
        (texte normalisé, langue, intention+confiance, entités, manquants, métadonnées)
   3. Garde "organisation suspendue"  → coupe l'IA, réponse type
   4. Garde quota                     → pas de crédits, réponse type
   5. Intercept escalade              → marque la conversation, réponse courte
   6. Matching workflow (agentWorkflows) ─oui─► moteur de workflow (state machine) ──┐
        │ non                                                                         │
        ▼                                                                             │
   7. Récupération sélective (decideRetrieval)                                        │
        ├─ conversationnel  → pas de récupération → agent                            │
        ├─ donnée live      → outil (CData/MCP/HTTP)                                  │
        └─ sinon            → KB d'abord (searchKnowledge = RAG vectoriel + seuil)    │
   8. Formulation de la réponse (modèle org, ou Mistral pour FR/AR, sinon Groq)       │
   9. Persistance conversations/messages + journaux  ◄──────────────────────────────┘
```

Modules clés : `system/messageProcessor.ts` (chef d'orchestre), `actions/processMessage.ts` (moteur de
contexte, action Node), `system/ai/selectiveRag.ts` (décision + récupération), `lib/actionExecutor/`
(moteur de workflow).

> ⚠️ **Point de robustesse n°1 (à arbitrer) :** il existe **deux logiques de sélection de workflow
> parallèles** — `messageProcessor` (chemin chat/voix live) et `orchestration/pipeline.ts` (chemin
> « pipeline test »). Elles se recouvrent sans être identiques → **risque de divergence**. Le contrat de
> workflow versionné (cf. §11) doit les **unifier**.

### 3.2 Parcours d'un workflow (state machine)

`lib/actionExecutor/` exécute un workflow comme une machine à états ; pour **chaque étape** :

1. **Validation** de l'entrée de l'étape.
2. **Garde de confirmation** — si `requiresConfirmation` et non approuvé → crée `pendingConfirmations`
   (human-in-the-loop), met en pause.
3. **Politique** (`lib/policyEngine.ts`) → `block` | `require_approval` | `auto_approve`.
4. **Quota** (`system/quotas.ts`).
5. **Dispatch** par type d'outil : `ConvexDB:*` → `convexTools` ; `SendMessage` → inline ; sinon
   résolution d'un *custom API tool* → `CustomApiToolExecutor`.
6. **Normalisation** du résultat (enveloppe lisible).
7. **Persistance + log** (`addStepToHistory` avec `inputHash` pour cache/replay, `executionLogger`).
8. **Retry** si `onFailure==="retry"` et `retryCount < maxRetries`.

### 3.3 Parcours voix (cible LiveKit + état actuel bridge)

**Cible verrouillée (2026-06-09) :** le modèle *speech-to-speech* temps réel devient le **cerveau** ;
Convex se **rétrograde en couche d'outils + conformité + persistance**.

```
Appelant ⇄ Telnyx (SIP) ⇄ LiveKit Cloud (EU) ⇄ Worker Python (agent)
                                                     │   modèle temps réel = Azure gpt-realtime (Sweden)
                                                     │
                                  appels d'outils ───┼──► Convex (le contrat /voice/*)
   • POST /voice/session         (bootstrap : gardes, persona, manifeste d'outils)
   • POST /voice/tools/search_knowledge | lookup_data | run_workflow | escalate | record_answer
   • POST /voice/persist          (puits idempotent : conversations/messages + eval)
```

- **Aujourd'hui (transitoire) :** un *media bridge* custom (`services/voice-bridge`, Fly/Paris) fait
  STT (Voxtral) → `/voice/turn` (orchestration complète) → TTS (Supertonic). Lent sur le chemin profond
  (~10–30 s/tour). Conservé comme **plan de reprise (DR)**.
- **Demain (cible) :** LiveKit + Azure `gpt-realtime` (un seul aller-retour modèle) pour viser
  l'objectif **600–800 ms** conversationnel.
- **🔴 Blocage actuel :** quota `gpt-realtime` Azure = 0 dans toutes les régions → demande d'augmentation
  de quota soumise (en attente d'info société/facturation, côté boss). Le formulaire a été soumis hier.

---

## 4. L'architecture du code sur Git (monorepo)

**Outils :** pnpm + Turborepo (`turbo dev`, `turbo build`). Origine GitLab
(`gitlab.com/Fakhreddine/coredeskai`). Branche de production : `prod-branch` / `main`.

```
coredeskai/
├── apps/
│   ├── web/        # Dashboard Next.js (Clerk, client Convex, /admin, settings)
│   ├── widget/     # Widget de chat embarquable (chat seul)
│   └── embed/      # Packaging d'embed additionnel
├── packages/
│   ├── backend/    # ★ Backend Convex — schéma, fonctions, HTTP, cron (cœur métier)
│   ├── ui/         # Composants UI partagés (design system)
│   ├── eslint-config/
│   └── typescript-config/
├── services/
│   ├── voice-livekit/   # Worker agent LiveKit (Python) — cible voix
│   ├── voice-bridge/    # Media bridge Voxtral/Supertonic (Python) — DR voix
│   └── whatsapp-baileys/# Canal WhatsApp texte non-officiel (Baileys)
└── (turbo.json, pnpm-workspace.yaml, tsconfig.json, …)
```

**Cible de déploiement :** backend Convex (EU Irlande) + web sur Vercel (région Paris `cdg1`).

### 4.1 Anatomie du backend Convex (`packages/backend/convex/`)

C'est le **cœur** : source de vérité des données et de la majeure partie de la logique métier. Le
découpage par **convention de visibilité** est la clé de la modularité et de la sécurité.

| Dossier | Rôle | Exemples |
|---|---|---|
| `public/` | Fonctions Convex **appelées par les clients** (web/widget) | `conversations.ts`, `widgetSettings.ts`, `customApiTools.ts`, `billing.ts` |
| `private/` | Fonctions **internes** (jamais exposées au client) | `files.ts`, `rekeyOrg.ts`, `migrations.ts`, `toolTesting.ts` |
| `system/` | **Orchestration + logique métier** | `messageProcessor.ts`, `outboundCalls.ts`, `voiceTools.ts`, `quotas.ts` |
| `system/ai/` | Stack IA (modèles, RAG, prompts, outils) | `selectiveRag.ts`, `rag.ts`, `resolveChatModel.ts`, `agents/`, `tools/` |
| `lib/` | Briques réutilisables (pas des fonctions Convex) | `auth.ts`, `policyEngine.ts`, `mcpClient.ts`, `actionExecutor/`, `*ChannelAdapter.ts` |
| `actions/` | Actions Node (calculs lourds, appels externes) | `processMessage.ts` (moteur de contexte) |
| `orchestration/` | Chemin « pipeline test » | `pipeline.ts` |
| `admin/` | Dashboard plateforme (vendeur) | `dashboard.ts`, `management.ts`, `billing.ts`, `featureFlags.ts` |
| `evaluation/` | Moteur d'évaluation + rapports | (moteur, rapports, alertes) |
| `queries/` `mutations/` | Helpers de lecture/écriture | — |
| `http.ts` | **Routeur HTTP** (webhooks + voix + eval) — cf. §5 | — |
| `schema.ts` | **Schéma de données** (toutes les tables) | — |
| `crons.ts` / `cronHandlers.ts` | Tâches planifiées | — |

> **Convention de sécurité fondamentale :** une fonction `public/*` doit dériver l'`organizationId` de
> la **session authentifiée**, jamais des arguments client. Le non-respect de cette règle est la cause
> du P0 BOLA/IDOR (cf. §8).

### 4.2 Frontend (`apps/web`)

- `app/` — routes Next.js : `(auth)`, `(dashboard)`, `admin`, `onboarding`, `api/`.
- `modules/` — fonctionnalités par domaine : `agent-builder`, `campaigns`, `files`, `integrations`,
  `marketplace`, `customization`, `call-history`, `outbound-outcomes`, `workflow-templates`, `admin`,
  `billing`, `calendar`, `i18n`, `auth`, `dashboard`, `tool-testing`.
- `app/api/*/route.ts` — quelques routes serveur Next (ex. OAuth Meta, debug d'exécution).

---

## 5. Les API

### 5.1 Surface HTTP (routeur Convex `http.ts`) — vérifiée dans le code

| Route | Méthode | Rôle | Auth |
|---|---|---|---|
| `/clerk-webhook` | POST | Sync abonnements / utilisateurs Clerk | Signature Clerk |
| `/webhooks/meta` | GET/POST | Messenger + Instagram (vérif + inbound) | `X-Hub-Signature-256` (HMAC) |
| `/webhooks/whatsapp` | GET/POST | WhatsApp Cloud (vérif + inbound) | verify token + HMAC |
| `/webhooks/whatsapp-openwa` | POST | Canal WhatsApp texte Baileys | secret partagé |
| `/webhooks/telegram` | POST | Inbound Telegram | `secret_token` |
| `/webhooks/telnyx` | POST | Événements d'appel Telnyx (bridge) | (signature Telnyx Ed25519, si `TELNYX_PUBLIC_KEY`) |
| `/webhooks/livekit` | POST | `room_finished` → chaînage de campagne | webhook LiveKit |
| `/voice/session` | POST | Bootstrap d'appel (gardes, persona, manifeste) | `x-voice-secret` (`VOICE_TOOL_SECRET`) |
| `/voice/tools/search_knowledge` | POST | Outil KB (RAG sélective) | idem |
| `/voice/tools/lookup_data` | POST | Outil de données (CData/HTTP par org) | idem |
| `/voice/tools/run_workflow` | POST | Lancer un workflow | idem |
| `/voice/tools/escalate` | POST | Escalade humaine | idem |
| `/voice/tools/record_answer` | POST | Enregistrer une réponse de campagne | idem |
| `/voice/persist` | POST | Persistance idempotente `(callId,turnIndex)` | idem |
| `/voice/turn` | POST | Orchestration voix complète (chemin profond, bridge) | `x-organization-id` (+ secret) |
| `/voice/llm` | POST | Chemin léger (LLM + naturalness, ~2,6 s) | idem |
| `/evaluation/events/log` | POST | Ingestion d'événements d'éval | secret d'ingestion |
| `/evaluation/feedback/log` | POST | Ingestion de feedback | secret |
| `/evaluation/reports/generate` | POST | Générer un rapport | token |
| `/evaluation/reports/latest` | GET | Dernier rapport | token |
| `/gmail/send` | POST | Envoi d'email (proxy Gmail) | secret proxy |

### 5.2 API « interne » Convex (queries / mutations / actions)

Au-delà du HTTP, le client web/widget appelle directement les fonctions **`public/*`** via le SDK
Convex (typé, temps réel). Conventions :

- **query** = lecture réactive · **mutation** = écriture transactionnelle · **action** = effets de bord /
  appels externes (Node).
- `public/*` = exposé au client (doit valider l'authz) · `private/*` = interne · `system/*` = orchestration
  (souvent `internalAction`/`internalMutation`).

### 5.3 APIs externes consommées

Groq (LLM), Mistral (LLM FR/AR), Voyage (embeddings + reranker), Azure OpenAI (`gpt-realtime`, cible voix),
Telnyx (téléphonie), LiveKit Cloud (média temps réel), Clerk (auth), CData (SQL-over-REST, abonnement
expiré), Meta Graph API (différé), Resend (email).

---

## 6. Le modèle de données (Convex `schema.ts`)

Tables groupées par domaine (clé `organizationId` quasi partout) :

| Domaine | Tables (exemples) |
|---|---|
| Tenancy / facturation | `subscriptions`, `orgQuotas`, `tokenUsageLogs` |
| Config widget & agent | `widgetSettings` (persona/rôle, greeting, design) |
| Secrets & plugins | `plugins`, `orgSecrets`, secret store (DB dev / AWS prod) |
| Intégrations | `customApiTools`, `llmConfigurations`, `phoneNumbers`, `socialChannels`, `cdataConnections` |
| Workflows | `agentWorkflows`, `workflowExecutions` (state machine + `stepHistory`), `pendingConfirmations` |
| Conversations | `contactSessions`, `conversations`, `messages` (contexte structuré), `conversationContexts` |
| Voix sortante | `outboundCampaigns`, `outboundCallAttempts` (+`answers`), `voiceMigrationConfigs`, `voiceCallChains`, `voiceTurnEvents` |
| Connaissance (KB) | `fileChunks` (+ `enabled`) + composant RAG (Voyage) |
| Observabilité | `toolExecutionLogs`, `executionLogs`, `system_events`, `feedback`, `evaluation_reports`, `evaluation_alerts` |
| Marketplace | `marketplaceTools`, `installedTools`, `toolReviews` |
| Données métier | `businessRecords`, `businessRecordConfig`, `convexTools` |
| Admin plateforme | `platformOrgState`, `platformFeatureFlags` |

---

## 7. Les choix structurants faits jusqu'à présent (avec justification)

| Choix | Décision | Justification / arbitrage |
|---|---|---|
| **Backend** | **Convex** (serverless, réactif, typé bout-en-bout) | Temps réel natif pour l'inbox, schéma + fonctions colocalisés, pas de gestion d'infra. |
| **Hébergement données** | **Convex EU Irlande** (`necessary-pheasant-631`) | Souveraineté GDPR (cas recrutement) ; supprime le saut transatlantique (latence voix). ⚠️ ~30 % plus cher que US. |
| **Auth** | **Clerk** (`fun-guppy-70`) + template JWT `convex` | Organisations multi-tenant prêtes à l'emploi ; intégration Convex documentée. |
| **Frontend** | **Next.js** (web + widget), Vercel région Paris | SSR proche du backend EU ; design system partagé `packages/ui`. |
| **LLM principal** | **Groq** (`llama-3.3-70b`, `llama-3.1-8b` pour l'interpréteur KB) | Latence très faible. |
| **LLM par défaut FR/AR** | **Mistral** (auto si pas de config org) | Meilleure qualité FR/AR ; **hiérarchie de langue : français = défaut**, AR + EN = langues secondaires. |
| **Embeddings / RAG** | **Voyage** (`voyage-3.5-lite`, 1024d) + `@convex-dev/rag` | RAG sélectif vectoriel au moment de la réponse ; `localSearch` (TF-IDF) en repli. |
| **RAG « sélectif »** | Décision *retrieve-or-not* + routage source + seuil + sélection doc/chunk + rerank (opt.) | Évite d'injecter du bruit ; ancrage sur le bon document. Rerank Voyage **par défaut OFF** (coût). |
| **Téléphonie** | **Telnyx** (SIP) ; **Ringover** pour DID FR (pilote recrutement) | Telnyx débloque BYOC/SIP ; +216 (Tunisie) bloqué côté opérateur (descoped). |
| **Runtime voix** | **LiveKit Agents + Azure `gpt-realtime`** (verrouillé 2026-06-09) | Speech-to-speech 1 aller-retour pour viser 600–800 ms ; EU-résident (Azure Sweden). OpenClaw **abandonné** ; bridge Voxtral/Supertonic conservé en **DR**. |
| **Sync de données (cible)** | **Airbyte** (ELT batch → namespace RAG) | 600+ connecteurs, EU self-hostable. ⚠️ batch seulement → la couche d'outils live read/write reste séparée. |
| **Outils / intégration** | 4 types : CData/MCP, custom HTTP, ConvexDB virtuel, SendMessage | Cible : contrat typé read/write/admin, IDs stables, enveloppe normalisée (repris par le nouveau collègue). |
| **Gouvernance** | Policy engine + human-in-the-loop + quotas + audit | Écritures = approbation requise par défaut (cible). |

> **Décisions abandonnées (historique, pour éviter de les rouvrir) :** Vapi (retiré), OpenClaw (abandonné
> au profit de LiveKit), Gemini Live via Vertex EU (cassé en multi-tour), swap STT/TTS Groq (supprimé car
> le modèle temps réel élimine les jambes STT/TTS séparées).

---

## 8. Sécurité & gouvernance

**Authz plateforme :** `lib/auth.ts` `requirePlatformAdmin` (allowlist `PLATFORM_ADMIN_USER_IDS` ou claim
JWT `role=platform_admin`). A fermé le P0 d'admin marketplace ouvert.

**P0 restants (NO-GO production tant que non corrigés) :**
1. ~~Identifiants CData en dur~~ — semble **déjà corrigé** (à reconfirmer).
2. **BOLA / IDOR** — plusieurs fonctions `public/*` font confiance à l'`organizationId` fourni par le
   client (`private/customApiTools`, `socialChannels`, `phoneNumbers`, `conversations.listByOrganization`,
   `widgetSettings.getByOrganizationId`). **C'est le point dur.**
3. ~~Mutations admin marketplace non protégées~~ — **fermé** 2026-06-04.
4. Liaison `state` / org faible sur le callback OAuth.
5. Routes HTTP d'écriture d'évaluation non authentifiées.

**Secrets :** dev = tokens dans `orgSecrets` (lisible en base) ; **prod = AWS Secrets Manager** (poser
`AWS_*`). Rotation des clés vers le compte société : en cours (cf. `KEY_ROTATION_CHECKLIST.md`).

---

## 9. Robustesse & stabilisation (vers une version viable)

_Section directement liée à la demande du boss. Voici ce qui sépare l'état actuel d'une **version viable
et robuste**, par ordre de priorité._

1. **Fermer le P0 BOLA/IDOR** (§8.2) — bloquant absolu avant tout client réel partageant des tokens.
2. **Unifier les deux moteurs de workflow** (`messageProcessor` vs `orchestration/pipeline`, §3.1) — via
   un **contrat de workflow versionné** ; sinon divergence chat ↔ pipeline.
3. **Contrat d'outils typé** (read/write/admin, IDs stables, enveloppe normalisée, idempotence,
   retry/backoff, taxonomie d'erreurs) — robustesse de la couche intégration (porté par le nouveau collègue).
4. **Secrets en AWS Secrets Manager** en prod (sortir de la base) + finir la rotation des clés.
5. **Observabilité de bout en bout** : aujourd'hui les décisions de récupération RAG sont loguées en
   **console**, pas dans `system_events` — prévoir un puits de télémétrie dédié pour le routage.
6. **Sécurité de facturation voix** : `time_limit_secs` + `safetyHangup` idempotent en place ; ⚠️ le bridge
   Fly **facture en continu tant qu'il tourne** (l'arrêter à l'arrêt). +216 facture des « false answers ».
7. **Tests** : socle de tests présent (`*.test.ts`, `vitest`) ; à étendre sur les chemins critiques
   (évaluateur de conditions, transitions, validation d'outils, isolation cross-org).
8. **Calibration RAG** : seuil 0.7 calibré sur petit corpus ; la bande s'effondre sur le cross-lingue dur
   (dialecte tunisien) → activer le rerank (après sortie du tier gratuit Voyage) + classifieur de routage.

---

## 10. État actuel & blocages

**Construit & déployé (EU dev) — souvent non commité sur `prod-branch` (règle de checkpoint) :**
Admin Dashboard (slices 1–2), RAG sélective (étapes 1, 2, 5 + curation de contenu ; étape 3 rerank OFF),
couche d'outils voix LiveKit + worker Python, dispatch sortant + chaînage de campagne LiveKit (commité
`4064adf`), canaux Telegram + WhatsApp texte, personas/templates/RTL/switcher de langue.

**Blocages actifs (les deux côté boss) :**
- 🔴 **Quota Azure `gpt-realtime` = 0** → formulaire d'augmentation **soumis hier**, en attente. Débloque
  tout le runtime voix LiveKit.
- 🔴 **Meta App Review** + prérequis (Business Verification, pages légales, env prod) → débloque le
  branchement client des canaux IG/Messenger/WhatsApp Cloud.

**Autres :** abonnement CData expiré (outils data en échec) ; widget Baileys non encore lié par QR.

---

## 11. Points à valider ensemble & suite proposée

**À valider avec le boss (arbitrages d'architecture) :**
- [ ] Le **socle en 6 plans** (§2) est-il le bon cadre de référence ?
- [ ] Priorité de stabilisation : **P0 BOLA/IDOR d'abord** (§9.1), avant nouvelles fonctionnalités ?
- [ ] **Unifier les deux moteurs de workflow** via un contrat versionné (§9.2) — accord sur l'effort ?
- [ ] Frontière **nouveau collègue** (outils live) / **Airbyte** (sync) / **Hamdi** (voix + RAG) confirmée ?
- [ ] Domaine de prod canonique (pour App Domains Meta + redirect URI).
- [ ] Acceptation du **risque mono-région** Azure Sweden (bridge = DR) pour le pilote voix.

**Suite proposée (une fois le socle validé) :**
1. Sécuriser : P0 BOLA/IDOR + secrets AWS.
2. Stabiliser le runtime : contrat de workflow versionné (unification) + contrat d'outils typé.
3. Débloquer voix (dès quota Azure) → test conversation → mesure latence vs 600–800 ms.
4. Débloquer Meta (App Review) en parallèle.
5. Étendre l'observabilité + les tests sur les chemins critiques.

---

_Fin de l'ébauche — document vivant, à amender lors de la session de validation._