Résumé exécutif

Les métadonnées ne “gagnent” pas un dossier à elles seules, mais cinq éléments peuvent en changer radicalement l’issue: horodatage fiable, provenance technique, identité opératoire, intégrité vérifiable et corrélation inter-sources. Quand ces cinq éléments convergent, la narration factuelle devient beaucoup plus résistante à la contestation. [7] [8] [9] [10]

1) Le temps: la métadonnée la plus sous-estimée

Un horodatage sans contexte (UTC/fuseau, temps événement vs temps ingestion) peut inverser une séquence et fausser toute l’analyse. La règle: conserver l’original, normaliser en UTC, documenter la transformation. [7] [8]

2) La provenance technique

Savoir d’où vient exactement l’information change sa valeur: EXIF GPS dans une photo, en-tête SMTP, log IPFIX, événement Zeek. Chacune de ces sources répond à une question différente; les confondre produit de faux raccourcis. [1] [2] [3] [4] [5] [6]

3) L’identité opératoire (qui agit réellement?)

Une adresse courriel, une IP ou un compte applicatif n’est pas automatiquement une personne. Il faut combiner identité technique et contexte d’usage (poste, session, droits, corrélations d’accès). Sans cela, l’attribution reste fragile. [2] [3] [7]

4) L’intégrité vérifiable

Les métadonnées n’ont de valeur probatoire que si leur chaîne de conservation est propre: collecte documentée, hash, transferts tracés, stockage contrôlé. Une donnée “intéressante” mais mal conservée perd vite de sa force en litige. [7] [8] [9] [10]

5) La corrélation inter-sources

La preuve solide est rarement monolithique. Elle vient du recoupement: EXIF + logs réseau + entêtes email + journaux système. Plus les sources indépendantes convergent, plus l’explication adverse doit être sophistiquée pour tenir. [1] [2] [4] [6]

Exemple concret: ce que “5 éléments” change

Sans ces cinq éléments, un dossier peut ressembler à une hypothèse plausible. Avec eux, le même dossier devient une reconstruction défendable: chronologie stable, source identifiée, intégrité démontrée, corrélation visible, limites explicitement assumées.

Erreurs fréquentes

  • Prendre la date affichée dans une app comme vérité absolue.
  • Lire une IP comme preuve d’auteur humain sans contexte.
  • S’appuyer sur une seule famille de métadonnées.
  • Négliger la documentation de transformation (timezone, parsing, fusion).

Checklist avocat / expert

  1. Le temps source et le temps normalisé sont-ils tous deux conservés?
  2. Chaque métadonnée clé est-elle reliée à sa source technique?
  3. L’intégrité (hash/transferts) est-elle démontrée?
  4. Les corrélations sont-elles inter-sources et reproductibles?
  5. Les limites et hypothèses alternatives sont-elles écrites?

À retenir: les métadonnées ne valent pas par leur volume, mais par la qualité de leur provenance et de leur corrélation.

Incertitudes et limites

Les métadonnées peuvent être absentes, incomplètes ou ambiguës selon l’outil et l’environnement. Une approche prudente doit intégrer des marges d’erreur et distinguer clairement faits observés et inférences expertes. [7] [8]

Références

  1. ExifTool GPS tags — https://exiftool.org/TagNames/GPS.html
  2. RFC 5322 — Internet Message Format — https://www.rfc-editor.org/rfc/rfc5322.html
  3. RFC 8601 — Authentication-Results — https://www.rfc-editor.org/rfc/rfc8601.html
  4. RFC 7011 — IPFIX — https://www.rfc-editor.org/rfc/rfc7011
  5. RFC 3954 — NetFlow v9 — https://www.rfc-editor.org/rfc/rfc3954
  6. Zeek conn.log documentation — https://docs.zeek.org/en/current/logs/conn.html
  7. NIST SP 800-86 — https://csrc.nist.gov/pubs/sp/800/86/final
  8. NIST SP 800-92 — https://csrc.nist.gov/pubs/sp/800/92/final
  9. LCCJTI (Québec) — https://www.legisquebec.gouv.qc.ca/fr/document/lc/C-1.1
  10. Code civil du Québec — art. 2837+ — https://www.legisquebec.gouv.qc.ca/fr/document/lc/CCQ-1991#se:2837

Articles qui pourraient vous intéresser