> ## 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 : avertissements et codes > Avertissements de validation en base de données Didit : COULD_NOT_PERFORM_DATABASE_VALIDATION, registres inaccessibles ou champs manquants. La fonctionnalité 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é 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](https://docs.didit.me/fr/reference/data-models.md#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](https://docs.didit.me/fr/core-technology/database-validation/database-validation-matching-methods.md) 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**. | > [!NOTE] > > `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. > [!NOTE] > > 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 ```json theme={null} { "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](https://docs.didit.me/fr/core-technology/database-validation/overview.md) — fonctionnement de bout en bout de la fonctionnalité et registres pris en charge. * [Rapport de validation en base de données](https://docs.didit.me/fr/core-technology/database-validation/database-validation-report.md) — structure complète de la réponse, incluant `validations[]` par service. * [Méthodes de correspondance](https://docs.didit.me/fr/core-technology/database-validation/database-validation-matching-methods.md) — 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](https://docs.didit.me/fr/core-technology/database-validation/database-validation-outcome-codes.md) — taxonomie complète par résultat avec les codes de détail spécifiques aux pays. * [Pays et services pris en charge](https://docs.didit.me/fr/core-technology/database-validation/database-validation-supported-countries.md) — tous les registres actifs, champs obligatoires et tarif par appel. * [Modèles de données — validation en base de données](https://docs.didit.me/fr/reference/data-models.md#validation-en-base-de-données) — schéma canonique champ par champ. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.