Aller au contenu

Virtual Patch

Status: CURRENT

À quoi sert ce Read Service ?

Le Virtual Patch permet d'évaluer l'effet d'un correctif hypothétique sans modifier l'état persistant de CMonChoix.

Il applique une logique candidate en mémoire sur un périmètre borné, puis compare le résultat virtuel au comportement de référence.

État de référence
      ↓
Hypothèse de correctif
      ↓
Virtual Patch
      ↓
Résultat hypothétique
      ↓
Comparison / KPI / rapport

Le Virtual Patch mesure. Il n'écrit pas.

Pourquoi il existe

Une modification apparemment locale peut toucher de nombreuses offres, identités ou projections.

Avant d'introduire un correctif réel, il faut pouvoir répondre à des questions comme :

  • combien de cas changeraient ?
  • combien seraient améliorés ?
  • combien seraient dégradés ?
  • des conflict seraient-ils masqués ?
  • des cas unknown ou ambiguous seraient-ils forcés à tort vers resolved ?
  • le gain justifie-t-il le risque et la complexité ?

Le Virtual Patch fournit ces mesures sans mutation.

Position dans le cycle industriel

Audit
  ↓
Hypothèse
  ↓
Simulation
  ↓
Virtual Patch
  ↓
Comparison
  ↓
Décision
  ↓
Correctif réel éventuel
  ↓
Nouvel audit

Il ne remplace ni les tests ni la validation après écriture.

Entrées

Une exécution reproductible doit identifier :

  • le run, snapshot ou dataset de référence ;
  • la population ciblée ;
  • la règle actuelle ;
  • la règle candidate ;
  • la version de code ;
  • les paramètres et seuils ;
  • les filtres ;
  • les critères d'amélioration et de régression.

Une hypothèse de patch non versionnée ou non décrite rend la comparaison difficile à reproduire.

Sorties attendues

Le résultat doit distinguer au minimum :

  • éléments évalués ;
  • éléments inchangés ;
  • éléments améliorés selon les critères annoncés ;
  • éléments dégradés ;
  • changements de statut ;
  • nouveaux conflits ;
  • conflits supprimés ;
  • nouveaux unknown ou ambiguous ;
  • nouveaux resolved ;
  • erreurs techniques ;
  • reason codes ;
  • exemples représentatifs.

Les compteurs doivent être réconciliables.

Exemple conceptuel :

eligible
= unchanged
+ improved
+ degraded
+ neutral_change
+ technical_failure

La formule précise dépend du patch, mais aucune population ne doit disparaître silencieusement.

Lecture seule

Le Virtual Patch peut :

  • lire les données existantes ;
  • appliquer en mémoire une logique candidate ;
  • construire un résultat hypothétique ;
  • comparer le résultat à la référence ;
  • produire des KPI et un rapport.

Il ne doit jamais :

  • écrire dans une table ;
  • persister une projection hypothétique ;
  • appeler un Write Service ;
  • modifier une Canonical Identity ;
  • relancer un Pipeline ou un worker ;
  • vider ou remplacer une image ;
  • activer une règle runtime sous couvert de simulation.

Un Virtual Patch qui écrit temporairement puis annule n'est pas conforme au contrat read-only attendu.

Définir « amélioration » avant de mesurer

Le service ne doit pas décider après coup qu'un changement est positif.

Les critères doivent être annoncés avant l'exécution.

Exemples :

  • réduction d'un faux conflict confirmé ;
  • passage de ambiguous à resolved avec preuve suffisante ;
  • correction d'une projection sans dégrader les identités ;
  • baisse d'une famille d'écarts documentée ;
  • conservation des cas légitimement unknown.

Un simple accroissement du taux resolved n'est pas une preuve d'amélioration.

Détecter les régressions

Une régression peut prendre plusieurs formes :

  • faux positif nouvellement résolu ;
  • conflit réel masqué ;
  • variante fusionnée à tort ;
  • perte d'un reason code utile ;
  • déplacement artificiel d'une anomalie vers unknown ;
  • amélioration sur une verticale mais dégradation sur une autre ;
  • changement inattendu de projection.

Le Virtual Patch doit donc mesurer les sous-populations, pas seulement un KPI global.

Relation avec les Vertical Modules

Si l'hypothèse concerne une règle propre à une verticale, la logique candidate doit rester dans le Vertical Module concerné.

Le Virtual Patch ne doit pas servir à déplacer une logique métier spécifique dans le Domain Core uniquement parce qu'elle améliore un échantillon donné.

Relation avec Media Quality

Pour Media Quality, le mode reste audit-first et non destructif.

Un Virtual Patch peut :

  • estimer un remplacement potentiel ;
  • comparer une classification actuelle et candidate ;
  • mesurer les cas matched, mismatched, unknown_actual ou ambiguous.

Il ne doit pas :

  • vider image_norm ;
  • remplacer une image ;
  • transformer une proposition de remplacement en mutation réelle.

Toute mutation éventuelle appartient à un Write Service séparé et explicitement activé.

Comment interpréter le résultat

Avant d'accepter un patch réel, vérifier :

  1. la population simulée est-elle représentative ?
  2. les gains reposent-ils sur les critères annoncés ?
  3. les régressions sont-elles mesurées par famille ?
  4. les cas unknown, ambiguous et conflict restent-ils honnêtes ?
  5. le changement appartient-il à la bonne couche ?
  6. les résultats sont-ils reproductibles ?
  7. les tests unitaires et de non-régression couvrent-ils l'hypothèse ?

Ce qu'il ne faut pas en déduire

Un Virtual Patch positif ne prouve pas qu'un correctif est prêt pour la production.

Il ne vérifie pas à lui seul :

  • l'idempotence d'une future écriture ;
  • le comportement sous charge ;
  • les migrations ;
  • les erreurs d'infrastructure ;
  • les effets sur une population non représentée.

Après implémentation réelle, un nouvel audit et une validation sont nécessaires.

Reproductibilité

À mêmes données, règles et paramètres, le Virtual Patch doit produire le même résultat logique.

Le rapport doit conserver :

  • dataset ou run ;
  • version du patch virtuel ;
  • paramètres ;
  • filtres ;
  • seuils ;
  • version du code ;
  • critères de classement des gains et régressions.

Tests attendus

Les tests doivent couvrir :

  • absence d'écriture ;
  • absence d'appel aux Write Services ;
  • déterminisme ;
  • réconciliation des compteurs ;
  • cas améliorés, dégradés et inchangés ;
  • changements resolved, unknown, ambiguous, conflict ;
  • stabilité des reason codes ;
  • séparation entre logique générique et verticale.

Invariants

  1. Le Virtual Patch est read-only de bout en bout.
  2. L'hypothèse et les critères d'amélioration sont explicites avant mesure.
  3. Les gains et régressions sont tous deux visibles.
  4. Les statuts d'incertitude et conflits ne sont jamais masqués pour améliorer un KPI.
  5. La logique candidate reste dans la bonne couche architecturale.
  6. Un résultat positif ne déclenche jamais automatiquement une écriture.
  7. Toute mutation réelle éventuelle passe ensuite par un Write Service explicite.

Voir aussi