Virtual Patch — CLI¶

Status: CURRENT / CONTRACT

Rôle de cette page¶

Cette page décrit le mode opératoire CLI d'un Virtual Patch.

La définition conceptuelle de référence reste :

Un Virtual Patch applique virtuellement une hypothèse de correction sur un périmètre borné afin d'en mesurer l'effet avant toute mutation métier persistante.

Ce que Virtual Patch n'est pas¶

Un Virtual Patch n'est pas :

un Write Service ;
une activation Runtime ;
une modification directe des projections persistées ;
une validation finale ;
une preuve suffisante qu'un patch réel est sûr.

Il est possible qu'une implémentation de l'algorithme simulé soit nécessaire pour produire la variante virtuelle. Cela ne transforme pas pour autant la simulation en activation production.

Effets techniques possibles¶

Le résultat métier simulé doit rester non persistant.

Cependant, une commande CLI appelée virtual-patch ou dry-run peut avoir des effets techniques explicitement documentés : fichiers temporaires, tables temporaires, locks, artefacts ou initialisation de composants techniques.

Ne jamais déduire « aucune écriture » uniquement du nom de la commande. Vérifier l'aide, l'adapter et la façade appelée.

Quand utiliser un Virtual Patch¶

Utiliser un Virtual Patch après qu'un audit a établi :

une famille de différences cohérente ;
une cause plausible ;
un périmètre identifiable ;
une baseline reproductible ;
des garde-fous explicites.

Cas fréquents :

règle verticale locale ;
modification d'une heuristique de scoring ;
traitement d'un bruit marchand ;
ajustement d'une politique de conflit ;
test d'une nouvelle génération de candidats.

Workflow opérateur recommandé¶

Real Sample Comparison
        ↓
Difference Family Audit
        ↓
Resolution Status Audit
        ↓
Candidate Dump
        ↓
Virtual Patch
        ↓
Virtual Candidates Dump
        ↓
Remaining Audit
        ↓
Validation Report

Ce workflow est une progression de preuve, pas une chaîne qui doit être exécutée mécaniquement si certaines étapes ne sont pas pertinentes.

Entrées attendues¶

Avant la simulation, conserver :

le run, feed, verticale ou échantillon ;
la révision Git ;
les KPI de baseline ;
la définition exacte de l'hypothèse ;
les cas qui ne doivent surtout pas changer ;
les critères d'acceptation ;
les reason codes ou familles d'écarts attendus.

Si l'état de départ a été altéré par une ancienne mutation, reconstruire les données dérivées nécessaires avant comparaison.

Sorties minimales¶

Un Virtual Patch utile doit rendre visibles :

volume examiné ;
volume éligible ;
volume virtuellement modifié ;
volume inchangé ;
volume ignoré ;
erreurs ;
KPI avant et après ;
reason codes avant et après ;
cas améliorés ;
régressions potentielles ;
effets sur resolved / unknown / ambiguous / conflict lorsque la résolution est concernée.

Les cas réellement sensibles doivent pouvoir être inspectés individuellement.

Comment juger le résultat¶

Un bon Virtual Patch n'est pas celui qui maximise le nombre de changements.

Il doit :

améliorer le problème ciblé ;
conserver les vrais conflits ;
ne pas convertir artificiellement des ambiguïtés en succès ;
ne pas déplacer une règle générique vers une verticale sans raison ;
ne pas créer de régression sur des familles voisines ;
rester explicable et reproductible.

Une hausse de resolved accompagnée d'une baisse artificielle de conflict ou ambiguous est un signal d'alerte, pas un succès automatique.

Passage éventuel vers une mutation réelle¶

Une mutation réelle ne doit être envisagée qu'après :

revue du résultat virtuel ;
recherche explicite de régressions ;
Remaining Audit ;
validation du périmètre ;
stratégie de reprise/rollback ;
Validation Report ;
activation via un Write Service ou une action applicative explicite.

Le Virtual Patch ne doit jamais contenir lui-même le writer de production.

Vérifier la commande¶

Avant usage :

docker compose exec platform-worker wp --allow-root --path=/var/www/html help <commande>

Si l'existence d'une commande doit être automatisée, parser l'arbre JSON de :

docker compose exec platform-worker wp --allow-root --path=/var/www/html cli cmd-dump --format=json

Diagnostic en cas de divergence inattendue¶

Avant de modifier le code :

vérifier que la baseline est fraîche ;
vérifier la révision et les paramètres ;
comparer Candidate Dump et Virtual Candidates Dump ;
isoler si l'écart vient du candidate generation, du Resolver, d'une policy verticale ou de la projection ;
confirmer les effets techniques réels de la commande ;
contrôler les cas unknown / ambiguous / conflict individuellement.

Garde-fous¶

Le Virtual Patch ne doit jamais :

écrire la vérité métier persistée ;
activer implicitement une règle en production ;
remplacer une validation finale ;
court-circuiter l'analyse des écarts résiduels ;
présenter un score ou une confiance comme une preuve absolue ;
masquer les régressions par un KPI agrégé.