[[:identifier_les_etapes_en_echec|Français]] | [[:en:identifier_les_etapes_en_echec|English]]
----

====== 📄 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 🚀.

===== 1. 📌 Erreurs majeures : ''all_status_codes'' =====

**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 [[https://id360docaposte.com/fr/documentation/status-codes|ici]])
  * ''message'' : une description des validations échouées

**Exemple** :
<code json>
{
  "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"
      }]
}
</code>

**🎯 Utilité** : Identification des erreurs majeures.

-----

===== 2. 📄 Détail des validations : ''validations'' =====

**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** :
<code json>
{
  "ref": "IDENTITY.FIRST_NAME.first_name",
  "is_valid": false,
  "fields": [...]
}
</code>

**🎯 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**.

-----

===== 3. 🆚 Comparaisons entre sources : ''comparisons'' =====

**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** :
<code json>
{
  "ref": "KBIS.SIREN.siren",
  "is_equivalent": false,
  "field1": {...},
  "field2": {...}
}
</code>

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

-----

===== 4. ⚙️ Règles personnalisées : ''customs'' =====

**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** :
<code json>
{
  "ref": "IDENTITY_DOCUMENT.document_number",
  "is_valid": false,
  "fields": [...]
}
</code>

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

-----


===== 5. 🔢 Analyse par step : ''steps'' =====

**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** :
<code json>
{
  "steps": {
    "id_document": {
      "status": "KO",
      "status_codes": [
      {
        "code": "MDL_INPUT_INVALID",
        "message": "No MRZ could be read on the uploaded image(s)"
      }
    ]
  }
}
</code>

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

-----

===== ✅ Résumé =====

^ Élément          ^ Chemin JSON                                                  ^ Vérification                                                  ^                      
| All Status Code  | ''all_status_code''                                          | ''status_code'' existe     | 
| Validations      | ''finalizer_reports > validator_report > validations''       | ''is_valid: false''        |                                   
| Comparaisons     | ''finalizer_reports > validator_report > comparisons''       | ''is_equivalent: false''   |
| Customs          | ''finalizer_reports > validator_report > customs''           | ''is_valid: false''        |
| Étapes (steps)   | ''steps > [nom_step] > status'' + ''status_codes''           | Si ''status: KO'', analyser les ''status_codes'' associés     |