# Distinguer une absence d’une panne dans la surveillance de présence à domicile

L’absence d’un signal de présence à domicile peut avoir plusieurs significations : la personne a peut-être quitté les lieux, la détection locale a pu échouer ou l’équipement de surveillance a cessé de transmettre des données.

Pour les prestataires qui prennent en charge le contrôle des couvre-feux à domicile, ces possibilités ont des conséquences opérationnelles très différentes. Considérer chaque signal manquant comme un départ confirmé peut entraîner des escalades inutiles. À l’inverse, interpréter le silence de l’équipement comme la preuve que la personne est toujours chez elle peut créer un problème bien plus grave : une interruption de la surveillance qui passe inaperçue.

Un service de surveillance efficace ne doit donc pas se contenter de générer une alerte. Il doit aider les opérateurs à répondre à trois questions :

• Que savons-nous réellement de la présence de la personne ?
• Qu’est-ce qui pourrait expliquer l’absence d’observation ?
• Qui doit enquêter et de quelles données cette personne a-t-elle besoin ?

Cet article examine comment les TSP et les concepteurs de solutions peuvent combiner les observations de présence locale, la télémétrie du dispositif portable et l’état des équipements afin de faciliter l’interprétation des exceptions de surveillance. En prenant comme référence matérielle la station à domicile S921 de Megastek et le bracelet électronique de cheville MT200X, il présente les données nécessaires à un tel service et la manière dont les capacités de traitement, d’intégration et d’analyse de Navixy peuvent le prendre en charge.

L’objectif n’est pas de laisser le système décider si un couvre-feu a été enfreint. Il consiste à réduire le temps et l’incertitude liés à l’examen d’une exception, tout en rendant visibles les limites des données disponibles.

Que se passe-t-il lorsque la présence à domicile est requise, mais que la détection s’arrête ?

Imaginons qu’un couvre-feu commence à 21 heures. Le service de surveillance dispose d’une observation antérieure de présence à domicile, mais aucune détection récente ne confirme que le dispositif portable attribué se trouve toujours à proximité de la station.

Un opérateur doit maintenant examiner la situation.

La personne a peut-être quitté les lieux. La station a pu perdre sa connexion. Le dispositif portable a peut-être cessé de transmettre. Les conditions radio locales peuvent également perturber la détection. Une ancienne position affichée sur la carte aide peu à distinguer ces possibilités si son ancienneté et sa source ne sont pas clairement indiquées.

Le temps consacré à cette enquête constitue lui-même un enjeu opérationnel. Une étude du GAO américain sur la surveillance de la localisation a relevé des lacunes dans les informations structurées concernant les causes des alertes et le temps passé par les agents à les examiner et à y répondre. Pour un TSP, cela fait ressortir une exigence concrète : réunir les observations pertinentes afin que l’opérateur n’ait pas à reconstituer manuellement la situation.

Autrement dit, il ne s’agit pas simplement de détecter l’absence d’un signal de présence. Il faut transformer ce signal en une vue opérationnelle plus utile :

La présence n’est plus confirmée. Voici ce que transmet la station, ce que transmet le dispositif portable, l’ancienneté de chaque observation, l’existence éventuelle d’une autorisation de sortie et les éléments indiquant s’il s’agit plutôt d’une exception de supervision ou d’un problème de surveillance.

Cette distinction peut réduire les escalades inutiles, raccourcir le temps d’enquête et aider les équipes techniques à résoudre les interruptions liées aux équipements sans les traiter comme des incidents de supervision.

Ce qu’une station à domicile apporte au suivi par dispositif portable

Pour comprendre ce qui pourrait aider dans notre scénario de 21 heures, il faut d’abord examiner ce que l’équipement peut réellement nous indiquer. Une station fixe et un dispositif portable observent des aspects différents de la situation. Leurs rôles déterminent les conclusions que le service peut raisonnablement tirer.

Comment la station à domicile et le bracelet électronique fonctionnent ensemble

La Megastek S921 est une station fixe conçue pour fonctionner avec des bracelets électroniques de cheville compatibles, dont le MT200X. Megastek indique une connexion Wi-Fi avec le dispositif portable et une portée de détection nominale de 15 à 20 mètres. La station prend également en charge les alertes de coupure d’alimentation, de retrait, de choc et SOS, ainsi que les messages heartbeat.

Le MT200X fournit le positionnement à l’extérieur ainsi que les états et alertes liés au dispositif portable.

Ensemble, les appareils peuvent fournir trois types d’informations utiles :

• les observations de présence locale provenant de la station ;
• le positionnement extérieur fourni par le dispositif portable ;
• les états et alertes des équipements pouvant aider à expliquer une interruption de la surveillance.

Cette combinaison est plus utile qu’un signal isolé, à condition que le service conserve la signification réelle de chaque observation.

Ce que la proximité de la station permet réellement d’établir

Une détection récente indique que le dispositif portable attribué se trouvait près de la station au moment de l’observation. Elle ne permet pas de déterminer une pièce ou les limites exactes d’une propriété, ni de vérifier à elle seule l’identité de la personne qui porte le dispositif.

La portée nominale doit également être testée lors de l’installation. Les murs, les appartements voisins et l’emplacement de la station peuvent affecter la détection locale. Le service doit tenir compte de ces conditions lorsqu’il interprète une absence de détection.

Le principe est simple :

Une observation constitue un élément d’information sur une situation à un moment précis. Elle ne prouve pas automatiquement tout ce que l’opérateur souhaite savoir.

Avant d’interpréter un signal, il faut établir son contexte

Avant de définir les conditions d’alerte, le concepteur doit établir un contrat de données clair. Le service doit savoir quelles observations sont disponibles, à quels équipements elles se rapportent, quand elles ont été produites et quel contexte opérationnel s’applique.

Quel dispositif portable, quelle station et quelle attribution ?

Commençons par l’observation elle-même.

Quel dispositif portable a été détecté ? Quelle station est concernée ? Quand l’observation a-t-elle eu lieu ? Quels équipements sont actuellement attribués à l’installation surveillée ?

Cette relation est importante lorsque des appareils sont remplacés ou réattribués. L’historique des attributions doit être conservé afin que les événements antérieurs puissent être interprétés selon la relation entre les équipements qui s’appliquait à ce moment-là.

Un message récent peut contenir une ancienne observation

L’heure de l’événement sur l’appareil et l’heure de réception par le serveur doivent rester distinctes.

Un message retardé peut décrire correctement un événement antérieur sans fournir aucune indication sur la situation actuelle. Le service doit donc faire la distinction entre :

• l’état de la station ;
• l’état du dispositif portable ;
• la fraîcheur de l’observation de présence.

Un heartbeat récent peut confirmer la communication sans fournir de nouvelle observation de présence. Les informations relatives à l’alimentation et à la connectivité peuvent aider à expliquer une interruption, à condition que le service sache quels signaux chaque appareil fournit et ce qu’ils signifient.

La sortie était-elle autorisée à ce moment-là ?

Le service a également besoin du planning applicable et de toute autorisation de sortie approuvée.

Ces informations doivent inclure leur période de validité, leur fuseau horaire et leur référence. Les modifications doivent être identifiables afin qu’une autorisation expirée ou remplacée ne continue pas à influencer les décisions simplement parce que sa dernière valeur reste disponible.

Le système de gestion des dossiers doit rester la source de référence pour cette autorisation. Le workflow de surveillance doit l’utiliser comme contexte, sans devenir silencieusement la source de vérité.

Utiliser ces données pour interpréter l’absence de détection

Une fois les entrées définies, revenons à notre scénario de 21 heures.

Le service dispose désormais d’un contexte suffisant pour distinguer une observation récente confirmant la présence, un départ possible ou un problème de détection, et une situation dans laquelle la surveillance est simplement devenue incertaine.

Une détection récente établit la proximité à cet instant

Si une observation récente provenant de la station attendue arrive, le service peut afficher cet élément avec son horodatage.

Cela répond à la question de la présence au moment de l’observation. Toute alerte indépendante liée au dispositif portable ou tout incident concernant l’équipement reste ouvert et doit faire l’objet de son propre examen.

Les deux appareils transmettent, mais aucune présence locale n’est détectée

Supposons que les deux appareils continuent à communiquer, mais que la détection locale disparaisse.

Le service peut rechercher des informations complémentaires, comme une position extérieure récente du dispositif portable. Cette combinaison peut justifier l’examen d’un départ possible.

Le bon fonctionnement des communications ne prouve toutefois pas que la liaison radio locale fonctionne correctement. Un problème de détection reste une autre explication possible.

Le résultat utile n’est donc pas :

« La personne est partie. »

Il se rapproche plutôt de ceci :

« La présence locale n’est plus confirmée. Les appareils transmettent, le dispositif portable a fourni cette position récente, aucune autorisation applicable n’explique l’absence de détection et la situation doit être examinée. »

Il s’agit d’un point de départ bien plus exploitable pour un opérateur.

Lorsque l’équipement cesse de transmettre, la présence devient incertaine

Si l’un des appareils cesse de fournir des informations utilisables, le service doit classer la situation comme une incertitude de surveillance.

Conserver indéfiniment l’état de présence précédent masquerait cette interruption.

Le silence nécessite également son propre déclencheur. Une condition évaluée uniquement à l’arrivée d’un paquet peut ne jamais s’exécuter lorsque la transmission s’arrête. Un délai d’expiration vérifié sur la plateforme ou une minuterie externe peut identifier les observations obsolètes même en l’absence de nouvelle télémétrie.

La distinction essentielle se situe entre l’absence de preuve et la preuve d’une absence. Le service de surveillance doit préserver cette distinction au lieu de convertir une situation incertaine en alerte définitive.

Mettre en pratique la logique de surveillance avec Navixy

Ces distinctions se traduisent par plusieurs exigences de traitement. L’étape suivante consiste à déterminer ce que Navixy peut gérer à partir des données disponibles et ce qui nécessite une configuration ou une intégration externe.

Commencer par confirmer quels événements des appareils parviennent à Navixy

Le MT200X est intégré à Navixy, avec des capacités et des catégories de règles liées notamment à la batterie, à la connectivité, au SOS et à la surveillance du bracelet.

Cette intégration ne garantit pas la prise en charge de tous les événements de la S921. Leur correspondance exacte doit encore être confirmée. Le workflow doit donc être considéré comme une architecture de référence à valider avant le déploiement.

Il faut d’abord confirmer :

• quel appareil est à l’origine de chaque événement ;
• comment Navixy le décode ;
• où l’attribut obtenu est disponible ;
• si les horodatages et les changements d’état se comportent comme prévu.

Les événements de test contrôlés peuvent être examinés avec Data Stream Analyzer. Il convient de vérifier les valeurs manquantes et de déterminer si une alerte représente une transition ou un état qui reste actif.

Cette étape de validation est importante, car la fiabilité de la logique opérationnelle dépend directement de la définition des événements sous-jacents.

Évaluer les observations avec IoT Logic

IoT Logic fournit des attributs calculés, un traitement conditionnel et des actions externes.

Une fois les entrées requises vérifiées, le concepteur peut utiliser ces capacités pour évaluer les classifications décrites ci-dessus. Les observations d’origine doivent rester disponibles avec la classification dérivée afin que l’opérateur puisse examiner les éléments qui la justifient.

Si la station et le dispositif portable transmettent comme des objets distincts, leurs informations doivent également être corrélées correctement. Les placer tous les deux dans un même flux ne garantit pas à lui seul que leurs derniers états puissent être associés correctement.

Si la corrélation ou le comportement temporel requis ne sont pas disponibles, un service externe peut être nécessaire.

Intégrer les autorisations approuvées dans le flux avec HTTP Push

L’enrichissement HTTP Push permet à un système externe d’associer des attributs à un tracker existant afin qu’ils soient traités avec la télémétrie.

Un système de gestion des dossiers peut utiliser ce mécanisme pour fournir une autorisation applicable et son intervalle de validité. L’intégration doit gérer la correspondance des identités, les mises à jour des autorisations et la réévaluation aux limites du planning, y compris lorsqu’aucun nouveau paquet de l’appareil n’arrive.

HTTP Push apporte du contexte à la télémétrie existante. Si la S921 nécessite un décodeur externe, ce besoin doit être évalué séparément. L’enrichissement n’assure pas la prise en charge du protocole de l’appareil.

Transmettre l’exception et ses éléments au système de gestion des incidents

Une fois l’exception classée, un webhook IoT Logic peut envoyer une requête HTTP POST à une application externe.

Une charge utile utile pour l’exception peut inclure :

• la référence du dossier ;
• les identifiants des équipements ;
• la classification ;
• les heures des observations pertinentes ;
• la référence de l’autorisation applicable.

L’application destinataire doit créer ou mettre à jour l’incident et attribuer la responsabilité.

Les nouvelles tentatives, les doublons et les accusés de réception doivent être testés explicitement. Le déclenchement d’un webhook ne garantit pas que l’incident a été accepté ni qu’un opérateur a réagi.

Qui doit intervenir face à l’exception ?

La valeur du workflow devient plus claire lorsque nous suivons le scénario de 21 heures au-delà du traitement technique.

Différentes classifications peuvent orienter l’enquête vers différentes équipes.

Ce que l’équipe de supervision doit examiner

Supposons que les appareils transmettent, que le dispositif portable fournisse une position extérieure récente et qu’aucune autorisation applicable n’explique l’absence de détection à domicile.

Au lieu de reconstituer manuellement les données des appareils et les autorisations, l’opérateur reçoit les éléments pertinents ensemble, avec les horodatages et toute tolérance configurée.

Le workflow n’a pas décidé qu’une infraction avait eu lieu. Il a rendu l’enquête plus ciblée en indiquant ce qui est connu, ce qui manque et pourquoi la situation peut nécessiter une attention particulière.

Ce dont le support a besoin lorsque la surveillance devient incertaine

Supposons maintenant que la station ait cessé de transmettre avant le contrôle de présence prévu.

Le support a besoin d’un autre ensemble d’informations : l’heure de la dernière communication, les événements d’alimentation pertinents, l’état du dispositif portable associé et les détails de l’installation.

L’équipe de supervision doit également savoir que la couverture de surveillance est incertaine.

Un événement de perte d’alimentation suivi d’un silence constitue un indice de diagnostic utile, mais il ne prouve pas que la batterie de secours était épuisée. Le dossier d’incident doit continuer à distinguer les conditions observées des causes supposées.

La transmission a repris. L’incident peut-il être clôturé ?

Le rétablissement de la communication constitue une première étape de récupération.

La confirmation d’observations utilisables provenant de la bonne paire d’appareils en constitue une autre.

Un incident de perturbation ou de suspicion d’arrachement peut encore nécessiter un examen après la reprise de la transmission des deux appareils.

Les conditions de clôture doivent donc être définies pour chaque type d’incident, et la chronologie de la récupération doit être conservée. Les équipes de supervision et de support disposent ainsi d’une vue commune de ce qui est revenu à la normale et de ce qui reste non résolu.

Comment savoir si le workflow a réellement été utile ?

Un workflow de surveillance n’a de valeur que s’il améliore les opérations qu’il doit prendre en charge.

Il faut donc mesurer autre chose que le volume d’alertes.

Enregistrez ce que les enquêteurs ont réellement constaté après une exception. Les catégories utiles peuvent inclure :

• une sortie autorisée ;
• un problème d’équipement confirmé ;
• une difficulté de détection locale ;
• une cause non résolue.

Associez ces résultats aux délais d’accusé de réception et de résolution afin d’identifier les conditions qui génèrent régulièrement du travail et de déterminer si le contexte supplémentaire réduit l’effort d’enquête.

Les mesures opérationnelles utiles comprennent :

• le temps d’enquête ;
• le nombre de minutes d’incertitude de surveillance ;
• les incidents d’équipement répétés ;
• le temps nécessaire pour rétablir des observations utilisables.

IoT Query peut prendre en charge l’analyse historique et la BI autour de ces mesures, à condition que les attributs nécessaires des appareils et les dossiers d’enquête externes soient disponibles.

Une baisse du nombre d’alertes reste ambiguë. Elle peut indiquer que le workflow gère les exceptions plus efficacement, ou que le système ne fait plus remonter certains événements pertinents.

La charge de travail et la qualité de la surveillance doivent être évaluées ensemble.

Le véritable critère de réussite n’est pas simplement la diminution du nombre d’alertes. Il s’agit d’une opération de surveillance dans laquelle les exceptions sont examinées plus rapidement, les défaillances techniques sont distinguées plus systématiquement des problèmes de supervision et les périodes d’incertitude restent visibles au lieu d’être silencieusement prolongées.

Tester le parcours entre l’événement de l’appareil et la résolution de l’incident

Avant le déploiement, testez l’ensemble du parcours entre la condition physique et le dossier d’incident de l’opérateur.

Commencez avec une véritable paire station-dispositif portable, la documentation correspondant au firmware et une liste écrite des événements à vérifier.

Testez :

• l’association des appareils, l’origine des événements et les attributs décodés ;
• la perte de détection, la panne d’alimentation, la perte de communication et le rétablissement ;
• les valeurs obsolètes, les messages retardés et les doublons ;
• le remplacement et la réattribution des équipements ;
• les modifications du planning et les autorisations expirées ;
• les délais d’expiration en l’absence de télémétrie ;
• la transmission, l’accusé de réception, l’escalade et la clôture de l’incident.

Pour le scénario de 21 heures présenté au début, une mise en œuvre efficace doit fournir à l’opérateur une vue des éléments disponibles, de leurs limites et du planning applicable.

Elle doit également rendre visibles les interruptions de surveillance non résolues et orienter les défaillances techniques vers les personnes chargées de les résoudre.

Voilà la valeur concrète de la combinaison entre les observations de la station à domicile, la télémétrie du dispositif portable et l’état des équipements : non pas transformer des données incertaines en fausse certitude, mais fournir aux bonnes personnes de meilleurs éléments pour décider de la suite.

Contactez l’équipe Navixy pour discuter de la prise en charge du matériel et des exigences de données d’un workflow de surveillance de présence à domicile.