Un pipeline de vision par ordinateur sur un drone ISR a un seul travail : prendre les photons frappant un capteur, les transformer en pistes géolocalisées d'objets qui comptent, et pousser ces pistes vers un système de commandement et contrôle assez vite pour qu'un opérateur — ou un autre système — puisse agir dessus. Tout le reste est de la surcharge d'ingénierie au service de cette boucle. Cet article parcourt le pipeline de bout en bout : les architectures de modèles qui détectent, les algorithmes qui suivent, la fusion de capteurs qui survit à la nuit et à la météo, les mathématiques de géoréférencement qui rendent une boîte englobante utile, et les réalités de déploiement edge qui décident si tout cela fonctionne sur le terrain.

Pour un contexte plus large sur la place de ceci dans la pile IA de défense, voir notre guide complet de l'IA en défense et l'analyse capteur-edge dans capteur-à-tireur partie 2.

1. Le pipeline CV ISR

Le pipeline canonique comporte six étapes : capture du capteur (EO et IR), ingestion et synchronisation des trames, détection, suivi multi-objets, géoréférencement et push C2. De bout en bout, le budget sur une plateforme ISR tactique est d'environ 150 à 250 ms en temps réel depuis l'arrivée du photon jusqu'à la mise à jour de piste sur la surface C2. Au-delà de 300 ms, la confiance opérateur s'effondre — un véhicule en mouvement à 60 km/h parcourt 5 mètres en 300 ms.

La décomposition du budget sur une plateforme typique de classe Jetson Orin NX : 16–33 ms pour la capture (selon que le capteur tourne à 30 ou 60 fps), 5–10 ms pour l'ISP et le démosaïquage, 15–40 ms pour la passe avant du détecteur, 3–8 ms pour l'association de suivi, 10–20 ms pour les mathématiques de géoréférencement, et 20–80 ms pour la liaison radio vers le C2. La radio est généralement le pire contrevenant et celui que l'ingénieur CV ne peut pas réparer. Tout le reste embarqué doit se comprimer pour compenser.

La synchronisation à l'ingestion des trames compte plus que les débutants ne le pensent. Les capteurs EO et IR partagent rarement une horloge de trame. Si votre logique de fusion suppose qu'ils le font, vous fusionnez le pixel EO d'une cible à t avec le pixel IR à t-16 ms — un véhicule à 30 m/s a bougé d'un demi-mètre. Le pipeline doit horodater au capteur, pas au consommateur.

2. Architectures de détection

Le détecteur est la décision dominante de calcul et de précision dans le pipeline. Trois familles comptent actuellement sur les drones ISR.

YOLOv8, v10, v11. La lignée convolutionnelle YOLO reste le cheval de bataille — YOLOv8 d'Ultralytics et les plus récents YOLOv10 et v11 délivrent 30–60 fps à 640×640 sur Jetson Orin NX avec quantification INT8. YOLOv11n (nano) atteint ~60 fps à un mAP acceptable sur les jeux de données aériens ; YOLOv11s (small) descend à ~30 fps avec un rappel des petits objets matériellement meilleur. YOLOv10 supprime entièrement l'étape NMS, économisant 3–5 ms de latence de post-traitement, ce qui compte quand chaque milliseconde est disputée.

RT-DETR. Le DETR temps réel de Baidu est l'alternative transformeur — un détecteur basé sur requêtes qui saute le NMS par conception et produit un ensemble fixe de requêtes d'objets. Sur les benchmarks, RT-DETR-L égale ou bat le mAP de YOLOv8-L sur COCO tout en tournant à une latence comparable. Sur l'imagerie aérienne, le motif d'attention transformeur gère souvent mieux les scènes denses de petits objets (véhicules stationnés, groupes d'infanterie) que les détecteurs convolutionnels basés sur ancres. Le coût est un modèle plus gros et une quantification INT8 plus délicate — les couches d'attention transformeur se dégradent plus sous une quantification agressive que les couches conv.

Le problème des petits objets. Un drone ISR à 1500 m AGL avec un HFOV de 30° voit une personne comme environ 6–10 pixels de côté. Les détecteurs d'objets standard entraînés sur l'imagerie de style COCO (où les objets font typiquement >32 pixels) échouent gravement dans ce régime. Les deux corrections pratiques sont le tuilage (diviser la trame en patchs chevauchants de 640×640, exécuter l'inférence par patch, réconcilier dans l'espace image) et l'entraînement sur des jeux de données spécifiques à l'aérien — VisDrone, DOTA, xView, et de plus en plus des données synthétiques spécifiques au domaine. Voir notre article données synthétiques pour l'entraînement IA de défense pour le pipeline.

3. Algorithmes de suivi

La détection vous donne des boîtes englobantes par trame. Le suivi les transforme en pistes stables en identité au fil du temps — ce dont un système C2 a réellement besoin. Les choix embarqués dominants sont BYTETrack, StrongSORT et OC-SORT.

BYTETrack. Bon marché, rapide et étonnamment robuste. L'intuition de BYTETrack est que les détections à faible confiance — que la plupart des trackers rejettent — sont généralement des objets réels partiellement occlus ou temporairement ambigus. En associant d'abord les détections à haute confiance, puis en faisant correspondre les boîtes à faible confiance aux pistes non appariées dans une seconde passe, BYTETrack récupère des pistes que les méthodes d'association IoU pures perdent. Sur un Jetson Orin NX, le tracker ajoute <5 ms par trame.

StrongSORT. Une évolution de DeepSORT — filtre de Kalman pour le mouvement plus un embedding d'apparence de ré-identification. Meilleur sur les scènes sujettes au changement d'ID (véhicules se croisant, occlusion sous couvert d'arbres) mais le réseau d'embedding d'apparence ajoute 8–15 ms par trame et nécessite ses propres données d'entraînement. Vaut le coût quand la stabilité d'ID importe plus que le débit, par exemple en suivi de convoi.

OC-SORT. Observation-Centric SORT adresse un échec spécifique de BYTETrack/SORT : quand un objet est perdu pendant plusieurs trames, l'estimation de vélocité du filtre de Kalman dérive. OC-SORT ré-estime la vélocité à partir de l'observation lors de la ré-identification plutôt que de faire confiance à la prédiction du filtre. Sur des séquences ISR avec occlusion fréquente (environnements urbains, lisière forestière), OC-SORT réduit mesurablement les changements d'ID par rapport à BYTETrack.

Le problème de la plateforme instable. Tous ces trackers supposent que le mouvement caméra-trame d'un objet est dominé par le mouvement de l'objet. Sur un drone dans de l'air turbulent, le mouvement propre contribue à la majorité de la vélocité pixel apparente. La correction est de suivre dans une trame stabilisée ou monde : soit alimenter le tracker avec des trames pré-stabilisées (dé-rotation basée sur homographie contre l'IMU), soit exécuter le filtre de Kalman en coordonnées géoréférencées plutôt qu'en coordonnées image. Cette dernière est plus de travail mais produit des pistes nettement plus propres.

4. Fusion de capteurs EO + IR

Un drone ISR EO uniquement est une plateforme de jour. Un drone IR uniquement résout les sources de chaleur mais ne peut pas lire les marquages d'un véhicule, compter le personnel de manière fiable à distance, ni distinguer les leurres à température similaire. L'ISR opérationnel exige les deux, et exige qu'ils fusionnent.

La fusion tardive exécute des détecteurs indépendants sur les flux EO et IR et réconcilie les pistes en aval. Plus simple à concevoir, échoue gracieusement si un capteur se dégrade, mais perd le signal cross-modal — un contact EO faible renforcé par une signature IR claire devrait produire une piste à haute confiance, et la fusion tardive gère cela maladroitement.

La fusion précoce empile les canaux EO et IR en un seul tenseur et entraîne un détecteur sur l'entrée combinée. Meilleures performances cross-modales, mais nécessite des données alignées — ce qui exige une discipline de calibration de visée. Les optiques EO et IR partagent rarement une visée ; elles nécessitent une calibration par cellule (typiquement un damier ou une calibration de cible chaude avant le vol) et une re-calibration après tout événement de maintenance.

Transition jour-nuit. Le moment le plus sujet aux échecs est le crépuscule et l'aube, quand le contraste EO s'effondre mais que la scène IR est aussi au contraste thermique minimum (tout est à l'ambiant). Un bon pipeline de fusion module la confiance par capteur via des métriques au niveau de la scène — contraste sur toute l'image, statistiques d'histogramme — et repondère la détection fusionnée en conséquence, plutôt que de faire confiance à un poids de fusion précoce fixe 24 heures sur 24.

5. Géoréférencement à la cadence d'image

Une boîte englobante en coordonnées pixel est inutile pour un système C2. La boîte englobante doit être projetée vers une coordonnée géographique (latitude, longitude, élévation), avec une ellipse d'erreur. Les mathématiques impliquent : la position du drone (GPS, souvent fusionné INS), l'attitude du drone (IMU), la pose du gimbal par rapport à la cellule (encodeurs de gimbal), les intrinsèques de la caméra (focale, point principal), et un modèle de terrain (idéalement un DEM DTED niveau 2 ou meilleur) pour déprojeter le rayon pixel à l'intersection sol.

Deux réalités pratiques. Premièrement, la latence de géoréférencement rivalise avec la latence de détection. Une implémentation naïve qui lit les encodeurs de gimbal et l'IMU au moment du push C2 introduit une erreur de 50–100 ms par rapport à l'horodatage réel de la trame — à 30 m/s de vitesse sol cela représente 1,5–3 mètres d'erreur de position. Les échantillons d'encodeur et d'IMU doivent être horodatés et interpolés au milieu d'exposition de la trame.

Deuxièmement, le budget d'erreur. À 1500 m de portée oblique avec 0,5° d'incertitude de pose de gimbal, l'erreur projetée au sol est d'environ 13 mètres avant d'ajouter l'incertitude GPS, l'erreur du modèle de terrain et le décalage temporel. Le CEP réaliste pour un système de classe tactique bien conçu est de 15–25 mètres aux altitudes ISR typiques. Tout ce qui est rapporté plus serré que cela est soit de l'ingénierie héroïque soit du vœu pieux.

6. Sélection de modèle pour le déploiement edge

La plateforme de calcul contraint tout. Les options actuelles de classe drone ISR :

Jetson Orin Nano (8 Go) — ~40 TOPS INT8, adapté à YOLOv8n/v11n à 640×640 plus un tracker léger. Enveloppe de puissance 7–15 W. Bon pour les plateformes Groupe 1/2 où la cellule ne peut pas dissiper plus.

Jetson Orin NX (16 Go) — ~100 TOPS INT8. Exécute YOLOv11s confortablement à 60 fps, RT-DETR-R18 à ~30 fps, StrongSORT avec embedding d'apparence. 10–25 W. Le sweet spot actuel pour l'ISR tactique.

Jetson AGX Orin (32/64 Go) — ~275 TOPS INT8. Exécute des modèles plus grands, multi-flux (EO+IR simultanément sans partager le GPU), et laisse de la marge pour des tâches CV supplémentaires (détection de changement, têtes de classification). 15–60 W — généralement une décision de plateforme Groupe 3.

Réalités de la quantification INT8. Float32 → INT8 délivre typiquement 3–4× d'accélération d'inférence et 4× de réduction mémoire avec 0,5–1,5 mAP de perte sur les détecteurs bien quantifiés. Les pièges : l'attention transformeur quantifie moins bien que les convolutions ; les données de calibration doivent être représentatives de l'imagerie de déploiement (calibrer sur COCO et déployer sur IR thermique est une faute professionnelle) ; et certaines couches personnalisées retombent en FP16, perdant silencieusement l'accélération. Notre guide d'optimisation ONNX/TensorRT couvre la chaîne d'outils.

TensorRT vs ONNX Runtime. Sur Jetson, TensorRT est la bonne réponse pour la production — builds d'engine ajustés au nombre exact de SM du GPU, pipelines de calibration INT8 matures, fusion de kernels agressive. ONNX Runtime avec le fournisseur d'exécution TensorRT est acceptable pour le développement et donne 80–90% de la performance native TensorRT avec un déploiement plus simple. CUDA EP pur perd 30–50%.

7. Sortie temps réel vers C2

Le produit du pipeline est un flux de pistes géolocalisées, stables en identité, plus la vidéo plein mouvement qui les a produites. Les formats interopérables sont bien définis.

CoT (Cursor-on-Target). Format d'événement basé XML, originaire de MITRE, la lingua franca du C2 de l'écosystème TAK (ATAK, WinTAK, iTAK). Un événement CoT encode un point (lat/lon/élévation avec ellipse d'erreur), un code de type (par ex. a-h-G-U-C-I pour une unité au sol hostile), et un détail libre. Un drone publiant du CoT toutes les 0,5–1 s par objet suivi s'intègre nativement avec les affichages d'opérateur.

MISB 0903 VMTI. Video Moving Target Indicator — la norme OTAN/MISB pour intégrer des métadonnées de détection et de suivi en KLV à côté de la vidéo plein mouvement. Un paquet VMTI à l'intérieur du flux MPEG-TS encodé MISB 0601 transporte des listes de cibles par trame avec position, vélocité et confiance géoréférencées. Requis pour toute plateforme qui doit se brancher aux consommateurs FMV ISR Classe 1 OTAN.

Modèles de bus de messages. À l'intérieur de la cellule, ROS 2, Zenoh ou MQTT transportent les messages intermédiaires entre le détecteur, le tracker, le géoréférenceur et le processus de liaison descendante radio. Le modèle pub-sub-query de Zenoh gère bien les liens intermittents — la radio tombe, le store-and-forward embarqué retient les pistes, et le client C2 rattrape à la reconnexion.

8. Réalités du terrain

Tout ce qui précède est la partie facile. La partie difficile est de le faire fonctionner sur le terrain.

Vibration. Un quadricoptère de 2 kg à plein régime vibre le support de caméra à 100–200 Hz. Les capteurs à obturateur déroulant produisent du flou ; les capteurs à obturateur global non, mais coûtent plus cher et dissipent plus. La précision du détecteur sur l'imagerie floue de mouvement chute de 5–15 points mAP à moins que l'ensemble d'entraînement n'inclue des échantillons flous de mouvement.

Thermique. Un Jetson Orin NX tournant à 100 TOPS dissipe 20+ W dans une charge utile scellée qui peut elle-même être en plein soleil à +45°C. Sans refroidissement actif, le throttling thermique se déclenche en 90 secondes — et un GPU throttlé chute le fps du détecteur de 40–60%. Concevoir l'enveloppe thermique de la charge utile est autant une préoccupation d'ingénierie CV que le choix de modèle.

Modes basse consommation. Une mission ISR en loitering peut vouloir le détecteur tournant à 5 fps en transit et 60 fps au-dessus de la zone d'intérêt, divisant la puissance moyenne par 4–5×. Le pipeline doit supporter le gating de puissance par étape — pas seulement les horloges GPU, mais le taux de trame du capteur, le chemin ISP et le rapport cyclique radio. Voir le triage de données ISR par IA pour le côté filtrage embarqué de ceci.

Dégradation du modèle au cours du déploiement. Un détecteur entraîné sur l'imagerie d'été européen et déployé dans un hiver baltique à -20°C voit un monde différent : la réflectance du terrain enneigé change les statistiques EO ; les moteurs froids émettent moins d'IR ; le feuillage qui cachait les véhicules en juillet est dénudé en février. L'atténuation réaliste est une évaluation continue contre les nouvelles données collectées et une cadence de ré-entraînement mesurée en semaines, pas le modèle d'entraînement-et-déploiement unique que le travail en labo suppose.

Un pipeline CV de drone ISR n'est pas un modèle — c'est un système. Le modèle en est la plus petite partie. Le budget de latence, la discipline de calibration, le format de message C2, la conception thermique et la cadence de ré-entraînement sont ce qui décide si le système fonctionne pour l'opérateur à l'autre bout du lien radio.