Comment construire une application mobile pour passes numériques et cartes d'accès

Définir le type de pass (et le workflow réel)

Écrivez ce qui se passe de bout en bout, incluant qui approuve et à quoi ressemble le « succès » à la porte.

Par exemple :

• Badge d'accès : lié à une personne ; nécessite un déverrouillage rapide ; révocation immédiate lors d'un offboarding.
• Pass d'adhérent : peut privilégier une inscription et un renouvellement simples plutôt qu'un contrôle d'accès strict.
• Billets : scan à haut débit, anti-duplication, fenêtre de validité courte.
• Pass visiteur : parrainé par un employé ; expire automatiquement ; peut être limité à certaines zones.

Identifiez les utilisateurs principaux (pas seulement les « utilisateurs finaux »)

Listez les personnes qui interviennent dans le système et leurs objectifs :

• Employés/clients/visiteurs : installation simple, entrée fiable, faible friction.
• Admins/personnel sécurité : émettre, révoquer, auditer, gérer les exceptions (téléphone perdu, entrée refusée).
• Personnel d'accueil/équipe événementielle : vérification rapide et dépannage en période d'affluence.

Choisissez des métriques de succès mesurables

Choisissez des métriques qui correspondent à l'expérience utilisateur et aux opérations :

• Taux d'activation : % d'utilisateurs invités qui ajoutent/activent le pass.
• Taux d'ouverture de porte : unlocks/scans réussis au premier essai.
• Temps jusqu'à émission : du moment de la demande/approbation au credential utilisable.
• Tickets support : volume, raisons principales, temps de résolution.

Décidez tôt de l'accès hors ligne (et de ses limites)

Si les portes ou scanners doivent fonctionner sans connectivité réseau, définissez combien de temps l'accès hors ligne reste valide (minutes, heures, jours) et ce qui se passe lorsqu'un pass est révoqué alors que le lecteur est hors ligne. Ce choix influence la conception des credentials, la configuration des lecteurs et votre modèle de sécurité.

Choisissez comment le pass sera présenté : QR, NFC et solutions de secours

Votre « pass numérique » n'est utile que lorsqu'il est scanné ou tapé. Avant de concevoir les écrans, décidez ce que le lecteur acceptera et ce que les utilisateurs peuvent présenter de manière fiable dans des conditions réelles (foule, mauvaise connectivité, temps froid, gants).

Options courantes de présentation (et leurs forces)

Codes QR : universels et peu coûteux : tout scanner basé caméra — ou même la caméra d'un téléphone pour une vérification visuelle — peut fonctionner. Ils sont plus lents par personne que le tap, et plus faciles à copier si vous vous fiez à des codes statiques.

NFC (tap) : se rapproche d'un badge physique. Rapide et familière, mais dépend des lecteurs de porte compatibles et du support des appareils. Il existe aussi des contraintes de plateforme (par exemple, si vous pouvez émuler une carte ou devez utiliser des credentials basés sur Wallet).

Bluetooth (hands-free) : améliore l'accessibilité et la vitesse, mais est plus complexe à régler (portée, interférences) et peut générer des moments « pourquoi ça ne s'est pas ouvert ? ».

Liens à usage unique / codes in-app (codes tournants, tokens signés) : bons recours et peuvent réduire le risque de clonage. Ils exigent une logique dans l'app et, selon la conception, peuvent nécessiter un accès réseau périodique.

Cartographiez la technologie à vos contraintes

Associez chaque méthode à : matériel lecteur existant, débit (personnes/minute), besoins hors ligne, budget, et charge de support. Exemple : des tourniquets à fort trafic demandent souvent la vitesse du NFC ; des entrées temporaires d'événement peuvent tolérer le QR.

Choisissez une méthode primaire et une solution de secours délibérée

Un modèle pratique est NFC en primaire + QR en secours. Le NFC gère la vitesse ; le QR couvre les téléphones plus anciens, le NFC cassé ou les sites sans lecteur NFC.

Planifiez les scénarios de « mauvais jour »

Documentez exactement ce qui arrive quand :

• Téléphone verrouillé : le pass peut-il être présenté depuis l'écran de verrouillage (Wallet), ou l'utilisateur doit-il déverrouiller l'app ?
• Pas de réseau : le credential est-il vérifiable hors ligne (token signé, droit mis en cache), et pendant combien de temps ?
• Batterie faible / téléphone mort : offrez-vous un QR imprimé temporaire, un contournement sur site ou une carte physique de secours ?

Ces décisions orientent l'intégration des lecteurs, la posture de sécurité et le playbook support utilisateur.

Décidez : passes in-app vs Apple Wallet et Google Wallet

Choisir où « vit » le credential est une décision tôt car cela impacte l'intégration des lecteurs, l'expérience utilisateur et les contraintes de sécurité.

Option A : passes in-app (dans votre application)

Un pass in-app est rendu et géré par votre application. Cela vous donne un contrôle maximal sur l'UI, l'authentification, l'analytics et les workflows personnalisés.

Avantages : branding complet et écrans personnalisés, auth flexible (biométrie, prompts step‑up), contexte riche (plans de site, instructions), et meilleur support de plusieurs types de credentials.

Inconvénients : l'utilisateur doit ouvrir votre app (ou utiliser un widget/action rapide que vous créez), l'accès depuis l'écran de verrouillage est limité par l'OS, et le comportement hors ligne est entièrement à votre charge.

Option B : passes Apple Wallet / Google Wallet

Les passes Wallet (par exemple PKPass sur iOS) sont familiers et conçus pour une présentation rapide.

Avantages : grande confiance et découvrabilité, accès depuis l'écran de verrouillage, gestion système optimisée pour la présentation, et comportement rapide « montrer le code ».

Inconvénients : contraintes de plateforme (formats de barcode/NFC supportés, UI limitée), les mises à jour suivent les règles du Wallet, et vous pouvez avoir besoin de configurations spécifiques Apple/Google (certificats, configuration d'émetteur, parfois revue). La télémétrie approfondie est aussi plus difficile.

Règle pratique de décision

Utilisez Wallet quand la rapidité, la familiarité et la disponibilité « toujours accessible » comptent (visiteurs, événements, workflows simples par code-barres). Utilisez in-app quand vous avez besoin de contrôles d'identité plus stricts, de workflows riches ou d'une logique de credential complexe (accès multi-sites du personnel, approbations, rôles).

Plusieurs types de pass, templates et branding

Si vous servez plusieurs organisations, prévoyez des templates par organisation : logos, couleurs, instructions et champs de données différents. Certaines équipes livrent les deux : un pass Wallet pour l'entrée rapide et un credential in-app pour l'administration et le support.

Cycle de vie du pass à supporter

Indépendamment du conteneur, définissez les actions de cycle de vie que vous pouvez déclencher :

• Issue (inscription initiale)
• Update (nom, niveau d'accès, expiration, changements visuels)
• Suspend (mise en pause temporaire)
• Revoke (retrait permanent)
• Re-issue (nouvel appareil, téléphone perdu, suspicion de compromission)

Gardez ces opérations cohérentes entre in-app et Wallet pour que les équipes opérations gèrent les accès sans solutions de contournement manuelles.

Concevez le modèle de données et le cycle de vie des passes

Un modèle de données propre rend le reste du système prévisible : émettre un pass, le valider à un lecteur, le révoquer et enquêter sur des incidents doivent être des requêtes simples, pas des conjectures.

Entités principales à modéliser

Commencez par un petit ensemble d'objets « première classe » et étendez uniquement si nécessaire :

• Utilisateur : la personne devant obtenir l'accès.
• Organisation / Site : qui possède le système (et où l'accès s'applique).
• Pass : la « carte » vue par l'utilisateur (ce que l'app ou le wallet affiche).
• Credential : le token présenté à un lecteur (credential NFC, payload QR, etc.). Un pass peut avoir plusieurs credentials au fil du temps.
• Appareil : l'instance téléphone qui détient ou affiche le credential.
• Lecteur / Porte : le point physique (ID lecteur, ID porte, localisation).
• Politique d'accès : règles qui lient utilisateurs/groupes aux portes et aux horaires.

Cette séparation aide quand un utilisateur change de téléphone : le pass peut rester conceptuellement le même tandis que les credentials tournent et les appareils changent.

États du pass et cycle de vie

Définissez des états explicites et autorisez uniquement des transitions délibérées :

• pending (invité/en cours d'inscription)
• active (utilisable)
• suspended (bloqué temporairement)
• expired (fin temporelle atteinte)
• revoked (invalidé définitivement)

Exemple de transitions : pending → active après vérification ; active → suspended pour violation de politique ; active → revoked à la fin d'un emploi ; suspended → active après restauration admin.

Identifiants et mapping aux lecteurs

Prévoyez des IDs uniques à deux niveaux :

• Un pass_id stable (interne) pour le cycle de vie et le support.
• Un ou plusieurs credential_id / token_id que les lecteurs peuvent valider.

Décidez comment les lecteurs associent des tokens aux règles d'accès : lookup direct (token → utilisateur → politique) ou token → groupe de politique (plus rapide en périphérie). Gardez les identifiants non devinables (aléatoires, pas séquentiels).

Logs d'audit : quoi enregistrer et où

Traitez les logs d'audit comme append-only et séparés des tables d'état courant. Enregistrez au minimum :

• issue (qui a émis, à qui, appareil, heure)
• scan (lecteur, résultat, code raison)
• deny (mismatch politique, expiré, révoqué, échec hors ligne)
• revoke/suspend/reactivate (acteur, justification, heure)

Ces événements deviennent votre source de vérité pour le dépannage, la conformité et la détection d'abus.

Construisez le flux d'inscription et d'émission du pass

Un projet de pass numérique réussit ou échoue sur l'expérience des « 5 premières minutes » : à quelle vitesse une vraie personne peut-elle s'inscrire, recevoir un credential et comprendre quoi faire ensuite.

Chemins d'inscription (choisissez 1–2 principaux)

La plupart des équipes mixent ces étapes selon la sécurité et la taille du déploiement :

• Lien d'invitation : un admin (ou le système RH) génère un lien limité dans le temps. L'utilisateur l'ouvre sur son téléphone et arrive directement dans le flux correct.
• Vérification email/SMS : envoi d'un code à usage unique pour confirmer le numéro ou l'email lié à l'identité.
• SSO : pour les employés, utilisez SAML/OIDC pour émettre le pass après connexion corporate.
• Approbation admin : pour les sites à haute sécurité, placez la demande en file d'examen (avec codes raison, horodatages et piste d'audit).

Un pattern pratique : lien d'invitation → vérification email/SMS → (optionnel) SSO → émission du pass.

Comment le pass est ajouté (et comment guider les utilisateurs)

Concevez l'émission pour que l'utilisateur n'ait pas à « deviner » :

• Pass in-app : le credential vit dans votre app ; vous contrôlez les mises à jour et l'UI. Utile quand vous avez besoin d'authentification personnalisée, de règles hors ligne, ou de comportements lecteurs spécifiques.
• Ajout au Wallet : proposez un bouton « Ajouter à Apple Wallet » / « Ajouter à Google Wallet » après vérification. Supportez aussi les deep links qui ouvrent l'écran d'ajout du Wallet depuis une invitation.
• Fallback QR d'invitation : sur site, permettez à une réceptionniste d'afficher un QR qui ouvre le lien d'inscription (pratique si l'utilisateur ne trouve pas l'email).

Rédigez un texte très clair : à quoi sert le pass, où il apparaîtra (app vs wallet), et quoi faire à la porte.

Changement d'appareil et règles de ré-émission

Planifiez cela tôt pour éviter une avalanche de tickets support :

• Nouveau téléphone : fournissez une réinscription en libre-service qui reverifie l'identité et réémet le pass.
• Appareils multiples : décidez si vous l'autorisez. Si oui, limitez le nombre et affichez les appareils actifs dans les paramètres.
• Appareil perdu : activez la révocation à distance instantanée, puis permettez la ré-émission après ré-vérification.

Messages utilisateurs pour les échecs réels

Rédigez des messages conviviaux et spécifiques pour :

• Accès refusé (et étape suivante : « Contacter la sécurité » vs « Réessayer après actualisation »)
• Pass expiré (inclure la date d'expiration et l'action de renouvellement)
• Problèmes de connectivité (expliquer ce qui fonctionne hors ligne et comment récupérer une fois en ligne)

Une bonne émission, ce n'est pas juste « créer un pass » — c'est un parcours complet, compréhensible et avec des chemins de récupération prévisibles.

Authentification et autorisation pour utilisateurs et admins

Les passes numériques ne valent que par la fiabilité de l'identité et des permissions qui les sous-tendent. Traitez authentification (qui vous êtes) et autorisation (ce que vous pouvez faire) comme des fonctionnalités produit de première classe.

Choisir une approche d'authentification

Adaptez la méthode de connexion à votre audience et au niveau de risque :

• Email + OTP : simple pour les consommateurs, moins de réinitialisations de mot de passe.
• Passwordless “magic link” : faible friction, mais exige une délivrabilité email fiable.
• SSO / identité enterprise (SAML/OIDC) : idéal pour employés, sous-traitants et campus ; lie l'accès aux politiques RH/IT.

Si vous supportez plusieurs tenants (organisations différentes), décidez tôt si un utilisateur peut appartenir à plusieurs tenants et comment il change de contexte.

Autorisation : rôles, scopes et traçabilité

Définissez des rôles en langage clair (par ex. Titulaire de Pass, Accueil, Admin Sécurité, Auditeur), puis mappez-les aux permissions :

• Qui peut émettre, ré-émmettre, révoquer ou suspendre des passes
• Qui peut voir les logs d'accès et exporter des rapports
• Qui peut modifier les règles de l'installation (groupes de portes, horaires)

Gardez les contrôles d'autorisation côté serveur (pas seulement dans l'UI), et journalisez chaque action sensible avec qui, quoi, quand, où (IP/appareil), plus un champ raison pour les actions manuelles.

Sessions, confiance d'appareil et confort utilisateur

Utilisez des tokens d'accès à courte durée avec refresh tokens, et supportez la ré‑entrée sécurisée via biométrie pour afficher le pass.

Pour les déploiements à plus haute sécurité, ajoutez le device binding afin qu'un credential soit valide uniquement sur l'appareil(s) enregistré(s). Cela rend aussi plus difficile l'utilisation d'un token copié ailleurs.

Garde‑fous admin qui réduisent les erreurs et les abus

Les outils admin nécessitent des protections supplémentaires :

• Workflows d'approbation pour émission en masse ou passes privilégiés
• Limits de débit sur les endpoints d'émission/ré-émission
• Alertes pour motifs inhabituels (par ex. beaucoup de passes émis au même domaine email, pics hors heures normales)

Documentez ces politiques dans un runbook interne et liez-les depuis l'UI admin (par ex. /docs/admin-security) pour que les opérations restent cohérentes.

Modèle de sécurité : empêcher le clonage, les captures d'écran et le rejeu

La sécurité des passes numériques consiste moins à « cacher le QR » qu'à décider ce que le lecteur est autorisé à faire confiance. Le modèle adapté dépend de la connectivité, des capacités du lecteur et de la vitesse de révocation nécessaire.

Que valide le lecteur ?

Vous avez typiquement trois patterns :

• Payload signé (validation hors ligne) : le QR/NFC contient un payload signé par votre système. Les lecteurs vérifient la signature localement, donc les portes fonctionnent hors ligne. C'est rapide, mais la révocation n'est effective qu'avec la mise à jour des lecteurs.
• Vérification serveur (validation en ligne) : le lecteur envoie le token scanné à votre backend pour approuver/refuser en temps réel. La révocation est immédiate, mais vous dépendez de la disponibilité et de la latence réseau.
• Hybride : les lecteurs vérifient d'abord une signature (pour bloquer les faux évidents), puis appellent éventuellement le serveur pour les zones à risque ou quand la connectivité est disponible.

QR : réduire le risque de capture d'écran et de rejeu

Les QR statiques se partagent et se screenshotent facilement. Préférez des codes tournants ou limités dans le temps :

• Utilisez un token à courte durée (ex. valable 15–60 secondes).
• Liezz‑le à un appareil/session quand possible (un screenshot retransmis ne validera pas ailleurs).
• Incluez des données anti-replay (timestamp + nonce) et faites que le backend rejette les tokens déjà utilisés si l'entrée unique est requise.

Si vous devez supporter la validation QR hors ligne, faites-leur être signés et limités dans le temps, en acceptant que la révocation en temps réel ne sera pas possible sans synchronisation des lecteurs.

NFC : protéger les clés sur l'appareil

Pour le NFC, planifiez où résident les secrets et comment ils sont utilisés :

• Stockez les clés de credential dans un stockage sécurisé matériel (Secure Enclave / Keystore quand disponible).
• Évitez d'exposer des identifiants longue durée sur NFC ; utilisez challenge‑response ou des clés de session dérivées si le lecteur le permet.
• Supposez l'existence d'appareils rootés/jailbreakés ; fiez-vous aux clés matérielles et aux règles côté serveur plutôt qu'à l'obfuscation d'app.

Vitesse de révocation : définissez l'exigence opérationnelle

Décidez à l'avance à quelle vitesse un pass révoqué doit cesser de fonctionner (secondes, minutes, heures). Cette exigence conditionne l'architecture :

• Secondes : vérifications en ligne (ou lecteurs en connexion constante) généralement requises.
• Minutes : synchronisations fréquentes des lecteurs + tokens à courte durée peuvent suffire.
• Heures : mises à jour périodiques acceptables pour des zones à faible risque.

Écrivez cela comme un SLO sécurité/ops car cela influe sur la configuration des lecteurs, la disponibilité backend et la réponse aux incidents.

Intégration avec lecteurs de portes et ACS

C'est l'endroit où vos passes numériques rencontrent le monde réel : tourniquets, contrôleurs de porte, lecteurs d'ascenseur et scanners d'accueil. Les choix d'intégration ici affectent la fiabilité, la rapidité et le comportement en cas de réseau tombant.

Choisissez le chemin de validation du lecteur

Parmi les chemins d'intégration courants :

• Lecteur → votre API (validation cloud) : le lecteur (ou son contrôleur) appelle votre endpoint de validation pour chaque tap/scan. Flexible, mais dépendant de la qualité réseau et nécessite une gestion serrée du débit.
• Lecteur → ACS existant : votre application émet un credential que l'ACS comprend, et l'ACS décide de l'autorisation. Moins de logique personnalisée aux portes, mais peut limiter ce que vous encodez.
• Lecteur → gateway locale (validation edge) : les lecteurs parlent à un service sur site qui valide localement et synchronise avec votre backend. Améliore la résilience et garde une latence prévisible.

Fixez des cibles de temps de réponse et de comportement hors ligne

Définissez des cibles tôt (par ex. « décision d'ouverture en < 300–500 ms »). Documentez aussi ce que « hors ligne » signifie pour chaque site :

• Si le réseau tombe, faites-vous fail closed (tout refuser) ou fail open pour certaines portes ?
• Supportez-vous des allowlists mises en cache au gateway/controller avec expirations courtes ?
• Comment journalisez-vous et synchronisez-vous les événements sans duplication ?

Documentez les points d'intégration (ne sautez pas les détails)

Notez les systèmes et données à aligner :

• Provisioning des badges : qui crée l'enregistrement personne et quand (système RH, système visiteurs, portail admin) ?
• Groupes d'accès et horaires : mappage des rôles aux portes, étages, fenêtres temporelles et règles de jours fériés.
• Inventaire portes/lecteurs : IDs de porte canoniques, localisations, types de lecteurs (NFC, QR) et contraintes de firmware du contrôleur.

Un simple diagramme « source de vérité » dans la doc interne économise des semaines plus tard.

Planifiez la surveillance et le diagnostic

Traitez les lecteurs comme une infra de production. Surveillez :

• Santé du lecteur : dernier ping, version firmware, état batterie/énergie (si disponible).
• Taux d'échec et latence : temps de validation p95, timeouts et retries.
• Raisons de refus : pass expiré, credential révoqué, hors horaire, porte inconnue, rejeu suspect.

Exposez ces métriques dans un dashboard ops et routez les incidents critiques à l'on-call. Un workflow « pourquoi ai-je été refusé ? » rapide réduit le support pendant le déploiement.

Architecture backend : APIs, signature et scalabilité

Un système de pass numérique vit ou meurt par son backend : il émet des credentials, contrôle la validité et enregistre rapidement et fiablement ce qui s'est passé quand des gens sont devant une porte.

APIs core (simples et versionnées)

Commencez par un petit nombre d'endpoints que vous ferez évoluer :

• POST /v1/passes/issue — créer un pass pour un utilisateur, renvoyer un lien d'activation ou le payload du pass
• POST /v1/passes/refresh — faire tourner des identifiants / mettre à jour des habilitations, renvoyer les données récentes du pass
• POST /v1/passes/validate — vérifier un token QR/NFC présenté à un lecteur (pour lecteurs en ligne)
• POST /v1/passes/revoke — invalider immédiatement un pass (téléphone perdu, accès terminé)
• POST /v1/events — journaliser les tentatives d'entrée et leurs résultats (accepté/refus/erreur)

Même si certaines validations ont lieu sur l'appareil ou le lecteur, conservez une API côté serveur pour l'audit, la révocation distante et les opérations d'urgence.

Signature et gestion des clés (et comment les faire tourner en toute sécurité)

Si vous supportez Apple Wallet (PKPass) ou d'autres payloads signés, traitez les clés de signature comme des secrets de production :

• Stockez les clés privées dans un KMS/HSM géré ; jamais sur des serveurs applicatifs ni dans des logs CI.
• Faites tourner les clés selon un calendrier et après incident ; supportez plusieurs clés publiques actives pour que les anciens passes continuent de fonctionner pendant la transition.
• Auditez chaque opération de signature (qui/quoi/pour qui/quand/quelle version de clé).

Un pattern pratique : un service de « signature » dédié avec une interface restreinte (par ex. “signer le payload du pass”), isolé du reste de l'application.

Conception pour la montée en charge lors des pics d'entrée

Les pics d'entrée sont souvent prévisibles (9h00, début d'un événement). Prévoyez des lectures en rafales :

Utilisez du caching pour les listes de révocation et les recherches d'habilitation, ajoutez des retries avec clés d'idempotence pour l'émission, et mettez en file le travail non critique (analytics, notifications) pour que la validation reste rapide. Si les lecteurs se connectent en ligne, évitez les dépendances chatties pour garder la latence basse.

Confidentialité et rétention des logs

Minimisez les données personnelles stockées : préférez des IDs internes plutôt que des noms/emails dans les enregistrements de pass et d'événements. Définissez la rétention à l'avance (ex. garder les logs d'entrée 30–90 jours sauf obligation contraire), et séparez les logs opérationnels des logs sécurité/audit avec des contrôles d'accès plus stricts.

UX mobile : configuration, affichage et accessibilité

Un pass numérique réussit sur l'écran que les gens voient à la porte. Optimisez pour trois moments : configuration initiale, « montrer mon pass maintenant » et « il y a un problème — aide rapide ».

Choisissez l'approche applicative

• Native (iOS/Android) : idéal pour les expériences NFC, l'intégration Wallet et des comportements système soignés.
• Cross‑platform (Flutter/React Native) : bon pour UI partagée et itération rapide, mais testez NFC, comportements en arrière-plan et handoffs Wallet tôt.
• Compagnon Web : fonctionne pour les programmes QR-only et les pilotes rapides, mais dépend davantage des permissions caméra et de la connectivité.

Si vous supportez Apple Wallet / Google Wallet, indiquez clairement si l'app reste nécessaire après le provisionnement. Beaucoup d'utilisateurs préfèrent « ajouter au wallet et oublier ».

Affichage du pass efficace sous pression

Concevez l'écran « présenter le pass » comme un boarding pass : immédiat, lisible, et impossible à mal lire.

• Rendu QR : code très contrasté avec zones de silence généreuses, verrouillage d'orientation si nécessaire, et invite « augmenter la luminosité ».
• UI NFC : état simple « Approchez du lecteur », indice animé de positionnement, et confirmation claire de succès.
• Deep links Wallet : fournissez une action en un tap « Ouvrir dans Wallet » / « Ouvrir dans Google Wallet » (redirigez l'utilisateur directement plutôt que de le laisser chercher).

Ne cachez pas le pass derrière des menus. Une carte persistante ou un bouton principal réduit les délais à la porte.

Accessibilité et clarté

Supportez Grande Police, Dynamic Type, labels pour lecteurs d'écran (« Code QR du pass d'accès ») et thèmes contraste élevé. Traitez les états d'erreur comme partie intégrante de l'UX : caméra bloquée, NFC désactivé, pass expiré, lecteur non répondant. Chacun doit inclure une correction en langage clair (« Autoriser la Caméra dans Réglages ») et une action de secours.

Cas limites à concevoir

Les fuseaux horaires et la dérive d'horloge sur l'appareil peuvent rendre les passes temporels « incorrects », affichez donc les heures avec le fuseau du lieu et un indicateur subtil « Dernière synchronisation ». Prévoyez aussi : mode avion, réception instable dans les halls, permissions révoquées (caméra/NFC), et modes accessibilité batterie faible. Un petit lien « Dépannage » vers /help/mobile-pass peut éviter des files de support aux heures de pointe.

Stratégie de test : appareils, lecteurs, hors ligne et cas d'abus

Tester une application de carte d'accès mobile, ce n'est pas seulement « est-ce que ça ouvre », mais « est-ce que ça ouvre tout le temps, sous pression ». Considérez les tests comme une exigence produit.

Construisez une matrice de test pratique

Commencez par une matrice reflétant ce que les utilisateurs portent et ce que vos portes utilisent :

• Appareils : mélange d'iPhone/Android anciens et récents, différentes tailles d'écran, caméras bas de gamme
• Versions OS : au moins la version majeure courante et la précédente
• Capacités : disponibilité NFC (et emplacement), vitesse d'autofocus caméra, luminosité, modes économie d'énergie
• Modèles de lecteurs : chaque firmware/version de lecteur que vous supportez, y compris tourniquets et scanners portables

Incluez les flows in-app et Wallet (Apple Wallet / Google Wallet), car le comportement PKPass et l'UI système peuvent différer de votre app.

Répétez des entrées en conditions réelles

Les scans parfaits de labo ne correspondent pas aux files d'entrée réelles. Effectuez des « rush tests » où 20–50 personnes présentent des passes rapidement, successivement, avec :

• Mauvaise luminosité et reflets
• Connectivité instable (Wi‑Fi perdu, LTE faible)
• Mode hors ligne (mode avion + redémarrage) pour confirmer les credentials mis en cache et l'aide UX

Mesurez le temps médian d'entrée, le taux d'échec et le temps de récupération (quoi fait l'utilisateur ensuite).

Validez les scénarios d'abus et d'échec

Testez activement :

• Tentatives de rejeu (réutilisation du même QR dans sa fenêtre de validité)
• Utilisation de captures d'écran et cas d'enregistrement d'écran
• Tentatives avec pass révoqué (refus immédiat après révocation serveur)
• Limits de débit et verrouillages après échecs répétés

Stagez comme la production

Maintenez un environnement staging avec lecteurs de test et trafic synthétique simulant des pics. Vérifiez l'émission, les mises à jour et les révocations sous charge, et assurez-vous que le logging permet de tracer « tap/scan → décision → résultat porte » de bout en bout.

Lancement, déploiement et exploitation continue

Un lancement réussi, c'est moins une grosse sortie qu'une entrée prévisible à chaque porte, chaque jour. Planifiez un rollout contrôlé, des chemins de support clairs et des métriques révélatrices des frictions.

Migrer des cartes physiques sans couper l'accès

La plupart des organisations adoptent un déploiement progressif :

• Groupe pilote (sécurité, facilities, un seul bureau/étage) pour valider lecteurs, onboarding et cas limites
• Période double-credential où les employés peuvent utiliser la carte physique ou le pass numérique. Fixez une date cible de fin, mais gardez des exceptions pour les sous-traitants ou appareils spéciaux.
• Formation et comms : instructions courtes « comment entrer », où tapper/scanner, que faire si le téléphone meurt, et comment demander de l'aide.

Playbooks support que vous utiliserez réellement

Créez des workflows simples et répétables pour le help desk et les admins :

• Téléphone perdu : révoquer immédiatement ; ré-émission sur nouveau device après vérification d'identité.
• Accès refusé : vérifier logs lecteur, statut du pass (active/expired), permissions utilisateur et horaires ; fournir un fallback temporaire si nécessaire.
• Changement d'appareil/mise à jour : réinscription libre-service avec limites de taux et override admin.
• Ré-émission : définissez quand faire tourner les identifiants vs ré-activer le même pass (important pour la prévention de fraude et la traçabilité).

Centralisez ces playbooks et liez-les depuis la console admin et les docs internes.

Instrumentation et métriques opérationnelles

Ajoutez de l'analytics reflétant la performance réelle d'accès, pas seulement les installations :

• Funnel d'activation : invitation → install → inscription → première entrée réussie
• Taux de succès scan/tap (par site, porte, modèle de lecteur)
• Temps d'entrée (médian et p95)
• Erreurs lecteurs et backend (timeouts, hors ligne, échecs de signature)

Utilisez ces métriques pour prioriser l'ajustement des lecteurs et la formation des utilisateurs.

Checklist de déploiement (publiez et réutilisez)

• Lecteurs vérifiés (NFC/QR) et fallback testés
• Rôles admin et contacts d'escalade définis
• Scripts support prêts (téléphone perdu, accès refusé, ré-émission)
• Dashboard analytics actif avec revue hebdomadaire
• Comms utilisateurs prêtes et moyen de demander de l'aide (/contact)
• Plan commercial et de montée en charge confirmé (/pricing)

Séparer pass et credential facilite les changements d'appareil et la rotation de credentials sans « perdre » l'identité ni l'historique.

Définissez qui peut déclencher chaque transition (utilisateur vs admin vs règle automatisée) et journalisez chaque changement avec acteur, horodatage et raison.

Prévoyez aussi la réinscription en libre-service pour un nouveau téléphone et la révocation à distance immédiate en cas de perte.

Même si une partie des validations a lieu sur l'appareil ou le lecteur, gardez une API de validation côté serveur pour l'audit, la révocation distante et les opérations « break glass ».

Pour la signature et la gestion des clés :

• Stockez les clés privées dans un KMS/HSM géré ; jamais sur les serveurs applicatifs ni dans les logs CI.
• Faites des rotations planifiées et supportez des clefs publiques actives multiples pour que les anciens passes restent valides pendant la transition.
• Auditez chaque opération de signature (qui/quoi/pour qui/quand/quelle version de clé).

Concevez pour la montée en charge : cachez les listes de révocation et les recherches d'habilitations, mettez en file le travail non critique (analytics, notifications) pour garder la validation rapide. Définissez des règles de rétention et minimisez les données personnelles conservées.

Si vous itérez vite, des outils comme Koder.ai peuvent aider à prototyper et livrer un système de pass bout en bout, puis exporter le code quand vous intégrerez un ACS ou une gateway sur site.

Prévoyez aussi les cas limites (décalage d'horloge, mode avion, permissions révoquées, batterie faible) et un lien de dépannage (/help/mobile-pass).

Documentez et publiez ces étapes pour réutilisation à chaque nouveau site.