SDK mobiles et web
Les SDK natifs pour iOS, Android, React Native et Flutter intègrent le flux dans votre application et sont la seule voie qui prend en charge le NFC. Les SDK web intègrent le flux dans votre frontend.
Des SDK natifs existent pour iOS, Android, React Native et Flutter ; les SDK web intègrent le flux dans votre frontend. Utilisez un SDK natif quand vous avez besoin du NFC ou du meilleur comportement caméra : une WebView ne vous donne ni l'un ni l'autre. Les résultats arrivent toujours par webhook, pas depuis le SDK.
#Pourquoi un SDK plutôt qu'une redirection
Une redirection hébergée demande le moins de travail et convient très bien à la plupart des flux. Un SDK vaut le coût quand :
- Vous avez besoin du NFC. La puce d'un passeport ou d'une carte d'identité ne peut pas être lue depuis une page de navigateur. Un SDK natif est la seule voie possible. Voir vérification par puce NFC.
- Vous ne voulez pas que l'utilisateur quitte votre application. Une redirection aller-retour est un vrai point d'abandon sur mobile.
- Vous voulez le meilleur comportement caméra. L'accès caméra natif est plus fiable que celui d'un navigateur, en particulier sur les appareils plus anciens.
#Ce qui est disponible
| Plateforme | Remarques |
|---|---|
| iOS | Distribué sous forme de XCFramework |
| Android | Distribué via Maven |
| React Native | Encapsule les modules natifs ; prend en charge la New Architecture |
| Flutter | Encapsule les modules natifs |
| JavaScript / web | Intègre le flux hébergé dans votre frontend web |
| Iframe in-context | Affiche le flux dans votre page plutôt que de rediriger |
- Choisissez votre plateforme et la page vous donne l'extrait de code de cette stack.
- Les SDK natifs et web, chacun avec son propre guide de démarrage rapide, sont liés ici.
Les exigences de version et les minimums de plateforme changent au fil des versions, donc consultez la documentation SDK actuelle plutôt qu'un instantané de page d'aide, et si vous utilisez une version de framework spécifique (un SDK Expo particulier, par exemple), confirmez la compatibilité avec votre contact Didit avant de vous engager sur un sprint.
#Une WebView n'est pas un SDK natif
Encapsuler le flux web hébergé dans une WebView donne l'impression d'offrir une expérience intégrée à l'application. Elle vous en donne l'apparence :
- Pas de NFC. La puce ne peut toujours pas être lue.
- Les permissions caméra sont plus difficiles. L'accès caméra d'une WebView dépend de la configuration de l'application hôte, et une mauvaise configuration produit exactement les signalements "la caméra ne s'est jamais ouverte" couverts dans corriger les problèmes de preuve de vie et de correspondance faciale.
- La langue est celle de l'application, pas celle de l'utilisateur. Une WebView rapporte la langue de l'application hôte, donc transmettez
languageexplicitement à la création de session. Voir définir la langue de vérification.
Si vous vous donnez la peine de faire un flux intégré à l'application, utilisez le SDK natif.
#Les résultats viennent toujours des webhooks
C'est ce qui piège les gens : le SDK indique à votre application que l'utilisateur a terminé le flux. Ce n'est pas la source faisant autorité pour la décision de vérification.
La décision est produite côté serveur après l'exécution des contrôles, et elle vous parvient par webhook. N'accordez jamais un accès en vous basant uniquement sur le callback de complétion du SDK : un signal côté client est trivialement falsifiable, et les contrôles peuvent même ne pas être terminés au moment où il se déclenche.
Traiter "le SDK a dit terminé" comme "l'utilisateur est vérifié" est l'erreur la plus lourde de conséquences possible dans une intégration mobile. Confirmez sur votre serveur, depuis le webhook ou l'endpoint de décision, avant de déverrouiller quoi que ce soit.
#Une seule application grand public, ou la vôtre ?
Il n'existe pas d'application Didit grand public distincte vers laquelle une session hébergée renverrait les utilisateurs pour une étape comme le NFC. Si vous voulez tout regrouper (NFC et non-NFC) dans une seule expérience d'application, cette application est la vôtre, avec le SDK intégré dedans.
#Distribution et conflits de dépendances
L'intégration du SDK natif entre parfois en collision avec d'autres dépendances d'une application hôte : une bibliothèque transitive partagée, ou une subspec qui fige une version que quelque chose d'autre fige aussi. Si cela vous arrive, c'est un problème concret et reproductible qu'il vaut mieux signaler avec votre manifeste de dépendances plutôt que de contourner en figeant une ancienne version : la correction appartient généralement au SDK.
#Tester sur un appareil
Le sandbox fonctionne de la même façon via un SDK que partout ailleurs : pointez l'application vers la clé d'une application sandbox et chaque contrôle est simulé et non facturé. C'est la bonne façon de répéter un flux mobile, car les comportements du SDK que vous devez le plus tester (invites de permission, cycle de vie de la caméra, mise en arrière-plan en pleine capture) sont des comportements de l'appareil que vous pouvez exercer à volonté sans frais. Voir tester en sandbox.