Alice et Bob font un refresh, calculent un plan chacun, puis écrivent un nouveau state. Le dernier terraform apply gagne. L’autre a pourtant bien créé ou modifié des objets : ces changements existent dans le cloud et ont disparu de la carte. Au prochain plan, Terraform invente des créations, des destructions, ou un mélange illisible. C’est une corruption de possession, pas un simple conflit Git.
Le lock existe pour une raison unique : une seule opération d’écriture (et le plan qui la prépare) à la fois sur un state donné.
Le premier apply pose un verrou (DynamoDB, lock file S3, ou lock HCP Terraform). Le second reçoit une erreur du type « state locked » avec l’identité du locker et un identifiant. Bob attend, ou il va voir Alice. Il ne fait pas force-unlock parce que son sprint est bloqué.
force-unlock est un geste d’incident : process mort, runner tué, lock orphelin après avoir vérifié qu’aucun apply réel ne tourne. Déverrouiller pendant qu’Alice écrit, c’est recréer le scénario sans lock, en pire, parce que tout le monde croyait être protégé.
Le récit Alice/Bob. La différence entre attendre et forcer. Le fait que le lock protège le fichier d’état, pas magiquement deux configurations différentes : deux roots, deux states, deux locks — ils peuvent s’entrechoquer dans le cloud (même nom de bucket) sans que Terraform le sache. Le lock n’est pas un sémaphore mondial du compte AWS.
« Le plan en CI pose-t-il un lock ? »
Souvent oui, un lock de courte durée le temps du refresh. Un plan qui reste ouvert une heure tout en tenant le lock bloque l’équipe. D’où les backends et les runners qui libèrent vite, et l’habitude de sauver le plan plutôt que de le recalculer en tenant le cadenas.