API de détection de fraude documentaire : guide d'intégration 2026

Une API de détection de fraude documentaire est un service web qui analyse automatiquement les pièces justificatives soumises par un utilisateur — identités, relevés bancaires, bulletins de salaire, actes notariés — afin d'identifier les altérations numériques, les métadonnées falsifiées, les incohérences de police ou les substitutions de photo. Contrairement aux workflows manuels, une telle API s'insère dans un pipeline d'onboarding ou de souscription existant et renvoie un score de confiance structuré en quelques secondes, permettant une prise de décision automatisée à l'échelle. Ce guide détaille les étapes d'intégration concrètes, les structures de requêtes et de réponses, ainsi que les exigences réglementaires applicables en 2026.

Pourquoi intégrer une API de détection de fraude documentaire ?

Intégrer une API de détection de fraude documentaire réduit directement l'exposition aux pertes liées aux faux documents tout en satisfaisant les obligations de vigilance imposées par les régulateurs européens. La problématique est significative : selon le rapport ACFE 2024 (Report to the Nations), seulement 37 % des fraudes documentaires sont détectées par des procédures manuelles, ce qui signifie que les deux tiers des falsifications échappent aux contrôleurs humains. En France, l'étude PwC 2025 indique que 69 % des entreprises ont été victimes d'une fraude économique au cours des deux dernières années, une proportion record qui touche aussi bien les banques que les assureurs et les entreprises de services.

Sur le plan réglementaire, les obligations se sont considérablement renforcées. L'Autorité de Contrôle Prudentiel et de Résolution (ACPR) exige des établissements financiers qu'ils mettent en place des dispositifs de vérification des pièces justificatives dans le cadre de leurs procédures KYC (Know Your Customer) et de lutte contre le blanchiment de capitaux. Le Règlement UE 2024/1689 sur l'intelligence artificielle (AI Act), entré en application progressive depuis août 2024, classe la vérification d'identité automatisée dans les systèmes à haut risque, imposant des exigences de robustesse, de transparence et d'audit trail. Par ailleurs, Tracfin, la cellule de renseignement financier française, attend des déclarants qu'ils documentent les anomalies détectées avant d'émettre une déclaration de soupçon.

Une API bien intégrée permet d'aligner technique et conformité : elle génère automatiquement les journaux d'audit requis, applique les règles de minimisation des données dès la collecte et produit une traçabilité exploitable par les équipes compliance.

Architecture technique : comment fonctionne l'intégration

L'intégration repose sur une API REST standard utilisant OAuth 2.0 pour l'authentification, des payloads JSON pour les métadonnées et multipart/form-data pour la transmission des fichiers binaires. Cette architecture est compatible avec l'ensemble des stacks modernes (Node.js, Python, Java, PHP) sans nécessiter de bibliothèque propriétaire.

Flux d'authentification OAuth 2.0

Le client envoie ses identifiants (client_id, client_secret) vers l'endpoint /oauth/token en échange d'un jeton d'accès JWT valable 3 600 secondes. Ce jeton est ensuite transmis dans l'en-tête Authorization: Bearer <token> à chaque requête. La rotation des jetons est gérée automatiquement via un refresh_token à durée de vie longue. Les secrets ne transitent jamais dans les URLs, conformément aux recommandations RGPD concernant la sécurité des transmissions (article 32).

Modes synchrone et asynchrone

Pour les documents de taille inférieure à 5 Mo, le mode synchrone retourne le résultat en moins de 2 secondes dans le corps de la réponse HTTP 200. Pour les dossiers volumineux ou les lots de documents multiples, le mode asynchrone est recommandé : la requête initiale retourne immédiatement un identifiant de traitement (job_id), et le résultat est récupéré via polling sur GET /result/{job_id} ou notifié par webhook. Ce second mode est particulièrement adapté aux workflows de souscription crédit ou d'onboarding KYC qui traitent plusieurs pièces simultanément.

Pour une vue d'ensemble des patterns d'intégration documentaire, voir également notre guide d'intégration API pour les développeurs.

Endpoints principaux et format des requêtes

Les endpoints principaux sont POST /analyze pour soumettre un document et GET /result/{id} pour interroger le statut d'un traitement asynchrone. Le tableau suivant résume l'ensemble des endpoints disponibles :

La requête POST /analyze utilise multipart/form-data avec deux champs : file (le document binaire) et metadata (un objet JSON contenant le type de document attendu, la juridiction et l'identifiant du dossier client). Voici un exemple de réponse synchrone typique :

{
  "job_id": "chk_a1b2c3d4e5f6",
  "status": "completed",
  "document_type": "passeport_fr",
  "confidence_score": 82,
  "risk_level": "medium",
  "signals": [
    {
      "type": "metadata_inconsistency",
      "detail": "Date de création EXIF antérieure à la date d'émission déclarée",
      "weight": 0.45
    },
    {
      "type": "font_anomaly",
      "detail": "Variation de corps typographique détectée sur le champ 'nom'",
      "weight": 0.30
    }
  ],
  "ocr_extracted": {
    "nom": "MARTIN",
    "prenom": "Sophie",
    "date_naissance": "1988-03-12",
    "numero_document": "13AA12345"
  },
  "processing_time_ms": 847,
  "jurisdiction": "FR",
  "rgpd_retention_until": "2026-12-19"
}

La plateforme CheckFile supporte plus de 3 200 types de documents dans 32 juridictions, ce qui couvre la quasi-totalité des pièces justificatives rencontrées dans les workflows européens d'onboarding et de crédit.

Interprétation des réponses et scores de confiance

Le score de confiance est un entier compris entre 0 et 100, où 100 indique un document dont aucune anomalie n'a été détectée et 0 signale une falsification quasi certaine. Le champ risk_level traduit ce score en une énumération exploitable directement par les règles métier. Le tableau ci-dessous détaille la correspondance recommandée :

Le tableau signals détaille chaque anomalie détectée avec son poids relatif dans le calcul du score global. Les types de signaux couvrent notamment : les incohérences de métadonnées EXIF, les anomalies typographiques, les traces de recadrage ou de superposition d'image, les numéros de série de document invalides pour la juridiction déclarée, et les signatures numériques manquantes ou altérées. L'OCR intégré couvre 24 langues pour les workflows multilingues, ce qui permet d'extraire et de valider les champs textuels des documents émis dans l'ensemble des États membres de l'UE ainsi que dans plusieurs juridictions extra-européennes.

Pour comprendre comment l'intelligence artificielle traite ces signaux à une échelle plus large, notre article sur la détection de fraude documentaire par IA développe les mécanismes de modélisation sous-jacents.

Cas d'usage par secteur d'activité

Les secteurs les plus exposés à la fraude documentaire partagent un point commun : ils collectent des pièces justificatives à fort enjeu dans des contextes de relation à distance. Le tableau suivant illustre les combinaisons document/signal les plus fréquentes par vertical :

Pour les établissements bancaires, la combinaison de l'API de détection documentaire avec un workflow KYC complet est détaillée dans notre page solutions banque et KYC. Les équipes compliance peuvent également consulter notre page sécurité et certifications pour vérifier les conditions de traitement des données personnelles.

Conformité RGPD, ACPR et obligations réglementaires

Le Règlement UE 2024/1689 sur l'IA (AI Act) classe les systèmes de vérification d'identité automatisée dans la catégorie des systèmes à haut risque, ce qui implique des obligations spécifiques pour les intégrateurs. Concrètement, tout système utilisant une API de détection de fraude documentaire dans un contexte réglementé doit documenter les critères de décision, conserver un journal d'audit horodaté, et permettre une voie de recours humaine pour les décisions défavorables.

Minimisation des données (RGPD art. 5 et 32)

L'article 32 du RGPD impose des mesures techniques et organisationnelles appropriées pour garantir la sécurité des données personnelles traitées. En pratique, l'API ne doit recevoir que les champs nécessaires à la vérification : transmettre un document complet sans masquer les données non pertinentes constitue un manquement. CheckFile propose une option de masquage automatique des champs sensibles avant stockage, configurable dans les paramètres de l'endpoint /analyze.

Conservation des journaux et Tracfin

Les établissements assujettis aux obligations de lutte contre le blanchiment (banques, assureurs, notaires, agents immobiliers) doivent conserver les preuves de leur diligence pendant cinq ans minimum. L'API génère automatiquement un enregistrement immuable de chaque analyse (audit_log_id), incluant l'horodatage, le hash du document transmis et le résultat de l'analyse, sans stocker le document source au-delà de la durée de traitement si l'option no_retention est activée. En cas de transmission d'une déclaration de soupçon à Tracfin, cet identifiant constitue la preuve de diligence technique.

Obligations spécifiques ACPR

L'ACPR précise dans ses lignes directrices que les procédures de vérification d'identité à distance doivent être documentées et auditables. L'utilisation d'une API de détection de fraude documentaire répondant aux critères de l'AI Act constitue un élément de démonstration de la robustesse du dispositif. Les établissements doivent néanmoins s'assurer que l'API utilisée ne constitue pas elle-même un système à haut risque non déclaré, ce qui implique de vérifier que le fournisseur a bien procédé à l'enregistrement requis auprès des autorités compétentes.

L'ACFE recommande par ailleurs de combiner la détection automatisée avec un dispositif de remontée d'alerte interne, afin que les scores critical déclenchent systématiquement une procédure de revue par un responsable compliance nommément désigné.

Pour les organisations souhaitant intégrer la détection des documents générés par IA et des deepfakes dans leur dispositif anti-fraude, la page détection deepfake et IA présente les capacités complémentaires disponibles. Un panorama complet des approches d'automatisation est disponible dans notre guide d'automatisation de la vérification documentaire.

---

Cet article est fourni à titre informatif uniquement et ne constitue pas un conseil juridique ou réglementaire. Les obligations applicables varient selon la nature de l'activité, le secteur et les décisions des autorités compétentes. Consultez un conseiller juridique qualifié avant de mettre en place un dispositif de vérification automatisée dans un contexte réglementé.

---

Questions fréquemment posées

Quelle est la différence entre OCR et détection de fraude documentaire ?

L'OCR (reconnaissance optique de caractères) extrait le contenu textuel d'un document numérisé sans évaluer son authenticité, tandis que la détection de fraude documentaire analyse l'ensemble des couches du fichier — métadonnées, cohérence visuelle, typographie, structure des données — pour identifier des signes de falsification. Un document peut passer l'OCR avec succès et présenter néanmoins des anomalies révélatrices d'une manipulation. Les deux fonctions sont complémentaires : l'OCR fournit les données à valider, la détection de fraude évalue leur fiabilité.

Comment une API de détection de fraude documentaire gère-t-elle les faux positifs ?

Les faux positifs sont gérés par une combinaison de seuils de score configurables, de décomposition des signaux et de circuit de revue humaine. En paramétrant le seuil de déclenchement de la revue humaine à 65 plutôt qu'à 85, les équipes peuvent absorber la variabilité liée à des documents légitimes de mauvaise qualité de numérisation sans augmenter le taux de rejets automatiques. La transparence du tableau signals permet à un analyste de comprendre en quelques secondes pourquoi un document a obtenu un score élevé et de confirmer ou d'infirmer l'alerte. Les intégrateurs peuvent également entraîner des règles d'exception pour des types de documents connus pour générer des faux positifs structurels dans leur flux.

L'API est-elle conforme au RGPD et à l'AI Act ?

Une API de détection de fraude documentaire conforme doit répondre à plusieurs critères cumulatifs : chiffrement des transmissions (TLS 1.3 minimum), durée de rétention des données personnelles limitée et documentée, journaux d'audit horodatés et immuables, et documentation du système au sens de l'AI Act (Règlement UE 2024/1689). L'article 32 du RGPD impose par ailleurs que les mesures de sécurité soient proportionnées au risque pour les personnes concernées. CheckFile publie sa documentation de conformité sur la page sécurité et maintient un registre de traitement accessible aux responsables de traitement clients.

Combien de temps faut-il pour intégrer une API de détection de fraude documentaire ?

Une intégration basique — authentification OAuth 2.0, envoi d'un document via POST /analyze, lecture du résultat JSON — peut être réalisée en une demi-journée par un développeur familier des APIs REST. Une intégration complète incluant le mode asynchrone, les webhooks, la gestion des erreurs, le circuit de revue humaine et les journaux d'audit prend généralement entre deux et cinq jours selon la complexité du workflow existant. Les intégrateurs peuvent consulter la page tarifs pour évaluer les options de support à l'intégration disponibles selon le plan souscrit.

Quels formats de fichiers sont acceptés par une API de détection de fraude documentaire ?

Les formats acceptés couvrent typiquement les images haute résolution (JPEG, PNG, WebP avec une résolution minimale recommandée de 300 DPI) et les documents PDF, y compris les PDF natifs et les PDF images. Certaines APIs acceptent également les fichiers TIFF utilisés dans les workflows de numérisation documentaire d'entreprise. Les fichiers compressés ou chiffrés doivent être décompressés avant transmission. La taille maximale par fichier est généralement de 20 Mo pour le mode synchrone et de 50 Mo pour le mode asynchrone, avec des limites de lot configurables pour les traitements en volume.