Alternatives — migration de l’application et du client
Alternative à une application Hikvision : changer le client, pas les caméras
C’est dans l’application qu’une migration se ressent, même quand tout le matériel en dessous est terminé et fonctionne : votre équipe l’ouvre chaque matin, et c’est elle qui décide comment l’accès distant est atteint, qui possède un compte et ce qui se passe quand quelqu’un a besoin d’un extrait à minuit. Cette page couvre ce qui bouge réellement, ce qui reste derrière, et comment planifier le basculement pour que le site ne soit jamais aveugle. Nous publions nos propres spécifications et nos prix ; nous ne publions aucune affirmation sur les produits d’autres fabricants que nous ne pouvons pas documenter.
- Clients Seetong Cloud sur iOS, Android et Windows
- P2P et traversée NAT en un clic — pas d’IP fixe, pas de redirection de port
- Caméras intégrées via ONVIF, RTSP et GB28181
- Jusqu’à 38 comptes utilisateurs locaux sur l’enregistreur
Ce que le client tient réellement ensemble
Une application ressemble à une mosaïque de caméras, mais c’est en réalité trois choses empilées : le compte qui liste les appareils, la route par laquelle l’accès distant les atteint, et le modèle d’utilisateurs qui décide qui peut voir quoi. Changez l’application et les trois changent, c’est pourquoi une migration d’application mérite plus de planification que sa taille ne le suggère.
La route est la partie que l’on sous-estime. L’accès distant s’obtient de trois façons : pair à pair avec traversée NAT, qui n’exige ni adresse IP fixe ni configuration du routeur ; la redirection de ports, qui exige une adresse statique et une ouverture délibérée dans le pare-feu ; et l’accès local sur le même réseau. Notre plateforme utilise le P2P avec traversée NAT en un clic, la plus simple des trois pour un site disposant d’une connexion internet ordinaire, et elle continue de fonctionner quand le fournisseur d’accès change votre adresse du jour au lendemain.
Trois plateformes clientes, un seul compte
Les clients Seetong Cloud tournent sur iOS, Android et Windows, donc le même compte couvre l’agent sur un téléphone, le superviseur sur une tablette et la salle de contrôle sur un poste fixe. L’image en direct et la relecture des enregistrements sont les deux fonctions qui comptent le plus au quotidien, et toutes deux proviennent de l’enregistreur plutôt que des caméras individuelles, c’est pourquoi le client et l’enregistreur bougent ensemble.
Le visionnage mobile dépend aussi de ce que la caméra envoie. Chaque caméra émet un flux principal à 500–8000 kbps et un sous-flux à 50–2000 kbps, et un client mobile affiche normalement le sous-flux — plus petit, moins gourmand en données et parfaitement adéquat sur un écran de 6 pouces. Le flux principal en pleine résolution est ce que vous examinez en salle de contrôle et exportez quand quelque chose compte. Vérifier que les deux sont configurés délibérément, plutôt que laissés aux valeurs par défaut, fait partie des petits travaux qui font la différence entre un système auquel on fait confiance et un système dont on se plaint.
Ce qui est perdu quand le client change
Être franc là-dessus est plus utile qu’une liste de fonctions, alors voici ce qui ne survit pas à un changement de plateforme :
- Le compte et son historique. Les listes d’appareils, les dispositions enregistrées, les règles d’alerte, les réglages de partage et les préférences de notification sont configurés à neuf. Emportez un inventaire écrit de ce qui existe avant de commencer, sinon vous le reconstruirez de mémoire.
- Les extraits cloud et l’historique d’alertes détenus dans l’ancienne plateforme. Tout ce dont vous pourriez avoir besoin plus tard doit être exporté pendant que les deux systèmes tournent encore.
- Toute analyse intelligente propre à l’ancienne application. Les fonctions qui vivent dans le client plutôt que dans la caméra ne voyagent pas ; notre enregistreur propose la détection des visages, des plaques, des formes humaines, des véhicules et des chutes d’objets sur les canaux configurés, et c’est le plafond de ce que toute migration de client peut promettre.
- Un identifiant unique pour tout le parc, si certains appareils restent sur l’ancienne plateforme. Deux systèmes signifient deux comptes, sauf si vous déplacez aussi l’enregistreur en plus du client.
- La configuration des caméras depuis le téléphone. Si vous comptiez sur l’ancienne application pour modifier les réglages des caméras, faites ce travail avant le basculement — et notez les mots de passe. Après le changement, les réglages des caméras s’atteignent depuis l’interface de la caméra plutôt que depuis le client.
Une limite de marque à connaître tôt : le placement du logo couvre le carton extérieur, le boîtier de l’appareil, la page d’affichage des canaux et l’écran de démarrage, mais l’application cliente elle-même est fournie par la plateforme et ne peut pas être rebaptisée.
Changer le client sans changer les caméras
C’est la route que prennent la plupart des sites, et elle fonctionne comme toute migration menée par l’enregistreur : les caméras restent au mur, et le nouvel enregistreur tire leurs flux par le réseau. Chaque caméra publie un chemin RTSP standard et est découverte via ONVIF, donc elle apparaît comme un canal sur le nouvel enregistreur et, de là, dans le nouveau client. Rien dans les objectifs, les fixations, la commutation PoE ou les tirages de câble n’a besoin de changer.
Les deux choses à préparer sont les adresses et les identifiants. Donnez à chaque caméra une adresse fixe plutôt que de la laisser à DHCP, et rassemblez le nom d’utilisateur et le mot de passe de chaque appareil en un seul endroit avant le basculement. Ces deux travaux prennent une heure et évitent une soirée très désagréable. Une fois les caméras intégrées, la liste d’utilisateurs de l’enregistreur est mise en place — jusqu’à 38 comptes locaux — et les habitudes de travail se transfèrent une personne à la fois, en commençant par celle qui est de service la nuit du changement.
Une note sur le nom
Le client de cette gamme s’appelle Seetong Cloud. Nous le traitons pour ce qu’il est : la couche de compatibilité qui se tient entre vos caméras, votre enregistreur et votre téléphone. Ce n’est pas une marque que nous commercialisons, et elle n’apparaît pas sur ce site sous forme de page de marque. Ce qui compte commercialement est plus étroit — il enregistre les caméras via ONVIF, RTSP et GB28181, il atteint les appareils distants en P2P avec traversée NAT en un clic, et il tourne sur iOS, Android et Windows. Voilà les faits à comparer avec le client que vous utilisez aujourd’hui.
Le basculement, dans l’ordre
- Inventoriez les appareils, les comptes et les règles d’alerte de l’ancienne plateforme, et notez qui utilise quelle vue et sur quel appareil.
- Confirmez la route d’accès distant que vous voulez : P2P et traversée NAT pour la simplicité, ou mappage de ports si votre politique l’exige.
- Rassemblez les adresses et les identifiants des caméras, et fixez des adresses statiques sur les appareils qui seront intégrés.
- Intégrez un groupe pilote de quatre à six caméras et testez de bout en bout l’image en direct, l’image nocturne, les horodatages et la relecture.
- Créez les comptes utilisateurs sur l’enregistreur dans les rôles dont vous avez besoin, plutôt que de copier tout le monde dans un compte administrateur.
- Faites tourner les deux clients en parallèle pendant un cycle de conservation complet, pour que personne n’ait à faire confiance à un système qu’il n’a pas vu fonctionner.
- Coupez l’ancien accès en dernier, et conservez la méthode d’export documentée au cas où un ancien extrait serait nécessaire après le basculement.
Faites le basculement dans une fenêtre de maintenance, pas un lundi matin. Une migration de client planifiée pour un jeudi soir se règle en cinq minutes de conversation le vendredi ; une migration qui tombe pendant un changement d’équipe, c’est une semaine de réclamations.
Trois façons d’aborder une migration de client
Le client et l’enregistreur changent, les caméras restent
La route standard. Les caméras sont intégrées à un nouvel enregistreur via ONVIF, RTSP ou GB28181, le nouveau client devient l’interface quotidienne, et l’installation physique n’est pas touchée.
- Quand l’utiliser
- Caméras saines, enregistreur ou client vieillissant, et une équipe qui a de nouveau besoin d’un accès distant fonctionnel sans projet d’investissement.
- Quand ne pas l’utiliser
- Parcs avec des caméras analogiques ou des modèles qui ne publient aucun flux standard — dans ce cas, la couche caméra doit changer d’abord.
Le client seul, l’enregistreur reste
Possible seulement si l’enregistreur lui-même prend en charge le client vers lequel vous migrez ou publie un flux standard vers une autre plateforme. C’est l’option la moins perturbante quand elle est disponible, et celle à vérifier en premier.
- Quand l’utiliser
- Sites dont l’enregistreur est actuel et fondé sur des standards, où la plainte porte sur l’application plutôt que sur l’enregistrement.
- Quand ne pas l’utiliser
- Enregistreurs verrouillés sur leur propre client sans interface standard. Là, le client et l’enregistreur bougent ensemble ou pas du tout.
Les deux clients, pendant une période de transition
L’ancienne application reste installée et connectée pendant un cycle de conservation complet tandis que la nouvelle prend le relais au quotidien. Personne n’a à renoncer à l’accès à des séquences dont il pourrait avoir besoin avant que le nouveau système n’ait gagné la confiance.
- Quand l’utiliser
- Sites avec des incidents en cours, des enquêtes ouvertes ou des obligations contractuelles qui rendent un trou de couverture inacceptable.
- Quand ne pas l’utiliser
- Sites avec des politiques de comptes strictes qui interdisent l’accès parallèle — là, planifiez une bascule stricte dans une fenêtre de maintenance.
Questions fréquentes
Quelle est l’alternative à l’application Hikvision ?
Le client livré avec cette gamme est Seetong Cloud, qui tourne sur iOS, Android et Windows, et la comparaison pratique n’est pas le nom de l’application mais les trois choses qu’elle doit faire. Elle doit atteindre vos caméras à distance — le nôtre le fait en P2P avec traversée NAT en un clic, donc aucune IP fixe et aucune redirection de port ne sont nécessaires. Elle doit afficher à la fois l’image en direct et la relecture des enregistrements depuis l’enregistreur. Et elle doit prendre en charge les comptes dont vous avez besoin, jusqu’à 38 utilisateurs locaux sur l’enregistreur. Confrontez toute application que vous envisagez à ces trois questions, et vérifiez comment elle traite les caméras que vous possédez déjà, car c’est là que la plupart des migrations réussissent ou échouent.
Puis-je voir mes caméras existantes dans une autre application ?
Si elles publient un flux standard ONVIF, RTSP ou GB28181, elles peuvent être intégrées à un enregistreur que ces clients lisent, et elles apparaîtront comme des canaux dans la nouvelle application. Si elles sont analogiques, ou verrouillées sur un protocole propriétaire sans flux standard, aucun changement de client ne les fera passer sans une couche d’encodage. Le test fiable prend dix minutes : essayez d’ouvrir un flux depuis la caméra à partir d’un ordinateur portable sur le même réseau, en utilisant le chemin RTSP documenté par le fabricant. Si cela fonctionne, un enregistreur fondé sur des standards pourra le tirer. Si cela ne fonctionne pas, interrogez-nous avant de planifier la migration.
Comment fonctionne l’accès distant — ai-je besoin d’une IP fixe ou d’une redirection de port ?
Notre plateforme atteint les appareils distants en P2P avec traversée NAT en un clic. En clair, l’enregistreur établit une connexion sortante vers la plateforme et le client l’y rejoint, donc vous n’avez pas besoin d’une adresse IP publique statique et vous n’avez pas à ouvrir de ports dans le routeur. Cela compte sur une liaison internet professionnelle ordinaire, où l’adresse peut changer sans prévenir et où un port ouvert est une question de sécurité permanente. Si votre politique informatique préfère la redirection de ports ou un VPN, l’enregistreur publie aussi du RTSP standard et prend en charge l’accès par mappage de ports, donc les deux approches peuvent fonctionner — la différence tient seulement à ce que votre équipe réseau doit maintenir.
Quelles fonctions cessent de marcher après le basculement ?
Tout ce qui appartenait à l’ancien compte plutôt qu’aux caméras : listes d’appareils, dispositions multi-caméras enregistrées, règles d’alerte, réglages de notification, liens de partage et historique des extraits cloud. Les fonctions qui vivent dans le logiciel de l’ancien client — sa propre recherche intelligente ou ses propres analyses — ne voyagent pas non plus. Ce qui continue de fonctionner, c’est la vidéo elle-même, parce qu’elle vient des caméras via un flux standard, plus la détection côté enregistreur que propose notre plateforme : visages, plaques d’immatriculation, formes humaines, véhicules et chutes d’objets, aux côtés de la détection de mouvement ordinaire. Prévoyez une reconstruction de la couche de configuration plutôt qu’une copie, et le changement ressemblera à de l’administration plutôt qu’à une perte.
L’application peut-elle être rebaptisée pour notre entreprise ?
Non. Le placement du logo sur cette gamme couvre le carton extérieur, le boîtier de l’appareil, la page d’affichage des canaux et l’écran de démarrage, et ces options sont disponibles sur commandes OEM. L’application cliente elle-même est fournie par la plateforme et garde son propre nom et son identité sur les boutiques d’applications, donc un projet OEM ne doit pas promettre à ses clients une application en marque blanche. Si une expérience mobile de marque est une exigence de votre appel d’offres plutôt qu’une préférence, dites-le dès le début pour que personne ne planifie autour d’un livrable qui n’existe pas — et si ce dont vous avez besoin est votre logo sur l’affichage des canaux et l’écran de démarrage, cette partie-là, nous pouvons la faire.
Combien de personnes peuvent utiliser le système en même temps ?
L’enregistreur prend en charge jusqu’à 38 comptes utilisateurs locaux, chacun avec ses propres identifiants, donc les services et les équipes n’ont pas à partager un identifiant. Cela compte plus qu’il n’y paraît : les identifiants partagés rendent impossible de dire qui a consulté ou exporté un extrait, et c’est la première chose qu’un auditeur ou un assureur demande. Côté visionnage, planifiez combien de personnes diffuseront en même temps et sur quelle connexion — une poignée de clients mobiles sur les sous-flux représente une charge très légère, tandis que plusieurs sessions de bureau simultanées sur le flux principal exigent une vraie capacité de liaison montante sur le site. Donnez-nous les chiffres et nous les vérifierons contre la conception.
Dois-je être sur site pour faire le changement ?
Généralement non. La migration est un travail réseau, donc elle peut se faire à distance pendant une fenêtre de maintenance, à condition que quelqu’un sur site puisse redémarrer un appareil si on le lui demande et confirmer ensuite que les caméras sont toujours en direct. Ce qui doit être organisé à l’avance, c’est l’accès : les identifiants des caméras, les réglages réseau de l’enregistreur et une fenêtre de maintenance convenue avec ceux qui utilisent le système la nuit. Ne tentez pas une migration de client pendant un changement d’équipe ou au milieu d’une enquête. Planifiez-la pour une heure calme, gardez l’ancien client installé jusqu’à ce que le nouveau ait tourné sur un cycle de conservation complet, et ayez une procédure de retour arrière écrite avant de commencer.
Planifiez le basculement du client avant qu’il n’ait lieu
Dites-nous ce que votre équipe utilise aujourd’hui, combien de comptes vous voulez et comment votre site accède à internet. Nous cartographierons la migration, confirmerons quelles caméras s’intègrent proprement, et vous dirons quoi exporter avant que l’ancien accès ne soit coupé.