1) Cas d’usage pris en charge
Avant l’arrivée : pré‑enregistrement → réservation d’un identifiant/badge (optionnel selon ACS).
À l’accueil : création du titulaire (visitor/holder), association d’un credential (numéro badge ou QR), affectation d’un profil d’accès et fenêtre de validité.
Pendant/fin de visite : suspension/modification éventuelle ; désactivation à la sortie ou à expiration.
2) Flux & données échangées (haut niveau)
Visitor → ACS
Titulaire : nom, prénom, e‑mail (selon politique), société, identifiant visite.
Credential : numéro (badge RFID) ou QR (si supporté par l’ACS).
Accès : profil/groupe, dates/horaires de validité, sites/portes cibles.
ACS → Visitor (selon connecteur)
Statut de création/activation, erreurs, journal d’opérations.
Le modèle de données exact dépend du connecteur choisi. Paramétrer la correspondance des champs côté Visitor.
3) Pré‑requis côté ACS
Compte/API dédié (moindre privilège) et FQDN/URL d’API.
Référentiels prêts : sites/bâtiments/portes, profils d’accès (visiteur), plages horaires.
Environnement de test (si possible) pour la recette d’intégration.
4) Paramétrage côté Hamilton Visitor
Activer le connecteur Contrôle d’accès et saisir URL/API key ou identifiants.
Définir les mappings :
Type de visite ↔ profil d’accès (ex. « Visiteur journée » → Profil V1).
Champs : nom, société, e‑mail, credential (numéro badge/QR).
Renseigner la politique de validité (début/fin, tolérances) et comportement à la sortie (désactivation immédiate).
Tester : création d’une visite témoin → vérifier la création ACS et l’activation aux dates prévues.
5) Sécurité & réseau
TLS 1.2+ vers l’API ACS ; si possible, restreindre par FQDN/IP.
Secrets : stockés chiffrés, rotation planifiée ; ne jamais les exposer dans les logs.
Pare‑feu : ouvrir uniquement les flux nécessaires (généralement HTTPS 443 ou ports éditeur). Voir Matrice des flux réseau.
6) Scénarios d’émission
Badge RFID : impression badge (visuel) + saisie/scannage du numéro RFID affecté.
QR d’accès : si l’ACS supporte les QR temporaires, utiliser le QR visiteur (imprimé ou mobile) comme credential.
7) Dépannage rapide
Droits non appliqués : vérifier le mapping “type de visite → profil” et la fenêtre (décalage horaire/NTP).
Badge non reconnu : contrôler le numéro saisi (zéro en tête, format) et l’antériorité du badge dans l’ACS.
Non‑désactivation à la sortie : vérifier l’événement de sortie côté Visitor et la tâche/webhook du connecteur.
Erreur API : certificat/TLS, proxy, comptes/permissions API insuffisantes.
8) Checklist Go‑Live
Profils d’accès et portes validés par la Sûreté.
Compte API dédié, droits moindre privilège, testé.
Mapping champs & types de visite documenté.
Scénarios de création/activation/désactivation testés.
Journalisation active et supervision des erreurs du connecteur.
Liens croisés
Visitor — Administration → Connecteurs (contrôle d’accès), Types de visite & politiques d’accueil, Modèles de badges.
Réseau & Impression (Visitor) → postes, imprimantes, iPad.
Matrice des flux réseau / Connexions sortantes → ports/FQDN.
Chiffrement & secrets → gestion des clés API, certificats.