{"notes":[{"id":"object-detection/yolo26","category":"object-detection","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"YOLO26","subtitle":"On garde les deux têtes","author":"Z. Yuan","paperDate":"2026-06-02","publishedOn":"2026-10-07","paperTitle":"Ultralytics YOLO26: Unified Real-Time End-to-End Vision Models","paperUrl":"https://arxiv.org/abs/2606.03748","bibliography":{"title":"Ultralytics YOLO26: Unified Real-Time End-to-End Vision Models","authors":["Glenn Jocher","Jing Qiu","Mengyu Liu","Shuai Lyu","Fatih Cagatay Akyon","Muhammet Esat Kalfaoglu"],"url":"https://arxiv.org/abs/2606.03748","pdfUrl":"https://arxiv.org/pdf/2606.03748v1","codeUrl":"https://github.com/ultralytics/ultralytics","preprint":{"id":"2606.03748","submittedOn":"2026-06-02","url":"https://arxiv.org/abs/2606.03748"},"publication":null,"citation":"@misc{objectdetectionyolo262026,\n  title = {{Ultralytics YOLO26: Unified Real-Time End-to-End Vision Models}},\n  author = {Glenn Jocher and Jing Qiu and Mengyu Liu and Shuai Lyu and Fatih Cagatay Akyon and Muhammet Esat Kalfaoglu},\n  year = {2026},\n  eprint = {2606.03748},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2606.03748}\n}\n","citationPath":"/content/papers/citations/object-detection/yolo26.d5782368677d.bib"},"thumbnail":{"src":"/content/papers/assets/81b8a4e821bdb84f6040563add1c1f2341963826d993348c64cab2715e5d6e93.png","width":1494,"height":367},"locale":"fr","path":"/content/papers/fr/object-detection/yolo26.651904ef3c54.md","headings":[{"id":"définir-le-problème","text":"Définir le problème","depth":2},{"id":"résoudre-le-problème","text":"Résoudre le problème","depth":2},{"id":"procédure-dentraînement","text":"Procédure d'entraînement","depth":3},{"id":"deux-têtes-chacune-ses-positifs","text":"Deux têtes, chacune ses positifs","depth":3},{"id":"perte-progressive","text":"Perte progressive","depth":3},{"id":"supprimer-la-dfl","text":"Supprimer la DFL","depth":3},{"id":"stal","text":"STAL","depth":3},{"id":"musgd","text":"MuSGD","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"de-yolo11s-à-yolo26s-pas-à-pas","text":"De YOLO11s à YOLO26s, pas à pas","depth":3},{"id":"la-répartition-des-poids","text":"La répartition des poids","depth":3},{"id":"trois-autres-ablations","text":"Trois autres ablations","depth":3},{"id":"combien-décart-entre-les-deux-têtes","text":"Combien d'écart entre les deux têtes","depth":3},{"id":"les-chiffres-phares-viennent-des-deux-têtes","text":"Les chiffres phares viennent des deux têtes","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"object-detection/yolov10","relation":"referenced","topic":""},{"id":"object-detection/gfl","relation":"referenced","topic":""},{"id":"object-detection/tood","relation":"referenced","topic":""}]},{"id":"object-detection/yolov10","category":"object-detection","legacyPath":"object-detection/2405-yolov10","legacySlug":"2405-yolov10","legacyPaths":[],"title":"YOLOv10","subtitle":"Adieu, NMS","author":"Z. Yuan","paperDate":"2024-05-23","publishedOn":"2025-07-19","paperTitle":"YOLOv10: Real-Time End-to-End Object Detection","paperUrl":"https://proceedings.neurips.cc/paper_files/paper/2024/hash/c34ddd05eb089991f06f3c5dc36836e0-Abstract-Conference.html","bibliography":{"title":"YOLOv10: Real-Time End-to-End Object Detection","authors":["Ao Wang","Hui Chen","Lihao Liu","Kai Chen","Zijia Lin","Jungong Han","Guiguang Ding"],"url":"https://proceedings.neurips.cc/paper_files/paper/2024/hash/c34ddd05eb089991f06f3c5dc36836e0-Abstract-Conference.html","pdfUrl":"https://proceedings.neurips.cc/paper_files/paper/2024/file/c34ddd05eb089991f06f3c5dc36836e0-Paper-Conference.pdf","codeUrl":"https://github.com/THU-MIG/yolov10","preprint":{"id":"2405.14458","submittedOn":"2024-05-23","url":"https://arxiv.org/abs/2405.14458"},"publication":{"venue":"NeurIPS","year":2024,"kind":"conference","url":"https://proceedings.neurips.cc/paper_files/paper/2024/hash/c34ddd05eb089991f06f3c5dc36836e0-Abstract-Conference.html"},"citation":"@misc{objectdetectionyolov102024,\n  title = {{YOLOv10: Real-Time End-to-End Object Detection}},\n  author = {Ao Wang and Hui Chen and Lihao Liu and Kai Chen and Zijia Lin and Jungong Han and Guiguang Ding},\n  year = {2024},\n  eprint = {2405.14458},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2405.14458}\n}\n","citationPath":"/content/papers/citations/object-detection/yolov10.f624ec9e20b6.bib"},"thumbnail":{"src":"/content/papers/assets/43843817d1e6667933eb36b7b588db3ca318fe74e00d2d47095426923f3a5b44.jpg","width":1614,"height":536},"locale":"fr","path":"/content/papers/fr/object-detection/yolov10.81070e8e6ec5.md","headings":[{"id":"définir-le-problème","text":"Définir le problème","depth":2},{"id":"résoudre-le-problème","text":"Résoudre le problème","depth":2},{"id":"double-attribution-des-étiquettes","text":"Double attribution des étiquettes","depth":3},{"id":"optimisation-de-lefficacité-et-de-la-précision","text":"Optimisation de l'efficacité et de la précision","depth":3},{"id":"renforcements-axés-sur-la-précision","text":"Renforcements axés sur la précision","depth":3},{"id":"détails-de-mise-en-œuvre","text":"Détails de mise en œuvre","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"comparaison-avec-létat-de-lart","text":"Comparaison avec l'état de l'art","depth":3},{"id":"études-dablation","text":"Études d'ablation","depth":3},{"id":"le-système-sans-nms-remplace-t-il-vraiment-lapproche-classique-","text":"Le système sans NMS remplace-t-il vraiment l'approche classique ?","depth":3},{"id":"pourquoi-alléger-le-réseau-ne-détruit-il-pas-la-précision-","text":"Pourquoi alléger le réseau ne détruit-il pas la précision ?","depth":3},{"id":"plus-de-précision-pour-presque-la-même-latence-","text":"Plus de précision, pour presque la même latence ?","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"object-detection/yolov11","relation":"comparison","topic":"Architectures récentes de détection en temps réel"},{"id":"object-detection/yolo-tiny","relation":"comparison","topic":"Architectures récentes de détection en temps réel"}]},{"id":"object-detection/gfl","category":"object-detection","legacyPath":"object-detection/2006-gfl","legacySlug":"2006-gfl","legacyPaths":[],"title":"GFL","subtitle":"Le point de convergence","author":"Z. Yuan","paperDate":"2020-06-08","publishedOn":"2025-08-23","paperTitle":"Generalized Focal Loss: Learning Qualified and Distributed Bounding Boxes for Dense Object Detection","paperUrl":"https://arxiv.org/abs/2006.04388","bibliography":{"title":"Generalized Focal Loss: Learning Qualified and Distributed Bounding Boxes for Dense Object Detection","authors":["Xiang Li","Wenhai Wang","Lijun Wu","Shuo Chen","Xiaolin Hu","Jun Li","Jinhui Tang","Jian Yang"],"url":"https://arxiv.org/abs/2006.04388","pdfUrl":"https://proceedings.neurips.cc/paper_files/paper/2020/file/f0bda020d2470f2e74990a07a607ebd9-Paper.pdf","codeUrl":"https://github.com/implus/GFocal","preprint":{"id":"2006.04388","submittedOn":"2020-06-08","url":"https://arxiv.org/abs/2006.04388"},"publication":{"venue":"NeurIPS","year":2020,"kind":"conference","url":"https://papers.nips.cc/paper_files/paper/2020/hash/f0bda020d2470f2e74990a07a607ebd9-Abstract.html"},"citation":"@misc{objectdetectiongfl2020,\n  title = {{Generalized Focal Loss: Learning Qualified and Distributed Bounding Boxes for Dense Object Detection}},\n  author = {Xiang Li and Wenhai Wang and Lijun Wu and Shuo Chen and Xiaolin Hu and Jun Li and Jinhui Tang and Jian Yang},\n  year = {2020},\n  eprint = {2006.04388},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2006.04388}\n}\n","citationPath":"/content/papers/citations/object-detection/gfl.71fabce4b963.bib"},"thumbnail":{"src":"/content/papers/assets/b23270560323cea28f3b1fe736d861dd3365d20c4fb99278dcc3ce306df890dc.jpg","width":1224,"height":380},"locale":"fr","path":"/content/papers/fr/object-detection/gfl.bfe7d892ca7e.md","headings":[{"id":"définir-le-problème","text":"Définir le problème","depth":2},{"id":"résoudre-le-problème","text":"Résoudre le problème","depth":2},{"id":"focal-loss","text":"Focal Loss","depth":3},{"id":"quality-focal-loss","text":"Quality Focal Loss","depth":3},{"id":"distribution-focal-loss","text":"Distribution Focal Loss","depth":3},{"id":"generalized-focal-loss","text":"Generalized Focal Loss","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"qfl-est-elle-utile-","text":"QFL est-elle utile ?","depth":3},{"id":"dfl-est-elle-utile-","text":"DFL est-elle utile ?","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"object-detection/fcos","relation":"comparison","topic":"Aligner classification et qualité de localisation"},{"id":"object-detection/tood","relation":"comparison","topic":"Aligner classification et qualité de localisation"}]},{"id":"object-detection/tood","category":"object-detection","legacyPath":"object-detection/2108-tood","legacySlug":"2108-tood","legacyPaths":[],"title":"TOOD","subtitle":"La fin du décalage","author":"Z. Yuan","paperDate":"2021-08-17","publishedOn":"2025-08-30","paperTitle":"TOOD: Task-aligned One-stage Object Detection","paperUrl":"https://arxiv.org/abs/2108.07755","bibliography":{"title":"TOOD: Task-aligned One-stage Object Detection","authors":["Chengjian Feng","Yujie Zhong","Yu Gao","Matthew R. Scott","Weilin Huang"],"url":"https://arxiv.org/abs/2108.07755","pdfUrl":"https://openaccess.thecvf.com/content/ICCV2021/papers/Feng_TOOD_Task-Aligned_One-Stage_Object_Detection_ICCV_2021_paper.pdf","codeUrl":"https://github.com/fcjian/TOOD","preprint":{"id":"2108.07755","submittedOn":"2021-08-17","url":"https://arxiv.org/abs/2108.07755"},"publication":{"venue":"ICCV","year":2021,"kind":"conference","url":"https://openaccess.thecvf.com/content/ICCV2021/html/Feng_TOOD_Task-Aligned_One-Stage_Object_Detection_ICCV_2021_paper.html"},"citation":"@misc{objectdetectiontood2021,\n  title = {{TOOD: Task-aligned One-stage Object Detection}},\n  author = {Chengjian Feng and Yujie Zhong and Yu Gao and Matthew R. Scott and Weilin Huang},\n  year = {2021},\n  eprint = {2108.07755},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2108.07755}\n}\n","citationPath":"/content/papers/citations/object-detection/tood.4de53d61811e.bib"},"thumbnail":{"src":"/content/papers/assets/d5560386911d14104af5e1609a50f0af6db4f571f764de0e5f60f48ff30f4584.jpg","width":904,"height":772},"locale":"fr","path":"/content/papers/fr/object-detection/tood.36ea7f0f4c72.md","headings":[{"id":"définir-le-problème","text":"Définir le problème","depth":2},{"id":"résoudre-le-problème","text":"Résoudre le problème","depth":2},{"id":"caractéristiques-interactives-des-tâches","text":"Caractéristiques interactives des tâches","depth":3},{"id":"attention-entre-niveaux-dans-tap","text":"Attention entre niveaux dans TAP","depth":3},{"id":"alignement-explicite--m-et-o","text":"Alignement explicite : M et O","depth":3},{"id":"attribution-déchantillons-alignée-sur-les-tâches","text":"Attribution d'échantillons alignée sur les tâches","depth":3},{"id":"construction-des-pertes","text":"Construction des pertes","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"la-t-head-vaut-elle-le-remplacement-","text":"La T-head vaut-elle le remplacement ?","depth":3},{"id":"essai-de-tal","text":"Essai de TAL","depth":3},{"id":"tood-complet","text":"TOOD complet","depth":3},{"id":"face-à-létat-de-lart","text":"Face à l'état de l'art","depth":3},{"id":"lalignement-a-t-il-vraiment-lieu-","text":"L'alignement a-t-il vraiment lieu ?","depth":3},{"id":"comment-le-décalage-est-il-réduit-","text":"Comment le décalage est-il réduit ?","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[{"id":"object-detection/fcos","relation":"comparison","topic":"Aligner classification et qualité de localisation"},{"id":"object-detection/gfl","relation":"comparison","topic":"Aligner classification et qualité de localisation"}]}],"text":"YOLO26 est le modèle de détection d'objets en temps réel d'Ultralytics. Ultralytics est l'entreprise qui maintient la bibliothèque open source `ultralytics`, et YOLOv5, YOLOv8 et YOLO11 sortent tous de chez elle. Donnez une photo à YOLO26, il renvoie une liste de boîtes, chacune accompagnée d'une classe et d'un score de confiance ; le même backbone sert aussi à la segmentation d'instances, à l'estimation de pose, à la détection de boîtes orientées et à la classification d'images. Le modèle existe en cinq tailles, n, s, m, l et x ; la plus petite, n, ne compte que 2,4 millions de paramètres et vise les appareils en périphérie à la puissance de calcul limitée, comme les téléphones et les cartes embarquées.\n\nIl fait sa première apparition le 25 septembre 2025 à YOLO Vision 2025, organisé par Ultralytics à Londres, et sort officiellement le 14 janvier 2026 avec `ultralytics` 8.4.0. Le premier point des notes de version est la conception nativement de bout en bout, qui se passe entièrement du post-traitement NMS à l'inférence ; suivent une inférence CPU 43 % plus rapide, le nouvel optimiseur MuSGD et la suppression de la DFL. [Blog Ultralytics, 2025-09-29](https://www.ultralytics.com/blog/ultralytics-key-highlights-from-yolo-vision-2025), [Ultralytics v8.4.0](https://github.com/ultralytics/ultralytics/releases/tag/v8.4.0)\n\nL'article n'arrive sur arXiv qu'en juin 2026. Les générations précédentes de YOLO d'Ultralytics n'avaient que du code et une documentation en ligne ; quand cet article cite YOLOv8 et YOLO11, il ajoute même après la référence bibliographique la mention « no formal paper » (pas d'article formel). On peut enfin voir les raisons et les ablations derrière chaque choix de conception.\n\nEn 2024, YOLOv10 entraînait déjà deux têtes de sortie ensemble, puis abandonnait la tête un à plusieurs à l'inférence pour n'utiliser que la tête un à un. YOLO26 garde les deux têtes dans les mêmes poids ; par défaut, l'article utilise la tête un à un sans NMS, et quand la précision prime, on peut aussi passer par la tête un à plusieurs suivie d'une NMS.\n\nQuand on entraîne deux têtes ensemble, comment répartir l'effort d'entraînement ? Et combien de précision perd la tête utilisée au déploiement ? La méthode et les expériences de l'article tournent pour l'essentiel autour de ces deux questions.\n\n\n> [!NOTE]\n> \n> Si la NMS et l'appariement un à un ne vous sont pas encore familiers, commençons par un peu de contexte. YOLO devine une boîte à chaque position, et l'entraînement fait de plusieurs positions proches d'un objet des positifs (un à plusieurs) ; à l'inférence, un même objet fait donc surgir plusieurs boîtes, et il faut compter sur la NMS pour les trier par score et supprimer les boîtes de même classe qui se recouvrent trop. L'attribution un à un n'associe qu'un positif à chaque objet ; le modèle apprend à ne signaler chaque objet qu'une fois, et l'inférence se passe de NMS. Pour la double tête de YOLOv10, voir notre note :\n> \n> - **[[24.05] YOLOv10 : adieu, NMS](/blog/papers/object-detection/yolov10)**\n\n\n## Définir le problème\n\nSelon les auteurs, si YOLO reste le détecteur temps réel le plus répandu de l'industrie, c'est pour deux raisons. D'une part, il n'utilise que des convolutions standard et s'exporte directement vers TensorRT, ONNX, CoreML, TFLite, OpenVINO, NCNN, ExecuTorch et d'autres environnements d'inférence ; d'autre part, un même backbone et un même neck peuvent servir à la fois à la détection, à la segmentation, à la pose et à d'autres tâches. Les modèles temps réel de la lignée DETR, comme RT-DETR, D-FINE, DEIM et RF-DETR, ont rattrapé YOLO en précision, mais selon les auteurs, ils dépendent souvent de grands backbones préentraînés, d'opérateurs personnalisés comme l'attention déformable, ou d'une résolution d'entrée fixe, ce qui complique leur déploiement sur des matériels variés. C'est la position d'Ultralytics ; il faudra s'en souvenir en lisant les tableaux comparatifs plus loin.\n\nLes auteurs listent ensuite quatre limites des détecteurs YOLO existants :\n\n1. **NMS et entraînement à double tête**. La plupart des détecteurs CNN ont encore besoin de la NMS à l'inférence pour supprimer les doublons. YOLOv10 a supprimé la NMS grâce à sa double tête, mais avec les mêmes poids de perte pour les deux têtes du début à la fin ; selon les auteurs, la tête un à un, la seule utilisée à l'inférence, n'est donc pas entraînée au niveau qu'elle pourrait atteindre.\n2. **Paramètres et portée de la DFL**. Depuis YOLOv8, la DFL fait passer la boîte de chaque position de 4 nombres à 4K logits (en général K=16), ce qui gonfle les paramètres de la tête. Sans DFL, YOLO11n passe de 2,6M à 2,3M paramètres et de 6,5 à 5,2 GFLOPs. La DFL limite aussi la taille maximale des boîtes.\n3. **Un entraînement trop long**. La recette SGD standard demande environ 600 époques pour atteindre une précision compétitive sur COCO, ce qui rend coûteux l'essai rapide de nouvelles idées.\n4. **Les plus petits objets ne reçoivent pas de positifs**. Les attributions d'étiquettes comme TAL ne considèrent que les positions dont le centre tombe dans la boîte annotée ; quand un objet est plus petit que le plus petit stride, il peut n'y avoir aucune position dans sa boîte, et il ne contribue alors à aucun gradient de tout l'entraînement.\n\nYOLO26 part de YOLO11 et répond à ces quatre points, dans l'ordre, par la double tête avec une perte progressive (Progressive Loss, écrite ProgLoss sur le blog d'Ultralytics), la régression directe à la place de la DFL, l'optimiseur MuSGD et STAL (Small-Target-Aware Label Assignment).\n\n## Résoudre le problème\n\n### Procédure d'entraînement\n\nLa Figure 2 de l'article dessine toute la procédure d'entraînement, à lire de gauche à droite.\n\n[![Schéma de la procédure d'entraînement de YOLO26. Tout à gauche, Backbone + Neck, d'où partent deux lignes, en haut One-to-Many Branch (TAL topk = 10), en bas One-to-One Branch (TAL topk = 7, topk2 = 1) ; les deux lignes entrent dans Task-Aligned Assignment, puis donnent respectivement One-to-Many Loss et One-to-One Loss, transmises à Progressive Loss Weighting (le poids un à plusieurs descend de 0,8 à 0,1), qui aboutit à MuSGD Optimizer](/content/papers/assets/81b8a4e821bdb84f6040563add1c1f2341963826d993348c64cab2715e5d6e93.png)](/content/papers/assets/81b8a4e821bdb84f6040563add1c1f2341963826d993348c64cab2715e5d6e93.png)\n\n*Jocher et al., Figure 2 de l'article original, extraite de la [**page 6 du PDF v1**](https://arxiv.org/pdf/2606.03748v1#page=6), CC BY 4.0. Procédure d'entraînement de YOLO26.*\n\nLe backbone et le neck extraient des caractéristiques multi-échelles et les transmettent en même temps aux deux têtes de détection. Les deux têtes choisissent leurs positifs avec TAL (Task-Aligned Assignment) ; la tête un à plusieurs porte topk = 10, la tête un à un topk = 7 et topk2 = 1. Chacune calcule ses pertes de boîte et de classe, que la pondération de la perte progressive additionne, puis MuSGD met à jour les paramètres. STAL n'est pas dessiné ; il se cache dans l'étape où TAL choisit les candidats.\n\nLa Table 1 de l'article donne les noms de ces composants dans la bibliothèque ultralytics. La double tête se trouve dans `Detect`, la régression directe correspond à `reg_max=1`, STAL se trouve dans `TaskAlignedAssigner`, la perte progressive s'appelle `E2ELoss`, et l'optimiseur s'appelle simplement `MuSGD`. Les détails d'implémentation mentionnés plus bas se réfèrent au code de la version 8.4.0.\n\n### Deux têtes, chacune ses positifs\n\nUne photo de 640×640 passe par trois niveaux de cartes de caractéristiques de stride 8, 16 et 32, de tailles respectives 80×80, 40×40 et 20×20, soit 8 400 positions au total. Les deux têtes produisent à chaque position un ensemble de scores de classe et une boîte ; elles ne diffèrent que par les positions considérées comme positives à l'entraînement.\n\nTAL attribue à chaque position un score pour chaque objet annoté, qui n'est élevé que si la classification et la localisation sont toutes deux justes. L'implémentation d'Ultralytics l'écrit $s^{0.5}\\cdot u^{6}$, où $s$ est le score de la position pour la classe annotée et $u$ l'IoU entre la boîte prédite et la boîte annotée ; la métrique d'appariement cohérente que YOLOv10 fait partager à ses deux têtes utilise les mêmes exposants. Avant la notation, seules les positions dont le centre tombe dans la boîte annotée peuvent être candidates.\n\n- **Tête un à plusieurs** : chaque objet prend au plus les 10 meilleurs scores comme positifs. À l'inférence, la sortie a la forme `(N, nc+4, 8400)`, où `N` est la taille du batch et `nc` le nombre de classes, et doit ensuite passer par la NMS.\n- **Tête un à un** : elle prend d'abord les 7 meilleurs comme candidats, règle les cas où une même position est disputée par plusieurs objets, puis ne garde que le premier pour chaque objet. À l'inférence, elle choisit parmi les 8 400 positions les 300 de score le plus élevé et produit `(N, 300, 6)` ; chaque ligne contient les quatre coordonnées de la boîte, le score et la classe, sans aucune suppression par IoU.\n\nLes deux têtes rendent des sorties très différentes. Pour les 80 classes de COCO, la tête un à plusieurs produit par image 84×8 400 = 705 600 nombres, et la NMS doit trier 8 400 candidats ; la tête un à un n'en produit que 300×6 = 1 800.\n\n\n> [!NOTE]\n> \n> À l'entraînement, la tête un à un reçoit des caractéristiques passées par `detach()` ; son gradient ne remonte pas jusqu'au backbone et au neck, et les caractéristiques partagées ne sont façonnées que par la perte de la tête un à plusieurs. L'article ne mentionne pas ce détail ; sur la branche main actuelle, cette ligne porte le commentaire « detach keeps one2one out of the backbone » (le detach tient la tête one2one à l'écart du backbone). L'implémentation officielle de YOLOv10 est branchée de la même façon.\n\n\n### Perte progressive\n\nLa perte progressive détermine comment s'additionnent les pertes des deux têtes. Les équations (2) et (3) de l'article sont :\n\n$$\n\\mathcal{L}_{\\text{total}} = \\alpha(t)\\,\\mathcal{L}_{\\text{one2many}} + \\bigl(1-\\alpha(t)\\bigr)\\,\\mathcal{L}_{\\text{one2one}}\n$$\n\n$$\n\\alpha(t) = \\max\\!\\left(1-\\frac{t}{\\max(E-1,\\,1)},\\ 0\\right)\\bigl(\\alpha_{\\text{init}}-\\alpha_{\\text{final}}\\bigr)+\\alpha_{\\text{final}}\n$$\n\n$t$ est l'époque en cours (comptée à partir de 0), $E$ le nombre total d'époques. L'implémentation prend $\\alpha_{\\text{init}}=0.8$ et $\\alpha_{\\text{final}}=0.1$, avec une mise à jour à la fin de chaque époque (§4.1). Autrement dit, les poids un à plusieurs et un à un partent de 0,8 pour 0,2 et vont en ligne droite jusqu'à 0,1 pour 0,9.\n\nLe raisonnement des auteurs est que la tête un à plusieurs, riche en positifs, s'entraîne facilement au début et peut d'abord stabiliser les caractéristiques ; la tête un à un, aux conditions plus strictes, est pourtant celle qui décide en fin de compte de la sortie au déploiement. Avec des poids fixes du début à la fin, comme dans YOLOv10, la tête utilisée au déploiement ne reçoit pas assez d'effort.\n\nFaisons le calcul pour un entraînement de 100 époques :\n\n```python\ndef o2m_weight(t, E, a_init=0.8, a_final=0.1):\n    # équation (3) de l'article : t est l'époque en cours (comptée à partir de 0), mise à jour à la fin de chaque époque\n    return max(1 - t / max(E - 1, 1), 0) * (a_init - a_final) + a_final\n\nE = 100\nfor t in (0, 25, 42, 43, 75, 99):\n    a = o2m_weight(t, E)\n    print(f\"époque {t:>2} : un à plusieurs {a:.3f}, un à un {1 - a:.3f}\")\n```\n\n```text\népoque  0 : un à plusieurs 0.800, un à un 0.200\népoque 25 : un à plusieurs 0.623, un à un 0.377\népoque 42 : un à plusieurs 0.503, un à un 0.497\népoque 43 : un à plusieurs 0.496, un à un 0.504\népoque 75 : un à plusieurs 0.270, un à un 0.730\népoque 99 : un à plusieurs 0.100, un à un 0.900\n```\n\nLes poids des deux côtés se croisent entre la 42e et la 43e époque. En général, $\\alpha(t)=0.5$ tombe à $t/(E-1)=3/7$ ; c'est donc vers 43 % de l'entraînement que la tête un à un commence à recevoir le poids le plus fort.\n\nRevenons au `detach()` de tout à l'heure. Les gradients du backbone et du neck ne viennent que de la perte un à plusieurs, avec un coefficient $\\alpha(t)$ qui descend de 0,8 à 0,1 ; la tête un à un ne met à jour que son propre jeu de convolutions, avec un coefficient qui monte de 0,2 à 0,9. L'ampleur réelle de chaque mise à jour dépend encore de l'optimiseur ; dans MuSGD, la partie Muon orthogonalise d'abord la matrice de mise à jour, dont l'amplitude devient presque indépendante du facteur d'échelle du gradient.\n\n### Supprimer la DFL\n\nLa DFL (Distribution Focal Loss) vient de GFL. Plutôt que de régresser directement un nombre pour la distance entre chaque côté de la boîte et le centre, elle prédit une distribution de probabilité sur K cases, puis en prend l'espérance :\n\n$$\nd=\\sum_{i=0}^{K-1} i\\cdot\\operatorname{softmax}(z)_i,\\qquad z\\in\\mathbb{R}^{K}\n$$\n\nDe YOLOv8 à YOLO11, tous utilisent K=16, ce qui entraîne deux coûts.\n\nLe premier est le volume de sortie. La boîte de chaque position passe de 4 nombres à 64 logits ; sur 8 400 positions, cela fait 537 600 contre 33 600.\n\nLe second est la portée. L'espérance $d$ ne dépasse pas $K-1=15$ ; multipliée par le stride, elle limite chaque côté à 15 strides. Au niveau de stride 32, un côté va au plus à 480 pixels, et la largeur de boîte est plafonnée à environ 960 pixels. Avec une entrée agrandie à 1280, les grands objets peuvent dépasser cette limite.\n\nPour voir où se font les économies de paramètres, il faut regarder comment est écrite la tête de détection d'Ultralytics. La largeur en canaux de la branche de boîte vaut `max(16, ch // 4, 4 * reg_max)`, où `ch` est le nombre de canaux du niveau de caractéristiques le moins profond (stride 8). Pour YOLO11n, `ch` vaut 64 ; avec la DFL, `reg_max=16` et la largeur vaut max(16, 16, 64) = 64 ; sans DFL, `reg_max=1` et la largeur tombe à 16. En comptant avec cette formule les paramètres des trois branches de boîte, on obtient environ 382 000 avec DFL et environ 72 000 sans, soit 310 000 d'écart, ce qui concorde avec le passage de 2,6M à 2,3M annoncé par l'article. Avec le même calcul pour la version m, `ch // 4` vaut déjà 64, la largeur est la même des deux côtés, et l'écart n'est que d'environ 12 000 paramètres. Le coût en paramètres de la DFL pèse donc surtout sur les deux petits modèles, n et s.\n\nYOLO26 prédit directement les quatre distances (`reg_max=1`) et ajoute une perte L1. Si vous lisez la configuration d'entraînement de YOLO26, vous verrez que le champ `dfl` existe toujours ; dans YOLO26, il devient le poids de la perte de régression L1 (annexe S3), et une valeur non nulle active bien la perte L1.\n\n\n> [!TIP]\n> \n> Pour l'origine de la DFL, voir notre note :\n> \n> - **[[20.06] GFL : le point de convergence](/blog/papers/object-detection/gfl)**\n\n\n### STAL\n\nComme nous l'avons vu, TAL ne choisit des candidats que parmi les positions dont le centre tombe dans la boîte annotée. Un objet de 6×6 pixels coincé entre deux rangées de centres du niveau de stride 8 n'a aucun candidat. STAL ne modifie que cette étape de sélection des candidats ; il étire les côtés de largeur ou de hauteur inférieure au plus petit stride (8 pixels) jusqu'au stride du niveau suivant (16 pixels), et la notation, l'appariement et la régression de boîte qui suivent utilisent toujours la boîte d'origine.\n\nPlaçons un objet de 6×6 centré en (96, 96) pour voir :\n\n```python\ndef centers(stride, size=640):\n    # coordonnées (en pixels) du centre de chaque cellule, par exemple 4, 12, 20, ... pour le stride 8\n    return [(i + 0.5) * stride for i in range(size // stride)]\n\ndef n_candidates(cx, cy, w, h, stride):\n    x1, x2, y1, y2 = cx - w / 2, cx + w / 2, cy - h / 2, cy + h / 2\n    xs = [c for c in centers(stride) if x1 < c < x2]\n    ys = [c for c in centers(stride) if y1 < c < y2]\n    return len(xs) * len(ys)\n\ndef stal(w, h, s_min=8, s_ref=16):\n    # seulement pour choisir les candidats : étire jusqu'à s_ref les côtés plus petits que le plus petit stride\n    return (s_ref if w < s_min else w), (s_ref if h < s_min else h)\n\ncx, cy, w, h = 96, 96, 6, 6\nfor name, (bw, bh) in [(\"boîte d'origine\", (w, h)), (\"après étirement STAL\", stal(w, h))]:\n    counts = {s: n_candidates(cx, cy, bw, bh, s) for s in (8, 16, 32)}\n    print(f\"{name} {bw}×{bh} :\", counts, \"total\", sum(counts.values()))\n```\n\n```text\nboîte d'origine 6×6 : {8: 0, 16: 0, 32: 0} total 0\naprès étirement STAL 16×16 : {8: 4, 16: 0, 32: 0} total 4\n```\n\nLa boîte d'origine va de 93 à 99, et les centres du stride 8 sont à 92 et 100, juste à l'extérieur ; les deux autres niveaux, plus clairsemés, n'en ont pas non plus. Une fois étirée à 16×16, la boîte va de 88 à 104, et les centres 92 et 100 du niveau de stride 8 y entrent tous les deux ; avec deux centres dans chaque direction, cela fait 4 candidats.\n\nCette position a été choisie exprès. Nous avons aussi placé l'objet au hasard sur toute l'image, vingt mille fois pour chaque taille. Pour des objets de 2×2, 4×4 et 6×6, environ 92 %, 67 % et 34 % des placements respectivement n'ont aucun candidat ; après étirement, chaque placement a au moins un candidat. Ce calcul ne porte que sur la sélection des candidats ; qui devient finalement positif dépend encore du score TAL.\n\n\n> [!TIP]\n> \n> La notation de TAL vient de TOOD ; voir notre note :\n> \n> - **[[21.08] TOOD : la fin du décalage](/blog/papers/object-detection/tood)**\n\n\n### MuSGD\n\nMuSGD mélange deux optimiseurs. Muon accumule d'abord le moment comme d'habitude, puis orthogonalise cette matrice de mise à jour par quelques itérations de Newton–Schulz ; l'article cite une étude de Moonshot AI selon laquelle, pour l'entraînement de grands modèles de langage, son efficacité de calcul est environ le double de celle d'AdamW. Pour les paramètres multidimensionnels, comme les noyaux de convolution et les couches linéaires, MuSGD additionne dans une proportion donnée les mises à jour de Muon et de SGD ; pour les paramètres unidimensionnels, comme les biais et les facteurs d'échelle des couches de normalisation, il n'utilise que SGD. Les notes de version indiquent que l'idée vient de Kimi K2, de Moonshot AI.\n\nL'article conçoit aussi des têtes et des pertes propres à la segmentation, à la pose et aux boîtes orientées, et dote YOLOE, à vocabulaire ouvert, du détecteur de YOLO26 pour en faire YOLOE-26. Cette note ne traite que de la détection d'objets.\n\n## Discussion\n\n### De YOLO11s à YOLO26s, pas à pas\n\nLa Table 2 de l'article part de YOLO11s et ajoute une modification à la fois. Dans le tableau, E2E désigne la tête un à un sans NMS, non E2E la tête un à plusieurs avec NMS.\n\n| Étape | AP (E2E) | AP (non E2E) | Paramètres (M) | GFLOPs | Latence (ms) |\n| --- | ---: | ---: | ---: | ---: | ---: |\n| Référence YOLO11s | – | 47,0 | 9,4 | 21,5 | 2,5 |\n| Suppression de la DFL | – | 46,4 | 9,1 | 20,1 | 2,3 |\n| Ajout de la perte L1 | – | 46,6 | 9,1 | 20,1 | 2,3 |\n| Ajout de STAL | – | 46,8 | 9,1 | 20,1 | 2,3 |\n| Ajustement du backbone et du neck | – | 47,0 | 9,5 | 20,7 | 2,5 |\n| Ajout de la tête un à un | 46,4 | 47,0 | 9,5 | 20,7 | 2,5 |\n| Perte progressive | 46,7 | 47,2 | 9,5 | 20,7 | 2,5 |\n| MuSGD | 47,1 | 47,6 | 9,5 | 20,7 | 2,5 |\n| Préentraînement sur Objects365 | 47,4 | 48,0 | 9,5 | 20,7 | 2,5 |\n| Recherche d'hyperparamètres | 47,8 | 48,6 | 9,5 | 20,7 | 2,5 |\n\n*Tableau : Table 2 de l'article original.*\n\n1. **Supprimer la DFL coûte d'abord 0,6 AP**, puis la perte L1, STAL et l'ajustement du backbone et du neck (une couche d'attention de plus dans le neck) en récupèrent chacun 0,2. Au bout de ces quatre étapes, l'AP revient à 47,0, les GFLOPs passent de 21,5 à 20,7 et la latence ne change pas.\n2. **Ajouter la tête un à un ne dégrade pas la voie un à plusieurs**, qui reste à 47,0 ; la tête un à un obtient 46,4, soit 0,6 de moins.\n3. **La perte progressive fait gagner 0,3 à la tête un à un**, et 0,2 à la tête un à plusieurs.\n4. **Les deux dernières lignes n'ont rien à voir avec l'architecture**. La tête un à plusieurs passe de 47,0 à 48,6, et sur ces 1,6 AP, 1,0 vient du préentraînement sur Objects365 et de la recherche d'hyperparamètres.\n\nCette ablation n'indique pas le nombre d'époques d'entraînement, et chaque ligne ne repose que sur un seul résultat. L'article ne rapporte pas la variance sur plusieurs entraînements ; les écarts de 0,2 à 0,4 AP sont à lire avec prudence.\n\n### La répartition des poids\n\nLa Table 5 compare six répartitions sur la même configuration YOLO11s ; les chiffres sont l'AP de la tête un à un sans NMS :\n\n| Départ (un à plusieurs ; un à un) | Arrivée (un à plusieurs ; un à un) | AP (E2E) |\n| --- | --- | ---: |\n| (0,5 ; 0,5) | (0,5 ; 0,5) | 46,4 |\n| (1,0 ; 0,0) | (0,1 ; 0,9) | 46,4 |\n| (1,0 ; 0,0) | (0,2 ; 0,8) | 46,4 |\n| (1,0 ; 0,0) | (0,3 ; 0,7) | 46,3 |\n| (0,8 ; 0,2) | (0,1 ; 0,9) | 46,7 |\n| (0,9 ; 0,1) | (0,1 ; 0,9) | 46,3 |\n\n*Tableau : Table 5 de l'article original, sur la base de YOLO11s.*\n\nLe partage fixe 0,5 pour 0,5 donne 46,4, et la répartition par défaut, de 0,8 pour 0,2 vers 0,1 pour 0,9, donne 46,7 ; ces deux cases correspondent exactement aux lignes « Ajout de la tête un à un » et « Perte progressive » de la Table 2. Les trois répartitions dont le poids un à un part de 0 se situent entre 46,3 et 46,4, sans faire mieux que les poids fixes. Les auteurs en concluent que la tête un à un doit recevoir un peu de supervision dès le début, puis un poids croissant.\n\nPourtant, la répartition qui part de 0,9 pour 0,1 donne 46,3, au niveau de celles qui partent de 0, si bien que « donner un peu dès le début » ne peut pas encore passer pour une règle. Lu prudemment, le tableau indique que, dans cette configuration, la répartition par défaut fait 0,3 AP de plus que les poids fixes, et que l'écart entre chacune des autres répartitions et les poids fixes est de 0,1 au plus.\n\n### Trois autres ablations\n\n1. **DFL**. La Table 3 entraîne de zéro avec la configuration YOLO26s, avec ou sans DFL pour seule différence. En résolution 640, supprimer la DFL fait passer l'AP de 46,0 à 46,3, et l'$\\text{AP}_L$ des grands objets de 62,8 à 63,8 ; en résolution 1280, l'AP passe de 49,8 à 51,1 et l'$\\text{AP}_L$ de 61,8 à 64,0, tandis que les petits et moyens objets reculent légèrement. Comparé à la perte de 0,6 sur YOLO11s dans la Table 2, le bilan de la suppression de la DFL dépend des autres réglages ; les auteurs attribuent le gain sur les grands objets en haute résolution à la limite de portée de la DFL. Le tableau ne précise pas de quelle tête provient l'AP.\n2. **MuSGD**. La Table 4 entraîne COCO de zéro ; SGD sur 600 époques donne 47,0, MuSGD sur 500 époques 47,4. L'article ne précise pas la taille du modèle et ne rapporte pas le temps d'entraînement réel ; les itérations de Newton–Schulz ajoutent du calcul à chaque pas, et si les époques diminuent de 16,7 %, le temps gagné n'est pas forcément aussi important. Dans la comparaison en classification ImageNet (Table S1 de l'annexe), le top-1 des cinq tailles progresse de 0,4 à 1,4.\n3. **STAL**. La Table 6 part de YOLO11s ; le TAL d'origine donne 46,6, avec un $\\text{AP}_S$ des petits objets de 29,0 ; en étirant à 16 pixels, on obtient 46,8 et un $\\text{AP}_S$ de 29,6. En étirant à 8 pixels, l'$\\text{AP}_S$ tombe au contraire à 27,7 ; à 32 pixels, l'ensemble descend à 46,5. La valeur par défaut de 16 pixels apporte 0,2 AP au total.\n\n### Combien d'écart entre les deux têtes\n\nLa Table 7 donne les résultats des modèles publiés sur COCO, avec la précision des deux têtes :\n\n| Modèle | mAP (un à plusieurs + NMS) | mAP (un à un) | Écart | T4 TensorRT (ms) | CPU ONNX (ms) | Paramètres (M) |\n| --- | ---: | ---: | ---: | ---: | ---: | ---: |\n| YOLO26n | 40,9 | 40,1 | 0,8 | 1,7 | 38,9 | 2,4 |\n| YOLO26s | 48,6 | 47,8 | 0,8 | 2,5 | 87,2 | 9,5 |\n| YOLO26m | 53,1 | 52,5 | 0,6 | 4,7 | 220,0 | 20,4 |\n| YOLO26l | 55,0 | 54,4 | 0,6 | 6,2 | 286,2 | 24,8 |\n| YOLO26x | 57,5 | 56,9 | 0,6 | 11,8 | 525,8 | 55,7 |\n\n*Tableau : Table 7 de l'article original, COCO val2017, entrée 640×640 ; la colonne « Écart » est calculée pour cette note. Le CPU est un Intel Xeon @ 2,00 GHz exécutant ONNX.*\n\nSur les cinq tailles, la tête un à un obtient 0,6 à 0,8 AP de moins que un à plusieurs + NMS. Les auteurs écrivent au §4.4 que, si la plateforme cible peut exécuter efficacement la NMS et que l'AP prime, la tête un à plusieurs peut rester le premier choix ; quand la simplicité du déploiement, la facilité d'intégration ou l'absence de NMS comptent davantage, mieux vaut la tête un à un par défaut.\n\nComparons avec l'écart de YOLOv10. L'article YOLOv10 donne un écart de 1,0 pour la version N, 0,5 pour S, 0,2 pour M, B et L, et 0 pour X. Mais YOLOv10 compare avec un autre modèle, entraîné uniquement en un à plusieurs puis suivi d'une NMS, alors que YOLO26 compare directement les deux têtes d'un même jeu de poids. Les deux séries de chiffres ne mesurent pas la même chose, et on ne peut pas dire de quel côté la tête un à un est la mieux entraînée. L'écart de YOLO26 ne disparaît pas non plus sur les grands modèles ; la version x garde 0,6.\n\nLa tête un à un ne garantit pas non plus l'absence de doublons. En juillet 2026, quelqu'un a signalé des doublons presque superposés dans les prédictions de YOLO26n-obb ; un collaborateur d'Ultralytics a répondu que YOLO26n le fait parfois, qu'on peut rebrancher une NMS au besoin, et qu'avec peu de boîtes, ce devrait être rapide. [ultralytics #25304](https://github.com/ultralytics/ultralytics/issues/25304)\n\nLe §3.5 de l'article indique aussi que certains runtimes ne prennent pas en charge l'opération top-K nécessaire au décodage de bout en bout ; l'export se rabat alors automatiquement sur la tête un à plusieurs. Le guide de bout en bout d'Ultralytics cite NCNN, RKNN, Edge TPU, Qualcomm QNN et d'autres formats, qui se rabattent ainsi quand leurs opérateurs ne prennent pas en charge la sortie de bout en bout. [Guide Ultralytics de détection de bout en bout](https://docs.ultralytics.com/guides/end2end-detection/)\n\n### Les chiffres phares viennent des deux têtes\n\nLe résumé de l'article annonce pour YOLO26, sur COCO, 40,9–57,5 mAP et une latence T4 TensorRT de 1,7–11,8 ms. La partie précision correspond aux résultats un à plusieurs + NMS de la Table 7 ; la note de bas de page de la documentation Ultralytics indique, elle, que la latence est mesurée avec la tête un à un sans NMS (`nms=False`). En déployant sans NMS, la précision correspondante va de 40,1 à 56,9 ; en passant par la tête un à plusieurs, il faut ajouter à la latence le temps de NMS, absent du tableau. [Documentation YOLO26](https://docs.ultralytics.com/models/yolo26/)\n\nLa Table S9 de l'annexe, pour les modèles de segmentation, donne séparément la latence des deux têtes, sans NMS des deux côtés. Pour la version n sur T4, la tête un à un prend 2,1 ms et la tête un à plusieurs 2,0 ms ; pour la version x, 16,4 ms contre 16,8 ms. À ne regarder que le modèle lui-même, les deux voies sont à peu près aussi rapides, et la tête un à un économise l'étape de NMS.\n\nLes 43 % de gain sur CPU ont aussi leurs conditions. L'article précise qu'il s'agit d'une comparaison entre YOLO26n et YOLO11n en ONNX sur CPU Intel Xeon. D'après les tableaux des deux documentations officielles, YOLO11n prend 56,1 ms et YOLO26n 38,9 ms, soit un débit 1,44 fois plus élevé, ou environ 31 % de latence en moins. En comparant les autres tailles une à une, la version s passe de 90,0 ms à 87,2 ms, presque pareil ; pour les versions m, l et x, YOLO26 est au contraire 14 % à 20 % plus lent que YOLO11. Sur T4, la version n donne 1,5 ms contre 1,7 ms, YOLO26 étant légèrement plus lent. La documentation de YOLO11 ne précise pas si la latence inclut la NMS. [Documentation YOLO11](https://docs.ultralytics.com/models/yolo11/)\n\nRegardons maintenant la figure principale de l'article. L'axe vertical donne la mAP sur COCO, l'axe horizontal la latence en T4, TensorRT10, FP16 :\n\n[![Nuage de points précision-latence sur COCO val2017. En abscisse, la latence T4 TensorRT10 FP16 (de 0 à 16 millisecondes) ; en ordonnée, la COCO mAP 50-95 (de 37,5 à 57,5). La courbe bleu foncé de YOLO26 relie 26n (environ 1,7 milliseconde, 40,9) à 26x (environ 11,8 millisecondes, 57,5) et passe au-dessus des autres courbes ; les autres courbes sont YOLO11, YOLOv10, YOLOv9, YOLOv8, YOLOv7, YOLOv6-3.0, YOLOv5, PP-YOLOE+, DAMO-YOLO et RTMDet](/content/papers/assets/ab67bb3bd246062be0c7a56a363c356177cca42c6e7349343402535b7b723f2c.png)](/content/papers/assets/ab67bb3bd246062be0c7a56a363c356177cca42c6e7349343402535b7b723f2c.png)\n\n*Jocher et al., Figure 1 de l'article original, extraite de la [**page 1 du PDF v1**](https://arxiv.org/pdf/2606.03748v1#page=1), CC BY 4.0. Précision et latence sur COCO val2017.*\n\nLa courbe bleu foncé est celle de YOLO26 ; ses points reprennent les chiffres ci-dessus, la mAP un à plusieurs + NMS associée à la latence de la tête un à un. Toutes les autres courbes sont des YOLO, plus trois détecteurs CNN, PP-YOLOE+, DAMO-YOLO et RTMDet.\n\nQuand l'article est arrivé sur Hacker News, un utilisateur se présentant comme cofondateur de Roboflow a objecté que la figure principale ne montrait qu'un seul DETR, datant de 2022, tout en revendiquant le meilleur compromis AP–latence. Roboflow développe RF-DETR et est un concurrent direct d'Ultralytics. [Hacker News, 2026-06-23](https://news.ycombinator.com/item?id=48639434) À regarder la figure, on n'y trouve en fait aucun modèle de la lignée DETR. Les modèles temps réel de la lignée DETR n'apparaissent que dans la Table S8 de l'annexe, avec RT-DETRv2, D-FINE et DEIM ; RF-DETR, mentionné dans l'introduction de l'article, n'est pas inclus dans la comparaison.\n\nDans la gamme x de la Table S8, YOLO26x obtient 57,5 AP en 11,8 ms, DEIM-X 56,5 AP en 12,9 ms et D-FINE-X 55,8 AP en 12,9 ms. Là encore, l'AP de YOLO26 vient du un à plusieurs + NMS et la latence de la tête un à un ; YOLO26 a aussi été préentraîné sur Objects365, alors que les lignes D-FINE et DEIM correspondent aux versions entraînées sur COCO seul. La version préentraînée sur Objects365 publiée par D-FINE atteint 59,3 AP en X. [D-FINE](https://github.com/Peterande/D-FINE) Pour voir comment la lignée DETR mesure la latence et compte le temps de la NMS, on peut se reporter à la note [RF-DETR](/blog/papers/object-detection/rf-detr).\n\n## Conclusion\n\nYOLO26 garde les deux têtes, déplace progressivement le centre de gravité de l'entraînement du un à plusieurs vers le un à un grâce à la perte progressive, puis supprime la DFL, adopte MuSGD et ajoute STAL. Les preuves apportées par l'article se résument à peu près ainsi :\n\n1. **La tête un à un perd 0,6 à 0,8 AP sur les cinq tailles**, en échange d'une sortie fixe d'au plus 300 boîtes, sans NMS.\n2. **La preuve directe de la perte progressive tient à une seule ablation**. Sur YOLO11s, la répartition par défaut fait 0,3 AP de plus que les poids fixes ; les répartitions qui partent de 0 ne font pas mieux que les poids fixes.\n3. **Les paramètres économisés en supprimant la DFL se concentrent sur n et s**, et cette suppression profite plutôt aux grands objets en haute résolution. STAL garantit des candidats aux objets de moins de 8 pixels et apporte 0,2 AP au total.\n4. **Une partie de l'écart avec YOLO11 vient de la recette d'entraînement**. Sur les 1,6 AP de la version s, 1,0 vient du préentraînement sur Objects365 et de la recherche d'hyperparamètres.\n\nAu moment de la rédaction de l'article, la tête un à un était encore la valeur par défaut. Publiée le 5 septembre 2026, `ultralytics` 8.4.142 fait passer par défaut la prédiction et la validation de YOLO26 à la tête un à plusieurs avec NMS, au motif qu'elle est généralement plus précise que la tête un à un sans NMS ; pour passer par la tête sans NMS, il faut régler soi-même `nms=False`. Les deux têtes sont toujours entraînées ; seules la validation, la sélection des checkpoints et l'arrêt anticipé suivent désormais la tête choisie. [Ultralytics v8.4.142](https://github.com/ultralytics/ultralytics/releases/tag/v8.4.142)\n\nAvant de comparer YOLO26 à d'autres détecteurs, décidez donc d'abord par quelle tête passera le déploiement, puis comparez la précision et la latence d'une même tête ; le guide de bout en bout d'Ultralytics recommande la même chose. Sur CPU, c'est la version n qui accélère le plus nettement ; à partir de m, les tableaux officiels montrent YOLO26 plus lent que YOLO11. Sur HN, quelqu'un a aussi rapporté que, sur sa propre tâche de vidéos de football, YOLO26 faisait moins bien que v9 et v11, sans donner de chiffres ; sur vos propres données, il faudra mesurer vous-même. Enfin, la bibliothèque `ultralytics` est sous licence AGPL-3.0 ; avant de l'utiliser dans un produit, vérifiez aussi la licence.\n","imageSizes":{"/content/papers/assets/81b8a4e821bdb84f6040563add1c1f2341963826d993348c64cab2715e5d6e93.png":{"width":1494,"height":367},"/content/papers/assets/ab67bb3bd246062be0c7a56a363c356177cca42c6e7349343402535b7b723f2c.png":{"width":1362,"height":633}}}