Capture photo in-app ou fichier envoyé : quel risque de fraude ?

Forcer la capture photo dans l'application plutôt que d'accepter un fichier envoyé depuis la galerie réduit un vecteur de fraude précis — l'image recyclée, éditée ou recapturée d'écran — mais ne supprime ni la fraude par injection vidéo ni le besoin d'une analyse forensique du document lui-même. Les deux méthodes de collecte restent vulnérables si elles ne sont pas combinées à une détection de vivacité et à une vérification du contenu du document.

Qu'est-ce que la capture photo in-app en vérification documentaire ?

La capture photo in-app désigne l'usage obligatoire de l'appareil photo du terminal, déclenché depuis l'application ou le navigateur du parcours de vérification, sans possibilité de sélectionner un fichier existant dans la galerie ou le disque. Le SDK contrôle en direct le flux de la caméra : cadrage assisté, détection de reflets, guidage pour photographier les deux faces d'une pièce d'identité, parfois complétés par un défi de vivacité (cligner des yeux, tourner la tête).

Le téléversement de fichier, à l'inverse, accepte n'importe quelle image déjà présente sur l'appareil : capture d'écran, scan, photo prise des semaines plus tôt, ou fichier reçu par un tiers. Le contrôle d'upload classique vérifie le format, la résolution et la lisibilité des champs OCR du fichier reçu — jamais son origine.

Pourquoi le téléversement de fichier facilite trois familles de fraude

Le téléversement de fichier ouvre la porte à la réutilisation, à l'édition et à la recapture d'écran, trois techniques qui exploitent l'absence de contrôle sur la provenance de l'image. Un fraudeur peut envoyer la même pièce d'identité volée à plusieurs services, éditer un champ dans un logiciel de retouche avant l'envoi, ou photographier un document falsifié affiché sur un second écran pour masquer les traces de montage — une technique documentée en détail dans notre analyse de la détection de recapture d'écran.

Les métadonnées EXIF, souvent présentées comme un garde-fou, se dégradent dès que le fichier transite par un réseau social, une messagerie ou un simple copier-coller : la plupart de ces canaux suppriment les données EXIF d'origine, laissant un fichier « propre » impossible à distinguer d'une photo légitime récente. Notre guide sur l'analyse des métadonnées EXIF détaille pourquoi cette analyse reste utile mais jamais suffisante seule.

Ce que change réellement la capture in-app

La capture in-app déplace le point de contrôle du fichier reçu vers le flux caméra lui-même, ce qui neutralise la réutilisation passive d'images mais introduit une nouvelle surface d'attaque : l'injection. Une caméra virtuelle ou un pilote modifié peut faire croire au SDK qu'un flux vidéo préenregistré ou généré provient d'une caméra physique, sans qu'aucune photo n'ait réellement été prise devant l'objectif.

La limite structurelle : injection vidéo et deepfake en temps réel

Des chercheurs ont documenté en 2026 une boîte à outils Android capable d'injecter une vidéo préenregistrée, une image fixe ou un flux contrôlé à distance directement dans le pipeline de capture d'une application, en se faisant passer pour la caméra physique du téléphone (ID Tech, analyse de la boîte à outils Android de contournement KYC). Cette attaque opère au niveau du système d'exploitation, en amont de l'application — elle n'exploite donc aucune faille de la capture in-app en tant que telle, mais contourne l'hypothèse implicite selon laquelle « caméra activée » signifie « image authentique ».

Le secteur distingue deux familles de menaces : les attaques de présentation (PAD), où un objet physique — écran, impression, masque — est placé devant la caméra, et les attaques par injection (IAD), où le flux vidéo est remplacé avant même d'atteindre l'objectif. La norme ISO/IEC 30107-3 encadre les tests de résistance PAD ; la résistance aux IAD relève de la vérification d'intégrité logicielle et de la liaison cryptographique de session, un chantier distinct que la seule capture in-app ne couvre pas.

Ce que recommandent les référentiels techniques

Le référentiel NIST SP 800-63A, qui encadre la vérification d'identité à distance de niveau IAL2 aux États-Unis, ne rend pas la détection de vivacité obligatoire mais la recommande fortement pour écarter les attaques de présentation les plus simples ; au niveau IAL3, il exige une transmission vidéo continue en haute résolution supervisée par un opérateur humain. En France, l'ACPR attend des établissements assujettis qu'ils journalisent la capture du document, la détection de vivacité et la comparaison faciale à des fins d'audit, sans imposer une méthode de collecte unique.

Le règlement eIDAS 2 et le déploiement du portefeuille européen d'identité numérique (EUDI Wallet) prévu d'ici décembre 2026 déplacent progressivement le sujet : à terme, les attributs d'identité seront présentés sous forme d'assertions cryptographiques signées plutôt que de photos de document, ce qui rend la question capture vs upload obsolète pour les parcours compatibles avec le portefeuille. En attendant cette bascule, la donnée biométrique associée à la capture reste une catégorie particulière au sens du RGPD, et la CNIL rappelle que sa collecte doit rester strictement proportionnée à la finalité de vérification.

Ce que demandent les équipes produit sur les forums spécialisés

Les discussions entre développeurs et équipes produit qui implémentent des parcours KYC reviennent régulièrement sur deux questions concrètes. La première porte sur l'expérience utilisateur : pourquoi bloquer l'upload alors qu'il est plus rapide, notamment pour les utilisateurs qui ont déjà scanné leur pièce d'identité pour une autre démarche ? La réponse tient à l'arbitrage risque/friction — un upload accepté sans contrôle de provenance multiplie les faux positifs de réutilisation, ce qui coûte plus cher en révision manuelle que la friction ajoutée par la caméra.

La seconde question porte sur la fiabilité perçue : certains évoquent des applications qui « forcent la caméra » tout en générant automatiquement horodatage et géolocalisation sur chaque photo prise, un signal utilisé comme preuve d'authenticité de bas niveau. Ce mécanisme fonctionne pour de la preuve d'usage (photo d'état des lieux, preuve de livraison) mais n'équivaut pas à une vérification documentaire : l'horodatage prouve quand la photo a été prise, pas que le document photographié est authentique.

Comment arbitrer capture in-app et upload dans votre parcours

1. Réservez le téléversement aux documents non falsifiables facilement : relevés bancaires PDF signés numériquement, factures avec QR code de vérification.
2. Imposez la capture in-app pour les pièces d'identité et justificatifs à fort enjeu, avec détection de vivacité active et non un simple test statique.
3. Ajoutez une analyse forensique du document reçu dans les deux cas : la capture in-app réduit le risque de réutilisation, elle ne remplace pas l'analyse de cohérence interne du document.
4. Journalisez la méthode de collecte utilisée pour chaque dossier, afin de pouvoir justifier la procédure en cas de contrôle ACPR ou de déclaration de soupçon.
5. Prévoyez une voie de recours humaine pour les utilisateurs dont la caméra échoue à plusieurs reprises, sans dégrader le niveau de contrôle appliqué.

Pour une vue d'ensemble des méthodes de vérification documentaire, notre guide de vérification des documents détaille les briques complémentaires à assembler autour du choix capture vs upload. Les solutions bancaires et KYC de CheckFile combinent ces deux étapes de collecte avec une analyse documentaire multi-couche, et notre page sécurité détaille les certifications et pratiques de traitement des données biométriques associées.

Ni la capture in-app ni l'upload ne détectent seuls un document généré par intelligence artificielle : les signaux de génération IA — cohérence de texture, artefacts de modèle, absence de bruit de capteur naturel — s'analysent en complément des contrôles de capture existants. Notre page dédiée à la détection de deepfakes et de documents générés par IA présente cette couche complémentaire, sans prétendre détecter à elle seule l'intégralité des falsifications possibles.

Questions fréquemment posées

La capture photo in-app empêche-t-elle toute fraude documentaire ?

Non. Elle réduit fortement la réutilisation d'images et la recapture d'écran, mais reste vulnérable à l'injection vidéo si aucune vérification d'intégrité du flux caméra n'est en place. Elle doit être combinée à une analyse forensique du document.

Pourquoi certaines applications acceptent-elles encore l'upload de fichier ?

Pour des raisons d'expérience utilisateur et d'accessibilité — certains appareils ou navigateurs limitent l'accès caméra — et parce que tous les documents ne présentent pas le même niveau de risque. Un relevé bancaire PDF signé numériquement n'a pas le même profil de fraude qu'une pièce d'identité.

Les métadonnées EXIF suffisent-elles à détecter une fraude sur un fichier téléversé ?

Non. Elles sont souvent absentes après passage par un réseau social ou une messagerie, et un fraudeur averti peut fabriquer des métadonnées EXIF crédibles. L'analyse EXIF reste un indice complémentaire, jamais une preuve à elle seule.

La capture in-app est-elle obligatoire selon la réglementation en France ?

L'ACPR n'impose pas une méthode de collecte unique mais attend une procédure documentée, journalisée et proportionnée au risque. La capture in-app avec détection de vivacité est généralement recommandée pour les pièces d'identité dans les parcours à distance à fort enjeu.

Le futur portefeuille européen d'identité numérique (EUDI Wallet) rendra-t-il ce débat obsolète ?

En partie. Pour les parcours compatibles avec eIDAS 2 et l'EUDI Wallet, l'utilisateur présentera des attributs cryptographiques vérifiés plutôt qu'une photo de document, ce qui déplace le contrôle vers la vérification de signature plutôt que vers la méthode de capture de l'image.