Consentement biométrique pour BIPA, CUBI et le Colorado

L’Illinois (BIPA), le Texas (CUBI) et le Colorado exigent une notification préalable et une autorisation explicite avant qu’une entreprise ne recueille la géométrie faciale, que ce soit à partir d’un selfie ou de la photo figurant sur une pièce d’identité. Didit peut afficher une étape de consentement avant la première capture de visage pour les personnes couvertes par ces lois, et conserve la réponse sur la session comme preuve. Cette page explique quand l’étape apparaît, quelles applications peuvent l’afficher, et comment la réponse est intégrée à votre décision et transmise à vos webhooks.

Didit affiche l’étape et enregistre la réponse. Il vous appartient de déterminer si votre parcours utilisateur respecte les lois sur la biométrie applicables à votre entreprise. Cette page ne constitue pas un avis juridique : examinez votre implémentation avec votre conseiller juridique.

Quand l’étape apparaît

Une session affiche l’étape de consentement lorsque ces deux conditions sont réunies :

Le workflow capture un visage. Une étape de Détection du vivant, de Correspondance faciale ou d’Estimation de l’âge, le selfie pris avec la caméra frontale lors de l’étape de Vérification d’identité (sauf si vous l’avez désactivé), ou l’enregistrement vidéo complet de la session.
Le mode de consentement de l’application le requiert. En mode Automatique, l’un des déclencheurs ci-dessous s’applique. En mode Toujours, chaque session qui capture un visage le demande.

L’étape apparaît avant la première capture de visage. Lorsque seul le document d’identité indique un État concerné, elle apparaît immédiatement après la capture de la pièce d’identité et avant le selfie, et aucune géométrie faciale n’est calculée à partir des images de la pièce d’identité tant que la personne n’a pas donné son accord. Didit vérifie cette exigence lorsque la personne ouvre le flux, puis à nouveau à chaque étape jusqu’à ce qu’elle s’applique. Dès lors qu’une session requiert le consentement, cette exigence est maintenue.

Modes de consentement

Choisissez le mode dans la console, sous Settings > Data and privacy > Biometric consent de l’application. Chaque modification est enregistrée dans le journal d’audit.

Mode	Ce qui se passe
Automatique (par défaut, recommandé)	Affiche l’étape uniquement lorsqu’un déclencheur s’applique. Toutes les autres personnes voient la mention standard sur une seule ligne.
Toujours	Chaque personne dont le visage est capturé voit l’étape, où qu’elle se trouve. La décision enregistre `trigger: "forced"`.
Jamais	Didit n’affiche jamais l’étape. Lorsque la législation de l’État exige un consentement, vous le recueillez vous-même avant le selfie et vous en conservez la preuve.

Ce qui déclenche l’étape en mode Automatique

Didit vérifie ces règles dans l’ordre et enregistre la première qui s’applique dans biometric_consent.trigger :

Déclencheur	Quand il s’applique
`declared_state`	Vous avez déclaré un État concerné lors de la création de la session : `user_state`, ou une adresse aux États-Unis dans `expected_details`.
`ip_state`	L’IP de la personne est localisée dans l’Illinois, au Texas ou dans le Colorado.
`ip_unknown`	La personne semble se trouver aux États-Unis (IP américaine, document américain ou informations transmises la situant aux États-Unis), mais son État ne peut être déterminé : l’IP est aux États-Unis sans précision de l’État, ou ne peut pas être localisée alors que vos informations ou le document placent la personne aux États-Unis.
`document_issuer`	La pièce d’identité lue lors de la capture du document a été délivrée par un État concerné.

Les VPN, proxys et réseaux d’hébergement ne déclenchent pas la demande d’eux-mêmes. Didit localise l’IP de la personne comme n’importe quelle autre : une adresse dans l’Illinois, au Texas ou dans le Colorado affiche l’étape, une adresse située ailleurs ne l’affiche pas. L’étape n’est demandée que sur preuve manifeste d’un État concerné (l’IP, l’État ayant délivré la pièce d’identité ou un État que vous avez déclaré), ou lorsque la personne est localisée aux États-Unis sans État déterminé (ip_unknown). Une personne située dans un État concerné derrière un VPN dont le point de sortie se trouve ailleurs, avec une pièce d’identité qui n’a été délivrée par aucun État concerné, ne verra pas l’étape ; utilisez le mode Toujours, ou transmettez user_state, si vous devez couvrir ce cas de figure. Deux autres valeurs décrivent la manière dont le consentement d’une session a été déterminé plutôt que la raison pour laquelle il a été demandé :

Déclencheur	Signification
`forced`	Le mode de l’application est Toujours.
`customer_collected`	Vous avez transmis un consentement que vous aviez déjà recueilli lors de la création de la session (voir ci-dessous).

Transmettez à Didit ce que vous savez déjà

Créer une session accepte deux champs facultatifs à cet effet :

Champ	Fonction
`user_state`	Le lieu de résidence de la personne, lorsque vous le connaissez : un code de subdivision ISO 3166-2 (`US-IL`, `ES-M`) ou un code ou nom d’État américain (`IL`, `Illinois`). Un État concerné affiche l’étape avec `trigger: "declared_state"`. Une valeur inconnue renvoie une erreur `400`.
`biometric_consent`	Le consentement que vous avez déjà recueilli : `{ "given_at": "<ISO 8601>", "text_version": "<your version id>" }`. Le flux ne redemande pas le consentement et la décision enregistre `status: "given"` avec `trigger: "customer_collected"`. `given_at` ne peut pas être dans le futur.

{
  "workflow_id": "YOUR_WORKFLOW_ID",
  "vendor_data": "user-42",
  "user_state": "US-IL",
  "biometric_consent": {
    "given_at": "2026-10-13T09:12:00Z",
    "text_version": "consent-v3"
  }
}

Quelles applications affichent l’étape

L’étape nécessite une application capable de l’afficher. Didit en décide à chaque requête effectuée par l’application :

Où la personne se vérifie	Affiche l’étape
Le flux de vérification hébergé : un navigateur, le SDK Web ou une WebView	Oui
Le SDK natif 4.10.0 ou ultérieur (iOS, Android, ainsi que les versions React Native ou Flutter qui intègrent le SDK natif 4.10.0 ou ultérieur)	Oui
Un SDK natif inférieur à la version 4.10.0, ou qui ne transmet pas sa version	Non

SDK natifs antérieurs à la version 4.10.0

Les SDK natifs publiés avant la version 4.10.0 ne prennent pas en charge l’étape de consentement, Didit ne la leur demande donc jamais. La vérification s’exécute exactement comme auparavant : le selfie et les autres captures de visage sont acceptés et traités, et la session aboutit à sa décision comme d’habitude. Didit n’enregistre jamais un consentement qui n’a pas été donné. Lorsque la session exigeait un consentement et qu’un SDK plus ancien a capturé un visage, la décision indique :

"biometric_consent": {
  "required": true,
  "trigger": "ip_state",
  "status": "pending",
  "given_at": null,
  "reason": "BIOMETRIC_CONSENT_UNSUPPORTED_SDK"
}

Mettez à niveau vers le SDK natif 4.10.0 ou ultérieur si vous vérifiez des personnes dans l’Illinois, au Texas ou au Colorado dans une application native. Tant que ce n’est pas fait, ces sessions se terminent sans consentement explicite, et son recueil avant le selfie relève de votre responsabilité.

Si la personne poursuit la même session dans le flux hébergé (sur un autre appareil, ou dans une WebView que l’application ouvre pour certains types de détection du vivant), le flux hébergé affiche l’étape et n’y capture aucun visage tant qu’elle n’a pas répondu. Le consentement donné à cet endroit conserve reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK", car des visages ont déjà été capturés sans lui.

Ce que voit la personne

L’étape indique à la personne ce qui est collecté, pourquoi, qui le détient et pendant combien de temps ces données sont conservées, et fournit un lien vers la Politique relative aux données biométriques. Elle comporte un seul bouton : J’accepte et je continue, qui reste désactivé jusqu’à ce que la personne coche la case d’acceptation. Didit conserve la réponse à titre de preuve : le moment où elle a été donnée, la version et le hachage du texte affiché, la langue, l’étape du workflow, ainsi que l’adresse IP, la localisation et l’agent utilisateur de la requête. Une fois que la personne a accepté, la réponse est définitive.

Quand la personne n’accepte pas

L’étape ne comporte pas de bouton de refus. Une personne qui ne souhaite pas accepter quitte le flux : aucun visage n’est capturé et la session se termine avec l’état Abandoned, comme toute autre session que la personne ne termine pas (voir Statuts de vérification). Proposez-lui un autre moyen de se vérifier.

Consentement refusé dans l’API

La décision conserve un statut declined et le motif BIOMETRIC_CONSENT_DECLINED sous forme de valeurs d’API. Aucun écran Didit ne propose de refus à l’heure actuelle, de sorte que le flux hébergé et les SDK natifs n’en enregistrent pas. Une session qui enregistre un refus :

Se termine avec le statut Declined, et le webhook status.updated est déclenché comme pour tout autre refus.
Affiche biometric_consent.status avec la valeur declined, reason et decline_reason avec la valeur BIOMETRIC_CONSENT_DECLINED, et declined_at avec l’heure correspondante.
Ne capture aucun visage après le refus. Chaque image de visage et chaque gabarit biométrique que la session contient déjà est supprimé : selfies, selfie pris avec la caméra frontale lors de la capture de la pièce d’identité, recadrage du visage sur le portrait du document, vidéos de détection du vivant et de la session complète. Le champ face_data_deleted_at enregistre la date et l’heure de suppression. La décision ne les renvoie plus, et la suppression est irréversible.
Conserve les images des documents et les données extraites de ceux-ci : le refus n’a pas d’impact sur ces éléments.

Dans la décision et les webhooks

Chaque décision de Vérification des utilisateurs contient un objet biometric_consent, dans Récupérer une session et dans le champ decision des webhooks de session. Il est null lorsque la session n’a jamais été évaluée, par exemple dans un workflow sans capture de visage.

`status`	Signification
`not_required`	La session n’exigeait pas de consentement.
`pending`	Le consentement est requis et n’a pas été donné. Consultez `reason` pour distinguer un SDK plus ancien d’une personne qui n’a pas encore répondu.
`given`	La personne a donné son accord dans le flux, ou vous avez transmis `biometric_consent` lors de la création.
`declined`	Un refus a été enregistré et la session s’est terminée avec le statut `Declined`. Aucun écran Didit ne propose de refus à l’heure actuelle (voir ci-dessus).

`reason`	Signification
`BIOMETRIC_CONSENT_UNSUPPORTED_SDK`	Un SDK natif inférieur à la version 4.10.0, ou n’ayant pas transmis sa version, a capturé un visage sans passer par l’étape.
`BIOMETRIC_CONSENT_DECLINED`	Un refus a été enregistré. Aucun écran Didit ne propose de refus à l’heure actuelle.
`null`	Rien à signaler. Toujours `null` lorsque la session n’exigeait pas de consentement.

Une session où la personne a donné son accord dans le flux hébergé :

"biometric_consent": {
  "required": true,
  "trigger": "declared_state",
  "status": "given",
  "given_at": "2026-10-13T18:31:07.412000Z",
  "declined_at": null,
  "text_version": "bio-consent-2026-10-12",
  "locale": "en",
  "policy_url": "https://didit.me/legal/biometric-data-policy",
  "step": "LIVENESS",
  "ip_address": "198.51.100.23",
  "ip_country_code": "ES",
  "detected_ip_address": "198.51.100.23",
  "detected_country_code": "ES",
  "jurisdictions": ["IL"],
  "retention_months": 36,
  "reason": null,
  "decline_reason": null,
  "face_data_deleted_at": null
}

Cet exemple est raccourci. Chaque champ, accompagné de son type, figure dans les Modèles de données.

Ressources associées

Créer une session : user_state et biometric_consent.
Récupérer une session : la décision contenant biometric_consent.
SDK natifs : versions et étapes de mise à niveau.
Sécurité et conformité : vos responsabilités dans les flux de vérification.

Présentation

Tarifs

Workflows et vérification

Examen et opérations

Entités (utilisateurs et entreprises)

Paramètres et personnalisation

Sécurité et conformité

Didit Academy

Ressources

Consentement biométrique pour BIPA, CUBI et le Colorado

Quand l’étape apparaît

Modes de consentement

Ce qui déclenche l’étape en mode Automatique

Transmettez à Didit ce que vous savez déjà

Quelles applications affichent l’étape

SDK natifs antérieurs à la version 4.10.0

Ce que voit la personne

Quand la personne n’accepte pas

Consentement refusé dans l’API

Dans la décision et les webhooks

Ressources associées

​Quand l’étape apparaît

​Modes de consentement

​Ce qui déclenche l’étape en mode Automatique

​Transmettez à Didit ce que vous savez déjà

​Quelles applications affichent l’étape

​SDK natifs antérieurs à la version 4.10.0

​Ce que voit la personne

​Quand la personne n’accepte pas

​Consentement refusé dans l’API

​Dans la décision et les webhooks

​Ressources associées

Quand l’étape apparaît

Modes de consentement

Ce qui déclenche l’étape en mode Automatique

Transmettez à Didit ce que vous savez déjà

Quelles applications affichent l’étape

SDK natifs antérieurs à la version 4.10.0

Ce que voit la personne

Quand la personne n’accepte pas

Consentement refusé dans l’API

Dans la décision et les webhooks

Ressources associées