Passer au contenu principal

Vue d’ensemble

Le rapport de correspondance faciale restitue une comparaison biométrique 1:1 entre le selfie en direct capturé pendant la détection du vivant et une image de référence — le plus souvent le portrait extrait de la pièce d’identité. Il renvoie un score de similarité unique compris entre 0 et 100, des URL signées pour les deux images comparées, la session source de l’image de référence, ainsi que les avertissements générés par la correspondance. Le rapport est généré une fois que l’utilisateur a terminé à la fois l’étape de détection du vivant et l’étape documentaire dans un workflow (ou, pour les workflows basés sur le portrait comme l’authentification biométrique, après la seule détection du vivant), ou directement via l’API de correspondance faciale autonome lorsque vous fournissez vous-même deux images faciales arbitraires. Chaque rapport comporte son propre status — indépendant du statut global de la session — qui reflète l’issue de la seule étape de correspondance faciale :
  • Approuvé — le score est supérieur au seuil d’examen et aucun avertissement de refus automatique ne s’est déclenché.
  • En cours d’examen — le score se situe entre les seuils de refus et d’examen, ou aucun score n’a pu être calculé et face_match_not_computed_action est défini sur REVIEW.
  • Refusé — le score est inférieur ou égal au seuil de refus, NO_REFERENCE_IMAGE s’est déclenché, ou aucun score n’a pu être calculé et face_match_not_computed_action est défini sur DECLINE.
  • Nouvelle soumission demandée — un réviseur a demandé à l’utilisateur de soumettre à nouveau cette étape depuis la console.
  • Non terminée — l’étape de correspondance faciale n’a pas encore produit de résultat (y compris pendant que l’utilisateur réessaie une capture ayant échoué).

Où il apparaît dans les réponses de l’API

Le rapport de correspondance faciale est transmis au sein du tableau face_matches[] — toujours un tableau JSON, jamais un objet face_match unique. Il est null jusqu’à ce qu’au moins une étape de correspondance faciale ait produit des données, et plusieurs entrées apparaissent lorsqu’un workflow exécute la correspondance faciale plusieurs fois. Un workflow d’Adaptive Age Verification le remplit également lorsque la solution de repli de vérification d’identité est exécutée : cette entrée indique le nœud d’estimation de l’âge comme son node_id, puisque le workflow ne possède pas de nœud de correspondance faciale propre.
  • API de décision de session — GET /v3/session/{sessionId}/decision/ renvoie face_matches[] au niveau racine. Voir Récupérer la décision de session.
  • Webhooks — les payloads session.status.updated incluent le même tableau face_matches[] une fois que l’étape a produit des données. Voir Webhooks.
  • API autonome de correspondance faciale — pour les comparaisons directes 1:1, voir API autonome de correspondance faciale.
Lisez response.face_matches[0] et itérez sur le tableau — la structure face_match au singulier mentionnée dans certains tutoriels plus anciens n’existe pas sur l’endpoint de décision v3.

Schéma

Le schéma canonique champ par champ se trouve sur la page de référence Modèles de données. Les champs ci-dessous reflètent ce schéma canonique.

Valeurs de statut

Les échecs dus à une faible similarité font l’objet d’une nouvelle tentative avant que le statut ne soit figé : l’utilisateur bénéficie d’un maximum de face_match_max_attempts captures (3 par défaut), et seul le score de la dernière tentative est appliqué. Des règles de statut personnalisées configurées sur le nœud de workflow peuvent également ajuster le statut résultant, en se combinant avec le statut dérivé du score selon l’ordre de priorité Declined > In Review > Approved.

Exemples

Approuvé — correspondance nette

En cours d’examen — similarité limite

Refusé — aucune image de référence pour la comparaison

Note de sécurité

Les URL signées pour source_image et target_image constituent des données biométriques et expirent après une courte fenêtre de validité. Considérez-les comme éphémères : ne les mettez pas en cache et ne les exposez pas publiquement. En règle générale, votre application n’a besoin que de status et de score — stockez le moins d’informations possible afin de minimiser les données biométriques présentes sur vos serveurs.

Ressources associées

Dernière modification le 7 novembre 2026