L'état distant de Terraform est constitué d'un fichier JSON stocké dans un compartiment S3, associé à un verrou Consul ou DynamoDB ; forjar enregistre l'état sous la forme d'un fichier YAML haché selon l'algorithme BLAKE3, à côté de votre fichier de configuration, puis le valide dans Git. Conséquence opérationnelle : Terraform a besoin d’un guide d’intervention pour la restauration de l’état au cas où quelqu’un supprimerait le compartiment S3 ; la restauration de forjar se résume à `git checkout`. La commande `terraform plan -out=plan.tfplan` d’OpenTofu génère un fichier binaire que `terraform apply plan.tfplan` utilise par la suite, tandis que le fichier de verrouillage BLAKE3 de forjar EST le plan enregistré. Dans ce module, vous examinerez où réside l’état, vous verrez les plans enregistrés en action et vous lirez la sortie du plan au format JSON pour comprendre les modifications que l’IAC va apporter avant l’application.

Terraform 1.12 introduit `lifecycle.ignore_changes` pour les champs modifiés par l’API, des blocs `moved` pour la refactorisation sans suppression, et des blocs `removed` pour les suppressions légitimes. Forjar implémente ces trois mêmes primitives avec une légère modification syntaxique : il exige que vous déclariez que la ressource de destination existe dans votre configuration avant que le bloc `moved` ne soit résolu, ce qui permet de détecter le bug « déplacement vers un nom que vous avez oublié » dès la phase de planification. OpenTofu 1.8 a ajouté l’évaluation précoce des clés `for_each`, ce qui permet à un bloc `moved` de cibler une clé dynamique sans déclencher l’erreur d’état partiel générée par Terraform 1.5. Dans ce module, vous apprendrez comment les blocs de cycle de vie renomment, ignorent et suppriment des ressources sans les détruire.

La dérive est ce qui sépare le schéma que vous avez dessiné du cluster dont vous disposez. Ce module met en parallèle la commande « plan -refresh-only » de Terraform — lente et coûteuse, car elle interroge toutes les API cloud pour chaque ressource — avec la comparaison locale du hachage BLAKE3 de forjar par rapport au fichier de verrouillage, qui détecte la dérive en quelques millisecondes sans aucun appel réseau. Vous verrez également comment les blocs de vérification d’OpenTofu 1.5 ajoutent des contrôles d’intégrité post-application qui émettent des avertissements (sans bloquer l’opération), tandis que les contrats C1-C10 de forjar sont des tests de propriétés vérifiés à chaque application. Le dernier élément concerne les importations inter-stacks : terraform_remote_state consomme silencieusement tout ce que l’amont a produit, tandis que forjar verrouille le hachage importé et refuse l’application en cas de non-correspondance.

Ce module de synthèse rassemble les tests, le chiffrement d’état et un parc de canaries en production au sein d’une vision globale de niveau production. Vous découvrirez le langage DSL de test .tftest.hcl de Terraform, avec ses blocs d’exécution et ses conditions d’assertion sur les sorties « plan » et « apply », qui sert de couche de tests unitaires pour les configurations d’infrastructure. Vous verrez également comment le mode « plan-test » de forjar résout le DAG et génère le diff YAML sans aucune opération « apply » ni « destroy ». Vous comparerez ensuite le « state_encryption » d’OpenTofu 1.7 (AES-GCM au repos via AWS KMS) au manifeste signé BLAKE3 de forjar, où toute modification entre le plan et l’application invalide la signature et provoque l’abandon de l’opération. La démonstration finale de la flotte « canary » modifie un message d’accueil géré, exécute la commande « apply », observe la restauration du contenu par Forjar et prouve que les 10 affirmations C1 à C10 sont valides sur une flotte active « primary-plus-canary ».