> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # Validation en base de données : méthodes 1x1 et 2x2 > Didit calcule les résultats 1x1 et 2x2 via seuils de noms flous, règles partialMatchAction et logique en cascade. Dès $0.05/vérification. L'API de [Validation en base de données](https://docs.didit.me/fr/core-technology/database-validation/overview.md) de Didit vérifie les données d'identité par rapport au registre civil, à l'administration fiscale ou au fichier électoral officiel de chaque pays — RENAPER (Argentine), Receita Federal (Brésil), Tribunal Electoral (Panama), RENAPO (Mexique), Junta Central Electoral (République dominicaine), Registraduría Nacional (Colombie) et bien d'autres. Chaque requête est facturée par appel réussi, à partir de **\$0.05/vérification** sans minimum mensuel. Les résultats découlent des résultats par service : **1×1** lorsqu'un seul registre renvoie une correspondance complète, **2×2** lorsque deux registres indépendants corroborent les données. Cette page décrit comment ces résultats sont calculés, les seuils de correspondance approximative appliqués aux noms et la logique de décision qui régit `partialMatchAction` et `noMatchAction` dans les règles de votre workflow. ## Correspondance 1×1 Cette méthode consiste à faire correspondre une donnée d'entrée (généralement un numéro d'identification national ou un identifiant similaire) avec notre base de données. Si une correspondance directe est trouvée, nous confirmons l'identité. Toutefois, si la tentative initiale échoue, nous pouvons essayer d'autres sources de données fiables selon une séquence en cascade. Cela signifie que nous continuons la validation auprès de prestataires successifs jusqu'à obtenir une correspondance ou épuiser toutes les options. Il est important de noter qu'une correspondance partielle n'interrompt pas le processus : nous ne nous arrêtons que lorsque nous trouvons une correspondance complète et concluante ou déterminons qu'aucune correspondance n'existe. La logique de correspondance 1x1 nécessite de faire correspondre les données personnelles d'un utilisateur avec une source pour obtenir une Correspondance complète sur son identité.\* | Résultat de vérification | Catégorie de nom | Catégorie d'identifiant | Catégorie de date de naissance | | :- | :- | :- | :- | | Correspondance complète | Correspondance complète | Correspondance complète | Toute valeur | | Correspondance partielle | Correspondance partielle | Correspondance complète | Toute valeur | | Aucune correspondance | Toutes les autres combinaisons | | | *\*Les sources applicables du pays sont vérifiées jusqu'à ce qu'une Correspondance complète soit obtenue sur l'identité. Si aucune Correspondance complète n'est trouvée, le système continue alors à vérifier ces sources jusqu'à obtenir une Correspondance partielle sur l'identité de l'utilisateur.* > [!NOTE] > > Le tableau 1×1 ci-dessus et le tableau 2×2 ci-dessous décrivent le modèle général, et non une garantie valable pour chaque service. Les champs décisifs varient selon le service et selon les entrées optionnelles que vous transmettez : un registre ne peut comparer que les champs qu'il détient et ceux que vous lui fournissez, et le résultat d'un service est déterminé par les champs qu'il compare réellement. Tous les services ne comparent pas le numéro d'identification, et certains ne le comparent que si vous le transmettez. Par exemple, [Espagne - Vérification DNI/NIE](https://docs.didit.me/fr/api-reference/database-validation/spain/dni.md) (`esp_dni`) requiert le nom, la date de naissance et l'adresse, et accepte `national_id` comme entrée optionnelle. Il compare systématiquement le nom, la date de naissance et l'adresse, et compare également le numéro d'identification lorsque vous transmettez `national_id`. > > Un champ obligatoire n'est pas nécessairement décisif, et un champ optionnel peut l'être. Un champ obligatoire doit être envoyé pour que la requête soit acceptée, et un champ listé dans `source_data` correspond aux données renvoyées par le registre. Aucun des deux n'indique quels champs ont déterminé le résultat. Les exemples de réponse sur la page de chaque service illustrent une réponse possible, de sorte que les clés de leur objet `validation` ne constituent pas une liste exhaustive des champs comparés par ce service. La page de référence API de chaque service, répertoriée sous [Pays et services pris en charge](https://docs.didit.me/fr/core-technology/database-validation/database-validation-supported-countries.md), détaille ses entrées obligatoires et optionnelles sous **Entrées**. ## Correspondance 2×2 Cette méthode nécessite de faire correspondre deux données en entrée (par exemple, nom + date de naissance, ou numéro d'identité national + numéro de téléphone) avec deux champs correspondants dans notre base de données. Tout comme pour la méthode 1x1, nous suivons une approche en cascade en interrogeant successivement plusieurs sources de données. Nous progressons à chaque étape jusqu'à trouver une correspondance complète sur les deux champs de données. Les correspondances partielles ou sur un seul champ ne suffisent pas ; le processus de validation se poursuit jusqu'à ce qu'une correspondance définitive sur 2 champs soit obtenue ou que toutes les sources aient été vérifiées. La logique de correspondance 2x2 exige de faire correspondre les données personnelles d'un utilisateur avec deux sources pour obtenir une Correspondance complète sur son identité.\* | Résultat de la vérification | 1re source de données | 2e source de données | | :- | :- | :- | | Correspondance complète | Nom Correspondance complète + Numéro d'identité national Correspondance complète | Nom Correspondance complète + Numéro d'identité national Correspondance complète | | Correspondance complète | Nom Correspondance complète + Numéro d'identité national Correspondance complète | Nom Correspondance partielle + Numéro d'identité national Correspondance complète | | Correspondance complète | Nom Correspondance complète + Numéro d'identité national Correspondance complète | Nom Correspondance complète + Date de naissance Correspondance complète | | Correspondance complète | Nom Correspondance complète + Numéro d'identité national : n'importe quelle valeur | Nom Correspondance complète + Numéro d'identité national : n'importe quelle valeur | | Correspondance partielle | Nom Correspondance complète + Numéro d'identité national Correspondance complète | | | Correspondance partielle | Nom Correspondance partielle + Numéro d'identité national Correspondance complète | | | Correspondance partielle | Nom Correspondance totale + Date de naissance Correspondance totale | | | Correspondance partielle | Nom Correspondance totale + Numéro d'identité nationale (toute valeur) | | | Aucune correspondance | Toutes les autres combinaisons | | *\*Les sources applicables du pays sont vérifiées jusqu'à obtenir une correspondance totale sur l'identité. Si aucune correspondance totale n'est trouvée, le système vérifie alors de manière répétée ces sources pour trouver une correspondance partielle sur l'identité de l'utilisateur.* *** ## Correspondance des catégories de données et des attributs Voici les scénarios qui donnent lieu à une Correspondance complète pour les catégories de données Nom, Date de naissance et ID. Une Correspondance partielle n'est possible que pour la catégorie Nom. ### Correspondance de la catégorie Nom Une **Correspondance complète** sur la catégorie Nom est retenue lorsque l'un des scénarios de correspondance d'attributs de données suivants est rempli : * Concaténation du nom complet Correspondance complète (Prénom + Nom de famille combinés avec un seuil de similarité de 85%) * Prénom Correspondance complète + Nom de famille Correspondance complète * Prénom Correspondance complète + Nom maternel Correspondance complète * Prénom Correspondance complète + Nom paternel Correspondance complète Une **Correspondance partielle** sur la catégorie Nom est retenue lorsque l'un des scénarios de correspondance d'attributs de données suivants est rempli : * Prénom Correspondance complète * Nom de famille Correspondance complète * Nom paternel Correspondance complète * Nom maternel Correspondance complète * Nom maternel Correspondance complète + Nom paternel Correspondance complète ### Correspondance de la catégorie Date de naissance Une **Correspondance complète** sur la catégorie Date de naissance n'est retenue que lorsque le scénario de correspondance d'attributs de données suivant est rempli : * Année de naissance Correspondance complète + Mois de naissance Correspondance complète + Jour de naissance Correspondance complète Une Correspondance partielle sur la catégorie Date de naissance n'est pas possible. ### Correspondance de la catégorie ID Une **Correspondance complète** sur la catégorie ID n'est retenue que lorsque le scénario de correspondance d'attributs de données suivant est rempli : * Numéro d'identification Correspondance complète Une Correspondance partielle sur la catégorie ID n'est pas possible. La catégorie ID n'est prise en compte que lorsque le service compare le numéro d'identification. Certains services ne le comparent jamais, et d'autres ne le comparent que si vous le transmettez en entrée. *** ## Correspondance floue pour les attributs de données Voici les critères de correspondance floue appliqués aux différents attributs de données par rapport aux sources de données par pays. * **Attributs de données relatifs au nom** Pour qu'un attribut de données de la catégorie Nom génère un résultat Correspondance complète, il doit présenter une similarité de caractères de Levenshtein d'au moins 70% par rapport aux enregistrements des sources de données. Pour la concaténation du nom complet (prénom + nom de famille combinés), un seuil plus élevé de 85% de similarité est appliqué. Par exemple, si la valeur fournie pour l'attribut Nom est « Christophel » et que le nom réel est « Christopher », un résultat Correspondance complète est renvoyé conformément à la logique de correspondance floue. Ce système s'applique aux attributs de données *First Name*, *Last Name*, *Paternal Name* et *Maternal Name*. * **Attributs de données relatifs à la date de naissance et au document d'identité** Nous n'appliquons aucun type de correspondance floue aux attributs de données des catégories Date de naissance ou Document d'identité. Une correspondance exacte est requise pour ces champs. ### Exemples Voici des exemples de valeurs saisies pour des attributs de données qui respectent les critères de la logique de correspondance floue et génèrent un résultat Correspondance complète. | Attribut de données | Saisie | Enregistrement de la source de données | Résultat | | :- | :- | :- | :- | | first\_name | Christopher | Christopher | Correspondance complète | | first\_name | Christophel | Christopher | Correspondance complète | | first\_name | Chris | Christopher | Aucune correspondance | | last\_name | Smith | Smith | Correspondance complète | | last\_name | Smyth | Smith | Correspondance complète | | last\_name | Smitty | Smith | Aucune correspondance | ## Voir aussi * [Vue d'ensemble de la validation en base de données](https://docs.didit.me/fr/core-technology/database-validation/overview.md) : fonctionnement de bout en bout de l'API, registres pris en charge et tarifs. * [Codes de résultat](https://docs.didit.me/fr/core-technology/database-validation/database-validation-outcome-codes.md) : liste complète des codes de réponse des fournisseurs (personne décédée, mineur, document introuvable, discordance biométrique). * [Avertissements](https://docs.didit.me/fr/core-technology/database-validation/database-validation-warnings.md) : éléments signalés lorsqu'un service ne peut pas être exécuté en raison de données manquantes. * [Pays et services pris en charge](https://docs.didit.me/fr/core-technology/database-validation/database-validation-supported-countries.md) : liste de tous les registres actifs, champs requis et prix par appel. * [Rapports](https://docs.didit.me/fr/core-technology/database-validation/database-validation-report.md) : exportations mensuelles de facturation par service. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.