Lightroom Classic CC... Cloud obligatoire?

[tenmangu81]

J'ai essayé DPL, et l'ai acheté. Pas convaincu du tout.
Oui, Capture One vise "l'élite", à savoir les pros et/ou ceux qui ont les moyens. Mais son dématriceur est hors pair. Son catalogue devient correct, son module d'impression ne l'est pas encore. C'est le logiciel que je préfère (et que j'utilise) après avoir passé plusieurs années (depuis sa création) avec Lightroom, et essayé darktable, Lumariver et d'autres.

[Samoreen]

Dingue comment Adobe aime disperser ces morceaux logiciels et ses satellites (logs, fichiers de config) un peu partout sur le système.
...
Franchement, les directeurs de dev doivent être particulièrement retors pour penser (ou laisser faire) pareille gabegie.

Là-dessus, j'ai une réponse. Au cours de ma carrière de consultant et formateur "développement", je me suis souvent interrogé sur ces phénomènes. J'ai quelques élements de réponse qui valent ce qu'ils valent mais qui semblent se confirmer avec le temps...

Le premier point est la perte de maîtrise. Le turn over important, le recours à l'offshore, la mauvaise documentation du code et la pression du marketing font que beaucoup de logiciels suivent une courbe asymptotique qui les rapproche progressivement d'une situation où plus personne n'a la maîtrise complète du logiciel, de son histoire et de sa conception. Les designs initiaux sont rarement pensés en vue des évolutions futures qui se font donc par l'ajout de couches dont les effets de bord sont peu (ou pas) mesurés. Au bout d'un certain temps, le logiciel atteint un état où l'ajout ou la modification de fonctions génère plus d'ennuis que de bénéfices pour l'utilisateur (on vend des mises à jour qui ne servent globalement à rien). Le mille-feuilles grossit et on oublie de retirer les couches devenues inutiles et de les nettoyer au moment des mises à jour. Pire, on n'ose pas les retirer de peur de casser quelque chose (j'ai déjà vu ça).

Il y a ensuite le problème de la méthodologie de développement. On sait aujourd'hui comment développer des logiciels ayant un taux de bugs très réduit et on dispose des outils pour le faire. J'ai enseigné ça pendant des années à des développeurs et à des chefs de projet. Et j'ai toujours eu les mêmes réactions : c'est super mais on ne s'en servira pas. Pourquoi ? Parce que cela reviendrait à déplacer les coûts du département support vers le département développement (développement plus propre, plus sain mais plus long et donc plus cher). Même si beaucoup reconnaissent que cela représenterait un bénéfice global pour l'entreprise (et pour l'utilisateur), la gestion par mise en concurrence des services ainsi que la toxicité des impératifs calendaires du département marketing font que l'on s'en tient aux méthodes habituelles.

Les conséquences sont connues. On attend que le logiciel "s'étouffe" lui-même, on le retire du marché, on sort une nouveauté et le cycle recommence. Ces problèmes ont commencé à se développer massivement au début des années 90 avec l'apparition des outils de programmation automatisés qui permettaient d'embaucher dans les équipes de développement à des niveaux de compétence nettement plus bas. Et surtout, partout, dans tous les domaines, le personnel technique a perdu toute la part d'autorité qu'il pouvait avoir au profit des financiers et des marketeurs. On en arrive donc à des situations où, pour citer Adobe, on peut lire les interventions de certains membres du staff qui visiblement ne savent pas grand-chose du logiciel dont ils parlent (parfois moins que certains utilisateurs).

Revenir en arrière sur cette approche est nécessaire mais sera incroyablement difficile. Ce qui m'inquiète, c'est qu'elle a contaminé des domaines où, jusqu'ici, on s'astreignait encore à une grande rigueur. L'affaire récente des Boeing Max en est une dramatique démonstration. Tous ceux qui ont réfléchi de manière un peu approfondie aux processus de développement logiciels savaient que ce type d'accident majeur allait arriver. Et je suis convaincu que ça va continuer...

[Samoreen]

...son module d'impression ne l'est pas encore.

Bonjour Robert,

Tu imprimes avec quoi ?

[Nikojorj]

(QImage est excellent malgré une interface désuète)

Désuète? Je me permettrai de respectueusement disconvenir, déjà à sa sortie on s'arrachait les cheveux avec, alors qu'on n'avait guère que PS pour comparer...
Et du point de vue qualité, sorti des mires synthétiques, je trouve que l'irrecommandable Lightroom fait aussi bien.

[Samoreen]

Désuète? Je me permettrai de respectueusement disconvenir, déjà à sa sortie on s'arrachait les cheveux avec, alors qu'on n'avait guère que PS pour comparer...
Et du point de vue qualité, sorti des mires synthétiques, je trouve que l'irrecommandable Lightroom fait aussi bien.

D'accord, j'ai été particulièrement indulgent. Si on reste plus d'une semaine sans s'en servir, il faut ressortir le manuel (dont la lecture est déjà une épreuve en soi). Cependant, j'ai pu imprimer correctement avec QImage des images que LR était incapable de sortir. En particulier des images ayant une tendance à présenter du moiré. Cela dit, la majeure partie de mes impressions "maison" sont faites avec LR. Par contre, je n'ai jamais testé l'impression sous C1 ou Affinity Photo.

[Nikojorj]

Je veux bien mettre moi aussi de l'eau dans mon vin et reconnaître qu'il y a des fonctions de mise en page bien pratiques dans QImage (une fois qu'on a compris comment ça marche  ), et je note ton appréciation pour les images à moiré.

[alafaille]

...

Le premier point est la perte de maîtrise. Le turn over important, le recours à l'offshore, la mauvaise documentation du code et la pression du marketing font que beaucoup de logiciels suivent une courbe asymptotique qui les rapproche progressivement d'une situation où plus personne n'a la maîtrise complète du logiciel, de son histoire et de sa conception. Les designs initiaux sont rarement pensés en vue des évolutions futures qui se font donc par l'ajout de couches dont les effets de bord sont peu (ou pas) mesurés. Au bout d'un certain temps, le logiciel atteint un état où l'ajout ou la modification de fonctions génère plus d'ennuis que de bénéfices pour l'utilisateur (on vend des mises à jour qui ne servent globalement à rien). Le mille-feuilles grossit et on oublie de retirer les couches devenues inutiles et de les nettoyer au moment des mises à jour. Pire, on n'ose pas les retirer de peur de casser quelque chose (j'ai déjà vu ça).

Il y a ensuite le problème de la méthodologie de développement. On sait aujourd'hui comment développer des logiciels ayant un taux de bugs très réduit et on dispose des outils pour le faire. J'ai enseigné ça pendant des années à des développeurs et à des chefs de projet. Et j'ai toujours eu les mêmes réactions : c'est super mais on ne s'en servira pas. Pourquoi ? Parce que cela reviendrait à déplacer les coûts du département support vers le département développement (développement plus propre, plus sain mais plus long et donc plus cher). Même si beaucoup reconnaissent que cela représenterait un bénéfice global pour l'entreprise (et pour l'utilisateur), la gestion par mise en concurrence des services ainsi que la toxicité des impératifs calendaires du département marketing font que l'on s'en tient aux méthodes habituelles.

Les conséquences sont connues. On attend que le logiciel "s'étouffe" lui-même, on le retire du marché, on sort une nouveauté et le cycle recommence. Ces problèmes ont commencé à se développer massivement au début des années 90 avec l'apparition des outils de programmation automatisés qui permettaient d'embaucher dans les équipes de développement à des niveaux de compétence nettement plus bas. Et surtout, partout, dans tous les domaines, le personnel technique a perdu toute la part d'autorité qu'il pouvait avoir au profit des financiers et des marketeurs. On en arrive donc à des situations où, pour citer Adobe, on peut lire les interventions de certains membres du staff qui visiblement ne savent pas grand-chose du logiciel dont ils parlent (parfois moins que certains utilisateurs).

Revenir en arrière sur cette approche est nécessaire mais sera incroyablement difficile. Ce qui m'inquiète, c'est qu'elle a contaminé des domaines où, jusqu'ici, on s'astreignait encore à une grande rigueur. L'affaire récente des Boeing Max en est une dramatique démonstration. Tous ceux qui ont réfléchi de manière un peu approfondie aux processus de développement logiciels savaient que ce type d'accident majeur allait arriver. Et je suis convaincu que ça va continuer...

Je me sens moins seul avec mes pensées sur l'évolution du développement informatique ...

[tenmangu81]

Bonjour Robert,

Tu imprimes avec quoi ?

Bonjour Patrick,

J'utilise Photoshop ou Lightroom. J'ai des soucis de colorimétrie avec Capture One, mais je n'ai pas dit mon dernier mot. Mais, de toutes façons, les modules Adobe sont encore meilleurs. Et je n'ai pas d'imprimante compatible avec un RIP, et n'en veux pas : celle que j'ai épate un peu, même les professionnels, et c'est pourtant une petite Canon de base !!

[albert-r]

Bonsoir,

J'ai trouvé que le fait d'exporter les photos depuis C1, en jpg qualité sur 100, avec un Gain de netteté de sortie pour impression, de les importer dans le logiciel Photos donnait à mes yeux de bons résultats, l'impression se faisant avec une HP Envie Photo 7134

[tenmangu81]

J'avais aussi essayé de passer par "Photos", et ça marche à peu près, même si on n'a pas la même latitude de réglages physiques (marges, cellules, etc...) qu'avec Photoshop ou Lightroom. Et on gère un peu moins bien l'espace couleur.