La détection d’objets est au cœur d’applications révolutionnaires, qu’il s’agisse de véhicules autonomes circulant dans les rues des villes, de systèmes de sécurité identifiant les menaces en temps réel, d’analyses dans le secteur de la vente au détail permettant de suivre les stocks ou encore d’imagerie médicale permettant de détecter des tumeurs. Cependant, choisir le modèle adapté à votre projet de vision par ordinateur peut s’avérer difficile, d’autant plus que des dizaines d’architectures revendiquent leur supériorité selon différents indicateurs.Dans ce guide, nous examinerons les meilleurs modèles de détection d’objets disponibles en 2026, en comparant leurs architectures, leurs caractéristiques de performance et leurs cas d’utilisation idéaux afin de vous aider à déterminer quels modèles sont les mieux adaptés à vos applications. Que vous développiez des systèmes d’analyse vidéo en temps réel, des systèmes d’inspection de haute précision ou des applications en périphérie aux ressources limitées, vous trouverez des conseils clairs sur le modèle qui correspond le mieux à vos besoins.
Qu’est-ce que la détection d’objets ?
La détection d’objets vise à identifier et à localiser plusieurs objets au sein d’images ou d’images vidéo. Contrairement à la classification d’images, qui se contente de classer l’identité générale d’une image, la détection d’objets identifie les objets présents dans une image ou une image vidéo ainsi que leur position exacte au sein de celle-ci.
En résumé, la détection d’objets résout deux problèmes interdépendants :
- Localiser (détecter) les objets sur l’image, en traçant les cadres de sélection de ces objets (il est possible qu’il n’y ait aucun objet !). Un cadre de sélection est généralement défini comme un tuple (x, y, h, w), où x et y sont les coordonnées du coin supérieur gauche du rectangle du cadre de sélection, et h et w sont respectivement la hauteur et la largeur de ce cadre.
- La classification de l’identité de ces objets (par exemple, une personne, une voiture ou un chien).
Cette double capacité rend la détection d’objets plus complexe que la classification seule, car elle nécessite des modèles capables de gérer plusieurs objets de tailles différentes apparaissant n’importe où dans une image.
Comme pour les tâches de classification, un simple indicateur de précision ne suffit pas pour évaluer les performances d’un modèle. Nous avons besoin de deux types d’indicateurs. Premièrement, des indicateurs de performance qui mesurent le compromis entre la détection erronée d’objets (faux positifs) et la non-détection d’objets présents dans l’image (faux négatifs). Deuxièmement, nous avons également besoin de mesures pour évaluer le temps que mettra notre modèle à effectuer la tâche en question : nous appellerons cela des mesures d’efficacité de calcul. Généralement, les nouvelles architectures de détection d’objets sont évaluées sur la partition de validation de l’ensemble de données COCO et exécutées sur du matériel GPU NVIDIA T4.
Voici les indicateurs standard utilisés dans le domaine de la détection d’objets :
- Élément de base des indicateurs de performance : l’intersection sur l’union (IoU) est la mesure géométrique fondamentale utilisée pour déterminer si un cadre de détection prédit est correct. Elle est calculée comme la surface de chevauchement entre le cadre prédit et le cadre de référence, divisée par la surface de leur union, ce qui donne un score compris entre 0 (aucun chevauchement) et 1 (correspondance parfaite). Une détection n’est comptabilisée comme un vrai positif que si son IoU avec le cadre de référence le plus proche dépasse un seuil choisi (par exemple 0,5). Un seuil d’IoU bas est indulgent quant au placement des cadres ; un seuil élevé exige une localisation précise.
- Mesure de performance : la précision moyenne (mAP), qui évalue la précision de la détection en mesurant dans quelle mesure les cadres prédits chevauchent les annotations de référence pour différents seuils de confiance. La variante la plus couramment citée, mAP@[50:95] (également notée AP50:95), calcule la moyenne de la précision sur des seuils d’IoU compris entre 0,50 et 0,95 par paliers de 0,05 ; il s’agit d’une mesure rigoureuse qui pénalise autant une localisation imprécise que les détections manquées.
mAP50 vs mAP50:95 : le mAP50 mesure la détection pour un IoU ≥ 0,5 et les scores semblent plus élevés, ce qui favorise les modèles plus rapides. Le mAP50:95 calcule la moyenne sur les seuils d’IoU compris entre 0,5 et 0,95 – il s’agit de la métrique la plus stricte et la plus privilégiée. Pour les applications où la précision est cruciale (robotique, médecine), il est courant d’optimiser le modèle pour le mAP50:95.
- Indicateur d’efficacité de calcul : le nombre d’images par seconde (FPS), qui mesure la vitesse d’inférence et permet de déterminer si un modèle est capable de traiter une vidéo en temps réel. Pour les vidéos standard, le temps réel est défini comme étant ≥ 30 FPS (selon Google ou l’article original sur YOLO) ou une latence ≤ 33,3 ms (1/FPS * 1 000). Naturellement, pour des applications telles que les voitures autonomes ou la robotique, les exigences en matière de FPS sont plus élevées, pouvant atteindre 60 à 100 FPS, voire plus.
- Indicateur d’efficacité de calcul : le nombre de paramètres est une caractéristique du modèle qui influence ses performances. Il existe un compromis entre la précision du modèle et son nombre de paramètres. C’est pourquoi les modèles sont proposés en différentes tailles pour une même architecture (S, M, L, XL, etc.) afin de répondre aux divers scénarios liés à ce compromis. Ce principe est similaire au concept de nombre de paramètres dans les grands modèles de langage (LLM).
Il existe plusieurs jeux de données couramment utilisés pour évaluer les performances des modèles de détection d’objets. Comme mentionné plus haut, le choix standard pour l’évaluation comparative de la détection d’objets est le jeu de données COCO, qui contient 80 catégories d’objets réparties sur 330 000 images. Il existe bien sûr de nombreux autres jeux de données, spécialisés dans certains domaines, tels que les voitures autonomes, ou dans certains scénarios, comme la détection d’objets dans des environnements encombrés. Il est important de garder à l’esprit que les valeurs des métriques de détection d’objets, à savoir l’IoU et le mAP, dépendent de l’ensemble de données sur lequel elles ont été évaluées ; ainsi, un mAP@[50:95] = 60,1 sur l’ensemble de données COCO n’est pas nécessairement directement transposable à votre ensemble de données personnalisé. Ces métriques doivent toujours être réévaluées sur votre ensemble de données afin de définir les performances de référence des modèles sur celui-ci.
Algorithmes de détection d’objets et familles d’architectures
Les modèles de détection d’objets s’inscrivent dans deux flux de traitement distincts et appartiennent à deux familles d’architectures différentes.
Architectures
Basées sur les CNN
Exemples : Faster R-CNN, Mask R-CNN, Cascade R-CNN, YOLO
Les détecteurs basés sur les CNN s’appuient sur des couches convolutives pour extraire hiérarchiquement des caractéristiques locales à travers l’image, en utilisant traditionnellement des « anchor boxes » prédéfinies comme a priori spatiaux pour localiser les objets. Les a priori spatiaux sont des hypothèses prédéfinies concernant l’emplacement et la taille des objets susceptibles d’apparaître dans une image, ce qui donne au modèle un point de départ pour la détection plutôt que de procéder à une recherche aléatoire.
Basés sur les Transformers
Exemples : RF-DETR, RT-DETR, D-FINE
Les détecteurs basés sur les transformateurs, inspirés par les avancées en traitement du langage naturel, appliquent à la place des mécanismes d’auto-attention globaux qui permettent au modèle de raisonner simultanément sur les relations à l’échelle de l’image entière. Plus précisément, les détecteurs basés sur les transformateurs utilisent des requêtes d’objets apprises et l’auto-attention globale, chaque requête étant entraînée pour correspondre à un objet au maximum, contrairement aux détecteurs basés sur les CNN, qui construisent une compréhension spatiale localement via des couches convolutives aux champs réceptifs limités.
Cependant, dans les architectures modernes, on observe une fusion des deux approches : un réseau CNN peut intégrer des modules d’auto-attention dans son architecture, comme c’est le cas pour YOLOv12 ou YOLOv13, ce qui donne lieu à des conceptions inter-architecturales.
Flux de traitement
Détecteurs en deux étapes
Exemples : Faster R-CNN, Mask R-CNN, Cascade R-CNN
Le réseau effectue deux passages successifs, chacun ayant une tâche distincte :
- Étape 1 : Proposition de régions (Region Proposal) :
Analyse l’image et propose environ 1 000 à 2 000 régions candidates (RoI) susceptibles de contenir des objets.
Il ne tient pas encore compte de la classe, mais uniquement du fait qu’« il y a quelque chose d’intéressant ici ».
Il s’agit du réseau de proposition de régions (RPN) dans les détecteurs classiques.
- Étape 2 : Classification et affinement des RoI :
Ne prend en compte que les régions proposées à l’étape 1.
Recadre/agrège les caractéristiques pour chaque région.
Prédit la classe exacte et les coordonnées affinées du cadre pour chaque proposition.
Détecteurs à étape unique
Exemples : série YOLO, SSD, RetinaNet, DETR
Le réseau prédit directement les étiquettes de classe et les boîtes englobantes à partir des cartes de caractéristiques. Il effectue toutes ces opérations en un seul passage avant. En général, le processus se déroule comme suit :
- Une grille dense de boîtes d’ancrage (ou de points) est placée sur l’image.
- Pour chaque point d’ancrage, le réseau prédit simultanément :
S’il y a un objet à cet endroit (score d’objet/de classe).
Comment le rectangle doit être ajusté (décalages de régression du rectangle).
- Dans les anciennes versions des détecteurs à un seul étage, il fallait filtrer les rectangles de délimitation qui se chevauchaient à la fin ; cela se faisait à l’aide de l’algorithme de suppression du non-maximum (NMS). À partir de YOLOv10, l’utilisation du NMS est une étape superflue.
De plus, les détecteurs modernes à un seul étage se sont complètement éloignés des conceptions basées sur des ancrages, prédisant les coordonnées des rectangles directement à partir des points de la grille et des pixels, ce qui élimine totalement le besoin d’un réglage des ancrages spécifique à chaque ensemble de données.
Historiquement, les détecteurs à deux étapes offraient une meilleure précision au détriment de la vitesse, mais les détecteurs modernes à un seul étage ont largement comblé cet écart, obtenant des résultats comparables, voire supérieurs, tout en restant nettement plus rapides. Ainsi, nous nous concentrerons uniquement sur les détecteurs à un seul étage lors de l’évaluation des modèles de pointe pour des applications pratiques.
Les meilleurs modèles de détection d'objets en 2026
Les pipelines en deux étapes (Faster R-CNN, Mask R-CNN) ne sont plus compétitifs. La pointe de la technologie est désormais représentée par les architectures de transformateurs en une seule étape sans NMS et les modèles de la famille YOLO. Chacun des modèles présentés ci-dessous excelle dans un scénario de déploiement spécifique.
RF-DETR (de Roboflow) – Précision maximale
Le modèle en temps réel le plus performant à ce jour. RF-DETR utilise DINOv2 pour extraire des représentations de caractéristiques extrêmement riches et globales de l’image d’entrée, puis recourt à une attention croisée déformable dans la tête de détection afin d’interroger efficacement ces caractéristiques et de prédire des cadres de sélection sans avoir besoin de cadres d’ancrage ni de post-traitement NMS. Il en résulte un modèle qui est à la fois plus précis sur des scènes complexes et plus rapide en inférence que ne le laisserait supposer la combinaison naïve de ces composants. RF-DETR est le premier détecteur en temps réel à dépasser les 60 mAP sur MS COCO. Conçu dès le départ pour le réglage fin, le pré-entraînement de DINOv2 sur des données à l’échelle d’Internet lui confère une adaptabilité sans pareille à divers domaines, notamment l’imagerie aérienne, les examens médicaux, l’inspection industrielle et bien d’autres encore. Il est disponible en quatre tailles : Nano, Small, Medium, Large (ainsi que XL/2XL sous licence PML).
Points forts :
- Le mAP le plus élevé de tous les modèles en temps réel.
- Transfert de domaine exceptionnel (réglage fin rapide).
- Performances optimales sur les scènes occluses et complexes.
- Prend en charge la détection et la segmentation via une seule API.
- Licence Apache 2.0, entièrement adaptée à un usage commercial.
Limites :
- Plus lourd que YOLO sur les appareils embarqués/mobiles.
- Les modèles XL/2XL nécessitent une licence PML.
- Mémoire GPU plus importante par rapport aux variantes de YOLO.
Licence : Apache 2.0 (N/S/M/L) · PML 1.0 (XL/2XL)
YOLO12 (Université de Tsinghua) – Recherche / Test de performance
YOLO12 est le premier modèle YOLO à placer les mécanismes d'attention au cœur du système plutôt que les réseaux CNN, tout en offrant des vitesses d'inférence comparables à celles des modèles basés sur les CNN et en tirant parti des avantages de l'auto-attention en termes de contexte global. Principales innovations : l’attention par zone (A²) divise les cartes de caractéristiques en régions afin de réduire le coût quadratique de l’auto-attention complète ; le Residual ELAN (R-ELAN) stabilise l’entraînement des grands blocs d’attention ; FlashAttention réduit les goulots d’étranglement liés à la mémoire. Il est déployable sur NVIDIA Jetson, les GPU NVIDIA et macOS.
Remarque concernant les implémentations. YOLO12 existe sous la forme de deux bases de code distinctes, et cette distinction a son importance dans la pratique. Les auteurs originaux (Tsinghua/Université de Buffalo) assurent activement la maintenance de leur propre dépôt sur sunsmarterjie/yolov12. En juin 2025, ils ont explicitement déconseillé l’utilisation de l’intégration d’Ultralytics, affirmant qu’elle « est inefficace, nécessite plus de mémoire et présente un apprentissage instable » – des problèmes qu’ils ont corrigés dans leur propre dépôt. Les critiques concernant l’instabilité de l’entraînement et la consommation de mémoire souvent formulées à l’encontre de YOLO12 visent donc le portage d’Ultralytics, et non le modèle lui-même. La recommandation d’Ultralytics de privilégier YOLO26 plutôt que YOLO12 doit être replacée dans ce contexte : la comparaison s’effectue en partie par rapport à leur propre implémentation, qui n’est pas optimale.
Si vous utilisez YOLO12, installez-le à partir du dépôt d’origine plutôt que via la commande pip install ultralytics.
Points forts :
- Grande précision à l’échelle nanométrique (dépasse YOLO11-N de 0,9 % en mAP).
- Contexte à longue portée via des mécanismes d’attention : il peut prendre en compte l’image entière lors de la détection d’un objet, plutôt que le voisinage local de pixels, comme dans les architectures CNN pures.
- Déployable sur Jetson, Android et macOS.
- Le dépôt d’origine corrige les problèmes de mémoire et de stabilité de l’entraînement présents dans le portage d’Ultralytics.
- Maintenu activement par les auteurs d’origine avec des mises à jour régulières (variante « turbo », segmentation et classification).
Limites :
En cas d’utilisation de l’implémentation d’Ultralytics :
- L’utilisation commerciale sous licence AGPL-3.0 nécessite une licence d’entreprise.
- Instabilité de l’entraînement et consommation mémoire élevée sur les grands modèles.
En cas d’utilisation d’une implémentation open source :
- L’utilisation commerciale sous licence AGPL-3.0 nécessite une licence d’entreprise.
- Prétend offrir un entraînement et une inférence stables par rapport à l’implémentation Ultralytics.
- Nécessite une installation à partir du dépôt d’origine pour éviter les problèmes liés au portage d’Ultralytics, ce qui rend la configuration légèrement plus fastidieuse.
- Écosystème et soutien communautaire plus restreints que pour les modèles natifs d’Ultralytics.
Licence : AGPL-3.0 (open source) · Licence d’entreprise via Ultralytics pour une utilisation commerciale
YOLO26 (Ultralytics) – Idéal pour les applications en périphérie et en production
Le produit phare d’Ultralytics pour 2025–2026. YOLO26 délaisse la maximisation de la précision au profit d’une simplification axée sur le déploiement : il supprime le NMS et la perte focale de distribution (DFL) pour l’inférence de bout en bout, introduit l’optimiseur MuSGD pour une convergence stable, et ajoute l’équilibrage progressif des pertes (ProgLoss), qui garantit que le modèle ne sur-optimise pas un objectif au détriment des autres, ainsi que l’attribution d’étiquettes tenant compte des petites cibles (STAL), qui assure une attention particulière aux petits objets. Ce modèle YOLO26 unique permet de résoudre cinq tâches : la détection, la segmentation, l’estimation de la pose, la détection de boîtes englobantes orientées, ainsi que la détection et la segmentation à vocabulaire ouvert. Il est explicitement conçu pour les processeurs NVIDIA Jetson Orin/Xavier, Qualcomm Snapdragon AI et ARM. Il prend en charge la quantification INT8 et FP16, ainsi que l’exportation vers ONNX, TensorRT, CoreML et TFLite.
Points forts :
- Meilleures performances en périphérie et sur mobile (Jetson Orin et Snapdragon).
- L’absence de NMS permet une latence réduite.
- Inférence CPU 43 % plus rapide que YOLO11(N) avec une précision comparable, idéal pour les appareils sans GPU.
- Cinq tâches dans une seule architecture.
- Quantification INT8/FP16 stable.
Limites :
- AGPL-3.0 : l’utilisation commerciale nécessite une licence d’entreprise.
- Précision maximale inférieure à celle de RF-DETR XL.
Licence : AGPL-3.0 (open source) · Licence d’entreprise via Ultralytics pour une utilisation commerciale/industrielle.
Comparaison des performances
Afin de permettre une comparaison entre les modèles, voici les valeurs exactes des tests de performance. Tous les scores ont été obtenus sur le jeu de données MS COCO val2017. La latence a été mesurée sur un GPU NVIDIA T4.
Voici une visualisation des résultats ci-dessus, accompagnée d'autres modèles modernes de détection d'objets, pour une comparaison plus complète :
Recommandations d'utilisation
Objets masqués : RF-DETR (M/L) s’impose clairement. Son architecture DINOv2 modélise le contexte global sur l’ensemble de l’image, ce qui le rend nettement plus performant que les modèles basés sur les réseaux neuronaux convolutifs (CNN) pour détecter des objets partiellement masqués.
Petits objets : RF-DETR utilise une extraction de caractéristiques multi-échelle. YOLO26 intègre également le STAL (Small-Target-Aware Label Assignment), ce qui le rend compétitif pour la détection de petits objets sur du matériel embarqué.
Périphérie / mobile / Jetson : YOLO26-N ou YOLO12-N. YOLO26 est la recommandation d’Ultralytics pour les processeurs Jetson Orin/Xavier, Snapdragon AI et ARM. Il offre une inférence CPU 43 % plus rapide que YOLO11n avec une précision comparable.
Domaine personnalisé / réglage fin : RF-DETR, et de loin. Grâce à son pré-entraînement, DINOv2 s’adapte aux nouveaux domaines (médical, aérien et industriel) plus rapidement et avec moins de données que n’importe quel autre modèle présenté ici.
Résumé des licences
Code de démarrage rapide
RF-DETR
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 | # Install
pip install rfdetr
# Inference
from rfdetr import RFDETRBase
model = RFDETRBase()
detections = model.predict("image.jpg")
# Fine-tune on your dataset
model.train(dataset_dir="./my_dataset", epochs=50, batch_size=4) |
YOLO26 / YOLO12 (via Ultralytics)
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | # Install
pip install ultralytics
# Inference — YOLO26
from ultralytics import YOLO
model = YOLO("yolo26n.pt") # or yolo26s/m/l/x
results = model.predict("image.jpg")
# Inference — YOLO12
model = YOLO("yolo12n.pt")
results = model.predict("image.jpg")
# Export for edge (TensorRT / CoreML / ONNX)
model.export(format="engine") # TensorRT for Jetson
model.export(format="coreml") # Apple Silicon / iOS
model.export(format="tflite") # Android / ARM |
YOLO12 (utiliser le dépôt open source d'origine – et non l'intégration Ultralytics)
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | # Install from the original authors' repo
conda create -n yolov12 python=3.11
conda activate yolov12
git clone https://github.com/sunsmarterjie/yolov12 && cd yolov12
pip install -r requirements.txt
pip install -e .
# Inference
from ultralytics import YOLO
model = YOLO("yolov12n.pt") # or s/m/l/x
results = model("path/to/image.jpg")
results[0].show()
# Export for edge
model.export(format="engine", half=True) # TensorRT FP16
model.export(format="onnx") # ONNX for broad compatibility |
Apprentissage par transfert et affinage
RF-DETR – recommandé pour le changement de domaine. Grâce à une architecture de base DINOv2 pré-entraînée sur des données à l’échelle d’Internet, l’affinage nécessite moins de données étiquetées et converge plus rapidement. Utilisez le package rfdetr avec un point de contrôle pré-entraîné sur COCO. Roboflow propose également une interface utilisateur hébergée pour l’affinage.
YOLO26 / YOLO12 – pipeline le plus simple. L’API d’entraînement d’Ultralytics constitue l’écosystème de réglage fin le plus abouti. Elle prend en charge les ensembles de données aux formats YOLO et COCO, et bénéficie d’une documentation de qualité ainsi que d’une communauté active.
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 | # Fine-tuning YOLO26 on a custom dataset (YOLO format)
from ultralytics import YOLO
model = YOLO("yolo26m.pt") # start from pretrained weights
model.train(
data="custom_dataset.yaml", # path to your dataset config
epochs=100,
imgsz=640,
batch=16,
device=0, # GPU index; "cpu" for CPU
)
metrics = model.val() # evaluate on validation set |
Résumé : choisir le modèle adapté à votre projet
Le choix d’un modèle de détection d’objets nécessite de mettre en adéquation vos exigences spécifiques avec les points forts de chaque modèle. Le cadre décisionnel ci-dessous met en correspondance des scénarios courants avec les choix de modèles optimaux.
Commencez dès aujourd’hui avec PyCharm
PyCharm est un environnement de développement intégré (EDI) destiné à la programmation en Python. Il propose des fonctionnalités d'analyse de code, un débogueur graphique, un outil de test unitaire intégré, une intégration avec les systèmes de contrôle de version, et prend en charge le développement web avec Django. PyCharm est développé par JetBrains et repose sur sa plateforme IntelliJ. PyCharm est multiplateforme et fonctionne sous Microsoft Windows, macOS et Linux. Certaines parties du code source de PyCharm sont publiées sous licence Apache et disponibles sur GitHub ; un abonnement est proposé pour accéder aux fonctionnalités propriétaires.
Le choix d’une architecture de détection d’objets en 2026 est une décision stratégique dictée par les exigences spécifiques de l’application et le budget de calcul disponible. Que l’on privilégie la précision record de RF-DETR pour les scènes complexes ou l’efficacité inégalée de la famille YOLO pour le déploiement en périphérie, le choix doit trouver un équilibre entre les exigences en matière de mAP et les contraintes de latence en temps réel.
Le paysage de la vision par ordinateur évolue rapidement vers des frameworks de détection « zero-shot » qui reconnaissent des objets inédits sans supervision spécifique à la tâche. À mesure que les modèles de base intègrent de plus en plus des embedders d’images sophistiqués tels que CLIP ou DINOv2 dans les pipelines de détection, les limites de la détection de haute précision sur du matériel aux ressources limitées continueront de s’étendre. Alors que les architectures basées sur les transformateurs se développent rapidement, l’écosystème bien établi de la famille YOLO lui assure de rester une pierre angulaire pour les environnements de production en temps réel.
Pour obtenir les meilleurs résultats adaptés à votre cas d’utilisation spécifique, nous vous encourageons à tester les modèles et les exemples de code fournis dans ce guide. À cette fin, PyCharm offre l’écosystème idéal pour expérimenter divers modèles open source via l’interface Code -> Insert HF Model. Si vous souhaitez vous y essayer, PyCharm Pro propose une période d’essai de 30 jours.
Essayer PyCharm pour la création de modèles de données et d'agents IA
Vous avez lu gratuitement 3 457 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.