Modes simulation (dry-run) pour les actions d'un agent : montrer le plan avant le changement

Objectif

Permettre à un agent, et à la personne qui le supervise, de voir exactement ce que ferait une action modifiant un état avant qu'elle ne le fasse, en empruntant le même chemin de code que celui qui appliquera ensuite le changement.

Prérequis

Des outils qui séparent la planification de l'application, ou qui peuvent être enveloppés pour le faire. Des outils établis illustrent ces formes : rsync --dry-run effectue un essai sans qu'aucun changement ne soit apporté ; terraform plan sans -out crée ce que la documentation appelle un plan spéculatif, une description de l'effet sans aucune intention de l'appliquer, tandis que -out=FILE enregistre un plan que apply pourra exécuter plus tard ; kubectl apply --dry-run=client se contente d'afficher l'objet qui serait envoyé, et --dry-run=server soumet la requête sans persister la ressource ; la documentation de l'API Kubernetes décrit le mode dry-run comme l'évaluation d'une requête à travers les étapes habituelles (chaîne d'admission, validation, conflits de fusion) jusqu'à la persistance des objets en stockage, avec la garantie qu'aucun autre effet de bord ne se produit.

Étapes

1. Ajouter un paramètre dry_run à chaque outil qui écrit, supprime, envoie ou publie, et en faire la valeur par défaut documentée pour le premier appel d'une session. La description de l'outil indique que le résultat d'une simulation est un plan, pas un effet.
2. Retourner le plan dans la même structure que le résultat réel, avec un marqueur en plus ("applied": false), et des objets concrets : les chemins de fichiers et les sections modifiées (hunks), les identifiants d'enregistrement et les champs qui changeraient, les destinataires, les comptes. « Mettrait à jour certaines lignes » n'est pas un plan.
3. Préférer les simulations côté serveur lorsque le système cible les propose ; un plan côté client ne peut pas voir les permissions, les quotas, les règles de validation ni les changements concurrents.
4. Exiger le plan avant le changement : l'hôte refuse un appel réel dont les arguments n'ont pas d'abord été soumis en simulation au cours de la même session, ou achemine le plan vers un contrôle humain pour les actions dépassant un seuil.
5. Appliquer avec les mêmes arguments, puis comparer (diff) le résultat réel au plan et remonter les différences à l'agent et au journal ; un écart signifie que l'état a bougé entre le plan et l'application, ou que la logique du plan est erronée.
6. Enregistrer le plan et le résultat ensemble, afin qu'une revue puisse voir ce qui avait été prédit et ce qui s'est produit.

Résultat attendu

Chaque action irréversible est précédée d'un énoncé concret et révisable de son effet, et l'écart entre les deux est détecté plutôt que découvert plus tard.

Limites et base de vérification

Une simulation prouve ce que l'outil ferait, pas ce que d'autres systèmes feraient en réaction (webhooks, déclencheurs, tâches en aval). Elle ne protège pas contre un plan correct mais non désiré ; c'est le rôle des contrôles d'approbation et des actions réversibles. L'ordre des étapes est une proposition ; aucune réduction du taux d'échec n'est avancée.

Préconditions sur l'application, plans selon un seuil

Un plan et une application sont deux appels séparés par un intervalle durant lequel l'état peut bouger, si bien qu'une simulation obligatoire avant chaque écriture ne prouve rien sur le moment de l'application et double les appels pour les écritures à faible risque. Là où la cible le permet, exiger une précondition sur l'application elle-même : If-Match avec un ETag, le resourceVersion de Kubernetes, un numéro de version de document, ou un plan Terraform enregistré que apply rejette si l'état a changé. L'écriture échoue alors de manière atomique lorsque le monde a bougé, et la comparaison a posteriori devient un contrôle sur l'outil plutôt que la seule défense. Réserver le plan obligatoire aux actions sans retour possible (envoi, publication, suppression sans copie) et aux actions en masse au-delà d'un seuil de taille ; pour tout le reste, la simulation reste disponible sur demande.