PotoP VMS Studio

Le client interroge le système d’exploitation sur ses écrans et le pilote graphique sur leurs caractéristiques : chaque moniteur indique ainsi son fabricant, son modèle, son numéro de série, sa résolution, sa fréquence de rafraîchissement, son connecteur et le GPU qui le pilote, ainsi que la température et la VRAM lorsque le pilote les communique. Chaque écran physique est identifié par son matériel, et non par sa position, et reçoit un code permanent comme M1. Les noms et les codes sont enregistrés sur ce poste client et survivent aux redémarrages comme aux rebranchements. Un écran débranché reste dans la liste jusqu’à ce que vous le supprimiez : un mur enregistré pointe donc toujours vers le même écran.

L’éditeur s’exécute dans le navigateur et enregistre la multi-disposition sur le serveur : la même recette est ainsi partagée avec les clients de bureau. Le navigateur liste ses propres écrans grâce à l’API Window Management, qui exige une connexion HTTPS sécurisée et l’autorisation de l’utilisateur. Chaque entrée affiche un code d’écran, et les codes absents de ce navigateur sont signalés comme non présents. Choisir une disposition pour un code l’ajoute à la recette. La projection ouvre une fenêtre de navigateur par écran correspondant et l’y place, chacune affichant la disposition en direct.

Les multi-dispositions sont enregistrées sur le serveur sous forme de liste de codes d’écran, avec la disposition associée à chacun. Cette vue d’ensemble représente chaque recette par une petite image de ses écrans et indique combien d’entre eux existent sur le navigateur que vous utilisez. Lancer la projection ouvre une fenêtre sur chaque écran correspondant et y démarre les dispositions en direct. Modifier et Supprimer changent la recette enregistrée pour tous les clients. L’accès suit les mêmes droits d’utilisateurs et de groupes que le reste du système, et un mur peut être rattaché à des utilisateurs ou à des groupes pour s’ouvrir automatiquement pour eux.

Grâce à l’API Window Management — qui exige HTTPS et une autorisation accordée une seule fois — le navigateur sait sur quel écran physique se trouve chaque fenêtre. Identifier ouvre une fenêtre sans bordure sur chaque écran détecté, y affiche en grands caractères le code et le nom de l’écran, puis la ferme après quelques secondes. Le code provient d’un registre conservé dans ce navigateur : les noms modifiés sont conservés et un écran débranché reste dans la liste jusqu’à ce que vous le supprimiez. Le panneau de détails indique la résolution, la position, l’échelle et la profondeur de couleur telles que le navigateur les voit.

Pendant que le pipeline d’IA analysait le flux en direct, il a enregistré chaque détection — classe, niveau de confiance, cadre de délimitation et vignette — dans la base de données d’analyse. La lecture relit ces lignes pour l’instant affiché et dessine le cadre par-dessus la vidéo dans le navigateur : rien n’est incrusté dans l’enregistrement. La liste latérale s’appuie sur les mêmes lignes et affiche la classe, l’heure et le niveau de confiance. Un clic sur une entrée positionne l’enregistrement à cet instant précis. Le tracker compte aussi combien d’observations appartiennent à un même objet, ce qui permet de distinguer une voiture garée de nombreux véhicules de passage.

Examiner prend l’image sous la tête de lecture et l’envoie au serveur, qui y applique le détecteur et découpe l’objet avec son masque. Le bouton Identifier transmet ce découpage à un modèle de langage visuel configuré dans les paramètres IA, exécuté localement ou chez un fournisseur de votre choix, et affiche sa description. La couleur est déduite du découpage lui-même. « Rechercher ce type et cette couleur » interroge ensuite la base de données d’analyse pour trouver les détections de même classe et de même couleur dans les enregistrements. La description est la meilleure estimation du modèle, qui le signale lorsque l’image est de mauvaise qualité.

Le serveur parcourt les segments enregistrés de la plage choisie, les déchiffre en mémoire et en échantillonne les images. Un filtre de soustraction d’arrière-plan ignore les images vides, de sorte que le détecteur et le suiveur d’objets ne s’exécutent que là où quelque chose bouge. Chaque objet suivi devient un « tube » d’images recadrées avec ses horodatages d’origine. Les tubes sont replanifiés pour être joués simultanément sur un même arrière-plan, et ffmpeg produit un MP4 où l’heure réelle de chaque objet est incrustée. La tâche s’exécute en arrière-plan avec suivi de progression et peut être annulée. Un clic sur un objet amène la ligne de temps à son moment d’origine.

Le serveur extrait la plage horaire demandée des segments enregistrés avec ffmpeg, en déchiffrant en mémoire les enregistrements chiffrés si vous le demandez. L’horodatage, le nom de la caméra et le filigrane sont incrustés dans l’image. Si vous activez le chiffrement, le MP4 est chiffré en AES-256 avec une clé dérivée de votre mot de passe par PBKDF2, et un fichier de signature est écrit à côté. Le mot de passe n’est jamais conservé : rien ne permet donc de le récupérer. Le résultat reste sur le serveur, est téléchargé sur votre ordinateur, ou les deux, selon la destination choisie.

Le lecteur fonctionne sur n’importe quel ordinateur, sans serveur PotoP. Vous choisissez la vidéo chiffrée et son fichier de signature, puis saisissez le mot de passe. Il vérifie d’abord la signature par HMAC pour prouver que le fichier n’a pas été modifié, puis dérive la clé du mot de passe avec PBKDF2 et déchiffre en AES-256. La vidéo en clair n’existe qu’en mémoire pendant la lecture. Vous pouvez alors faire glisser les poignées vertes pour découper une sélection, enregistrer une image fixe ou exporter une copie MP4 standard. Une variante pour navigateur est fournie dans les dossiers d’export, avec des lanceurs pour Linux, Windows et macOS.

Chaque caméra possède ses propres paramètres d’enregistrement stockés sur le serveur, et l’enregistreur les applique dès que vous enregistrez. Les déclencheurs peuvent être continus, suivre un planning hebdomadaire ou dépendre d’événements tels qu’un mouvement, une personne, une plaque, une entrée d’alarme ou une macro, avec des tampons pré- et post-événement pour conserver l’instant qui précède le déclenchement. Les segments sont découpés à une longueur définie et peuvent être chiffrés en AES-256 une fois fermés. La conservation supprime les anciens segments selon leur âge ou une taille maximale. Les événements de démarrage, d’arrêt et de détection peuvent déclencher des notifications via les événements système, l’e-mail, Telegram ou un webhook.

Le détecteur principal tourne à une fréquence d’images configurée, avec ses propres seuils de confiance et de chevauchement, son nombre maximal de détections et son filtre de classes. Un tracker, ici ByteTrack, relie les détections d’une image à l’autre en identifiants d’objet stables, qui alimentent le comptage et le temps de présence. Les étapes secondaires sont conditionnées par la classe : la reconnaissance de plaques ne démarre que si une voiture, un camion, un bus ou une moto est détecté, et la posture ou la segmentation uniquement lorsque leur classe déclencheuse apparaît. La charge reste ainsi faible, car les modèles plus lourds ne voient qu’un petit recadrage et non l’image entière.

Un modèle de posture s’exécute sur le recadrage de la personne trouvée par le détecteur principal et renvoie les points clés du corps, chacun avec son niveau de confiance. Le serveur stocke le squelette et le navigateur le dessine sur l’image, avec le tableau des articulations à côté. La détection de chute analyse le mouvement et la disposition de ces points clés dans le temps, et un réglage de sensibilité ajuste ses seuils. Lorsqu’elle se déclenche, l’événement est enregistré et peut lever une alerte ou lancer une macro. Le tableau en direct ci-dessous interroge la base de données : vous voyez donc les mêmes lignes que celles qui parviennent au système d’alarme.

Un modèle de segmentation s’applique aux objets trouvés par le détecteur principal et renvoie un masque au pixel près pour chacun. Le serveur les envoie au navigateur sous forme d’images de masque, et l’aperçu les peint sur l’image. Le suiveur conserve un identifiant d’objet, ce qui permet au tableau d’indiquer depuis combien de temps chaque objet est visible. Lorsqu’un objet reste immobile au-delà du seuil d’immobilité, la logique de cycle de vie le marque comme abandonné et la ligne passe au rouge. Les événements de cycle de vie, comme « apparu » ou « parti », sont journalisés pour une recherche ultérieure.

Vous dessinez des polygones et des lignes directement sur une image en direct, et le serveur les enregistre dans les coordonnées normalisées de la caméra : ils restent donc justes quelle que soit la résolution. Le tracker suit les identifiants d’objet, et un franchissement est détecté lorsque la position d’un objet suivi passe d’un côté de la ligne à l’autre, ce qui donne le sens A vers B ou B vers A. Les zones génèrent des événements d’entrée et de présence. Chaque événement est inscrit dans la base de données d’analyse avec un horodatage et un identifiant de piste, où compteurs, rapports, alarmes et macros peuvent l’exploiter.

La détection de mouvement a deux sources. La détection propre à la caméra arrive sous forme d’événements de mouvement ONVIF, tandis que l’analyse serveur compare les images vidéo à un modèle d’arrière-plan sur le serveur, en utilisant le CPU ou le GPU. Le masque est une grille de blocs que vous peignez sur l’image ; les blocs marqués comme ignorés sont exclus de la comparaison, si bien que le feuillage ou la circulation ne déclenchent rien. Sensibilité, surface minimale, fréquence d’échantillonnage et réduction d’échelle sont réglables. Le masque est enregistré avec la caméra et appliqué par le serveur dès que vous enregistrez.

Vous dessinez des blocs sur une image en direct, et le serveur les enregistre avec la caméra. Selon les options activées, le serveur floute ou recouvre ces zones dans le flux en direct, les instantanés et les enregistrements. Pour le direct et les enregistrements, il le fait sur le serveur, avant que la vidéo ne soit stockée ou diffusée ; pour les enregistrements, la zone masquée est définitivement perdue dans la vidéo stockée, ce dont la page vous avertit. La couleur et l’intensité du flou sont réglables. Les masques sont transmis au pipeline en cours dès l’enregistrement : la modification s’applique donc sans redémarrer la caméra.

Chaque recadrage de personne ou de véhicule est converti en un vecteur d’apparence de 256 valeurs par un petit modèle de ré-identification fonctionnant sur OpenVINO, puis stocké dans la base de données d’analyse. La recherche transforme l’image de requête de la même manière et la compare aux vecteurs stockés par similarité cosinus, à l’aide d’un index en mémoire, si bien que le résultat est à la fois exact et rapide. Comme elle compare l’apparence globale et non un visage, elle fonctionne sur des personnes vues de dos ou en basse résolution. Sélectionner un résultat charge l’historique d’observations et l’itinéraire de cette piste, et Suivre dans la lecture ouvre les enregistrements.

Lorsqu’un objet suivi franchit une ligne configurée, le serveur enregistre l’événement avec son sens, la caméra, la ligne et l’heure. Cet écran lit ces événements en direct dans la liste Récents. Le rapport d’historique les regroupe par heure ou par jour, avec des colonnes entrées, sorties et total, et peut ajouter le temps de présence et l’occupation lorsqu’ils sont configurés. Le dépassement d’une limite d’occupation déclenche une alerte. Le bouton CSV exporte le rapport vers un tableur, qui est la manière habituelle de mener les études d’effectifs et d’occupation.

Le serveur compte les détections par caméra et par heure à partir des données d’analyse, y compris les plaques et les correspondances avec les listes de surveillance. Ces chiffres sont transmis à un modèle de langage — ici un petit modèle Llama servi localement par Ollama — qui rédige le compte rendu en langage clair. Si aucun modèle n’est disponible, un simple résumé statistique s’affiche à la place. Le détecteur d’anomalies n’utilise aucun modèle d’IA : il apprend un nombre typique pour chaque heure de la journée, séparément pour la semaine et le week-end, et signale toute heure qui dépasse nettement cette référence. Il reste silencieux tant que l’historique est insuffisant.

Un plan d’étage est un canevas doté d’une image d’arrière-plan facultative, d’éléments de bâtiment dessinés et d’icônes, enregistré sur le serveur avec le reste de la configuration du système. Chaque icône est liée à un objet réel — caméra, éclairage, sortie de porte ou interphone — et le serveur transmet l’état de cet objet à tous les clients ouverts : la couleur de l’icône change donc dès que l’appareil change d’état. Les clients de bureau, navigateur et téléphone lisent tous la même définition de plan et la dessinent eux-mêmes, c’est pourquoi un plan a partout le même aspect. La modification nécessite les autorisations de visualisation.

La page Nouveau plan regroupe un ensemble de générateurs intégrés. Vous choisissez un type de bâtiment, renseignez quelques paramètres, comme le nombre de salles de consultation et la quantité d’équipements à placer, et un aperçu est calculé sur-le-champ. Lors de la création, le générateur écrit murs, pièces, portes et icônes dans un plan ordinaire sur le serveur. Rien n’est verrouillé ensuite : le résultat est un plan normal, que vous modifiez comme un plan dessiné à la main. Un plan existant peut aussi être cloné, avec ou sans ses éléments de construction.

Les modèles sont des générateurs pilotés par code qui disposent pièces, murs et icônes à partir de quelques paramètres, ici le nombre de rangées de serveurs et le niveau d’équipement. Les icônes sont créées sans liaison, avec le bon type et le bon libellé pour chaque pièce : l’installateur n’a plus qu’à relier chacune d’elles à une caméra, un capteur ou une sortie réels. Comme le résultat est enregistré comme un plan ordinaire, il peut être renommé, déplacé, complété ou dupliqué comme n’importe quel autre. Les différents types de bâtiments utilisent simplement des générateurs différents derrière le même formulaire.

L’éditeur d’icônes comporte un onglet Caméra avec un aperçu en forme de boussole. Faites glisser une poignée pour orienter, les poignées latérales pour la largeur et une poignée carrée pour la portée, ou saisissez les valeurs et utilisez les préréglages d’objectif. L’aperçu montre exactement ce que le plan affichera après OK ; l’anneau et les lignes de repère n’existent que dans l’éditeur. Le même onglet définit la caméra et le flux (principal ou secondaire) utilisés par l’icône, ainsi que l’action d’un clic, par exemple l’ouverture d’un aperçu. Toutes les valeurs sont enregistrées avec l’icône.

La boîte de dialogue présentée est l’éditeur d’icône d’éclairage : chaque état (éteint, allumé, tamisé, en défaut, hors ligne) y reçoit sa propre couleur, avec des pastilles d’état d’entrée et de sortie en option. Une icône d’éclairage est liée via un plugin d’appareil, comme l’intégration Philips Hue ou les E/S génériques, et le serveur maintient son état synchronisé avec le luminaire réel. La commutation automatique à partir des entrées d’interphone ou de capteur est assurée par le moteur de macros côté serveur, et non par le plan lui-même. Les problèmes signalés par le plugin, comme une absence de connexion, ont leur propre couleur sur l’icône.

Une icône d’interphone est liée à un plugin d’interphone — dans la boîte de dialogue, l’intégration Commend ICX — et le serveur écoute les événements d’appel de ce poste. Chaque événement correspond à un état de l’icône, comme repos, appel sortant, sonnerie, en communication, en attente, urgence ou défaut de ligne, et chaque état possède sa propre couleur, prévisualisée dans l’éditeur. L’état est transmis à tous les clients connectés, de sorte que le plan reflète le poste réel en quelques instants. Les actions sur l’icône, comme appeler ou ouvrir une porte, sont renvoyées à l’appareil par ce même plugin.

Chaque action d’icône peut être verrouillée par un code PIN. Lorsqu’un opérateur clique sur une telle icône, le client demande le code PIN avant d’envoyer la commande au serveur, de sorte qu’un clic malencontreux ne peut ni commuter une sortie ni ouvrir une porte. Les codes PIN peuvent être permanents ou temporaires et se définissent icône par icône dans l’éditeur. Ce verrou constitue une protection supplémentaire, en plus des contrôles d’autorisation habituels que le serveur continue d’appliquer à l’utilisateur connecté.

Le panneau Éléments de construction répertorie les objets que l’on peut dessiner — murs, portes, fenêtres, escaliers, ascenseurs, routes, plantes, clôtures, piscines, panneaux — et vous pouvez ajouter les vôtres. Les éléments sont des formes vectorielles enregistrées dans le même plan que les icônes d’appareils, avec leur position, leur taille et leur ordre de calque : ils restent nets à tous les niveaux de zoom. Un plan peut donc être dessiné entièrement dans le produit, ou par-dessus un arrière-plan PNG, JPG, BMP ou GIF importé, comme un plan d’architecte.

Chaque client de bureau et navigateur s’enregistre auprès du serveur sous un identifiant unique et continue de se signaler, si bien que la page peut afficher ce qui est en ligne, son utilisateur, son GPU, son nombre d’écrans et l’heure de dernière activité. Un administrateur peut préenregistrer un client par son identifiant ou en supprimer un. Affecter un joystick lie un enregistrement d’appareil à ce client. Les joysticks réseau envoient de petites trames UDP ou HTTP et restent désactivés lors de leur première détection, afin que personne sur le réseau local ne puisse piloter les caméras tant qu’un administrateur ne les a pas activés. Les contrôleurs joystick IP se connectent en VISCA over IP : le serveur écoute sur un port, se comporte comme une caméra et transmet les commandes à l’interface PTZ de la caméra réelle.

Un groupe d’appareils est un ensemble nommé de caméras sur un serveur. Les groupes d’utilisateurs sont liés aux groupes d’appareils et, lorsqu’un utilisateur demande des caméras, le serveur ne renvoie que celles qui appartiennent à un groupe d’appareils lié à l’un de ses groupes. Les statistiques indiquent le nombre de caméras ainsi que le nombre de groupes d’utilisateurs et d’utilisateurs ayant accès. Comme la règle est évaluée par le serveur et non par le client, une caméra ajoutée à un groupe est immédiatement visible par les bonnes personnes, et l’administrateur intégré voit toujours tout.

Le sélecteur répertorie tous les groupes d’utilisateurs avec une courte description de leurs droits, et un champ de recherche affine la liste. L’ajout d’un groupe enregistre sur le serveur un lien entre ce groupe d’utilisateurs et le groupe d’appareils. Dès lors, chaque membre de ce groupe obtient les caméras du groupe en vue en direct, en lecture et dans les mosaïques, et aucune autre par ce lien. Lier ou délier se fait en une seule étape et prend effet pour les utilisateurs connectés sans redémarrage.

Les administrateurs choisissent si les actions des clients et les modifications côté serveur sont enregistrées, la gravité minimale, les catégories à conserver et le nombre de jours de conservation. Une purge en arrière-plan supprime régulièrement les lignes plus anciennes, et « Appliquer la conservation maintenant » la lance à la demande. Les événements d’authentification et de sécurité sont toujours conservés à leur propre niveau de gravité. La piste peut être téléchargée en CSV ou en PDF, et une tâche planifiée peut envoyer le rapport par e-mail chaque semaine ou selon la fréquence choisie, via le serveur de messagerie configuré dans les paramètres d’événements.

Le PDF est généré sur le serveur à partir des mêmes lignes d’audit que celles affichées dans l’onglet Rapports, à l’aide d’une bibliothèque PDF Python standard, et non d’une capture d’écran. Il contient l’en-tête et le logo du produit, l’auteur et la date du rapport, les filtres actifs, un tableau paginé dont l’en-tête se répète sur chaque page, et un pied de page. Les très gros volumes de résultats sont plafonnés, et le rapport l’indique explicitement, par exemple « 5000 sur le total ». Le rapport planifié envoyé par e-mail joint ce même fichier.

L’éditeur de macros est un graphe de nœuds visuel qui s’exécute sur le serveur. Un nœud Événement système se déclenche lorsque le moniteur de santé émet un événement correspondant — un certificat sur le point d’expirer, une forte occupation du disque ou du GPU, la batterie faible d’un appareil — et transmet le texte et la valeur de l’événement sur ses ports de sortie. Relié à un nœud Envoi Telegram, il publie un message via l’API des bots Telegram. Le graphe se vérifie avec Valider, peut être simulé et, lorsqu’il est actif, l’éditeur affiche les valeurs qui transitent par chaque nœud.

L’écran montre le nœud Telegram Send de l’éditeur de macros : jeton du bot, identifiant de conversation, modèle de message avec variables pour l’heure et la valeur, bouton Test et intervalle minimal entre deux envois afin que des événements répétés n’inondent pas la conversation. Le serveur publie via l’API des bots Telegram lorsque le nœud reçoit un front montant. Les alertes par e-mail utilisent le serveur SMTP configuré dans les paramètres d’événements. Les événements eux-mêmes proviennent du moniteur de santé du serveur et des flux d’événements des caméras.

Le serveur définit environ 144 autorisations, chacune associée à un module et à un niveau d’action, comme utiliser ou modifier. La boîte de dialogue du groupe les présente par sections, avec un champ de filtre, des raccourcis tout/utiliser/modifier et des préréglages qui cochent un ensemble type. Le serveur vérifie l’autorisation concernée à chaque appel d’API et sur chaque canal en direct : un utilisateur sans droits PTZ ou d’enregistrement est refusé, même s’il appelle l’API directement. Les tentatives refusées sont inscrites dans la piste d’audit avec le nom de l’autorisation.

Au lieu d’accorder des droits utilisateur par utilisateur, l’administrateur répartit les utilisateurs dans des groupes prédéfinis comme Opérateurs, Observateurs et des paires éditeur/utilisateur pour les mosaïques, macros, plans, PTZ, appareils et plus encore. Les droits effectifs d’un utilisateur correspondent à l’union des droits de tous ses groupes, plus leurs mosaïques et les caméras des groupes d’appareils liés à ces groupes. Modifier un groupe modifie tous ses membres à la fois, ce qui garantit des rôles cohérents sur de nombreux comptes.

L’onglet Ressources d’un groupe fixe des plafonds numériques, zéro signifiant illimité : caméras et flux simultanés qu’un membre peut ouvrir, durée, taille et nombre d’exports par jour, nombre de mosaïques, macros et signets qu’il peut créer, requêtes API par heure et jetons. Le serveur les applique au moment de la requête, par exemple en refusant un flux au-delà du plafond. Les réglages individuels d’un utilisateur peuvent remplacer la valeur du groupe, de sorte qu’une installation partagée reste prévisible sous charge.

L’onglet Sécurité d’un groupe définit les sessions simultanées, le délai d’expiration de session, l’authentification à deux facteurs obligatoire, la longueur minimale, la complexité et l’expiration des mots de passe, l’interdiction de réutilisation, le verrouillage après échecs et sa durée, ainsi que le niveau d’audit et la conservation des journaux. Le serveur applique la politique à la connexion et lors des changements de mot de passe ; les mots de passe sont stockés sous forme de hachages bcrypt salés, jamais en clair. La durée de connexion est égalisée, de sorte qu’on ne peut pas distinguer un nom d’utilisateur inconnu d’un mauvais mot de passe.

L’onglet Autorisations de l’utilisateur affiche la même matrice que celle d’un groupe, en deux couleurs : les cases bleues sont des autorisations directes modifiables ici, les violettes proviennent des groupes de l’utilisateur et sont en lecture seule dans cette vue. Le serveur combine les deux ensembles lorsqu’il contrôle une requête. Les autorisations directes sont utiles pour des exceptions ponctuelles ; le compteur indique combien sont actives sur le total et combien proviennent des groupes. « Tout effacer (direct) » supprime les exceptions sans toucher aux droits de groupe.

L’onglet Sécurité gère le second facteur d’un utilisateur, un mot de passe à usage unique basé sur le temps (TOTP) compatible avec les applications d’authentification courantes, ainsi que des codes de secours à usage unique. Il affiche aussi l’état du compte — verrouillage, tentatives échouées, dernière connexion — et permet à un administrateur de déverrouiller ou de réinitialiser. Les sessions actives sont listées avec l’adresse IP et le navigateur, et peuvent être fermées une à une ou toutes ensemble. Les jetons d’API sont des identifiants distincts, avec un nom et une date d’expiration : scripts et intégrations n’ont pas besoin du mot de passe de l’utilisateur, et ils peuvent être révoqués à tout moment.

L’onglet Activité lit deux informations sur le serveur pour un utilisateur : les sessions actives, avec adresse IP, identifiant du client et dernière activité, et les derniers événements de sécurité de la piste d’audit. Les actions refusées, comme une autorisation rejetée ou une caméra que l’utilisateur n’a pas le droit de voir, sont journalisées au moment où le serveur rejette la requête, avec le nom de l’autorisation ou de la ressource. Les sessions indiquent le type de client, par exemple un navigateur ou un script utilisant l’API, ce qui aide à distinguer l’usage normal d’un accès inattendu.

Le serveur peut générer une autorité de certification ou en importer une existante. Le certificat de l’AC et sa clé privée sont stockés sur le serveur ; le fichier de clé n’est lisible que par le compte de service et peut être protégé par un mot de passe, et seuls les certificats signés quittent la machine. L’onglet permet aussi de télécharger le certificat de l’AC, de le sauvegarder et de le restaurer, de l’installer dans le magasin de confiance du système, de révoquer des certificats par numéro de série et de générer une liste de révocation (CRL). Un certificat de serveur RADIUS pour le 802.1X peut être émis par cette même AC.

Une nouvelle paire de clés est générée et un certificat est signé par l’AC enregistrée pour le nom et les entrées DNS et IP indiqués, avec la validité et le type de clé choisis. Le résultat est proposé au format PEM (certificat, clé et AC) ou sous forme de paquet PKCS#12. En cochant l’option serveur, le certificat est installé comme certificat propre du serveur, l’AC est approuvée pour le client de bureau, l’ancien certificat auto-signé est retiré et le service redémarre : les navigateurs cessent d’afficher des avertissements dès qu’ils font confiance à l’AC.

Vous saisissez les caméras à la main ou importez un CSV avec adresse, fabricant, identifiants et ports. Pour chaque ligne, le serveur émet un certificat d’appareil depuis l’autorité de certification (CA), transmet le certificat et la CA à la caméra via l’API web propre au fabricant, puis active HTTPS. Des actions permettent aussi de désactiver HTTPS et de le tester. Le serveur doit pouvoir joindre les caméras sur le réseau, et les identifiants ne servent que le temps de l’opération. Résultat : un seul passage au lieu de se connecter à chaque caméra.

Pour une caméra, le serveur signe un certificat d’appareil, le téléverse via l’API du fabricant et peut transmettre la CA, activer HTTPS, désactiver le HTTP non chiffré et tester la connexion sécurisée. La seconde section se connecte à un autre hôte PotoP via SSH, copie le certificat, la clé et le fichier CA dans le répertoire de destination et peut redémarrer un service. Les deux opérations s’exécutent sur le serveur : celui-ci doit pouvoir joindre la cible, et elles nécessitent des droits d’administrateur.

Le panneau affiche le certificat actuellement chargé pour le client web, avec son sujet, son émetteur, sa validité, le type et la taille de sa clé, l’algorithme de signature et l’empreinte SHA-256, et peut l’exporter au format PEM. La section mobile met le certificat de l’AC à disposition en téléchargement, ou sous forme de QR code qu’un téléphone ou une tablette peut scanner : l’appareil fait ainsi confiance au serveur une fois pour toutes et cesse d’afficher des avertissements. Des instructions et des scripts d’installation sont fournis pour Linux, macOS et Windows.

Avant l’envoi du mot de passe, la page de connexion contacte le serveur choisi en HTTPS et vérifie le certificat auprès du magasin de confiance du navigateur. Si la chaîne est valide et correspond, le message vert « Connexion sécurisée » apparaît ; sinon, l’utilisateur voit un avertissement. Cette vérification est effectuée par la pile TLS du navigateur lui-même : la page ne peut donc pas la falsifier. Les identifiants sont ensuite envoyés au serveur vérifié par la connexion chiffrée.

Le panneau RAID des paramètres d’administration du serveur est un moteur de dessin qui représente les disques, les bandes et la parité pour le niveau choisi. En mode simulation, vous choisissez un niveau et un nombre de disques, et il affiche une grappe synthétique, sans rien toucher de réel. Sur un serveur en production, la même vue est alimentée par le contrôleur effectif : RAID logiciel via mdadm, ou contrôleurs matériels via les outils en ligne de commande de leur fabricant. La tolérance aux pannes et la capacité utile sont calculées à partir du niveau et du nombre de disques, et le schéma montre comment la parité tourne entre les membres, pour que les installateurs puissent planifier avant de construire une grappe.

Le même moniteur RAID sait représenter les niveaux imbriqués. Ici, un RAID 60 simulé de seize disques apparaît sous forme de quatre groupes RAID 6, avec la répartition entre les groupes au-dessus. Le panneau calcule la tolérance aux pannes par groupe — chaque groupe survit à la perte de deux disques — et la capacité utile, soit huit disques sur seize. Le curseur de simulation en dessous transmet cette capacité au calculateur de durée d’enregistrement, qui la divise par le débit mesuré des caméras. La planification se fait sur les données du serveur, sans modifier aucun disque.

La boîte de dialogue Gestion RAID s’exécute dans le client de bureau mais agit sur le serveur auquel vous êtes connecté. L’administrateur saisit de nouveau son mot de passe pour obtenir un jeton d’administration de courte durée. Créer une grappe produit un plan : le serveur liste les disques détectés, prépare la commande exacte sous forme de liste d’arguments — jamais de chaîne shell — et l’affiche en aperçu. Rien ne s’exécute au stade du plan. « Appliquer » exécute uniquement ce plan enregistré, via une liste fixe d’outils RAID autorisés, et les actions dangereuses vous demandent d’abord de saisir l’identité de la cible. Le RAID logiciel utilise mdadm.

Les actions d’agrandissement et de maintenance suivent le même processus « planifier puis appliquer » que la création de grappes. Le client envoie la demande ; le serveur valide chaque nom de périphérique, construit la commande mdadm exacte pour ajouter des disques, étendre la grappe, changer la taille de bloc ou convertir le niveau, puis la renvoie pour vérification. La vérification et la réparation (scrub) lancent l’analyse de cohérence du noyau sur la grappe. Les vitesses de resynchronisation minimale et maximale sont les limites standard du RAID logiciel Linux : une reconstruction peut ainsi être ralentie pendant que les caméras enregistrent. L’application exige le jeton d’administration et, pour les étapes risquées, une confirmation d’identité.

L’onglet Configuration détermine comment une défaillance est détectée et comment le serveur de secours reste à jour. Le moniteur sonde chaque serveur à l’intervalle défini, et un serveur n’est déclaré défaillant qu’après le nombre configuré d’échecs consécutifs. Les services requis sont toujours surveillés, tandis que les services facultatifs, comme la VoIP ou l’analyse, ne comptent que s’ils sont cochés. L’intervalle de sauvegarde, le nombre d’instantanés conservés et un plafond de bande passante pilotent l’agent de réplication du nœud de basculement. Les alertes peuvent être envoyées par e-mail (SMTP), Telegram ou notification sur le bureau.

Pendant un cycle de sauvegarde, le nœud de basculement demande un manifeste des fichiers et bases de données du serveur en production, puis ne récupère que ce qui a changé depuis l’instantané précédent. Les fichiers inchangés sont liés à partir de la copie précédente : c’est pourquoi le panneau peut afficher des milliers de fichiers dont seule une poignée a été récupérée. La progression, en fichiers et en mégaoctets, est écrite dans un enregistrement d’état que le client affiche en direct. L’export terminé est déplacé par rotation dans un dossier d’instantanés, et la ligne de base de données du serveur de secours indique « Synchronisation » pendant l’application des données.

Une reprise a lieu automatiquement lorsque le seuil de défaillance est atteint, ou manuellement avec « Forcer la reprise ». Le serveur de secours sert alors les caméras du serveur défaillant, celui-ci est marqué hors ligne, et le bandeau ainsi que la ligne d’état supérieure passent au rouge. Lorsque le serveur d’origine répond de nouveau aux sondages, « Retour » ramène les caméras chez lui. L’onglet Configuration peut aussi le faire automatiquement après que le serveur a été opérationnel pendant un nombre de minutes défini. Les clients continuent de fonctionner, car les utilisateurs et les sessions étaient déjà répliqués sur le serveur de secours.

L’onglet Journal des événements enregistre en temps réel chaque étape du processus de redondance, avec un horodatage local : un cycle de réplication forcé, la demande de reprise, le démarrage du processus de reprise, la migration des caméras, le nombre de flux arrêtés sur le serveur défaillant et le résultat final. Les entrées proviennent de la séquence de reprise du serveur et sont conservées pendant la session, avec un bouton Effacer. Comme chaque transition est écrite dans l’ordre, un opérateur peut vérifier après coup ce que le système a fait et le reprendre dans un rapport d’incident.

L’onglet Entraînement regroupe les réglages de jeu de données, d’augmentation et de source d’images qui alimentent un entraînement. Un jeu de données est un dossier d’images annotées, alimenté par des fichiers importés, une webcam, un fichier vidéo ou un flux RTSP. Les augmentations — mosaïque, retournements, mise à l’échelle, rotation, variations de couleur — sont appliquées à la volée pendant l’entraînement. La part de validation et la graine aléatoire rendent les entraînements reproductibles. La boîte de dialogue présentée s’affiche lorsqu’on clique sur « Démarrer l’entraînement » sans jeu de données sélectionné. La conversion vers ONNX et les formats d’accélérateurs se fait dans un onglet distinct.

La reconnaissance d’actions se fait en deux étapes. D’abord, un modèle de pose analyse vos vidéos ou images et extrait les points clés du corps de chaque personne, enregistrés avec l’étiquette choisie, comme marche ou chute. Ensuite, un petit classificateur de séquences — un LSTM par défaut — est entraîné sur des fenêtres d’images consécutives de ces points clés, avec PyTorch sur le périphérique sélectionné. Après l’entraînement, la précision, le rappel et le F1 sont calculés par classe sur des données de validation mises de côté. Le résultat peut être exporté avec un extrait de code d’inférence pour être utilisé dans l’analyse.

L’onglet Plaques entraîne un réseau de reconnaissance de séquences de caractères de type LPRNet, qui lit une image de plaque recadrée et décode les caractères par CTC. Vous choisissez le jeu de caractères d’un pays et la taille d’entrée, puis collectez des recadrages de plaques à partir d’enregistrements, de dossiers d’images, de listes d’URL ou de jeux de données publics. L’éditeur d’étiquettes permet de corriger les plaques non étiquetées, avec des suggestions OCR en option. « Tester sur une image » exécute le modèle actuel sur une seule image. Les modèles terminés sont exportés et peuvent être compilés en paquet pour les accélérateurs Axelera Metis, puis installés dans la cascade de reconnaissance en production.

L’onglet Annotation est un outil d’étiquetage intégré au Training Studio. Vous définissez des classes d’objets, parcourez les images du jeu de données et tracez à la souris des cadres englobants ou des polygones. Chaque annotation est enregistrée avec sa classe et ses coordonnées dans le dossier du jeu de données, au format lu par les outils d’entraînement. L’annotation automatique exécute un modèle de détection existant sur l’image et vous propose des étiquettes à accepter ou à corriger. Le panneau de statistiques compte le total des annotations et les cadres par classe, pour repérer les classes qui manquent d’exemples.

Les questions d’inventaire reçoivent une réponse directement depuis la base de données du serveur, sans modèle de langage. Taper « list cameras » lance une recherche sur le serveur et renvoie les noms, adresses IP, fabricants et l’état de chaque caméra (active, en enregistrement), présentés sous forme de tableau texte dans le Result Board. Le même moteur couvre les plans, serveurs, dispositions et macros. Le chat ne fait qu’afficher le résultat : la réponse reflète donc la configuration en production et respecte les autorisations de l’utilisateur connecté.

Les demandes auxquelles il manque un détail, comme une requête avancée sur une caméra, ouvrent un court dialogue sur le serveur. L’assistant liste les choix valides tirés de la configuration actuelle — ici, chaque caméra avec son adresse — et attend la réponse. Vous pouvez répondre par la lettre, le nom ou l’adresse IP. Retour revient à la question précédente et Annuler met fin au dialogue. Le sélecteur est généré à partir des données en direct : il ne propose donc que des caméras qui existent.

Les questions sur la base de données et les sauvegardes sont traitées par des fonctions directes du serveur. La commande « db status » lit la connexion PostgreSQL en production et indique le type, la version, la taille, le nombre de tables, le pool de connexions et l’hôte, avec le mot de passe masqué. La commande « backups » liste les sauvegardes de configuration stockées sur le serveur, avec leur date et leur taille. L’interrupteur LLM active un modèle de langage facultatif qui tourne localement via Ollama : les questions libres peuvent ainsi être traitées sans envoyer de données à un service cloud.

La boîte de dialogue de verbosité change la manière dont le chat met en forme les réponses du serveur. Les quatre niveaux vont du décompte sur une seule ligne à la sortie complète, valeurs brutes comprises. Horodatages, icônes d’état et tableaux ASCII peuvent être activés ou désactivés, tout comme un mode d’espacement compact et une limite du nombre d’éléments affichés dans les listes. Les réglages s’appliquent côté client lors de l’affichage des réponses : différents opérateurs peuvent donc utiliser différents niveaux avec le même serveur. Le panneau derrière la boîte de dialogue est la liste d’aide des exemples de commandes, classés par catégorie.