Analyse vidéo par IA : meilleurs outils gratuits et modèles open source (2026)

L’analyse vidéo par IA transforme les vidéos en données structurées que les logiciels peuvent rechercher, mesurer, classer et exploiter. Ce guide se concentre sur les solutions gratuites et auto-hébergées destinées aux développeurs qui doivent choisir entre exécuter eux-mêmes les modèles ou utiliser une API externe. Vous y trouverez les principaux modèles open source actuels, classés par tâche, avec leurs licences et leurs besoins matériels, afin de comparer les options adaptées aux tests locaux, au déploiement sur serveur et aux charges vidéo plus importantes.

La question principale ne consiste pas seulement à savoir ce qu’un modèle peut détecter. La vidéo ajoute une dimension temporelle, ce qui modifie à la fois la difficulté du problème et son coût. Un système efficace peut devoir suivre une même personne ou un même objet sur des centaines d’images, comprendre des actions qui se déroulent sur plusieurs secondes, distinguer différents plans et traiter plusieurs heures de vidéo sans rendre les coûts de calcul trop élevés.

Les sections suivantes détaillent ces besoins selon les principales tâches d’analyse vidéo par IA et présentent les solutions open source disponibles pour chacune d’elles.

* Google publie le dépôt MediaPipe sous licence Apache-2.0, mais ne fournit pas de déclaration de licence distincte pour les poids du modèle Pose Landmarker.

Qu’est-ce que l’analyse vidéo par IA ?

L’analyse vidéo par IA désigne l’utilisation de modèles de machine learning pour extraire des informations à partir des images d’une vidéo, des mouvements, de l’audio et des changements qui se produisent au fil du temps. Ce domaine est également couramment appelé Video Content Analysis (VCA), ou analyse de contenu vidéo.

Analyse vidéo vs analyse d’image : pourquoi le temps change tout

L’analyse d’image traite chaque image comme une entrée indépendante. L’analyse vidéo doit également prendre en compte ce qui se passe entre les images.

L’identité en est un bon exemple. Détecter une personne sur une seule image relève de l’analyse d’image. Suivre cette même personne dans un couloir, après une occlusion partielle ou sur plusieurs centaines d’images nécessite de conserver son identité dans le temps. Une nouvelle détection à chaque image ne suffit donc pas.

Le mouvement apporte également des informations qu’une image fixe ne peut pas fournir. Une image peut montrer une personne à côté d’un vélo, tandis qu’une séquence vidéo permet de déterminer si cette personne est en train de le conduire, de le pousser, de s’en approcher ou de s’en éloigner. Certains événements ne peuvent être compris qu’en analysant plusieurs images successives.

Le coût évolue lui aussi. Une vidéo peut contenir de nombreuses images par seconde, ce qui signifie que les besoins en calcul augmentent à la fois avec la durée de la vidéo et avec sa fréquence d’images. Un modèle peu coûteux à exécuter sur une seule image peut devenir beaucoup plus cher lorsqu’il est appliqué à chaque image d’un enregistrement d’une heure.

Les changements de plan et de scène ajoutent une difficulté supplémentaire. Une vidéo peut passer d’une caméra à une autre, changer de lieu ou de sujet. Les systèmes qui ne tiennent pas compte de ces transitions risquent d’associer des objets ou des actions appartenant à des parties totalement différentes de la vidéo.

Les principales tâches de l’analyse vidéo par IA

La plupart des systèmes d’analyse vidéo combinent plusieurs des tâches suivantes :

• Détection d’objets : identifie et classe les objets présents dans chaque image de la vidéo.
• Suivi d’objets : associe les détections entre plusieurs images afin qu’un même objet conserve une identité cohérente au fil du temps.
• Segmentation : attribue des pixels à des objets ou à des zones précises, tout en pouvant suivre leur évolution d’une image à l’autre.
• Estimation de pose : détecte les points clés du corps et peut suivre l’évolution de la posture ou des mouvements d’une personne au cours d’une séquence.
• Génération de descriptions et compréhension vidéo : produit du texte ou des interprétations structurées à partir des événements, des actions et du contexte observés sur plusieurs images.
• Recherche et récupération vidéo : permet de retrouver des extraits ou des moments pertinents à partir de texte, du contenu visuel, d’actions ou d’autres caractéristiques indexées.
• Transcription de la piste audio : convertit les paroles présentes dans une vidéo en texte consultable, éventuellement associé à des horodatages.

Comment avons-nous sélectionné ces modèles ?

Nous avons sélectionné les modèles selon des critères qui comptent réellement pour les équipes souhaitant déterminer si l’auto-hébergement est une option viable.

Tout d’abord, le modèle devait être activement maintenu, avec une sortie ou une mise à jour significative au cours des 18 derniers mois. Nous avons également vérifié sa licence pour un usage commercial, car certains modèles de recherche bien connus imposent des restrictions sur les déploiements commerciaux.

Les exigences matérielles ont également servi de filtre. Nous nous sommes concentrés sur des modèles pouvant fonctionner sur du matériel accessible à une équipe d’ingénierie classique, et nous indiquons les besoins en VRAM lorsque cette information est disponible. Un modèle qui ne fonctionne que sur de grands clusters de recherche est moins pertinent pour la plupart des équipes produit.

Nous avons aussi recherché des résultats de benchmarks publiés sur des jeux de données reconnus. Nous n’avons pas exécuté notre propre suite de benchmarks ni testé chaque modèle en production. Nous avons plutôt comparé les résultats publiés, les conditions de licence, l’activité de maintenance et les besoins matériels annoncés. Lorsqu’un chiffre de performance provient du fournisseur du modèle ou de l’équipe du projet plutôt que de tests indépendants, nous le précisons.

Enfin, le modèle devait être conçu pour la vidéo, et non être simplement un modèle d’image appliqué indépendamment à chaque frame.

Tous les résultats de benchmarks cités dans cet article proviennent de la documentation ou de la publication scientifique du modèle concerné.

Modèles vision-langage : le changement qui a transformé l’analyse vidéo

L’approche historique de l’analyse vidéo reposait sur des modèles spécialisés. Un modèle détectait les objets, un autre associait ces détections entre les frames et un troisième classait les actions. Mettre en place un système en production impliquait souvent d’assembler plusieurs composants dans un pipeline, puis de gérer le passage des données d’un composant à l’autre.

Chaque étape possédait également ses propres données d’entraînement et son propre ensemble de catégories. Pour détecter des véhicules de livraison, les suivre et identifier le moment où ils s’arrêtent dans une zone de chargement, il pouvait être nécessaire de disposer de jeux de données ou d’étapes d’ajustement distincts pour la détection, le suivi et la reconnaissance d’actions. Ajouter une nouvelle question pouvait alors nécessiter de modifier une partie du pipeline et de collecter de nouveaux exemples annotés.

Les modèles vision-langage appliqués à la vidéo changent cette interface. Au lieu de définir d’abord une tâche fixe, vous fournissez au modèle une vidéo accompagnée d’une question en langage naturel. La réponse peut prendre la forme de texte, d’horodatages ou d’un autre format structuré pris en charge par le modèle. Il devient par exemple possible de demander « à quel moment le véhicule de livraison arrive-t-il ? » sans entraîner au préalable un détecteur spécifique de véhicules pour répondre à cette question.

Cette approche ouvre la voie à plusieurs types d’analyses difficiles à mettre en œuvre avec des pipelines reposant sur des catégories fixes. Les requêtes en vocabulaire ouvert permettent aux utilisateurs de poser des questions sur des objets, des actions ou des situations qui n’ont pas été définis comme un ensemble fermé de classes lors du déploiement.

La localisation temporelle permet d’identifier le moment précis où un événement se produit, au lieu de seulement signaler qu’un objet ou une action apparaît quelque part dans la vidéo. Un contexte plus long permet également d’analyser des volumes de vidéo beaucoup plus importants, y compris des contenus de plusieurs heures plutôt que de simples clips courts.

La contrepartie concerne le coût et la vitesse. Un modèle vision-langage vidéo nécessite beaucoup plus de ressources de calcul par minute de vidéo qu’un petit détecteur conçu pour une tâche fixe. Il est également peu adapté à de nombreux flux vidéo en temps réel à 30 FPS exécutés sur du matériel edge. Lorsque les besoins prioritaires sont une faible latence, un débit élevé et un ensemble stable de catégories, un détecteur, un tracker ou un classificateur spécialisé reste le meilleur choix.

La liste des modèles ci-dessous est donc organisée par tâche, plutôt que de considérer tous les modèles vidéo comme interchangeables. En 2026, la plupart des systèmes en production combinent les deux approches : un détecteur peu coûteux assure l’analyse continue, tandis qu’un modèle vision-langage traite les requêtes nécessitant davantage de raisonnement.

Compréhension et description de vidéos

Les deux principaux choix généralistes sont ici Qwen3-VL et InternVideo3, mais leur positionnement est différent. Qwen3-VL dispose d’un écosystème multimodal plus large et prend en charge un contexte allant jusqu’à 1 million de tokens. InternVideo3 est davantage spécialisé dans la vidéo et devance actuellement Qwen3-VL-8B sur 12 des 15 benchmarks vidéo présentés dans l’article d’InternVideo3. La comparaison n’est toutefois pas à sens unique puisque Qwen3-VL-8B reste devant sur LVBench, VideoMME-v2 et TempCompass.

Les chiffres ci-dessous proviennent de l’article InternVideo3, arXiv 2606.12195, dans lequel Qwen3-VL-8B a été évalué comme modèle de référence. Les résultats publiés directement par Qwen peuvent différer.

À titre de comparaison, le même benchmark Video-MME rapporte un score de 88,6 pour Gemini 3 Pro, 87,8 pour Gemini 2.5 Pro et 83,3 pour GPT-5. Les modèles à poids ouverts restent derrière ces résultats sur ce benchmark, ce qui signifie que l’auto-hébergement implique encore un compromis mesurable en matière de qualité.

Qwen3-VL (Alibaba)

Sorties les 15 et 21 octobre 2025, rapport technique publié le 27 novembre 2025 · Apache-2.0, usage commercial autorisé

Qwen3-VL est le modèle vision-langage généraliste le plus polyvalent de cette sélection. Il prend en charge la compréhension de vidéos longues, la localisation d’événements dans la vidéo, la génération de descriptions vidéo détaillées, les horodatages textuels et une architecture Interleaved-MRoPE.

Les variantes denses sont disponibles en 2B, 4B, 8B et 32B, chacune proposée en versions Instruct et Thinking. Les variantes MoE comprennent le 30B-A3B, avec 3 milliards de paramètres actifs, et le 235B-A22B, avec 22 milliards de paramètres actifs. Le contexte natif atteint 256K tokens et peut être étendu jusqu’à 1M de tokens.

Dans l’article InternVideo3, Qwen3-VL-8B obtient 71,4 sur Video-MME, 62,4 sur LongVideoBench, 68,7 sur MVBench et 58,0 sur LVBench. La documentation officielle ne publie pas d’exigences en matière de VRAM.

Idéal pour : les systèmes multimodaux généralistes qui nécessitent un contexte long, des questions vidéo avec horodatage et un écosystème plus large plutôt qu’un modèle exclusivement spécialisé dans la vidéo.

InternVideo3 (OpenGVLab / Shanghai AI Lab)

Sorti en juin 2026 · Apache-2.0

InternVideo3 est le modèle spécialisé dans la vidéo de cette sélection. Le modèle Instruct 8B actuel devance Qwen3-VL-8B dans la majorité des comparaisons mentionnées ci-dessus et obtient les meilleurs résultats parmi les modèles à poids ouverts dans les données présentées sur Video-MME, MLVU, VRBench et EgoSchema.

Il obtient 73,8 sur Video-MME, 77,3 sur MLVU, 69,4 sur VRBench et 76,6 sur EgoSchema. Il peut fonctionner sur un seul GPU H200. Son mécanisme M2LA vise également à améliorer l’efficacité sur les longs contextes, avec un débit de décodage 1,84 fois supérieur avec 32K tokens de prefill et 5,01 fois supérieur avec 384K, tout en restant exécutable avec un prefill de 512K tokens là où le modèle de référence manque de mémoire.

La famille InternVideo montre également une maintenance continue : InternVideo1 est sorti en janvier 2023, les checkpoints InternVideo2 en avril 2024, InternVideo2.5 en janvier 2025, InternVideo-Next en décembre 2025 et InternVideo3 en juin 2026.

Idéal pour : les systèmes auto-hébergés de questions-réponses sur la vidéo, de recherche, de localisation temporelle et d’analyse de longs contextes lorsque les performances sur les benchmarks vidéo comptent davantage que la largeur de l’écosystème multimodal.

VideoMAE (MCG-NJU)

NeurIPS 2022 Spotlight · CC-BY-NC 4.0, usage commercial interdit

VideoMAE est un backbone destiné à la classification et à la représentation vidéo plutôt qu’un modèle conversationnel. Son entraînement par autoencodeur vidéo masqué cache 80 % des tokens frame par frame, et les variantes disponibles sont ViT-S, ViT-B, ViT-L et ViT-H, préentraînées sur Kinetics-400.

La précision top-1 publiée sur Kinetics-400 est de 79,0 % pour ViT-S, 81,5 % pour ViT-B, 85,2 % pour ViT-L, 86,6 % pour ViT-H et 87,4 % pour ViT-H en 320 × 320 avec 32 frames. Sur Something-Something V2, les chiffres corrects sont de 66,8 % pour ViT-S, 70,8 % pour ViT-B, 74,3 % pour ViT-L et 75,4 % pour ViT-L avec 32 frames.

Idéal pour : la recherche ou les projets internes de classification et de représentation vidéo lorsque l’usage commercial n’est pas nécessaire.

Gemma 4 (Google)

Apache 2.0 selon la fiche du modèle.

Gemma 4 doit davantage être considéré comme un modèle multimodal destiné aux clips courts que comme un système conçu pour les vidéos longues. L’entrée vidéo est limitée à environ 60 secondes à raison d’une frame par seconde, tandis que l’entrée audio est limitée à 30 secondes. La prise en charge de l’audio est limitée aux modèles E2B, E4B et 12B. Google ne publie pas de résultats de benchmarks vidéo pour Gemma 4.

La taille des modèles et leur fenêtre de contexte varient selon les versions. E2B compte 2,3 milliards de paramètres effectifs, 5,1 milliards en incluant les embeddings, avec un contexte de 128K. E4B compte 4,5 milliards de paramètres effectifs, 8 milliards en incluant les embeddings, avec un contexte de 128K. Le modèle Unified 12B compte 11,95 milliards de paramètres et dispose d’un contexte de 256K.

Le modèle MoE 26B-A4B compte 25,2 milliards de paramètres au total, dont 3,8 milliards actifs, avec un contexte de 256K. Le modèle Dense 31B compte 30,7 milliards de paramètres et dispose également d’un contexte de 256K. La désignation « E » correspond aux paramètres effectifs obtenus grâce aux Per-Layer Embeddings.

Les chiffres de consommation mémoire ci-dessous proviennent de mesures communautaires réalisées par Unsloth et non de spécifications officielles de Google.

Idéal pour : les traitements multimodaux de clips courts sur du matériel local, lorsque la vidéo et l’audio doivent être traités par un seul modèle et qu’une durée d’environ 60 secondes par vidéo est suffisante.

Détection d’objets

Les détecteurs d’objets fonctionnent toujours image par image. Dans un pipeline vidéo, le détecteur identifie les objets présents dans chaque frame, tandis qu’un tracker relie ces détections dans le temps afin qu’une même personne, un même véhicule ou un même objet conserve une identité stable. La sous-section suivante est consacrée à cette étape de suivi.

La latence a également un effet direct sur le débit de traitement vidéo. Un détecteur suffisamment rapide pour analyser quelques images ponctuellement peut ne plus suivre le rythme d’un flux en direct lorsqu’il doit être exécuté plusieurs dizaines de fois par seconde.

YOLO26 (Ultralytics)

Annoncé en septembre 2025, sorti en janvier 2026 · AGPL-3.0 ou licence Enterprise payante. La licence AGPL impose la divulgation du code source, les produits propriétaires nécessitent donc une licence Enterprise.

YOLO26 est le détecteur d’Ultralytics conçu en priorité pour les déploiements edge, notamment la robotique, les drones, les appareils mobiles et les systèmes embarqués. Son architecture ajoute notamment une inférence native de bout en bout sans NMS, une régression sans DFL, Progressive Loss avec STAL pour une attribution des labels adaptée aux petites cibles, MuSGD et des têtes spécialisées selon les tâches. Il prend en charge la détection, la segmentation d’instances, la segmentation sémantique, l’estimation de profondeur, la classification, l’estimation de pose et les boîtes englobantes orientées.

À une résolution de 640 px, YOLO26n atteint 40,9 de mAP50-95 avec 2,4 millions de paramètres et 5,4 milliards de FLOPs. Sur le processeur Intel Xeon testé, il nécessite 38,9 ms par frame, soit environ 26 FPS. Ce résultat est déjà inférieur aux 30 FPS d’un flux vidéo en temps réel, avant même d’ajouter le coût du décodage et du tracking. Sur un GPU T4 avec TensorRT10, le même modèle nécessite 1,7 ms par frame, soit environ 588 FPS, ce qui laisse beaucoup plus de marge pour traiter plusieurs flux simultanément.

YOLO26 prend également en charge la détection en vocabulaire ouvert. YOLOE-26x atteint 40,6 AP sur LVIS minival avec des prompts textuels, ce qui permet de rechercher dans une vidéo des concepts définis en texte sans entraîner un détecteur autour d’une liste fixe de classes.

Idéal pour : les pipelines vidéo qui recherchent une meilleure précision de détection pour une taille de modèle donnée, notamment sur de petits déploiements CPU ou des charges GPU où la détection en vocabulaire ouvert est utile.

YOLO11 (Ultralytics)

Sorti le 10 septembre 2024 · AGPL-3.0 ou licence Enterprise payante. La licence AGPL impose la divulgation du code source, les produits propriétaires nécessitent donc une licence Enterprise.

YOLO11 reste une référence largement déployée dans l’écosystème Ultralytics, avec de nombreux tutoriels et intégrations disponibles. Il prend en charge la détection, la segmentation d’instances, la classification, l’estimation de pose et les boîtes englobantes orientées.

À une résolution de 640 px, YOLO11n atteint 39,5 de mAP50-95 avec 2,6 millions de paramètres et 6,5 milliards de FLOPs. Il nécessite 56,1 ms sur le processeur Intel Xeon testé et 1,5 ms sur un T4 avec TensorRT10. À l’autre extrémité de la gamme, YOLO11x atteint 54,7 de mAP50-95 avec 56,9 millions de paramètres et 194,9 milliards de FLOPs.

Sur GPU, YOLO26 n’apporte pas systématiquement un gain de débit. YOLO11n est plus rapide sur le T4 testé, avec 1,5 ms contre 1,7 ms pour YOLO26n, tandis que YOLO11x nécessite 11,3 ms contre 11,8 ms. Les variantes medium et large affichent la même latence T4 dans les deux familles.

Idéal pour : les pipelines Ultralytics déjà déployés en production lorsque la compatibilité, les intégrations existantes et le débit GPU comptent davantage que les gains de précision apportés par YOLO26.

YOLO26 vs YOLO11 sur CPU

Les performances CPU évoluent différemment selon la taille du modèle. YOLO26 est plus rapide uniquement pour les variantes nano et small. À partir de la variante medium, YOLO11 devient plus rapide.

Cette inversion est importante pour un déploiement vidéo. Choisir YOLO26m uniquement parce que le modèle nano est 31 % plus rapide sur CPU conduirait au résultat inverse : YOLO26m nécessite 220,0 ms par frame contre 183,2 ms pour YOLO11m, soit environ 20 % de temps supplémentaire sur le processeur testé.

L’avantage constant de YOLO26 concerne la précision. Il gagne 1,4 point de mAP50-95 sur la variante nano, 1,6 point sur les variantes small, medium et large, et 2,8 points sur la variante extra-large. La latence CPU ne s’améliore que sur les deux plus petites tailles.

Pour l’analyse vidéo, le choix du détecteur doit donc être effectué en fonction de la taille exacte du modèle et du matériel sur lequel il sera exécuté. Une fois les détections produites, un tracker reste nécessaire pour conserver l’identité des objets entre les frames.

Suivi d’objets

Tous les trackers modernes reposent sur un détecteur. Le détecteur détermine quels objets sont présents dans chaque frame, puis le tracker tente de conserver leur identité dans le temps. Un tracker performant ne peut pas compenser un détecteur médiocre, ce qui signifie que la qualité de la détection compte souvent davantage que de petites différences entre les méthodes d’association.

Les six trackers disponibles dans Ultralytics sont plus faciles à comprendre comme quelques familles proches que comme six solutions totalement indépendantes :

├── DeepSORT (2017, adds appearance)
├── ByteTrack (2022)
│   ├── BoT-SORT (+ camera-motion compensation, + optional ReID, improved Kalman state)
│   └── FastTracker (+ occlusion handling)
├── OC-SORT (2023, observation-centric)
│   └── Deep OC-SORT (+ ReID, + camera-motion compensation)
└── TrackTrack (multi-cue association)

‍

À partir d’Ultralytics YOLO v8.4.63, OC-SORT, Deep OC-SORT, FastTracker et TrackTrack sont disponibles aux côtés de BoT-SORT et ByteTrack. Sur les versions antérieures, seuls BoT-SORT et ByteTrack sont disponibles.

BoT-SORT

Aharon, Orfaig & Bobrovsky · Soumis le 29 juin 2022 · Licence MIT

BoT-SORT est le tracker utilisé par défaut dans Ultralytics. Il repose sur ByteTrack et FastReID. Il combine les informations de mouvement et d’apparence avec une compensation du mouvement de la caméra ainsi qu’un vecteur d’état de filtre de Kalman plus précis.

Sur le jeu de test MOT17, BoT-SORT atteint 80,6 en MOTA, 79,5 en IDF1 et 64,6 en HOTA. La variante avec ReID atteint 80,5 en MOTA, 80,2 en IDF1 et 65,0 en HOTA. Sur MOT20, BoT-SORT obtient 77,7 en MOTA, 76,3 en IDF1 et 62,6 en HOTA, tandis que BoT-SORT-ReID atteint 77,8 en MOTA, 77,5 en IDF1 et 63,3 en HOTA. Lors de sa publication, il occupait la première place sur les jeux de test MOT17 et MOT20 de MOTChallenge. Aucun chiffre de FPS n’a été publié.

Les résultats ReID permettent de mieux comprendre dans quels cas les embeddings d’apparence valent la peine d’être activés. Sur MOT17, l’ajout de ReID fait passer le MOTA de 80,6 à 80,5, mais augmente l’IDF1 de 79,5 à 80,2. Sur MOT20, le MOTA passe de 77,7 à 77,8 tandis que l’IDF1 progresse de 76,3 à 77,5. Pour les usages où la conservation de l’identité compte davantage que le nombre brut de détections, ce compromis peut justifier l’étape supplémentaire d’analyse de l’apparence.

Idéal pour : le suivi multi-objets généraliste lorsque la conservation de l’identité, les mouvements de caméra et l’association optionnelle par apparence sont importants.

ByteTrack

Zhang et al., ECCV 2022 · Licence MIT

ByteTrack suit les objets uniquement à partir des boîtes de détection, sans modèle d’apparence ni ReID. Sur MOT17, il atteint 80,3 en MOTA, 77,3 en IDF1 et 63,1 en HOTA à 29,6 FPS sur un seul GPU V100. Sur MOT20, il obtient 77,8 en MOTA, 75,2 en IDF1 et 61,3 en HOTA à 13,7 FPS sur le même GPU.

Ces mesures de FPS de bout en bout sont principalement déterminées par le coût du détecteur plutôt que par celui de l’association elle-même. Elles ne peuvent pas non plus être comparées directement aux 28 FPS d’OC-SORT, car OC-SORT a été mesuré sur une RTX 2080Ti et non sur une V100. L’avantage de ByteTrack en matière de débit vient surtout de la légèreté de son étape d’association, et non d’une comparaison directe des FPS publiés dans différents articles.

Idéal pour : le suivi vidéo à haut débit lorsque le faible coût de l’association compte davantage que la conservation de l’identité fondée sur l’apparence.

OC-SORT

Cao et al., CVPR 2023 · Licence MIT

OC-SORT est un tracker centré sur les observations et basé principalement sur le mouvement plutôt que sur le ReID. Sur MOT17 avec des détections privées, il atteint 78,0 en MOTA, 77,5 en IDF1 et 63,2 en HOTA. Sur MOT20 avec des détections privées, les résultats correspondants sont de 75,9, 76,4 et 62,4.

Sur le jeu de test DanceTrack, il obtient 89,4 en MOTA, 54,2 en IDF1 et 55,1 en HOTA. Ces résultats montrent pourquoi il ne faut pas se limiter au MOTA. Le MOTA est fortement influencé par les détections manquées et les faux positifs, tandis que l’IDF1 et le HOTA accordent davantage d’importance au maintien d’une même identité entre les frames.

Sur DanceTrack, les objets sont généralement bien détectés, mais les identités peuvent encore être interverties car les danseurs se ressemblent et leurs mouvements sont difficiles à prédire. Il ne faut donc pas comparer directement l’IDF1 de 54,2 sur DanceTrack avec les 77,5 obtenus sur MOT17 comme si le chiffre inférieur indiquait qu’OC-SORT était globalement moins performant.

OC-SORT fonctionne à environ 28 FPS sur une RTX 2080Ti de bout en bout. Son étape d’association seule atteint 700 FPS sur un processeur i9 à 3,0 GHz lorsque les détections sont fournies à l’avance, ce qui montre que le tracker lui-même peut ajouter très peu de coût de calcul par rapport au détecteur.

Idéal pour : les mouvements non linéaires et les scènes où l’association des identités devient difficile même lorsque la détection reste fiable.

Comment interpréter les résultats des benchmarks

Il ne faut pas considérer le tableau de benchmarks ci-dessous comme un classement direct des trackers. Les 80,3 de MOTA de ByteTrack et les 78,0 d’OC-SORT, par exemple, proviennent de publications différentes utilisant des détecteurs différents. Comme les métriques de tracking dépendent fortement de la qualité du détecteur, un écart de 2,3 points entre deux articles dit peu de choses sur la qualité de l’algorithme d’association lui-même.

BoT-SORT et ByteTrack sont un peu plus proches sur le plan technique puisque BoT-SORT est directement construit sur la base de code de ByteTrack, mais il faut malgré tout vérifier que les détecteurs utilisés sont identiques avant d’interpréter ces chiffres comme une comparaison contrôlée.

Pour compter des objets uniques, produire des analyses par objet ou réaliser toute tâche dépendant de l’identité, l’IDF1 et le HOTA sont plus importants que le MOTA. Le MOTA est souvent cité car il est familier, mais il peut masquer des changements d’identité coûteux dans un système d’analyse vidéo.

Cela explique également pourquoi BoT-SORT constitue un choix cohérent comme tracker par défaut dans Ultralytics. Dans les résultats MOT17 et MOT20 présentés ci-dessus, sa variante ReID obtient les meilleures valeurs d’IDF1 et de HOTA, deux métriques directement liées à la conservation de l’identité entre les frames.

Qu’est devenu DeepSORT ?

DeepSORT est désormais davantage une référence historique de 2017 qu’une recommandation actuelle. Il a introduit les embeddings d’apparence dans les pipelines de suivi de type SORT, ce qui permettait de mieux conserver les identités lorsque des objets se croisaient ou disparaissaient temporairement.

L’ancienne version de cet article présentait DeepSORT comme l’une des principales solutions de tracking. Cette recommandation est désormais dépassée. ByteTrack, BoT-SORT, OC-SORT, Deep OC-SORT, FastTracker et TrackTrack proposent des approches plus récentes autour de la modélisation du mouvement, du ReID, de la compensation des mouvements de caméra et de la gestion des occlusions.

DeepSORT reste important d’un point de vue historique, car il a contribué à établir le principe du suivi assisté par l’apparence. Il ne devrait toutefois plus être le choix par défaut pour une nouvelle implémentation en 2026.

Segmentation et suivi de concepts

SAM 3.1 (Meta)

Sorti le 27 mars 2026 · Meta SAM License, qui n’est pas une licence OSI standard. Consultez les conditions de licence avant toute utilisation dans un produit commercial.

SAM 3.1 est la recommandation actuelle de Meta pour la segmentation de concepts à partir de prompts. Il est présenté comme un remplacement direct de SAM 3, sorti le 19 novembre 2025.

Le principe reste celui de la Promptable Concept Segmentation : vous fournissez au modèle un groupe nominal comme « bus scolaire jaune » ou un exemple visuel, et il renvoie les masques ainsi que les identités de toutes les instances correspondantes. SAM 1 et SAM 2 prédisaient un seul objet par prompt. SAM 3 a introduit une architecture combinant détecteur et tracker, avec une tête de présence et un encodeur visuel partagé. SAM 3.1 améliore cette architecture pour mieux gérer plusieurs objets dans une vidéo.

Le principal changement est l’object multiplexing. SAM 3.1 peut suivre jusqu’à 16 objets en un seul passage avant, alors que SAM 3 traitait les objets individuellement. Sur un seul H100, le débit pour des vidéos contenant un nombre moyen d’objets passe de 16 FPS à 32 FPS. Le raisonnement global réduit les calculs redondants et les goulets d’étranglement liés à la mémoire, améliore la précision dans les scènes denses et réduit les besoins GPU afin que le modèle puisse fonctionner sur du matériel plus petit.

La base de SAM 3 compte environ 840 millions de paramètres et son checkpoint pèse 3,45 Go. Pour les images, Roboflow rapporte environ 30 ms par image sur un GPU H200 avec plus de 100 objets.

Les résultats de benchmarks ci-dessous concernent SAM 3 et non SAM 3.1. SAM 3 atteint 65,0 en CGF1 sur SA-Co/Gold contre un précédent meilleur résultat de 34,3, 47,0 en Mask AP zero-shot sur LVIS contre 38,5, 60,1 en J&F sur MOSEv2 contre 47,9 pour SAM 2.1, et 92,0 en J&F sur DAVIS 2017.

SAM 3 est également présenté comme plus performant sur les objets fins, petits, peu contrastés et partiellement occultés, avec des contours plus précis et une meilleure séparation entre les objets qui se touchent que SAM 2. SAM 3.1 repose sur cette base, mais ne dispose pas encore d’un tableau de benchmarks distinct ni d’un nombre de paramètres confirmé.

Idéal pour : la segmentation vidéo en vocabulaire ouvert, notamment pour les charges multi-objets où l’object multiplexing de SAM 3.1 rend le suivi à cadence de production plus réaliste sans entraîner un modèle de segmentation spécifique à chaque classe.

Estimation de pose et analyse du mouvement

La règle de déploiement est simple : MediaPipe pour le navigateur, RTMPose pour le CPU et l’edge, ViTPose pour les serveurs GPU.

La vidéo ajoute deux difficultés que les benchmarks de pose sur images fixes ne montrent pas. D’abord, les estimations de points clés frame par frame peuvent produire des tremblements ou des variations brusques. Les pipelines vidéo en production ont donc souvent besoin d’un lissage temporel. Un modèle de pose peut être précis sur des images isolées tout en générant des trajectoires de mouvement instables.

Ensuite, l’estimation de pose multi-personnes nécessite un système de tracking si les identités doivent rester cohérentes entre les frames. Pour cette partie du pipeline, reportez-vous à la section précédente sur le suivi d’objets.

RTMPose (MMPose / OpenMMLab)

Apache-2.0, usage commercial autorisé

RTMPose combine un backbone CSPNeXt avec une tête SimCC, en traitant la localisation des points clés comme une classification sur des coordonnées x et y discrétisées plutôt que comme des heatmaps.

Avec une entrée de 256 × 192, RTMPose-t atteint 68,5 de COCO AP à plus de 300 FPS sur un i7-11700 et plus de 940 FPS sur une GTX 1660Ti. RTMPose-s atteint 72,2 AP à plus de 200 FPS sur CPU et 710 FPS sur GPU. RTMPose-m atteint 75,8 AP à plus de 90 FPS sur CPU et 430 FPS sur GPU, tandis que RTMPose-l atteint 76,5 AP à plus de 50 FPS sur CPU et 280 FPS sur GPU.

Sur Snapdragon 865 avec ncnn FP16, la latence annoncée est de 9,02 ms pour RTMPose-t, soit environ 111 FPS, 13,89 ms pour RTMPose-s, soit environ 72 FPS, 26,44 ms pour RTMPose-m, soit environ 38 FPS, et 45,37 ms pour RTMPose-l, soit environ 22 FPS. L’article rapporte également plus de 70 FPS pour RTMPose-s et plus de 35 FPS pour RTMPose-m sur Snapdragon 865.

La conséquence pour la vidéo est directe : sur l’i7-11700 testé, toutes les variantes RTMPose de t à l dépassent 30 FPS. Un flux vidéo standard peut donc être traité en temps réel sans GPU, avant de prendre en compte le coût supplémentaire du décodage, du tracking et du lissage.

RTMPose prend en charge 17 points clés COCO ou 26 points Halpe pour le corps, 133 points COCO-WholeBody, 106 points pour le visage, 21 pour les mains et 17 pour les animaux.

Idéal pour : l’estimation de pose en temps réel sur CPU et matériel edge, notamment lorsqu’un flux vidéo à 30 FPS doit fonctionner sans GPU dédié.

ViTPose / ViTPose++ (ViTAE-Transformer)

NeurIPS 2022 / TPAMI 2023 · Apache-2.0, usage commercial autorisé

ViTPose utilise un backbone Vision Transformer classique avec très peu de modifications, tandis que ViTPose++ ajoute un entraînement sur plusieurs jeux de données. Dans cette sélection, son principal intérêt réside dans la précision plutôt que dans un déploiement CPU.

À 256 × 192, ViTPose-B atteint 75,8 de COCO AP en entraînement mono-tâche et 77,1 lorsqu’il est entraîné avec COCO, AIC et MPII combinés. ViTPose-L atteint respectivement 78,3 et 78,7, tandis que ViTPose-H atteint 79,1 et 79,5. ViTPose-H obtient également 76,3 AP sur CrowdPose test, dont 65,6 AP sur le sous-ensemble difficile. Sur MPII, le PCKh atteint 94,1 avec H, tandis que ViTPose-L affiche 90,9 AP et 92,2 AR sur OCHuman test.

La comparaison avec RTMPose explique la différence de positionnement. ViTPose-B et RTMPose-m atteignent tous deux 75,8 de COCO AP, mais RTMPose-m obtient ce résultat à plus de 90 FPS sur un i7-11700, alors que ViTPose-B est davantage destiné à un usage GPU. ViTPose devient intéressant lorsqu’il faut aller plus loin en matière de précision, avec jusqu’à 79,1 AP pour le backbone H et 76,3 AP sur CrowdPose.

Idéal pour : l’estimation de pose sur serveur GPU lorsque la précision publiée maximale compte davantage que le débit CPU, notamment dans les scènes denses contenant plusieurs personnes.

MediaPipe Pose Landmarker / BlazePose GHUM 3D (Google)

Framework et dépôt MediaPipe : Apache-2.0. Google ne publie pas de déclaration de licence explicite pour les poids du modèle Pose Landmarker sur la page actuelle du modèle. La documentation est sous CC-BY 4.0 et les exemples de code sous Apache-2.0.

MediaPipe Pose Landmarker, basé sur BlazePose GHUM 3D, est l’option de cette sélection la plus adaptée aux déploiements dans le navigateur. Il est disponible en variantes Lite, Full et Heavy en float16 et prend en charge Android, iOS, Python et le Web via JavaScript. Les modes d’entrée comprennent IMAGE, VIDEO et LIVE_STREAM, ce qui en fait une solution directement adaptée à l’estimation continue de pose dans des applications web ou mobiles.

Le modèle produit 33 points de repère corporels à partir d’une entrée RGB. La documentation BlazePose GHUM 3D de Google les décrit comme des repères 3D et mentionne également un masque de segmentation de l’arrière-plan. Le détecteur de pose utilise une entrée de 224 × 224 × 3 et le landmarker une entrée de 256 × 256 × 3. Google ne publie ni la taille des modèles ni les chiffres de latence pour les trois variantes.

La licence des poids mérite d’être distinguée de celle du code. Le dépôt Google est sous Apache-2.0 et certaines redistributions tierces, comme OpenCV Zoo et Qualcomm AI Hub, indiquent également Apache-2.0 pour le modèle de pose. Toutefois, la propre page Pose Landmarker de Google ne précise pas la licence des bundles .task.

Idéal pour : les applications vidéo web et mobiles qui nécessitent le mode LIVE_STREAM et des points corporels 3D à partir d’un seul flux RGB. Les équipes qui ont besoin d’une licence explicite pour les poids du modèle doivent vérifier les conditions du bundle .task téléchargé avant tout déploiement commercial.

DWPose (IDEA Research)

ICCV 2023 CV4Metaverse Workshop · Apache-2.0, usage commercial autorisé

DWPose se concentre sur l’estimation du corps entier, avec les points clés du corps, des pieds, du visage et des mains au sein d’un même système.

À 256 × 192, DWPose-t utilise 0,5G FLOPs et atteint 48,5 % de Whole AP. DWPose-s utilise 0,9G FLOPs pour 53,8 %, DWPose-m 2,2G FLOPs pour 60,6 %, et DWPose-l 4,5G FLOPs pour 63,1 %. Passer DWPose-l à 384 × 288 fait monter le coût de calcul à 10,1G FLOPs et le Whole AP à 66,5 %.

Les scores par composant du meilleur modèle sont de 72,2 % pour le corps, 70,4 % pour les pieds, 88,7 % pour le visage et 62,1 % pour les mains. Le score des mains est le plus faible de cette décomposition publiée. La vitesse d’inférence n’est pas indiquée dans le dépôt.

Ces chiffres de Whole AP ne doivent pas être comparés directement aux scores COCO AP de RTMPose ou ViTPose. DWPose est évalué sur COCO-WholeBody, tandis que les principaux résultats RTMPose et ViTPose présentés ci-dessus utilisent 17 points corporels sur COCO standard. Le Whole AP correspond à un benchmark différent et plus difficile.

RTMPose-l atteint également 67,0 % d’AP sur COCO-WholeBody à plus de 130 FPS, ce qui le place dans la même plage générale que les 66,5 % de DWPose-l.

Idéal pour : les travaux de recherche sur la pose du corps entier lorsque des scores distincts pour le visage, les mains, les pieds et le corps sont nécessaires plutôt qu’une seule métrique de pose corporelle.

OpenPose (CMU Perceptual Computing Lab)

Usage non commercial uniquement. OpenPose est gratuit pour les usages non commerciaux, tandis qu’un usage commercial nécessite une licence CMU distincte via FlintBox.

OpenPose est une référence historique de 2017 qui a contribué à établir les bases de l’estimation moderne de pose multi-personnes. Il prend en charge des configurations corps et pieds avec 15, 18 ou 25 points clés, dont 6 points pour les pieds, ainsi que 21 points par main et 70 pour le visage, soit 135 points clés pour l’ensemble du corps.

Les plateformes prises en charge comprennent Ubuntu, Windows, macOS et Nvidia TX2. Les modes de compilation disponibles incluent CUDA, OpenCL et CPU-only.

Sa propriété technique historique est que le temps d’inférence reste constant lorsque le nombre de personnes détectées augmente, alors que certaines approches concurrentes peuvent voir leur coût augmenter linéairement avec le nombre de personnes. MediaPipe et RTMPose offrent désormais des options de déploiement plus rapides et plus pratiques, tandis que la licence non commerciale exclut OpenPose de la plupart des produits commerciaux.

Idéal pour : une référence historique, la recherche ou les charges de travail où un temps d’inférence constant malgré les variations du nombre de personnes présente un intérêt spécifique.

Meilleure solution pour la transcription audio

Une analyse vidéo qui ignore la piste audio passe à côté d’informations que les images seules ne peuvent pas fournir. Whisper permet d’identifier ce qui a été dit et à quel moment. L’identification des différents locuteurs est un problème distinct qui nécessite une couche supplémentaire de diarisation.

Whisper (OpenAI)

Licence MIT, usage commercial autorisé

Whisper transforme la piste audio d’une vidéo en texte horodaté. Pour la vidéo, ces horodatages sont essentiels : ils permettent à l’utilisateur d’accéder directement au moment où une phrase a été prononcée, d’aligner la parole avec des détections visuelles sur une même timeline et d’intégrer la recherche dans les transcriptions à un système plus large de recherche vidéo. Transcription + détections + horodatages constitue l’un des schémas de base pour rendre une vidéo consultable.

Whisper traite de l’audio et non directement de la vidéo. La piste audio doit donc généralement être extraite au préalable avec un outil comme ffmpeg.

Whisper applique une limite d’entrée de 30 secondes pour son mode court. Un fichier audio de 30 secondes ou moins peut être transcrit en une seule passe. Au-delà, le modèle utilise un algorithme séquentiel pour les contenus longs, basé sur les prédictions d’horodatage ainsi que sur des heuristiques de ratio de compression, de log-probabilité et de repli sur différentes températures décrites dans la section 3.8 de l’article Whisper. La plupart des pistes audio de vidéos dépassent 30 secondes, les traitements vidéo utilisent donc généralement ce mode long.

Pour les fichiers audio de plus de 30 secondes, return_timestamps=True est requis. La précision des horodatages est par défaut de 0,02 seconde, soit environ 20 ms. Cela permet d’aligner une phrase prononcée avec un moment précis de la vidéo au lieu de renvoyer un unique bloc de texte sans timing.

Whisper expose également un paramètre no_speech_threshold qui permet d’ignorer les segments contenant uniquement du silence. Cette fonction est utile pour les enregistrements de surveillance, les cours ou les vidéos comportant de longues périodes sans parole, et elle aide à réduire la génération de texte erroné pendant les silences.

La famille de modèles va de tiny avec 39 millions de paramètres à large avec 1,55 milliard de paramètres. Turbo est une version optimisée de large-v3 et reste le choix pratique parmi les modèles de référence : 809 millions de paramètres, environ 6 Go de VRAM et une vitesse relative environ 8 fois supérieure à large.

Whisper a été entraîné sur 680 000 heures d’audio : 438 000 heures en anglais, 126 000 heures de contenu non anglophone associé à des transcriptions anglaises et 117 000 heures de contenu non anglophone associé à des transcriptions dans la langue d’origine. Les données d’entraînement couvrent 98 langues, mais la fiche du modèle indique de bonnes performances ASR dans environ 10 langues. La présence d’une langue dans les données d’entraînement ne signifie donc pas que la qualité de transcription est identique dans les 98 langues.

Idéal pour : extraire la parole horodatée d’une vidéo afin de rendre son contenu audio recherchable et de l’aligner avec les événements visuels.

faster-whisper

Licence MIT

faster-whisper est une implémentation adaptée aux pipelines de production lorsque la vitesse et la consommation mémoire de Whisper sont importantes. Il repose sur CTranslate2 et prend en charge word_timestamps=True ainsi que le traitement par lots avec BatchedInferencePipeline.

Le projet annonce une inférence jusqu’à 4 fois plus rapide que openai/whisper à précision équivalente, tout en utilisant moins de mémoire.

On the same GPU, the int8 configuration cuts VRAM by 38% and runtime by 2.4x compared with the OpenAI reference implementation.

The CPU difference is also substantial. With the small model on an Intel i7-12700K using 8 threads:Sur une RTX 3070 Ti 8 Go avec CUDA 12.4, en utilisant large-v2 et un beam size de 5, les chiffres publiés montrent également qu’une configuration int8 réduit la consommation de VRAM de 38 % et le temps d’exécution d’environ 2,4 fois par rapport à l’implémentation de référence d’OpenAI.

L’écart est également important sur CPU. Avec le modèle small sur un Intel i7-12700K utilisant 8 threads, faster-whisper est conçu pour réduire sensiblement le temps de traitement par rapport à l’implémentation de référence.

Idéal pour : les pipelines de transcription en production qui souhaitent conserver la compatibilité avec Whisper tout en réduisant la latence et l’utilisation de mémoire, avec prise en charge du batching et des horodatages au niveau des mots.

WhisperX

Licence BSD-2-Clause

WhisperX ajoute les éléments que Whisper seul ne fournit pas pour produire des transcriptions vidéo associées aux différents locuteurs. Il utilise l’alignement forcé avec wav2vec2 pour obtenir des horodatages au niveau des mots et pyannote-audio pour la diarisation des locuteurs.

Le projet annonce une transcription jusqu’à 70 fois plus rapide que le temps réel avec Whisper large-v2 grâce au traitement par lots.

Cette approche répond au problème du « qui a dit quoi », mais elle ajoute des contraintes de déploiement. La diarisation utilise le modèle speaker-diarization-community-1 et nécessite un token Hugging Face en lecture ainsi que l’acceptation des conditions d’utilisation de ce modèle.

Whisper indique ce qui a été dit et à quel moment. WhisperX associé à pyannote permet d’ajouter qui l’a dit.

Idéal pour : les vidéos de réunions, d’entretiens et d’appels support qui nécessitent à la fois des horodatages au niveau des mots et l’attribution des paroles aux différents intervenants.

Pour une comparaison plus détaillée, consultez l’article d’Eden AI sur les solutions gratuites et open source de speech-to-text.

Bibliothèques et frameworks réellement utiles en production

OpenCV, PyTorch et des outils similaires sont souvent présentés comme des « modèles d’analyse vidéo ». Ce ne sont pas des modèles. Ils constituent la couche technique utilisée pour construire le pipeline et peuvent être aussi importants que le choix du modèle lui-même dans un système vidéo en production.

Supervision (Roboflow) est la couche d’intégration souvent absente de ce type de liste. Le projet est sous licence MIT, activement maintenu et compte 49,4k étoiles sur GitHub. Il fournit du suivi multi-objets, des outils d’annotation personnalisables, du comptage en temps réel par zone, de l’analyse du temps de présence et des utilitaires pour traiter les vidéos frame par frame.

Il s’intègre notamment avec Ultralytics, Transformers, MMDetection, Roboflow Inference, RF-DETR et des connecteurs indépendants des modèles. Si votre pipeline combine détection, tracking, overlays, compteurs et entrées/sorties vidéo, Supervision peut servir de couche permettant d’assembler ces différents composants en une application.

OpenCV gère les opérations de plus bas niveau : décodage des vidéos, lecture et écriture des frames, ainsi que les opérations classiques de computer vision autour du modèle.

PyTorch est le framework d’entraînement et d’inférence utilisé par la majorité des modèles présentés dans cet article. Il permet de charger les poids, exécuter l’inférence, fine-tuner les modèles et connecter leur code au reste du pipeline.

MMPose et MMAction2 sont des toolkits OpenMMLab dédiés respectivement à l’estimation de pose et à la reconnaissance d’actions. RTMPose fait partie de cet écosystème, aux côtés d’autres composants orientés recherche et déploiement vidéo.

Decord et PyAV prennent en charge le décodage vidéo. Celui-ci peut devenir un goulot d’étranglement lorsque vous traitez de nombreux fichiers ou de longues vidéos. Le décodage doit donc être intégré dès la conception de l’architecture plutôt que traité comme un détail secondaire.

Comment choisir entre auto-hébergement et API ?

Commencez par votre volume

Une utilisation faible et irrégulière favorise généralement une API. Vous payez uniquement pour les vidéos traitées et n’avez pas besoin de maintenir des capacités GPU actives lorsqu’aucun traitement n’est en cours. Cette approche convient aux prototypes, aux outils internes et aux produits dont le trafic varie fortement d’un jour à l’autre.

Un volume élevé et constant modifie l’équation économique. Un coût GPU fixe peut devenir moins élevé qu’une facturation à la minute lorsque votre utilisation dépasse votre propre seuil de rentabilité.

Ne vous basez pas sur un seuil générique. Estimez le nombre de minutes de vidéo que vous prévoyez de traiter chaque mois, comparez-le aux tarifs API par minute de la section précédente, puis confrontez ce montant au coût total de votre propre infrastructure d’inférence.

Vérifiez vos besoins en latence

La vidéo en temps réel pousse généralement vers des modèles locaux plus petits. Un flux à 30 FPS laisse environ 33 ms pour traiter chaque frame, et ce budget doit également couvrir le décodage, le tracking, la logique applicative et les éventuels échanges réseau.

YOLO26n nécessite 1,7 ms par frame sur un T4, contre 38,9 ms sur le CPU testé. Le résultat GPU laisse suffisamment de marge pour le traitement en temps réel et plusieurs flux simultanés, tandis que le résultat CPU ne suffit pas à lui seul pour suivre un flux à 30 FPS.

Les traitements par lots ou réalisés pendant la nuit réduisent fortement cette contrainte. Si une vidéo peut être analysée pendant plusieurs minutes ou plusieurs heures, des modèles vision-langage plus grands deviennent plus réalistes, car le débit global compte davantage que la latence de chaque frame.

Déterminez où vos données peuvent être traitées

Les contraintes de confidentialité et d’infrastructure peuvent prendre le dessus sur le calcul des coûts. Des données réglementées, des exigences on-premise ou des vidéos contenant des personnes identifiables peuvent empêcher l’envoi des fichiers bruts vers un service tiers.

Dans ces situations, l’auto-hébergement peut devenir la seule option réaliste, même si une API serait moins coûteuse sur le papier. Si un traitement dans l’Union européenne répond à vos exigences, Eden AI propose également un endpoint européen.

Tenez compte des ressources de votre équipe

Un modèle téléchargeable n’est pas un système d’analyse vidéo prêt à l’emploi. L’auto-hébergement nécessite une personne ou une équipe capable de gérer l’inférence GPU, le décodage, le batching, le monitoring, les mises à jour des modèles, la gestion des erreurs ainsi que les pipelines complémentaires de tracking ou d’indexation.

Un modèle peut être gratuit et le projet peut malgré tout échouer si personne ne prend en charge cette infrastructure. Une API coûte davantage par unité d’utilisation, mais elle supprime une partie de cette charge opérationnelle.

Une architecture hybride est fréquente en production : un petit détecteur local fonctionne en continu, puis seules certaines frames ou certains clips sont envoyés à un modèle vision-langage ou à une API lorsqu’une analyse plus poussée est nécessaire. Cela permet de maintenir un faible coût pour le traitement continu tout en réservant les analyses plus coûteuses aux moments où elles apportent une réelle valeur.

Dans de nombreux déploiements en 2026, cette approche hybride offre le meilleur compromis entre coût et exigences produit.

FAQs - Analyse vidéo par IA gratuite