📄 Comment identifier les étapes en échec dans un rapport JSON ID360

Lorsqu'une vérification ID360 retourne un statut KO ❌, il est possible d’en analyser la cause grâce à la structure du fichier JSON. Voici les chemins à suivre pour retrouver les informations utiles 🔍.

⚠️ Important : Vous devez analyser l’ensemble des étapes décrites dans ce guide 🗂️, même si certaines clés ou sections du fichier JSON ne sont pas présentes à l’instant T dans votre parcours actuel.
Chaque clé du JSON correspond à une configuration précise du parcours 🛠️.

🔄 Si la configuration de votre parcours évolue (ajout ➕, suppression ➖ ou modification ✏️ d’étapes ou de contrôles), la liste des erreurs possibles évoluera également.
Ainsi, l’absence d’une clé dans le JSON aujourd’hui ne garantit pas qu’elle sera absente demain.

✅ Pour cette raison, il est essentiel de parcourir toutes les étapes mentionnées dans ce guide afin d’anticiper et de traiter correctement les évolutions futures 🚀.

Chemin JSON : all_status_code

Ce tableau contient des erreurs majeures détectées durant la vérification.

Chaque élément status_code contient :

• code : le code d’erreur (ex. VLD_VALIDATION_KO, liste exhaustive ici)
• message : une description des validations échouées

Exemple :

{
  "all_status_codes": [{
     "status_code": {
        "code": "VLD_VALIDATION_KO",
	"message": "1 validations failed: . Max allowed: 0"
        },
        "where": "ID360"
      },{
     "status_code": {
	"code": "MDL_INPUT_INVALID",
	"message": "No MRZ could be read on the uploaded image(s)"
       },
       "where": "id_document"
      }]
}

🎯 Utilité : Identification des erreurs majeures.

Chemin JSON : finalizer_reports > validator_report > validations

Chaque validation représente une règle métier appliquée à une donnée.

Vérifier :

• is_valid: false → indique un échec
• ref : identifiant de la règle (ex. IDENTITY.FIRST_NAME.first_name)
• fields : données concernées

Exemple :

{
  "ref": "IDENTITY.FIRST_NAME.first_name",
  "is_valid": false,
  "fields": [...]
}

🎯 Utilité : Identifier quelles données utilisateur ont échoué aux contrôles.

⚠️ Subtilité : Lors de la comparaison du nom de famille, deux contrôles sont effectués : l’un sur le nom d’usage, l’autre sur le nom de naissance. Par conséquent, vous verrez apparaître deux fois le champ “ref”: “IDENTITY.NAME.name” dans le rapport. Si l’un des deux contrôles est validé, la comparaison du nom est à considérer comme réussie.

Chemin JSON : finalizer_reports > validator_report > comparisons

Ces blocs comparent des valeurs issues de plusieurs sources (documents vs saisie utilisateur, documents entre eux…).

Vérifier :

• is_equivalent: false → la comparaison a échoué
• ref : la règle concernée
• field1 et field2 : les deux valeurs comparées

Exemple :

{
  "ref": "KBIS.SIREN.siren",
  "is_equivalent": false,
  "field1": {...},
  "field2": {...}
}

🎯 Utilité : Détecter des incohérences entre documents ou avec les données saisies.

Chemin JSON : finalizer_reports > validator_report > customs

Ces contrôles sont propres au client ou à certaines typologies de documents.

Vérifier :

• is_valid: false → la règle personnalisée a échoué
• ref : nom de la règle
• fields : données analysées

Exemple :

{
  "ref": "IDENTITY_DOCUMENT.document_number",
  "is_valid": false,
  "fields": [...]
}

🎯 Utilité : Comprendre les échecs sur des règles spécifiques définies pour un client donné.

Chemin JSON : steps

Le bloc steps contient les différentes étapes du parcours. Pour chaque step, vous devez :

• Lire le champ status
• Si la valeur est KO, parcourir la liste status_codes à l'intérieur de ce step pour en comprendre la ou les causes

Exemple :

{
  "steps": {
    "id_document": {
      "status": "KO",
      "status_codes": [
      {
        "code": "MDL_INPUT_INVALID",
        "message": "No MRZ could be read on the uploaded image(s)"
      }
    ]
  }
}

🎯 Utilité : Permet d'isoler les étapes qui ont échoué et d'obtenir des détails contextuels sur les anomalies rencontrées.