Superviser plusieurs sites industriels en temps réel à partir de l'analyse vidéo repose sur quatre décisions d'architecture : où le traitement des images est exécuté, ce qui remonte réellement vers le niveau central, à qui chaque alerte est adressée, et comment une même configuration est appliquée à un groupe de sites sans être reprise site par site.
Ces décisions comptent plus que la performance du modèle de détection. Un algorithme qui fonctionne sur un site se heurte, dès le troisième ou le quatrième, à des problèmes d'un autre ordre : liaisons réseau inégales, parcs de caméras hétérogènes, équipes locales aux habitudes différentes, et absence d'un endroit unique où comparer les sites entre eux.
Dans la plupart des configurations industrielles, le traitement est exécuté sur un équipement installé dans le site, au plus près des caméras. Trois raisons à cela.
Le volume. Transporter en continu les flux de plusieurs dizaines de caméras vers un point central consomme une bande passante dont peu de sites de production ou de plateformes logistiques disposent réellement.
La latence. Une alerte de présence en zone interdite ou de piéton sur une allée d'engins n'a de valeur que si elle parvient à l'opérateur en quelques secondes.
La maîtrise des données. Un traitement local permet de ne faire sortir du site que des mesures et, le cas échéant, une vignette associée à une alerte, ce qui simplifie sensiblement le dossier de conformité.
Le niveau central reçoit alors des événements et des séries de mesures, pas des images en continu. C'est ce choix qui rend la supervision multisite praticable sur une liaison ordinaire.
Trois flux suffisent, et il vaut mieux les distinguer clairement.
Les alertes, qui exigent une action immédiate d'une personne identifiée. Leur nombre doit rester faible par site et par jour, faute de quoi elles cessent d'être traitées.
Les mesures d'exploitation, agrégées par zone et par créneau : occupation, durées, flux, files d'attente. Elles n'exigent aucune réaction immédiate et alimentent la comparaison entre sites.
L'état technique du dispositif : caméras hors service, flux interrompus, traitements arrêtés, horloges désynchronisées. Ce troisième flux est le plus souvent oublié, et c'est celui qui détermine la confiance accordée aux deux premiers. Un indicateur qui baisse parce qu'une caméra est tombée ressemble beaucoup à un indicateur qui baisse pour une raison réelle.
Une alerte sans destinataire désigné n'est pas une alerte, c'est une notification. Avant la mise en service, chaque type d'événement doit être associé à un rôle, à un canal et à un délai attendu.
Le rôle : responsable de quai, chef d'équipe, poste de garde, astreinte. Le canal : écran de supervision, message sur un terminal mobile, remontée dans l'outil de gestion des interventions déjà utilisé sur le site. Le délai : une alerte de sûreté nocturne et une alerte d'encombrement de zone n'appellent pas la même réactivité.
Deux réglages évitent la plupart des dérives. Le premier est le seuil de déclenchement, à calibrer sur les images réelles du site plutôt que sur une valeur par défaut. Le second est la temporisation, qui empêche un même événement de produire une série de notifications pendant qu'il est déjà pris en charge.
Mesurez enfin le taux de qualification des alertes, c'est à dire la part d'alertes effectivement traitées par les équipes. Une baisse de ce taux signale un réglage à revoir bien avant que les utilisateurs ne s'en plaignent.
C'est le point qui décide du coût réel d'un déploiement sur un parc. Trois mécanismes à exiger lors de l'évaluation.
Des modèles de configuration réutilisables : un même ensemble de règles, de zones types et de seuils applicable à une famille de sites comparables, avec la possibilité d'ajuster localement sans perdre le lien au modèle.
Un déploiement des mises à jour à distance, par groupe de sites, avec possibilité de revenir à la version précédente.
Une procédure d'ajout de site documentée, avec le temps nécessaire, les compétences requises localement et la liste des prérequis réseau. Demandez cette procédure par écrit : sa précision renseigne mieux sur la maturité d'une solution que n'importe quelle démonstration.
L'intérêt principal d'une supervision commune est la comparaison. Elle n'a de valeur qu'à condition d'être légitime.
Deux sites ne se comparent utilement que si les zones mesurées ont la même définition et si les indicateurs reposent sur les mêmes règles de calcul. Un taux d'occupation de quai calculé sur la surface totale dans un site et sur les emplacements actifs dans un autre produit un écart qui ne dit rien de l'exploitation.
La pratique utile consiste à figer un dictionnaire d'indicateurs avant le déploiement : nom, définition, zone de référence, méthode de calcul, période d'agrégation. Ce document évite les discussions sans fin sur la fiabilité des chiffres une fois les tableaux de bord en service.
L'analyse vidéo ne remplace ni la supervision industrielle, ni l'outil de gestion d'entrepôt, ni la gestion de maintenance. Elle leur apporte une mesure qui leur manque, celle de ce qui se passe physiquement dans les zones où aucun capteur n'est installé.
Les intégrations les plus utiles sont souvent les plus simples : envoi des événements vers l'outil déjà utilisé par les équipes, export des séries de mesures vers l'entrepôt de données du groupe, mise à disposition d'une interface de programmation documentée. Vérifiez ce dernier point tôt dans l'évaluation, car une solution fermée oblige à maintenir un tableau de bord de plus.
XXII est un éditeur français de logiciels de vision par ordinateur. Sa plateforme CORE analyse les flux des caméras déjà installées, sans reconnaissance faciale, et permet de superviser plusieurs sites depuis une même interface, avec des configurations réutilisables d'un site à l'autre et la remontée des mesures vers les outils de pilotage existants.
Une séquence tient en trois temps. Un site pilote, choisi parce qu'il est représentatif et non parce qu'il est facile, avec deux ou trois indicateurs et un dictionnaire figé. Puis un groupe de trois à cinq sites, qui révèle les vrais problèmes de déploiement : réseau, hétérogénéité des caméras, disponibilité des équipes locales. Puis seulement l'extension au parc.
Le point de bascule n'est pas technique. Il est atteint quand les équipes locales consultent les indicateurs sans qu'on le leur demande, et quand une alerte non traitée devient une anomalie plutôt qu'une habitude.