Contexte
Lors de l'analyse de la PR #5 (bump python-multipart 0.0.6→0.0.27), il a été constaté que cette dépendance n'est pas importée directement dans le code source :
- Aucun
from python_multipart import ...
- Aucun usage de
UploadFile, Form(), File() dans FastAPI
- L'ingestion de documents passe par du base64 dans le JSON, pas du multipart/form-data
Objectif
Auditer l'ensemble des dépendances de requirements.txt pour identifier celles déclarées mais non utilisées par le code (excluant les transitives nécessaires).
Démarche proposée
- Pour chaque dépendance de
requirements.txt, grep dans src/ et scripts/ pour vérifier les imports directs
- Tester suppression de la dépendance + rebuild Docker + recette
scripts/test_recette.py (doit rester Ă 150/150 PASS)
- Si pas de régression → supprimer du
requirements.txt
- Documenter le changement dans CHANGELOG.md
Candidats identifiés
Critères de succès
- Recette complète : 150/150 PASS après suppression
- Surface d'attaque réduite (moins de CVE potentielles)
docker-compose up fonctionne sans erreur
- Build Docker reproductible
Priorité
🟡 Moyenne — Pas de blocage production, mais bonne hygiène de sécurité (réduction surface CVE).
Contexte
Lors de l'analyse de la PR #5 (bump python-multipart 0.0.6→0.0.27), il a été constaté que cette dépendance n'est pas importée directement dans le code source :
from python_multipart import ...UploadFile,Form(),File()dans FastAPIObjectif
Auditer l'ensemble des dépendances de
requirements.txtpour identifier celles déclarées mais non utilisées par le code (excluant les transitives nécessaires).Démarche proposée
requirements.txt, grep danssrc/etscripts/pour vérifier les imports directsscripts/test_recette.py(doit rester à 150/150 PASS)requirements.txtCandidats identifiés
python-multipart(>=0.0.27) — pas d'import direct, pas d'usage FastAPI multipartaiofiles(>=23.0.0) — à vérifierCritères de succès
docker-compose upfonctionne sans erreurPriorité
🟡 Moyenne — Pas de blocage production, mais bonne hygiène de sécurité (réduction surface CVE).