Pourquoi passer par HTTP ?
Depuis les séances 2 à 4, votre dashboard Streamlit accède aux données en important directement le repository Python. Cette approche fonctionne, mais elle ne correspond pas aux architectures en production.
L'approche actuelle : import direct
Ce que vous faites depuis la séance 2 :
from api.repository import VentesRepository
repo = VentesRepository("db/ventes.db")
data = repo.get_par_region(annee=2024)
df = pd.DataFrame(data)
Le dashboard Streamlit importe directement la classe VentesRepository et appelle ses méthodes. Pas de réseau, pas de HTTP — un simple appel de fonction Python.
Les limites du couplage direct
Cette simplicité a un coût :
1. Couplage fort entre les composants
Le dashboard et l'API partagent le même code source Python. Pour déployer le dashboard, il faut aussi déployer tout le code de l'API, le repository, et la base de données sur la même machine.
2. Pas de vrai test d'intégration API
Vous avez construit des endpoints HTTP en séance 1, mais votre dashboard ne les utilise jamais. Impossible de valider que l'API fonctionne de bout en bout.
3. Non représentatif du monde réel
En entreprise, les dashboards BI consomment des APIs distantes. Le serveur de données et le serveur de visualisation sont rarement sur la même machine.
Quel est le principal problème de l'import direct du repository dans le dashboard ?
Quand garder l'import direct ?
L'import direct reste approprié dans certains cas :
- Prototype rapide : vous testez une idée et la vitesse de développement prime
- Performance critique : l'overhead HTTP (même local) est inacceptable
- Même machine garantie : le dashboard et la base de données seront toujours co-localisés
- Outil interne simple : un script d'analyse utilisé par une seule personne
Quand HTTP est nécessaire ?
HTTP devient nécessaire dès que :
- Machines séparées : le dashboard tourne sur un serveur, l'API sur un autre (ou dans des conteneurs Docker différents)
- Clients multiples : plusieurs dashboards, une application mobile, un notebook Jupyter consomment la même API
- Backend remplaçable : vous voulez pouvoir changer l'implémentation de l'API sans toucher au dashboard
- Équipes différentes : une équipe data maintient l'API, une autre le dashboard
Dans ce cours
Même si votre API et votre dashboard tournent sur la même machine, passer par HTTP vous prépare aux architectures réelles et vous permet de valider que vos endpoints fonctionnent de bout en bout.
Architecture cible
L'architecture mise en place dans cette séance :
Le dashboard Streamlit (port 8501) envoie des requêtes HTTP à l'API Flask (port 5000). L'API retourne du JSON, que le dashboard convertit en DataFrame pour l'afficher dans des graphiques Plotly.
Les deux applications sont indépendantes :
- L'API Flask peut être redémarrée sans affecter le dashboard
- Le dashboard peut être déployé sur une autre machine
- D'autres clients peuvent consommer la même API
Dans l'architecture cible, quel format de données circule entre Streamlit et Flask ?
Ce qui change concrètement
| Aspect | Import direct | Via HTTP |
|---|---|---|
| Code côté dashboard | from api.repository import ... | requests.get(url) |
| Format des données | Objets Python (listes, dicts) | JSON (converti en dict/list) |
| Gestion d'erreurs | Exceptions Python classiques | Erreurs réseau + codes HTTP |
| Déploiement | Tout sur la même machine | Séparation possible |
| Sécurité | Accès direct à la DB | API comme point d'entrée unique |
À retenir
Points clés
- L'import direct crée un couplage fort entre le dashboard et l'API
- HTTP permet de découpler les composants : déploiement séparé, clients multiples, backend remplaçable
- L'architecture cible : Streamlit (port 8501) appelle Flask (port 5000) via HTTP
- Le dashboard reçoit du JSON qu'il convertit en DataFrame pour l'affichage
- Même en local, HTTP vous prépare aux architectures de production