L’API BiometricPrompt unifie l’authentification biométrique sur Android et standardise l’interface utilisateur système. Cette uniformisation réduit la fragmentation entre appareils et simplifie le travail des développeurs mobile.
La biométrie couvre aujourd’hui l’empreinte digitale et la reconnaissance faciale, et l’API supporte plusieurs scénarios d’authentification forte. Retrouvez l’essentiel dans la rubrique A retenir :
Standardisation de l’interface biométrique système
Compatibilité avec empreinte digitale et reconnaissance faciale
Intégration possible avec Keystore pour opérations cryptographiques
Gestion des erreurs et des cas de secours intégrée au framework
Du concept à l’API BiometricPrompt : composants et rôle sur Android
Cette section décrit comment l’API organise l’authentification et quels composants elle expose aux développeurs. Selon Android Developers, BiometricPrompt fournit un dialogue visuel système et des classes d’interaction documentées.
Architecture de BiometricPrompt et classes clés
Le noyau de l’API inclut des classes comme BiometricPrompt.Builder et BiometricPrompt.CryptoObject qui structurent le dialogue. Selon Android Developers, BiometricPrompt.AuthenticationCallback et AuthenticationResult gèrent les retours d’état et les données de session.
Le développeur initialise un BiometricPrompt et fournit un Executor pour recevoir les callbacks sur le bon thread. Cette organisation évite les fuites mémoire si le prompt est réutilisé correctement.
Code
Constante
Signification
12
BIOMETRIC_ERROR_HW_NOT_PRESENT
Capteur absent sur l’appareil
1
BIOMETRIC_ERROR_HW_UNAVAILABLE
Matériel temporairement indisponible
7
BIOMETRIC_ERROR_LOCKOUT
Verrouillage après tentatives échouées
9
BIOMETRIC_ERROR_LOCKOUT_PERMANENT
Verrouillage permanent jusqu’à authentification forte
Points techniques API :
BiometricPrompt.Builder pour personnaliser le dialogue
AuthenticationCallback pour gérer réussite et erreurs
CryptoObject pour opérations chiffrées liées à l’authentification
« J’ai remplacé plusieurs implémentations maison par BiometricPrompt et la cohérence utilisateur s’est nettement améliorée. »
Alice D.
Comportement pratique et limites des callbacks
Le flux d’authentification se termine par onAuthenticationSucceeded ou onAuthenticationError selon le résultat. Selon Android Developers, l’appel authenticate réchauffe le matériel, affiche le dialogue et lance le scan biométrique.
Il est possible d’annuler l’opération via CancellationSignal et de réutiliser le BiometricPrompt sans recréer constamment l’objet. Cette pratique améliore la stabilité au gré des changements de configuration.
A lire également :5 paramètres à modifier d’urgence pour sécuriser votre Android
Mise en œuvre pratique de BiometricPrompt pour le développement mobile Android
Le passage de la théorie à la pratique exige des vérifications d’état et une gestion soignée des cas non enrôlés. Selon Android Developers, BiometricManager.from(context) permet de vérifier si l’appareil est prêt pour la biométrie.
Vérifier l’état et rediriger vers l’enrôlement
Avant d’appeler authenticate, il faut interroger BiometricManager.canAuthenticate pour connaître l’état du dispositif. Si l’utilisateur n’a rien enrôlé, il faut proposer l’ouverture des paramètres d’enrôlement adaptés au version SDK.
Étapes d’intégration :
Vérifier BiometricManager.canAuthenticate pour BIOMETRIC_STRONG
Rediriger vers Settings.ACTION_BIOMETRIC_ENROLL si nécessaire
Préparer un CancellationSignal et un Executor adapté
Construire PromptInfo avec setAllowedAuthenticators
Ces étapes gardent l’expérience fluide et évitent des échecs déroutants pour l’utilisateur. La redirection vers l’enrôlement reste dépendante de la version d’Android et mérite un message explicatif.
« J’ai vu moins d’abandons au moment de l’authentification après avoir ajouté un rappel d’enrôlement clair. »
Marc L.
Organisation du code : extraire un use case réutilisable
Un extract comme BiometricAuthUseCase réduit la duplication et maintient les activités légères et lisibles. Selon Android Developers, réutiliser BiometricPrompt prévient les problèmes liés aux changements de configuration.
Un modèle observable ou une interface Listener facilite l’intégration dans divers contrôleurs d’UI sans répéter la logique. Cette séparation renforce la testabilité et la maintenabilité du code.
Sécurité et limites de la biométrie : empreinte digitale et reconnaissance faciale
La biométrie améliore l’ergonomie mais elle soulève des questions de sécurité et de périmètre d’usage. Selon Android Developers, seuls les capteurs respectant le niveau Strong peuvent débloquer des opérations avec Keystore.
Bonnes pratiques pour l’authentification forte et la protection des clés
Il est recommandé d’utiliser Authenticators.BIOMETRIC_STRONG pour les opérations sensibles et de lier CryptoObject au Keystore. Cette contrainte évite que des méthodes peu fiables déclenchent des opérations cryptographiques protégées.
Bonnes pratiques sécurité :
Lier CryptoObject au Keystore pour opérations sensibles
Exiger BIOMETRIC_STRONG pour opérations cryptographiques
Préférer fallback device credential si nécessaire
Surveiller les erreurs de sécurité et appliquer mises à jour
Une mise en garde utile concerne les mises à jour de sécurité et les vulnérabilités constructeur possibles. En 2026, garder le capteur et le système à jour reste la meilleure défense contre les failles.
Erreurs utilisateur, UX et retours d’expérience
La gestion d’erreurs comme BIOMETRIC_ACQUIRED_IMAGER_DIRTY ou BIOMETRIC_ERROR_LOCKOUT influence fortement l’expérience finale. Un message clair et des options de secours évitent la frustration et réduisent le support technique.
« Après avoir affiché des conseils de nettoyage pour le capteur, les taux de réussite immédiats ont progressé chez nos utilisateurs. »
Sophie R.
« Le passage à BiometricPrompt a diminué les bugs liés aux dialogues custom et facilité la conformité. »
