Aller au contenu

Simulations

Vue d'ensemble

Les simulations constituent l'un des mécanismes les plus importants de la Platform CMonChoix.

Elles permettent d'évaluer le comportement d'une évolution avant toute modification réelle du système.

Contrairement aux traitements exécutés par le Pipeline, une simulation ne produit jamais d'effet de bord. Elle reproduit un scénario d'exécution afin de mesurer les conséquences d'un changement, d'une nouvelle règle ou d'une nouvelle stratégie de résolution.

Les simulations jouent un rôle central dans la méthode industrielle de développement de la Platform.


Pourquoi des simulations ?

Modifier directement une logique métier sur plusieurs centaines de milliers de produits représente un risque important.

Même un changement limité peut produire des conséquences inattendues :

  • fusion incorrecte d'identités ;
  • augmentation des conflits ;
  • baisse du taux de correspondance ;
  • création de faux positifs ;
  • régressions sur une verticale déjà validée.

Avant toute évolution, la Platform cherche donc à répondre à une question simple :

Que se passerait-il si cette modification était appliquée ?

Les simulations apportent cette réponse sans modifier les données.


Principe de fonctionnement

Une simulation reproduit un traitement réel en remplaçant les écritures par une analyse des résultats potentiels.

Données existantes
        │
        ▼
Simulation
        │
        ▼
Résultats simulés
        │
        ▼
Comparaison
        │
        ▼
Décision

Aucune donnée n'est écrite.

Aucune projection n'est reconstruite.

Aucune synchronisation n'est relancée.


Lecture seule

Toutes les simulations sont strictement read-only.

Elles peuvent :

  • lire les données existantes ;
  • reconstruire des calculs en mémoire ;
  • comparer plusieurs scénarios ;
  • produire des rapports.

Elles ne doivent jamais :

  • modifier une table ;
  • mettre à jour une projection ;
  • corriger une identité ;
  • lancer un traitement Runtime.

Place dans le cycle industriel

Les simulations interviennent après les audits et avant tout correctif.

Audit
    │
    ▼
Simulation
    │
    ▼
Analyse
    │
    ▼
Validation
    │
    ▼
Micro-correctif éventuel

Cette étape permet de vérifier qu'une hypothèse est réellement pertinente avant d'investir dans une modification du code.


Objectifs

Une simulation peut servir à :

  • tester une nouvelle heuristique ;
  • mesurer l'impact d'une règle de résolution ;
  • évaluer une stratégie de fusion ;
  • comparer plusieurs approches ;
  • préparer un micro-correctif ;
  • estimer les gains attendus.

Le résultat attendu est une décision éclairée, et non une modification automatique.


Simulations utilisées dans CMonChoix

La Platform s'appuie sur plusieurs familles de simulations.

Simulation d'identité

Cette simulation vérifie comment une identité canonique serait construite avec une nouvelle règle.

Elle permet notamment d'observer :

  • les candidats retenus ;
  • les candidats rejetés ;
  • les changements de résolution ;
  • les conflits supprimés ou créés.

Simulation de projection

Cette simulation estime l'impact d'une évolution sur les projections générées.

Elle permet de vérifier que les informations destinées au Frontend restent cohérentes sans reconstruire réellement les projections.


Simulation de patch

Avant d'appliquer un micro-correctif, la Platform exécute une simulation reproduisant le comportement attendu.

Cette approche permet de mesurer précisément :

  • les produits concernés ;
  • les gains attendus ;
  • les éventuelles régressions.

Le patch n'est appliqué que si les résultats sont satisfaisants.


Simulation comparative

Deux stratégies peuvent être exécutées en parallèle sur les mêmes données.

Les résultats sont ensuite comparés afin d'identifier la solution la plus pertinente.

Cette approche est particulièrement utile lors de l'introduction d'une nouvelle heuristique.


Bonnes pratiques

Une simulation doit toujours :

  • répondre à une question clairement identifiée ;
  • être reproductible ;
  • être documentée ;
  • produire des résultats mesurables ;
  • être accompagnée de KPI.

Une simulation sans objectif précis apporte rarement une information exploitable.


Ce que les simulations ne font jamais

Les simulations ne doivent pas devenir une alternative au Pipeline.

Elles ne remplacent pas :

  • les synchronisations ;
  • les projections ;
  • les traitements de production ;
  • les Write Services.

Leur unique objectif est d'aider à la prise de décision.


Exemple

Une nouvelle règle est envisagée pour améliorer la résolution des smartphones reconditionnés.

Avant de modifier le Resolver :

  1. un audit identifie les produits concernés ;
  2. une simulation applique virtuellement la nouvelle règle ;
  3. les KPI sont comparés ;
  4. les éventuelles régressions sont analysées ;
  5. la règle n'est intégrée au code qu'après validation.

Ainsi, les décisions reposent sur des résultats mesurés et non sur des hypothèses.


Évolution

À mesure que la Platform évoluera, les simulations couvriront un nombre croissant de scénarios.

L'objectif est que toute évolution importante puisse être évaluée virtuellement avant d'être intégrée au code.

Cette approche constitue l'un des principaux garde-fous de l'architecture CMonChoix.


Voir aussi