# Améliorations récentes — Crypto Trading Bot
_Période couverte : 29 avril → 13 mai 2026_
_Fichiers principaux modifiés : `market_spy.py`, `ai_predictor.py`, `ai_opportunity_selector.py`, `api/routes.py`, `dashboard.html`_

---

## Sommaire

1. [Entrées — filtres et blocages renforcés](#1-entrées--filtres-et-blocages-renforcés)
2. [Sorties — trailing et exits anticipés](#2-sorties--trailing-et-exits-anticipés)
3. [Pipeline IA — Framework 7 Couches](#3-pipeline-ia--framework-7-couches)
4. [Dashboard — nouveaux indicateurs visuels](#4-dashboard--nouveaux-indicateurs-visuels)
5. [Infrastructure et réalisme testnet](#5-infrastructure-et-réalisme-testnet)
6. [Problèmes encore ouverts](#6-problèmes-encore-ouverts)

---

## 1. Entrées — filtres et blocages renforcés

### 1.1 Cas D — Flash bypass interdit si EMA baissière + slope négatif (13/05)
**Fichier** : `market_spy.py` · `is_entry_confirmed()` · ligne ~1769

**Problème** : CFG acheté alors que EMA7 déclinait ET que EMA7 < EMA25 (double signal baissier). La condition d'exception `is_strong_flash + surge ≥ 1.5% + buy_ratio ≥ 45%` permettait d'ignorer ce double signal.

**Correction** : Ajout de `and not ema_bearish_effective` dans l'exception du Cas D. Désormais, si EMA7 est à la fois en slope négatif **et** sous EMA25 structurellement, **aucun flash** ne justifie l'entrée.

```python
# Avant
elif ema7_declining and not _effective_extreme and not (is_strong_flash and surge_strength >= 1.5 and best_buy_ratio >= 0.45):

# Après
elif ema7_declining and not _effective_extreme and not (is_strong_flash and surge_strength >= 1.5 and best_buy_ratio >= 0.45 and not ema_bearish_effective):
```

---

### 1.2 EMA7 pré-spike et seuil de pente (03/05)
**Fichier** : `market_spy.py`

- EMA7/EMA25 calculés maintenant **sans la dernière bougie** (`closes[:-1]`) pour détecter l'état de tendance avant le spike et non pendant.
- Seuil de pente EMA7 abaissé de `-0.15%` à `-0.10%` pour détecter le déclin EMA7 plus tôt (Cas D).
- `ema_bearish_effective = ema_bearish_now OR ema_bearish_pre` — les dead cat bounces en pleine bougie de spike sont détectés.

---

### 1.3 ENTRY_FILTER 5 règles — seuil testnet assoupli (11/05)
**Fichier** : `market_spy.py`

Le filtre à 5 règles (surge_ok, ema7_ok, wick_ok, rsi_ok, volume_ok) bloque maintenant :
- **Production** : rejet si ≤ 3/5 règles validées
- **Testnet / HOTLIST / AI_OPP** : rejet si ≤ 2/5 règles (3 suffisent)

Les coins détectés par le Framework IA (score ≥ 55) bénéficient du même assouplissement que la hotlist.

---

### 1.4 Pression vendeuse élargie — seuil 35% → 45% buy_ratio (29/04)
**Fichier** : `market_spy.py`

`sell_pressure` déclenche si buy_ratio < 45% (était 35%). Exemple RAY : 37% buy_ratio passait à travers l'ancien seuil — désormais bloqué.

---

### 1.5 EXTREME_FLASH mèche de manipulation (29/04)
**Fichier** : `market_spy.py`

Un `EXTREME_FLASH` (≥ 3%) avec buy_ratio < 45% ET contexte EMA baissier est maintenant classé `_extreme_flash_is_wick = True` et perd son exemption. Seul un vrai EXTREME avec pression acheteuse réelle (`_effective_extreme`) reste autorisé. Cas déclencheur : RAY +5.75% en 7s avec 37% buy ratio → mèche vendeuse.

---

### 1.6 Volume suspect — nouveau listing (05/05)
**Fichier** : `market_spy.py`

Si `best_vol_ratio > 500x`, le coin est bloqué (artefact de premier listing, baseline ≈ 0, carnet vide). Exemple WUSDC vol=3434x sur première bougie → slippage sortie -1.45%.

---

### 1.7 Guard spread ask/bid pré-achat (05/05)
**Fichier** : `market_spy.py`

Avant d'envoyer l'ordre, le spread ask/bid est vérifié depuis le payload `bookTicker` déjà en mémoire (0 appel API supplémentaire). Blocage si spread > 0.8% (0.5% pour micro-caps < 0.001 USDT). Activé aussi en testnet (08/05) car `SCAN_API` utilise Binance prod.

---

### 1.8 Log Framework 7 Couches dans les cycles spy (13/05)
**Fichier** : `market_spy.py`

À chaque surge détecté sur un coin éligible (score IA ≥ 55), un log dédié est émis :
```
🧠 [FRAMEWORK 7C] ZECUSDC éligible — score=82/100 rank=#3 dir=NEUTRAL | ENTRY_FILTER 3/5 (seuil assoupli: 3 règles suffisent)
```
Permet de vérifier en temps réel que le pipeline IA → spy fonctionne.

---

## 2. Sorties — trailing et exits anticipés

### 2.1 INSTANT_REVERSAL_EARLY — exit ultra-précoce (08/05)
**Fichier** : `market_spy.py` · règle 0

Nouvelle règle déclenchée entre **15 et 30 secondes** si :
- `max_pnl < 0.05%` (jamais monté)
- `pnl < -0.35%`
- Pas de protection EMA7 active

Objectif : couper avant la règle standard INSTANT_REVERSAL (45s / -0.6%). Diagnostic : 19 INSTANT_REVERSAL sur 14 jours = -93 USDC en testnet. Avg perte -0.52% ; en coupant à -0.35% dès 15-30s, économie ≈ +0.17%/trade.

---

### 2.2 EMA7_DOWNTREND — 3 lectures si EMA7 encore au-dessus EMA25 (13/05)
**Fichier** : `market_spy.py` · règle 0d

**Problème** : ZEC et SOLV vendus trop tôt pendant une consolidation normale dans un uptrend (EMA7 > EMA25 mais slope momentanément < -0.07%).

**Correction** : Si `_ema7_bearish is False` (EMA7 encore structurellement au-dessus d'EMA25), il faut **3 lectures consécutives** de slope négatif au lieu de 2 pour déclencher la vente. La sortie immédiate sur perte profonde (pnl < -0.70% + slope < -0.15%) reste inchangée.

```python
_ema7_still_above_ema25 = (_ema7_bearish is not None and not _ema7_bearish)
_min_bd = 3 if _ema7_still_above_ema25 else 2
```

---

### 2.3 MICRO_BOUNCE_TRAP (04/05)
**Fichier** : `market_spy.py` · règle 0a

Couvre la zone [0.15%–0.40%] de max_pnl dans les 45–90 premières secondes : si le prix repart en perte > -0.20%, sortie immédiate. Comble le gap entre INSTANT_REVERSAL (max<0.05%) et PROFIT_LOCK (max≥0.40%).

---

### 2.4 EARLY_SL renforcé (04/05)
**Fichier** : `market_spy.py` · règle 0b

Si après 90s le prix n'a jamais dépassé +0.15% (max_pnl < `EARLY_SL_MIN_PNL`) et est déjà à -0.5%, vente immédiate "Dead on Arrival". Cas BIO 07:32 (63 ticks à 0.00%).

---

### 2.5 PROFIT_LOCK_RETRACE assoupli (05/05)
**Fichier** : `market_spy.py`

`PROFIT_LOCK_RETRACE_EMA_SOFT` : 0.40% → 0.50%. Les petits gains (0.4–1%) avaient besoin de plus de tolérance. Exemple : gain max 0.61% → floor 0.11% (trop strict) vs 0.21% (correct).

---

### 2.6 Réalisme testnet — fees simulés + vente au BID (08/05)
**Fichier** : `market_spy.py`

- Les ventes testnet utilisent désormais le prix BID réel (pas `last`) pour simuler le slippage.
- Les fees Binance (0.1% maker + 0.1% taker) sont déduits du PnL testnet pour une comparaison réaliste avec la production.

---

## 3. Pipeline IA — Framework 7 Couches

### 3.1 Correction filtre stablecoin USDC (session courante)
**Fichier** : `ai_predictor.py` · `_analyze_symbol()` · ligne ~1074

**Problème** : Les 33 coins USDC (ZECUSDC, KITEUSDC, etc.) étaient tous rejetés comme "stablecoin" car `'USD' in 'ZECUSDC'` = True (USDC contient la sous-chaîne USD).

**Correction** :
- Extraction correcte du base asset : `symbol[:-4]` pour USDC/USDT
- Whitelist `STABLECOIN_BASES = {'USD', 'USDC', 'USDT', 'BUSD', 'DAI', ...}` pour tester le **base asset** uniquement
- Résultat : 33 coins USDC maintenant analysés par le framework

---

### 3.2 Mapping des features vers le sélecteur (session courante)
**Fichier** : `ai_predictor.py` · `_build_surveillance_status()` · ligne ~4428

**Problème** : Les features passées à `AIOpportunitySelector` étaient quasi toutes à zéro.

**Corrections** :
- `price_current` extrait depuis `features['price_current']` (clé correcte)
- `ema_diff_direct` calculé comme fraction directe (EMA7−EMA25)/EMA25 — évite la dépendance à ema_9/ema_21 absents
- `momentum_3/5/10/20` divisés par 100 (étaient en % mais attendus en décimal)
- `volume_ratio` mappé depuis `volume_precursor`

---

### 3.3 Priorité ema_diff_direct dans extract_features (session courante)
**Fichier** : `ai_opportunity_selector.py` · `extract_features()` · ligne ~324

Si `ema_diff_direct` est présent dans `crypto_data`, il est utilisé directement (priorité sur le calcul ema9/ema21 qui retournait 0 quand ces clés étaient absentes).

---

### 3.4 Structure et logique des 7 couches (référence)
**Fichier** : `ai_opportunity_selector.py` · `_evaluate_layers()`

| Couche | Ce qu'elle mesure | Seuil de passage |
|--------|-------------------|------------------|
| L1 Macro BTC | momentum BTC < 10min | BTC mom ≥ −0.3% |
| L2 Régime token | direction IA + alignement EMA | direction ≠ DOWN ET ema_diff > −0.02 |
| L3 Accumulation | volume vs moyenne | vol_ratio ≥ 1.2× |
| L4 Compression | Squeeze BB ou faible bandwidth | squeeze actif OU bb_bw < 2% |
| L5 Timing anti-pic | momentum 3 scans (≈3min) | 0% < mom_3 < 1.5% |
| L6 Structure | RSI sain + position BB | RSI ∈ [30,60] ET bb_pos ≤ 75% |
| L7 Historique | win-rate passé du token | WR ≥ 55% |

**Actions déduites** :
- `BUY_NOW` : fiabilité ≥ 5 ET `early_signal` (L3∧L4∧L5 toutes vertes simultanément)
- `WATCH` : fiabilité ≥ 4
- `TOO_LATE` : mom_3 ≥ 3% (pic déjà parti, score ×0.4)
- `SKIP` : reste

**Impact sur market_spy** : un coin avec score ≥ 55 active `_ai_opp_active = True` → ENTRY_FILTER assoupli de 4/5 à 3/5 règles.

---

## 4. Dashboard — nouveaux indicateurs visuels

### 4.1 Bloc "Opportunités IA — Framework 7 Couches" (session courante)
**Fichier** : `dashboard.html` · `renderAiOpps()`

Affiche pour chaque coin surveillé :
- Dots L1–L7 verts/rouges
- Fiabilité X/7 + score IA
- Action : BUY_NOW / WATCH / TOO_LATE / SKIP
- Valeurs détaillées par couche (BTC mom, EMA diff, vol ratio, squeeze, timing, RSI/BB, WR)

**Bug corrigé** : le message "Données temps réel indisponibles" s'affichait systématiquement pour tous les coins (causes : filtre stablecoin, features nulles — cf. §3.1 et §3.2).

---

### 4.2 Badge Framework 7C dans le tableau "Toutes les Valeurs Tradables" (13/05)
**Fichiers** : `api/routes.py` + `dashboard.html`

Pour chaque coin avec score IA ≥ 55, un badge `🧠 N/7` apparaît à côté du nom dans le tableau, avec :
- **Vert** si action = `BUY_NOW`
- **Orange** si action = `WATCH`
- **Gris** sinon
- Tooltip au survol : `Framework 7C · score=82.6 · 4/7 couches · WATCH`

**Côté API** : `routes.py` lit `ai_opportunities.json` et injecte `ai_framework: {score, fiability, action}` dans chaque entrée du tableau.

---

## 5. Infrastructure et réalisme testnet

### 5.1 WebSocket miniTicker + fallback REST (05/05)
**Fichier** : `market_spy.py`

Prix temps réel via WebSocket Binance miniTicker (latence ~100ms). Si le WS est stale (> 5s sans update), fallback automatique sur REST. Réduit la latence de détection de 7s à ~100ms pour les surges courts.

---

### 5.2 Alignement temporel des scans sur grille absolue (05/05)
**Fichier** : `market_spy.py`

Les scans s'alignent sur une grille temporelle absolue (ex : chaque 7.000s depuis minuit UTC) plutôt que de s'enchaîner en relatif. Évite la dérive temporelle sur sessions longues.

---

### 5.3 Refresh AI_OPP + Hotlist — cadence 40 scans (≈5min)
**Fichier** : `market_spy.py`

`_refresh_ai_opp_scores()` et `_refresh_hotlist()` sont appelés tous les 40 scans (offset +3 pour ne pas se superposer). Les scores IA sont ainsi synchronisés avec le cycle de l'`AIOpportunitySelector` (recalcul toutes les 3min dans `ai_predictor.py`).

---

### 5.4 BREAKOUT_SURGE différé d'un scan (29/04)
**Fichier** : `market_spy.py`

Les surges de type BREAKOUT sont confirmés un scan plus tard (~7s) pour filtrer les wicks de fin de tendance. Réduit les faux positifs sur breakouts qui s'inversent immédiatement.

---

## 6. Problèmes encore ouverts

### 6.1 Données temps réel partielles pour certains coins USDC
Le message "Données temps réel indisponibles" peut encore apparaître si le cycle d'analyse `ai_predictor.py` n'a pas encore tourné depuis le démarrage (premier cycle ≈ 30s). Pas de bug structurel — juste un délai d'amorçage.

### 6.2 Production en pause
La production reste en pause (cf. analyse du 08/05) en raison d'un slippage moyen mesuré de +0.535% sur les ordres market FLASH. Prochaine étape : implémenter les ordres LIMIT post-only avant tout redémarrage prod.

### 6.3 `load_opportunities()` ne restaure pas `layers`
Dans `ai_opportunity_selector.py`, la méthode `load_opportunities()` recharge les profils depuis `ai_opportunities.json` mais ne restaure pas le champ `layers` (les 7 couches détaillées). Cela n'affecte pas le dashboard (qui lit le fichier directement) mais empêche l'utilisation in-memory des layers après redémarrage.

### 6.4 L7 Historique — valeur peu fiable sur coins récents
Le WR proxy à 100% sur ZEC (comme visible dans le dashboard) indique un très faible nombre de trades historiques. Le framework ne pondère pas la valeur par le nombre d'observations. Un min_trades threshold améliorerait la fiabilité de L7.

---

## Résumé chiffré des changements

| Domaine | Nb de corrections | Impact principal |
|---------|-------------------|-----------------|
| Entrées (filtres) | 8 | Réduction achats en downtrend / dead cat |
| Sorties (exits) | 6 | Réduction pertes INSTANT_REVERSAL (-93 USDC/14j) |
| Pipeline IA | 3 | 33 coins USDC analysés, layers L1-L7 alimentés |
| Dashboard | 2 | Visibilité Framework 7C dans 2 blocs |
| Infrastructure | 4 | Latence réduite, réalisme testnet amélioré |

---

_Document généré le 13/05/2026 — pour transmission et revue externe._