Ma stack technique de photographe-développeur, et pourquoi j’ai fait ces choix

Dans mon métier, je passe mes journées à optimiser des processus grâce à la data et à l’IA. C’est devenu un réflexe : dès qu’une tâche se répète, je cherche comment la remplacer par de la donnée bien structurée et un peu d’automatisation, plutôt que de la refaire à la main indéfiniment.

Je ne suis pas photographe professionnel, mais je vends régulièrement des tirages, et j’ai fini par réaliser que je passais bien plus de temps que je ne le voulais sur le backoffice de cette activité : éditer un certificat d’authenticité, mettre à jour la compta, relancer un contact d’exposition, tenir mon catalogue à jour. Rien de tout ça n’est de la photographie, et pourtant ça grignotait le temps que je voulais consacrer à shooter, pas à gérer de l’administratif. Je me suis rendu compte que j’avais, sous la main, exactement les compétences pour appliquer à ma pratique de photographe ce que je fais tous les jours au travail.

C’est ce qui m’a poussé à construire ma propre stack technique. Pas par goût du gadget, mais parce qu’à un moment j’ai préféré passer quelques soirées à automatiser plutôt que de continuer à perdre des heures chaque semaine sur des tâches répétitives. Cet article détaille cette stack : ce que j’utilise, comment les briques s’articulent entre elles, et surtout pourquoi j’ai fait ces choix plutôt que d’autres. L’idée n’est pas de vous transformer en développeur, mais de vous montrer qu’avec les bons outils, une bonne partie de la gestion d’une activité de photographe peut tourner toute seule.

Avant de lister les outils, un mot sur la logique qui les relie. Je ne suis pas développeur de métier : je suis photographe qui a appris à coder par nécessité, pas l’inverse. Ça change complètement la façon d’aborder les choix techniques.

Ma règle de base : ne jamais coder ce qui peut être assemblé avec du no-code ou du low-code, et ne coder « en dur » que ce qui a vraiment besoin d’un vrai logiciel — typiquement quand le résultat doit devenir un produit utilisable par d’autres photographes, pas juste un bricolage personnel. C’est pour ça que ma gestion interne (certificats, compta, catalogue) repose presque entièrement sur des outils d’automatisation visuelle, alors qu’Optiq AI, mon plugin d’analyse IA pour Lightroom Classic, est du code à part entière.

Cette distinction structure toute la stack : d’un côté des briques d’automatisation pour piloter mon activité, de l’autre du développement plus classique pour le produit destiné aux autres photographes.

Concrètement, la stack s’articule autour de cinq briques principales : Lightroom Classic comme point de départ de tout mon flux photo, Notion comme base de données centrale, n8n et Make.com comme moteurs d’automatisation, et OpenRouter comme porte d’entrée vers les modèles d’IA. Autour de ça gravitent quelques outils Google et, pour l’encaissement en exposition, SumUp.

Chacune de ces briques a été choisie pour une raison précise, souvent après avoir testé autre chose avant. Je détaille chacune ci-dessous, avec les workflows concrets qu’elles font tourner au quotidien.

Notion est le cœur de tout. C’est là que vit mon catalogue de tirages, le suivi des ventes, l’historique des certificats d’authenticité, mes contacts d’exposition. Rien de très original en soi — beaucoup de monde utilise Notion comme base de connaissance personnelle — mais dans ma stack, Notion joue un rôle précis : celui de base de données que toutes mes automatisations lisent et écrivent.

Je l’ai choisi plutôt qu’une vraie base de données (Airtable, une base SQL, ou même un simple tableur) pour une raison très pragmatique : c’est l’outil que j’ouvre naturellement pour consulter l’information, avec une interface qui reste agréable même quand ce n’est pas un développeur qui la regarde. Une automatisation qui écrit dans une base illisible n’a que la moitié de sa valeur. Notion me donne à la fois une API propre pour mes scripts et une interface que je peux consulter ou modifier à la main sans effort.

C’est d’ailleurs ce qui m’a poussé à passer sur l’offre payante : les graphiques natifs de Notion, branchés directement sur ma base de suivi des ventes, me donnent une vue chiffre d’affaires par mois, répartition par format de tirage ou par exposition, sans avoir à exporter quoi que ce soit vers un outil de reporting séparé. Rien de spectaculaire, mais ça m’évite de reconstruire à la main ce que Notion sait déjà faire correctement, et ça garde toute la comptabilité — données et visualisation — au même endroit.

C’est aussi la brique la plus tournée vers l’avenir : je prépare actuellement des templates Notion pour d’autres photographes — quelques bases essentielles en gratuit, un système complet de gestion d’activité en payant. Le fait que ma propre gestion tourne déjà dessus depuis un moment est une forme de validation en conditions réelles avant de la proposer à d’autres.

n8n est l’outil qui surveille et déclenche. Concrètement, il tourne dans un conteneur Docker sur un Mac mini que j’ai dédié à cet usage à la maison — pas de cloud, pas d’abonnement mensuel pour l’hébergement, juste une petite machine qui tourne en continu.

Ce choix de l’auto-hébergement n’est pas anodin. Il m’a demandé un peu de mise en place au départ (Docker, configuration réseau, sauvegardes), mais il m’apporte deux choses que je ne voulais pas sacrifier : le contrôle total sur mes données — mes exports Lightroom, mes informations de vente, tout ça reste chez moi et ne transite pas par un service tiers avant d’arriver dans Notion — et l’absence de coût récurrent lié au volume d’exécutions, ce qui compte quand on multiplie les automatisations sans forcément avoir un gros volume d’affaires derrière.

Le rôle de n8n dans mes workflows est presque toujours le même : surveiller un dossier ou une source de données, détecter un événement, et déclencher la suite. Deux exemples concrets tournent avec :

Le premier, ce sont les certificats d’authenticité. Quand j’exporte un tirage vendu depuis Lightroom vers un répertoire spécifique, n8n surveille ce dossier, détecte le nouvel export, et crée automatiquement une ligne correspondante dans ma base Notion. Fini la saisie manuelle à chaque vente, fini le risque d’oubli le jour où on est pressé.

Le second, plus récent et encore en développement, concerne la comptabilité. Chaque encaissement passé sur mon terminal SumUp — typiquement pendant une exposition — est récupéré automatiquement par n8n, qui vient créer l’enregistrement correspondant dans mon suivi comptable sur Notion. Avant, chaque vente en expo impliquait une ressaisie manuelle le soir en rentrant, avec le risque classique d’en oublier une ou de se tromper de montant.

Il y a un aspect auquel je tiens à m’arrêter ici, parce que ça compte sincèrement pour moi : l’impact écologique de l’IA que j’utilise. Entre Optiq AI, les automatisations n8n et le reste, j’utilise probablement l’IA plus qu’une bonne partie des photographes qui liront cet article — mais j’essaie de le faire de façon mesurée et responsable plutôt que d’envoyer systématiquement chaque tâche vers le plus gros modèle disponible.

Concrètement, ça passe par une distinction entre LLM et SLM. Un LLM (Large Language Model, ou grand modèle de langage) désigne les modèles massifs comme GPT-4o, Claude ou Gemini : entraînés sur d’immenses volumes de données, capables de raisonner sur des tâches complexes, mais hébergés dans des datacenters et coûteux en énergie à chaque requête. Un SLM (Small Language Model, ou petit modèle de langage) est une version bien plus légère — quelques milliards de paramètres au lieu de centaines — moins polyvalente, mais largement suffisante pour des tâches simples de classification ou de mise en forme, et qui peut tourner directement sur du matériel grand public.

Dans mes automatisations n8n, une partie des traitements liés aux certificats et à la comptabilité passe justement par un SLM que je fais tourner en local via Ollama, sur mon Mac mini, plutôt que d’envoyer chaque petite requête vers un LLM cloud. Le résultat est équivalent pour ce type de tâche, mais sans latence réseau, sans dépendance à un fournisseur externe, et avec une consommation d’énergie sans commune mesure avec un appel à un modèle massif hébergé ailleurs. Je réserve les LLM cloud, via OpenRouter, aux tâches qui le justifient vraiment — typiquement l’analyse visuelle fine d’Optiq AI, où la capacité de raisonnement d’un grand modèle apporte une vraie valeur.

Make.com est arrivé avant n8n dans ma stack, et c’est resté honnêtement la principale raison pour laquelle je continue à l’utiliser en parallèle. Il y a une vraie question de cohérence à se poser — pourquoi faire tourner deux outils d’automatisation plutôt qu’un seul — et je n’ai pas de réponse architecturale définitive à donner. La vraie réponse est plus simple : j’avais déjà des automatisations qui tournaient sur Make, elles fonctionnent bien, et je ne vois pas encore l’intérêt de tout migrer vers un outil unique. Ce n’est pas un dogme, juste une histoire de coût de migration face à un bénéfice qui reste flou tant que rien ne casse.

Dans le workflow des [certificats d’authenticité](https://www.bertrandbayer.com/guide-certificats-authenticite-photographe/), Make prend le relais une fois que n8n a créé la ligne dans Notion : c’est lui qui génère le PDF du certificat, prêt à imprimer, à partir des informations de cette ligne. Le résultat pour moi : zéro double saisie, zéro oubli, et un certificat disponible dès la fin de l’export Lightroom, sans que j’aie à y penser.

Si je devais résumer la différence de rôle entre les deux outils dans ma stack aujourd’hui, ce serait plutôt : n8n pour la détection et le déclenchement, hébergé chez moi ; Make pour l’orchestration qui suit et la génération de documents. Mais je le redis, ce n’est pas un plan conçu à l’avance — c’est la manière dont les choses se sont organisées au fil du temps, et ça fonctionne, donc je n’ai pas de raison urgente d’y toucher.

Cela dit, la tendance de fond est assez claire : je vais probablement migrer progressivement mes scénarios de Make vers n8n. Pas dans un grand chantier planifié, mais scénario par scénario, à mesure que l’auto-hébergement gagne en maturité chez moi et que ça devient plus simple de tout garder au même endroit, sous mon contrôle, plutôt que de continuer à payer un abonnement pour des automatisations que n8n saurait tout aussi bien reproduire.

OpenRouter est la brique qui donne accès aux modèles d’intelligence artificielle dans l’ensemble de ma stack — pas seulement pour Optiq AI, mais partout où j’ai besoin d’appeler un modèle de langage. Plutôt que d’intégrer directement l’API de chaque fournisseur (Anthropic, OpenAI, Google), OpenRouter joue le rôle d’une couche unique qui me permet de basculer entre les modèles sans réécrire mon code à chaque fois.

Ce choix a deux justifications. La première est pratique : quand un nouveau modèle sort ou qu’un fournisseur ajuste ses prix, je peux changer de modèle en modifiant un paramètre plutôt qu’en refaisant une intégration complète. La seconde est plus spécifique à mon usage : dans Optiq AI, je laisse justement le photographe choisir son modèle — Claude d’Anthropic, GPT-4o d’OpenAI, ou Gemini de Google — parce que chaque modèle a sa propre sensibilité sur l’analyse d’une image, et je ne voulais pas trancher à sa place. OpenRouter rend ce choix possible sans multiplier le travail d’intégration de mon côté.

Optiq AI, mon plugin d’analyse IA pour Lightroom Classic, est développé avec le SDK officiel d’Adobe pour Lightroom Classic. C’est la seule brique de toute la stack qui relève du développement logiciel classique plutôt que de l’automatisation, et c’est un choix délibéré : un plugin qui vit directement dans Lightroom, là où le photographe travaille déjà, plutôt qu’une application séparée qu’il faudrait ouvrir en plus.

Le fonctionnement est simple à décrire même si la mécanique derrière est plus complexe : la photo est analysée directement dans Lightroom, le plugin envoie les informations nécessaires au modèle d’IA choisi via OpenRouter, et récupère en retour un radar sur six critères photographiques — composition, mise au point, exposition, couleurs, impact émotionnel, singularité — accompagné de réglages de curseurs suggérés avec des valeurs précises, et de mots-clés générés automatiquement. L’analyse est calibrée selon le niveau du photographe, du débutant au professionnel, et c’est toujours lui qui décide d’appliquer ou non les suggestions.

Rester dans le SDK natif de Lightroom Classic plutôt que de partir sur une application web ou desktop indépendante m’a semblé être le seul choix cohérent avec l’usage réel : aucun photographe n’a envie d’exporter ses photos vers un outil tiers juste pour obtenir un avis sur ses réglages. Le prix à payer, c’est un développement plus contraint techniquement — le SDK a ses limites et son propre langage, Lua — mais le gain en fluidité pour l’utilisateur final justifie largement cette contrainte.

Autour de ce noyau, quelques outils Google interviennent en soutien — feuilles de calcul, stockage, formulaires selon les besoins ponctuels. Rien qui mérite un développement long ici : ce sont des briques d’appoint, choisies parce qu’elles s’intègrent facilement avec n8n et Make, et qu’elles ne demandent aucune mise en place particulière.

La question revient souvent : pourquoi ne pas tout centraliser sur Zapier, ou tout migrer sur Make, ou tout basculer sur n8n, plutôt que de faire cohabiter plusieurs outils qui se recoupent en partie ? La réponse honnête, je l’ai déjà donnée pour Make et n8n : c’est autant une question d’histoire personnelle que de choix rationnel a priori. Mais il y a quand même une logique qui se dégage après coup, même si elle n’a pas été pensée dès le départ.

Un outil auto-hébergé comme n8n a un coût de mise en place — Docker, un Mac mini dédié, un minimum de maintenance — mais aucun coût récurrent lié au volume, et un contrôle total sur des données que je préfère garder chez moi avant qu’elles n’atterrissent dans Notion. Un outil cloud comme Make a l’avantage inverse : zéro installation, une bibliothèque d’intégrations déjà prête (génération de PDF, connecteurs SumUp, etc.), avec un modèle de prix qui grimpe avec le nombre d’exécutions et de scénarios au-delà d’un certain seuil — même si, dans mon cas, mon volume reste encore dans la version gratuite. Dans les faits, je me retrouve à utiliser chaque outil là où son compromis me convient le mieux à un instant donné, plutôt que d’imposer un choix unique à toute la stack au prix d’une migration qui ne m’apporterait, pour l’instant, aucun bénéfice concret.

C’est une question qu’on me pose souvent quand je parle de cette stack à d’autres photographes, donc autant être transparent. Contrairement à ce qu’on pourrait imaginer, Make ne me coûte rien : je reste sur la version gratuite, largement suffisante pour mon volume de scénarios. Le vrai poste de dépense, c’est plutôt Notion, où je suis passé sur un abonnement payant — pas par confort, mais parce que j’ai besoin des graphiques pour mon suivi comptable et d’un chargement de fichiers illimité, puisque j’utilise aussi Notion comme base de connaissance plus large, pas seulement comme backend de gestion. Le Mac mini qui héberge n8n a été un investissement ponctuel plutôt qu’une charge récurrente, amorti depuis longtemps rien qu’en temps de saisie économisé. OpenRouter facture à l’usage des modèles appelés, ce qui reste marginal tant qu’on ne fait pas tourner ça à trois cent photos par jour. Rien de tout ça n’est hors de portée d’un photographe indépendant qui vend régulièrement des tirages, mais ce n’est pas forcément là où on l’attendrait que se trouve la dépense.

Je précise volontiers ce point parce que je sais que la partie technique de cet article peut sembler intimidante si on ne vient pas de ce monde-là — ce qui était mon cas il n’y a pas si longtemps. On n’a pas besoin de partir sur du Docker et un Mac mini dédié pour commencer à automatiser sa gestion.

La progression la plus raisonnable, c’est de commencer par une base Notion propre pour centraliser catalogue et ventes — c’est d’ailleurs tout l’objet des templates que je prépare actuellement, une partie gratuite pour poser les bases essentielles. Une fois cette base en place, Make (ou un équivalent no-code comme Zapier) suffit largement pour connecter deux ou trois outils entre eux sans écrire une ligne de code, avec une interface visuelle pensée pour ça. L’auto-hébergement avec n8n, le développement d’un plugin avec un SDK, tout ça ne devient pertinent que plus tard, quand le volume ou les besoins spécifiques le justifient vraiment. Je suis passé par ces étapes dans cet ordre, pas l’inverse.

Le résultat de tout ça, ce n’est pas une usine à gaz qu’il faut surveiller en permanence. C’est plutôt l’inverse : une fois les workflows en place, je ne pense quasiment plus à la partie administrative de mon activité. Une vente de tirage génère son certificat sans intervention de ma part. Un encaissement en exposition finira bientôt sa route jusqu’à ma compta sans ressaisie. Et sur le terrain, le vrai retour objectif que je n’ai plus le recul de me donner moi-même après une longue sortie, Optiq AI me le fournit directement dans Lightroom.

Rien de tout ça n’est parfait ni figé. Make reste dans la stack par pragmatisme plus que par conviction architecturale, la comptabilité automatisée est encore en développement, et les templates Notion ne sont pas encore tous disponibles. Mais c’est justement l’intérêt de documenter cette stack maintenant : elle continue d’évoluer, brique par brique, à mesure que j’identifie une nouvelle tâche répétitive à automatiser plutôt qu’à subir.

Si vous êtes photographe et que vous vous reconnaissez dans ce constat de départ — trop de temps perdu sur l’administratif, pas assez sur la photo — n’hésitez pas à me contacter. Je partage volontiers mon expérience, et certains de ces outils (les [templates Notion, le guide des certificats d’authenticité, la bêta d’Optiq AI](https://www.bertrandbayer.com/mes-outils-ia/)) sont déjà accessibles ou le seront bientôt.