mirror of
https://github.com/R0m1k3/Priceflow.git
synced 2026-10-17 12:18:17 +02:00
Michael
6cf7f98843
- Passage des requêtes DB en asynchrone dans improved_search_service pour éviter le blocage de l'Event Loop. - Ajout du Rapport d'Analyse Technique complet. - Sécurisation CORS (best effort). - Ajout Walkthrough et Implementation Plan.
100 lines
5.6 KiB
Markdown
100 lines
5.6 KiB
Markdown
# Rapport d'Analyse Technique - PriceFlow
|
|
|
|
**Date:** 07 Janvier 2026
|
|
**Analyste:** Mary (Business Analyst)
|
|
**Application:** PriceFlow (Backend & Scrapers)
|
|
|
|
## 1. Synthèse "Executive Summary"
|
|
|
|
L'application **PriceFlow** présente des fondations fonctionnelles solides pour le scraping e-commerce, utilisant des technologies modernes (Playwright, FastAPI, Browserless). L'architecture de scraping est particulièrement sophistiquée, utilisant des navigateurs persistants et des stratégies hybrides d'extraction (JSON-LD, CSS, IA).
|
|
|
|
Cependant, l'analyse révèle des **failles de sécurité critiques** (clés API exposées) et des **problèmes de performance structurels** (blocage de la boucle événementielle asynchrone par la base de données) qui doivent être corrigés avant tout passage en production.
|
|
|
|
---
|
|
|
|
## 2. Analyse Sécurité 🚨 (CRITIQUE)
|
|
|
|
### 🔴 Failles Critiques
|
|
1. **Exposition de Secrets (Hardcoded Secrets) :**
|
|
* **Fichier :** `docker-compose.yml`
|
|
* **Problème :** La clé `OPENROUTER_API_KEY` est écrite en clair.
|
|
* **Risque :** Utilisation frauduleuse du quota, surcoût financier immédiat.
|
|
* **Action requise :** Révoquer la clé immédiatement et utiliser un fichier `.env`.
|
|
|
|
2. **Identifiants par Défaut :**
|
|
* **Fichier :** `docker-compose.yml`
|
|
* **Problème :** `POSTGRES_PASSWORD=priceflow` est utilisé.
|
|
* **Risque :** Compromission triviale de la base de données si le port 5488 est exposé (ce qui est le cas dans la config actuelle).
|
|
|
|
3. **CORS Permissif (Cross-Origin Resource Sharing) :**
|
|
* **Fichier :** `main.py`
|
|
* **Problème :** `allow_origins=["*"]` (ou via variable d'env par défaut).
|
|
* **Risque :** Permet à n'importe quel site malveillant d'interroger l'API s'il est visité par un utilisateur authentifié (CSRF/Data Exfiltration).
|
|
|
|
### 🟠 Risques Modérés
|
|
1. **Migrations Manuelles Hardcodées :**
|
|
* **Fichier :** `main.py`
|
|
* **Problème :** Utilisation de `CREATE TABLE` via des chaînes SQL brutes au démarrage.
|
|
* **Risque :** Difficile à maintenir, risque d'erreur humaine et d'injection si les chaînes étaient dynamiques. `alembic` est installé mais non utilisé pour l'initialisation.
|
|
|
|
2. **CSP Browserless désactivé :**
|
|
* Le service Browserless désactive explicitement la Content Security Policy (`bypass_csp: true`). C'est nécessaire pour le scraping mais nécessite que le conteneur soit strictement isolé du réseau interne sensible.
|
|
|
|
---
|
|
|
|
## 3. Analyse Efficience ⚡
|
|
|
|
### ✅ Points Forts
|
|
1. **Browserless Persistant :** L'utilisation de `async_playwright` avec une connexion WebSocket persistante vers Browserless (`BrowserlessService`) est excellente. Cela évite le coût énorme du lancement de processus Chrome pour chaque requête.
|
|
2. **Streaming SSE :** L'endpoint de recherche (`/api/search`) utilise les Server-Sent Events, permettant une UX réactive même si le scraping est lent.
|
|
|
|
### ⚠️ Problèmes de Performance (Blocking I/O)
|
|
1. **Mélange Synchrone/Asynchrone Dangereux :**
|
|
* **Fichier :** `app/services/improved_search_service.py` (et autres routeurs)
|
|
* **Détection :** La fonction `search_products` est définie avec `async def`, mais elle effectue des appels base de données synchrones : `db.query(SearchSite)...all()`.
|
|
* **Impact :** **Ceci bloque la boucle d'événements (Event Loop) de FastAPI.** Pendant que la base de données répond, *aucune* autre requête API ne peut être traitée. Sous charge, cela effondrera les performances.
|
|
* **Solution :** Utiliser `run_in_threadpool` pour les appels DB synchrones ou migrer vers `SQLAlchemy AsyncSession`.
|
|
|
|
---
|
|
|
|
## 4. Analyse Efficacité & Fonctionnalités 🎯
|
|
|
|
### ✅ Points Forts
|
|
1. **Stratégie de Scraping Robuste ("ImprovedSearchService") :**
|
|
* Le code implémente une stratégie en "couches" très intelligente :
|
|
1. **JSON-LD** (Structuré, très fiable).
|
|
2. **IA Extraction** (Fallback puissant si configuré).
|
|
3. **Sélecteurs CSS Stricts** (Meta tags, ID connus).
|
|
4. **Sélecteurs CSS Flous** (Recherche du prix le plus bas, détection de mots clés "HT/TTC").
|
|
* Cette redondance garantit un taux de succès élevé.
|
|
2. **Gestion des Anti-Bots :**
|
|
* Rotation des User-Agents.
|
|
* Injection de scripts "Stealth" (masquage de `navigator.webdriver`).
|
|
* Gestion automatique des popups (CMP/Cookies).
|
|
|
|
### ⚠️ Améliorations Possibles
|
|
1. **Gestion des Erreurs :**
|
|
* Les exceptions sont souvent capturées génériquement (`except Exception: pass`). Cela peut masquer des changements structurels sur les sites cibles.
|
|
|
|
---
|
|
|
|
## 5. Qualité du Code 📝
|
|
|
|
### ✅ Points Positifs
|
|
* Utilisation du typage statique (Type Hints) généralisée.
|
|
* Utilisation de `ruff` pour le linting.
|
|
* Code modulaire (Routeurs / Services / Schémas).
|
|
|
|
### ⚠️ Dette Technique
|
|
1. **God Classes :**
|
|
* `BrowserlessService` (~700 lignes) et `ImprovedSearchService` (~950 lignes) cumulent trop de responsabilités (gestion navigateur, parsing, logique métier).
|
|
* Il serait préférable de séparer le "BrowserManager" des "Parsers".
|
|
2. **Duplication de Code :**
|
|
* Redondance entre `browserless_service.py` et `improved_search_service.py` sur l'initialisation et la gestion des popups.
|
|
|
|
## Recommandations Prioritaires
|
|
|
|
1. **IMMÉDIAT (Sécurité) :** Passer `OPENROUTER_API_KEY` et les mots de passe DB dans un fichier `.env`.
|
|
2. **COURT TERME (Performance) :** Corriger les appels DB bloquants dans les routes `async`.
|
|
3. **MOYEN TERME (Code) :** Refactoriser pour éliminer la duplication entre les services de scraping.
|