Architecture

Architecture distribuée pour caméras, communauté, IoT et IA

Horus s'organise comme une architecture de service distribuée : les caméras et capteurs restent sur chaque site, l'expérience mobile permet d'opérer depuis n'importe où, l'edge peut exécuter des charges proches du point de capture et l'environnement cloud coordonne identités, permissions, notifications, scénarios et intégrations.

Chaque instance Horus représente un environnement autonome. Les relations entre dispositifs, utilisateurs, groupes, calendriers, permissions et automatisations existent dans cette instance, ce qui garantit l'indépendance opérationnelle et la sécurité logique entre différentes installations ou clients.

Couches connectées de l'écosystème

Horus by Fidumtec est plus qu'une application, une solution IoT ou un système de caméras. C'est une plateforme distribuée composée de couches connectées :

1. Terrain : caméras, capteurs, actionneurs, dispositifs physiques et infrastructure installée.
2. Gateway / edge local : gateways, adaptateurs, protocoles de terrain et traitement proche du site.
3. ISP / edge opérateur : réseau de l'ISP, datacenter, edge régional, stockage, GPU, enregistrement et inférence.
4. Horus Cloud : identité, instances, utilisateurs, permissions, règles, tableaux de bord, événements et multi-tenancy.
5. IA et automatisation : analyse vidéo, événements intelligents, règles, scénarios et actions automatiques ou assistées.
6. Expérience mobile / Clipxu : visualisation, alertes, opération sur le terrain et interaction des utilisateurs.

Les points 4, 5 et 6 permettent à la logique centralisée de l'architecture de coexister de manière distribuée sur plusieurs plateformes. Horus Cloud ne se comprend plus comme un cloud unique : il fonctionne comme un réseau de clouds, qu'il s'agisse de clouds purs, de clouds opérateur ou de déploiements ISP connectés.

Connexion par instance et opération multi-cloud

Chaque instance Horus appartient à un noeud cloud déterminé. Ce noeud peut être associé à un ISP, à une région cloud spécifique ou à un cloud opéré dans une architecture distribuée. La connexion ne se résout pas contre un cloud global unique, mais contre le noeud cloud où vit l'instance à opérer.

Dans l'application mobile Clipxu, l'utilisateur se connecte au noeud cloud où est enregistrée l'instance Horus qu'il configure ou opère. S'il change d'instance, la configuration active pointe vers le noeud cloud correspondant à cette nouvelle instance.

Dans un dashboard, le comportement est différent : chaque moniteur peut représenter la visualisation ou le contrôle d'un élément Horus différent. Les connexions du dashboard se font donc contre le noeud cloud auquel appartient l'instance Horus de chaque élément surveillé. Un même dashboard peut opérer, en parallèle, des éléments hébergés dans des clouds ISP, des régions cloud ou des noeuds cloud différents.

Vision : une plateforme technologique unique

La capacité du backend n'est pas définie par la taille d'une interface ni par le nombre de caméras habituellement gérées par un utilisateur. Horus a été conçu comme une plateforme multi-tenant où chaque instance conserve son autonomie, ses utilisateurs, permissions, dispositifs et règles, tandis que le traitement horizontal évolue avec la capacité de calcul disponible.

Le même Core peut prendre en charge une caméra, une communauté, une entreprise multisite ou des milliers d'instances opérant en parallèle. Il n'existe pas de backends « petits » et « grands » : il existe une plateforme commune qui distribue les charges, maintient l'isolation entre les environnements et augmente les ressources sans fragmenter l'architecture.

La simplicité est une décision d'expérience

Horus masque la complexité technique afin de simplifier la mise en service et l'opération quotidienne. La découverte des dispositifs, les assistants de configuration, les automatisations et la navigation directe sont des décisions produit ; elles ne constituent pas des limites du Core.

Lorsqu'une opération passe de dizaines à des milliers de caméras, le modèle de travail doit évoluer. Une entreprise ou un centre de supervision a besoin de recherches avancées, de filtres complexes, d'actions en masse, de hiérarchies, de tableaux de bord opérationnels, de permissions d'entreprise, d'audit et de gestion par site, région ou agence.

La différence ne réside pas dans le traitement. Ce qui change, c'est :

• L'interface présentée à l'utilisateur.
• Les outils mis à disposition.
• Les workflows de configuration, supervision et réponse.
• Le niveau d'agrégation et de gouvernance opérationnelle.

Modes d'opération et périmètre

Tous les modes utilisent le même backend. Une expérience spécialisée peut évoluer sans dupliquer les services, séparer artificiellement les données ni créer une plateforme parallèle.

Architecture hybride : traiter là où la valeur est maximale

Les caméras restent sur le site du client et se connectent de manière sécurisée à l'infrastructure de service. Selon le besoin, les modules peuvent s'exécuter sur l'edge local, dans un environnement intermédiaire à faible latence et disposant de bande passante, ou dans le cloud. Cette flexibilité permet d'équilibrer latence, trafic, coût, disponibilité et gouvernance.

Le streaming est protégé depuis la gateway jusqu'à la couche d'accès. Des processus spécialisés consomment la vidéo autorisée et transforment les images en événements ou données ; le Core coordonne règles, notifications, scénarios et historiques, tandis que l'expérience mobile consomme l'information indépendamment de son lieu de production.

Un Core, différentes expressions de l'écosystème

Les « saveurs » de Horus ne sont pas des backends incompatibles. Ce sont différentes manières d'exploiter le même noyau technologique :

• Horus réunit communauté intelligente, caméras, IoT, permissions et automatisation.
• HorusSense oriente la plateforme vers l'analytique, l'IA et l'intelligence métier.
• Clipxu fournit l'expérience mobile pour la visualisation, les alertes et l'opération.
• Fidumtec intègre et soutient institutionnellement l'écosystème et ses verticales.

Cette séparation permet d'adapter la proposition commerciale et l'expérience sans fragmenter le développement du backend. Le Core reste unique ; chaque expression sélectionne les capacités, interfaces et workflows adaptés à son contexte.

1. Caméras et sites

• Les caméras sont incorporées à l'aide de standards comme ONVIF.
• Un même utilisateur peut opérer ses propres caméras ou des vues partagées par des tiers.
• La plateforme évite de dépendre du cloud propriétaire de chaque fabricant.

2. Cloud, edge et expérience mobile

• Administre utilisateurs, groupes, caméras, permissions et communautés.
• Définit des fenêtres d'accès 24/7 ou des permissions temporaires avec date de début et de fin.
• Coordonne des notifications spécifiques vers les utilisateurs liés.
• Maintient des tableaux de bord personnalisés selon les permissions de chaque utilisateur.
• Permet à Clipxu d'agir comme expérience mobile de visualisation, d'alertes et d'opération.
• Expose la base pour des déploiements comme ISP, IoT, communautés et infrastructure critique.

3. Capteurs, actions et IA

• Intègre des capteurs IoT sélectionnés pour compléter l'information des caméras.
• Peut exécuter des actions physiques à distance avec des dispositifs IoT.
• Traite des images vidéo avec des moteurs d'inférence pour générer des événements et de l'information utilisateur.
• Permet des règles fondées sur des événements, conditions logiques, états de capteurs, horaires, calendriers et présence d'utilisateurs.

4. Déploiements