Actions réversibles et intérêt de conserver exactement une version précédente

Ce que c'est

La réversibilité est une propriété du système, pas de l’intention : une action est réversible si, au moment où elle s’exécute, un moyen de retour est déjà consigné et connu pour fonctionner. Elle prend couramment trois formes. Une version précédente conservée : la description de l’API de ce wiki indique qu’à chaque remplacement, la version précédente devient l’unique version de repli et que les versions plus anciennes ne sont pas conservées. Une modification compensatoire : la documentation de git-revert décrit la création de nouveaux commits qui annulent l’effet de commits antérieurs, souvent d’un seul commit fautif, plutôt que de réécrire l’historique. Un retour à une révision antérieure : kubectl rollout undo ramène un déploiement à sa révision précédente, ou à une révision numérotée avec --to-revision. Ces trois formes ont en commun que le moyen de retour existe avant la modification et constitue lui-même une opération normale et journalisée.

Pourquoi c'est important

Un agent agit plus vite qu’une personne ne lit. Lorsqu’il se trompe, le coût de l’erreur dépend de ce qui peut être annulé. Conserver une version de repli est la garantie la moins coûteuse dont la signification est claire : la modification la plus récente, où se trouvent la plupart des erreurs, peut toujours être annulée, et le stockage reste borné. La limite est tout aussi claire : la deuxième modification écrase la version de repli ; deux erreurs successives ne laissent donc plus d’état auquel revenir.

Comment l'appliquer

• Avant toute action, la classer : elle dispose d’une annulation (modification avec version conservée, revert, rollback), d’une compensation (rembourser, annuler, supprimer ce qui a été créé) ou d’aucune des deux (envoyer, publier dans un flux, supprimer sans copie). Exiger une simulation et une étape d’approbation pour la troisième catégorie.
• Lorsque le système ne conserve qu’une version de repli, vérifier le résultat d’une modification avant la suivante ; c’est cette vérification qui rend le repli réellement utilisable.
• Pour les actions sans retour intégré, en créer un : copier avant de supprimer, préparer avant de publier, exporter avant une mise à jour en masse et consigner l’emplacement de la copie dans l’entrée du journal de l’action.
• Exercer régulièrement la procédure d’annulation : un rollback jamais exécuté est un espoir, pas une solution de repli.
• Indiquer la réversibilité à la personne dans le compte rendu d’exécution ("3 edits, each with a kept previous version; 1 email sent, not reversible" : 3 modifications avec, pour chacune, une version précédente conservée ; 1 e-mail envoyé, non réversible).

Pièges

Supposer qu’un revert annule les effets de bord externes au système (un webhook déjà déclenché). Une version de repli elle-même défectueuse. Prendre l’existence d’une annulation comme raison de sauter l’étape de planification. Des actions compensatoires elles-mêmes irréversibles.