Qui a encore besoin de Photoshop en photographie classique ?

[MFloyd]

"On ne peut pas réfléchir correctement dans une chambre mal rangée"

Charlotte Gainsbourg dans L'Effrontée.

J'ai un catalogue avoisinant les 200'000 images - en reportage sportif on shoote probablement plus qu'en travail studio - ... et je n'ai jamais perdu de photos. En plus ça me permet de retrouver des images très rapidement. Le Catalogue Lr ce n'est non plus pas du "rocket science"; c'est une base de données SQL Light (Structured Query Language), réputée pour être stable et rapide. SQL développée chez IBM en 1970 par Donald Chamberlin et Raymond Boyce, donc c'est pas tout jeune.

Où je me fais souvent ch..er 💩, c'est la synchronisation avec le cloud Adobe. Ca s'est amélioré, mais ce n'est toujours pas ça.

Au besoin, je vous développe un argumentaire.

En résumé, le Catalogue est un outil indispensable dans mon travail. Mais je peux m'imaginer que ce ne soit pas le cas pour tout le monde.

[Verso92]

J'étais persuadé que c'était une citation d'Isidore Kea.

Le fameux Suédois ?

[MFloyd]

Voila ce qu'on en dit du Catalogue.

La relation entre le catalogue Lightroom et SQLite

Quand on parle du catalogue de Adobe Lightroom Classic, on parle en réalité... d'une base de données SQLite.

Oui, littéralement.

Le fichier NomDuCatalogue.lrcat est un fichier SQLite standard. Lightroom n'a pas inventé un système propriétaire obscur : il s'appuie sur un moteur de base de données relationnelle léger, robuste et ultra répandu.

⸻

1. SQLite : c'est quoi exactement ?

SQLite est :
   •   Une base de données relationnelle
   •   Sans serveur (pas besoin de service séparé)
   •   Stockée dans un simple fichier
   •   Extrêmement stable
   •   Utilisée dans des millions d'applications (navigateurs, iOS, Android...)

C'est une base embarquée.
Autrement dit : tout tient dans un seul fichier.

C'est précisément ce qui rend le catalogue Lightroom portable et simple à sauvegarder.

⸻

2. Ce que contient réellement le fichier .lrcat

Le fichier catalogue (.lrcat) contient des tables SQL structurées, avec :

📌 Tables principales
   •   Références aux fichiers photos (chemins d'accès)
   •   Métadonnées EXIF
   •   Mots-clés
   •   Collections
   •   Historique de développement
   •   Paramètres de traitement RAW
   •   Relations entre images et ensembles

📌 Ce qu'il ne contient PAS
   •   Les RAW
   •   Les JPEG exportés
   •   Les aperçus (stockés dans des dossiers séparés)

Le catalogue ne stocke pas les pixels.
Il stocke la structure.

⸻

3. Pourquoi Adobe a choisi SQLite

Trois raisons stratégiques :

1️⃣ Performance locale

Pas besoin d'un serveur MySQL ou PostgreSQL.
Tout fonctionne en local, immédiatement.

2️⃣ Portabilité

Un seul fichier = facile à copier, sauvegarder, dupliquer.

3️⃣ Robustesse

SQLite est extrêmement fiable pour des volumes importants en lecture fréquente.

Pour un photographe qui gère des centaines de milliers d'images sur des disques externes, c'est un choix logique :
léger, rapide, sécurisé.

⸻

4. Comment Lightroom exploite SQL

Lightroom interroge la base en permanence via des requêtes SQL internes :
   •   Rechercher toutes les images ISO > 3200
   •   Filtrer par objectif
   •   Afficher les images non notées
   •   Générer des collections dynamiques

Chaque filtre que vous appliquez est une requête SQL.

Chaque collection dynamique est une requête SQL sauvegardée.

Quand on comprend ça, on réalise :
Lightroom est un moteur de requêtes visuel.

⸻

5. Pourquoi il ne faut PAS modifier le catalogue directement

Techniquement, on peut ouvrir un .lrcat avec un outil SQLite.

Mais c'est une très mauvaise idée.

Pourquoi ?
   •   Les relations internes sont complexes
   •   Lightroom ajoute des index spécifiques
   •   Toute modification externe peut corrompre le catalogue
   •   Adobe ne garantit pas l'intégrité après intervention

Le catalogue est une base SQLite,
mais gérée exclusivement par Lightroom.

⸻

6. Implications pratiques pour un workflow professionnel

🔹 Sauvegarde rapide

Vous sauvegardez une base de données, pas des images.

🔹 Optimisation

La fonction "Optimiser le catalogue" reconstruit les index SQL.

🔹 Intégrité

La vérification au démarrage contrôle la cohérence des tables.

🔹 Performance

Plus le catalogue est bien structuré (mots-clés propres, hiérarchie claire), plus les requêtes sont efficaces.

⸻

7. Conclusion

Le catalogue Lightroom n'est pas un simple fichier de paramètres.

C'est une base de données relationnelle SQLite sophistiquée, pensée pour :
   •   Structurer
   •   Interroger
   •   Organiser
   •   Sécuriser
   •   Éditorialiser

Ce n'est pas un dossier amélioré.
C'est un moteur.

Comprendre qu'on travaille avec une base SQL change la perception du catalogue :
on ne manipule plus des images isolées,
on manipule un système relationnel intelligent.

Et c'est précisément ce qui en fait sa puissance.

[Samoreen]

Sous-entendrais tu Patrick que, hors catalogage Lightroom, point de salut ?

Je n'irai pas jusque là. Mais je trouve que le catalogue LR est le juste compromis entre une absence complète de fonctionnalité DAM ou quelque chose d'assez primitif comme dans DxO Photolab et certains outils de DAM survitaminés où l'excès de fonctions tue la fonction, sauf peut-être pour des travaux professionnels très lourds à gérer.

Le catalogue LR contient quelques bugs persistants mais en ce qui me concerne, c'est exactement ce qu'il me faut pour gérer mes projets, mon site et mes expos. J'utilise Photodeck pour mon site et je gère sans problème les collections depuis LR. Les galeries du site que j'ai développé pour mon ancien club sont gérées directement depuis LR. Je ne produis pas des quantités industrielles de photos. Je suis un photographe lent. Mon catalogage me permet de regrouper assez facilement quelques photographies quand je dois travailler sur un thème donné.

J'admets que c'est une question assez personnelle mais sur le fond, je suis assez d'accord avec Charlotte. Quand je vois le bazar qui règne sur les ordinateurs de certains de mes collègues/amis photographes et les pertes irrémédiables que cela provoque parfois, je suis content d'avoir des possibilités de classement directement intégrées dans le logiciel qui me sert de plate-forme générale. Même si je dois parfois utiliser des logiciels tiers : Photolab (ou plutôt PureRAW, Topaz Studio et quelques autres. Je dois toutefois préciser que j'utilise une config en double écran et que cela peut changer le point de vue sur la question.

Mais je sais que certains ne sont créatifs que dans le désordre. J'admets. En tant qu'ancien ingénieur software, mon approche est certainement un peu biaisée...

[Samoreen]

Quand on parle du catalogue de Adobe Lightroom Classic, on parle en réalité... d'une base de données SQLite.

C'est aussi le cas pour DxO Photolab. On peut facilement comparer les structures respectives de la base de données Photolab (extrêmement simpliste - ce qui explique les fonctionnalités limitées) et de LR (nettement plus complexe mais plus efficace). Idem pour Capture One.

Techniquement, on peut ouvrir un .lrcat avec un outil SQLite. Mais c'est une très mauvaise idée.

Pourquoi ?
   •   Les relations internes sont complexes
   •   Lightroom ajoute des index spécifiques
   •   Toute modification externe peut corrompre le catalogue
   •   Adobe ne garantit pas l'intégrité après intervention

Je ne suis pas trop d'accord. J'ai déjà utilisé un outil tiers (SQLite Expert - gratuit) pour intervenir dans le catalogue LR :

- pour comprendre comment le catalogue fonctionne
- pour tracer un bug (rapport remis à Adobe)
- pour corriger ou rechercher des données en batch

Je n'ai jamais eu aucun problème suite à ces manips. Mais oui, il vaut mieux s'abstenir tant que l'on a pas compris l'articulation des tables entre elles.

PS : Contrairement à ce qui a été dit plus haut, on ne perd jamais une image à cause d'un dysfonctionnement du catalogue de LR puisque les photos ne sont pas dans le catalogue qui ne fait que référencer leur emplacement. On perd des photos quand elles sont mal organisées ou que l'on a une stratégie de sauvegarde déficiente. Je n'ai jamais perdu une photo à cause du catalogue de LR mais à cause de mes propres erreurs. Là encore, Charlotte a raison, je pense.

[raymondheru]

Je n'ai jamais perdu une photo à cause du catalogue de LR mais à cause de mes propres erreurs.

CQFD. On commet des erreurs quand l'outil est peu intuitif même quand on fait partie des convaincus apparemment...
Jamais commis une seule "erreur" et donc perdu aucune photo avec ma méthode de faux désordonné 

[Gérard B.]

la mode du catalogage forcené née avec LR est une véritable calamité en général.
Liens (cor)rompus, fichiers perdus etc...

Photoshop + CR + dossiers à l'ancienne = nirvana 

Aucun problème de ce côté là pour moi. Et les collections me sont nécessaires.

[Verso92]

Je n'irai pas jusque là. Mais je trouve que le catalogue LR est le juste compromis entre une absence complète de fonctionnalité DAM ou quelque chose d'assez primitif comme dans DxO Photolab et certains outils de DAM survitaminés où l'excès de fonctions tue la fonction, sauf peut-être pour des travaux professionnels très lourds à gérer.

Le catalogue LR contient quelques bugs persistants mais en ce qui me concerne, c'est exactement ce qu'il me faut pour gérer mes projets, mon site et mes expos. J'utilise Photodeck pour mon site et je gère sans problème les collections depuis LR. Les galeries du site que j'ai développé pour mon ancien club sont gérées directement depuis LR. Je ne produis pas des quantités industrielles de photos. Je suis un photographe lent. Mon catalogage me permet de regrouper assez facilement quelques photographies quand je dois travailler sur un thème donné.

J'admets que c'est une question assez personnelle mais sur le fond, je suis assez d'accord avec Charlotte. Quand je vois le bazar qui règne sur les ordinateurs de certains de mes collègues/amis photographes et les pertes irrémédiables que cela provoque parfois, je suis content d'avoir des possibilités de classement directement intégrées dans le logiciel qui me sert de plate-forme générale. Même si je dois parfois utiliser des logiciels tiers : Photolab (ou plutôt PureRAW, Topaz Studio et quelques autres. Je dois toutefois préciser que j'utilise une config en double écran et que cela peut changer le point de vue sur la question.

Mais je sais que certains ne sont créatifs que dans le désordre. J'admets. En tant qu'ancien ingénieur software, mon approche est certainement un peu biaisée...

En fait, comme déjà évoqué, tout dépend des impératifs, des besoins et des habitudes de chacun.

En ce qui me concerne, je n'ai pas besoin de DAM : une simple arborescence de fichiers me suffit. Et j'apprécie, de plus, la complète indépendance de ma structure à l'égard des logiciels, voire des OS...

[MFloyd]

« L'habitude tue ». Heureusement, pas en photographie . C'est comme ces "CQFD" qui pullulent dans les commentaires et qui relèvent, le plus souvent, du simple sophisme.

😉

[doppelganger]

En ce qui me concerne, je n'ai pas besoin de DAM : une simple arborescence de fichiers me suffit. Et j'apprécie, de plus, la complète indépendance de ma structure à l'égard des logiciels, voire des OS...

Pareil. Ce qui ne rend pas incompatible sa propre organisation avec l'utilisation d'un logiciel fonctionnant sur la base d'un catalogue (ou d'une session, dans le cas de CA).

[doppelganger]

Je ne suis pas trop d'accord. J'ai déjà utilisé un outil tiers (SQLite Expert - gratuit) pour intervenir dans le catalogue LR :

- pour comprendre comment le catalogue fonctionne
- pour tracer un bug (rapport remis à Adobe)
- pour corriger ou rechercher des données en batch

Je n'ai jamais eu aucun problème suite à ces manips. Mais oui, il vaut mieux s'abstenir tant que l'on a pas compris l'articulation des tables entre elles.

J'ai eu à migrer mon catalogue C1 de Windows à macOS, j'ai avant tout réalisé un "ModOp" digne de ce nom, après essais / validation, afin que tout se passe bien le jours J. Y'avait, dans le lot, deux ou trois requêtes SQL. C'est bien bien parce que c'est en parti mon métier que j'ai opéré ainsi.

Finalement, je valide à 100% l'idée de ne pas aller mettre les mains sous l'capot. Autrement dit, vu que pour au moins 99% des utilisateurs, le SQL est du charabia, je ne conseillerais à personne d'aller fouiner dans une base de données, pour y jouer à l'apprenti sorcier.

[doppelganger]

PS : Contrairement à ce qui a été dit plus haut, on ne perd jamais une image à cause d'un dysfonctionnement du catalogue de LR puisque les photos ne sont pas dans le catalogue qui ne fait que référencer leur emplacement. On perd des photos quand elles sont mal organisées ou que l'on a une stratégie de sauvegarde déficiente. Je n'ai jamais perdu une photo à cause du catalogue de LR mais à cause de mes propres erreurs. Là encore, Charlotte a raison, je pense.

La fameuse interface entre la chaise et le clavier

[Samoreen]

je ne conseillerais à personne d'aller fouiner dans une base de données, pour y jouer à l'apprenti sorcier.

Bien évidemment. De toute façon, quelqu'un qui ne connaît rien aux bases de données ne saura pas quoi faire une fois le catalogue ouvert dans un outil SQL.

Je ferais cependant remarquer que si LR propose un outil d'optimisation du catalogue, ce n'est pas le cas pour DxO Photolab. Dans ce cas, le chargement de la BD dans SQLite Expert permet de procéder facilement à une réparation/optimisation sans prendre de risques. On me dira bien sûr que dans Photolab, l'optimisation de la BD consiste le plus souvent à la supprimer, ce qui causera, au pire, la perte des projets (à condition que l'on ait bien généré les fichiers .DOP).

[raymondheru]

Pour en revenir au "sujet" initial, il faut vraiment une grande méconnaissance du logiciel pour penser qu'il est inutile.
Utiliser chat GPT pour tenter de construire un argumentaire étant encore plus symptomatique d'une absence de réflexion intellectuelle digne de ce nom

[MFloyd]

En fait, comme déjà évoqué, tout dépend des impératifs, des besoins et des habitudes de chacun.

En ce qui me concerne, je n'ai pas besoin de DAM : une simple arborescence de fichiers me suffit. Et j'apprécie, de plus, la complète indépendance de ma structure à l'égard des logiciels, voire des OS...

La structure de mon fichier images est du plus simple:

2026
└── 2026-02-14

C'est super simple et j'ai une excellente mémoire doublée d'un agenda/calendrier qui me permet "physiquement" de retrouver mes images.
Tout le reste est gérée par l'application (collections, collections dynamiques, mots-clés, couleurs, notes,...)

👉 Le disque devient une simple archive technique.
👉 Le catalogue devient l'outil éditorial.

C'est la philosophie la plus moderne.

D'autres préfèrent une structure année, thématique, date

2026
├── Sport
│    └── 2026-02-14
├── Corporate

Peut-Être plus logique hors Lr.

Attention:

•    Une image ne peut appartenir qu'à une seule thématique physique
•    Devient rigide avec le temps

👉 Structure risquée si tu fais du storytelling transversal.

En résumé:

La structure disque doit être :
    •    Stable sur 20 ans
    •    Indépendante d'un logiciel
    •    Simple
    •    Non redondante
    •    Compatible sauvegarde

La structure intellectuelle, elle, doit vivre dans le catalogue.

[MFloyd]

Pour en revenir au "sujet" initial, il faut vraiment une grande méconnaissance du logiciel pour penser qu'il est inutile.
Utiliser chat GPT pour tenter de construire un argumentaire étant encore plus symptomatique d'une absence de réflexion intellectuelle digne de ce nom

Demande peut-être à Chatmachin ce que signifie une "Question rhétorique". Le doigt et la Lune ...

[Verso92]

La structure de mon fichier images est du plus simple:

2026
└── 2026-02-14

C'est super simple et j'ai une excellente mémoire doublée d'un agenda/calendrier qui me permet "physiquement" de retrouver mes images.
Tout le reste est gérée par l'application (collections, collections dynamiques, mots-clés, couleurs, notes,...)

👉 Le disque devient une simple archive technique.
👉 Le catalogue devient l'outil éditorial.

C'est la philosophie la plus moderne.

D'autres préfèrent une structure année, thématique, date

2026
├── Sport
│    └── 2026-02-14
├── Corporate

Peut-Être plus logique hors Lr.

Attention:

•    Une image ne peut appartenir qu'à une seule thématique physique
•    Devient rigide avec le temps

👉 Structure risquée si tu fais du storytelling transversal.

En résumé:

La structure disque doit être :
    •    Stable sur 20 ans
    •    Indépendante d'un logiciel
    •    Simple
    •    Non redondante
    •    Compatible sauvegarde

La structure intellectuelle, elle, doit vivre dans le catalogue.

La mienne est structurée principalement sur des lieux (avec des sous-répertoires "années" pour les endroits où je fais beaucoup de photos).

- Photos numériques
  - Angleterre
  - Bolivie
  - Canaries
  - Colombie
  - Crète
  - Cuba
  - Divers
  - Egypte
  - Equateur
  - Ethiopie
  - France
    - Aquitaine
    - Autoroutes
    - Bretagne
    - Centre
    - Champagne-Ardenne
    - Ile-de-France
      - 78
      - 91
      - 92
        - 2006
        - 2007
        - 2008
        - 2009
        - 2010
        - 2011
        - 2012
        - 2013
        - 2014
        - 2015
        - 2016
        - 2017
        - 2018
        - 2019
        - 2020
        - 2021
        - 2022
        - 2023
        - 2024
        - 2025
        - 2026
        - La Défense
      - 93
      - 94
      - 95
      - Paris
    - Limousin
    - Lorraine
    - Midi-Pyrénées
    - Nord-Pas-de-Calais
    - Normandie
    - Pays de la Loire
    - Picardie
    - Poitou-Charentes
    - Provence-Alpes-Côte d'Azur
  - Iles Anglo-Normandes
  - Inde
  - Irlande
  - Italie
  - Jordanie
  - Ladakh
  - Maroc
  - Myanmar
  - Pérou
  - Portugal
  - République dominicaine
  - Thaïlande
  - Tunisie
  - USA
  - Vietnam

A l'époque où j'ai mis en place cette arborescence (2006 ?), c'était encore l'ancien découpage des régions, que j'ai conservé.

Je me promène dans mon arborescence avec Nikon ViewNx2, intuitif et rapide (ou alors avec XnView quand il y a des RAW Sony ou Sigma).


C'est complètement adapté à mes besoins (quand je veux retrouver une photo, c'est très rapide), et je sais que je n'en changerai pas... après, je sais parfaitement que ce serait complètement inadapté pour un pro qui fait du mariage, par exemple.

Mais, ne faisant pas de mariages et n'étant pas pro...


Pour les photos argentiques (diapos), je m'appuie sur une BdD Access (environ 6 700 diapos référencées).

[raymondheru]

Pour moi c'est du année-mois pour les raw, automatisé avec un petit utilitaire.(je garde tous mes agendas pros pour connaitre la date de PdV)
Pour l'export, c'est dossier par client pour le pro et par thème/projet pour le travail plus perso.

[Verso92]

Pour moi c'est du année-mois pour les raw, automatisé avec un petit utilitaire.(je garde tous mes agendas pros pour connaitre la date de PdV)
Pour l'export, c'est dossier par client pour le pro et par thème/projet pour le travail plus perso.

Oui, bien sûr : tes besoins étant complètement différents des miens, c'est logique qu'on ait des organisations différentes.


L'essentiel (le seul critère important, en fait), c'est que ça réponde aux besoins.

[MFloyd]

La mienne est structurée principalement sur des lieux (avec des sous-répertoires "années" pour les endroits où je fais beaucoup de photos).

- Photos numériques
  - Angleterre
  - Bolivie
  - Canaries
  - Colombie
  - Crète
  - Cuba
  - Divers
  - Egypte
  - Equateur
  - Ethiopie
  - France
    - Aquitaine
    - Autoroutes
    - Bretagne
    - Centre
    - Champagne-Ardenne
    - Ile-de-France
      - 78
     ...

A l'époque où j'ai mis en place cette arborescence (2006 ?), c'était encore l'ancien découpage des régions, que j'ai conservé.

Je me promène dans mon arborescence avec Nikon ViewNx2, intuitif et rapide (ou alors avec XnView quand il y a des RAW Sony ou Sigma).


C'est complètement adapté à mes besoins (quand je veux retrouver une photo, c'est très rapide), et je sais que je n'en changerai pas... après, je sais parfaitement que ce serait complètement inadapté pour un pro qui fait du mariage, par exemple.

Mais, ne faisant pas de mariages et n'étant pas pro...


Pour les photos argentiques (diapos), je m'appuie sur une BdD Access (environ 6 700 diapos référencées).

Si cette structure te convient et te permet facilement de retrouver ce que tu cherches: why not?

Idem pour Raymondheru: votre structure de base est quasi identique à la mienne. Où ça devient compliqué c'est quand une image doit être référencée dans plusieurs classements.

[Verso92]

Si cette structure te convient et te permet facilement de retrouver ce que tu cherches: why not?

En fait, je me suis intéressé très tôt au référencement de mes photos : dès le début des années 90, j'avais construit une BdD sur l'Atari.

Celle réalisée sous Access (PC) par la suite en était le prolongement. Mais ça demandait un gros travail de saisie informatique, et pas seulement : chaque diapo avait une gommette avec un numéro de référence alphanumérique (2 lettres + 3 chiffres).


J'ai d'ailleurs repris ce genre de référencement pour mes photos numériques (3 lettres + 5 chiffres).

Élevé au MS-DOS, j'ai gardé cette habitude de 8 caractères max pour les noms de fichiers pour l'archivage...

[MFloyd]

Les 8 caractères traînent encore par ci ou par là: dans le nom des fichier images ... du style DSC_0001.NEF par exemple. Ce qui me fait penser aux interfaces des appareils photos qui en sont restés à l'époque du MS-DOS. Mais ça c'est un autre sujet à aborder.

[Verso92]

Les 8 caractères traînent encore par ci ou par là: dans le nom des fichier images ... du style DSC_0001.NEF par exemple. Ce qui me fait penser aux interfaces des appareils photos qui en sont restés à l'époque du MS-DOS. Mais ça c'est un autre sujet à aborder.

Personnellement, je pense que c'est la voie de la sagesse (ne serait-ce que pour le micro-code des APN).

Et, en ce qui me concerne, il n'y aurait aucun intérêt à aller au delà dans mon archivage.


Même si ce n'est pas directement comparable, on rencontre régulièrement des problèmes au boulot lors des migrations, à cause de noms de fichiers qui, arborescence comprise, dépassent le nombre de caractères autorisés par l'OS du moment (256 ?)...