YOLO en 2026 : détection sans NMS, une carte des versions qui ment, et la licence que personne ne lit

YOLO26 supprime les deux étapes de post-traitement qui rendaient les détecteurs antérieurs difficiles à déployer. Il exécute par défaut une tête de détection un-à-un, si bien qu'il n'y a pas de suppression non maximale (NMS) à l'inférence et que le réseau produit les détections finales directement. Il abandonne aussi la distribution focal loss (DFL), ce qui allège la tête pour les appareils en périphérie et à faible consommation. La recette d'entraînement est nouvelle aussi : un optimiseur MuSGD, une progressive loss et une affectation d'étiquettes pour petites cibles.

Pourquoi le sans-NMS est la partie à retenir : le NMS est une étape séparée, dépendante des données, qui s'exécute après le réseau, et sa durée varie selon le nombre d'objets à l'image. Le supprimer donne une latence déterministe et un export plus propre, ce qui est exactement ce que l'on veut quand la cible est ONNX, TensorRT, OpenVINO ou CoreML sur du matériel fixe. Moins de boutons de post-traitement signifie moins de façons dont le chemin de production dérive du labo.

Les chiffres sont incrémentaux, pas spectaculaires. Sur COCO, YOLO26n atteint 40,9 de mAP à 2,4M de paramètres, et Ultralytics rapporte jusqu'à 43 pour cent d'inférence CPU ONNX plus rapide que YOLO11n. Ce chiffre CPU, pas la précision, est le titre pour un acheteur qui exécute de la détection sur du silicium de périphérie standard sans GPU.

La chose la plus utile à comprendre en 2026 est que « YOLO » n'est plus un seul projet, et que les numéros de version viennent d'équipes différentes. Ultralytics maintient YOLO26, YOLO11, et les plus anciens v8 et v5. YOLOv12 et YOLOv13 sont des lignées académiques distinctes, et toutes deux reposent encore sur NMS et DFL, précisément ce que YOLO26 a supprimé.

La leçon est qu'un numéro de version plus élevé n'est pas un produit plus récent du même fournisseur. C'est parfois un groupe de recherche entièrement différent. YOLOv13 a suscité des critiques ouvertes pour avoir rapporté une AP d'environ 54,8 contre 55,2 pour YOLOv12 tout en tournant plus lourdement, une régression présentée comme une amélioration. Et YOLO lui-même n'est pas automatiquement le leader en précision : les détecteurs à base de transformeurs de la famille RF-DETR rivalisent désormais frontalement au sommet. Lisez le benchmark et le mainteneur, pas l'étiquette.

Avant l'architecture, vérifiez la licence, car celle par défaut contraint la façon dont vous livrez. YOLO d'Ultralytics est sous licence AGPL-3.0. L'AGPL est une licence copyleft forte : si vous distribuez le logiciel, ou l'offrez sur un réseau comme un service, vous êtes généralement tenu de publier l'intégralité du code source correspondant de votre œuvre dérivée, et la lecture courante étend cette obligation aux poids et au code applicatif environnant.

Le point que la plupart des équipes manquent est que l'on-prem ne vous exempte pas. La clause réseau de l'AGPL est déclenchée par l'offre de la fonctionnalité comme un service, même en interne selon certaines interprétations, pas seulement par la livraison d'un binaire à un client. Pour un produit à source fermée, ou un déploiement que vous préféreriez ne pas ouvrir, Ultralytics vend une licence Enterprise commerciale. Elle est sur devis, sans prix public, elle appartient donc tôt à la conversation d'achat, pas après que le prototype fonctionne.

L'enseignement pertinent pour l'achat est simple : budgétez la licence Enterprise, ou choisissez d'emblée un détecteur sous une licence permissive (Apache ou MIT). C'est la même question de contrôle à laquelle nous revenons sans cesse avec les modèles open-weight, où la licence et le stack, pas le benchmark, décident de ce que vous avez le droit de faire.

Traitez les sorties de 2026 comme une courte checklist ennuyeuse plutôt qu'un classement.

• Figez une version maintenue. Pour la production, la lignée Ultralytics (YOLO26 ou YOLO11) est la voie prise en charge. Les lignées académiques v12 et v13 sont de la recherche, utiles à lire, pas le choix par défaut à livrer.
• Lisez le benchmark, pas l'étiquette. Comparez mAP et latence sur un matériel proche du vôtre, et soyez honnête que RF-DETR ou un modèle plus ancien et plus petit peut l'emporter pour votre scène.
• Testez tôt le chemin d'export. La valeur du sans-NMS se réalise dans l'export ONNX ou TensorRT sur votre appareil cible. Confirmez-la là avant de vous engager.
• Réglez la licence avant le pilote. AGPL ou licence Enterprise, ou une alternative permissive. Décidez-en tant qu'il est encore peu coûteux de changer.

Rien de tout cela n'a besoin du numéro le plus récent. Il faut un détecteur qui tourne à votre latence, sur votre matériel, sous une licence avec laquelle vous pouvez vivre.