Verticale Photo¶

La verticale Photo regroupe les règles métier propres aux appareils photo, objectifs et accessoires photographiques.

Elle spécialise les mécanismes génériques de la Platform sans introduire de dépendance inverse vers le Domain Core.

Sommaire¶

Rôle
Périmètre
Frontières architecturales
Signaux métier
Résolution et conflits
Projection
Qualité et Media Quality
Industrialisation
Invariants
Limites connues
Voir aussi

Rôle¶

La verticale Photo constitue la deuxième validation majeure de l'architecture Platform après Smartphone.

Elle a confirmé qu'un domaine fortement spécialisé pouvait être industrialisé sans déplacer ses règles dans le Domain Core.

Elle est responsable de :

reconnaître les familles de produits photographiques ;
normaliser les attributs propres au domaine ;
construire les signaux nécessaires au Resolver ;
classifier les conflits spécifiques ;
enrichir les projections avec les attributs photographiques ;
exposer des diagnostics déterministes et auditables.

Elle ne remplace ni le Resolver, ni les Write Services, ni le moteur de projection.

Périmètre¶

La verticale peut couvrir notamment :

appareils photo hybrides ;
reflex numériques ;
appareils compacts ;
objectifs ;
kits boîtier et objectif ;
accessoires photographiques lorsque leur identité est suffisamment structurée.

Chaque famille doit être explicitement reconnue. Une offre ambiguë entre plusieurs familles ne doit pas être forcée dans une identité unique.

Frontières architecturales¶

Domain Core
    │
    ▼
Resolver générique
    │
    ├── signaux et règles Photo
    ▼
Canonical Identity
    │
    ▼
Projection Builder / Write Service

La dépendance reste orientée dans un seul sens :

Verticale Photo → Domain Core

Le Domain Core ne connaît pas les notions de monture, focale, ouverture, capteur ou compatibilité optique.

La verticale Photo ne doit pas :

écrire directement dans les tables de projection ;
créer une identité canonique hors du Resolver ;
masquer un conflit de famille produit ;
ajouter une règle Photo dans le Core ;
modifier silencieusement une donnée normalisée.

Signaux métier¶

Les signaux couramment exploités incluent :

marque ;
modèle ou référence constructeur ;
famille produit ;
monture ;
longueur focale fixe ou plage focale ;
ouverture maximale ;
type de capteur ;
type d'objectif ;
stabilisation ;
marqueurs de kit ou de bundle ;
compatibilités explicitement prouvées.

Un signal marchand n'est pas automatiquement une vérité métier.

Chaque signal important doit conserver, lorsque disponible :

sa valeur brute ;
sa valeur normalisée ;
sa provenance ;
son niveau de confiance ;
les raisons ayant conduit à son interprétation.

Résolution et conflits¶

Les règles Photo complètent le Resolver générique. Elles ne produisent pas seules la décision finale.

Les états canoniques attendus restent :

État	Signification
`resolved`	Une identité est suffisamment prouvée
`unknown`	Les signaux disponibles ne permettent pas de conclure
`ambiguous`	Plusieurs identités compatibles restent possibles
`conflict`	Des preuves incompatibles empêchent la résolution

Exemples de conflits bloquants :

objectif et boîtier mélangés dans une même identité ;
montures incompatibles ;
références constructeur contradictoires ;
focale ou modèle correspondant à plusieurs familles non départagées ;
kit présenté comme produit unitaire sans preuve suffisante.

Un titre générique tel que Canon Zoom ne suffit pas à résoudre un objectif précis.

À l'inverse, une signature riche telle que marque, monture, plage focale et ouverture peut constituer un ensemble de preuves cohérent.

Les décisions doivent exposer des codes de raison stables afin de permettre l'audit, la simulation et les tests de non-régression.

Projection¶

Les attributs Photo enrichissent les projections uniquement après résolution.

Une projection peut exposer notamment :

Marque : Canon
Famille : Objectif
Monture : EF-S
Focale : 55-250 mm
Ouverture : f/4-5.6
Stabilisation : IS

Le Projection Builder :

consomme l'identité canonique et les attributs certifiés ;
conserve les états unknown, ambiguous et conflict ;
ne recalcule pas les heuristiques Photo ;
reste déterministe pour une même version de règles et les mêmes entrées.

Les écritures persistantes restent la responsabilité des Write Services.

Qualité et Media Quality¶

La qualité d'une offre Photo ne doit pas être confondue avec sa résolution d'identité.

Une offre peut être :

correctement résolue mais pauvre en contenu ;
riche en contenu mais ambiguë ;
cohérente sur l'identité mais incorrecte sur son image principale.

Media Quality intervient comme moteur indépendant, notamment pour vérifier la cohérence entre :

l'identité projetée ;
les attributs certifiés ;
l'image principale ;
les signaux observables dans l'URL ou les métadonnées média.

Son comportement est audit-first :

observation
    → classification
    → rapport
    → validation explicite
    → correction éventuelle par un Write Service

Une règle Media Quality ne doit pas supprimer, remplacer ou réécrire une image de manière implicite.

Industrialisation¶

Toute évolution importante suit un cycle mesurable :

1. Définition du cas métier
2. Constitution d'un corpus réel
3. Audit en lecture seule
4. Classification des erreurs
5. Implémentation locale dans la verticale
6. Simulation et comparaison
7. Validation par KPI
8. Activation contrôlée
9. Surveillance des régressions

Les KPI doivent distinguer au minimum :

volume évalué ;
taux de résolution ;
taux unknown ;
taux ambiguous ;
taux conflict ;
distribution des codes de raison ;
variations avant et après une évolution ;
couverture des attributs structurants.

Les chiffres historiques ne doivent pas être présentés comme une garantie permanente. Ils doivent être rattachés à un corpus, une date, une version de règles et une commande reproductible.

Invariants¶

La verticale Photo respecte les invariants suivants :

Isolation métier : aucune règle photographique n'est introduite dans le Domain Core.
Déterminisme : mêmes entrées et même version de règles produisent la même décision.
Traçabilité : toute décision significative expose ses preuves et ses raisons.
Conservatisme : une ambiguïté n'est jamais transformée artificiellement en résolution.
Non-destruction : les audits et règles de qualité sont sans mutation implicite.
Séparation lecture/écriture : les Read Services observent ; les Write Services modifient.
Compatibilité contractuelle : les états et structures de résultat restent compatibles avec les Contracts communs.
Testabilité : chaque règle importante dispose de cas positifs, négatifs, ambigus et conflictuels.

Limites connues¶

Les difficultés récurrentes incluent :

titres marchands incomplets ;
références constructeur abrégées ;
objectifs proposés dans plusieurs montures ;
kits et bundles insuffisamment explicités ;
compatibilités seulement suggérées ;
variantes commerciales proches ;
images ou métadonnées média incohérentes avec l'identité annoncée.

Ces limites doivent rester visibles dans les rapports. Elles ne doivent pas être masquées par des valeurs par défaut ou des rapprochements trop agressifs.