Aller au contenu

Reclassification

Status: TARGET

À quoi sert un Reclassification Write Service ?

Un Reclassification Write Service modifie explicitement la classe, la famille, la catégorie ou un autre statut métier persistant lorsqu'une nouvelle classification a été démontrée et validée.

Il applique une décision de classification ; il ne doit pas contenir lui-même une heuristique opaque qui décide silencieusement à quelle classe appartient un produit.

Audit / évidence
      ↓
Décision de classification
      ↓
Validation du périmètre
      ↓
Reclassification Write Service
      ↓
Persistance + audit après écriture

État documentaire

Cette page décrit la cible d'architecture de la famille Reclassification.

Elle ne prouve pas qu'une commande générique de reclassification est disponible dans le Runtime actuel. Avant toute opération, vérifier l'implémentation réelle, ses paramètres et les données qu'elle modifie.

Entrées attendues

Le service doit recevoir explicitement :

  • les éléments concernés ;
  • la classification actuelle ;
  • la classification cible ;
  • la raison ou le code de décision ;
  • la source de la décision ;
  • les exclusions ;
  • le contexte de run ou batch ;
  • les préconditions métier.

Une reclassification basée uniquement sur un libellé libre ou une correspondance approximative doit être simulée et auditée avant écriture.

Sorties attendues

Le résultat doit permettre de distinguer :

  • éléments examinés ;
  • éléments reclassifiés ;
  • éléments déjà conformes ;
  • éléments ignorés ;
  • conflits ;
  • erreurs techniques ;
  • raisons de chaque catégorie.

Les changements de classification doivent être traçables jusqu'à la règle ou la décision ayant autorisé l'opération.

Ce que le service ne doit jamais faire

Il ne doit jamais :

  • inventer une catégorie pour un cas unknown ;
  • forcer un cas ambiguous dans la classe la plus fréquente ;
  • masquer un conflict ;
  • déplacer une règle propre à une verticale dans le Domain Core générique ;
  • modifier une classification différente de celle demandée ;
  • utiliser la navigation Frontend comme autorité métier ;
  • écrire en dehors d'un Write Service explicite.

Domain Core et Vertical Modules

La décision de classification peut dépendre de règles génériques ou d'un Vertical Module.

Le Write Service reste neutre : il reçoit une décision déjà validée et l'applique. Si une règle ne concerne qu'une verticale, elle doit rester dans cette verticale au lieu d'être copiée dans un service générique.

Sécurité opérationnelle

Avant écriture :

  1. mesurer les classes actuelles ;
  2. produire la population cible ;
  3. simuler le changement ;
  4. inspecter les cas unknown, ambiguous et conflict ;
  5. vérifier les effets sur les projections et la navigation ;
  6. préparer le rollback ou la reconstruction nécessaire.

Après écriture, relancer l'audit de classification et vérifier les projections dépendantes séparément.

Erreurs fréquentes

  • confondre catégorie marchande et catégorie canonique ;
  • reclassifier sur un nom de produit non normalisé ;
  • transformer une absence de preuve en classe par défaut ;
  • corriger la projection sans corriger la donnée source appropriée ;
  • appliquer une règle verticale à toutes les familles ;
  • considérer une baisse des cas non classés comme une amélioration si les faux positifs augmentent.

Tests attendus

Tester au minimum :

  • changement nominal ;
  • élément déjà conforme ;
  • cas inconnu ;
  • cas ambigu ;
  • conflit ;
  • idempotence ;
  • respect du périmètre ;
  • réconciliation des compteurs ;
  • isolation des règles de Vertical Module.

Invariants

  1. La décision de classification précède l'écriture.
  2. unknown, ambiguous et conflict restent des états légitimes.
  3. Une règle verticale reste dans son Vertical Module.
  4. Toute reclassification est explicable et traçable.
  5. Les effets sur les projections sont vérifiés après la mutation.

Voir aussi