Oui. Le point le plus important est d’abord de distinguer les paramètres du modèle, les métriques d’évaluation et les méthodes de validation. Des termes comme Precision, F1-score ou ROC-AUC ne sont pas des « paramètres » de MobileNetV2 ou YOLOv8-nano : ce sont des métriques utilisées pour mesurer leurs performances.

Pour MobileNetV2 et YOLOv8-nano, on ne regarde d’ailleurs pas exactement les mêmes métriques, car MobileNetV2 est souvent utilisé pour la classification, tandis que YOLOv8-nano est généralement utilisé pour la détection d’objets.

1. Precision

La précision répond à la question :

Parmi toutes les prédictions positives faites par le modèle, combien étaient réellement correctes ?

$$Precision = \frac{TP}{TP+FP}$$

où :

• TP = True Positives / vrais positifs
• FP = False Positives / faux positifs

Exemple : votre modèle détecte 100 objets comme étant des pommes, mais seulement 90 sont réellement des pommes.

$$Precision = \frac{90}{100}=0.90$$

Donc Precision = 90 %.

Une précision élevée signifie que le modèle produit peu de fausses détections.

---

2. Recall — Rappel / Sensibilité

Le Recall répond à une autre question :

Parmi tous les objets réellement présents, combien le modèle a-t-il réussi à trouver ?

$$Recall = \frac{TP}{TP+FN}$$

avec FN = False Negatives, c'est-à-dire les objets présents mais non détectés.

Supposons qu'il y ait réellement 120 pommes et que le modèle en détecte correctement 90 :

$$Recall = \frac{90}{120}=0.75$$

Donc Recall = 75 %.

Ainsi :

Situation	Precision	Recall
Peu de fausses détections	élevée	pas nécessairement élevée
Peu d'objets manqués	pas nécessairement élevée	élevée

Pour YOLO, Precision et Recall sont extrêmement importantes.

---

3. F1-score

Le F1-score combine Precision et Recall :

$$F1 = 2\times \frac{Precision\times Recall}{Precision+Recall}$$

Par exemple, avec :

$$Precision=0.90$$

et

$$Recall=0.75$$

on obtient :

$$F1 \approx 0.82$$

Le F1-score est donc particulièrement utile lorsque vous souhaitez avoir un seul indicateur représentant le compromis entre Precision et Recall.

Un modèle avec :

• Precision = 99 %
• Recall = 40 %

n'est pas nécessairement excellent, malgré sa précision très élevée.

Le F1 permet de mettre en évidence ce déséquilibre.

---

4. Accuracy — Exactitude

Très utilisée pour MobileNetV2 en classification :

$$Accuracy = \frac{\text{nombre de prédictions correctes}} {\text{nombre total d'exemples}}$$

Exemple :

1000 images testées
920 correctement classifiées

$$Accuracy = 92\%$$

Attention cependant : Accuracy peut être trompeuse avec un dataset déséquilibré.

Supposons :

• 950 images de classe A
• 50 images de classe B

Un modèle qui prédit toujours A obtient :

$$Accuracy=95\%$$

alors qu'il est complètement incapable de reconnaître B.

C'est pourquoi on regarde également Precision, Recall et F1.

---

5. ROC Curve

La ROC curve — Receiver Operating Characteristic curve représente généralement :

$$TPR$$

en fonction de :

$$FPR$$

avec :

$$TPR = Recall = \frac{TP}{TP+FN}$$

et

$$FPR = \frac{FP}{FP+TN}$$

Elle permet d'étudier le comportement du modèle lorsque l'on fait varier le seuil de décision.

Par exemple, votre MobileNetV2 peut produire :

Malade : 0.72
Sain : 0.28

Si votre seuil est 0.50 → Malade.

Mais vous pourriez décider d'utiliser un seuil de 0.80. La Precision, le Recall, les FP et les FN vont alors changer.

La ROC curve permet d'étudier tous ces seuils.

---

6. AUC — Area Under the ROC Curve

L'AUC est l'aire située sous la courbe ROC.

Elle varie généralement entre :

$$0.5 \le AUC \le 1$$

Interprétation approximative :

ROC-AUC	Interprétation
0.50	modèle aléatoire
0.60–0.70	faible
0.70–0.80	acceptable
0.80–0.90	bon
0.90–1.00	excellent

Par exemple :

MobileNetV2 : ROC-AUC = 0.94

peut indiquer une très bonne capacité à séparer deux classes.

ROC-AUC est beaucoup plus naturelle pour un problème de classification avec MobileNetV2 que pour évaluer directement un détecteur YOLO.

Pour YOLO, on privilégie généralement mAP, Precision, Recall et IoU.

---

7. 5-fold Cross Validation

Le 5-fold n'est pas une métrique.

C'est une méthode de validation appelée 5-fold cross-validation.

Supposons que vous avez 1000 images.

Vous divisez votre dataset en cinq parties :

• Fold 1 : 200
• Fold 2 : 200
• Fold 3 : 200
• Fold 4 : 200
• Fold 5 : 200

Puis vous réalisez cinq expériences.

Expérience 1

Training :

Fold 2 + Fold 3 + Fold 4 + Fold 5

Validation :

Fold 1

Expérience 2

Training :

Fold 1 + Fold 3 + Fold 4 + Fold 5

Validation :

Fold 2

Et ainsi de suite.

À la fin, vous pourriez obtenir :

Fold	Accuracy
Fold 1	91.2 %
Fold 2	93.1 %
Fold 3	90.8 %
Fold 4	92.6 %
Fold 5	91.9 %

Puis vous calculez :

$$Accuracy_{mean}=91.92\%$$

et idéalement l'écart-type :

$$91.92\% \pm 0.84\%$$

C'est beaucoup plus informatif qu'une seule expérience.

Le 5-fold permet notamment de vérifier que les performances ne sont pas dues à un découpage train/test particulièrement favorable.

---

8. Confusion Matrix

La matrice de confusion est extrêmement utile pour MobileNetV2.

Pour un problème binaire :

	Prédit positif	Prédit négatif
Réel positif	TP	FN
Réel négatif	FP	TN

Elle permet ensuite de calculer :

$$Precision=\frac{TP}{TP+FP}$$ $$Recall=\frac{TP}{TP+FN}$$ $$Specificity=\frac{TN}{TN+FP}$$ $$Accuracy=\frac{TP+TN}{TP+TN+FP+FN}$$ $$F1=2\frac{Precision\times Recall}{Precision+Recall}$$

En classification multi-classes, vous aurez une matrice plus grande.

Par exemple avec quatre classes :

Réel \ Prédit	A	B	C	D
A	95	2	2	1
B	3	89	5	3
C	1	4	93	2
D	2	1	3	94

La diagonale représente les classifications correctes.

---

9. IoU — très important pour YOLO

Avec YOLO, il faut maintenant ajouter une notion inexistante dans une classification classique : la localisation de l'objet.

Le modèle prédit une bounding box.

On compare alors la boîte prédite avec la boîte réelle.

L'Intersection over Union est :

$$IoU = \frac{\text{Intersection entre les deux boîtes}} {\text{Union des deux boîtes}}$$

Si :

$$IoU=1$$

les deux bounding boxes sont parfaitement superposées.

Si :

$$IoU=0$$

elles ne se chevauchent pas.

Schématiquement :

text
Ground Truth
┌───────────────┐
│       ┌───────────────┐
│       │ //////│       │
│       │ //////│       │
└───────│───────┘       │
        └───────────────┘
           Prediction

La zone ////// correspond à l'intersection.

---

10. AP — Average Precision

Pour YOLO, on rencontre ensuite AP.

L'AP résume essentiellement la courbe Precision-Recall pour une classe donnée.

Par exemple :

• AP pomme = 0.92
• AP banane = 0.88
• AP orange = 0.81

---

11. mAP — probablement LA métrique principale pour YOLO

mAP = mean Average Precision.

On calcule l'AP de chaque classe puis la moyenne.

Par exemple :

Classe	AP
Pomme	0.92
Banane	0.88
Orange	0.81

Alors :

$$mAP = \frac{0.92+0.88+0.81}{3}$$ $$mAP=0.87$$

soit 87 %.

Mais vous rencontrerez souvent deux métriques différentes avec YOLOv8 :

mAP@50

Une détection est considérée comme correcte à partir d'un seuil :

$$IoU \ge 0.50$$

Exemple :

mAP@50 = 0.94

mAP@50:95

Beaucoup plus sévère.

On évalue plusieurs seuils :

$$IoU=0.50,0.55,0.60,...,0.95$$

et on en fait la moyenne.

Exemple :

mAP@50 = 0.94
mAP@50:95 = 0.67

C'est parfaitement normal que mAP@50:95 soit plus faible que mAP@50.

---

MobileNetV2 vs YOLOv8-nano : quelles métriques utiliser ?

Voici la distinction que je vous recommande de retenir :

Métrique	MobileNetV2 classification	YOLOv8-nano détection
Accuracy	✅ Très utile	⚠️ Rare
Precision	✅	✅ Très important
Recall	✅	✅ Très important
F1-score	✅	✅
Confusion Matrix	✅	✅
ROC Curve	✅ Très utile	⚠️ Moins courante
ROC-AUC	✅ Très utile	⚠️ Moins courante
IoU	❌	✅ Fondamental
AP	❌	✅
mAP@50	❌	✅ Très important
mAP@50:95	❌	✅ Très important
5-fold CV	✅	✅ possible

---

Et il existe une autre catégorie de « paramètres »

Lorsque vous comparez MobileNetV2 et YOLOv8-nano, vous pouvez également rencontrer :

Parameters = 3.5 M

Ici, le mot Parameters a un tout autre sens.

Il indique le nombre de poids entraînables ou paramètres du réseau neuronal.

Vous pouvez également avoir :

• Parameters / Params
• FLOPs ou GFLOPs
• Model size
• Inference time
• Latency
• FPS
• Epochs
• Batch size
• Learning rate
• Input size
• Loss

Ce sont encore des informations différentes de ROC, F1 ou mAP.

On peut donc classer tous ces termes en quatre familles :

Famille	Exemples
Métriques de classification	Accuracy, Precision, Recall, F1, ROC-AUC
Métriques de détection	Precision, Recall, F1, IoU, AP, mAP@50, mAP@50:95
Méthodes d'évaluation	Train/Validation/Test, 5-fold, 10-fold
Caractéristiques / hyperparamètres du modèle	Params, FLOPs, epochs, batch size, learning rate, image size

Cette distinction est très importante lorsque vous rédigez un article scientifique, mémoire ou comparaison expérimentale : on ne devrait pas présenter « 5-fold », « F1 » et « nombre de paramètres » comme s'il s'agissait du même type d'information.

Si votre objectif est de comparer expérimentalement MobileNetV2 et YOLOv8-nano, je peux également vous expliquer précisément quelles métriques mettre dans votre tableau de résultats, comment les calculer, comment les interpréter et quelles courbes présenter dans un article scientifique, avec un exemple complet de tableau MobileNetV2 vs YOLOv8-nano.

Oui. La différence devient très claire dès qu’on sépare deux idées : labelliser une image signifie lui attribuer une classe ou une identité, tandis que annoter une image signifie généralement indiquer précisément où se trouve l’objet dans l’image et éventuellement sa forme.

Pour un CNN de classification comme MobileNetV2, on fait surtout de la labellisation. Supposons que vous vouliez reconnaître trois classes : pomme, banane, orange. Si une image contient une pomme, vous donnez simplement à toute l’image le label pomme. Le modèle apprend donc une relation du type :

text
image_001.jpg  → pomme
image_002.jpg  → banane
image_003.jpg  → orange

Très souvent, cette labellisation est représentée directement par l’organisation des dossiers :

text
dataset/
├── train/
│   ├── pomme/
│   │   ├── img001.jpg
│   │   └── img002.jpg
│   ├── banane/
│   │   ├── img003.jpg
│   │   └── img004.jpg
│   └── orange/
│       ├── img005.jpg
│       └── img006.jpg

Ici, aucune bounding box n’est nécessaire. L’image entière reçoit une classe.

Pour YOLO, c’est différent parce que YOLO fait principalement de la détection d’objets. Il ne doit pas seulement répondre « il y a une pomme », mais également dire où se trouve la pomme dans l’image. Vous devez donc faire une annotation avec une bounding box autour de chaque objet.

Par exemple, cette image :

text
+--------------------------------------+
|                                      |
|       +----------+                   |
|       |  POMME   |        +-------+  |
|       |          |        |BANANE |  |
|       +----------+        +-------+  |
|                                      |
+--------------------------------------+

contient deux objets. Vous devez fournir à YOLO quelque chose qui signifie :

text
Pomme  → classe + position de la boîte
Banane → classe + position de la boîte

Dans le format YOLO classique, cela devient par exemple :

text
0 0.30 0.45 0.20 0.25
1 0.72 0.55 0.18 0.22

Chaque ligne correspond à un objet et contient :

text
class_id  x_center  y_center  width  height

Les coordonnées sont généralement normalisées entre 0 et 1.

Donc, pour une même image, MobileNetV2 pourrait simplement recevoir :

text
image.jpg → pomme

alors que YOLO recevrait quelque chose comme :

text
image.jpg
        ↓
pomme : x=..., y=..., largeur=..., hauteur=...

La différence essentielle peut être résumée ainsi :

Concept	CNN classification — MobileNetV2	YOLO détection
Que doit apprendre le modèle ?	Quelle classe représente l’image ?	Quelle classe et où se trouve l’objet ?
Labellisation	✅ Oui	✅ Oui
Bounding box	❌ Généralement non	✅ Oui
Plusieurs objets par image	Problématique en classification classique	✅ Naturellement supporté
Information nécessaire	Classe de l’image	Classe + coordonnées
Exemple	image → pomme	image → pomme à x,y,w,h

Il y a cependant une nuance de vocabulaire importante : dans beaucoup d’articles et d’outils, les mots labelling, labeling et annotation sont parfois utilisés presque comme des synonymes. Techniquement, il est plus précis de dire que la labellisation est une forme simple d’annotation.

On pourrait représenter cela comme :

text
ANNOTATION
   │
   ├── Classification
   │      └── Label de l'image
   │          "Cette image = pomme"
   │
   ├── Object Detection
   │      └── Label + Bounding Box
   │          "Ici se trouve une pomme"
   │
   └── Segmentation
          └── Label + contour précis
              "Ces pixels appartiennent à la pomme"

C’est également la raison pour laquelle la préparation d’un dataset YOLO demande généralement plus de travail humain qu’un dataset CNN de classification.

Imaginez une photo contenant 3 pommes et 2 bananes. Pour un CNN de classification classique, cette image pose déjà une question : quel label lui donner ? pomme ? banane ? Il faudrait éventuellement adapter le problème en classification multi-label.

Avec YOLO, aucun problème : vous dessinez 5 bounding boxes :

text
Image
 ├── pomme 1 → bounding box
 ├── pomme 2 → bounding box
 ├── pomme 3 → bounding box
 ├── banane 1 → bounding box
 └── banane 2 → bounding box

Chaque objet devient une annotation indépendante.

Autre différence pratique : pour MobileNetV2, votre dataset pourrait avoir simplement :

text
dataset/
├── train/
│   ├── classe_A/
│   ├── classe_B/
│   └── classe_C/
├── val/
└── test/

Pour YOLO, on utilise souvent une structure comme :

text
dataset/
├── images/
│   ├── train/
│   ├── val/
│   └── test/
│
└── labels/
    ├── train/
    ├── val/
    └── test/

Ainsi :

text
images/train/image001.jpg

possède généralement son fichier correspondant :

text
labels/train/image001.txt

Et ce fichier .txt contient les objets annotés dans l’image.

Par exemple :

text
0 0.453 0.521 0.218 0.346
0 0.721 0.412 0.175 0.290
1 0.284 0.678 0.194 0.240

Cela signifie que l’image contient trois objets annotés, deux appartenant à la classe 0 et un à la classe 1.

La phrase la plus simple à retenir est donc :

CNN de classification : « Qu’est-ce qu’il y a dans cette image ? »
YOLO : « Qu’est-ce qu’il y a dans cette image, et où se trouve chaque objet ? »

Et donc :

Labellisation = donner un nom/classe.
Annotation YOLO = donner le nom/classe + la localisation de l’objet.

Pour un travail scientifique, vous pourriez même écrire : « Les images utilisées pour le modèle de classification ont été labellisées au niveau image, tandis que celles destinées au modèle YOLO ont été annotées au niveau objet à l’aide de boîtes englobantes (bounding boxes). »

Oui. Cette figure décrit une chaîne complète de préparation d’un dataset d’images, depuis les données brutes jusqu’au dataset final prêt à entraîner un modèle. Elle est particulièrement adaptée à un projet où plusieurs sources de données sont réunies avant l’entraînement d’un CNN de classification comme MobileNetV2 ou d’un détecteur comme YOLOv8-nano.

Il faut surtout comprendre que ces étapes servent à garantir trois choses : qualité des images, cohérence des labels/annotations et absence de fuite de données entre train/validation/test.

1. Data Collection — Collecte des données

C’est le point de départ. On rassemble toutes les images disponibles depuis une ou plusieurs sources : datasets publics, acquisition par caméra, bases internes, images expérimentales, etc.

Objectif : obtenir suffisamment d’exemples représentatifs de toutes les classes que le modèle devra reconnaître.

À cette étape, les données peuvent encore être très hétérogènes : différentes résolutions, différents formats, doublons, images floues, classes nommées différemment, annotations différentes, etc.

Par exemple :

text
Dataset A
Dataset B
Dataset C
Caméra expérimentale
        ↓
Ensemble de données brutes

Il est important de documenter la provenance des données, le nombre d’images, les classes disponibles et les conditions d’acquisition. Pour un travail scientifique, cette traçabilité est très importante.

---

2. Data Filtering — Filtrage des données

Le filtrage consiste à décider quelles données doivent être conservées ou rejetées.

Supposons que vous ayez collecté 20 000 images. Toutes ne seront pas nécessairement utiles.

On peut éliminer par exemple les images hors sujet, totalement noires, extrêmement floues, corrompues, sans objet pertinent, ou incompatibles avec les classes étudiées.

Objectif : éliminer les données qui n’apportent aucune information utile ou qui pourraient dégrader l’apprentissage.

Attention toutefois : une image simplement « difficile » ne doit pas être supprimée automatiquement. Des variations réelles de luminosité, d’angle, de distance ou d’arrière-plan peuvent justement aider le modèle à mieux généraliser.

La question à se poser est donc :

« Cette image représente-t-elle une situation réelle que mon modèle pourrait rencontrer ? »

Si oui, elle peut être utile même si elle n’est pas parfaite.

---

3. Data Cleaning — Nettoyage des données

Le nettoyage est proche du filtrage, mais il est davantage orienté vers la correction des problèmes du dataset.

On recherche notamment les images dupliquées ou quasi dupliquées, fichiers corrompus, labels incorrects, mauvais formats, incohérences de noms, annotations absentes ou images inutilisables.

Par exemple :

text
IMG_001.jpg
IMG_001_copy.jpg
IMG_001(2).jpg

peuvent être trois copies de la même image.

Les doublons sont particulièrement dangereux s’ils se retrouvent ensuite dans différents ensembles :

text
Train → IMG_001.jpg
Test  → IMG_001_copy.jpg

Le modèle aura pratiquement déjà vu l’image de test pendant l’apprentissage. Les performances peuvent alors paraître artificiellement excellentes : c’est une fuite de données (data leakage).

Objectif : obtenir des données propres, uniques et exploitables.

---

4. Class Label Alignment — Harmonisation des classes

Cette étape devient extrêmement importante lorsqu’on utilise plusieurs datasets.

Supposons que trois sources utilisent :

text
Dataset A : Normal / Crack / Corrosion
Dataset B : Healthy / Cracked / Rust
Dataset C : normal / crack / corrosion

Même si certaines classes représentent la même chose, leurs noms diffèrent.

Il faut définir une nomenclature commune :

text
Normal
Crack
Corrosion

puis effectuer une correspondance :

text
Healthy → Normal
Cracked → Crack
Rust    → Corrosion

Objectif : faire en sorte qu’une même classe ait exactement la même signification dans tout le dataset final.

Pour YOLO, il faut aussi aligner les identifiants numériques. Par exemple :

text
0 = Normal
1 = Crack
2 = Corrosion

Un problème très dangereux serait :

text
Dataset A :
0 = Crack
1 = Corrosion

Dataset B :
0 = Corrosion
1 = Crack

Si les datasets sont fusionnés directement, le modèle recevra des informations contradictoires.

Cette étape est donc indispensable avant le Dataset Merging.

---

5. Data Annotation Check — Vérification des annotations

Ici, on vérifie que les labels ou annotations sont réellement corrects.

Cette étape n'est pas exactement la même pour MobileNetV2 et YOLO.

Pour un CNN de classification, on vérifie principalement :

text
image_001.jpg → Crack
image_002.jpg → Normal
image_003.jpg → Corrosion

Il faut vérifier que chaque image appartient réellement à la bonne classe.

Pour YOLO, la vérification est plus exigeante puisque chaque objet possède généralement :

text
class_id x_center y_center width height

On doit donc vérifier à la fois la classe et la bounding box.

Par exemple :

text
┌──────────────────────────────┐
│                              │
│       ┌────────────┐         │
│       │   défaut   │         │
│       └────────────┘         │
│                              │
└──────────────────────────────┘

Il faut contrôler que la boîte englobe correctement l’objet, qu’elle n’est ni trop grande ni trop petite, qu’elle correspond à la bonne classe et qu’aucun objet important n’a été oublié.

Objectif : éviter d’enseigner au modèle des informations incorrectes.

C’est fondamental, car un modèle apprend ce qu’on lui donne. Une annotation incorrecte signifie littéralement qu’on lui apprend une mauvaise réponse.

---

6. Image Resizing — Redimensionnement des images

Les images peuvent venir de plusieurs sources avec des tailles différentes :

text
4000 × 3000
1920 × 1080
1280 × 720
640 × 480
...

Les réseaux neuronaux utilisent généralement une taille d’entrée définie.

Pour MobileNetV2, on rencontre fréquemment par exemple :

text
224 × 224

Pour YOLO, une taille typique peut être :

text
640 × 640

bien que d’autres tailles soient possibles.

Objectif : uniformiser les dimensions et rendre les images compatibles avec l’entrée du modèle.

Mais il faut faire attention au ratio largeur/hauteur.

Si on transforme brutalement une image :

text
1920 × 1080

en :

text
640 × 640

sans préserver les proportions, les objets peuvent être déformés.

Pour YOLO, on utilise souvent des techniques comme le letterboxing : l’image est redimensionnée en conservant ses proportions, puis des marges sont ajoutées.

Autre point crucial pour YOLO : si les images sont physiquement redimensionnées, les coordonnées des bounding boxes doivent rester cohérentes. Les logiciels YOLO modernes gèrent généralement cette transformation automatiquement pendant le chargement des images.

---

7. Dataset Merging — Fusion des datasets

Une fois les différents datasets nettoyés, harmonisés et vérifiés, ils peuvent être réunis.

Par exemple :

text
Dataset A : 3 000 images
Dataset B : 4 500 images
Dataset C : 2 500 images
              ↓
Dataset combiné : 10 000 images

Objectif : créer une base de données unique, plus grande et plus diversifiée.

Mais « fusionner » ne signifie pas simplement copier tous les fichiers dans le même dossier. Il faut notamment contrôler les doublons entre datasets, les noms des fichiers, la distribution des classes, les formats d’annotation et l’origine des images.

Après fusion, on pourrait avoir :

text
Normal      : 6 500
Crack       : 2 500
Corrosion   : 1 000

On constate alors un déséquilibre de classes.

Ce déséquilibre peut influencer l’apprentissage. Il faut donc analyser la distribution avant de passer à l’étape suivante.

---

8. Train / Val / Test Split — Séparation entraînement, validation et test

C’est l’une des étapes les plus importantes.

Le dataset final est divisé en trois parties.

Train sert à apprendre les paramètres du réseau.

Validation sert à surveiller les performances pendant le développement, ajuster certains hyperparamètres ou sélectionner le meilleur modèle.

Test doit rester indépendant et sert à mesurer la performance finale.

Un exemple fréquent est :

text
Train       : 70 %
Validation  : 15 %
Test        : 15 %

ou :

text
Train       : 80 %
Validation  : 10 %
Test        : 10 %

Il n’existe pas un ratio universellement obligatoire.

L’idée fondamentale est :

$$Train \cap Validation \cap Test = \varnothing$$

Autrement dit, les ensembles doivent être indépendants.

Il faut également essayer de conserver une distribution similaire des classes, ce qu’on appelle souvent un split stratifié.

Par exemple :

Ensemble	Normal	Crack	Corrosion
Train	65 %	25 %	10 %
Validation	65 %	25 %	10 %
Test	65 %	25 %	10 %

Il faut être encore plus prudent si plusieurs images proviennent du même sujet, même objet, même patient, même structure ou même vidéo.

Par exemple, si 20 images proviennent du même objet, il vaut mieux éviter :

text
15 images → Train
5 images → Test

car elles peuvent être extrêmement similaires.

Il est souvent préférable d'effectuer une séparation par groupe/source/sujet, selon votre application.

---

9. Final SFCD Dataset Ready — Dataset final prêt

À cette étape, le dataset est considéré comme prêt pour les expériences.

Cela signifie idéalement que les images sont valides, les classes sont harmonisées, les annotations sont vérifiées, les doublons sont supprimés, les dimensions sont compatibles, les ensembles train/validation/test sont définis et leur distribution a été contrôlée.

Vous pouvez ensuite entraîner vos modèles.

Pour MobileNetV2, on pourrait avoir par exemple :

text
SFCD/
├── train/
│   ├── Class_A/
│   ├── Class_B/
│   └── Class_C/
├── val/
│   ├── Class_A/
│   ├── Class_B/
│   └── Class_C/
└── test/
    ├── Class_A/
    ├── Class_B/
    └── Class_C/

Alors que pour YOLO :

text
SFCD/
├── images/
│   ├── train/
│   ├── val/
│   └── test/
│
├── labels/
│   ├── train/
│   ├── val/
│   └── test/
│
└── data.yaml

Dans YOLO, data.yaml indique notamment les classes et les chemins vers les données.

---

Comment comprendre l'ensemble de votre figure

Votre pipeline peut être résumé conceptuellement ainsi :

$$\boxed{\text{Données brutes}}$$ $$\downarrow$$ $$\text{Sélection} \rightarrow \text{Nettoyage} \rightarrow \text{Harmonisation} \rightarrow \text{Vérification}$$ $$\downarrow$$ $$\text{Standardisation} \rightarrow \text{Fusion} \rightarrow \text{Séparation}$$ $$\downarrow$$ $$\boxed{\text{Dataset final}}$$

Et chaque étape répond à une question précise :

Étape	Question principale
Collection	Quelles données avons-nous ?
Filtering	Quelles données sont réellement pertinentes ?
Cleaning	Les données sont-elles propres et uniques ?
Class Label Alignment	Les classes signifient-elles la même chose partout ?
Annotation Check	Les labels et bounding boxes sont-ils corrects ?
Resizing	Les images sont-elles compatibles avec le modèle ?
Merging	Peut-on réunir correctement toutes les sources ?
Train/Val/Test Split	Comment évaluer le modèle sans fuite de données ?
Final Dataset	Les données sont-elles prêtes pour l'entraînement ?

Deux remarques particulièrement importantes sur votre pipeline

Premièrement, l’augmentation de données (Data Augmentation) n’apparaît pas dans votre figure. Si vous utilisez rotation, flip, modification de luminosité, zoom, crop, etc., il faut faire très attention : ces augmentations doivent être appliquées uniquement aux données d’entraînement, jamais de manière à créer des versions similaires d'une même image dans Train et Test.

Donc conceptuellement :

text
Dataset
   ↓
Train / Val / Test
   ↓
Train
   ↓
Data Augmentation
   ↓
Training

Deuxièmement, si vous prévoyez une 5-fold cross-validation, l’étape 8 change légèrement. Au lieu d’avoir simplement un unique Train/Validation, les données d’apprentissage sont réparties en plusieurs folds, tandis qu’un véritable jeu de test indépendant peut idéalement être conservé à part.

Enfin, dans le cadre d’une comparaison MobileNetV2 vs YOLOv8-nano, les étapes 1–4, 7–9 peuvent être très similaires, mais l’étape 5 est fondamentalement différente : MobileNetV2 de classification demande surtout des labels au niveau de l’image, tandis que YOLO exige des annotations au niveau des objets avec leurs bounding boxes. C’est cette différence qui produit ensuite deux formats de datasets différents.