Passer au contenu principal

Vue d’ensemble

La Recherche faciale est une recherche biométrique 1:N : Didit extrait le plus grand visage détecté dans votre champ user_image et le recherche dans l’index de recherche faciale de votre application — les visages enrôlés à partir de sessions de vérification, d’appels API autonomes sauvegardés, d’ajouts directs de visages sur des profils utilisateurs et de vos listes de blocage ou d’autorisation. Elle est distincte de Correspondance faciale, qui est 1:1 — Correspondance faciale compare un selfie avec la photo d’un document spécifique, tandis que Recherche faciale pose la question : « avons-nous déjà vu cette personne auparavant ? ». Deux comportements essentiels sont à comprendre avant d’analyser le rapport :
  • Seules les correspondances avec la liste de blocage entraînent un refus. Le champ face_search.status prend la valeur Declined uniquement lorsqu’un avertissement FACE_IN_BLOCKLIST ou POSSIBLE_FACE_IN_BLOCKLIST est déclenché. Les correspondances en double retournent à elles seules le statut Approved — inspectez matches et warnings, pas seulement status.
  • Persistance et enrôlement optionnels. Lorsque save_api_request=true (valeur par défaut), l’appel est conservé en tant que session de type API et le visage recherché est enrôlé dans votre index de recherche faciale. Les visages enrôlés par des appels de Recherche faciale sont exclus des futurs résultats de Recherche faciale, de sorte que des recherches répétées ne correspondent jamais entre elles. Transmettez save_api_request=false pour une requête ponctuelle : rien n’est stocké et le visage n’est pas enrôlé.

Où apparaissent les résultats

Recherche faciale est une API autonome. Les résultats de recherche sont renvoyés de manière synchrone, uniquement dans la réponse à POST /v3/face-search/, sous la forme d’un objet unique face_search au niveau racine :
Il n’y a pas de tableau au pluriel face_searches[] — la convention de tableau au pluriel utilisée par id_verifications[], aml_screenings[] et liveness_checks[] sur l’endpoint de décision de session ne s’applique pas ici. Lorsque save_api_request=true (valeur par défaut), l’appel est également conservé sous forme de session de type API :
  • Business Console — la session apparaît dans votre liste de sessions avec l’image recherchée, les correspondances et les avertissements.
  • GET /v3/session/{sessionId}/decision/ — récupérable en utilisant le request_id renvoyé comme identifiant de session. Les données conservées apparaissent sous la forme d’une entrée FACE_SEARCH dans features[] et d’un élément liveness_checks[] contenant les correspondances matches stockées (avec des valeurs match_image_url nouvellement signées) et les warnings — et non sous la forme d’un objet face_search.
Lorsque save_api_request=false, le champ request_id est un UUID de corrélation éphémère : la session n’est jamais stockée, elle ne peut donc pas être récupérée depuis la Console ou l’endpoint de décision.

Schéma

Consultez Recherche faciale dans la référence des modèles de données pour consulter les tableaux de champs faisant autorité. La structure ci-dessous reflète ce que l’endpoint renvoie réellement à l’exécution.
Notes sur les champs :
  • matches[] est limité à 5 entrées au-dessus du seuil de similarité minimal, classées par ordre décroissant de similarité (search_type=blocklisted_or_approved classe d’abord les entrées sur liste de blocage, puis sur liste d’autorisation, puis selon la similarité).
  • source indique l’origine de l’enrôlement du visage correspondant : session — une session de vérification ou un appel API autonome sauvegardé ; imported — un visage importé directement sur un profil utilisateur ; list_entry — un visage rattaché à l’une de vos listes ; retained_template — un gabarit biométrique sans image que l’application a conservé après la suppression de la session source. session_id, session_number, status et api_service sont à null pour les correspondances de type imported, list_entry et retained_template.
  • Les correspondances retained_template contiennent vendor_user_id, vendor_data et biometric_template_id ; match_image_url, user_details et tous les éléments liés à une session valent toujours null : la session à l’origine du visage n’existe plus et le gabarit ne contient aucune image ni donnée d’identité. Le champ is_blocklisted est toujours à false pour un gabarit conservé ; un visage sur liste de blocage est signalé séparément comme une correspondance de type list_entry. Vous pouvez purger le gabarit avec DELETE /v3/biometric-templates/{biometric_template_id}/.
  • api_service correspond au type d’API autonome de la session trouvée (en majuscules, par exemple PASSIVE_LIVENESS) et est à null lorsque le visage correspondant provient d’une session de vérification de workflow standard.
  • user_details provient de la vérification de document de la session correspondante. Pour les correspondances source: imported, ce champ est renseigné à partir du profil utilisateur (full_name renseigné, document_type/document_number à null) ; il est à null si aucune donnée d’identité n’existe (par exemple pour des sessions de détection du vivant uniquement).
  • Les avertissements utilisent une structure simplifiée par rapport aux avertissements de workflow : il n’y a pas de champ node_id. Le contrat de réponse documenté (FaceSearchResponseSerializer) déclare les cinq champs risk, additional_data, log_type, short_description, long_description ; le payload d’exécution contient en plus feature, qui vaut toujours "LIVENESS" ici. Consultez les avertissements de Recherche faciale.
  • Les correspondances pour un même utilisateur ne sont pas exclues — contrairement à la détection de doublons dans les workflows, l’endpoint autonome ne filtre pas les sessions antérieures ayant le même vendor_data. Ainsi, un utilisateur légitime récurrent correspondra à ses propres sessions précédentes.

Valeurs de statut

La valeur face_search.status au niveau racine est calculée à partir de warnings[]. Le status au niveau de la correspondance reflète le résultat de vérification de la session correspondante et fonctionne de manière indépendante. Remarque : lorsque l’image recherchée ne contient aucun visage détectable, l’API renvoie une erreur HTTP 400 avec {"error": "No face detected in the image"} avant qu’un objet face_search ne soit créé — aucun statut Declined n’est attribué dans ce cas. En cas de crédits insuffisants, l’API renvoie une erreur HTTP 403 avant tout traitement de l’image.

Exemples

Approuvé — correspondance en doublon, pas de liste de blocage

Refusé — correspondance avec la liste de blocage

Ressources associées

Lorsque save_api_request=true, les valeurs de match_image_url sont des URL signées à courte durée de vie — appelez à nouveau l’endpoint de décision de la session avec le request_id renvoyé pour en obtenir de nouvelles. Lorsque save_api_request=false, il s’agit de chemins de stockage internes non téléchargeables directement. Ne conservez de votre côté que l’ID de la session correspondante, le statut et similarity_percentage — ne conservez pas l’image biométrique sous-jacente.
Dernière modification le 7 novembre 2026