Apprenez à planifier, construire et sécuriser une application mobile pour passes numériques et cartes d'accès avec QR et NFC : flux d'émission, tests et conseils de déploiement.
Avant de choisir QR vs NFC — ou Apple Wallet vs un pass dans l'application — définissez précisément ce que « pass numérique » signifie dans votre projet. Une seule application peut délivrer des badges d'employé, des identifiants de membre, des billets d'événement ou des passes visiteurs limités dans le temps, et chacun a des exigences différentes pour les vérifications d'identité, la révocation et la fréquence de changement des credentials.
Écrivez ce qui se passe de bout en bout, incluant qui approuve et à quoi ressemble le « succès » à la porte.
Par exemple :
Listez les personnes qui interviennent dans le système et leurs objectifs :
Choisissez des métriques qui correspondent à l'expérience utilisateur et aux opérations :
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é.
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).
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.
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.
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.
Documentez exactement ce qui arrive quand :
Ces décisions orientent l'intégration des lecteurs, la posture de sécurité et le playbook support utilisateur.
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é.
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.
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.
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).
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.
Indépendamment du conteneur, définissez les actions de cycle de vie que vous pouvez déclencher :
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.
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.
Commencez par un petit ensemble d'objets « première classe » et étendez uniquement si nécessaire :
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.
Définissez des états explicites et autorisez uniquement des transitions délibérées :
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.
Prévoyez des IDs uniques à deux niveaux :
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).
Traitez les logs d'audit comme append-only et séparés des tables d'état courant. Enregistrez au minimum :
Ces événements deviennent votre source de vérité pour le dépannage, la conformité et la détection d'abus.
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.
La plupart des équipes mixent ces étapes selon la sécurité et la taille du déploiement :
Un pattern pratique : lien d'invitation → vérification email/SMS → (optionnel) SSO → émission du pass.
Concevez l'émission pour que l'utilisateur n'ait pas à « deviner » :
Rédigez un texte très clair : à quoi sert le pass, où il apparaîtra (app vs wallet), et quoi faire à la porte.
Planifiez cela tôt pour éviter une avalanche de tickets support :
Rédigez des messages conviviaux et spécifiques pour :
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.
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.
Adaptez la méthode de connexion à votre audience et au niveau de risque :
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.
Définissez des rôles en langage clair (par ex. Titulaire de Pass, Accueil, Admin Sécurité, Auditeur), puis mappez-les aux permissions :
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.
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.
Les outils admin nécessitent des protections supplémentaires :
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.
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.
Vous avez typiquement trois patterns :
Les QR statiques se partagent et se screenshotent facilement. Préférez des codes tournants ou limités dans le temps :
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.
Pour le NFC, planifiez où résident les secrets et comment ils sont utilisés :
Décidez à l'avance à quelle vitesse un pass révoqué doit cesser de fonctionner (secondes, minutes, heures). Cette exigence conditionne l'architecture :
É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.
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.
Parmi les chemins d'intégration courants :
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 :
Notez les systèmes et données à aligner :
Un simple diagramme « source de vérité » dans la doc interne économise des semaines plus tard.
Traitez les lecteurs comme une infra de production. Surveillez :
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.
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.
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 passPOST /v1/passes/refresh — faire tourner des identifiants / mettre à jour des habilitations, renvoyer les données récentes du passPOST /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.
Si vous supportez Apple Wallet (PKPass) ou d'autres payloads signés, traitez les clés de signature comme des secrets de production :
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.
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.
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.
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 ».
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 ».
Concevez l'écran « présenter le pass » comme un boarding pass : immédiat, lisible, et impossible à mal lire.
Ne cachez pas le pass derrière des menus. Une carte persistante ou un bouton principal réduit les délais à la porte.
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.
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.
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.
Commencez par une matrice reflétant ce que les utilisateurs portent et ce que vos portes utilisent :
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.
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 :
Mesurez le temps médian d'entrée, le taux d'échec et le temps de récupération (quoi fait l'utilisateur ensuite).
Testez activement :
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.
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.
La plupart des organisations adoptent un déploiement progressif :
Créez des workflows simples et répétables pour le help desk et les admins :
Centralisez ces playbooks et liez-les depuis la console admin et les docs internes.
Ajoutez de l'analytics reflétant la performance réelle d'accès, pas seulement les installations :
Utilisez ces métriques pour prioriser l'ajustement des lecteurs et la formation des utilisateurs.
/contact)/pricing)Un pass numérique est la « carte » présentée par une personne pour entrer ou vérifier un droit (badge, identifiant membre, billet, pass visiteur). En pratique, il est soutenu par un ou plusieurs credentials (payloads QR, jetons NFC) que les lecteurs valident, ainsi qu'un cycle de vie (émission, mise à jour, suspension, révocation, réémission) que l'on doit pouvoir gérer opérationnellement.
Commencez par décrire le flux de bout en bout (demande → approbation → émission → entrée → audit), puis choisissez des métriques mesurables :
Ces métriques permettent d'ancrer « ça marche » dans des données opérationnelles.
Utilisez QR quand vous avez besoin de compatibilité large et d'un coût matériel faible (scanners caméra, vérifications visuelles) et que vous pouvez tolérer un débit moindre. Utilisez NFC quand vous voulez une expérience rapide « tap-to-enter » et que vous avez des lecteurs compatibles.
Une configuration pratique courante :
Décidez (et documentez) trois éléments :
Si vous avez besoin d'une révocation presque immédiate, vous devrez généralement exiger une ou des synchronisations très fréquentes des lecteurs/gateways.
Choisissez Wallet lorsque la présentation rapide et la disponibilité depuis l'écran de verrouillage comptent (visiteurs, événements, workflows simples par code-barres). Choisissez in-app lorsque vous avez besoin de workflows riches et de contrôles d'identité renforcés (approbations, accès multi-sites, authentification step-up).
Beaucoup d'équipes proposent les deux :
Modélisez au minimum ces entités :
Rendez les états explicites et les transitions délibérées :
pending → l'utilisateur est en cours d'inscriptionactive → utilisablesuspended → bloqué temporairementConcevez l'expérience des « 5 premières minutes » :
Évitez les codes statiques. Privilégiez :
Si vous devez valider hors ligne, acceptez que la révocation ne soit pas en temps réel et compensez par des fenêtres de validité courtes et des mises à jour périodiques des lecteurs.
Choisissez l'un des trois patterns :
Fixez des objectifs (ex. décision d'ouverture en < 300–500 ms), définissez le comportement hors ligne et surveillez le p95 de latence, les taux d'échec et les motifs de refus par modèle de lecteur/porte.
Démarrez avec un petit ensemble d'endpoints versionnés que vous pourrez faire évoluer :
POST /v1/passes/issue — créer un pass pour un utilisateur, renvoyer un lien d'activation ou le payload du passOptimisez pour trois moments : première configuration, « montrer mon pass maintenant » et « quelque chose ne va pas — récupérez-moi vite ».
Points clés :
Considérez les tests comme une exigence produit :
Mesurez le temps médian d'entrée, le taux d'échec et le temps de récupération pour prioriser améliorations et formation.
Un lancement réussi repose sur un déploiement contrôlé, des chemins de support clairs et des métriques révélatrices :
Séparer pass et credential facilite les changements d'appareil et la rotation de credentials sans « perdre » l'identité ni l'historique.
expired → la fenêtre temporelle est terminéerevoked → invalide définitivementDé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.
POST /v1/passes/refresh — faire tourner les identifiants / mettre à jour les droits, renvoyer les données de pass les plus récentesPOST /v1/passes/validate — vérifier un token QR/NFC présenté par un lecteur (pour lecteurs en ligne)POST /v1/passes/revoke — invalider immédiatement un pass (téléphone perdu, fin d'accès)POST /v1/events — journaliser les tentatives d'entrée et leurs résultats (accepté/refus/erreur)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 :
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).
/contact)/pricing)Documentez et publiez ces étapes pour réutilisation à chaque nouveau site.