Virtual Patch¶

Vue d'ensemble¶

Le Virtual Patch est un Read Service permettant d'évaluer l'impact d'un correctif avant toute modification du code ou des données.

Il reproduit virtuellement le comportement d'une évolution afin de mesurer ses conséquences sur un ensemble de produits réels.

Contrairement à un correctif classique, un Virtual Patch ne modifie jamais la Platform.

Il constitue un environnement d'expérimentation permettant de valider une hypothèse avant d'engager une évolution du Domain Core, d'un Vertical Module ou du Pipeline.

Cette approche est au cœur de la méthode industrielle de CMonChoix.

Pourquoi un Virtual Patch ?¶

Dans une plateforme manipulant plusieurs centaines de milliers de produits, une modification, même minime, peut produire des effets inattendus.

Avant d'introduire une nouvelle règle, plusieurs questions doivent être résolues.

Quels produits seront concernés ?
Combien de conflits seront supprimés ?
De nouveaux faux positifs apparaîtront-ils ?
Des régressions sont-elles possibles ?
Le gain obtenu justifie-t-il la complexité du correctif ?

Le Virtual Patch répond à ces questions sans modifier le système.

Philosophie¶

Le principe est simple :

Mesurer avant de modifier.

Le Virtual Patch ne cherche pas à démontrer qu'un correctif fonctionne.

Il cherche à démontrer qu'il améliore réellement la Platform.

Cette nuance est essentielle.

Un correctif techniquement valide peut avoir un impact négatif sur d'autres familles de produits.

Le Virtual Patch permet de détecter ce type de situation avant qu'elle n'atteigne la production.

Position dans le cycle industriel¶

Le Virtual Patch intervient après les audits et les simulations.

Audit
    │
    ▼
Simulation
    │
    ▼
Virtual Patch
    │
    ▼
Mesure des KPI
    │
    ▼
Décision
    │
    ▼
Correctif réel éventuel

Aucun code n'est encore modifié à ce stade.

Principe de fonctionnement¶

Le service applique virtuellement une nouvelle règle sur les données existantes.

Les résultats obtenus sont ensuite comparés au comportement actuel de la Platform.

Cette comparaison permet notamment d'identifier :

les produits améliorés ;
les produits inchangés ;
les produits dégradés ;
les effets secondaires inattendus.

Toutes les observations sont réalisées en mémoire.

Aucune donnée persistante n'est modifiée.

Ce qui est évalué¶

Selon le contexte, un Virtual Patch peut mesurer :

l'évolution du taux de correspondance ;
la réduction des conflits ;
la disparition de faux négatifs ;
l'apparition de faux positifs ;
l'impact sur les projections ;
l'évolution des indicateurs de qualité ;
les effets sur une verticale particulière.

Les indicateurs retenus dépendent de l'objectif du correctif.

Lecture seule¶

Le Virtual Patch est strictement read-only.

Il peut :

lire les données ;
exécuter une logique virtuelle ;
comparer deux comportements ;
produire un rapport.

Il ne doit jamais :

modifier une règle métier ;
écrire dans une table ;
reconstruire des projections ;
lancer une synchronisation.

Cette garantie permet d'utiliser le Virtual Patch librement pendant les phases d'analyse.

Résultats¶

Un Virtual Patch doit produire un résultat exploitable.

En particulier, il doit permettre de répondre clairement aux questions suivantes :

Le correctif apporte-t-il une amélioration mesurable ?
Les bénéfices sont-ils supérieurs aux risques ?
Des régressions apparaissent-elles ?
Le correctif peut-il être généralisé ?
Une règle spécifique à une verticale serait-elle préférable ?

Le service ne prend jamais la décision finale.

Il fournit les éléments nécessaires à cette décision.

Exemple¶

Une nouvelle heuristique est proposée afin d'améliorer la résolution des smartphones reconditionnés.

Avant de modifier le Resolver :

un Virtual Patch applique virtuellement cette heuristique ;
les identités générées sont comparées aux identités actuelles ;
les KPI sont recalculés ;
les différences sont analysées.

Le rapport montre que :

96 % des produits restent inchangés ;
3,8 % sont améliorés ;
0,2 % présentent une régression.

Ces résultats permettent d'évaluer objectivement la pertinence du correctif.

Bonnes pratiques¶

Un Virtual Patch doit toujours :

être associé à une hypothèse clairement formulée ;
utiliser des données représentatives ;
produire des résultats reproductibles ;
être accompagné des principaux KPI ;
être documenté dans le rapport de validation.

Le Virtual Patch ne remplace jamais les tests.

Il complète la démarche d'analyse.

Limites¶

Le Virtual Patch ne garantit pas qu'un correctif sera parfait.

Il permet uniquement de mesurer son impact sur les données analysées.

Certaines situations particulières peuvent rester invisibles si elles ne sont pas représentées dans les jeux de données utilisés.

C'est pourquoi les résultats doivent toujours être interprétés en complément des audits et des simulations.

Évolution¶

À mesure que la Platform évoluera, le Virtual Patch deviendra un outil de plus en plus central.

L'objectif est que toute évolution significative puisse être évaluée virtuellement avant toute modification du code.

Cette approche réduit fortement les risques de régression et contribue à préserver la stabilité du Domain Core.

Elle constitue l'un des principaux garde-fous de la méthode industrielle de CMonChoix.