Tous les gestionnaires de fichiers du monde affichent une colonne « date de création ». On la lit comme on lit une date de naissance sur un acte d’état civil : une chose constatée, inscrite une fois, et qu’on ne discute pas.
On va vérifier. Pour ça, il faut d’abord savoir combien de dates un fichier porte, et lesquelles.
Quatre, pas deux
Sur ce Mac, en APFS, un fichier porte quatre dates, et stat sait les montrer séparément.
stat -f "naissance %SB | modif %Sm | inode %Sc | accès %Sa" fichier- La naissance (
%SB, pour birth) : quand le fichier a été créé. - La modification (
%Sm) : quand son contenu a changé pour la dernière fois. - L’inode (
%Sc, pour change) : quand la fiche du fichier a changé. Pas son contenu : sa fiche. Un changement de droits ou de propriétaire la déplace, une simple lecture non. - L’accès (
%Sa) : la dernière lecture.
Sur un fichier qu’on vient d’écrire, les quatre sont identiques, ce qui est rassurant et ne prouve rien. Trois secondes plus tard, après un ajout, la modification et l’inode avancent ensemble, la naissance reste en arrière. C’est exactement ce à quoi on s’attend. Gardons cette image en tête, parce qu’elle va se défaire.
La copie ment déjà, poliment
Première surprise, et elle est douce. cp -p copie un fichier « en préservant » ses dates.
Voici trois horaires, à cinq secondes d’intervalle : la source naît à 12h32m59s, on la modifie
à 12h33m04s, on la copie à 12h33m09s.
source.txt : naissance 12:32:59 | modif 12:33:04
copie-p.txt : naissance 12:33:04 | modif 12:33:04
copie-simple.txt : naissance 12:33:09 | modif 12:33:09Regardez la deuxième ligne. La copie déclare être née à 12h33m04s. Ce n’est ni le moment où elle a réellement été créée (12h33m09s), ni la naissance de l’original (12h32m59s). C’est la date de modification de la source, recopiée dans la case naissance.
Cette date de naissance ne désigne donc aucun événement. Elle n’est pas fausse par accident : il n’y a simplement rien, dans l’histoire de ces deux fichiers, qui se soit produit à cet instant-là pour cette copie.
Deux commandes pour naître en 1990
Passons au cas franc. On crée un fichier, il naît à 12h34m35s, ce samedi. Puis on exécute exactement ceci :
touch -m -t 199001010000 m.txtLe manuel de touch livré avec ce système décrit l’option -m en deux phrases :
Change the modification time of the file. The access time of the file is not changed unless the -a flag is also specified.
Une date change, l’autre ne bouge pas. Le manuel ne dit rien de plus, et en particulier il ne dit pas un mot de la naissance. Voici le relevé, avant et après :
avant : naissance 19/09/2026 12:34:35 | modif 19/09/2026 12:34:35 | inode 19/09/2026 12:34:35
après : naissance 01/01/1990 00:00:00 | modif 01/01/1990 00:00:00 | inode 19/09/2026 12:34:35Le fichier est né le 1er janvier 1990. Il a été créé il y a quarante secondes.
La date d’accès, elle, est restée à 12h34m35s : sur ce point précis le manuel dit vrai. C’est la naissance qui a bougé sans être invitée, et son déplacement n’est documenté nulle part dans cette page.
Le mouvement n’a qu’un sens, et pas de retour
Deux mesures pour cerner la règle.
Vers le futur, la naissance ne suit pas. Sur un fichier neuf, touch -m -t 203001010000
donne une modification en 2030 et laisse la naissance à aujourd’hui. Le fichier prétend alors
avoir été modifié quatre ans après qu’on l’ait consulté, ce qui ne gêne personne.
Vers le passé, elle suit. Et c’est logique : le système refuse qu’un fichier soit modifié avant d’exister, donc quand on antidate la modification sous la naissance, il tire la naissance avec elle. Il ne refuse pas l’opération, il ne prévient pas, il corrige en silence.
Et le mouvement ne se rembobine pas. Sur le fichier passé en 1990, on remet la modification à maintenant :
naissance 01/01/1990 00:00:00 | modif 19/09/2026 12:34:50La naissance reste en 1990. En deux commandes et sans droits particuliers, ce fichier écrit cet après-midi a désormais l’état civil parfaitement crédible d’un document de 1990 modifié aujourd’hui. Aucun avertissement n’a été émis à aucun moment.
Celle qui a refusé
Il reste la date d’inode, la troisième colonne de tous les relevés ci-dessus. Elle n’a pas
bougé d’un pouce. Elle affiche 12h34m35s après l’antidatage, 12h33m52s après la tentative
suivante, et touch n’a aucune option pour l’atteindre : elle se met à l’heure toute seule dès
qu’on touche à la fiche du fichier, y compris pour y écrire un mensonge.
Deux précisions honnêtes, parce que « ne se laisse pas écrire » est une affirmation forte.
D’abord, cette date n’est pas incorruptible dans l’absolu : elle se met à l’heure de l’horloge
du système, et qui peut changer l’horloge peut la placer où il veut. Ensuite, je n’ai mesuré
que touch. Je n’ai pas testé l’écriture directe sur le périphérique, et je ne prétendrai donc
pas qu’aucun outil ne sait la déplacer.
Ce que j’ai mesuré est plus modeste et suffit : des quatre dates d’un fichier, trois se posent avec une commande ordinaire, et la quatrième résiste à cette commande.
Le même fichier, trois réponses
Une dernière mesure, sur un cas que tout le monde a sous la main. Le README.md de notre dépôt.
dans le dépôt de travail : naissance 20/08/2026 00:48:51
dans un clone fait à l'instant : naissance 19/09/2026 12:33:54
ce que dit git : dernier commit qui le touche, 20/08/2026 00:52:52Trois dates pour un contenu identique à l’octet près. La première dit quand ce fichier est apparu sur cette machine. La deuxième dit la même chose pour l’autre machine, celle du clone, et c’est pour ça qu’un dépôt fraîchement cloné a l’air d’avoir été écrit ce matin. La troisième est la seule qui parle du texte lui-même, et encore : elle date l’enregistrement, pas l’écriture.
Aucune des trois ne répond à « quand ce texte a-t-il été écrit ». Cette information n’existe nulle part sur le disque.
Ce que ça vaut
Je ne vais pas vous dire de vous méfier des dates de fichiers, ce serait une conclusion de salon. Voici ce que ces mesures établissent, et leur portée exacte.
La colonne « date de création » de votre gestionnaire de fichiers n’est pas un constat du système, c’est une valeur stockée dans la fiche du fichier, au même titre que son nom. On la modifie comme on renomme, en une commande, sans droits d’administrateur, sans trace. Elle est utile, elle est presque toujours juste, et elle n’a aucune valeur de preuve.
La date qui résiste à la commande ordinaire existe, mais elle ne répond pas à la question qu’on lui pose : elle dit quand la fiche a changé, ce qui inclut un changement de droits, un déplacement, un mensonge posé sur les autres dates. Elle est plus difficile à falsifier précisément parce qu’elle ne parle pas du contenu.
C’est pour cette raison qu’on ne l’affiche nulle part, et c’est la seule chose de ce texte que je trouve vraiment belle : le système garde bien une trace qui résiste, mais elle ne dit pas ce qu’on voudrait lui faire dire. Les deux propriétés ne sont pas indépendantes. Une date reste honnête tant que personne n’a intérêt à la lire.
Pour finir sur du solide : sur les 119 fichiers d’articles de ce site, zéro affiche une naissance postérieure à sa modification. Rien n’a été antidaté ici. Vous n’avez aucune raison de me croire sur parole, et c’est précisément le propos.
