PhotoCraft agent-ready : piloter la retouche par CLI, JSON et MCP

Ce qu’il faut retenir

• PhotoCraft se présente comme une réimplémentation open source de Photoshop en Rust, avec exécution native, locale et hors ligne annoncée par le projet. Il ne faut pas confondre cette promesse avec une parité comportementale déjà démontrée sur tous les fichiers.
• Le point intéressant pour un workflow agentique est le registre de commandes partagé : une action d’interface peut devenir une commande CLI, une étape JSON ou un appel MCP, selon les contrôles réellement exposés.
• La release 0.6.0 a passé un test CLI réel : créer un document 320 × 200, ajouter un calque, inspecter l’arbre et exporter une image PNG. Ce test ne prouve pas la conservation des calques dans un PSD.
• Le mode batch protège les sources en refusant par défaut un dossier de sortie identique au dossier d’entrée. Cette petite contrainte est un garde-fou de production plus utile qu’une promesse vague d’automatisation.
• Les exemples MCP sont documentés, avec des racines de lecture et d’écriture explicites, mais ils sont marqués « documentés, non exécutés » ici. Un agent doit inspecter le document après un timeout avant de relancer une commande.
• Pour une agence ou un studio, le bon premier périmètre n’est pas « remplacer Photoshop ». C’est choisir une opération répétitive, isoler les copies, journaliser les commandes et placer une revue humaine avant livraison.

---

Pourquoi PhotoCraft intéresse un workflow agentique

Le dépôt officiel décrit PhotoCraft comme un éditeur d’images natif en Rust, avec calques, masques, réglages, texte, vecteurs et fichiers PSD. Le moteur revendique une exécution locale et hors ligne. La page du projet met surtout en avant un autre trait : chaque action passe par une commande, et l’interface, la CLI, le canal JSON et MCP appellent le même registre.

Cette architecture change le problème. Avec une application purement visuelle, l’automatisation doit souvent simuler des clics ou dépendre d’un script fragile. Avec un moteur commandable, on peut décrire une opération, conserver ses paramètres, produire une sortie séparée et inspecter l’état du document. Ce n’est pas encore une garantie de qualité : une commande bien formée peut appliquer la mauvaise action au bon fichier.

Le dépôt annonce plus de 500 commandes et une couverture complète du menu Photoshop dans sa matrice de parité. Ces indicateurs décrivent une surface d’interface et un registre ; ils ne remplacent pas un test sur vos documents, vos profils colorimétriques, vos polices, vos effets ou vos objets dynamiques.

Pour éviter un contresens, gardez quatre niveaux séparés :

Niveau	Ce qu’il permet d’affirmer	Ce qu’il ne permet pas d’affirmer
Annoncé par le dépôt	PhotoCraft possède une CLI, un canal JSON et un serveur MCP documentés	Que chaque commande fonctionne avec chaque PSD
Disponible dans la release ciblée	Le binaire 0.6.0 et ses sous-commandes sont accessibles	Que votre poste ou votre version de Rust reproduit le même environnement
Testé ici	Le scénario run et un batch à sortie séparée ont abouti	Que le round-trip PSD ou MCP est validé
Recommandé pour la production	Isoler les entrées, sorties et points de contrôle	Déléguer sans revue une retouche irréversible

---

Le setup minimal : une source, une commande, une sortie

Avant de parler d’agent, construisez un test que quelqu’un d’autre peut relancer. Il faut une version identifiée, un fichier d’entrée non confidentiel, une action unique, un dossier de sortie séparé et un critère de réussite lisible.

1. Fixer la version et le périmètre

La version ciblée ici est la release officielle PhotoCraft v0.6.0, testée avec le binaire photocraft-cli sur macOS. La compilation depuis les sources n’a pas été utilisée dans ce run : l’environnement local exposait Rust 1.72 alors que la chaîne de build attendait une version plus récente. Cette limite est importante pour un guide d’équipe : « installer depuis les sources » et « utiliser le binaire de release » ne sont pas la même procédure.

Préparez ensuite un dossier qui ne contient aucune source client. Un fichier de test doit rendre visibles les résultats : dimensions, mode colorimétrique, calques, nom de sortie et éventuellement un export aplati distinct du document éditable.

2. Décrire l’opération avant de l’exécuter

Dans ce guide, l’opération minimale est volontairement petite : créer un nouveau document, ajouter un calque nommé Ink, demander une inspection, puis exporter un PNG. Le test ne cherche pas à produire une belle image ; il vérifie que la chaîne document → commande → inspection → export est observable.

photocraft-cli run --new '{"width":320,"height":200,"mode":"rgb","depth":8,"background":"white"}' \
  --cmd layer.new.layer --params '{"name":"Ink"}' \
  --cmd document.inspect --out command-test.png

Statut : testé le 10 octobre 2026. Le retour document.inspect a décrit un document RGB de 320 × 200 avec un calque sélectionné nommé Ink, et l’export PNG a réussi. Le PNG est une sortie plate : il ne constitue pas une preuve de préservation des calques PSD.

3. Traiter les paramètres comme un contrat

Un agent ne doit pas inventer les identifiants de commandes ou la forme des paramètres. La documentation de développement montre des commandes comme layer.new.layer, filter.blur.gaussianBlur, document.inspect et commands --filter. La bonne pratique consiste à interroger la liste des commandes, à conserver le JSON transmis et à relire le résultat retourné.

photocraft-cli commands --filter blur

Si l’identifiant, le mode ou le paramètre n’est pas confirmé par la documentation ou par une sortie de l’outil, présentez-le comme une piste à vérifier, pas comme un prompt prêt à copier.

---

Le cas pratique : une retouche reproductible sans écraser la source

Le cas exécuté est pédagogique et ne porte sur aucun fichier client. L’objectif est de démontrer une chaîne causale minimale : une mission bornée, une entrée produite pour le test, une opération explicite, une inspection et une sortie indépendante.

Brief et critère de réussite

Brief fictif : préparer une opération de correction que trois personnes puissent relancer sur des visuels de préproduction, sans toucher au dossier original.

Critère de réussite : la commande doit produire un résultat dans un dossier distinct, retourner un état inspectable et laisser une trace suffisante pour comprendre ce qui s’est passé. La réussite ne signifie pas que la retouche est validée pour diffusion.

Le test CLI run a servi à vérifier la création de document, l’ajout d’un calque et l’inspection. Un second test batch a traité une image PNG plate dans un dossier de sortie séparé.

Le batch : répéter, mais dans un autre dossier

La documentation accepte un fichier actions.json sous plusieurs formes : liste de couples identifiant/paramètres, objets command/params, identifiants seuls, ou enveloppes actions et steps. Dans tous les cas, le fichier doit être versionné avec le test et relu avant exécution.

photocraft-cli batch --actions actions.json --in batch-in --out batch-out --format png

Statut : testé le 10 octobre 2026. Une image PNG d’entrée a été traitée vers le dossier de sortie distinct. Le garde-fou a été observé : le batch refuse par défaut que --out soit le même dossier que --in, sauf si --in-place est demandé explicitement.

Le résultat reste limité : une image PNG plate ne permet pas de conclure sur le round-trip PSD, les calques, les masques ou les objets dynamiques. C’est précisément pourquoi le journal du test doit conserver le format d’entrée et ne pas écrire seulement « la commande a fonctionné ».

---

MCP : exposer des commandes, pas déléguer le jugement

PhotoCraft documente un serveur MCP en mode headless et un mode bridge vers une application desktop. La version headless reçoit explicitement une racine de lecture et une racine d’écriture ; sans ces racines, elle n’a pas d’autorité sur le système de fichiers. Cette séparation est saine pour une équipe : le dossier autorisé fait partie du contrat de l’agent.

Le projet documente notamment doc_open, doc_new, doc_save, doc_export, doc_inspect, doc_render_preview, command_list, command_run et command_batch. Il propose une boucle simple : ouvrir, lister les commandes, exécuter, rendre un aperçu, inspecter, puis sauvegarder dans un chemin choisi.

Le guide Claude et les images : construire un workflow créatif avec un connecteur MCP traite une question proche — faire circuler un brief vers un outil — mais avec un service d’image distant. PhotoCraft ajoute ici un moteur local et des fichiers PSD à contrôler ; le rôle de MCP reste celui d’un transport outillé, pas celui d’un directeur artistique.

Mode headless : les racines sont une permission

La forme documentée est la suivante :

photocraft-cli mcp \
  --automation-read-root /work/project \
  --automation-write-root /work/project

Dans une vraie équipe, ne pointez pas ces racines vers le bureau complet ou un volume partagé sans tri. Créez un espace de travail dédié, copiez-y les entrées autorisées, et utilisez une sortie qui permet la comparaison. L’agent peut travailler dans cette zone sans obtenir une permission implicite sur les archives, les identifiants ou les fichiers clients non concernés.

Statut : documenté, non exécuté. Le serveur MCP, ses outils et ses exemples n’ont pas été lancés dans ce run. Les commandes ci-dessus décrivent le contrat officiel, pas un résultat observé sur cette machine.

Bridge desktop : authentifier, puis inspecter

Le mode bridge connecte la CLI à une application desktop via loopback et fichier de token. La documentation précise que l’adresse doit rester locale et que le serveur de contrôle est authentifié. Elle indique aussi une limite importante : un timeout peut arriver après le démarrage d’une opération ; la requête n’est pas automatiquement renvoyée.

photocraft --control 7878 \
  --control-token-file /chemin/prive/photocraft-control.token \
  --automation-read-root /work/project \
  --automation-write-root /work/project

photocraft-cli mcp --bridge 127.0.0.1:7878 \
  --control-token-file /chemin/prive/photocraft-control.token

Après un timeout, ne relancez pas immédiatement une retouche. Ouvrez ou inspectez le document, vérifiez son historique et son chemin de sortie, puis décidez si une nouvelle commande est nécessaire. Ce réflexe évite le cas classique où un agent applique deux fois une opération qui avait en réalité abouti.

---

Ce qu’un agent peut faire — et ce qu’il doit laisser à l’équipe

Une organisation n’a pas besoin d’automatiser toute la retouche pour obtenir un bénéfice. Commencez par les opérations qui ont un résultat observable et une sortie réversible.

Délégable sous contrôle	À garder dans la revue humaine
Lister les commandes compatibles avec une opération	Choisir si l’image respecte le brief et la marque
Préparer un fichier JSON à partir d’une mission structurée	Autoriser une modification sur le fichier source
Appliquer une action sur des copies	Valider les détails, les droits et les profils colorimétriques
Exporter dans un dossier nommé et journaliser le résultat	Décider qu’une sortie peut être transmise ou publiée
Inspecter la taille, le mode, les calques et l’historique retournés	Interpréter une absence de différence comme une réussite

Le guide ChatGPT Work pour les créatifs : transformer un brief en mission agentique développe cette logique de mission, d’entrées autorisées, d’étapes, de livrables et de conditions d’arrêt. PhotoCraft peut devenir l’outil spécialisé d’une mission ; il ne doit pas devenir une autorisation générale donnée à l’agent.

Une mission agentique exploitable

Pour cadrer une opération, écrivez une fiche courte :

1. Entrée autorisée : nom, format, emplacement et statut du fichier.
2. Action : identifiant de commande, paramètres et ordre des étapes.
3. Sortie : format, dossier, convention de nommage et rapport attendu.
4. Contrôle : propriétés à inspecter, comparaison à effectuer et personne responsable.
5. Arrêt : erreur, timeout, écart visuel ou action non couverte.

Le guide Brand Brain : transformer une stratégie de marque en système utilisable par l’IA apporte un prolongement utile sur la formalisation des invariants, des sources et des règles de marque. Ici, cette mémoire doit rester attachée au fichier et à la mission : une règle générale ne remplace jamais la vérification d’une sortie.

Prompt : préparer une commande

Modèle et mode vérifiés : assistant ou agent textuel qui prépare une commande PhotoCraft ; l’exécution PhotoCraft est séparée et doit être autorisée explicitement. Objectif : transformer une mission bornée en fiche de commande vérifiable, sans exécuter d’action externe.

À partir de la mission ci-dessous, prépare une fiche d’exécution PhotoCraft sans inventer de commande.

Mission : [décrire l’opération]
Entrée autorisée : [chemin relatif, format, copie ou original]
Sortie attendue : [format, dossier, nom]
Critères d’inspection : [dimensions, mode, calques, historique, aperçu]
Conditions d’arrêt : [erreur, timeout, résultat ambigu]

Retourne :
1. les commandes officiellement vérifiées à utiliser ;
2. leur ordre et leurs paramètres JSON ;
3. les contrôles après chaque étape ;
4. ce qui reste documenté mais non exécuté.
N’exécute aucune action externe et signale toute commande non confirmée.

Variables à adapter : mission, chemin relatif, format, dossier de sortie, critères d’inspection et conditions d’arrêt. Pourquoi cette structure : elle sépare la préparation du geste technique, force l’identification de la version et rend les contrôles après exécution explicites. Limites : le modèle ne connaît pas automatiquement le registre de commandes local, les permissions de fichiers ni la compatibilité de chaque opération avec un PSD donné. Ce prompt décrit une méthode de préparation ; il ne prouve pas qu’un assistant connaît votre registre de commandes ni qu’il dispose d’un accès MCP.

---

Les limites à inscrire dans le protocole

PhotoCraft est présenté comme une alpha précoce. La documentation et la roadmap évoluent ; un score de parité, une liste de menus ou un corpus de tests ne suffisent pas à certifier votre production.

1. PSD : un fichier peut être ouvert et réenregistré sans être identique octet par octet à la source. Testez les calques, masques, textes, effets, objets dynamiques, profils colorimétriques et exports dont votre équipe dépend.
2. MCP : la présence d’un serveur ne constitue pas une preuve d’installation ou de fonctionnement dans votre environnement. Vérifiez les racines, le token, les chemins et les outils réellement retournés.
3. Timeout : une requête expirée peut avoir démarré. Inspectez avant de relancer ; ne déduisez pas l’échec de l’absence de réponse.
4. Droits : un fichier local n’est pas automatiquement un fichier libre de droits. Les entrées, références et sorties doivent rester dans le périmètre autorisé par l’équipe.
5. Tests : un PNG plat et un nouveau document ne valident pas un round-trip PSD. Le prochain test utile est un fichier représentatif non confidentiel, avec comparaison avant/après et retour vers l’application de référence.

---

Où PhotoCraft peut trouver sa place dans une agence

Pour l’ICP CreativeAI, le cas le plus crédible n’est pas une migration brutale d’une équipe entière. C’est une agence ou un studio de 10 à 100 personnes, avec quelques utilisateurs pilotes, une production répétitive et des essais d’IA dispersés, qui cherche à rendre une opération plus transmissible et moins dépendante d’une seule personne.

Commencez par un pilote limité : une famille de fichiers non confidentiels, une opération fréquente, une convention de sortie et une revue menée par quelqu’un qui n’a pas écrit la commande. Mesurez le temps de préparation, le nombre de reprises, les écarts visuels, les erreurs de fichier et la facilité de handoff. Si l’équipe ne peut pas expliquer ce qui a été modifié, l’automatisation n’est pas prête à sortir du laboratoire.

La formation IA agentique pour les créatifs : du brief à l’automatisation prolonge directement ce guide : elle travaille la feuille de mission, les permissions minimales, les validations humaines, le mini-skill et la documentation d’un workflow.

---

Méthodologie et limites

Le dépôt et la documentation officielle ont été relus le 10 octobre 2026, notamment le README, la release v0.6.0, le développement CLI, MCP, le protocole de contrôle, la roadmap et la matrice de parité. Deux essais CLI sont conservés dans le registre de preuves : run sur un nouveau document et batch vers un dossier séparé. Le résultat de ces tests est réel mais étroit : il porte sur un document généré et une image PNG plate, pas sur un PSD client.

Les éléments suivants sont documentés, non exécutés dans ce run : configuration du serveur MCP headless, bridge desktop, appel command_run par MCP et procédure de reprise après timeout. La compilation depuis le dépôt n’a pas été utilisée.

---

Sources et références

• Dépôt officiel PhotoCraft — README, architecture, fonctionnalités, PSD, CLI et agents ; consulté le 10 octobre 2026.
• Release officielle PhotoCraft v0.6.0 — version testée ; consultée le 10 octobre 2026.
• Documentation de développement — CLI, batch, format natif et MCP ; consultée le 10 octobre 2026.
• Conventions MCP PhotoCraft — racines de lecture/écriture et mode headless ; consultée le 10 octobre 2026.
• Protocole de contrôle — loopback, authentification, timeout et limites de transport ; consulté le 10 octobre 2026.
• Roadmap officielle et matrice de parité — état du projet et limites d’interprétation ; consultées le 10 octobre 2026.