Guide d’architecture d’accès
Contrôle d’accès cloud ou serveur local?
Propriétaires, équipes TI et intégrateurs : comparez l’hébergement du logiciel de contrôle d’accès, son entretien et le comportement des entrées lors d’un problème de connexion. Comparez les offres cloud et locales, y compris les systèmes hybrides qui combinent gestion cloud et fonctionnement local hors ligne.
L’architecture suit les opérations
Commencez par l’équipe qui exploite le système et par le comportement attendu du site.
La différence principale concerne l’hébergement du logiciel de gestion et la responsabilité de son entretien. Dans le modèle cloud, le service de gestion est hébergé à distance; dans le modèle local, il fonctionne sur une infrastructure gérée pour l’organisation. Les deux dépendent des contrôleurs, lecteurs, serrures et alimentations retenus. Le fonctionnement local pendant une interruption doit être vérifié dans la conception des contrôleurs, quel que soit l’hébergement de la gestion.
Le contrôle d’accès hybride combine une gestion hébergée à distance et un fonctionnement local. Lexoh utilise cette architecture : gestion cloud et réseau maillé hors ligne permettent aux appareils du site de communiquer sans Internet. Les équipements locaux doivent rester alimentés. La gestion distante et les services externes ont leurs propres exigences de connexion.
Avant la liste de produits
Répondez à cinq questions avant de comparer les propositions.
Des réponses précises transforment un débat général d’architecture en projet que les fournisseurs et les équipes internes peuvent évaluer de façon cohérente.
-
Exploiter
Qui crée les identifiants d’accès, modifie les permissions, consulte les événements et traite les exceptions?
-
Connecter
Quels sites, portes, voies et réseaux doivent demeurer disponibles, et dans quelles conditions?
-
Gouverner
Où les données peuvent-elles être traitées ou conservées, et qui peut les consulter ou les exporter?
-
Intégrer
Quels systèmes sources et échanges documentés sont réellement requis?
-
Maintenir
Qui prend en charge les mises à jour, le cycle de vie, le suivi, les sauvegardes et la reprise?
Le système physique d’abord
Les portes, lecteurs et voies demeurent sur le terrain.
Quel que soit le modèle d’hébergement, la conception physique détermine comment un identifiant d’accès est présenté, comment la décision atteint l’équipement connecté et comment le site réagit à une exception.
Relevez les ouvertures, contrôleurs, lecteurs, serrures, barrières, alimentations, réseaux, interfaces de sécurité des personnes et responsabilités avant de considérer l’architecture logicielle comme réglée.
- Répertorier les contrôleurs, les lecteurs et les technologies d’identification qu’ils prennent en charge.
- Documenter le comportement local requis de chaque ouverture ou voie.
- Distinguer le contrôle d’accès des systèmes de sécurité des personnes et des procédures d’urgence approuvées.
- Définir les essais de mise en service pour les conditions normales et les exceptions.
Comparatif des responsabilités
Comparez qui exploite et entretient chaque composant.
Ce tableau sert à planifier un projet. Il décrit des questions à résoudre et des répartitions courantes de responsabilités; il ne décrit pas tous les produits et ne garantit aucun résultat.
Faites défiler le tableau horizontalement pour voir toutes les colonnes. Au clavier, sélectionnez le tableau puis utilisez les flèches gauche et droite.
| Décision | Modèle connecté au cloud | Modèle hébergé localement |
|---|---|---|
| Administration | L’administration centrale peut être offerte comme service hébergé. Portée à définir : séparation des organisations, rôles et responsabilités de soutien. | L’administration réside dans un environnement contrôlé par l’organisation ou son partenaire. Responsabilités d’exploitation : personnel et accès distant. |
| Connectivité | La synchronisation centrale et la gestion distante dépendent de la connexion conçue. Examiner le comportement local documenté de chaque appareil. | Des fonctions locales peuvent demeurer disponibles sur le réseau du site. Le multisite et l’accès distant exigent tout de même un réseau conçu. |
| Cycle de vie logiciel | Les responsabilités de mise à jour, d’entretien et de changement sont définies par l’entente de service et le matériel pris en charge. | L’organisation ou son partenaire gère habituellement le cycle de vie du serveur, de l’application et des dépendances. |
| Gouvernance des données | Revue du contrat : lieu d’hébergement, sous-traitants, conservation, accès, exportation et suppression. | Procédures d’exploitation : sécurité, sauvegardes, conservation et contrôles administratifs dans l’environnement de l’organisation. |
| Opérations multisites | Une plateforme hébergée peut offrir une vue partagée lorsque le produit et les permissions le permettent. | Une vue partagée dépend de l’application, de la topologie réseau et de toute conception de fédération ou d’hébergement central. |
| Intégrations | Vérifier chaque API ou connecteur documenté, le propriétaire des données et la limite de soutien. | Vérifier les interfaces locales, l’accès réseau, les versions prises en charge et la responsabilité du développement sur mesure. |
| Modèle de coût | Modéliser abonnements, connectivité, soutien, équipements, implantation et changements sur la période convenue. | Modéliser serveurs, licences, infrastructure, administration, sauvegardes, soutien, mises à niveau et renouvellement sur la même période. |
Comprendre une interruption
Distinguez la connexion à la gestion du point d’accès physique.
Commencez par nommer ce qui est indisponible. Un opérateur incapable de se connecter, un contrôleur qui ne communique plus et une porte présentant un problème physique sont des situations différentes. Un plan d’exploitation utile précise pour chacune le comportement attendu, le premier contact et la vérification du rétablissement. Le type d’hébergement ne répond pas à lui seul à ces questions.
Lors d’un exemple illustratif d’essai de réception, le fournisseur suit une procédure approuvée de perte de connexion à la gestion. L’opérateur consigne ce qui reste visible et l’installateur vérifie le comportement convenu à l’entrée retenue. L’équipe contrôle ensuite une modification d’identifiant, les événements disponibles et la reprise selon la procédure documentée. Elle distingue ainsi une entrée fonctionnelle d’un service de gestion entièrement rétabli.
Faites défiler le tableau horizontalement pour voir toutes les colonnes. Au clavier, sélectionnez le tableau puis utilisez les flèches gauche et droite.
| Situation | Ce que l’équipe doit établir | Preuve après rétablissement |
|---|---|---|
| Un opérateur ne peut pas utiliser le service de gestion | Si le problème touche son compte, son poste, sa connexion ou le service, et quelles actions restent disponibles. | Le rôle prévu peut se connecter et accomplir les actions administratives convenues. |
| Un contrôleur perd sa connexion à la gestion | Le comportement d’accès documenté du contrôleur retenu, les événements disponibles et le traitement des changements de configuration. | Les vérifications de connexion, configuration et événements réussissent; les changements non résolus ont un responsable. |
| L’ouverture ou son équipement local présente un problème | Le symptôme physique, les composants touchés et l’assistance approuvée; distinguer ce cas d’un problème de gestion seulement. | L’installateur qualifié confirme la réponse physique requise, puis l’opérateur termine les vérifications d’accès convenues. |
Architecture hybride Lexoh
Gestion cloud et communication locale hors ligne fonctionnent ensemble.
Lexoh Security Center peut présenter les sites, appareils, registres d’accès et contextes opérationnels configurés dans un même environnement. Les fonctions disponibles dépendent des équipements, des permissions et de la configuration du projet.
Lexoh combine la gestion cloud et un réseau maillé hors ligne permettant aux appareils du site de communiquer sans Internet. Les équipements doivent rester alimentés et disposer des permissions localement. Testez les accès configurés et la transmission des changements de permissions après reconnexion; la gestion distante et les services externes ont leurs propres besoins de connexion.
-
Vue centrale
Identifier les sites, appareils, registres et rôles qui doivent être réunis.
-
Comportement local
Documenter la gestion des décisions d’accès et des événements par chaque contrôleur lorsque la connectivité change.
-
Reprise
Documenter la synchronisation, les conflits et le suivi après le rétablissement du service.
-
Limite de service
Nommer qui surveille, modifie, soutient et approuve chaque partie du système.
Exemple illustratif d’exploitation
Suivez une demande en soirée dans deux immeubles.
Imaginez une organisation avec deux immeubles et une équipe d’entretien en soirée. Un gestionnaire demande de modifier l’horaire de l’immeuble A, tandis que l’immeuble B conserve ses heures. Avant de comparer les offres cloud et locales, précisez qui approuve la demande, qui la saisit, quelles entrées sont touchées et qui vérifie le résultat. Le même déroulement devient une démonstration utile pour les deux architectures.
Demandez à l’opérateur prévu d’effectuer ce changement avec son rôle et des identifiants d’essai représentatifs. Vérifiez la plage permise dans l’immeuble A et la règle inchangée dans l’immeuble B. Consultez ensuite le registre disponible et la procédure de relais au soutien hors des heures normales. Cette démarche montre mieux si l’organisation proposée convient à l’équipe qu’une démonstration réalisée uniquement avec un compte administrateur sans restriction.
-
Approbation
Consignez le site, les entrées, la plage horaire et la personne qui autorise le changement. Distinguez une exception temporaire d’un changement permanent d’horaire.
-
Administration
Démontrez l’action requise avec le rôle de l’opérateur et la configuration retenue. Réglez toute limite de site ou de compte que le produit proposé ne peut pas fournir.
-
Suivi
Nommez qui confirme le résultat, qui traite un refus d’accès et comment prend fin l’exception temporaire. Prévoyez le contact local si le soutien a besoin d’une personne à l’entrée.
Opérations hébergées localement
L’hébergement local est un engagement d’exploitation, pas seulement un emplacement de serveur.
Une conception hébergée localement peut convenir lorsque l’organisation possède des exigences ou contraintes qui la soutiennent. La décision doit tenir compte des personnes et procédures nécessaires pour maintenir l’environnement pendant tout son cycle de vie.
Clarifiez la propriété du serveur, le soutien logiciel, le suivi, les sauvegardes, la reprise, les mises à jour de sécurité, l’accès distant et le réseau multisite. Le contrôle local de l’infrastructure n’élimine pas ces responsabilités.
- Nommer l’équipe responsable du cycle de vie de l’application et de l’infrastructure.
- Documenter les essais de sauvegarde, de restauration et de reprise avec des responsables désignés.
- Définir l’accès administratif sécurisé du personnel interne et des partenaires de service.
- Planifier les mises à niveau et le renouvellement sans interrompre les opérations d’accès approuvées.
- Attribuer la responsabilité du soutien des intégrations lorsque les applications ou dépendances évoluent.
Évaluation des fournisseurs
Demandez les documents du système proposé.
Les affirmations de sécurité, de confidentialité, de disponibilité et d’intégration devraient être soutenues par la documentation, l’architecture, l’entente ou une preuve tierce actuelle qui s’applique exactement au service proposé.
-
Architecture
Composants déployés, flux de données, limites de confiance et comportement documenté des contrôleurs.
-
Sécurité
Identités, rôles administratifs, journaux, gestion des vulnérabilités, portée du chiffrement et responsabilités client.
-
Données
Emplacement, conservation, sauvegarde, exportation, suppression, sous-traitants et fin de contrat.
-
Opérations
Suivi, canaux de soutien, fenêtres d’entretien, communication d’incident et responsabilités de reprise.
-
Intégration
Interfaces documentées, versions, propriété des données, environnement d’essai et gestion des changements.
-
Modèle commercial
Une période d’évaluation commune avec tous les coûts d’implantation, de cycle de vie, de soutien et de sortie.
Compléter le comparatif
Transformez le tableau des responsabilités en entente d’exploitation.
Pour chaque ligne du comparatif, notez le service ou composant réel, son responsable et le document qui confirme l’entente. Distinguez l’exigence du propriétaire de l’engagement confirmé du fournisseur. Si une intégration, une exportation ou une étape de reprise reste à préciser, nommez qui doit répondre avant la réception.
Utilisez les questions ci-dessous pour relier la configuration proposée aux personnes qui l’exploiteront. Le guide de migration précise les questions sur les essais et la remise; le guide des coûts aide à clarifier ce que chaque proposition comprend.
-
Vérifier une remise administrative
Utilisez le rôle prévu de l’opérateur pour vérifier les actions convenues. Notez qui modifie les accès, gère les comptes, consulte les registres et approuve une exportation.
-
Consigner un exemple de reprise
Convenez de la configuration retenue et d’une condition d’essai approuvée par l’installateur. Notez le comportement local observé, les événements disponibles, les étapes de rétablissement et la vérification finale.
-
Préciser les limites de service
Nommez le contact pour le logiciel de gestion, le réseau, le contrôleur, l’ouverture et les intégrations. Consignez l’équipe responsable de la prochaine action lorsqu’un problème traverse ces limites.
Liste de vérification
Questions à poser sur l’entente d’exploitation du contrôle d’accès
Utilisez ces questions pour comparer la proposition cloud ou locale réelle. Demandez au fournisseur et à votre équipe qui prend chaque décision et quel document la confirme.
-
Où le logiciel de gestion sera-t-il hébergé et qui entretient cet environnement?
Demandez l’hébergement proposé et les responsabilités liées aux serveurs ou aux services hébergés. Confirmez le contact de soutien pour chaque partie du système.
-
Qui peut créer des identifiants, modifier les permissions et administrer les comptes?
Demandez les rôles d’opérateur prévus et les actions permises à chacun. Faites démontrer les limites d’un immeuble partagé ou de ses locataires avec des comptes représentatifs.
-
Que fait chaque contrôleur lorsque la connexion à la gestion est indisponible?
Demandez le comportement documenté de la configuration retenue, y compris décisions d’accès et événements disponibles. Précisez la vérification de ce comportement et du rétablissement.
-
Qui planifie, applique et vérifie les mises à jour logicielles et des appareils?
Confirmez les périodes d’entretien, l’information des opérateurs et les responsabilités de soutien. Demandez comment traiter une mise à jour échouée selon l’entente proposée.
-
Où sont conservées les données d’accès, qui peut les utiliser et que peut-on exporter?
Demandez les conditions d’hébergement, d’accès, de conservation et d’exportation applicables. Précisez formats, rôles autorisés et traitement des copies conservées à la fin de l’entente.
-
Quelles fonctions multisites et intégrations sont réellement incluses?
Demandez les sites couverts, interfaces, versions prises en charge et échanges de données. Identifiez qui entretient une intégration lorsqu’une application ou configuration change.
-
Qui traite un problème touchant plusieurs fournisseurs?
Demandez la procédure d’escalade pour la gestion, le réseau, le contrôleur, l’ouverture et les applications connectées. Confirmez le premier contact, les heures couvertes et le responsable de l’action suivante.
-
Quels frais récurrents et quelles responsabilités de sortie s’appliquent sur la période convenue?
Demandez la base de facturation, le soutien inclus, les renouvellements et les travaux d’infrastructure prévus. Confirmez transfert des comptes, accès aux données et responsabilités si l’entente prend fin.
Questions d’architecture
Remplacez les hypothèses par des réponses propres au projet.
Le contrôle d’accès cloud est-il toujours plus sécuritaire?
Aucune catégorie d’hébergement n’est sécuritaire par définition. Comparez l’architecture, les identités, les mises à jour, les journaux, les données, les pratiques opérationnelles et les responsabilités de chaque proposition.
L’accès continue-t-il pendant une panne Internet?
Lexoh prend en charge le fonctionnement hors ligne grâce à un réseau maillé qui permet aux appareils du site de communiquer sans Internet. Les accès dépendent de l’alimentation des équipements et des permissions disponibles localement. Lors de la réception, testez des identifiants valides, expirés et révoqués, puis vérifiez les contrôleurs concernés après reconnexion. Pour tout fournisseur, distinguez accès local, gestion distante et services externes dans le comparatif des pannes.
Quel modèle coûte le moins cher?
Il n’existe pas de réponse universelle. Bâtissez un modèle comparable avec les équipements, l’implantation, les abonnements ou licences, l’infrastructure, la connectivité, l’administration, le soutien, les mises à niveau, la conservation et la sortie sur la même période.
Les deux modèles peuvent-ils s’intégrer aux systèmes existants?
Potentiellement. La portée doit préciser le système source, le flux requis, les interfaces documentées, les versions prises en charge, l’authentification, la responsabilité et le soutien à long terme avant de considérer l’intégration comme incluse.
Comment évaluer la portabilité des données?
Demandez quelles données peuvent être exportées, dans quel format documenté, par qui, à quel moment du contrat et comment les copies conservées sont traitées après la fin de l’entente.
Comment organiser une migration entre deux modèles d’hébergement?
Commencez par inventorier les contrôleurs, moyens d’identification, permissions et applications connectées. Vérifiez les données et interfaces acceptées par la destination, puis convenez d’une entrée pilote, d’une période de transition, des essais de réception et d’une procédure de retour à l’ancien système. Associez le responsable du système actuel et les opérateurs pour maintenir des responsabilités et une assistance claires pendant la transition.
Qui est responsable des mises à jour logicielles planifiées?
L’entente d’exploitation proposée doit préciser qui planifie, applique et vérifie les mises à jour du service de gestion, de l’infrastructure locale et des appareils terrain. Demandez comment informer les opérateurs, quelles fonctions peuvent être touchées et comment traiter un échec. Comparez ces responsabilités explicitement; le mode d’hébergement ne les attribue pas à lui seul.
Quelles informations aident le soutien à distinguer un problème de porte d’un problème de connexion?
Fournissez le site, la référence de l’entrée, l’heure, la réponse physique observée et l’état de l’appareil visible par l’opérateur autorisé. Précisez si le problème touche une entrée, plusieurs appareils ou seulement un compte de gestion. Transmettez le registre utile par le canal convenu, sans détails personnels inutiles. Ce contexte aide les équipes à enquêter; un état au tableau de bord ne suffit pas à établir la cause d’un problème physique.
Comment vérifier les changements demandés pendant une interruption après le rétablissement?
Conservez les demandes de changement autorisées et identifiez celles que le système retenu a confirmées, différées ou laissées non résolues. Après le rétablissement, l’opérateur responsable rapproche cette liste de la configuration convenue et vérifie les identifiants ou horaires touchés selon la procédure d’essai approuvée. Le fournisseur doit définir le traitement réel et la reprise; soumettre une modification ne prouve pas que chaque contrôleur l’a appliquée.
Références et lectures complémentaires
- Documentation des rôles et permissions LEXOH
Utilisez les rôles documentés pour définir et tester les responsabilités prévues des opérateurs.
- Gestion des appareils LEXOH
État des appareils et contexte d’exploitation des équipements retenus.
- Réglages des cartes d’accès LEXOH
Validité des identifiants, zones et horaires utilisés dans les exemples d’exploitation.
Examiner le modèle d’exploitation
Réunissez les portes, les responsabilités et les intégrations requises.
Lexoh peut aider à documenter la portée physique et les limites d’exploitation avant le choix de l’architecture.
Discuter du projet d’accès