Résumé exécutif
Une capture d’écran n’est pas une preuve auto-suffisante. C’est une représentation visuelle d’un état d’affichage à un moment donné. Pour qu’elle devienne probante, il faut démontrer son authenticité, son intégrité et son contexte de production. [1] [3] [4] [5] [8]
Le protocole pratico-pratique ci-dessous permet de transformer une capture “fragile” en pièce utile: acquisition propre, hash, horodatage, corrélation et limites explicites. [1] [2] [3]
Étape 1 — Capturer le contexte, pas seulement l’image
- Qui réalise la capture, sur quel appareil, quelle application, quelle version.
- Date/heure locale + UTC + fuseau.
- URL, identifiant conversation/document, état de session.
- Méthode de capture (outil natif, enregistrement écran, export).
Sans ce contexte, la capture peut être exacte visuellement mais indéfendable méthodologiquement. [1] [4] [5]
Étape 2 — Sceller l’original
Conserver la version originale brute et calculer immédiatement un hash (p. ex. SHA-256). Travailler ensuite sur copie. Cette discipline protège contre la contestation “fichier modifié après coup”. [1] [3]
Étape 3 — Ajouter une preuve d’existence temporelle
Quand la date est litigieuse, un horodatage tiers (RFC 3161) renforce la preuve d’existence du fichier à un instant donné. Cela ne prouve pas la véracité du contenu, mais améliore la robustesse temporelle. [2]
Étape 4 — Vérifier les métadonnées utiles
Inspecter les métadonnées disponibles (dimensions, encodage, éventuelles données GPS/EXIF, historique de transformations). L’absence de métadonnées ne prouve pas la fraude, mais doit être documentée. [9]
Étape 5 — Corroborer avec source primaire
La capture doit être reliée à une source native: export applicatif, logs serveur, historique de message, artefact système. Une capture isolée reste un indice; corroborée, elle devient un élément probatoire plus solide. [1] [4] [5]
Étape 6 — Utiliser C2PA quand disponible
Les Content Credentials (C2PA) peuvent apporter une provenance signée (création/transformation). Très utile pour la transparence, mais insuffisant seul pour conclure à la “vérité” du contenu. [6] [7]
Erreurs fréquentes à éviter
- Capturer uniquement le crop sans l’écran complet/contextuel.
- Éditer l’image avant hashing.
- Confondre date de fichier et date d’événement.
- Prendre une carte/point GPS affiché comme précision absolue.
- Omettre les limites dans le rapport.
Format de note d’authentification recommandé
Pièce: nom + hash + taille
Contexte: opérateur, appareil, application, méthode
Temps: local + UTC + source de l’horloge
Validation: métadonnées, cohérence visuelle, corrélations externes
Limites: ce qui n’a pas pu être vérifié
Principe clé: une capture bien documentée et corroborée peut devenir probante; une capture spectaculaire mais isolée reste contestable.
Incertitudes et limites
Les méthodes de détection de manipulation ont des limites selon compression, recadrage et transformations successives. L’expertise doit donc privilégier les conclusions graduées et reproductibles plutôt que des certitudes excessives. [4] [5]
Références
- NIST SP 800-86 — https://csrc.nist.gov/pubs/sp/800/86/final
- RFC 3161 — Time-Stamp Protocol — https://datatracker.ietf.org/doc/html/rfc3161
- ISO/IEC 27037 — https://www.iso.org/standard/44381.html
- SWGDE — Best Practices for Image Authentication — https://www.swgde.org/documents/published-complete-listing/18-i-001-best-practices-for-image-authentication/
- SWGDE — Digital Video Authentication — https://www.swgde.org/documents/published-complete-listing/23-v-001-best-practices-for-digital-video-authentication/
- C2PA specification — https://spec.c2pa.org/specifications/specifications/2.3/specs/C2PA_Specification.html
- C2PA explainer — https://spec.c2pa.org/specifications/specifications/2.3/explainer/Explainer.html
- Rule 901 — Authenticating Evidence — https://www.law.cornell.edu/rules/fre/rule_901
- ExifTool GPS Tags — https://exiftool.org/TagNames/GPS.html
- Google Maps location accuracy help — https://support.google.com/maps/answer/2839911?hl=en
