Aller au contenu

Simulation CLI

Status: CURRENT / CONTRACT

Rôle de cette page

Cette page décrit l'usage opérateur des simulations depuis la CLI.

Le contrat conceptuel de référence reste documenté dans Simulation — Read Service.

Une simulation répond à une question simple :

« Que se passerait-il si cette règle, cette politique ou cette décision était appliquée ? »

Elle sert à mesurer une hypothèse avant toute mutation métier réelle.

Ce qu'une simulation garantit — et ce qu'elle ne garantit pas

Une simulation métier ne doit pas modifier la vérité métier persistée ni activer une nouvelle règle en production.

En revanche, le mot simulation ou l'option dry-run ne suffit pas à prouver une absence totale d'effet technique.

Selon l'implémentation, une commande peut par exemple :

  • créer une structure temporaire ;
  • initialiser un schéma technique ;
  • produire un fichier ou un rapport ;
  • prendre un lock ;
  • écrire un état temporaire explicitement documenté.

Avant d'utiliser une commande comme preuve « read-only », vérifier son aide, son adapter et la façade applicative appelée.

Quand simuler

Utiliser une simulation lorsque :

  • un audit a isolé une famille de différences cohérente ;
  • une hypothèse précise explique ces différences ;
  • on veut mesurer l'impact avant activation ;
  • il faut vérifier que les garde-fous restent intacts ;
  • une correction potentielle doit être comparée à une baseline reproductible.

Ne pas partir directement d'une intuition générale du type « assouplissons la règle ». Il faut pouvoir nommer la population, l'hypothèse et les critères d'acceptation.

Position dans le workflow

Observation / audit
        ↓
Baseline reproductible
        ↓
Hypothèse bornée
        ↓
Simulation
        ↓
Comparaison avant / après
        ↓
Décision
        ↓
Write Service éventuel
        ↓
Vérification post-écriture

La simulation ne constitue donc pas elle-même une autorisation d'écrire.

Entrées attendues

Une simulation exploitable doit identifier au minimum :

  • le run, feed, échantillon ou périmètre concerné ;
  • la version du code utilisée ;
  • la baseline de référence ;
  • l'hypothèse simulée ;
  • les règles ou paramètres modifiés virtuellement ;
  • les critères d'acceptation ;
  • les garde-fous qui doivent rester vrais.

Si la baseline provient d'une projection historiquement mutée par un ancien comportement, reconstruire d'abord la projection pertinente. Comparer contre une donnée contaminée produit une conclusion trompeuse.

Résultats attendus

Une simulation utile doit rendre visibles :

  • la population examinée ;
  • les cas éligibles ;
  • les cas réellement affectés ;
  • les cas inchangés ;
  • les cas ignorés ;
  • les erreurs ;
  • les différences avant/après ;
  • les raisons ou reason codes ;
  • les régressions potentielles ;
  • l'effet sur resolved / unknown / ambiguous / conflict lorsque la résolution d'identité est concernée.

Les compteurs doivent être réconciliables.

Comment lire le résultat

Une amélioration globale n'est pas suffisante.

Il faut notamment vérifier :

  • qu'un gain de resolved ne provient pas de conflits forcés ;
  • que des ambiguous ou conflict légitimes ne sont pas artificiellement convertis en succès ;
  • que les cas unknown restent inconnus lorsque les preuves sont insuffisantes ;
  • qu'aucune verticale non ciblée n'est affectée ;
  • qu'aucun comportement générique n'a été déplacé dans une règle verticale sans justification.

Un KPI meilleur accompagné d'une perte d'information sur l'incertitude métier n'est pas une amélioration valide.

Simulation locale et micro-patch

Une simulation peut justifier l'étude d'un micro-patch si :

  1. la cause est comprise ;
  2. la population affectée est bornée ;
  3. les garde-fous restent satisfaits ;
  4. les régressions ont été cherchées explicitement ;
  5. l'impact est reproductible ;
  6. une stratégie de retour arrière ou de reconstruction existe.

Elle ne justifie pas à elle seule l'activation du patch.

La décision finale doit être consignée dans un Validation Report ou un artefact équivalent.

Vérifier une commande avant usage

Depuis la racine du dépôt :

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

Pour vérifier l'enregistrement des commandes, préférer wp help ou parser :

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

Un grep brut sur l'arbre JSON n'est pas une preuve fiable de disponibilité.

Garde-fous

Une simulation ne doit jamais :

  • remplacer l'audit initial ;
  • modifier silencieusement les données métier ;
  • transformer un conflit explicite en succès pour améliorer un KPI ;
  • masquer les cas inconnus ou ambigus ;
  • servir de justification à une correction globale lorsque le problème est local ;
  • activer une règle Runtime pendant l'observation ;
  • contourner la validation finale.

Diagnostic si le résultat est surprenant

Avant de modifier l'algorithme :

  1. confirmer le périmètre réellement simulé ;
  2. vérifier la fraîcheur de la baseline ;
  3. contrôler la version du code et les paramètres ;
  4. comparer les reason codes ;
  5. vérifier si l'écart vient de la génération des candidats, du Resolver, d'une règle verticale ou de la projection ;
  6. contrôler les effets techniques éventuels de la commande ;
  7. seulement ensuite décider si un changement de code est justifié.

Invariants

  1. La simulation ne devient jamais une source de vérité métier.
  2. Une amélioration ne doit pas écraser l'incertitude légitime.
  3. Les mêmes entrées et la même version doivent produire le même résultat.
  4. Les effets techniques éventuels sont documentés explicitement.
  5. La mutation réelle reste portée par un Write Service ou une action explicite distincte.
  6. Toute décision finale reste vérifiable après application.

Voir aussi