simulation¶
simulation est la page opérateur qui décrit comment utiliser les simulations read-only dans les workflows Platform.
Le rôle architectural des simulations est documenté dans ../read-services/simulation.md.
Ici, on documente uniquement :
- quand simuler ;
- quel type de simulation choisir ;
- comment lire les résultats ;
- à quel moment une simulation autorise un micro-patch local.
Rôle pratique¶
Une simulation sert à tester une hypothèse sans écrire en base et sans brancher un changement runtime.
Dans la méthode industrielle CMonChoix, on simule avant de modifier.
Quand utiliser une simulation¶
Utiliser simulation quand :
- un audit a isolé une famille de causes cohérente ;
- on pense qu'une policy locale est trop stricte ;
- on veut mesurer un gain potentiel avant tout patch ;
- on doit prouver qu'un assouplissement n'ouvre pas de régression critique.
Position dans le workflow¶
audit
-> simulation
-> lecture des KPI
-> decision
-> micro-patch eventuel
Types de simulations courants¶
En pratique, les simulations les plus fréquentes sont :
- simulation de résolution d'identité ;
- simulation de patch virtuel ;
- simulation comparative old vs new ;
- simulation locale verticale ciblée sur une famille d'écarts.
Entrées attendues¶
Une simulation part généralement de :
- cas réels déjà audités ;
- candidats ou identités comparées ;
- causes probables identifiées ;
- règle hypothétique clairement formulée ;
- KPI de baseline connus.
Résultats attendus¶
Une simulation utile doit permettre de mesurer :
- combien de cas seraient améliorés ;
- combien resteraient bloqués volontairement ;
- s'il existe des régressions ;
- si le gain est local, propre et compréhensible ;
- si le futur patch doit être appliqué, rejeté ou ré-audité.
Comment décider après simulation¶
Lecture recommandée :
- gain net + aucun garde-fou cassé : candidat à micro-patch local ;
- gain faible + logique complexe : ne pas patcher ;
- gain important mais bruit sur vrais conflits : ré-auditer ;
- résultats ambigus : rester en read-only.
Garde-fous¶
Une simulation ne doit jamais servir à :
- contourner l'absence d'audit ;
- justifier un patch trop large ;
- assouplir cross-brand, true conflict, mount/focal, refurb ou autres garde-fous forts sans preuve ;
- remplacer un validation report final.