Aller au contenu

difference-family-audit

difference-family-audit est la page opérateur dédiée à l'exploitation du Difference Family Audit dans les workflows de validation Platform.

La théorie, le rôle architectural et la définition du Read Service vivent dans ../read-services/difference-family-audit.md.

Ici, on documente uniquement :

  • quand lancer cet audit ;
  • ce qu'il prend en entrée ;
  • comment lire ses familles de différences ;
  • comment décider de l'étape suivante.

Rôle pratique

Cette étape intervient après une première comparaison réelle.

Workflow usuel :

real-sample-comparison
-> difference-family-audit
-> resolution-status-audit
-> virtual-patch
-> validation-report

Son but n'est pas de corriger.

Son but est de regrouper les écarts observés en familles exploitables pour éviter les micro-corrections cas par cas.

Quand l'utiliser

Utiliser difference-family-audit quand :

  • un real-sample-comparison a produit trop d'écarts pour être relus unitairement ;
  • on veut distinguer bruit marchand, conflit réel, problème de policy locale ou faiblesse de vertical module ;
  • on prépare une simulation ou un micro-patch ;
  • on veut mesurer si plusieurs écarts proviennent en réalité d'une même cause structurelle.

Entrées attendues

En pratique, cette étape s'appuie sur :

  • les résultats d'un real-sample-comparison ;
  • les identités old/new si une comparaison legacy vs Platform existe ;
  • les statuts de résolution ;
  • les attributs verticaux utiles à la classification ;
  • les titres marchands, sources et candidats si disponibles.

Sorties attendues

On attend typiquement :

  • un nombre total de différences ;
  • une répartition par familles de causes ;
  • des exemples représentatifs par famille ;
  • une priorisation des familles les plus rentables à traiter ;
  • une recommandation sur la suite : audit complémentaire, simulation, ou absence d'action.

Comment lire les résultats

Une famille importante ne signifie pas automatiquement qu'il faut patcher.

Interprétation recommandée :

  • famille massive + cause homogène : bon candidat à une règle ciblée ;
  • famille faible mais légitime : souvent pas d'action ;
  • famille mêlant plusieurs causes : audit complémentaire avant toute décision ;
  • famille correspondant à du bruit marchand attendu : à documenter, pas forcément à corriger.

Décision industrielle

Après difference-family-audit, la question n'est pas encore "quel code modifier ?".

La bonne question est :

quelle famille mérite un audit plus fin, une simulation, ou un patch minimal local ?

En général :

  • si l'identité semble correcte mais le statut diffère : aller vers resolution-status-audit ;
  • si une policy paraît trop stricte : préparer un virtual-patch ;
  • si les familles révèlent des cas très dispersés : ne pas patcher tout de suite ;
  • si une famille domine clairement : la traiter comme candidat prioritaire.

Garde-fous

difference-family-audit ne doit jamais servir à :

  • modifier une règle ;
  • justifier un patch sans audit complémentaire ;
  • masquer un vrai conflit sous une famille trop large ;
  • mélanger observation et correction.

Voir aussi