Résumé exécutif
Dans les dossiers de litige numérique, les erreurs de préservation ne sont pas spectaculaires: elles sont souvent “ordinaires” (actions bien intentionnées, mais non tracées). Pourtant, ce sont elles qui réduisent la crédibilité d’un dossier. Le problème majeur n’est pas le manque d’outils, mais l’absence d’un protocole partagé entre avocats, TI et gestionnaires de preuve. [1] [3] [4] [14]
Cette version enrichie présente les erreurs les plus fréquentes observées en cabinet, leur impact probatoire et la correction praticable en moins d’une semaine. Les constats s’appuient sur nos recherches cloud, M365 et timeline multi-sources réalisées en février 2026. [6] [7] [8] [9] [10] [11] [15] [16]
Erreur 1 — Commencer l’analyse avant de geler la preuve
Symptôme: un technicien “ouvre pour vérifier” un compte, un poste ou une boîte courriel avant capture des traces critiques. Impact: contamination potentielle de l’état initial et contestation de la chronologie. Correction: étape de gel obligatoire, puis analyse sur copie. [1] [2] [3]
Erreur 2 — Aucune personne clairement responsable de la chaîne
Symptôme: plusieurs intervenants manipulent des exports sans point de contrôle unique. Impact: trous de possession, difficulté à certifier la continuité. Correction: nommer un responsable preuve + remplaçant et imposer un journal central. [3] [14]
Erreur 3 — Horodatages incohérents (UTC/fuseaux)
Symptôme: mélanges d’heures locales, UTC et heures d’ingestion. Impact: inversion de séquence causale (qui a fait quoi en premier). Correction: normaliser en UTC, conserver le timestamp original et l’offset. [2] [5] [15] [16]
Erreur 4 — Se fier à une seule source de vérité
Symptôme: argumentaire basé uniquement sur captures d’écran ou uniquement sur un export API. Impact: fragilité contradictoire. Correction: corrélation minimale multi-sources (identité + activité + objet métier). [1] [9] [10] [11]
Erreur 5 — Supposer la rétention sans la vérifier
Symptôme: “les logs sont forcément là”. Impact: faux négatifs, trous temporels non anticipés. Correction: documenter explicitement rétention/licence/périmètre par source. [5] [9] [10] [11]
Erreur 6 — Export sans hash ni registre d’intégrité
Symptôme: fichiers exportés puis copiés plusieurs fois sans empreinte. Impact: impossibilité de démontrer non-altération. Correction: hash à l’acquisition et avant production; log de transfert systématique. [3]
Erreur 7 — Mélanger containment et forensique
Symptôme: l’équipe qui “répare” efface involontairement des traces. Impact: perte de contexte. Correction: séparation des rôles et ordre d’intervention clair. [4] [1]
Erreur 8 — Chaîne de possession remplie après coup
Symptôme: reconstitution “de mémoire” en fin de journée. Impact: incohérences et trous de justification. Correction: enregistrement en temps réel, même minimal, puis enrichissement contrôlé. [1] [3]
Erreur 9 — Captures sans contexte de collecte
Symptôme: preuve visuelle isolée (pas d’URL, pas d’heure fiable, pas d’opérateur identifié). Impact: faible force autonome. Correction: lier chaque capture à un artefact source et à une entrée de registre. [5] [12] [13]
Erreur 10 — Absence de déclaration des limites
Symptôme: rapport trop affirmatif malgré données partielles. Impact: vulnérabilité en contre-interrogatoire. Correction: section “limites et incertitudes” obligatoire dans chaque note d’analyse. [1] [4] [14]
Erreur 11 — Nomenclature chaotique des pièces
Symptôme: fichiers nommés “export-final-v2-vrai.csv”. Impact: ambiguïté sur la version produite. Correction: convention stricte (incident/date/source/type/version/hash court). [3]
Erreur 12 — Escalade expert trop tardive
Symptôme: mandat expert demandé après altérations, purges ou perte de logs. Impact: réduction drastique du champ reconstructible. Correction: seuils d’escalade prédéfinis (enjeu financier, volume de données, suspicion d’exfiltration, source cloud multi-tenant). [6] [7] [8] [9] [10] [11]
Tableau de correction rapide (7 jours)
| Jour | Action corrective | Résultat attendu |
|---|---|---|
| J1 | Nommer responsable preuve + modèle registre | Traçabilité immédiate |
| J2 | Template legal hold + check rétentions critiques | Réduction du risque de perte |
| J3 | Standard UTC + guide de corrélation | Timeline plus fiable |
| J4 | Procédure hash + stockage contrôlé | Intégrité démontrable |
| J5 | Séparation rôles containment/forensic | Moins de contamination |
| J6 | Simulation interne d’incident | Détection des trous opérationnels |
| J7 | Revue qualité + plan d’amélioration | Dossier défendable |
Script de communication interne (cabinet/TI)
« Notre priorité est de préserver la valeur probatoire du dossier. On fige les sources critiques, on journalise chaque manipulation et on analyse sur copie. Aucun changement opérationnel majeur sans traçabilité associée. »
Incertitudes et limites
La liste ci-dessus couvre les erreurs les plus fréquentes en contexte professionnel, mais chaque organisation a ses contraintes (licences, architecture hybride, sous-traitance, politiques internes). Le protocole doit être adapté sans sacrifier les invariants probatoires: intégrité, continuité, traçabilité et transparence des limites. [1] [3] [4] [6] [7] [8] [9] [10] [11] [14]
Point clé: la meilleure façon d’éviter une erreur de préservation est de décider avant l’incident qui fera quoi, avec quels formulaires et quelles priorités de collecte.
Références
- NIST SP 800-86 — Guide to Integrating Forensic Techniques into Incident Response — https://csrc.nist.gov/pubs/sp/800/86/final
- RFC 3227 — Guidelines for Evidence Collection and Archiving — https://www.rfc-editor.org/rfc/rfc3227
- ISO/IEC 27037:2012 — Identification, collection, acquisition and preservation of digital evidence — https://www.iso.org/standard/44381.html
- NIST SP 800-61r2 — Computer Security Incident Handling Guide — https://www.nist.gov/privacy-framework/nist-sp-800-61
- NIST SP 800-92 — Guide to Computer Security Log Management — https://csrc.nist.gov/pubs/sp/800/92/final
- AWS — Collect and analyze forensic evidence — https://docs.aws.amazon.com/security-ir/latest/userguide/collect-analyze-forensic-evidence.html
- Microsoft Azure — Computer Forensics Chain of Custody — https://learn.microsoft.com/en-us/azure/architecture/example-scenario/forensics/
- Google Cloud — Collecting and analyzing cloud forensics — https://cloud.google.com/transform/how-google-does-it-collecting-and-analyzing-cloud-forensics
- Microsoft Purview — Search the audit log — https://learn.microsoft.com/en-us/purview/audit-search
- Microsoft Entra — Sign-in logs — https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins
- Office 365 Management Activity API reference — https://learn.microsoft.com/en-us/office/office-365-management-api/office-365-management-activity-api-reference
- LCCJTI (Québec) — https://www.legisquebec.gouv.qc.ca/fr/document/lc/C-1.1
- Code civil du Québec — Preuve technologique (art. 2837 et suiv.) — https://www.legisquebec.gouv.qc.ca/fr/document/lc/CCQ-1991#se:2837
- Sedona Canada Principles Addressing Electronic Discovery — https://thesedonaconference.org/publication/The%20Sedona%20Canada%20Principles%20Addressing%20Electronic%20Discovery
- Plaso (log2timeline) Documentation — https://plaso.readthedocs.io/en/latest/sources/user/Using-log2timeline.html
- Timesketch — Collaborative timeline analysis — https://timesketch.org/
