← Retour aux insights← Back to insights

Détection d'objets en environnement dégradé : pluie, poussière, contre-jour. Object detection in degraded environments: rain, dust, backlight.

Les benchmarks publics ignorent les conditions réelles. Notre protocole de test, et pourquoi nous l'avons construit. Public benchmarks ignore real-world conditions. Our test protocol, and why we built it.

COCO et Open Images sont des photos propres. Éclairage contrôlé, objectif sec, sujets bien exposés. Un modèle qui obtient 92 % de mAP sur ces bases peut s'effondrer à 40 % dès qu'il voit la réalité d'un capteur monté sur un engin de chantier à 7 h du matin sous la pluie. Ce n'est pas une hypothèse. C'est une mesure que nous avons reproduite six fois.

Il existe peu de littérature sur ce problème parce qu'il n'intéresse pas la recherche académique : ce ne sont pas des benchmarks publiés, et les jeux de données correspondants sont rarement partagés. C'est pourtant là que se joue la viabilité d'un système de vision industriel.

Trois modes de dégradation qui dominent

Sur neuf déploiements récents, trois conditions expliquent 80 % des échecs de détection :

Pourquoi les benchmarks publics ne prédisent rien

COCO a été curatée pour la qualité visuelle. Les images difficiles ont été écartées parce qu'elles rendaient l'annotation difficile. Cela produit un biais fondamental : les modèles sont évalués sur les images faciles, puis déployés sur des images difficiles. L'écart de performance n'est pas un bruit — c'est une conséquence structurelle de la manière dont la donnée d'évaluation a été construite.

Un modèle à 92 % sur COCO et 48 % en conditions réelles n'est pas un mauvais modèle. Il est évalué sur une distribution qui n'est pas la sienne.

PROTOCOLE Pour chaque projet, nous construisons désormais une base d'évaluation « terrain » de 500 à 2 000 images capturées dans les pires conditions d'usage attendu. C'est ce chiffre que nous communiquons au client. Pas le mAP sur COCO.

Notre rig de collecte

Nous avons construit un ensemble portable pour générer des conditions dégradées contrôlées : aspersion d'eau avec pression et goutte calibrées, générateur de brouillard à densité réglable, panneaux de contre-jour LED 10 000 lm, poussière de talc pour la simulation particulaire.

Chaque scène est capturée en conditions propres puis en cinq niveaux progressifs de dégradation. On obtient une courbe de performance en fonction de la sévérité, pas un point unique. Cette courbe est plus parlante qu'un chiffre agrégé : elle montre le modèle commence à échouer, pas seulement qu'il échoue.

Ce qui améliore vraiment la robustesse

Nous avons testé plusieurs approches. Classées par gain mesuré :

  1. Augmentation agressive à l'entraînement. Simulation synthétique des dégradations (pluie procédurale, dégradation gamma, noise patterns). Gain : +15 à 25 points de mAP en conditions dégradées, pour une perte < 1 point en conditions propres.
  2. Pré-traitement optique. Filtres physiques (polarisant circulaire pour le contre-jour, revêtement hydrophobe sur le dôme optique). Gain : +10 à 15 points, sans modification du modèle.
  3. Fine-tuning sur données terrain. Même avec 1 000 images annotées, le gain est substantiel : +8 à 12 points. En deçà de 500 images, le gain est marginal.
  4. Fusion multi-spectre. Ajout d'un canal thermique ou proche infrarouge en parallèle du RGB. Gain : +20 à 30 points, mais coût matériel et complexité de pipeline importants.

Le piège de l'optimisation globale

On peut améliorer la moyenne sans améliorer le pire cas. Sur un projet, notre mAP moyen est passé de 71 à 78 après augmentation de données — mais le p5 (cinquième percentile par sévérité) est resté à 32 %. Le modèle était meilleur en moyenne et toujours aussi mauvais dans les pires conditions.

Depuis, nous optimisons le p5, pas la moyenne. C'est un choix de fonction objectif qui change tout : le modèle cesse de gagner sur les cas faciles pour se concentrer sur les cas durs. Accuracy globale légèrement inférieure, comportement réel largement supérieur.

Ce qu'on dit au client

Nous annonçons deux chiffres : performance en conditions nominales, et performance en p5 — celle qu'il observera 5 % du temps. Si le cas d'usage ne tolère pas le p5 mesuré, ce n'est pas la performance qu'il faut améliorer. C'est le cas d'usage qu'il faut contraindre : ajouter un fallback manuel, limiter les plages horaires, installer un abri sur l'optique.

Un système de vision n'est pas un modèle. C'est un système qui contient un modèle. Et les systèmes robustes ne sont pas robustes parce que le modèle l'est — ils le sont parce que l'architecture tient compte de ce que le modèle ne sait pas faire.

COCO and Open Images are clean photos. Controlled lighting, dry lens, well-exposed subjects. A model that hits 92% mAP on these can collapse to 40% the moment it sees the reality of a sensor mounted on a construction vehicle at 7 AM in the rain. This isn't a hypothesis. It's a measurement we've reproduced six times.

There's little academic literature on this problem because it doesn't interest research: no published benchmarks, rarely shared datasets. Yet this is where an industrial vision system's viability is decided.

Three degradation modes that dominate

Across nine recent deployments, three conditions explain 80% of detection failures:

Why public benchmarks predict nothing

COCO was curated for visual quality. Hard images were filtered out because they made annotation difficult. That produces a fundamental bias: models are evaluated on easy images, then deployed on hard ones. The performance gap isn't noise — it's a structural consequence of how evaluation data was built.

A model at 92% on COCO and 48% in the field isn't a bad model. It's being evaluated on a distribution that isn't its own.

PROTOCOL For every project, we now build a "field" evaluation set of 500 to 2,000 images captured under the worst conditions expected in use. That's the number we report to the client. Not COCO mAP.

Our collection rig

We built a portable kit to generate controlled degraded conditions: water spray with calibrated pressure and droplet size, variable-density fog generator, 10,000-lm LED backlight panels, talc dust for particulate simulation.

Every scene is captured clean then at five progressive levels of degradation. We get a performance curve against severity, not a single point. That curve is more telling than an aggregate number: it shows where the model starts to fail, not only that it fails.

What actually improves robustness

We've tested several approaches. Ranked by measured gain:

  1. Aggressive training augmentation. Synthetic degradation simulation (procedural rain, gamma degradation, noise patterns). Gain: +15 to 25 mAP points in degraded conditions, with < 1 point loss on clean images.
  2. Optical preprocessing. Physical filters (circular polarizer for backlight, hydrophobic coating on the dome). Gain: +10 to 15 points, no model change.
  3. Fine-tuning on field data. Even with 1,000 annotated images, gain is substantial: +8 to 12 points. Below 500 images, gain is marginal.
  4. Multi-spectral fusion. Adding a thermal or near-IR channel alongside RGB. Gain: +20 to 30 points, but significant hardware cost and pipeline complexity.

The global-optimization trap

You can improve the average without improving the worst case. On one project, mean mAP went from 71 to 78 after data augmentation — but p5 (fifth percentile by severity) stayed at 32%. The model was better on average and just as bad in the worst conditions.

Since then, we optimize p5, not the mean. That objective-function choice changes everything: the model stops winning on easy cases and focuses on hard ones. Slightly lower global accuracy, dramatically better real-world behavior.

What we tell the client

We report two numbers: nominal-condition performance, and p5 performance — what they'll see 5% of the time. If the use case can't tolerate the measured p5, it's not the performance that needs improving. It's the use case that needs constraining: add a manual fallback, restrict operating hours, install a shield over the optics.

A vision system isn't a model. It's a system that contains a model. And robust systems aren't robust because the model is — they are because the architecture accounts for what the model can't do.