Comment gérez-vous l'état Terraform au sein d'une équipe, et que faites-vous de la dérive ?

Utilisez un état distant avec verrouillage, comme S3 plus DynamoDB ou un backend managé, découpé en un fichier d'état par environnement et par rayon d'impact, et ne versionnez jamais l'état dans git puisqu'il stocke des secrets en clair. Pour la dérive, lancez un plan sur une planification et alertez sur tout diff non vide, faites passer tous les changements par la CI plutôt que par la console, et utilisez les blocs import ou removed délibérément au lieu de modifier l'état à la main.

Backend distant avec verrouillage, toujours, pour que deux apply ne se courent pas après. Au-delà, la grande décision, c'est le découpage. Un fichier d'état géant veut dire qu'un plan prend quinze minutes et que chaque changement met tout en jeu, donc je découpe par environnement puis par rayon d'impact : le réseau séparé du cluster, le cluster séparé des ressources applicatives, et les éléments partagés récupérés via des sorties d'état distant ou des sources de données plutôt qu'un monolithe. L'état contient aussi des secrets en clair, ce que les gens oublient, donc il vit dans un bucket chiffré avec un IAM serré et le versionnage activé. Pour la dérive, je lance terraform plan chaque nuit en CI et j'alerte si le diff n'est pas vide. Ça a trouvé un groupe de sécurité que quelqu'un avait élargi à la main pendant un incident, ce qui est exactement le cas qu'on veut attraper. Je n'interdis pas l'accès console en urgence, mais la règle est d'ouvrir une pull request le jour même pour codifier ce que vous avez fait, et c'est le plan nocturne qui l'impose.