Passer au contenu principal

Vue d’ensemble

L’analyse de l’appareil et de l’IP émet des tags d’avertissement dans ip_analyses[].warnings[] dès qu’elle détecte un comportement suspect lié à l’appareil, au réseau ou à la localisation. Neuf tags disposent d’une action configurable (Refuser / Examen / Aucune action) par nœud de workflow ; les deux tags de liste de blocage imposent systématiquement Declined, et les deux tags de liste d’autorisation sont toujours informatifs. Le champ log_type de chaque avertissement reflète l’action appliquée : error (Refuser), warning (Examen) ou information (Aucune action). Chaque risque ne se déclenche au maximum qu’une seule fois par session. Chaque risque ci-dessous est vérifié par rapport au pipeline de décision en production ; les avertissements portent le tag de fonctionnalité LOCATION et la structure standard de l’objet d’avertissement. Les avertissements relatifs à l’empreinte de l’appareil sont intentionnellement répartis entre les signaux exacts et les signaux récupérés :
  • DUPLICATED_DEVICE_FINGERPRINT signifie que la même identité déterministe d’appareil (match_source persistent_id ou legacy_fp) a été réutilisée sur plusieurs sessions avec des valeurs vendor_data différentes.
  • DEVICE_RECOVERED_HIGH_CONFIDENCE signifie que la récupération d’empreinte v2 a associé la session à un appareil déjà observé après modification de l’identifiant persistant (stockage effacé, navigation privée, réinstallation de l’application). L’avertissement n’apparaît que lorsque la correspondance atteint le seuil de similarité requis pour une forte confiance et satisfait aux conditions strictes.
Exemple d'avertissement d'analyse de l'appareil et de l'IP Didit avec alertes d'appareil, de VPN, de proxy et de non-concordance de localisation

Avertissements générés

Lorsque l’appareil récupéré n’a pas encore de sessions sœurs éligibles (rien ne figure donc dans matches[]), DEVICE_RECOVERED_HIGH_CONFIDENCE se déclenche tout de même avec une structure de additional_data de secours : recovery_match_device_uuid, recovery_match_similarity, recovery_match_band, recovery_gate_reason. IP_LOCATION_NOT_ALLOWED se déclenche lorsque le géorepérage IP est activé (is_ip_geofencing_enabled) et que l’IP de la session est située dans un pays ou un État/région marqué comme non autorisé dans ip_geofencing_by_country. additional_data contient ip_country_code (ISO-3), ip_country, ip_state et restricted_by (country ou state). Les entrées d’État/région prévalent sur le paramètre du pays et sont comparées au nom de région du fournisseur IP sans tenir compte de la casse (par ex. "California") ; les pays non répertoriés dans la configuration sont autorisés.

Intégrité de l’appareil et de l’environnement d’exécution

Signaux rapportés par les SDK natifs et le client web décrivant l’état de l’appareil sur lequel la vérification a été exécutée. Ils existent pour détecter les attaques par injection : un attaquant capable d’obtenir un accès root à un appareil ou d’intercepter le processus de l’application peut remplacer le flux de la caméra avant même qu’il n’atteigne les contrôles biométriques. Chacun est configurable par workflow et est défini par défaut sur Aucune action, de sorte que l’activation de la fonctionnalité ne modifie aucune décision tant que vous n’avez pas choisi de l’activer.
Chaque sonde fonctionne au mieux. Lorsqu’un contrôle ne peut pas s’exécuter, il signale non déterminé plutôt qu’un résultat sans anomalie, de sorte qu’une sonde défaillante ne produit jamais de faux positif à l’encontre d’un utilisateur légitime. Les signaux sont rapportés à partir de la version 4.4.0 du SDK natif ; les sessions provenant de SDK antérieurs n’envoient légitimement rien et ne déclenchent jamais DEVICE_INTEGRITY_SIGNALS_MISSING.
Les signaux de root et d’émulateur sont fréquents chez les utilisateurs légitimes sur des appareils modifiés mais non frauduleux. Commencez par l’action « Examiner » plutôt que par « Refuser » et surveillez votre propre taux de refus avant d’adopter une action plus stricte.

Paramètres configurables

Contrôles de workflow par nœud (également configurables globalement dans les paramètres de vérification de l’application ; chaque action est définie par défaut sur Aucune action, sauf indication contraire) : Les listes d’autorisation d’IP et d’appareils suppriment uniquement l’avertissement de doublon exact d’adresse IP ou de doublon déterministe d’appareil pour la valeur autorisée. Elles ne suppriment pas les avertissements de VPN/proxy, de non-concordance de pays, de non-concordance d’IP attendue, d’appareil récupéré ou de liste de blocage. Les avertissements d’appareil récupéré sont utiles pour détecter les réseaux de fraude qui alternent les comptes et les sessions depuis le même matériel, mais Didit est conservateur par conception — le système préfère manquer certains utilisateurs dupliqués plutôt que de fusionner des appareils sans lien lorsque les preuves ne sont pas assez solides. Déploiement recommandé : commencez par Examiner, observez le volume pendant deux semaines, puis adoptez une action plus stricte si votre taux de faux positifs est faible.

Appareil dupliqué vs appareil récupéré

Traitez les deux avertissements différemment — ils se déclenchent sur des éléments de preuve distincts :

Correspondances entre sessions

Lorsque la même adresse IP, l’identité exacte de l’appareil ou un appareil récupéré sont détectés sur plusieurs sessions appartenant à différents utilisateurs, Didit les enregistre sous forme de matches[] dans ip_analyses[]. Les sessions sont regroupées par vendor_data : les sessions ayant le même vendor_data sont traitées comme étant le même utilisateur et exclues des correspondances. Sans vendor_data, chaque session est considérée comme un utilisateur unique et tous les doublons potentiels sont signalés — nous vous recommandons vivement de toujours fournir vendor_data pour réduire le bruit. Chaque correspondance comprend :
  • session_id, session_number, vendor_data et verification_date de la session correspondante, ainsi que son status de cycle de vie et api_service (null pour les sessions de workflow) ; source vaut toujours session
  • match_type — ip_address ou device_fingerprint
  • match_source — ip_address, persistent_id, legacy_fp ou recovered_high
  • matched_value — l’IP partagée, l’identifiant de l’appareil ou (pour les correspondances récupérées) l’UUID de l’appareil récupéré
  • confidence (0–1, 1 - P(false positive)) et match_mode (deterministic / probabilistic / co_occurrence)
  • device_info — device_brand, device_model, browser_family, os_family, platform, device_fingerprint
  • location_info — ip_address, ip_country, ip_country_code, ip_state, ip_city, is_vpn_or_tor, is_data_center
  • Informations supplémentaires sur l’appareil récupéré lorsque match_source est recovered_high : recovery_similarity, tls_ja4_corroborated, recovery_gate_reason
Les correspondances IP et les correspondances d’appareils sont limitées à 5 chacune (au maximum 10 entrées). Consultez la page du rapport pour obtenir le schéma complet des correspondances et le modèle de confiance.

Exemples

VPN + incohérence de pays (configuré sur Examen)

Détection dans la liste de blocage (force le refus)

Appareil récupéré avec un niveau de confiance élevé (configuré sur Examen)

Liens associés

Types d’avertissements

Dernière modification le 7 novembre 2026