Comment prouver la date de création d'un fichier en cas de litige

Prouver la date de création d’un fichier est une question qui revient constamment dans les contextes où la chronologie compte vraiment : journalisme d’investigation, litige de propriété intellectuelle, archivage, audits de conformité ou simple besoin de certifier qu’un document existait à un moment donné. La difficulté vient de ce que « date de création » n’est pas une information unique et immuable. Un fichier possède à la fois des horodatages imposés par le système d’exploitation, des métadonnées internes inscrites par l’application qui l’a produit, et parfois des traces indirectes contenues dans son contenu. Chacune de ces sources parle d’un aspect différent du cycle de vie du fichier et chacune peut être modifiée, perdue ou simplement absente selon le format, le mode de transfert ou le système utilisé. Comprendre cette superposition est la première étape pour éviter les erreurs d’interprétation et pour constituer un dossier technique solide, qui documente ce qui est réellement vérifiable au niveau technique sans prétendre établir une vérité juridique par lui-même. Dans la pratique, on ne prouve jamais une date de création avec une seule valeur. On construit un faisceau d’indices techniques cohérents : horodatages du système, métadonnées internes, empreintes cryptographiques et contexte de conservation. C’est ce faisceau qui permet de dire avec rigueur : à partir des données techniques disponibles, le fichier présente ces caractéristiques et n’a pas été altéré depuis la capture de l’analyse. Pour explorer ces informations de façon méthodique, il est utile de s’appuyer sur un outil qui centralise l’extraction des métadonnées, le calcul des empreintes et la génération d’un rapport horodaté, comme on peut le faire sur la page d’accueil où l’on dépose un fichier pour obtenir son profil technique complet.

Les dates affichées par l’explorateur Windows ou le Finder macOS sont souvent trompeuses. Elles dépendent du système de fichiers et du chemin emprunté. Une copie, un déplacement entre volumes, une synchronisation cloud ou une extraction d’archive réinitialise généralement la date de création, tout en conservant une date de modification plus stable. La date d’accès est quant à elle quasi inutilisable depuis des années sur la plupart des systèmes modernes. En d’autres termes, les horodatages du système témoignent surtout de la dernière manipulation du fichier dans cet environnement précis, pas de sa naissance originelle. Il faut donc aller chercher plus loin, dans le fichier lui-même.

C’est là que les métadonnées internes prennent toute leur importance. Une image JPEG ou HEIC contient souvent des champs EXIF comme DateTimeOriginal, DateTimeDigitized et parfois même un horodatage GPS. Ces champs sont écrits par l’appareil photo au moment de la prise de vue et ne sont pas régénérés par une simple copie. Un fichier PDF possède un dictionnaire d’information avec CreationDate et ModDate, qui sont initialisés par l’application de création, même si ces champs peuvent être réécrits volontairement. Un document DOCX embarque des propriétés étendues avec Created, Modified et des identifiants d’auteur. Les vidéos MP4/MOV stockent dans leurs atomes moov des dates de création et de modification, les fichiers audio FLAC conservent des tags et des blocs de métadonnées, et les archives ZIP conservent des timestamps de chaque entrée. Les formats techniques comme DWG, STL ou STEP contiennent également des champs de création et de révision propres au logiciel CAO. L’analyse de ces données demande une lecture format par format, ce qui devient rapidement fastidieux sans outil dédié. Une plateforme d’analyse comme FilesAudit permet justement d’extraire automatiquement ces champs pour plus de deux cents formats, des images aux exécutables en passant par les documents et les modèles 3D, et de les présenter de façon lisible à côté des horodatages du système. La liste complète des formats pris en charge donne une idée de l’étendue des cas couverts au quotidien.

Le second pilier de la preuve technique est l’intégrité. Même si une date est présente dans les métadonnées, il faut s’assurer que le fichier n’a pas été modifié depuis. C’est le rôle des empreintes cryptographiques. Le calcul d’un hash SHA-256, MD5 et CRC32 produit une signature unique du contenu binaire. La moindre altération, même d’un seul octet, change radicalement le hash. En consignant ces empreintes dans un rapport horodaté, on fige l’état du fichier à un instant T. Si le même fichier est réanalysé plus tard et que les hashes correspondent, on peut affirmer techniquement qu’il est identique à la version analysée. Cette documentation est particulièrement utile pour comparer deux versions, détecter un doublon ou établir une chaîne de conservation. Le rapport généré reprend les métadonnées système, les métadonnées internes, les hashes et un horodatage de l’analyse, ce qui constitue une base documentaire exploitable pour un audit ou une expertise. On trouve d’ailleurs un guide détaillé sur la façon de lire et d’utiliser un rapport de métadonnées d’un fichier pour l’expertise.

Un exemple concret illustre bien l’intérêt. Un journaliste reçoit une photo anonyme prétendument prise lors d’une manifestation. L’explorateur indique une date de création récente, correspondant au téléchargement. L’analyse EXIF révèle en revanche un DateTimeOriginal cohérent avec la date de l’événement, un modèle d’appareil plausible et des coordonnées GPS désactivées, conformément à la pratique de sécurité. Le hash SHA-256 est consigné et le rapport PDF est archivé. Même si la date système est fausse, le faisceau technique oriente vers une origine crédible, à condition de croiser avec d’autres éléments contextuels. C’est exactement ce type de travail qui demande rigueur et prudence.

Il faut cependant rester lucide sur les limites. Les métadonnées internes peuvent être absentes, vides ou volontairement falsifiées. Un éditeur d’images peut réécrire l’EXIF