# SDK mobiles et web

Source: https://help.didit.me/fr/integration/mobile-sdks
Updated: 2026-10-12

Les SDK natifs iOS, Android, React Native et Flutter intègrent le flux et sont la seule voie pour le NFC ; les SDK web visent 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

[Video: Le guide complet d’intégration - Didit Academy](https://www.youtube.com/watch?v=fX03-WEu_EI)

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](https://help.didit.me/fr/documents-coverage/nfc-chip-verification).
- **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

[Video: Choisir le bon SDK Didit - Didit Academy](https://www.youtube.com/watch?v=qHada8ZY24Q&t=14)

| 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 |

![La page Integrate dans la console Didit avec les liens vers le SDK et la documentation](https://help.didit.me/screenshots/integrate-light.webp)

*Chaque SDK part de la même page que l'API.*

iOS accepte Swift Package Manager et CocoaPods ; ajoutez les permissions caméra et NFC à `Info.plist` si nécessaire. Android est distribué via Maven. React Native accepte Expo avec une version de développement contenant les modules natifs, pas Expo Go.

Les exigences de version et les minimums de plateforme changent au fil des versions, donc consultez la [documentation SDK](https://docs.didit.me/integration/native-sdks/overview) 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](https://help.didit.me/fr/liveness-biometrics/liveness-and-face-match-issues).
- **La langue est celle de l'application, pas celle de l'utilisateur.** Une WebView rapporte la langue de l'application hôte, donc transmettez `language` explicitement à la création de session. Voir [définir la langue de vérification](https://help.didit.me/fr/workflows/verification-languages).

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](https://help.didit.me/fr/integration/webhooks-basics). 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.

> **Warning:** 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

Passez à **Sandbox** avec le sélecteur sous le nom de l’application, créez une clé API de test et utilisez-la. Les contrôles sont simulés, sans facturation, et vous pouvez choisir le résultat.

[tester en sandbox](https://help.didit.me/fr/getting-started/sandbox-and-testing)