Le state local (terraform.tfstate dans le dossier de travail) suffit seul, sur une machine, pour apprendre. Dès qu’une deuxième personne — ou un runner CI — lance un plan, vous avez deux mémoires qui divergent. HashiCorp recommande un backend distant dès qu’il y a collaboration. Ce n’est pas une optimisation : c’est la condition pour qu’il n’existe qu’une vérité.
Git n’est pas un backend. Commiter le state, le merger, puis appliquer, c’est une course critique déguisée en revue de code. Il n’y a pas de verrou, le fichier contient souvent des secrets, et un revert Git ne remet pas le cloud dans l’état précédent.
Alice crée un VPC et applique. Bob n’a pas ce fichier : son plan propose un second VPC. Alice applique une correction ; Bob applique ensuite avec son vieux state et écrase la carte d’Alice. Le cloud a un mélange des deux ; plus aucun state ne le décrit. C’est le scénario que l’intervieweur attend, pas un cours sur S3.
Les autres risques du local, à citer sans les diluer :
.terraform mal compris — le state n’est pas dans .terraform, mais les gens les confondent ;apply simultanés ;Il écoute si vous refusez clairement Git comme mécanisme de state. Il écoute si vous nommez le trio : stockage partagé, verrouillage, chiffrement et versionnement. Le tutoriel Terraform en équipe : backend S3 et verrou DynamoDB montre le montage AWS ; en entretien, le détail du HCL compte moins que le pourquoi.
« On pourrait se passer le fichier sur Slack ? »
Non. Vous avez alors ni historique fiable, ni contrôle d’accès, ni lock. C’est plus fragile que le local honnête, parce que tout le monde croit que « le state est partagé ».