Passer au contenu principal
Le rapport de questionnaire contient le formulaire structuré présenté à un utilisateur, le chemin qu’il a emprunté à travers les éventuelles branches conditionnelles, ainsi que la réponse pour chaque élément visible. Il est renvoyé par nœud, de sorte que les workflows multi-instances (par exemple, un questionnaire par UBO) comportent une entrée par occurrence.
Rapport de questionnaire KYC Didit présentant les réponses structurées, les sections et les types d'éléments

Vue d’ensemble

Chaque réponse au questionnaire décrit :
  • La version du questionnaire vue par l’utilisateur (titre, description, langues, métadonnées de version, sections).
  • Les éléments visibles correspondant au chemin réellement emprunté par l’utilisateur dans le graphe du formulaire — les éléments masqués par la logique conditionnelle sont retirés de la réponse.
  • La réponse pour chaque élément interactif visible, sous la forme correspondant à son element_type.
  • Un unique statut pour l’ensemble de la réponse.
Les éléments de mise en page sont restructurés plutôt que de faire l’objet d’une réponse : chaque SECTION_HEADER devient une délimitation de section (son titre et sa description deviennent les title/description de la section), tandis que HEADING, PARAGRAPH et SEPARATOR restent dans items[] sans clé answer, afin que le rapport conserve la même structure visuelle que celle vue par l’utilisateur.

Où il apparaît

Le rapport de questionnaire apparaît sous la forme du tableau questionnaire_responses[] dans GET /v3/session/{sessionId}/decision/, aussi bien pour les sessions KYC que KYB, dès lors qu’une fonctionnalité de questionnaire a été exécutée. Le champ vaut null tant qu’aucune instance de questionnaire n’a démarré. Chaque entrée comporte un node_id afin que les workflows multi-instances puissent lever toute ambiguïté sur l’étape du graphe qui l’a produite.

Structure d’un élément

Consultez Réponse de questionnaire dans la référence des modèles de données pour le schéma canonique.
Les éléments SECTION_HEADER n’apparaissent jamais dans items[] — ils ouvrent une nouvelle section et fournissent ses title et description.

Types d’éléments

Un élément interactif visible auquel l’utilisateur n’a jamais répondu est renvoyé avec "answer": null.

Visibilité conditionnelle

Lorsqu’un questionnaire définit un graphe (logique conditionnelle), seuls les éléments situés sur le chemin réellement emprunté par l’utilisateur sont inclus. Un élément masqué par une branche que l’utilisateur n’a pas suivie n’apparaît pas dans sections[].items — même s’il existe dans le modèle. Les sections qui ne contiennent aucun élément visible sont totalement supprimées.

Valeurs de statut

Le status au niveau de la réponse prend l’une des trois valeurs possibles. En interne, le statut de base (Approved, ou In Review lorsque le workflow impose un examen manuel) est combiné avec toute règle de statut personnalisée correspondante selon l’ordre de priorité global de la plateforme : Declined > In Review > Approved ; un résultat Declined au niveau du questionnaire est ensuite mis en correspondance avec In Review afin que les opérateurs déterminent la décision finale lors de l’examen.

Avertissements

Les questionnaires émettent un unique code d’avertissement, généré lorsqu’une règle de statut personnalisée configurée sur le nœud du questionnaire correspond à une réponse : Le champ additional_data de l’avertissement contient field, operator, rule_value, actual_value, target_status et score lorsque la règle en définit un. Son log_type suit le statut cible de la règle : error pour Declined, warning pour In Review, information dans les autres cas. Contrairement aux autres fonctionnalités, l’entrée du questionnaire n’intègre pas de tableau warnings[] — les journaux des règles déclenchées sont enregistrés sur la session sous feature: "QUESTIONNAIRE" et apparaissent dans l’écran d’examen de la Console (voir également la liste des avertissements de vérification d’entreprise ; le même code s’applique aux sessions KYC).

Exemple — Questionnaire sur l’origine des fonds

Exemple — Non terminé

Lorsque l’utilisateur a atteint l’étape du questionnaire mais n’a pas encore soumis de réponses, la réponse est renvoyée avec status: "Not Finished" et "answer": null sur chaque élément visible. Une session qui n’a jamais atteint cette étape ne génère aucune entrée — questionnaire_responses reste null lorsqu’aucune instance n’existe.

Remarques

  • Les URL de fichiers expirent. Les entrées dans answer.files sont des URL pré-signées (validité de 4 heures par défaut). Appelez à nouveau l’endpoint de décision lorsque vous avez besoin d’URL actualisées.
  • Localisation. Les champs title, description et placeholder de l’élément, le label du choix, ainsi que les champs title/description de la section sont renvoyés en anglais lorsque le questionnaire le prend en charge, sinon dans la default_language du questionnaire. La value d’un choix reste stable d’une langue à l’autre, vous permettant de fonder votre logique métier sur celle-ci en toute sécurité.
  • La description de l’élément correspond à son texte d’aide. Tout élément peut en comporter une, questions comprises, et elle vaut null lorsqu’aucune n’est définie. Un élément SEPARATOR n’en a jamais.

Pages associées

Vue d'ensemble des questionnaires

Comment concevoir, versionner et associer des questionnaires à un workflow.

Modèles de données — Réponse au questionnaire

Schéma canonique champ par champ pour cet objet.

Récupérer la session

Référence de l’endpoint pour le payload de décision V3.
Dernière modification le 7 novembre 2026