Drift en vision : détecter la dérive avant l’incident métier
En production, la vision dérive souvent avant de “tomber” : l’enjeu est de la détecter tôt et d’appliquer la bonne réponse sans usine à gaz.
En production, une solution de computer vision ne “tombe” pas toujours en panne. Le plus souvent, elle glisse : un peu plus de faux positifs, un peu moins de rappels, des comptages qui se décalent… jusqu’au moment où le métier le ressent (rebuts, pénalités, retards, incidents sécurité).
Chez Skalio, nous traitons le drift comme un sujet capteurs + contexte + exploitation, pas comme “un simple retrain”. L’objectif est double : voir la dérive arriver, puis savoir quoi faire sans déclencher une usine à gaz.
Le drift, c’est quoi (vraiment) ?
Le drift, c’est quand la réalité observée en production n’est plus la même que celle utilisée pour valider le système. En pratique, on retrouve trois sources principales :
- Dérive capteur : caméra sale, focus qui bouge, vibration, angle qui dérive, compression, baisse de FPS.
- Dérive des conditions : éclairage, reflets, météo/saison, nouveaux fonds, changements de cadence.
- Dérive métier : nouveaux produits/packaging, nouvelles références, nouveaux défauts, nouvelles règles qualité.
Ce point est important : la dérive est souvent progressive, donc invisible sans instrumentation.
Les causes terrain les plus fréquentes
Sur des déploiements multi-sites, les mêmes causes reviennent :
- éclairage (intensité, ombres, température de couleur, reflets)
- angle/cadrage (caméra déplacée, vibration, zoom)
- instabilité vidéo (RTSP, jitter, dropped frames)
- occlusions (opérateurs, cartons, poussière)
- changements produit (packaging, texture, variantes)
- changements process (vitesse, geste opérateur, ordre des opérations)
Les signaux à monitorer (sans complexité excessive)
Le monitoring IT (CPU/RAM/disque) ne suffit pas. Pour détecter une dérive tôt, nous ajoutons quelques signaux “perception”, simples mais efficaces.
Pipeline (stabilité)
FPS réel, frames perdues, latence vidéo → décision, erreurs RTSP/reconnexions.
Qualité image (capteur)
Sous/surexposition, flou, occlusions, changements brusques de luminosité/contraste.
Comportement modèle (symptômes)
Distribution des scores (moyenne/variance), taux d’alertes, taux de non-détection, variations par classes ou tailles d’objets.
Le but n’est pas de tout mesurer. Le but est d’identifier un “glissement” avant que le métier ne le subisse.
Que fait-on quand ça dérive ?
Un bon système ne se contente pas d’alerter. Il guide la décision.
- Warning : signal faible (scores qui glissent, qualité image qui se dégrade). Action : ticket + revue rapide d’un échantillon + contrôle captation (nettoyage/angle/éclairage).
- Incident : signal fort (FPS qui chute, flux instable, explosion des faux positifs). Action : mode dégradé (validation humaine, règles plus strictes, réduction de périmètre) + action terrain/IT.
- Correction durable : une fois stabilisé. Action : collecte ciblée des nouveaux cas + mise à jour dataset/version + nouveau modèle + redéploiement progressif.
La clé, c’est la boucle : détection → action → apprentissage.
Warning (surveillance + revue)
Le système détecte un signal faible : variation de luminosité, glissement des scores, hausse légère des faux positifs.
Actions typiques :
- création d’un ticket “drift” avec diagnostic automatique (caméra, période, métriques)
- revue humaine sur un échantillon court (10–20 événements)
- vérification de la captation (propreté, angle, éclairage)
Incident (mode dégradé)
Le signal devient fort : chute du FPS, flux instable, explosion du taux d’alertes, anomalies visibles.
Actions typiques :
- bascule en mode dégradé (règles plus strictes, ou validation humaine)
- désactivation d’une fonctionnalité non critique
- intervention terrain / IT (réseau, caméra)
Correction durable (boucle d’amélioration)
Une fois l’incident maîtrisé, on corrige pour éviter la répétition :
- collecte ciblée des cas nouveaux (pas “tout”)
- mise à jour dataset / taxonomie si besoin
- nouvelle version modèle + validation + déploiement progressif
- ajout/ajustement de seuils de monitoring
La clé, c’est la boucle : détection → action → apprentissage.
Mini-checklist
Avant déploiement
- définir 8–10 “situations difficiles” à couvrir (reflets, occlusions, variations jour/nuit, vitesse…)
- définir le mode dégradé et les responsabilités (qui fait quoi en cas d’alerte)
En exploitation
- monitorer 3 blocs : pipeline / qualité image / signaux modèle
- distinguer clairement warning vs critical (et associer une action à chaque)
Amélioration continue
- collecter de façon ciblée (cas nouveaux), versionner, revalider sur un site référence + un site différent
Conclusion
Le drift est normal : le monde change, les conditions changent, les produits changent. Ce qui fait la différence, c’est de ne pas le découvrir via un incident métier.
Chez Skalio, nous construisons des solutions Vision qui acceptent cette réalité : elles mesurent, alertent, basculent, puis s’améliorent sans crise permanente.