Validation en base de données : avertissements et codes

La fonctionnalité de Validation en base de données de Didit vérifie les données d’identité auprès de registres civils officiels — RENAPER (Argentine), Receita Federal (Brésil), Tribunal Electoral (Panama, biométrique), Junta Central Electoral (République dominicaine), et plus encore — facturée par requête réussie sans minimum mensuel. Lorsqu’aucun service ne peut s’exécuter (champs obligatoires manquants ou mal formés, registre indisponible), que le document lui-même ne peut pas être vérifié (il ne comporte pas l’identifiant requis par les services configurés — par exemple un passeport sans numéro d’identification national), ou que le résultat global n’est pas concluant (correspondance partielle, aucune correspondance), la fonctionnalité émet un avertissement sur la session. Si l’État émetteur n’est pas du tout activé dans le workflow, l’étape est ignorée silencieusement, sans avertissement ni facturation. Cette page documente chaque code d’avertissement, ce qui le déclenche et comment configurer la réponse du workflow.

Vue d’ensemble

Les avertissements sont générés à la fois dans les sessions de workflow et par l’API autonome (POST /v3/database-validation/). Les cinq risques sont associés à la fonctionnalité DATABASE_VALIDATION, apparaissent sur le rapport sous database_validations[].warnings[] et respectent la structure standard de l’objet d’avertissement (feature, risk, additional_data, log_type, short_description, long_description, node_id). Il n’existe aucun déclencheur de refus automatique strict pour la Validation en base de données. Les deux risques liés au résultat de correspondance, le risque de document obsolète et le risque de non-applicabilité correspondent à une action configurable (DECLINE, REVIEW ou NO_ACTION) ; COULD_NOT_PERFORM_DATABASE_VALIDATION est le seul comportement fixe — il fait toujours passer la fonctionnalité à l’état en cours d’examen.

Risques configurables

Paramètre	Code de risque	Comportement
Action en cas d’absence de correspondance	`DATABASE_VALIDATION_NO_MATCH`	`REVIEW` (valeur par défaut du workflow) fait passer la fonctionnalité à en cours d’examen ; `DECLINE` refuse ; `NO_ACTION` enregistre l’avertissement sans modifier le statut. Le paramètre `no_match_action` de l’API autonome a pour valeur par défaut `DECLINE`.
Action en cas de correspondance partielle	`DATABASE_VALIDATION_PARTIAL_MATCH`	`NO_ACTION` (par défaut) enregistre l’avertissement sans modifier le statut ; `REVIEW` fait passer la fonctionnalité à en cours d’examen ; `DECLINE` refuse.
Action en cas d’absence de correspondance	`DATABASE_VALIDATION_DOCUMENT_SUPERSEDED`	Partage le paramètre Action en cas d’absence de correspondance — il n’y a pas de réglage séparé. Le registre ayant contredit les données soumises, une organisation qui refuse en l’absence de correspondance refusera également un justificatif obsolète.
Action en cas de non-applicabilité	`DATABASE_VALIDATION_NOT_APPLICABLE`	`NO_ACTION` (par défaut) enregistre l’avertissement sans modifier le statut ; `REVIEW` fait passer la fonctionnalité à en cours d’examen ; `DECLINE` refuse. Se déclenche lorsque le document ne peut pas du tout être vérifié — il ne comporte pas l’identifiant utilisé par les services configurés pour interroger le registre (par exemple un passeport sans numéro d’identification national).

L’action configurée détermine également le log_type de l’avertissement : DECLINE → error, REVIEW → warning, NO_ACTION → information. Le résultat de correspondance lui-même est agrégé à partir des entrées validation de chaque service (toute correspondance complète → full_match ; sinon toute correspondance partielle → partial_match ; sinon no_match) — consultez les Méthodes de correspondance pour la logique décisionnelle complète qui détermine les résultats 1×1 / 2×2.

Avertissements générés

Tag	Description courte	Description
`COULD_NOT_PERFORM_DATABASE_VALIDATION`	Impossible d’effectuer la validation en base de données	Aucun service n’a retourné de résultat exploitable (`match_type` reste `null`) — généralement parce que des champs obligatoires sont manquants ou mal formés, ou que le registre a renvoyé une erreur. `additional_data` contient le récapitulatif, pour chaque service, des raisons pour lesquelles il n’a pas été exécuté (`reason`, `database_validation_errors`, `missing_required_fields_by_service`, `invalid_format_fields_by_service`, `field_reasons_by_service`) ; l’API autonome utilise `{ "validation_errors": [...] }` à la place. Vous n’êtes pas facturé lorsque cet avertissement se déclenche ; la fonctionnalité passe à l’état En cours d’examen jusqu’à ce que les données soient corrigées.
`DATABASE_VALIDATION_NOT_APPLICABLE`	Validation en base de données non applicable pour ce document	Le document fourni ne comporte pas l’identifiant requis par le ou les services de base de données configurés (`match_type` reste `null`) — par exemple, un passeport brésilien ne comporte pas de CPF, le registre du CPF ne peut donc pas être interrogé. Ce comportement est attendu pour ce type de document et n’indique pas de problème lié au document. `additional_data` contient le récapitulatif, pour chaque service, des raisons pour lesquelles il n’a pas été exécuté. Vous n’êtes pas facturé lorsque cet avertissement se déclenche. Action configurable (`NO_ACTION` par défaut).
`DATABASE_VALIDATION_PARTIAL_MATCH`	Correspondance partielle de la validation en base de données	Le `match_type` global est `partial_match` — certains champs vérifiés correspondaient au registre, mais pas tous. Action configurable (`NO_ACTION` par défaut).
`DATABASE_VALIDATION_NO_MATCH`	Aucune correspondance de la validation en base de données	Le `match_type` global est `no_match` — le registre n’a pas pu confirmer l’identité vérifiée. Action configurable (`REVIEW` par défaut dans les workflows, `DECLINE` sur l’API autonome).
`DATABASE_VALIDATION_DOCUMENT_SUPERSEDED`	Édition du document remplacée	Un service a renvoyé `DOCUMENT_SUPERSEDED` : le registre a confirmé la personne, mais l’édition du document présenté n’est pas celle enregistrée — une édition plus récente a depuis été émise. Déclenché indépendamment de `match_type`, qui reste `full_match` car tous les champs personnels correspondaient, ce qui rendrait sinon le constat invisible. `additional_data` indique les services qui l’ont signalé. Suit le paramètre No Match Action.

COULD_NOT_PERFORM_DATABASE_VALIDATION couvre deux situations différentes, et le long_description de l’avertissement (ainsi que, pour un échec par service, database_validation_errors[].message) indique désormais celle qui s’applique au lieu d’une seule phrase générique : les données vérifiées étaient manquantes ou mal formées avant qu’un quelconque service ne puisse être interrogé, ou un service a été interrogé et n’a pas renvoyé de résultat exploitable. Dans le second cas, lorsque le registre a signalé son propre détail de diagnostic pour cette tentative, ce détail est inclus dans le message afin que vous n’ayez pas à contacter le support pour en connaître la raison. Le service en amont n’est jamais nommé dans la réponse.

Lorsque COULD_NOT_PERFORM_DATABASE_VALIDATION ou DATABASE_VALIDATION_NOT_APPLICABLE se déclenche dans une session de workflow, la vérification est automatiquement relancée dès que les données manquantes sont renseignées sur la page de détail de la session dans la Console — enregistrer le champ réexécute la validation, et l’avertissement est supprimé en cas de succès. Cela fonctionne également lorsque l’action de non-applicabilité a refusé la session, de sorte qu’une session refusée peut être corrigée en modifiant les données. Pour DATABASE_VALIDATION_NOT_APPLICABLE, la réexécution est utile lorsque le document peut comporter l’identifiant mais que celui-ci n’a pas été lu (par exemple, un titre de séjour dont le numéro d’identité national n’a pas été extrait) ; les types de documents qui ne comportent jamais l’identifiant (par exemple, les passeports sans numéro d’identité national) conservent l’avertissement. Aucun frais ne s’applique aux services ignorés ; vous ne payez que lorsqu’un service renvoie un résultat facturable.

Exemple

{
  "warnings": [
    {
      "feature": "DATABASE_VALIDATION",
      "risk": "DATABASE_VALIDATION_NO_MATCH",
      "additional_data": null,
      "log_type": "warning",
      "short_description": "Database validation no match",
      "long_description": "The system identified a no match in the database validation, requiring further investigation.",
      "node_id": "feature_db_validation_1"
    }
  ]
}

Types d’avertissement

Chaque risque se voit attribuer une gravité en fonction de la configuration de votre application. Les gravités se divisent en trois catégories :

Voir aussi

Aperçu de la validation en base de données — fonctionnement de bout en bout de la fonctionnalité et registres pris en charge.
Rapport de validation en base de données — structure complète de la réponse, incluant validations[] par service.
Méthodes de correspondance — comment les résultats 1×1 / 2×2 (validation_type: one_by_one / two_by_two) sont dérivés des correspondances par service.
Codes de résultat — taxonomie complète par résultat avec les codes de détail spécifiques aux pays.
Pays et services pris en charge — tous les registres actifs, champs obligatoires et tarif par appel.
Modèles de données — validation en base de données — schéma canonique champ par champ.

Authentification

Vérification

Surveillance

Plateforme

Validation en base de données : avertissements et codes

Vue d’ensemble

Risques configurables

Avertissements générés

Exemple

Types d’avertissement

Voir aussi

​Vue d’ensemble

​Risques configurables

​Avertissements générés

​Exemple

​Types d’avertissement

​Voir aussi

Vue d’ensemble

Risques configurables

Avertissements générés

Exemple

Types d’avertissement

Voir aussi