Fine-tuning YOLO v11 sur un dataset métier : tutoriel pas-à-pas

📍 Guide principal : Détection d’objets en 2026 : pipeline YOLO v11 + Ultralytics + Roboflow. Avant de fine-tuner, il faut un modèle de base — voir Entraîner YOLO v11 sur un dataset Roboflow.

Le fine-tuning n’est pas un entraînement bis. C’est une opération chirurgicale qui prend un modèle déjà entraîné — typiquement les poids COCO de YOLO v11 ou un modèle métier pré-existant — et adapte ses dernières couches à un nouveau dataset, plus petit et plus spécifique. Bien fait, il atteint en quelques minutes ce qu’un entraînement complet n’obtient qu’en heures, parce qu’il s’appuie sur les représentations visuelles bas niveau déjà apprises (textures, formes, contrastes). Mal fait, il détruit ces représentations et donne un modèle plus mauvais que l’original. Ce tutoriel décrit le bon dosage : quelles couches geler, quel learning rate, combien d’époques, comment détecter un sur-apprentissage en cours de route.

Prérequis

• Un dataset Roboflow ou local au format YOLO (cf. tutoriel d’entraînement).
• Un modèle de départ : soit un checkpoint COCO d’Ultralytics (yolo11n.pt, yolo11s.pt…), soit un modèle métier déjà entraîné (best.pt d’une session précédente).
• YOLO v11 et Ultralytics installés (cf. installation).
• GPU avec au moins 6 Go de VRAM pour YOLO11s, 12 Go pour YOLO11m.
• Niveau attendu : avoir déjà lancé un entraînement model.train au moins une fois.
• Temps estimé : 30 à 90 minutes selon la taille du dataset.

Étape 1 — Comprendre quand fine-tuner et quand ré-entraîner

Fine-tuning et entraînement classique « from scratch » ne répondent pas aux mêmes situations. Le réflexe d’utiliser le fine-tuning par défaut est généralement bon, mais il faut savoir reconnaître les cas où un entraînement complet à partir des poids COCO donne un meilleur résultat. La règle empirique tient en trois points : si votre nouveau dataset partage des classes avec COCO (personne, voiture, animal), fine-tuning depuis YOLO11 COCO fonctionne très bien et converge vite. Si vos classes sont totalement étrangères à COCO (composants électroniques, lésions médicales, fissures de béton), le fine-tuning fonctionne aussi mais peut nécessiter de dégeler plus de couches. Si vous avez des dizaines de milliers d’images, l’entraînement complet redevient pertinent et bat parfois le fine-tuning, parce que le modèle peut adapter toutes ses couches à votre distribution d’images.

Concrètement, sur un projet métier typique avec 500 à 5000 images annotées, fine-tuner YOLO11s.pt en gelant le backbone et en n’entraînant que le head est le compromis qui marche dans 80 % des cas. C’est la stratégie que ce tutoriel détaille.

Étape 2 — Geler les couches du backbone

YOLO v11 est structuré en trois grands blocs : un backbone qui extrait les caractéristiques bas et moyen niveau (les premières couches conv), un neck qui combine les caractéristiques à plusieurs échelles (FPN-PAN), et un head qui produit boîtes et classes. Le backbone est ce qu’on a appris pendant des semaines sur ImageNet+COCO — pas envie d’y toucher pour un dataset de 1000 images. Le neck et le head, en revanche, doivent absolument s’adapter à vos classes. La technique consiste à geler le backbone (pas de calcul de gradients, donc pas de mise à jour) et n’entraîner que les couches qui suivent.

Avec Ultralytics, la flag freeze de model.train indique combien de couches à geler depuis le début du réseau. YOLO11 compte 23 modules indexés (0 à 22) dont les 11 premiers (indices 0 à 10) forment le backbone. Geler ces 11 premiers modules revient donc à ne ré-entraîner que neck + head. Voici la commande complète :

from ultralytics import YOLO

model = YOLO("yolo11s.pt")  # poids COCO ou un best.pt antérieur
results = model.train(
    data="./mon-dataset/data.yaml",
    epochs=50,
    imgsz=640,
    batch=16,
    device=0,
    freeze=11,         # gèle les 11 premiers modules (backbone complet)
    lr0=1e-3,          # learning rate initial réduit pour fine-tuning
    lrf=1e-2,          # ratio de décroissance final (lr0 * lrf en fin)
    pretrained=True,
    project="runs/finetune",
    name="finetune-v1"
)

Pendant l’entraînement, vous verrez dans les logs Ultralytics une ligne « freezing layer ‘model.0.conv.weight’ » répétée pour chaque paramètre gelé. Si cette ligne n’apparaît pas, la flag n’a pas été prise en compte — vérifier l’orthographe et la version d’Ultralytics. La consommation mémoire baisse aussi de 30 à 40 % par rapport à un entraînement plein, ce qui permet d’augmenter batch ou imgsz à VRAM constante.

Étape 3 — Ajuster le learning rate

Le learning rate par défaut d’Ultralytics (lr0=0.01) est calibré pour un entraînement à partir de zéro, pas pour un fine-tuning. À ce rythme, les couches dégelées vont bouger trop vite et risquent d’effacer la connaissance pré-acquise — phénomène appelé catastrophic forgetting. La règle pratique est de diviser le learning rate par dix : lr0=1e-3 au lieu de 1e-2. Combiné avec la décroissance par défaut (cosine schedule), le modèle converge proprement sans casser ce qu’il sait déjà.

Pour un fine-tuning encore plus prudent (par exemple à partir d’un modèle métier déjà bien entraîné qu’on adapte à un nouveau site géographique), on peut descendre à lr0=5e-4. À l’inverse, si après 50 époques la mAP plafonne sans progresser, c’est probablement que le learning rate est trop bas et que les gradients sont étouffés ; remonter à 1e-3 ou dégeler quelques couches supplémentaires.

Le warmup (montée progressive du learning rate sur les premières époques) reste important même en fine-tuning. Ultralytics applique 3 époques de warmup par défaut via warmup_epochs=3 ; gardez cette valeur, elle évite les divergences de loss au démarrage.

Étape 4 — Surveiller le sur-apprentissage en temps réel

Le sur-apprentissage (overfitting) est l’ennemi principal du fine-tuning sur petit dataset. Symptôme : les métriques de train continuent à s’améliorer alors que celles de validation stagnent ou se dégradent. Ultralytics imprime à chaque époque les deux séries de métriques côte à côte. Surveillez la divergence entre box_loss de train et val/box_loss. Tant que la val descend en parallèle de la train, tout va bien. Dès que la val remonte alors que la train continue à descendre, vous êtes en sur-apprentissage.

Trois leviers pour le contrer : early stopping (Ultralytics expose un argument patience qui arrête l’entraînement si la val ne s’améliore pas pendant N époques consécutives. Le défaut est 100, ce qui revient en pratique à laisser tourner toute la session ; pour un fine-tuning court, descendre explicitement à patience=10 ou 15), augmentations plus agressives au niveau Roboflow (mosaic, mixup), ou simplement réduire le nombre d’époques. Pour ce tutoriel, passer patience=10 à model.train et laisser l’entraînement s’arrêter automatiquement quand il aura atteint son maximum.

À la fin de l’entraînement, ouvrez runs/finetune/finetune-v1/results.png qui résume toutes les métriques sur un seul graphique. Si la courbe de val mAP a un pic puis redescend, le checkpoint best.pt sauvegardé correspond à ce pic et reste votre meilleur modèle, indépendamment de la valeur finale.

Étape 5 — Fine-tuning incrémental sur nouvelles images

En production, on n’arrête pas le fine-tuning au premier modèle. À mesure que de nouvelles images arrivent depuis les caméras de production (faux positifs corrigés, faux négatifs signalés), on les ré-injecte dans Roboflow et on lance un nouveau fine-tuning à partir du best.pt précédent — pas du checkpoint COCO. Cette boucle d’amélioration continue garde le modèle à jour avec le drift naturel des données.

model = YOLO("./runs/finetune/finetune-v1/weights/best.pt")
model.train(
    data="./mon-dataset-v2/data.yaml",  # version 2 avec nouvelles images
    epochs=20,                           # moins d'époques car déjà adapté
    imgsz=640,
    batch=16,
    freeze=11,
    lr0=5e-4,                            # encore plus prudent
    project="runs/finetune",
    name="finetune-v2"
)

Le nouveau modèle hérite des connaissances de v1 et apprend les nouveaux cas. Comparez les mAP par classe entre v1 et v2 : les classes anciennes ne doivent pas se dégrader (sinon catastrophic forgetting), et les classes ou les conditions ajoutées doivent progresser. Si v2 dégrade des classes anciennes, fusionner les datasets v1 et v2 plutôt que de remplacer.

Étape 6 — Vérifier la qualité finale par classe

L’agrégation mAP globale cache parfois des disparités par classe. Une classe sous-représentée dans le dataset peut avoir une mAP de 0,3 alors que la moyenne globale affiche 0,75. Pour un projet métier, ces disparités sont critiques — une caisse mal détectée dans un entrepôt coûte cher. Le rapport détaillé d’Ultralytics donne ces chiffres :

metrics = model.val(data="./mon-dataset/data.yaml")
for i, name in enumerate(metrics.names.values()):
    print(f"{name}: P={metrics.box.p[i]:.3f} R={metrics.box.r[i]:.3f} mAP50-95={metrics.box.maps[i]:.3f}")

La sortie liste chaque classe avec sa précision, son rappel et sa mAP50. Identifiez les classes les plus faibles. Pour chacune, deux pistes : ajouter 50-100 images supplémentaires dans Roboflow (le levier le plus efficace), ou re-pondérer la fonction de loss via le paramètre cls du training pour augmenter le poids de ces classes (levier secondaire, à utiliser avec prudence pour ne pas dégrader les autres).

Dépannage rapide

Tutoriels du même thème

• Exporter YOLO v11 en ONNX et TensorRT — étape suivante naturelle après fine-tuning.
• Surveiller la dérive d’un modèle YOLO en production — pour déclencher les fine-tunings au bon moment.

Lectures complémentaires

• 🔝 Vue d’ensemble : Pipeline YOLO v11
• Documentation arguments training : docs.ultralytics.com/modes/train
• Article de référence sur transfer learning en vision : cs231n.github.io/transfer-learning

Une fois le fine-tuning satisfaisant, l’étape suivante est l’export du modèle vers le format de déploiement (ONNX pour la portabilité, TensorRT pour la vitesse maximale sur GPU NVIDIA).