Une archive photographique vivante
Photographier ne produit pas seulement des images, ça produit aussi une masse fragile de fichiers.
Des RAW, des JPG, des exports, des vidéos, des screenshots, des fichiers reçus ou envoyés, des images compressées, des versions alternatives, des fichiers édités, des fichiers dupliqués, des fichiers dont le nom ne veut plus rien dire, des fichiers dont les métadonnées sont incomplètes ou incohérentes.
Avec le temps, retrouver une image ne dépend plus seulement de l’image elle-même. Cela dépend aussi de son nom, de sa date, de son format, de ses métadonnées, de son dossier, et de son historique : copies, exports, compressions, modifications.
Une archive n’est donc pas seulement un endroit où les fichiers dorment. C’est un système qui permet de les retrouver, de les comprendre, de les exploiter et de les transmettre.
Ce problème ne concerne pas uniquement les photographes professionnels. Il concerne toute personne qui accumule des images au fil du temps : photographes, artistes, designers, créateurs, ou simplement des personnes dont le téléphone et les comptes cloud sont devenus, peu à peu, de grandes masses visuelles difficiles à exploiter.
Aujourd’hui, presque tout le monde devient une sorte de collecteur d’images. On photographie avec son téléphone, on reçoit des images, on en envoie, on garde des screenshots, on édite et on exporte depuis des applications, on synchronise tout dans le cloud, puis on oublie progressivement ce que cette masse contient réellement.
La synchronisation cloud donne une impression de sécurité. Elle protège parfois contre la perte immédiate d’un appareil ou d’un disque. Mais elle ne règle pas le problème de fond : savoir ce que l’on possède, pouvoir le retrouver, le comprendre, le trier, le déplacer, le sauvegarder autrement, et l’exploiter dans cinq ou dix ans.
Ce n’est pas parce qu’une image est sauvegardée dans le cloud qu’on en garde réellement le contrôle.
La méthode repose sur une idée simple : avant de décider où chaque fichier doit vivre, il faut d’abord le rendre fiable, lisible et triable. Cela passe par une date de création aussi cohérente que possible, une vérification de sa lisibilité, et un nom suffisamment stable pour rester utile même en dehors d’une application photo.
Sources hétérogènes :
Nikon Zf/DCIM/100ND750/DSC_8421.NEF
Ricoh GR III/DCIM/100RICOH/R0004387.DNG
iPhone 15/
├── DCIM/104APPLE/IMG_4821.HEIC
└── Downloads/export_001.jpg
Samsung Galaxy S23/
├── DCIM/Camera/20260526_194218.jpg
├── WhatsApp/Media/WhatsApp Images/IMG-20050518-WA0004.jpg
├── Telegram/Telegram Images/photo_2024-05-26_19-42-19.jpg
├── Pictures/Screenshots/Screenshot_20260521-114207.png
└── Download/
├── sticker_20260517_083102.webp
└── 7f6c91e2a4f4d1d9.gif
Base stable :
Archive/
├── Camera/
│ ├── CAMERA_CV26_0412_212430_30071244.DNG
│ └── CAMERA_CV26_0514_165930_29257528.NEF
└── Phone/
├── PHONE_CV05_0518_214409_01288211.JPG
├── PHONE_CV24_0526_194219_00322817.JPG
├── PHONE_CV25_0113_192213_00591822.HEIC
├── PHONE_CV26_0517_083102_00422819.WEBP
├── PHONE_CV26_0520_163201_00482731.JPG
├── PHONE_CV26_0521_114207_00118291.PNG
└── PHONE_CV26_0526_194220_00112763.GIF
Organisation flexible :
Archive/
├── Camera/
│ └── 2026/
│ ├── 0412-elvis-party/
│ └── 0514-palermo-weekend/
└── Phone/
├── 2005/
├── 2024/
├── 2025/
└── 2026/
Un catalogue n’est pas une archive
Les applications photo et les DAM sont très utiles pour consulter, organiser, sélectionner, rechercher et éditer ses images. Ces outils permettent de reconnaître des visages, de regrouper des lieux, de compiler des souvenirs, de filtrer des séries ou de retrouver approximativement certaines images. Pour beaucoup d’usages quotidiens, ils sont suffisants.
Mais ils montrent leurs limites lorsqu’il s’agit d’organiser des images qui proviennent de sources hétérogènes : plusieurs appareils photo, plusieurs téléphones, des logiciels de retouche, des exports, des messageries, des captures d’écran, des téléchargements, des fichiers récupérés ou transférés plusieurs fois.
Chaque outil organise les images selon sa propre logique. Tant que tout reste dans la même application, cette abstraction fonctionne : on manipule un catalogue, pas directement une archive. Mais derrière l’interface, il y a toujours des fichiers, des noms, des formats, des dates, des dossiers, des versions et des métadonnées.
Dès que l’on veut migrer, archiver, comparer, extraire, sauvegarder soi-même ou travailler sur plusieurs supports, le système réel réapparaît : fichiers mal nommés, dates ambiguës, exports multiples, versions compressées, métadonnées absentes, modifiées ou contradictoires.
À ce moment-là, l’organisation ne peut pas dépendre uniquement de ce qu’une application croit savoir.
Le but est de garder l’archive lisible pour que le catalogue reste un outil, pas une dépendance. La recherche, les notes, les mots-clés et les collections peuvent vivre dans un catalogue. Les fichiers, les dossiers, les dates, les métadonnées, les formats et la structure doivent rester compréhensibles en dehors de lui.
Ce que j’entends par archive photographique
Le contenu comme le système doivent être pensés pour durer.
Je ne parle pas d’une archive photographique comme d’un stockage froid où les anciennes images disparaissent avec le temps. Je parle plutôt d’une structure de travail : un système qui garde les images passées et présentes accessibles, compréhensibles, faciles à retrouver et à utiliser.
Une bonne archive doit être simple à maintenir. Si le système est trop complexe, il ne sera pas utilisé longtemps. Elle doit rester rapidement accessible, aussi bien en partie que dans son intégralité. Elle doit rester stable dans le temps, indépendante d’une application spécifique, compréhensible par un humain, exploitable par des machines, vérifiable, et assez souple pour accueillir de nouvelles sources.
Dans l’esprit, cela rejoint certaines idées classiques de gestion des données : rendre les fichiers retrouvables, accessibles, interopérables et réutilisables. Mais je ne voulais pas construire un système lourd, difficile à maintenir seul. Je voulais un système simple, personnel, lisible, et robuste dans la pratique.
Un système que je peux comprendre en ouvrant un dossier.
Un système qui tient dans ma tête, pas dans une application.
Un système qui continue à avoir du sens même si je change de logiciel, de machine ou de service cloud.
La date comme point d’ancrage
Pour qu’une archive reste lisible, les fichiers doivent pouvoir être rangés dans un ordre qui a du sens. Le plus simple est souvent l’ordre chronologique : une date permet de retrouver une période, une session, un événement, ou simplement de remettre ensemble des images proches.
Mais cette date n’est pas toujours évidente. Pour situer l’origine d’une image, un fichier peut contenir plusieurs champs proches, comme DateTimeOriginal, CreateDate ou MediaCreateDate. Autant d’informations parfois absentes, modifiées ou contradictoires.
Mon workflow essaie donc d’abord d’établir la meilleure date possible à partir des informations disponibles. Cette étape n’est pas vraiment viable à la main dès qu’on traite beaucoup de fichiers. La méthode repose sur quelques automatisations simples : lire plusieurs champs de date, choisir la meilleure date disponible, normaliser certains champs, et vérifier que les fichiers restent lisibles.
L’objectif n’est pas de produire une vérité parfaite dans tous les cas, mais de créer une base stable et cohérente pour organiser l’archive.
Une fois cette date trouvée, elle peut devenir le point d’ancrage du nom de fichier.
Le nom de fichier comme infrastructure minimale
J’utilise un format de nommage simple :
PREFIXYY_MMDD_HHMMSS_FILESIZE.EXT
Par exemple :
CAMERA_CV26_0320_025038_31188070.DNG
Le préfixe suit une convention simple :
SOURCE_OWNER
Dans mon cas, j’utilise par exemple CAMERA_CV pour les fichiers issus de mon appareil photo et PHONE_CV pour les fichiers issus de mon téléphone. CAMERA ou PHONE indique la source. CV indique que ce sont mes fichiers.
Comme la date et l’heure sont intégrées au nom du fichier, un simple tri par nom devient aussi un tri chronologique. Les images proches dans le temps se retrouvent naturellement côte à côte. Une série, un voyage, une soirée ou une session de travail redeviennent lisibles sans dépendre d’une application photo.
La date de création est l’une des informations les plus importantes d’une archive média. L’inscrire dans le nom du fichier, et pas seulement dans les métadonnées, réduit le risque de la perdre au fil des exports, des copies ou des migrations futures.
La taille du fichier permet de réduire les collisions lorsque plusieurs fichiers partagent le même horodatage. Elle aide aussi à repérer rapidement certains doublons ou certaines versions moins compressées. Deux fichiers très proches, mais avec des tailles très différentes, racontent souvent quelque chose : un export, une compression, une version modifiée, une copie de moindre qualité.
L’extension normalisée rend le format immédiatement visible.
Ce n’est pas un nom élégant. C’est un nom opérationnel. Il transforme le fichier en objet plus lisible, plus triable, plus portable. En plus de faciliter le travail d’éventuelles applications tierces, il rend un simple explorateur de fichiers déjà utile.
C’est une idée très simple : le nom du fichier devient une petite infrastructure. Avant même de choisir une arborescence définitive, chaque fichier porte déjà sa source, sa date, son heure, son poids et son format. Il devient alors plus facile à trier, à comparer, à déplacer, à sauvegarder et à réorganiser plus tard.
Organiser par source et par usage
Une fois les fichiers normalisés, lisibles et triables par nom, l’arborescence peut rester très simple. Le système ne cherche pas à décider à l’avance où chaque fichier doit vivre pour toujours. Il crée d’abord une base propre, puis laisse assez de souplesse pour organiser selon les besoins.
Ma manière de faire repose sur une distinction simple : la source et l’usage.
La source désigne le point d’entrée du fichier dans l’archive. Dans mon cas, CAMERA_CV correspond aux fichiers issus d’un import contrôlé depuis un appareil photo. Ce sont souvent des images produites dans un contexte identifié : un shooting, un voyage, une commande, un projet. Elles peuvent ensuite être organisées par session, avec leurs RAW, JPG, sidecars ou exports.
PHONE_CV est volontairement plus large. Un téléphone ne sert pas seulement à prendre des photos. Il sert aussi à accumuler des images : photos personnelles, vidéos, captures d’écran, fichiers reçus, téléchargements, références, exports d’applications, images compressées ou modifiées ailleurs.
Selon les besoins, on peut traiter tout cela comme un même flux visuel issu du téléphone, ou bien le distinguer ensuite dans les dossiers. Le bon niveau de précision dépend de ce que l’on veut retrouver plus tard.
Le préfixe décrit donc la provenance ou le canal d’entrée. L’organisation des dossiers décrit l’usage, le contexte ou la manière dont on souhaite retrouver les fichiers.
Par exemple, une organisation simple peut rester très large :
Camera/2026/
Phone/2026/
Dans ce cas, Phone/2026/ contient le flux visuel du téléphone pour l’année : photos, vidéos, captures d’écran, fichiers reçus, téléchargements ou exports, selon ce que l’on choisit de garder dans cette archive.
Si l’archive devient trop dense, la même logique peut être affinée sans changer le principe :
Camera/2026/0412-elvis-party/
Camera/2026/0526-palermo-weekend/
Phone/2026/photos/
Phone/2026/videos/
Phone/2026/memories/
Phone/2026/screenshots/
Phone/2026/references/
La source reste la même ; c’est l’usage qui se précise dans les dossiers.
Le système ne cherche donc pas à imposer une définition unique de ce qui compte comme photographie, souvenir, document ou référence. Il crée d’abord une base stable et lisible, puis laisse assez de souplesse pour organiser selon les besoins.
L’important est que chaque fichier garde une identité claire, même si l’arborescence évolue ensuite.
Rester simple
Je voulais que ce système reste volontairement ennuyeux.
Des dossiers ordinaires. Des noms de fichiers lisibles. De petits scripts. Des outils standards. Pas de catalogue propriétaire comme seule source de vérité. Pas de base de données cachée indispensable pour comprendre l’archive.
Ce n’est pas un rejet des applications photo. J’utilise aussi des logiciels pour voir, sélectionner, éditer ou publier des images. Mais je ne veux pas que le sens de mon archive dépende uniquement d’eux.
Les outils changent. Les services cloud changent. Les catalogues deviennent parfois difficiles à exporter ou à relire. Des dossiers clairs, des fichiers bien nommés et des conventions simples restent plus faciles à comprendre, à copier et à maintenir dans le temps.
C’est aussi une question de maintenance personnelle. Plus un système est simple, plus il a de chances d’être réellement utilisé. Plus il est lisible, plus il est facile à reprendre après plusieurs mois. Plus il repose sur des conventions explicites, moins il dépend de ma mémoire.
Pour qui c’est utile
Ce système n’est pas un DAM complet. Ce n’est pas une application grand public. Ce n’est pas une solution magique pour quelqu’un qui veut ne jamais réfléchir à son organisation.
Il s’adresse plutôt aux personnes qui veulent reprendre le contrôle sur leur archive média avec des conventions simples, lisibles et durables.
Cela peut être un photographe professionnel qui veut garder ses imports propres. Un amateur sérieux qui accumule des années de photos. Un artiste ou un designer qui travaille avec beaucoup d’images. Un créateur de contenu qui mélange téléphone, appareil photo, exports et captures. Ou simplement quelqu’un qui sent que son cloud contient trop de fichiers pour être encore réellement maîtrisable.
Le but n’est pas de conserver des fichiers comme des objets morts.
Le but est de garder une archive photographique vivante : lisible par des machines, compréhensible par des humains, et assez utile pour continuer à travailler avec elle dans plusieurs années.
Commencer
J’ai transformé cette méthode en guide pratique, accompagné de quelques scripts Bash :
photography-archiving-workflow
Le guide explique le workflow étape par étape. Les scripts prennent en charge les parties qui ne sont pas réalistes à faire manuellement à grande échelle : nettoyer et normaliser les métadonnées, renommer les fichiers, et vérifier que les fichiers médias restent lisibles.
Discussion
- Article: Substack
- Workflow: GitHub Discussions