# Audit de la Dette Technique — Infrastructure PaaS (v3.0)

**Dernière Mise à Jour** : 25 Avril 2026
**Statut global** : 🏗️ Transition PaaS (Architecture Stable, Optimisations Requises)

## 🚦 Résumé des Risques Actuels

| Priorité | Sujet | État | Impact |
| :--- | :--- | :--- | :--- |
| 🔴 **Critique** | Performance du Bridge (Requêtes Prisma) | ⚠️ À RISQUE | Latence accrue à chaque message reçu |
| 🟠 **Haute** | Duplication d'Extraction WhatsApp | 🔄 DUPLIQUÉ | Risque d'incohérence entre Gateway et Worker |
| 🟠 **Haute** | Résilience des Webhooks Clients | ❌ MANQUANT | Perte de messages si le client est offline |
| 🟡 **Moyenne** | Validation JSON FlowConfig | ✅ **FIXED** | Sécurisé côté API, à renforcer côté Worker |
| 🟡 **Moyenne** | Gestion des Secrets (Shared Keys) | 🔐 STATIQUE | Risque de compromission sur le long terme |

---

## 1. Performance & Évolutivité (Scalability)
- **Problème** : Chaque message entrant dans le bridge du Worker (`index.ts`) déclenche une requête SQL synchrone pour récupérer le `mode` de l'organisation.
- **Risque** : Saturation de la pool de connexions Prisma lors de pics de trafic.
- **Action requise** : Implémenter un cache Redis pour les métadonnées des organisations (TTL: 1h).
- **Statut** : ⚠️ À surveiller.

## 2. Maintenabilité : Duplication de Logique
- **Problème** : La logique d'extraction du `phone` et du `text` depuis le payload Meta est copiée entre `apps/api` et `apps/whatsapp-worker`.
- **Risque** : Un changement dans l'API WhatsApp (ex: nouveau type de bouton) doit être reporté à deux endroits, multipliant les chances d'erreur.
- **Action requise** : Créer un helper `extractWhatsAppPayload` dans `packages/shared-types` ou un nouveau package `@repo/whatsapp-utils`.
- **Statut** : 🔄 Dette active.

## 3. Fiabilité des Webhooks (Phase 2)
- **Problème** : Le routage vers les clients externes en mode `WEBHOOK` utilise un simple `fetch` avec un log d'erreur en cas d'échec.
- **Risque** : Aucun mécanisme de retry (tentatives de renvoi). Si le serveur du client redémarre, le message est définitivement perdu.
- **Action requise** : Utiliser une file d'attente BullMQ dédiée (`webhook-retry-queue`) pour garantir la livraison avec exponential backoff.
- **Statut** : ❌ Manquant.

## 4. Intégrité des Données (Zod)
- **Problème** : Le Worker lit le champ `flowConfig` (JSON) et le parse sans re-validation.
- **Risque** : Si un administrateur injecte un JSON corrompu via un script direct (hors API), le Worker peut crasher en tentant de lire des propriétés inexistantes.
- **Action effectuée** : ✅ Validation Zod ajoutée sur la route `PUT /organizations`.
- **Action restante** : Re-valider le schéma lors de la lecture dans `OnboardingHandler.ts`.
- **Statut** : 🟡 Partiellement résolu.

## 5. Intelligence Artificielle (RAG)
- **Problème** : Le champ `knowledgeBaseUrl` n'est qu'un lien vers un fichier. L'`AIAgentHandler` simule l'injection.
- **Risque** : Pour des fichiers volumineux (> 10 pages), l'injection directe dans le prompt va exploser les limites de tokens et les coûts.
- **Action requise** : Implémenter une pipeline d'indexation vectorielle (Vector DB) pour les clients en mode `AI_AGENT`.
- **Statut** : 🏗️ En cours de conception.

---

## 📅 Historique des Corrections (v2.x)
- ✅ **[FIXED]** Sécurisation du bridge interne via `ADMIN_API_KEY`.
- ✅ **[FIXED]** Dé-hardcodage des secteurs EdTech.
- ✅ **[FIXED]** Isolation des tenants via `runWithTenant` (Context API).
- ✅ **[FIXED]** Centralisation des logs Pino.