"Ne jamais toucher la console AWS en production" sonne comme une regle extreme. Ce n'en est pas une. C'est la discipline operationnelle la plus importante dans une equipe cloud-native, et le cout de sa violation s'accumule silencieusement jusqu'a provoquer un incident majeur.

Cet article explique pourquoi, et comment appliquer le developpement IaC-first dans une vraie equipe.

Le Probleme de la Derive d'Etat

Terraform (et OpenTofu) maintient un fichier d'etat qui represente l'infrastructure existante. Lorsque vous appliquez, Terraform compare le fichier d'etat a la configuration et effectue l'ensemble minimal de changements pour aligner la realite sur la configuration.

Lorsque vous cliquez dans la console AWS et creez ou modifiez des ressources, vous changez la realite sans changer le fichier d'etat.

Maintenant : Le prochain plan montrera une derive : Terraform voudra detruire ou recreer des ressources qui "ne devraient pas exister" (parce qu'elles ne sont pas dans la configuration).

Ou pire : l'etat Terraform indique que la ressource existe avec la config A, mais la console l'a changee en config B. plan n'affiche "aucun changement" meme si la ressource est mal configuree.

Ou : quelqu'un ajoute une ressource dans la console, elle fonctionne, devient une dependance pour d'autres ressources, puis un apply s'execute et la supprime parce qu'elle n'est pas dans l'etat.

La console n'est pas la source de verite. Votre IaC l'est. La console est un mensonge.

Le Workflow d'Importation : La Reponse Correcte a "Ca Existe Deja"

Quand une ressource existe dans AWS mais pas dans votre configuration Terraform (creee par quelqu'un dans la console, creee manuellement via CLI, ou migree depuis un autre outil), l'action correcte est de l'importer :

Importer une ressource existante dans l'etat Terraform

./deploy.sh --infra --import aws_s3_bucket.service nom-du-bucket-existant
./deploy.sh --infra --import aws_dynamodb_table.service_files serviceFiles
./deploy.sh --infra --import aws_lambda_function.service_api myapp-service-api

Apres l'importation, lancez plan :
./deploy.sh --infra

Le plan montre la difference entre ce qui existe dans AWS et ce que votre configuration indique. Corrigez la configuration jusqu'a ce que le plan ne montre aucun changement inattendu. Puis appliquez pour synchroniser le fichier d'etat.

Ne supprimez jamais une ressource depuis la console pour la recreer via Terraform. Cela detruit les donnees et casse les dependances. Importer -> reconcilier -> appliquer.

Le Seul Usage Legitime de la Console

La console est appropriee pour :

L'exploration en lecture seule. Logs CloudWatch, metriques CloudWatch, historique d'invocation Lambda, inspection des elements DynamoDB.
Les operations d'urgence avec importation immediate. Si la production est en panne et que la correction necessite un changement dans la console, faites le changement ; mais documentez-le et importez-le dans Terraform dans la meme session de travail.

C'est tout. Tout ce qui cree, modifie ou supprime des ressources appartient a l'IaC.

Le Script de Deploiement Comme Point d'Entree Unique

Les commandes brutes terraform apply ou tofu apply executees directement sur la machine sont dangereuses car elles contournent le workflow de deploiement standard de votre equipe. Creez un script de deploiement qui enveloppe toutes les operations Terraform :

#!/bin/bash
# deploy.sh - le seul moyen d'interagir avec l'infrastructure
case “$1” in
–infra)
case “$2” in
–apply)   run_apply ;;
–plan)    run_plan ;;
–validate) run_validate ;;
–tflint)  run_tflint ;;
–import)  run_import “$3” “$4” ;;
*)         run_plan ;;  # defaut: plan seulement (sur)
esac
;;
esac

Proprietes cles d'un bon script de deploiement :

Par defaut, plan. Lancer ./deploy.sh --infra sans second argument doit afficher le plan, jamais appliquer. Appliquer necessite une intention explicite (--apply).
Toujours valider avant d'appliquer. Lancer terraform validate et tflint avant chaque apply. Rejeter le deploiement si l'un d'eux echoue.
Toujours afficher le plan avant d'appliquer. Meme pour --apply, afficher la sortie du plan et exiger une confirmation en mode interactif.
Var-file coherent. Toujours inclure le meme var-file (vars/production.tfvars). Ne jamais appliquer sans.

La Revue de Plan Comme Barriere

Avant qu'une PR d'infrastructure ne soit fusionnee, la sortie du plan doit etre visible dans la PR :

## Plan Terraform Terraform effectuera les actions suivantes : module.service_api.aws_lambda_function.service_api sera mis a jour sur place ~ resource “aws_lambda_function” “service_api” { ~ timeout = 30 -> 60 }

Plan : 0 a ajouter, 1 a changer, 0 a detruire.

Cela accomplit deux choses :

Le relecteur peut voir exactement ce qui changera en production avant d'approuver.
La sortie du plan est un enregistrement historique de ce qui etait prevu au moment de la fusion.

Un plan qui montre des destructions inattendues (N a detruire) doit bloquer la PR jusqu'a ce que l'auteur explique pourquoi.

La Regle du No-Exclude

Une erreur courante quand un apply echoue : exclure la ressource defaillante et appliquer quand meme.

# MAUVAIS tofu apply -exclude='aws_bedrockagent_knowledge_base.kb'

Cela cree un apply partiel : certaines ressources ont ete mises a jour, d'autres non. Le fichier d'etat reflete maintenant une configuration partiellement appliquee. La ressource exclue n'est plus synchronisee avec tout ce qui en depend.

La reponse correcte a une ressource defaillante :

Laisser l'apply se terminer. Ne pas l'interrompre.
Comprendre pourquoi la ressource a echoue.
Corriger la configuration ou importer la ressource existante.
Relancer apply jusqu'a zero erreurs.

Si l'erreur est "la ressource existe deja" : importez-la.
Si l'erreur est une non-correspondance de config : corrigez la configuration pour correspondre a la ressource existante.
Si l'erreur est un probleme d'ordre de dependances : corrigez depends_on.

Jamais : exclure, commenter ou sauter des ressources. La configuration IaC doit toujours refeter la realite.

Le Force-Unlock

Terraform utilise une table de verrouillage (DynamoDB) pour empecher les apply concurrents. Si un verrou est bloque (Lambda a expire en plein apply, le processus a ete tue), vous verrez :

Error: Error locking state: Error acquiring the state lock

La solution tentante : terraform force-unlock. C'est dangereux si un autre apply est reellement en cours - le force-unlock d'un apply actif provoque une corruption.

La reponse correcte :

Verifier si un apply est reellement en cours d'execution (verifier CloudWatch pour la Lambda de deploy, verifier avec les collegues).
Si aucun apply n'est en cours et que vous etes certain que le verrou est perime, alors force-unlock.
Documenter que vous avez force un verrou - c'est un signal pour investiguer pourquoi l'apply precedent n'a pas nettoye correctement.

Ne jamais faire force-unlock comme premiere reponse. Toujours verifier qu'il n'y a pas d'apply actif d'abord.

Detection de Derive

Meme avec une discipline IaC stricte, la derive s'accumule. AWS peut auto-modifier des ressources, ou un membre de l'equipe peut faire un changement d'urgence dans la console et oublier de l'importer.

Planifiez une execution reguliere de plan (hebdomadaire ou apres des periodes d'activite significatives) sans apply :

# Dans le CI/CD : plan hebdomadaire planifie
./deploy.sh --infra --plan 2>&1 | tee plan-output.txt
# Alerter si le plan montre des changements inattendus

Si le plan montre des changements qui ne devraient pas exister, investiguez avant que le prochain apply ne les detruise.

Points Cles a Retenir

La console AWS est pour lire, pas pour ecrire. Chaque changement d'infrastructure appartient a l'IaC.
Quand une ressource existe dans AWS mais pas dans Terraform : importez-la, reconciliez la config, puis appliquez.
Ne jamais utiliser -exclude pour contourner une ressource defaillante. Corrigez la cause racine.
Enveloppez toutes les operations Terraform dans un script de deploy. Par defaut, plan ; exiger une intention explicite pour apply.
Mettez la sortie du plan dans chaque PR d'infrastructure. Les destructions inattendues doivent bloquer la PR.
Ne jamais faire force-unlock sans verifier qu'aucun apply actif n'est en cours.
Lancez des verifications de plan planifiees pour detecter la derive tot.

IaC-First : Pourquoi Je Ne Touche Jamais a la Console AWS en Production