Diaure commited on
Commit
996d9f3
·
verified ·
1 Parent(s): 5935906

CD: update from GitHub main

Browse files
.gitignore CHANGED
@@ -8,4 +8,4 @@ App/model/
8
  *.joblib
9
  *.json
10
  App/model/modele_final_xgb.joblib
11
- Other
 
8
  *.joblib
9
  *.json
10
  App/model/modele_final_xgb.joblib
11
+ coverage.xml
Other/Rapport couverture.PNG ADDED
Other/comp_modeles.PNG ADDED
README.md CHANGED
@@ -35,6 +35,62 @@ Le projet inclut:
35
  - Un pipeline **CI/CD** pour automatiser les tests et le déploiement
36
  - Une documentation technique centralisée dans ce README
37
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
38
  ## Modèle de Machine Learning (ML)
39
  ### `Problématique`
40
  Le modèle vise à résoudre un problème de classification binaire :
@@ -319,11 +375,11 @@ Il a pour rôle:
319
  - d'évaluer la qualité de la suite de tests
320
  - d'identifier les zones non testées
321
  - de réduire les risques de régression
322
- - de garantir la fiabilité du code avant déploiement
323
- - de donner un indicateur objectif de maturité logicielle.
324
 
325
  ```text
326
- ============================== local tests coverage =====================================
327
 
328
  Name Stmts Miss Cover Missing
329
  -----------------------------------------------
@@ -335,7 +391,7 @@ App\schemas.py 32 0 100%
335
  -----------------------------------------------
336
  TOTAL 167 16 90%
337
 
338
- ========================== GitHub Actions tests coverage ================================
339
  Name Stmts Miss Cover Missing
340
  -----------------------------------------------
341
  App/database.py 25 10 60% 9-10, 23-32
@@ -356,62 +412,6 @@ TOTAL 167 50 70%
356
  - **CI/CD**: GitHub Actions, Hugging Face
357
  - **Versionnage**: Git / GitHub
358
 
359
- ## Architecture du projet
360
-
361
- L’architecture du projet repose sur une séparation claire des responsabilités afin de garantir la lisibilité, la maintenabilité et l’évolutivité de l’application.
362
-
363
- ### `Vue d’ensemble`
364
-
365
- ┌──────────────────────────────┐
366
- │ Utilisateur │
367
- │ (Client) │
368
- └───────────────┬──────────────┘
369
-
370
-
371
- ┌────────────────────────────────────────────┐
372
- │ API FastAPI │
373
- │ (endpoint - POST /predict) │
374
- └┬────────────────────┬─────────────────────┬┘
375
- | │ |
376
- ▼ ▼ ▼
377
- ┌────────────────┐ ┌──────────────┐ ┌───────────────────────────┐
378
- │ Vérification & | | Modèle ML | | Base PostgreSQL (stockage)|
379
- | Validation │ | - Chargement | | - Inputs |
380
- | | | - Prédiction | | - Prédictions |
381
- └────────────────┘ └──────────────┘ └───────────────────────────┘
382
-
383
- |
384
- |
385
- ┌────────────────────────────────────────┐
386
- │ CI/CD – GitHub Actions │
387
- │ - Tests unitaires │
388
- │ - Tests fonctionnels │
389
- │ - Rapport de couverture │
390
- │ - Déploiement sur HF Space │
391
- └────────────────────────────────────────┘
392
-
393
-
394
- ### `Description du flux`
395
-
396
- 1. Un utilisateur envoie une requête `POST /predict` à l’API
397
-
398
- 2. L’API FastAPI agit comme point d’entrée:
399
- - validation des données via **Pydantic**
400
- - orchestration du traitement
401
-
402
- 3. Le module de prédiction:
403
- - charge dynamiquement le modèle ML depuis **Hugging Face Hub**
404
- - génère la prédiction et la probabilité associée
405
-
406
- 4. Les données d’entrée et les résultats sont enregistrés dans une base **PostgreSQL** afin d’assurer la traçabilité
407
-
408
- 5. La réponse est retournée au client sous forme JSON
409
-
410
- 6. Le cycle de développement, de test et de déploiement est automatisé via un pipeline **CI/CD GitHub Actions** avec déploiement sur **Hugging Face Spaces**.
411
-
412
- Cette architecture permet une exposition fiable du modèle de Machine Learning, tout en respectant les bonnes pratiques MLOps et d’ingénierie logicielle.
413
-
414
-
415
  ## Structure du projet
416
  ```text
417
  futurisys_ml-api/
 
35
  - Un pipeline **CI/CD** pour automatiser les tests et le déploiement
36
  - Une documentation technique centralisée dans ce README
37
 
38
+
39
+ ## Architecture du projet
40
+
41
+ L’architecture du projet repose sur une séparation claire des responsabilités afin de garantir la lisibilité, la maintenabilité et l’évolutivité de l’application.
42
+
43
+ ### `Vue d’ensemble`
44
+
45
+ ┌──────────────────────────────┐
46
+ │ Utilisateur │
47
+ │ (Client) │
48
+ └───────────────┬──────────────┘
49
+
50
+
51
+ ┌────────────────────────────────────────────┐
52
+ │ API FastAPI │
53
+ │ (endpoint - POST /predict) │
54
+ └┬────────────────────┬─────────────────────┬┘
55
+ | │ |
56
+ ▼ ▼ ▼
57
+ ┌────────────────┐ ┌──────────────┐ ┌───────────────────────────┐
58
+ │ Vérification & | | Modèle ML | | Base PostgreSQL (stockage)|
59
+ | Validation │ | - Chargement | | - Inputs |
60
+ | | | - Prédiction | | - Prédictions |
61
+ └────────────────┘ └──────────────┘ └───────────────────────────┘
62
+
63
+ |
64
+ |
65
+ ┌────────────────────────────────────────┐
66
+ │ CI/CD – GitHub Actions │
67
+ │ - Tests unitaires │
68
+ │ - Tests fonctionnels │
69
+ │ - Rapport de couverture │
70
+ │ - Déploiement sur HF Space │
71
+ └────────────────────────────────────────┘
72
+
73
+ ### `Description du flux`
74
+
75
+ 1. Un utilisateur envoie une requête `POST /predict` à l’API
76
+
77
+ 2. L’API FastAPI agit comme point d’entrée:
78
+ - validation des données via **Pydantic**
79
+ - orchestration du traitement
80
+
81
+ 3. Le module de prédiction:
82
+ - charge dynamiquement le modèle ML depuis **Hugging Face Hub**
83
+ - génère la prédiction et la probabilité associée
84
+
85
+ 4. Les données d’entrée et les résultats sont enregistrés dans une base **PostgreSQL** afin d’assurer la traçabilité
86
+
87
+ 5. La réponse est retournée au client sous forme JSON
88
+
89
+ 6. Le cycle de développement, de test et de déploiement est automatisé via un pipeline **CI/CD GitHub Actions** avec déploiement sur **Hugging Face Spaces**.
90
+
91
+ Cette architecture permet une exposition fiable du modèle de Machine Learning, tout en respectant les bonnes pratiques MLOps et d’ingénierie logicielle.
92
+
93
+
94
  ## Modèle de Machine Learning (ML)
95
  ### `Problématique`
96
  Le modèle vise à résoudre un problème de classification binaire :
 
375
  - d'évaluer la qualité de la suite de tests
376
  - d'identifier les zones non testées
377
  - de réduire les risques de régression
378
+ - de garantir la fiabilité du code avant déploiement.
379
+
380
 
381
  ```text
382
+ ========================= local tests units coverage ============================
383
 
384
  Name Stmts Miss Cover Missing
385
  -----------------------------------------------
 
391
  -----------------------------------------------
392
  TOTAL 167 16 90%
393
 
394
+ ====================== GitHub Actions tests units coverage =======================
395
  Name Stmts Miss Cover Missing
396
  -----------------------------------------------
397
  App/database.py 25 10 60% 9-10, 23-32
 
412
  - **CI/CD**: GitHub Actions, Hugging Face
413
  - **Versionnage**: Git / GitHub
414
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
415
  ## Structure du projet
416
  ```text
417
  futurisys_ml-api/