Passer au contenu principal
La Validation en base de données de Didit vérifie les données d’identité d’une personne auprès de la source faisant autorité pour ce pays — le registre d’état civil national, l’administration fiscale, la liste électorale, le bureau de crédit ou le registre biométrique qui a initialement délivré le document. Chaque vérification renvoie une correspondance champ par champ (identification_number, first_name, last_name, date_of_birth et les champs d’adresse lorsque le service les utilise), ainsi qu’un résultat agrégé et les détails du dossier sous-jacent lorsqu’ils sont disponibles. Il s’agit de la défense la plus solide contre la fraude à l’identité synthétique : un DNI ou un CPF réel volé échouera à la vérification du registre, et un numéro inventé ne figurera pas du tout dans la base de données officielle. La validation en base de données s’associe à notre correspondance faciale biométrique dans les pays où le registre conserve une photo officielle (l’Argentine via RENAPER, le Panama via le Tribunal Electoral SIB / SIB Plus) afin que vous puissiez confirmer non seulement qu’un numéro est réel, mais que la personne devant la caméra en est bien le titulaire.

​
Pourquoi Didit

  • Les tarifs à l’appel les plus bas. À partir de $0.05 par vérification (République dominicaine) jusqu’à $7.00 pour les sources spécialisées les plus onéreuses. Le prix est fixé par service et non par pays — un service associé à un registre qui facture un tarif de gros élevé est tarifé en conséquence (la carte d’identité finlandaise est à $2.10). Consultez toujours le tarif du service exact que vous prévoyez d’appeler dans le tableau des tarifs par service. Aucun minimum mensuel, aucun frais de plateforme, aucune facturation par siège — seules les requêtes réussies sont facturées.
  • La plus rapide à intégrer. Inscrivez-vous, récupérez une clé API sur la console, et vous pouvez appeler POST /v3/database-validation/ en quelques minutes. Aucun appel commercial, aucun cycle d’approvisionnement, aucune formalité de preuve de concept — Didit est entièrement en libre-service.
  • Accès direct aux sources faisant autorité. RENAPER, Receita Federal (SERPRO), Tribunal Electoral, RENAPO, RENAP, RNP, RNPN, Junta Central Electoral, Registraduría Nacional, SEGIP, Servicio de Registro Civil, Tribunal Supremo de Elecciones, Dirección General de la Policía — et non de l’extraction de données chez des agrégateurs.
  • Correspondance faciale biométrique lorsque le registre dispose d’une photo officielle enregistrée. Un niveau de confiance supérieur à celui de l’OCR, sans travail d’intégration supplémentaire.
  • Latence adaptée à la production. p95 généralement inférieur à 1.5 s de bout en bout, disponibilité trimestrielle de 99.9%.
La leçon de l’Academy sur la lecture d’un résultat de vérification aborde la validation en base de données à 11:05 et montre les résultats avec correspondance complète, correspondance partielle et sans correspondance.

​
Couverture mondiale

Survolez n’importe quel pays mis en évidence pour voir chaque service de validation en base de données que nous y exploitons, le domaine de données (Identité, Financier, Biométrique, Adresse, Télécom, …) et le prix par appel. Les pays actifs sont prêts pour la production dès aujourd’hui ; les autres sont raccordés sur demande dès qu’un client en fait la demande.
Vous ne trouvez pas votre pays ? Contactez-nous — notre catalogue référence 60+ pays avec des centaines de services que nous activons à la demande dès qu’un client en a besoin. Les nouvelles intégrations sont généralement déployées en 2 à 3 semaines.

​
Déroulement d’une Validation en base de données

Une Validation en base de données ne se déclenche jamais de manière spéculative. Elle ne s’exécute que lorsque toutes les conditions suivantes sont remplies :
  1. La session a déterminé un pays à interroger — à partir du champ issuing_state d’une Vérification d’identité, ou, lorsque le workflow ne comporte aucune étape de Vérification d’identité, à partir de l’unique pays configuré pour l’étape de Validation en base de données.
  2. Ce pays dispose d’au moins un service de Validation en base de données activé dans le workflow.
  3. Les étapes précédant la Validation en base de données ont fourni tous les champs obligatoires requis par le service choisi.
Si un service est activé mais que les champs obligatoires ne sont jamais parvenus (par exemple, si le CPF n’a pas pu être extrait d’une carte RG brésilienne tachée), le service est ignoré, vous n’êtes pas facturé, et un avertissement est émis sur la session : DATABASE_VALIDATION_NOT_APPLICABLE lorsque le document ne comporte tout simplement pas l’identifiant sur lequel ce service effectue sa requête, ou COULD_NOT_PERFORM_DATABASE_VALIDATION lorsqu’il aurait dû être disponible mais ne l’était pas. Les deux sont répertoriés dans le catalogue des avertissements. Un membre de votre équipe disposant des autorisations d’examen sur la session peut alors renseigner le champ manquant à la main depuis la page de détails de la session dans la Console, et l’enregistrement relance automatiquement la vérification. Il s’agit d’une action réservée aux réviseurs, impossible à réaliser pour l’utilisateur final. Pour permettre à l’utilisateur de fournir un champ absent de son document, demandez-le dans un Questionnaire (ou via une extraction Document AI, ou une valeur transmise lors de la création de la session) et mappez-le sur l’étape de Validation en base de données, comme décrit ci-dessous.

​
La Validation en base de données ne requiert pas de Vérification d’identité

Auparavant, une étape de Validation en base de données impliquait nécessairement une étape préalable de Vérification d’identité, car l’OCR d’une pièce d’identité était le seul moyen intégré de collecter les données de l’utilisateur final. Ce n’est plus le cas : chaque champ obligatoire déclare quelles étapes peuvent le fournir, et un service devient disponible dès que votre workflow contient une étape fournissant l’ensemble des champs dont il a besoin. Cela signifie qu’un service biométrique facial peut s’exécuter à partir d’une simple étape de Détection du vivant, sans la moindre pièce d’identité dans le workflow, et qu’un service reposant sur un identifiant fiscal, un numéro de téléphone ou un e-mail peut être alimenté par une réponse à un questionnaire, une étape de Vérification du téléphone/de l’e-mail ou une extraction Document AI. Deux règles garantissent la sécurité de ce fonctionnement :
  • Un workflow sans Vérification d’identité doit configurer exactement un seul pays sur l’étape de Validation en base de données. Sans le champ issuing_state issu d’un document, il s’agit du seul signal explicite pour déterminer quel registre national interroger ; une configuration multi-pays sans Vérification d’identité n’exécute donc rien plutôt que de risquer une estimation.
  • La vérification des champs obligatoires reste inchangée. Un service dont les champs ne sont pas tous présents lors de l’exécution est ignoré avant toute interrogation d’un fournisseur, ce qui vous garantit de ne jamais être facturé pour une base de données qui n’a pas été consultée.

​
Mapper les champs Document AI et les champs de questionnaire

Les champs d’extraction de Document AI et les questions des questionnaires utilisent vos propres noms de clés, et non ceux de Didit. Une clé qui correspond exactement à un nom d’entrée de la Validation en base de données (tax_number, date_of_birth, phone, etc.) est automatiquement mappée et ne nécessite aucune configuration. Pour les autres, l’éditeur de workflow affiche un sélecteur sur l’étape de Validation en base de données pour les champs encore non renseignés, où vous associez chacun d’eux à la clé de champ Document AI ou à la réponse du questionnaire correspondante. Dans la Console, un service que votre workflow ne peut pas encore exécuter apparaît désactivé avec le motif associé — les champs manquants et l’étape qui permettrait de les fournir — et l’éditeur vous propose d’ajouter cette étape. L’ajouter débloque immédiatement tous les services correspondants.
Exemple concret — un identifiant absent du document. Le service du registre national du Nigeria s’appuie sur le NIN à 11 chiffres, qui n’est souvent pas imprimé sur les documents soumis par les utilisateurs ; s’appuyer uniquement sur la pièce d’identité entraîne donc l’ignorance de la vérification, considérée comme non applicable pour une grande partie des utilisateurs. Insérez une étape de Questionnaire avant l’étape de Validation en base de données pour demander le NIN, puis mappez national_id sur cette question dans l’étape de Validation en base de données. C’est ce même mapping qui rend exploitable dans un workflow un identifiant qui ne figure jamais sur un document, comme un numéro de vérification bancaire ou un numéro d’immatriculation d’entreprise.
Pour les services basés sur l’adresse, Didit segmente automatiquement le champ unique address de la pièce d’identité en éléments d’adresse structurés : Lors d’un appel à l’API autonome, vous pouvez envoyer soit un champ address unique, soit directement ces champs structurés. Les champs structurés ont la priorité lorsque les deux sont fournis. Les services exigeant une recherche par adresse nécessitent address_element_1 ainsi qu’au moins un autre élément d’adresse ; si Didit ne parvient pas à les extraire de la pièce d’identité ou du Justificatif de domicile au sein du workflow, le service est ignoré et non facturé. Si le pays déterminé n’est pas activé du tout, l’étape est ignorée silencieusement sans avertissement ni facturation.
Flux de validation en base de données de Didit vérifiant les données utilisateur auprès des registres d'identité gouvernementaux

​
Résultat de la correspondance

Chaque service activé renvoie une validation champ par champ : Le match_type agrégé se résume ainsi :
  • full_match — chaque champ demandé concorde avec au moins une source.
  • partial_match — concordance partielle ; redirigez vers une file d’attente d’examen selon les règles de votre workflow.
  • no_match — aucune source n’a confirmé les données ; généralement refusé.

​
Comment la correspondance est calculée (1×1 / 2×2)

Nous ne vous demandons plus de présélectionner « 1×1 » ou « 2×2 » — ces critères sont déduits du nombre de services distincts ayant obtenu une correspondance complète avec les données d’entrée :
  • Résultat 1×1 — un service a renvoyé une correspondance complète (une seule source faisant autorité a confirmé les données).
  • Résultat 2×2 — au moins deux services ont renvoyé une correspondance complète (corroboration indépendante ; le niveau de confiance le plus élevé possible).
Un workflow peut activer autant de services que souhaité par pays ; vous êtes facturé par service ayant effectivement renvoyé un résultat. Les services dont les champs obligatoires n’ont pas pu être extraits sont ignorés sans frais. ➡️ Consultez Méthodes de correspondance pour la logique de décision complète et son interaction avec partialMatchAction / noMatchAction.

​
Validation biométrique en base de données

Les registres de l’état civil de certains pays publient un gabarit biométrique (un portrait ou une empreinte digitale). Lorsque celui-ci est disponible, nous associons la recherche dans le registre à une correspondance faciale biométrique avec le selfie de l’utilisateur :
  • Argentine (arg_renaper) — correspondance faciale biométrique avec la photo officielle enregistrée au RENAPER. Couverture de 100% de la population ; chaque citoyen argentin possédant un DNI figure dans la base de données.
  • Panama (pan_cedula_sib, pan_cedula_sib_plus) — correspondance faciale biométrique avec le service SIB du Tribunal Electoral. SIB Plus est la variante de niveau supérieur dotée de seuils biométriques plus stricts et de métadonnées de correspondance plus riches.
Pour ces services, le champ selfie est obligatoire. Au sein d’un flux de session, nous réutilisons le selfie de détection du vivant (qualité maximale) et nous rabattons sur le portrait du document si nécessaire. En dehors d’une session, lors de l’appel à l’API autonome (POST /v3/database-validation/, mode B ci-dessus), vous fournissez vous-même le fichier JPEG/PNG.

​
Enrichissement d’identité mondial

glb_identity_enrichment est un service de Validation en base de données mondial et utilisable uniquement de manière autonome. À partir d’un e-mail et/ou d’un numéro de téléphone, il identifie les personnes associées (noms, dates de naissance, adresses, numéros de téléphone, e-mails et identifiants nationaux) et renvoie un score de correspondance de nom, associé aux codes de résultat standards MATCH / PARTIAL_MATCH / NO_MATCH / DOCUMENT_NOT_FOUND (avec le match_type correspondant parmi full_match / partial_match / no_match). Puisqu’il s’agit d’un service mondial (GLB) basé sur l’e-mail ou le téléphone plutôt que sur le pays de délivrance d’un document, il n’est pas disponible dans le générateur de workflow. Appelez-le directement via l’API autonome en définissant issuing_state sur GLB :
Il est facturé $0.20 par requête (facturé uniquement lorsque le fournisseur renvoie un résultat).

​
Configuration

La Validation en base de données se configure par workflow depuis la Console. Pour chaque pays, vous sélectionnez les services spécifiques que vous souhaitez exécuter ; les champs d’entrée obligatoires et optionnels sont déduits de l’ensemble combiné de ces services. L’action entreprise lors des résultats partial_match et no_match est configurée séparément et peut être approve, review ou decline.
Paramètres de la console de validation en base de données Didit sélectionnant les services de registre par pays et les règles de résultat

​
Notifications de disponibilité

Les registres gouvernementaux et d’autres sources subissent parfois des interruptions. Tant qu’une base de données est inaccessible, les vérifications qui l’interrogent ne renvoient aucune réponse et ne sont pas facturées. Au sein d’un workflow, le service renvoie REGISTRY_UNAVAILABLE. Sur l’API autonome, la même panne se présente sous l’une des trois formes suivantes, il convient donc de lire les résultats par service et database_validation.errors[], sans jamais se fier uniquement au statut HTTP :
  • 200 avec outcome_code: "REGISTRY_UNAVAILABLE" sur ce service dans validations, lorsque Didit a conservé un résultat à signaler pour celui-ci.
  • 200 avec ce service dans database_validation.errors[] sous la forme code: "empty_provider_response", retryable: true, lorsqu’il n’a produit aucune réponse exploitable alors qu’un autre service sélectionné en a produit une. Le service défaillant est alors absent de validations et de services_used, errors[] étant le seul endroit où il apparaît.
  • 502 avec validation_errors[].code: "empty_provider_response" et retryable: true, lorsqu’aucun service sélectionné n’a renvoyé de résultat exploitable (voir données d’entrée rejetées et résultats indisponibles).
Le status global suit les services qui ont répondu, il ne constitue donc pas à lui seul un indicateur fiable d’interruption. Une requête sans aucun élément de comparaison passe à In Review, mais une requête ayant sélectionné plusieurs services peut revenir Approved grâce à la correspondance d’un autre service alors même que l’une de ses sources était indisponible. Réessayez le service défaillant figurant dans errors[] plutôt que l’ensemble de la requête. Aucune de ces configurations n’indique quoi que ce soit sur la personne en cours de vérification. Didit surveille les résultats en temps réel des vérifications effectives, base de données par base de données, et envoie un e-mail à votre organisation lorsqu’une interruption se prolonge, plutôt que pour une simple requête échouée : Ces notifications sont envoyées aux membres et aux contacts de facturation de chaque organisation ayant effectué une vérification auprès de cette base de données précise au cours des dernières 48 heures. Aucune configuration n’est requise et aucune adhésion n’est nécessaire. Le trafic sandbox ne les déclenche jamais, pas plus que les échecs provoqués par les données transmises (données rejetées ou malformées) ou par les services utilisant des identifiants configurés par votre propre organisation. Une vérification ayant obtenu une réponse via une source de repli est considérée comme disponible, tout comme une absence de correspondance concluante.

​
Tarifs — ne payez que ce que vous utilisez

La Validation en base de données est facturée par requête réussie, par service, au tarif publié pour ce service. Les tarifs vont de $0.05 par vérification (République dominicaine via la Junta Central Electoral) jusqu’à $7.00 pour les sources spécialisées les plus onéreuses. De nombreuses consultations de registres gouvernementaux se situent dans la fourchette de USD 0.20 à USD 0.30, mais un nombre non négligeable coûte nettement plus cher car la source elle-même facture davantage — le service Finland National ID (fin_national_id) est à $2.10 par requête réussie. Déterminez le tarif applicable à un pays à partir de sa propre ligne dans le tableau des tarifs, jamais à partir d’une fourchette. Il n’y a aucun minimum mensuel, engagement ou frais de plateforme. Vous ne payez que lorsqu’un service renvoie un résultat. Les services ignorés en raison de données d’entrée manquantes ne sont pas facturés, pas plus qu’un service dont l’appel à la source échoue lui-même : une erreur de registre ou un registre inaccessible (REGISTRY_ERROR / REGISTRY_UNAVAILABLE) signifie que la requête n’a jamais reçu de réponse, il ne s’agit donc pas d’un résultat facturable. Chaque requête réussie auprès d’un registre est facturée dès la première, qu’elle soit exécutée au sein d’un workflow ou via l’API autonome POST /v3/database-validation/. Elle est prélevée sur le crédit de votre forfait ou votre solde de recharge comme toute autre vérification, et la remise liée à votre forfait s’applique à l’intégralité de son montant. Consultez la page des tarifs. ➡️ Tarifs de la Validation en base de données · Inscrivez-vous et obtenez une clé API

​
Tous les services

​
Poursuivre la lecture

  • Méthodes de correspondance — comment les résultats 1×1 / 2×2 sont dérivés et comment réagir en conséquence.
  • Codes de résultat — la liste complète des codes de réponse des fournisseurs (personne décédée, mineur, document non trouvé, incohérence biométrique, …) et leur correspondance avec les décisions de session.
  • Avertissements — ce que nous signalons lorsqu’un service ne peut pas s’exécuter en raison de données manquantes.
  • Rapports — exports mensuels de facturation par service avec pays, identifiant de service, utilisation, prix unitaire et coût total.
  • Pays pris en charge — une vue tabulaire statique de tous les pays que nous couvrons aujourd’hui.
Dernière modification le 7 novembre 2026