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 :
- un audit identifie les produits concernés ;
- une simulation applique virtuellement la nouvelle règle ;
- les KPI sont comparés ;
- les éventuelles régressions sont analysées ;
- 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.