Link to this sectionExplication de l'architecture YOLO : de YOLOv3 à YOLO26#

Chaque modèle Ultralytics YOLO est construit en trois étapes : une backbone qui extrait les caractéristiques, une neck qui les fusionne à travers différentes échelles, et une head qui prédit les boîtes et les classes. Ce guide documente les modules qui composent chaque étape et leur évolution de YOLOv3 à YOLO26, en traçant chaque composant jusqu'à sa définition dans les fichiers de configuration sous ultralytics/cfg/models/ et les classes de modules dans ultralytics/nn/modules/.

Chaque modèle est défini de manière déclarative dans un fichier YAML sous forme de liste ordonnée de couches, où chaque couche suit le format [from, repeats, module, args] : quelles couche(s) l'alimentent, combien de fois le module se répète, la classe de couche (Conv, C3k2, SPPF, Detect, …), et ses arguments de constructeur. Le Guide de configuration YAML du modèle documente ce format — y compris la façon dont repeats et args varient avec la profondeur et la largeur de la variante — ainsi que le système complet de résolution des modules. Ce guide se concentre sur les modules eux-mêmes et sur la manière dont ils ont changé d'une version à l'autre.

Link to this sectionLes trois étapes#

Chaque modèle Ultralytics YOLO achemine l'image à travers trois étapes séquentielles, chacune ayant une fonction distincte :

L'unité fondamentale est le bloc Conv (défini dans conv.py) : une convolution 2D, une batch normalization et une activation SiLU, appliquées en séquence. Chaque module plus large ci-dessous est construit en composant des blocs Conv.

Link to this sectionDiagrammes d'architecture#

Chaque version conserve le même squelette backbone → neck → head et modifie des étapes spécifiques. Les onglets ci-dessous montrent la structure par version : les étapes backbone et neck suivent les configs dans ultralytics/cfg/models/, tandis que les têtes YOLOv3 et YOLOv5 sont dessinées sous leur forme originale basée sur les ancres plutôt que sous la tête u-variant sans ancres que leurs configs de package utilisent réellement. Parcourir les onglets montre ce que chaque génération a ajouté. En résumé, la progression est : YOLOv3 est un détecteur uniquement FPN basé sur les ancres ; YOLOv5 ajoute le chemin PAN ascendant et SPPF ; YOLOv8 passe au bloc C2f avec une tête sans ancres, DFL ; YOLO11 insère l'attention C2PSA et le bloc C3k2 ; et YOLO26 ajoute un résidu SPPF et rend la tête sans NMS et sans DFL. Les couleurs des nœuds suivent la convention des diagrammes de documentation : entrée verte, backbone bleue, pooling spatial et attention gris bleu, neck orange, tête et sortie violettes.

flowchart TD
    IN[Input 640x640]:::start --> ST[Conv stem<br/>5x stride-2 down to P1-P5]:::proc
    ST --> BB[Darknet-53 backbone<br/>stacked Bottleneck]:::proc
    BB --> FPN[Neck FPN only<br/>top-down Upsample + Concat]:::decide
    FPN --> HD[Detect head<br/>3 scales, anchor-based]:::out
    HD --> O[Predictions + NMS]:::out
    classDef start fill:#4CAF50,color:#fff
    classDef proc fill:#2196F3,color:#fff
    classDef decide fill:#FF9800,color:#fff
    classDef out fill:#9C27B0,color:#fff

Les diagrammes YOLOv3 et YOLOv5 montrent la tête originale basée sur les ancres. Le package ultralytics livre les configs YOLOv3u et YOLOv5u sans ancres — les mêmes backbones Darknet-53 et C3 avec la tête Detect de YOLOv8 — décrites dans Detection Head.

Link to this sectionBlocs de backbone : Bottleneck → C3 → C2f → C3k2#

Le backbone empile un bloc CSP (Cross-Stage Partial) répétitif entre des couches de sous-échantillonnage Conv de stride 2. C'est ce bloc répétitif qui a le plus changé au fil des versions. Tous les blocs ci-dessous se trouvent dans block.py ; c1/c2 sont les canaux d'entrée/sortie et c = 0.5 * c2 est la largeur cachée.

Link to this sectionBottleneck (YOLOv3)#

L'unité de base est Bottleneck : deux couches Conv (noyaux par défaut (3, 3)) avec un ajout résiduel optionnel lorsque shortcut=True et c1 == c2. Le backbone Darknet-53 de YOLOv3 les empile directement, sans séparation CSP, et détecte à trois échelles (strides 8, 16, 32).

Link to this sectionC3 (YOLOv5)#

YOLOv5's C3 splits the input across two 1x1 convolutions: cv1 feeds n sequential Bottleneck blocks (kernels (1, 1) then (3, 3)), cv2 bypasses them. The two paths are concatenated and fused by a third 1x1 Conv:

def forward(self, x):
    # C3: bottleneck path m(cv1(x)) concatenated with bypass cv2(x), then fused by cv3
    return self.cv3(torch.cat((self.m(self.cv1(x)), self.cv2(x)), 1))

Seule la sortie du bottleneck final atteint la conv de fusion, donc cv3 voit 2 cartes de caractéristiques.

Link to this sectionC2f (YOLOv8)#

YOLOv8's C2f ("CSP Bottleneck with 2 convolutions, faster") changes which features reach the fusion conv:

1. cv1 = Conv(c1, 2 * c, 1), puis chunk(2) divise la sortie en deux tenseurs de canaux c.
2. n blocs Bottleneck(c, c) (noyaux (3, 3), (3, 3)) s'exécutent séquentiellement, chacun alimenté par la sortie du bloc précédent.
3. Tous les n + 2 tenseurs intermédiaires sont concaténés et fusionnés par cv2 = Conv((2 + n) * c, c2, 1).

Là où C3 passe 2 cartes de caractéristiques dans sa conv de fusion, C2f en passe n + 2 — chaque sortie de bottleneck intermédiaire est réutilisée.

Link to this sectionC3k2 (YOLO11 et YOLO26)#

YOLO11 et YOLO26 utilisent C3k2, une sous-classe de C2f qui échange l'unité répétitive. Chacun des n blocs devient, selon les drapeaux du constructeur :

• un Bottleneck simple (par défaut, c3k=False),
• un bloc C3k (c3k=True) — une variante C3 avec une taille de noyau configurable, ou
• une paire Bottleneck + PSABlock (attn=True).

Le second argument YAML définit c3k ; par exemple [-1, 2, C3k2, [512, True]] construit un module C3k2 à 512 canaux de sortie dont les blocs internes sont C3k (puisque c3k=True). Pour les modules CSP, le champ repeats — ici 2, avant d'être mis à l'échelle par le multiple de profondeur de la variante — devient le nombre de répétitions internes du bloc au lieu d'empiler des modules séparés.

Link to this sectionSpatial Pooling : SPP → SPPF#

At the end of the backbone, a spatial-pyramid-pooling block widens the receptive field. YOLOv5 replaced the original multi-kernel SPP with SPPF (Spatial Pyramid Pooling - Fast): a single MaxPool2d(kernel_size=5, stride=1, padding=2) applied n = 3 times in sequence, with the input and all three pooled outputs concatenated and fused by a 1x1 Conv. This is mathematically equivalent to SPP(k=(5, 9, 13)) but cheaper, because the chained 5x5 pools cover the larger kernels' receptive fields.

YOLO26 passe un drapeau shortcut (SPPF, [1024, 5, 3, True]) ; puisque c1 == c2 == 1024 à la couche la plus profonde, SPPF ajoute une connexion résiduelle (return y + x).

Link to this sectionSpatial Attention : C2PSA (YOLO11+)#

YOLO11 a ajouté C2PSA après SPPF. C'est un bloc CSP dont la branche active est une pile de n modules PSABlock (Position-Sensitive Attention) : cv1 = Conv(c1, 2 * c, 1) divise les caractéristiques, une moitié passe par la pile PSABlock, et cv2 = Conv(2 * c, c1, 1) fusionne la concaténation. Chaque PSABlock applique une attention multi-têtes suivie d'un réseau feed-forward à deux couches (Conv(c, 2 * c, 1) → Conv(2 * c, c, 1)), chacun avec une connexion résiduelle. YOLO26 conserve le même backbone C3k2 + C2PSA.

Link to this sectionNeck : FPN + PAN#

Le neck fusionne les cartes de caractéristiques P3/P4/P5 du backbone avec un Feature Pyramid Network (FPN) descendant suivi d'un Path Aggregation Network (PAN) ascendant. Dans la section de tête YAML, le FPN est nn.Upsample + Concat (transportant les informations sémantiques vers des résolutions plus élevées) et le PAN est Conv stride 2 + Concat (transportant les informations de localisation vers le haut) :

# YOLO11 head (FPN top-down, then PAN bottom-up)
- [-1, 1, nn.Upsample, [None, 2, "nearest"]]
- [[-1, 6], 1, Concat, [1]] # cat backbone P4
- [-1, 2, C3k2, [512, False]] # 13
# ... second upsample + concat to P3 ...
- [-1, 1, Conv, [256, 3, 2]]
- [[-1, 13], 1, Concat, [1]] # cat head P4 (PAN)
- [-1, 2, C3k2, [512, False]] # 19

Le neck réutilise le bloc de backbone de sa génération — C3 dans YOLOv5, C2f dans YOLOv8, C3k2 dans YOLO11 et YOLO26 — donc chaque point de fusion exécute le même module que le backbone utilise. Les trois sorties fusionnées alimentent la tête. YOLOv3 est l'exception : son neck est uniquement FPN descendant (sa tête YAML n'a pas de sous-échantillonnage stride 2), sans le chemin PAN ascendant introduit par YOLOv5.

Link to this sectionDetection Head : Anchor-Based → Anchor-Free → NMS-Free#

La tête transforme les trois cartes de caractéristiques fusionnées en prédictions pour la tâche de détection. Sa conception a changé au fil des versions, de basée sur les ancres à sans ancres puis sans NMS.

Link to this sectionTête Detect découplée et sans ancres#

Les YOLOv3 et YOLOv5 originaux utilisaient une tête couplée basée sur les ancres : des boîtes d'ancrage prédéfinies et une branche partagée pour les prédictions de boîte et de classe. Les dépôts autonomes ultralytics/yolov3 et ultralytics/yolov5 conservent cette conception basée sur les ancres. Le package principal ultralytics livre plutôt les variantes YOLOv3u et YOLOv5u sans ancres — les mêmes backbones Darknet-53 et C3 avec la tête Detect sans ancres de YOLOv8 — et les configs yolov3.yaml et yolov5.yaml documentées ici sont ces variantes u, et non la conception historique.

La tête Detect (head.py) est sans ancres et découplée : par niveau de pyramide, elle exécute deux branches parallèles et prédit directement sur les points de la grille plutôt que contre des boîtes d'ancrage.

• Branche boîte (cv2) : Conv(x, c2, 3) → Conv(c2, c2, 3) → Conv2d(c2, 4 * reg_max, 1).
• Branche classe (cv3) : dans YOLO11 et YOLO26, deux blocs séparables en profondeur (DWConv + 1x1 Conv) → Conv2d(c3, nc, 1) ; YOLOv8 utilise la variante héritée, deux couches 3x3 Conv → Conv2d(c3, nc, 1).

Chaque point d'ancrage émet donc no = nc + 4 * reg_max sorties. La suppression des ancres prédéfinies élimine les tailles et les rapports d'aspect des boîtes d'ancrage des hyperparamètres à régler.

Link to this sectionDistribution Focal Loss (DFL)#

YOLOv8 et YOLO11 régressent chacune des 4 coordonnées de boîte comme une distribution sur reg_max = 16 bacs plutôt que comme un scalaire unique (la forme intégrale de Generalized Focal Loss). Le module DFL reformate les 4 * reg_max canaux de boîte en (4, reg_max), applique une softmax sur les reg_max bacs, et prend l'index de bac attendu — chaque index de bac pondéré par sa probabilité softmax, puis sommé — comme la coordonnée prédite. Ceci est implémenté comme une convolution 1x1 fixe dont les poids sont les indices de bac arange(reg_max), donc la somme pondérée est un simple produit scalaire.

Link to this sectionYOLO26 : sans NMS, sans DFL#

YOLO26 définit deux paramètres YAML que la tête lit directement :

• end2end: True — Detect copie ses branches dans une tête un-à-un (one2one_cv2/one2one_cv3) qui produit une seule prédiction par objet, supprimant l'étape de post-traitement de Non-Maximum Suppression (NMS). Voir le guide de détection End-to-End pour les détails d'exportation et de migration.
• reg_max: 1 — avec un bac, self.dfl devient nn.Identity() et no = nc + 4 ; la tête régresse directement les coordonnées et aucune opération DFL n'apparaît dans le graphe ONNX exporté.

À travers ses cinq tailles de modèle (n/s/m/l/x), YOLO26 atteint 40,9-57,5 mAP sur COCO à 1,7-11,8 ms de latence TensorRT sur T4, tel que rapporté dans le papier YOLO26.

Link to this sectionRésumé version par version#

Pour des détails par modèle, des tableaux de performance et des exemples d'utilisation, consultez les pages individuelles pour YOLOv3, YOLOv5, YOLOv8, YOLO11 et YOLO26.

Link to this sectionInspectez l'architecture par vous-même#

La méthode model.info() imprime un résumé des couches, des paramètres et des FLOPs, et la liste des modules analysés est disponible sur model.model.model.

from ultralytics import YOLO

# Load a pretrained model
model = YOLO("yolo11n.pt")

# Fuse Conv + BatchNorm layers so counts match the published specs
model.fuse()

# Print a summary: layers, parameters, gradients, GFLOPs
model.info()

# Inspect the detection head (the last module in the network)
head = model.model.model[-1]
print(type(head).__name__, "| reg_max:", head.reg_max, "| end2end:", head.end2end)

Exécuter l'extrait sur trois générations montre les changements numériquement. Ce sont de vraies sorties de modèles fusionnés du package ultralytics, correspondant aux nombres de paramètres et de FLOPs publiés sur chaque page de modèle :

YOLO26n rapporte reg_max=1, end2end=True, et une couche DFL Identity — la signature architecturale de sa tête sans NMS et sans DFL.

Link to this sectionConclusion#

Au fil des versions, l'architecture YOLO a évolué étape par étape : le backbone est passé de Darknet-53 aux blocs C3, C2f et C3k2 basés sur CSP avec une attention C2PSA ; le neck a conservé sa structure FPN + PAN tandis que SPP est devenu SPPF ; et la tête est passée d'un système basé sur des ancres à un système sans ancres, puis vers la conception end-to-end sans NMS et sans DFL de YOLO26.

Pour définir des architectures personnalisées, consulte le Guide de configuration YAML du modèle, ou compare les modèles sur les pages des modèles. Pour toute question, contacte-nous sur GitHub ou Discord.

Link to this sectionFAQ#

Link to this sectionQuelles sont les trois étapes d'une architecture YOLO ?#

Un modèle YOLO possède un backbone qui extrait les caractéristiques de l'image aux strides 8, 16 et 32, un neck qui fusionne ces caractéristiques à travers différentes échelles avec FPN et PAN, et une head qui prédit les boîtes englobantes et les scores de classe. Chaque modèle Ultralytics YOLO, de YOLOv3 à YOLO26, suit cette conception en trois étapes.

Link to this sectionQuelle est la différence entre les blocs C2f et C3k2 ?#

C2f (YOLOv8) est un bloc CSP qui concatène les sorties de chaque Bottleneck interne — n + 2 cartes de caractéristiques — avant sa convolution de fusion, là où l'ancien C3 n'en passe que 2. C3k2 (YOLO11 et YOLO26) est une sous-classe de C2f qui peut remplacer chaque Bottleneck par un bloc C3k (une variante de C3 avec une taille de noyau configurable) lorsque son flag c3k est activé. Les deux sont définis dans block.py.

Link to this sectionQu'est-ce qui a changé dans l'architecture entre YOLOv8 et YOLO11 ?#

YOLO11 apporte trois changements structurels à YOLOv8 : il remplace le bloc backbone et neck C2f par C3k2, insère un bloc d'auto-attention C2PSA après SPPF, et fait passer la branche de classification de la tête à des convolutions séparables en profondeur plus légères. Les deux conservent la même tête Detect découplée et sans ancres avec une régression DFL reg_max=16, donc ces changements réduisent le nombre de paramètres et de FLOPs tout en augmentant la précision plutôt que de refondre l'interface de détection.

Link to this sectionYOLO est-il sans ancres (anchor-free) ?#

Les modèles modernes Ultralytics YOLO sont sans ancres. YOLOv8, YOLO11 et YOLO26 utilisent une tête Detect découplée et sans ancres avec des branches séparées pour la régression des boîtes et la classification. Les YOLOv3 et YOLOv5 originaux étaient basés sur des ancres, mais Ultralytics les propose sous forme de variantes YOLOv3u et YOLOv5u, dont les configurations utilisent la même tête sans ancres que YOLOv8.

Link to this sectionYOLO26 a-t-il supprimé le NMS ?#

Oui — YOLO26 définit end2end=True, ce qui donne à Detect une tête un-à-un qui produit une seule prédiction par objet et supprime l'étape de post-traitement Non-Maximum Suppression requise par les modèles précédents. Consulte le guide de détection End-to-End pour plus de détails.

Link to this sectionQu'est-ce que la Distribution Focal Loss (DFL) et pourquoi YOLO26 l'a-t-il supprimée ?#

La DFL régresse chaque coordonnée de boîte comme une distribution softmax sur reg_max bins (16 par défaut dans YOLOv8 et YOLO11) et prend la valeur attendue comme coordonnée, plutôt que de prédire un scalaire unique. YOLO26 définit reg_max=1, donc la couche DFL devient une opération identité, la tête régresse les coordonnées directement, et aucune opération DFL n'apparaît dans les graphes ONNX ou TensorRT exportés.

Link to this sectionComment puis-je voir l'architecture d'un modèle YOLO spécifique ?#

Charge le modèle en Python et appelle model.info() pour obtenir un résumé des couches, des paramètres et des GFLOPs. Les couches parsées se trouvent dans model.model.model — par exemple, model.model.model[-1] est la tête Detect, exposant des attributs comme reg_max et end2end. L'architecture complète est définie dans le fichier de configuration YAML du modèle.