Blog · 4 août 2026

Recherche faciale 1:N : Retrouver tous les comptes contrôlés par une même personne (FR)

Un seul appel d'API permet de rechercher un visage parmi tous vos utilisateurs vérifiés et de retourner chaque compte correspondant avec votre propre identifiant.

Par Didit4 août 2026Mis à jour le 4 août 2026

Un opérateur gérant quarante comptes sur votre plateforme a quarante adresses e-mail, probablement quarante instruments de paiement, et peut-être quarante appareils. Ce qu'il n'a pas, ce sont quarante visages.

Si une partie de votre flux d'accès capture un selfie, vous détenez déjà l'identifiant qui est réellement coûteux à multiplier. La recherche faciale 1:N est l'appel qui l'utilise — une requête, un visage, et tous les comptes de votre propre système que la même personne a vérifiés vous sont retournés.

Elle est gratuite avec la vérification d'identité Didit, elle répond en moins de deux secondes et elle s'exécute automatiquement pendant la détection du vivant lors d'une session de vérification.

Points clés à retenir

POST /v3/face-search/ recherche un visage par rapport aux visages que votre propre application a enregistrés — sessions exécutées avec save_api_request=true — et non un index global partagé.
Les correspondances sont retournées avec votre propre vendor_data sur chacune, de sorte que les résultats sont directement mappés à vos identifiants de compte.
Deux modes : most_similar pour la déduplication et les utilisateurs récurrents, blocklisted_or_approved pour le filtrage par liste noire.
Le status est "Declined" uniquement en cas de correspondance avec une liste noire. Les doublons retournent "Approved" avec un avertissement DUPLICATED_FACE — informationnel par conception, car la politique de déduplication vous appartient.
La réponse est un objet face_search singulier, et non un tableau. Cela surprend les utilisateurs.
Gratuit avec la vérification Didit. Réponse en moins de deux secondes. S'exécute automatiquement pendant la détection du vivant.

Ce que signifie 1:N et pourquoi c'est le bon outil

Une correspondance faciale 1:1 répond à la question « est-ce la personne sur ce document ? » C'est une question de vérification, et c'est ce qui se passe lors de l'intégration.

Une recherche 1:N répond à une question différente : « parmi toutes les personnes que j'ai déjà vérifiées, est-ce l'une d'entre elles ? » Une image est entrée, et toutes les correspondances dans votre index sont sorties.

Pour l'abus de compte coordonné, la deuxième question est celle qui compte. Le rapport d'Anthropic sur les campagnes de distillation décrivait une attribution construite à partir de signaux relationnels — méthodes de paiement partagées, synchronisation coordonnée, infrastructure partagée. Une recherche biométrique 1:N est la même classe de signal, provenant de l'identifiant le plus coûteux qu'un opérateur doit multiplier.

L'index est le vôtre. La recherche faciale s'exécute sur les visages que votre propre application a enregistrés via des vérifications précédentes — sessions avec save_api_request=true, ou détection du vivant passive avec save_api_request=true. Il ne s'agit pas d'une recherche parmi les utilisateurs d'autres clients Didit. Si vous n'avez pas enregistré de visages, il n'y a rien à rechercher.

L'API

Requête

curl -X POST 'https://verification.didit.me/v3/face-search/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -F 'user_image=@./selfie.jpg' \
  -F 'search_type=most_similar' \
  -F 'save_api_request=true' \
  -F 'vendor_data=acct_8842'

multipart/form-data, authentifié avec x-api-key.

Obligatoire : user_image — jpg, jpeg, png, tiff ou webp, maximum 5 Mo. Les PDF ne sont pas acceptés. L'image doit contenir au moins un visage détectable ; lorsque plusieurs sont présents, le plus grand cadre de délimitation l'emporte.

Optionnel :

search_type — most_similar (par défaut) pour la déduplication et la détection des utilisateurs récurrents, ou blocklisted_or_approved pour le filtrage par liste noire.
save_api_request — enregistrer cette image dans votre index.
vendor_data — votre propre identifiant pour le sujet.

Réponse

La réponse contient un objet face_search singulier. La plupart des fonctionnalités Didit renvoient des tableaux pluriels, c'est donc la seule forme qu'il convient de lire attentivement avant d'écrire l'analyseur.

{
  "request_id": "...",
  "face_search": {
    "status": "Approved",
    "total_matches": 12,
    "matches": [
      {
        "session_id": "...",
        "session_number": 4471,
        "similarity_percentage": 97.4,
        "vendor_data": "acct_3310",
        "verification_date": "2026-06-02T09:14:00Z",
        "user_details": { },
        "match_image_url": "...",
        "status": "Approved",
        "is_blocklisted": false
      }
    ],
    "user_image": { "entities": [] },
    "warnings": []
  }
}

Les champs qui portent l'enquête :

total_matches — combien de comptes partagent ce visage.
vendor_data sur chaque correspondance — votre identifiant, donc une liste de correspondances est immédiatement une liste de comptes.
similarity_percentage — la force de chaque correspondance individuelle.
verification_date — la chronologie. Douze comptes vérifiés sur onze mois se lisent différemment de douze vérifiés en un après-midi.
is_blocklisted — si cette correspondance est déjà sur votre liste noire.
session_id — le pivot vers tout ce que cette session a capturé d'autre, y compris ses avertissements d'appareil et de réseau.

Sémantique de l'état

C'est le comportement le plus important de tout le point de terminaison :

status est "Declined" uniquement lorsqu'au moins une correspondance de liste noire est trouvée. Les correspondances purement dupliquées retournent "Approved".

Un doublon n'est pas un refus. C'est une information. Didit refuse délibérément de prendre la décision de déduplication pour vous, car les doublons ont des explications légitimes et vous seul connaissez les règles de votre produit.

Avertissements

Avertissement	Signification
`FACE_IN_BLOCKLIST`	Correspondance définitive avec la liste noire — rejeter
`POSSIBLE_FACE_IN_BLOCKLIST`	Correspondance limite en dessous du seuil strict — acheminer vers une révision manuelle
`DUPLICATED_FACE`	Ce visage est déjà vérifié sous un `vendor_data` différent
`POSSIBLE_DUPLICATED_FACE`	Doublon limite
`MULTIPLE_FACES_DETECTED`	Plus d'un visage dans l'image soumise

Modes d'échec

HTTP 400 — aucun visage détecté dans user_image. Demandez une nouvelle prise.
HTTP 403 — plus de crédits.
status: "Declined" avec FACE_IN_BLOCKLIST — correspondance définitive. Rejeter.
POSSIBLE_FACE_IN_BLOCKLIST — en dessous du seuil strict. Révision manuelle.
DUPLICATED_FACE — déjà vérifié sous un vendor_data différent. Fusionner, bloquer ou autoriser selon votre politique.

La voie automatique

Souvent, vous n'avez pas besoin d'appeler le point de terminaison du tout. La recherche faciale s'exécute automatiquement pendant la détection du vivant au cours d'une session de vérification :

Les données biométriques faciales sont comparées à tous les utilisateurs précédemment vérifiés.
Les comptes potentiellement dupliqués sont identifiés par similarité faciale.
Les correspondances sont signalées selon vos seuils de similarité configurés.
Les visages sont vérifiés par rapport à votre liste noire, et une correspondance de liste noire refuse automatiquement la vérification.

Ainsi, pour tout niveau où vous effectuez déjà une vérification complète, la détection des doublons est incluse sans coût supplémentaire et sans appel supplémentaire. Le point de terminaison autonome est destiné aux cas que le flux de session ne couvre pas — enquêter sur un compte après coup, filtrer une image que vous avez obtenue d'une autre manière, ou changer le search_type pour exécuter une recherche axée sur la liste noire sur une image que vous détenez déjà.

Transformer les correspondances en carte d'acteurs

Le flux de travail pratique, à partir d'un compte suspect :

Rechercher le visage. total_matches: 12 — douze comptes, une personne.
Lire le vendor_data. Douze de vos propres identifiants de compte, aucune jointure requise.
Lire la chronologie. Regrouper les valeurs de verification_date. Les comptes créés par à-coups sont opérationnellement différents des comptes créés sur plusieurs années.
Pivoter sur session_id. Récupérer les avertissements d'appareil et de réseau de chaque session. Les visages qui partagent DUPLICATED_DEVICE_FINGERPRINT renforcent le regroupement ; les comptes sur des appareils non liés peuvent être un arrangement différent.
Développer. Les appareils et les plages IP identifiés à l'étape 4 attireront les comptes que la recherche faciale a manqués — car une personne différente a effectué ces vérifications.
Décider une fois, appliquer sur les identifiants. Si le regroupement est confirmé comme un abus, publiez le reference_session_id confirmé dans chaque liste noire de type d'entrée qui vous intéresse — visage, appareil, IP, e-mail, téléphone, document. C'est un appel par liste, et chaque appel extrait automatiquement la bonne valeur de cette session, de sorte que rien n'est retapé manuellement.

Six étapes, un point de départ, et aucune inspection d'invite nulle part. La couche de trafic vous indique que quelque chose ne va pas avec ce compte. Cela vous indique combien de comptes cela représente réellement.

Il est important de le dire clairement : une recherche faciale 1:N n'empêche pas l'extraction de modèle et ne la détecte pas. La recherche faciale n'a aucune visibilité sur votre trafic API. Elle résout les comptes en personnes, ce qui vous permet d'agir sur une alerte sur tout un regroupement au lieu d'une seule ligne. Les contrôles de sortie au niveau du modèle et la détection sémantique du trafic sont des couches distinctes, et ils restent la responsabilité du fournisseur de modèle.

Cas d'utilisation

Plateformes API d'IA résolvant une alerte comportementale dans l'ensemble complet de comptes contrôlés par un opérateur.

Abus de niveaux gratuits et de crédits — une personne, de nombreux comptes d'essai, est le même problème de détection avec des enjeux moindres.

Places de marché et plateformes de services détectant les vendeurs, chauffeurs ou coursiers bannis qui se réinscrivent.

iGaming appliquant les règles de compte unique et d'auto-exclusion, où un joueur exclu qui revient est un échec réglementaire, pas seulement un cas d'abus.

Services financiers identifiant les réseaux d'identité synthétiques où un seul visage réel est réparti sur de nombreuses identités fabriquées.

Questions fréquemment posées

Mon index de visages est-il partagé avec d'autres clients Didit ?

Non. La recherche faciale s'exécute sur l'index que votre propre application a construit grâce à vos propres vérifications. Il ne s'agit pas d'une recherche inter-clients.

Qu'est-ce qui contrôle l'entrée d'un visage dans l'index ?

save_api_request=true sur une session de vérification ou un appel de détection du vivant passif. Vous décidez ce qui est enregistré et vous contrôlez la rétention, conformément à votre propre avis de confidentialité et à votre base juridique pour le traitement des données biométriques.

Quel seuil de similarité dois-je utiliser ?

Sachez où le réglage s'applique. Sur le point de terminaison autonome, les bandes de similarité qui séparent les correspondances confirmées (FACE_IN_BLOCKLIST, DUPLICATED_FACE) des correspondances possibles (POSSIBLE_FACE_IN_BLOCKLIST, POSSIBLE_DUPLICATED_FACE) sont fixées en interne — le réglage du seuil par application s'applique à la vérification du vivant du flux de travail, et non à POST /v3/face-search/. Ainsi, sur le chemin autonome, lisez le similarity_percentage par correspondance et appliquez votre propre barre dans la logique de l'application, et traitez les avertissements POSSIBLE_* comme votre file d'attente de révision plutôt que votre file d'attente de refus.

Quelle est sa rapidité à grande échelle ?

Réponse en moins de deux secondes.

Puis-je rechercher un visage qui n'a jamais été soumis à la vérification Didit ?

Oui. Toute user_image dans un format accepté fonctionne. Si aucun visage n'est détecté, l'appel renvoie HTTP 400.

Est-ce vraiment gratuit ?

Oui — la recherche faciale 1:N est gratuite avec la vérification d'identité Didit. Il n'y a pas de frais par recherche. Vous payez pour les vérifications qui construisent l'index, à 0,33 $ pour l'ensemble complet, avec les 500 premières vérifications gratuites chaque mois.

Que se passe-t-il si la même personne a légitimement deux comptes ?

Alors DUPLICATED_FACE est exactement le signal informatif qu'il est censé être — c'est pourquoi il ne refuse pas. Fusionnez-les, autorisez-les ou demandez à l'utilisateur, selon les règles de votre produit.

Prêt à commencer ?

La recherche faciale est disponible sur chaque compte Didit, sans produit séparé à acheter.

Lisez la documentation — Présentation de la recherche faciale 1:N et l'API des listes pour les listes noires de visages.
Découvrez le produit — Vérification des utilisateurs.
Consultez les tarifs — La recherche faciale 1:N est gratuite ; le pack de vérification qui construit l'index coûte 0,33 $.
Commencez gratuitement — business.didit.me, 500 vérifications KYC par mois sans frais.

Continue ta lecture