Bonjour,
Tout d'abord, félicitations pour ce projet très complet. Développer un projet end-to-end (de l'entraînement d'un modèle SSD au déploiement sur Kubernetes avec une interface temps réel par WebSocket) est un défi technique ambitieux.
Voici ma revue de code, découpée entre les bonnes pratiques très bien appliquées et quelques pistes d'amélioration constructives.
Points forts
Sécurité et optimisation Docker
L'utilisation d'un multi-stage build dans le Dockerfile permet de réduire drastiquement la taille de l'image finale. La création d'un utilisateur non-root pour exécuter l'application est primordiale pour la sécurité, notamment dans un environnement Kubernetes.
Pipeline CI/CD
L'automatisation via GitHub Actions (.github/workflows/docker-deploy.yml) est très propre. L'utilisation des meta-tags pour lier les images Docker aux branches ou aux commits est une excellente méthode pour garantir la traçabilité.
Suivi des expérimentations
L'intégration native de WandB dans le script d'entraînement (training/train.py) pour suivre la loss, les métriques (mAP) et les hyperparamètres démontre une bonne maturité MLOps.
Qualité du code
L'ajout du linter ruff configuré dans pyproject.toml et la présence de tests unitaires (ex : tests/test_mobilenetv2.py) garantissent une bonne maintenabilité du projet.
Pistes d'amélioration
Architecture de l'API (serving/server.py)
Variables globales
Dans server.py, le modèle et la configuration sont chargés dans des variables globales (global model, config, transform, device) au démarrage. Dans l'écosystème FastAPI, il est préférable d'utiliser :
- le dictionnaire d'état de l'application :
app.state.model = model
- ou l'injection de dépendances via
Depends()
Cela évite les effets de bord et facilite les tests unitaires de l'API.
Gestion des fichiers temporaires
L'endpoint POST /upload stocke la vidéo dans un fichier temporaire. Si l'utilisateur ferme la page avant d'initier la connexion WebSocket, la fonction os.unlink(video_path) ne sera jamais appelée, entraînant une fuite d'espace disque.
Solution proposée: implémenter un nettoyage automatique via une tâche de fond BackgroundTasks qui supprime les sessions inactives après X minutes.
Observabilité et monitoring
Mise en place de métriques
Le projet dispose d'un endpoint /health, mais surveiller une API (latence, mémoire, utilisation du disque) est une étape incontournable. Le package prometheus-fastapi-instrumentator permettrait d'exposer un endpoint /metrics mesurant notamment la latence de traitement des vidéos.
Surveillance du modèle
Surveiller la performance d'un modèle en temps réel est difficile et requiert l'usage de proxys pour détecter le data drift ou le concept drift. Étant donné que le modèle dépend de la résolution et de la luminosité des vidéos, une première approche consiste à logger dynamiquement les scores de confiance médians des prédictions (ex : scores_list). Une chute brutale de ces scores en production alerterait d'un data drift possible (par exemple, des vidéos nocturnes alors que le modèle a été entraîné sur des vidéos de jour).
Bonjour,
Tout d'abord, félicitations pour ce projet très complet. Développer un projet end-to-end (de l'entraînement d'un modèle SSD au déploiement sur Kubernetes avec une interface temps réel par WebSocket) est un défi technique ambitieux.
Voici ma revue de code, découpée entre les bonnes pratiques très bien appliquées et quelques pistes d'amélioration constructives.
Points forts
Sécurité et optimisation Docker
L'utilisation d'un multi-stage build dans le Dockerfile permet de réduire drastiquement la taille de l'image finale. La création d'un utilisateur non-root pour exécuter l'application est primordiale pour la sécurité, notamment dans un environnement Kubernetes.
Pipeline CI/CD
L'automatisation via GitHub Actions (
.github/workflows/docker-deploy.yml) est très propre. L'utilisation des meta-tags pour lier les images Docker aux branches ou aux commits est une excellente méthode pour garantir la traçabilité.Suivi des expérimentations
L'intégration native de WandB dans le script d'entraînement (
training/train.py) pour suivre la loss, les métriques (mAP) et les hyperparamètres démontre une bonne maturité MLOps.Qualité du code
L'ajout du linter ruff configuré dans
pyproject.tomlet la présence de tests unitaires (ex :tests/test_mobilenetv2.py) garantissent une bonne maintenabilité du projet.Pistes d'amélioration
Architecture de l'API (
serving/server.py)Variables globales
Dans
server.py, le modèle et la configuration sont chargés dans des variables globales (global model, config, transform, device) au démarrage. Dans l'écosystème FastAPI, il est préférable d'utiliser :app.state.model = modelDepends()Cela évite les effets de bord et facilite les tests unitaires de l'API.
Gestion des fichiers temporaires
L'endpoint
POST /uploadstocke la vidéo dans un fichier temporaire. Si l'utilisateur ferme la page avant d'initier la connexion WebSocket, la fonctionos.unlink(video_path)ne sera jamais appelée, entraînant une fuite d'espace disque.Solution proposée: implémenter un nettoyage automatique via une tâche de fond
BackgroundTasksqui supprime les sessions inactives après X minutes.Observabilité et monitoring
Mise en place de métriques
Le projet dispose d'un endpoint
/health, mais surveiller une API (latence, mémoire, utilisation du disque) est une étape incontournable. Le packageprometheus-fastapi-instrumentatorpermettrait d'exposer un endpoint/metricsmesurant notamment la latence de traitement des vidéos.Surveillance du modèle
Surveiller la performance d'un modèle en temps réel est difficile et requiert l'usage de proxys pour détecter le data drift ou le concept drift. Étant donné que le modèle dépend de la résolution et de la luminosité des vidéos, une première approche consiste à logger dynamiquement les scores de confiance médians des prédictions (ex :
scores_list). Une chute brutale de ces scores en production alerterait d'un data drift possible (par exemple, des vidéos nocturnes alors que le modèle a été entraîné sur des vidéos de jour).