🔬 Optimisation des algorithmes

---

Algorithme actuel (v1)

Formule

scoreFinal = min(100, round(patternScore × 0.6 + headerScore × 0.4))

Calcul du patternScore

Pour chaque pattern :
  matchScore = 0
  + keywords match     → (matches/total) × 40   (max +40)
  + subject regex      → +30 si match           (max +30)
  + sender domain      → +30 si match           (max +30)
  + body keywords      → (matches/total) × 20   (max +20)
  
  Si matchScore > 15 :
    finalScore = min(100, round(matchScore/100 × pattern.score))
    
patternScore = max(finalScore de tous les patterns déclenchés)

Calcul du headerScore

SPF fail      → +25
DKIM fail     → +25
DMARC fail    → +20
rDNS mismatch → +15
IP blacklist  → +30

headerScore = min(100, sum des modifiers appliqués)

---

Limites de l'algorithme v1

Limitation	Impact	Priorité
Pas de contexte sémantique	Faux négatifs sur phishing sophistiqué	Haute
Regex sensible à la casse (mitigé par (?i))	Quelques faux négatifs	Moyenne
patternScore = max (pas de cumul)	Sous-scoring si plusieurs patterns faibles	Moyenne
Pas de velocity (fréquence d'une IP/domaine)	Manque les campagnes	Haute
Patterns statiques (pas d'apprentissage)	Dérive face aux nouvelles techniques	Haute

---

Scoring v2 (Q3 2026)

Nouvelle formule

scoreFinal = min(100, round(
  headerScore    × 0.30 +
  patternScore   × 0.35 +
  iaScore        × 0.20 +
  velocityScore  × 0.15
))

iaScore — Modèle ML embarqué

Technologie : TensorFlow.js (ONNX format) ou HuggingFace Transformers
Modèle cible : distilbert-base-uncased ou sentence-transformers/all-MiniLM-L6-v2
Latence cible : < 200ms par inférence

Pipeline d'entraînement :

Données brutes (SMS Spam + Enron + corpus communautaire)
  ↓
Nettoyage + tokenisation
  ↓
Feature extraction (TF-IDF + embeddings)
  ↓
Fine-tuning (SetFit / few-shot learning)
  ↓
Validation croisée (k=5)
  ↓
Export ONNX
  ↓
Déploiement Edge Function / TF.js
  ↓
Monitoring F1-score en production

Métriques cibles :

• Précision : > 96%
• Recall : > 94%
• F1-score : > 0.95
• Latence inférence : < 200ms

velocityScore — Détection de campagnes

// Principe : une IP/domaine qui apparaît N fois en T minutes → signal fort
const velocityScore = calculateVelocity({
  identifier: ip || domain,
  window: 60 * 60 * 1000, // 1 heure
  threshold: 10 // 10 occurrences = score maximal
});

// Stockage en Redis ou table PostgreSQL avec TTL
// score = min(100, (count / threshold) * 100)

---

Optimisations de performance

Cache/Déduplication par hash

// Empêcher les analyses identiques inutiles
import { createHash } from 'crypto';

const headerHash = createHash('sha256')
  .update(emailHeaders)
  .digest('hex');

// Vérifier le cache avant d'analyser
const cached = await redis.get(`analysis:${headerHash}`);
if (cached) return JSON.parse(cached);

// Analyser et mettre en cache 1h
const result = await analyze(emailHeaders);
await redis.set(`analysis:${headerHash}`, JSON.stringify(result), 'EX', 3600);

Économie estimée : 20-30% de requêtes évitées (emails en masse similaires).

Architecture asynchrone (job queue)

Pour les analyses lourdes (batch, IA lente) :

POST /analyze → 202 ACCEPTED + { jobId: "uuid" }
GET /job/uuid → { status: "pending" | "processing" | "complete" | "error", result? }

Avantages :

• Pas de timeout HTTP (analyses > 30s)
• Scalabilité horizontale des workers
• Retry automatique sur erreur

Stack : Bull.js (Redis) ou Supabase Queue (Q3 2026)

Validation Zod des patterns

const PatternSchema = z.object({
  id: z.string().regex(/^[A-Z]+-\d{3}$/),
  type: z.enum(['phishing', 'scam', 'malware', 'commercial', 'banking', 
                'tech_support', 'sextortion', 'delivery', 'sms_spam',
                'corporate_spam', 'financial_spam', 'generic_spam',
                'word_frequency', 'char_frequency', 'combination']),
  keywords: z.array(z.string()).min(1),
  subject_regex: z.array(z.string()),
  sender_domains: z.array(z.string()),
  score: z.number().min(0).max(100),
  severity: z.enum(['low', 'medium', 'high', 'critical']),
});

Validation au build : erreur TypeScript si un pattern est malformé.

---

Multi-langues (Q3 2026)

Problème actuel : les patterns keywords sont principalement en français.
Les emails en anglais peuvent avoir des scores plus faibles.

Solution :

// Patterns avec variantes multilingues
{
  "keywords": {
    "fr": ["livraison", "colis", "suivi"],
    "en": ["delivery", "package", "tracking"],
    "it": ["consegna", "pacco"],
    "de": ["Lieferung", "Paket"]
  }
}

Détection automatique de la langue via franc ou langdetect (Deno).

---

NLP avancé — Corps d'email (Q4 2026)

Actuellement, seuls les headers sont analysés. L'analyse du corps permettrait :

Feature	Gain détection estimé
URLs suspectes (phishing, redirections)	+15% recall
Pièces jointes (hash, extension)	+10%
Sentiment / tonalité émotionnelle	+8%
Extraction d'entités (IBAN, numéros de téléphone)	+5%
Résumé LLM des emails suspects	(qualité, pas précision)

Architecture cible :

Corps email brut
  ↓ HTML stripping
  ↓ URL extraction → VirusTotal check
  ↓ LLM summarization (GPT-4 API ou LLaMA local)
  ↓ Entity extraction (spaCy / Duckling)
  ↓ Sentiment analysis
  ↓ bodyScore intégré dans scoreFinal