POC d’analyse vidéo : mesurer la précision, le rappel et la charge des alertes

Choisissez un événement observable : entrée dans une zone définie, présence prolongée ou franchissement dans un sens interdit, par exemple. Fixez les horaires, les catégories concernées et les exceptions. Une personne autorisée dans une zone ouverte ne doit pas devenir un « incident » parce qu’un modèle sait la détecter.

Définissez ensuite l’unité évaluée. Ici, un événement réel ne compte qu’une fois, même s’il apparaît sur plusieurs images. Précisez comment rapprocher une alerte de cet événement : même caméra ou zone, même catégorie et fenêtre temporelle convenue. Après regroupement, associez au maximum une alerte à un événement, et un événement à une alerte. Décidez comment traiter les doublons, les alertes tardives et les événements partiellement masqués.

La fiche de réception doit aussi indiquer qui vérifie les résultats et qui accepte le risque résiduel. Le cadre volontaire AI RMF du NIST recommande de documenter les jeux d’essai, les métriques, les conditions d’évaluation et les limites du système. Il ne fixe pas un seuil universel de réussite pour votre projet.

Pour mesurer les événements manqués, il faut connaître les événements présents dans les séquences évaluées. Examiner uniquement les clips proposés par le logiciel permet de contrôler ses alertes, mais pas de savoir ce qu’il n’a jamais signalé.

Organisez donc une annotation de référence sur des plages définies à l’avance, comprenant aussi des périodes sans incident. Relevez l’heure, la caméra, la catégorie, le début et la fin de chaque événement. Faites arbitrer les cas ambigus et gardez leur trace. Un désaccord humain ne doit pas disparaître silencieusement du dénominateur.

Incluez les conditions importantes du site : lumière, densité, météo si pertinente, obstacles et changements d’activité. Des scénarios joués peuvent compléter les événements rares, dans un cadre autorisé et maîtrisé. Présentez leurs résultats séparément de ceux des situations naturelles : leur fréquence et leur mise en scène peuvent modifier la difficulté.

Réservez une première partie des données à la configuration : zones, seuils, temporisations et règles de regroupement. Utilisez ensuite des séquences distinctes pour la réception. Évitez de placer des images presque identiques d’une même scène de part et d’autre de cette séparation.

La documentation scikit-learn sur les fuites de données explique pourquoi utiliser les données de test pour choisir le modèle produit des estimations trop optimistes. Appliqué au pilote, ce principe invite à figer les réglages avant l’évaluation finale. Si vous modifiez la configuration après avoir vu ses erreurs, prévoyez une nouvelle évaluation indépendante.

Consignez les versions du logiciel et des modèles, les paramètres vidéo et les ressources matérielles. Un résultat sans configuration identifiable ne permet pas de vérifier ce qui sera déployé.

Dans notre exemple fictif, la référence contient 100 événements. Le système en retrouve 80 et en manque 20. Il émet aussi 20 alertes sans événement correspondant. Après regroupement des doublons selon la règle convenue, il reste donc 100 alertes uniques : 80 justifiées et 20 injustifiées.

La précision répond à « quelle part des alertes évaluées est juste ? » ; le rappel à « quelle part des événements recherchés a été retrouvée ? ». Ces deux dénominateurs sont différents, même lorsque les résultats numériques coïncident. Source des définitions : documentation scikit-learn.

Ne résumez pas cet exemple par « 80 % de fiabilité ». Si aucune alerte n’est produite, la précision n’est pas calculable ; si aucun événement réel n’est présent, le rappel ne l’est pas non plus. Affichez « non calculable » plutôt qu’un score rassurant.

Supposons maintenant que ces 100 alertes uniques aient généré 110 notifications, car dix notifications répètent des événements déjà signalés. Le regroupement des répétitions facilite le rapprochement entre événements et alertes ; il ne supprime pas les interruptions vécues par l’équipe. Le rapport doit donc conserver les deux volumes.

Dans ce même exemple fictif, dix caméras ont été analysées huit heures par jour pendant quatorze jours, sans interruption : 10 × 8 × 14 = 1 120 heures-caméras. Les 20 fausses alertes uniques représentent 20 / 1 120 × 100, soit environ 1,79 fausse alerte pour 100 heures-caméras. Ce n’est pas un taux de faux positifs au sens d’une matrice de classification : le dénominateur est une durée d’observation.

Si chaque notification exige en moyenne 45 secondes de vérification, les 110 notifications occupent 4 950 secondes, soit 82,5 minutes sur la période. Ce calcul pédagogique exclut les interventions et la rédaction de comptes rendus. Mesurez ces durées sur le terrain, et observez les pointes : plusieurs alertes simultanées peuvent saturer une équipe malgré une moyenne faible.

Une alerte correcte peut arriver trop tard. Définissez le début du délai mesuré : instant du franchissement, ou instant où une condition de durée devient vraie, par exemple. Mesurez ensuite l’arrivée dans l’outil opérateur, l’acquittement et, si pertinent, l’action engagée. Présentez la médiane et un percentile élevé, en indiquant leur population de calcul. Pour chaque étape, donnez aussi le nombre d’alertes qui l’ont atteinte et celles encore en attente ; une alerte non acquittée ne doit pas disparaître du bilan.

Ces délais ne concernent que les événements détectés : ils ne compensent pas les événements manqués. Les alertes tardives doivent suivre la convention écrite au départ, sans devenir des succès après lecture des résultats.

Rapportez aussi les périodes indisponibles. Pour qualifier l’algorithme, vous pouvez isoler les plages réellement analysées ; pour évaluer le service, rendez visibles les événements survenus pendant une interruption. Sinon, retirer les mauvaises périodes pourrait embellir artificiellement le bilan.

Ventilez enfin les résultats par caméra et condition. Un total de 80 événements retrouvés sur 100 n’indique pas si les vingt manqués se concentrent sur une entrée, la nuit ou une classe d’objets. Associez les pourcentages aux effectifs : neuf succès sur dix et neuf cents sur mille n’apportent pas la même quantité d’information.

L’exactitude globale peut devenir trompeuse lorsque les événements recherchés sont rares : un système qui ne signale presque rien peut sembler performant sur une majorité de situations ordinaires. Le cours de Google sur les métriques de classification explique cette limite. En vidéo continue, définir artificiellement chaque image sans incident comme un succès ne résout pas votre problème métier.

Le seuil d’alerte doit aussi correspondre au coût des erreurs. Le relever peut réduire les alertes injustifiées tout en augmentant les événements manqués. La documentation sur le réglage du seuil de décision distingue le score produit par le modèle de la décision opérationnelle. Comparez les réglages sur les données prévues à cet effet, puis figez celui retenu pour la réception.

Avant le pilote, convenez des niveaux attendus de rappel, de précision, de délai et de charge, ainsi que des conditions impératives de continuité et d’intégration. Ces objectifs doivent découler du risque et des moyens du site. Ils ne se copient pas d’un projet différent.

La conclusion peut être une validation limitée à certaines conditions, une correction suivie d’un nouvel essai, une prolongation faute d’événements suffisants, ou un abandon du scénario. Précisez qui surveillera les dérives après mise en service et quels changements imposeront une nouvelle vérification.

Le statut de « test » n’exonère pas d’examiner le traitement des données et les obligations applicables. Le besoin d’une analyse d’impact doit notamment être évalué en fonction des risques. Un protocole technique ne constitue pas une autorisation juridique.

Pour préparer un pilote de détection et d’alertes de sûreté, réunissez un scénario, des plages d’observation autorisées et une équipe capable de qualifier les résultats. Vous pourrez alors échanger avec Videtics sur un périmètre d’évaluation, avec des critères de décision compréhensibles par tous.