Prédiction du prix journalier par Machine Learning
v1.0.0 — Gradient BoostingConstruisez votre requête avec les menus ci-dessous, observez le JSON généré en temps réel puis envoyez-le à l'endpoint /predict.
Content-Type: application/json.| Méthode | Route | Description |
|---|---|---|
| POST | /predict |
Prédiction du prix journalier à partir de 13 features. Renvoie {"prediction": [float]}. |
| GET | / |
Page d'accueil (cette page) avec le constructeur de requête interactif. |
| GET | /docs |
Documentation HTML conçue pour un lecteur humain : tableau des features, exemples curl et Python commentés. |
| GET | /swagger |
Interface Swagger UI interactive. Branchée sur /openapi.json. Permet de tester la requête avec "Try it out". |
| GET | /openapi.json |
Descripteur OpenAPI 3.1 brut (JSON). Lisible par n'importe quel client OpenAPI : Postman, Insomnia, generation de SDK. |
Cliquez sur une question pour afficher la réponse.
Dataset de 4 843 lignes, pas assez pour un réseau profond. Le Gradient Boosting gère très bien les données tabulaires mixtes (numériques et catégorielles), reste interprétable grâce à la feature importance, s'entraîne en quelques secondes et se déploie dans un fichier joblib de moins de 2 Mo. Régression linéaire testée en baseline : R² 0.69. Gradient Boosting : R² 0.75 sur le test set.
Le OneHotEncoder est configuré avec handle_unknown='ignore' : toutes les variables one-hot de cette marque tombent à 0, le modèle s'appuie alors uniquement sur les autres features (puissance, kilométrage, options). Pas de crash, pas d'erreur HTTP 500, juste une prédiction légèrement moins précise.
Pydantic vérifie la structure à l'entrée de FastAPI : clé input présente, liste de listes. Si le body est mal formé, FastAPI renvoie un HTTP 422 avec le détail de l'erreur. Ensuite, les valeurs arrivent dans une pipeline scikit-learn qui applique le preprocessing (StandardScaler, OneHotEncoder) puis prédit.
Choix délibéré : permet d'envoyer plusieurs véhicules en une seule requête (batch). Par exemple 100 véhicules d'un coup, une seule aller-retour réseau, plus performant en production. Le compromis est la lisibilité : l'ordre des 13 features est critique, c'est pour ça que la page /docs détaille le tableau ordonné.
Cette instance est en mode démo : pas d'authentification, pas de rate limiting, HTTPS activé par défaut via Hugging Face. Pour une mise en production réelle : ajouter une API key via fastapi.security, déployer derrière un API Gateway (AWS ou Cloudflare) avec quotas, et versionner les modèles via MLflow Model Registry plutôt qu'un fichier joblib figé.
MLflow tracke chaque entraînement localement (dossier mlruns/ du notebook). Deux runs sont enregistrés : linear_regression et gradient_boosting, avec paramètres, métriques (R², MAE, RMSE) et pipeline complet loggé. Pour cette démo, le modèle retenu est exporté via joblib.dump(pipeline, 'model.joblib') et chargé au démarrage de l'API.
Le dataset la fournit, donc elle passe dans le pipeline. Le Gradient Boosting l'utilise comme signal faible (importance < 1 %). La retirer aurait nécessité une étape de feature selection explicite, non priorisée ici. En production : on auditerait le dataset, on retirerait cette feature et on aurait un modèle plus simple, sans perte mesurable de performance.
Environ 150 à 300 ms pour un véhicule (réseau + sérialisation + preprocessing + prédiction), essentiellement la latence réseau vers Hugging Face. Le calcul ML pur prend moins de 5 ms. En batch, le coût marginal par véhicule supplémentaire est négligeable.
200 OK : prédiction réussie, corps = {"prediction": [...]}. 422 Unprocessable Entity : body JSON mal formé (clé input manquante, nombre de features incorrect, type invalide). 500 Internal Server Error : défaillance côté serveur (rare). Timeout : le Space Hugging Face dort, premier appel plus long (5 à 12 secondes) le temps du réveil.