Passer au contenu principal
Un plugin Flutter multiplateforme qui encapsule les SDK natifs iOS et Android et fournit une API Dart unifiée pour la vérification d’identité.

Dépôt GitHub

Consultez le code source et les exemples sur GitHub

Package pub.dev

didit_sdk

SDK natif : C’est l’approche recommandée pour les applications Flutter. Le SDK encapsule les SDK natifs iOS et Android via des canaux de plateforme pour offrir la meilleure expérience utilisateur, une gestion optimisée de la caméra et une prise en charge complète du NFC.


Prérequis

Prérequis par plateforme

Le consentement biométrique nécessite la version 4.10.0 ou ultérieure des SDK natifs. Pour les personnes soumises aux lois de l’Illinois, du Texas ou du Colorado, Didit peut demander un consentement biométrique explicite avant la première capture du visage. Une version du SDK Flutter qui épingle les SDK natifs iOS et Android en 4.10.0 ou ultérieure affiche cette étape. Les versions antérieures ne peuvent pas l’afficher : leurs sessions se déroulent comme auparavant, et la décision indique que le consentement n’a pas été recueilli (biometric_consent.reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK"). Mettez à jour si vous vérifiez des personnes dans ces États.

Installation

Ou ajoutez-le manuellement à votre pubspec.yaml :
Puis exécutez :

Variantes du SDK natif

didit_sdk embarque le SDK natif complet. Pour livrer un binaire plus léger, dépendez plutôt d’un package de variante : il expose exactement la même API Dart et épingle le SDK natif correspondant sur les deux plateformes :
Dépendez d’un seul de ces packages et importez depuis celui que vous avez choisi, par exemple package:didit_sdk_core/sdk_flutter.dart.

Configuration iOS

Le plugin prend en charge les deux gestionnaires de dépendances iOS de Flutter : Swift Package Manager et CocoaPods.

Swift Package Manager

Si la prise en charge de Swift Package Manager est activée dans votre version de Flutter (à activer avec flutter config --enable-swift-package-manager sur Flutter 3.24+), le plugin est utilisé automatiquement comme package Swift. Aucune configuration du Podfile n’est nécessaire : la dépendance native DiditSDK se résout seule depuis GitHub. Dans Xcode, réglez la cible de déploiement iOS de votre application (cible Runner et projet) sur le minimum requis par le package choisi : 15.0 pour didit_sdk et didit_sdk_nfc, 13.0 pour didit_sdk_core et didit_sdk_autodetection.

CocoaPods

Avec didit_sdk, le plugin sélectionne la variante du SDK natif iOS à partir de $DiditSdkIosVariant, une variable globale Ruby que vous définissez dans le fichier ios/Podfile de votre application (le pod DiditSDK n’est pas disponible sur CocoaPods trunk) :
Si vous utilisez un package de variante (didit_sdk_core, didit_sdk_autodetection, didit_sdk_nfc), il épingle directement sa sous-spécification native et ignore $DiditSdkIosVariant : gardez la ligne pod de votre Podfile et la cible de déploiement alignées sur cette variante (par exemple pod 'DiditSDK/Core', :podspec => ... avec platform :ios, '13.0').
Les variantes all et nfc nécessitent une cible de déploiement iOS 15.0+ ; core et autodetection peuvent cibler iOS 13.0. Lors d’un changement de variante, nettoyez d’abord CocoaPods (rm -rf Pods Podfile.lock) pour que la variante précédente du SDK ne soit pas réutilisée.
Le tag de l’URL du podspec doit correspondre à la version du SDK natif iOS épinglée par votre version de didit_sdk (4.13.2 épingle le natif 4.13.2). Si l’URL pointe vers un tag plus ancien, pod install échoue à résoudre la dépendance : CocoaPods trouve un podspec qui déclare cette version antérieure, alors que le plugin exige une correspondance exacte. Lorsque vous mettez à jour didit_sdk, passez le tag de cette URL à la même version.

Configuration Android

Par défaut, le plugin dépend du SDK Android complet, NFC inclus. Pour compiler sans NFC, ajoutez ceci à android/gradle.properties :
Cela remplace la dépendance me.didit:didit-sdk par me.didit:didit-sdk-core, ce qui supprime le module de lecture NFC et ses dépendances JMRTD, SCUBA et BouncyCastle. Lorsque le NFC est activé (par défaut), ajoutez cette règle de packaging à android/app/build.gradle.kts pour résoudre un fichier de métadonnées en double provenant de BouncyCastle :
Sans cette règle, la compilation échoue avec une erreur mergeDebugJavaResource. Cette règle n’est pas nécessaire lorsque diditSdkAndroidNfcEnabled=false.
Le SDK natif Android se résout depuis un dépôt Maven GitHub distant (depuis le plugin 3.4.0) : aucune configuration Maven manuelle n’est nécessaire dans votre application.

Autorisations

iOS

Ajoutez les clés suivantes au fichier Info.plist de votre application :
Si une clé de confidentialité iOS obligatoire est absente, iOS arrête l’application dès que le SDK tente d’accéder à cette ressource protégée. Par exemple, si NSCameraUsageDescription est absente, l’application plante lorsque l’utilisateur appuie sur le bouton de prise de photo de la caméra de document.

Configuration NFC

Pour activer la lecture NFC des passeports et des cartes d’identité équipés d’une puce :
  1. Ajoutez la capacité NFC dans Xcode :
    • Sélectionnez votre cible > Signing & Capabilities > + Capability > Near Field Communication Tag Reading
  2. Ajoutez les identifiants ISO7816 au fichier Info.plist :
D392F000260100000001 permet au SDK de lire la carte My Number du Japon via JPKI : sans cet identifiant, iOS ne signale pas la carte au SDK. La lecture de la carte My Number n’est pas encore activée en production, et cet identifiant n’a aucun effet sur les autres documents : vous pouvez donc l’ajouter dès maintenant.
  1. Ajoutez un fichier d’entitlements avec la lecture des tags NFC activée :
Assurez-vous que le profil de provisioning de l’application inclut la capacité NFC Tag Reading. Si l’identifiant de bundle n’est pas configuré pour le NFC dans votre compte Apple Developer, Xcode échouera à la signature avec une erreur indiquant l’absence de l’entitlement com.apple.developer.nfc.readersession.formats. Cette configuration NFC n’est pas nécessaire pour les variantes core ou autodetection ($DiditSdkIosVariant), ni pour les packages didit_sdk_core et didit_sdk_autodetection, car aucun d’entre eux ne lit les puces.

Android

Les autorisations suivantes sont déclarées dans le fichier AndroidManifest.xml du SDK et fusionnées automatiquement : Les fonctionnalités matérielles de caméra et de NFC sont déclarées comme facultatives (android:required="false"), afin que votre application puisse être installée sur des appareils dépourvus de ces fonctionnalités. Lorsque diditSdkAndroidNfcEnabled=false, le SDK n’ajoute ni l’autorisation NFC ni la fonctionnalité NFC Android.

Autorisations à l’exécution

Le SDK gère automatiquement les demandes d’autorisations Android à l’exécution. Lorsque l’utilisateur atteint une étape qui nécessite l’accès à la caméra :
  1. Le SDK demande l’autorisation d’accès à la caméra si elle n’a pas encore été accordée
  2. Si l’utilisateur refuse l’autorisation, un message d’erreur s’affiche avec un bouton Try Again
  3. Si l’utilisateur accorde l’autorisation, le parcours de vérification se poursuit
Vous n’avez pas besoin de demander l’autorisation d’accès à la caméra dans le code de votre application avant d’appeler startVerification() : le SDK gère cela en interne.

Démarrage rapide


Méthodes d’intégration

Le SDK prend en charge deux méthodes d’intégration :

Méthode 1 (token de session, recommandée en production)

Créez une session sur votre backend à l’aide de l’API de création d’une session de vérification, puis transmettez le token au SDK :
Cette approche vous donne un contrôle total sur :
  • L’association des sessions à vos utilisateurs (vendor_data)
  • La définition de métadonnées personnalisées
  • La configuration des callbacks par session

Méthode 2 (ID de workflow, intégration simplifiée)

Pour des intégrations plus simples, le SDK peut créer directement des sessions à partir de votre ID de workflow, sans backend :
Les paramètres avancés de session (contact_details, expected_details, metadata) ne sont pris en charge que par la méthode du token de session, où votre backend appelle l’API de création de session avec la prise en charge complète des paramètres. Transmettez le session_token renvoyé à DiditSdk.startVerification().

Configuration

Personnalisez le comportement du SDK en passant un objet DiditConfig :
Pour startVerificationWithWorkflow, passez config comme paramètre nommé :

Options de configuration

Options de caméra

Les options de caméra correspondent aux options de caméra du SDK Web. Chaque objectif est CameraLens.front ou CameraLens.back. Si l’appareil ne dispose pas de l’objectif demandé, le SDK utilise la première caméra disponible. Le bouton de changement de caméra est aussi masqué sur les appareils qui n’ont qu’une seule caméra. Définissez une option de changement de caméra sur false pour verrouiller l’utilisateur sur l’objectif par défaut de cette étape.
Thème et couleurs : les couleurs, les arrière-plans et les réglages de l’écran d’introduction se configurent dans vos paramètres de marque blanche dans la Didit Console, et non dans la configuration du SDK. Cela garantit une identité visuelle cohérente sur toutes les plateformes.

Prise en charge des langues

Le SDK prend en charge 54 langues. Si aucune langue n’est spécifiée, le SDK utilise les paramètres régionaux de l’appareil, avec l’anglais comme langue de repli.
Voir toutes les langues prises en charge →

Paramètres de session avancés

Les paramètres comme contact_details, expected_details et metadata sont uniquement pris en charge avec la méthode du token de session. Votre backend appelle POST /v3/session/ avec la prise en charge complète des paramètres, puis transmet le session_token renvoyé au SDK.
La méthode Dart startVerificationWithWorkflow n’accepte que workflowId, vendorData et config. Les versions antérieures à la 3.4.0 exposaient les paramètres contactDetails, expectedDetails et metadata, mais ils ont été supprimés, car l’endpoint Unilink ne les prend pas en compte.

Gestion des résultats

startVerification et startVerificationWithWorkflow renvoient toutes deux un Future<VerificationResult>. Le résultat est une classe scellée : utilisez la correspondance de motifs pour déterminer le résultat.

Cas de résultat

Propriétés de SessionData

Types d’erreur

L’énumération VerificationErrorType expose les cas suivants :

Perte de connexion

Si l’appareil perd sa connexion pendant la vérification, le SDK recouvre le parcours d’un écran « Pas de connexion Internet » au lieu de laisser une étape se charger indéfiniment. Il continue de vérifier la connexion en arrière-plan et ferme l’écran automatiquement dès que Didit redevient joignable. L’utilisateur reprend alors à l’étape où il se trouvait. L’écran propose Réessayer et, sauf si le bouton de fermeture est désactivé, Quitter la vérification. Quitter met fin à la vérification avec un résultat VerificationFailed dont le type d’erreur est networkError, ce qui permet à votre application de savoir que l’utilisateur est parti à cause de la connexion.

Exemple complet de gestion des résultats


Exemple de bout en bout (session backend → SDK Flutter → webhook)

Il s’agit de l’intégration prête pour la production : votre backend crée la session, votre application Flutter reçoit le session_token, et le SDK exécute le parcours. La décision finale est transmise à votre backend par webhook. Ne faites jamais confiance au seul résultat côté client.

1. Backend – créer la session

2. Flutter – échanger le token et démarrer le SDK

3. Backend – recevoir la décision finale via webhook

Consultez le guide des webhooks pour les détails de la vérification de signature HMAC.

Exemple complet


Dernière modification le 7 novembre 2026