--- title: 'PhotoCraft : règles, orchestration et contrôle des résultats' date: '2026-10-21' author: Karbonic category: Technologie language: fr-CH canonical: https://www.karbonic.net/journal-photocraft-harness.html description: 'PhotoCraft : encadrer les agents, orchestrer les tâches et vérifier les résultats avec des harness, des juges calculés et des outils locaux.' og:image: https://www.karbonic.net/assets/photocraft-orchestration-v54.webp --- # PhotoCraft : règles, orchestration et contrôle des résultats PhotoCraft est un chantier de pilotage : les agents sont encadrés par des règles, les tâches sont orchestrées et les résultats soumis à des contrôles. La chaîne d’image sert ici de cas concret. ![Illustration d’un poste de pilotage logiciel vu de dos : tableau de validation, journal d’exécution et historique Git sur deux écrans.](https://www.karbonic.net/assets/photocraft-orchestration-v54.webp) Règles, suivi des validations et historique Git : le pilotage au premier plan. Illustration. ## Le cas d’application : de la photo au nouvel éclairage Nous travaillons sur une chaîne PhotoCraft associant photographies existantes, préparation du maillage, projection UV, scène Blender, éclairage et contrôles d’image. Des traitements sont lancés sur trois machines locales. Le couplage et les méthodes d’évaluation sont en cours de développement : ce billet décrit une itération, pas un résultat industriel acquis. Une photo contient déjà des reflets et des ombres. La projeter sur une géométrie puis ajouter une lumière peut cumuler deux éclairages. Une face partiellement cachée peut aussi recevoir une texture qui réapparaît deux fois lorsque la caméra tourne. Le problème ne se résout donc pas par un meilleur prompt. ## Le harness : un cadre d’exécution vérifiable Le harness est l’environnement qui encadre l’agent : outils autorisés, contexte, consignes, exécution, traces et contrôles. Pour une chaîne d’image, le contrat doit aussi préciser les entrées, les versions de scripts et de modèles, les paramètres, les sorties attendues et les conditions d’arrêt. Un identifiant d’essai relie les fichiers sources, leurs empreintes, les réglages et les résultats. Une copie de script sur une autre machine doit être vérifiée avant de comparer les rendus. Sinon, une différence de version peut être prise pour une amélioration d’algorithme. C’est le cadre de reproductibilité que nous construisons autour du chantier. ## Des juges CPU, et des tests pour juger les juges Par juge CPU, nous entendons ici un contrôle calculé et reproductible, distinct de l’avis d’un modèle de langage. Dans l’itération observée, les mesures portent notamment sur la conservation des pixels à l’angle de référence, les doublons, les zones inconnues et la déformation du texte. Un modèle peut aider à repérer un défaut ou à proposer une correction. La validation doit ensuite revenir aux images, aux mesures et aux cas témoins. Un mauvais maillage volontairement introduit est particulièrement utile : si le juge lui attribue presque le même résultat qu’au maillage corrigé, le juge ne distingue pas suffisamment les deux cas. ## Un progrès mesuré, avec sa contrepartie Sur un même essai à +10°, l’indicateur interne de doublons passe de 5,06 % à 1,72 %. En parallèle, la surface classée inconnue passe de 11,8 % à 13,2 %. Les pixels identiques à 0° restent à 99,71 %. Ces chiffres concernent ce seul essai et ses mesures internes ; ils ne constituent pas un benchmark général. La correction évite de plaquer une texture sur certaines surfaces non visibles. Elle réduit les répétitions, mais laisse davantage de zones sans information. C’est une contrepartie à rendre visible, plutôt qu’à masquer derrière une note globale. Le cas témoin au maillage dégradé obtient pourtant 1,79 % de doublons, très près des 1,72 % du résultat corrigé. Conclusion de cette itération : cet indicateur, pris seul, ne suffit pas pour autoriser la suite. ## UV, normales et relighting : trois problèmes différents Le dépliage UV établit une correspondance entre surface et texture. Il ne révèle pas les parties absentes de la photo. Une carte de normales agit sur la réponse à la lumière ; elle ne crée pas, à elle seule, le volume réel ni une silhouette fiable sous un nouvel angle. Le travail en cours examine aussi la prédiction de profondeur, de normales et de composantes d’apparence avec les pipelines Marigold de Diffusers. Les sorties disponibles dépendent du modèle choisi. Elles restent des estimations : une matière prédite ou un relief suggéré ne devient pas une mesure du produit. La suite consiste à séparer autant que possible l’objet, ses détails sensibles et son environnement lumineux. Les inscriptions et les éléments fonctionnels doivent être contrôlés à part. Un arrière-plan généré peut servir à la mise en scène ; il ne doit pas être confondu avec une reconstruction documentée de l’objet. ## Trois machines : distribuer les travaux, garder la même expérience Python et Blender fournissent les briques d’exécution ; des modèles locaux peuvent participer à l’analyse et au pilotage. L’enjeu du parallélisme est d’attribuer les travaux sans saturer les postes et de récupérer des résultats comparables. La chaîne doit prévoir une file de travaux, des budgets CPU, RAM et VRAM par machine, des délais et des reprises contrôlées. La mémoire de trois postes ne s’additionne pas automatiquement en une mémoire unique. Une priorité basse ne limite pas, à elle seule, la consommation CPU. Un rendu brut, un rendu éclairé et un résultat final doivent pouvoir être comparés séparément. La géométrie, la matière et l’éclairage ne doivent pas changer simultanément si l’on veut identifier la cause d’un défaut. ## ECC, Hermes, MCP et llama.cpp : des rôles distincts ECC fournit des ressources pour structurer le travail des agents, notamment des skills, des hooks et des règles. Hermes Agent peut se connecter à des serveurs d’outils via MCP. MCP décrit l’échange avec ces outils ; il ne remplace ni l’ordonnanceur des rendus ni les critères de validation. llama.cpp permet d’exécuter des modèles localement, avec des possibilités CPU et GPU selon la configuration. Dans l’architecture visée, le modèle propose des actions, les outils exécutent et les contrôles décident si une étape peut continuer. Ces briques sont des repères d’intégration ; leur présence dans cette liste ne signifie pas que chacune est déjà raccordée à PhotoCraft. ## Tout en local : un périmètre à vérifier L’objectif est de conserver les images et les traitements sur les machines locales. Cela suppose de vérifier les points de sortie : fournisseurs de modèles configurés, téléchargements initiaux, télémétrie, outils distants et éventuels fournisseurs de secours. Un serveur MCP ou un modèle installé sur un poste ne garantit pas, à lui seul, l’absence de trafic externe. Se tenir informé fait partie du travail. Mais adopter une nouvelle brique n’a d’intérêt que si elle améliore une expérience reproductible : mêmes sources, versions identifiées, comparaisons explicites et limites visibles. L’enjeu de PhotoCraft est là : produire des images dont les transformations peuvent être expliquées et contrôlées. ## Références techniques - [ECC](https://github.com/affaan-m/ECC) - [Hermes Agent · MCP](https://hermes-agent.nousresearch.com/docs/user-guide/features/mcp) - [llama.cpp · server](https://github.com/ggml-org/llama.cpp/blob/master/tools/server/README.md) - [Blender · Python API](https://docs.blender.org/api/current/) - [Diffusers · Marigold](https://huggingface.co/docs/diffusers/main/en/using-diffusers/marigold_usage)