Passer au contenu principal
Chaque transaction qui comporte une adresse IP d’appareil est enrichie côté serveur, en temps réel, avant que les règles ne l’évaluent. L’enrichissement ajoute le pays, la ville, les indicateurs VPN, Tor et centre de données, l’ASN et l’opérateur, qui sont tous utilisables comme conditions de règle.

Quand l’enrichissement s’exécute

Intégré à la création de la transaction :
  1. Vous envoyez POST /v3/transactions/ avec subject.device_context.network_context.ip_address (ou l’adresse IP de l’appareil de n’importe quelle partie).
  2. Didit recherche l’IP dans un cache en mémoire (TTL de 24 heures).
  3. Si elle n’est pas en cache, Didit consulte la table d’enrichissement IP partagée (fraîcheur d’environ 30 jours).
  4. Si la donnée est périmée ou absente, Didit résout l’IP via son pipeline d’enrichissement, avec basculement entre plusieurs fournisseurs.
  5. Les champs enrichis sont écrits dans l’enregistrement de la transaction et mis à disposition des règles.
L’enrichissement est intégré : il se termine avant l’exécution des règles, mais il n’est pas bloquant en cas d’échec. Si l’enrichissement ne peut pas aboutir, la transaction est tout de même traitée, et l’IP apparaît simplement sans données d’enrichissement.

Champs enrichis

Utiliser les champs enrichis dans les règles

Chacun des champs enrichis peut servir de condition de règle. Voici les schémas courants : Juridiction à haut risque selon l’IP
Usage de VPN ou Tor
Centre de données ou origine non résidentielle
Pays de l’IP différent du pays KYC

Couches de cache

Les résultats trouvés dans les deux premières couches ne vous coûtent rien de plus. Les résolutions à jour peuvent être facturées : consultez votre console de facturation.

Comportement en cas d’échec

  • La création de la transaction n’échoue jamais parce que l’enrichissement a échoué.
  • Les champs d’enrichissement manquants ne correspondent simplement à aucune condition de règle qui les référence.
  • Les alertes concernant un enrichissement bloqué sont remontées à votre équipe d’exploitation via la surveillance interne ; cela n’a aucun impact côté client.

Filtrage de validité

Les IP non routables sont ignorées avant l’enrichissement :
  • Privées (10/8, 172.16/12, 192.168/16)
  • Boucle locale (127/8)
  • Liaison locale (169.254/16)
  • Adresses de multidiffusion et adresses non spécifiées
Ce filtrage permet d’économiser le quota des fournisseurs et évite des données d’enrichissement incohérentes.

Consulter l’enrichissement d’une transaction

Via l’API. Il n’existe pas de bloc d’enrichissement distinct. Les champs enrichis sont écrits dans l’objet device.network_context de la partie elle-même, à côté de l’ip_address que vous avez envoyé, dans l’entrée correspondante du tableau parties :
Les champs que vous avez fournis dans la requête sont conservés ; l’enrichissement ne remplit que les clés que vous avez omises, et les clés pour lesquelles le résolveur a renvoyé une valeur vide sont omises. Consultez le schéma de réponse pour la structure complète de device. Dans la console. La page de détail de la transaction affiche l’enrichissement IP dans l’onglet IP et appareil, avec un repère sur la carte.

Considérations relatives à la confidentialité

  • Les adresses IP brutes sont stockées avec la transaction.
  • Les données d’enrichissement sont conservées dans une table partagée indexée par IP, et non par utilisateur.
  • La suppression au titre du droit à l’effacement retire les IP de la transaction ; l’entrée de cache partagée est conservée, car elle n’identifie pas personnellement quelqu’un.

Étapes suivantes

Règles

Utilisez les champs enrichis dans les conditions.

Bibliothèque de règles

Règles prédéfinies basées sur l’IP.

Schéma de réponse

Emplacement de l’enrichissement IP.
Dernière modification le 7 novembre 2026