Quelqu’un avait besoin d’un fix rapide. Il se connecte à la console AWS, clique un peu partout, crée une instance EC2. Peut-être un bucket S3 au passage. Un security group avec le port 22 ouvert sur le monde parce que “c’est plus simple”.

Six mois plus tard, l’instance tourne toujours. Personne ne sait à quoi elle sert. Personne ne sait qui l’a créée. Elle n’est pas dans Terraform, pas documentée. Elle est juste là, quelque part dans le compte.

C’est de la wild infrastructure.

A quoi ça ressemble

Ce sont des ressources créées via la console au lieu du code. Des quick fixes qui deviennent permanents. Des environnements de test qui ne sont jamais supprimés. Cette Lambda déployée “juste pour tester un truc”.

Aucun state file ne les trace, aucune PR ne les a validées. Elles sont juste apparues comme ça.

Les symptômes:

• Des factures cloud avec des ressources inconnues
• Des security groups dont personne ne se souvient
• Des “touche pas à ça, je crois que c’est important”

Pourquoi les gens en créent

La vitesse. Toujours la vitesse.

“Je l’ajouterai dans le code après.” (Ils ne le feront jamais.) “C’est juste temporaire.” (Ça ne l’est jamais.)

La console est là, à portée de clic. Terraform paraît lent quand on a besoin de quelque chose tout de suite.

Le test marche, devient la solution, et reste là pour toujours.

Le vrai coût

FinOps

Pas de tags d’allocation, donc impossible de savoir quelle équipe ou quel projet est responsable. Ça saigne de l’argent en silence.

J’ai déjà vu 15 000$/mois de ressources oubliées pendant des audits. Des instances RDS qui tournaient depuis des années sans aucune connexion. Des volumes EBS attachés à rien!

On ne peut pas optimiser ce qu’on ne voit pas.

Sécurité

Ce security group créé pour “tester rapidement”? Il est toujours ouvert. Ce rôle IAM avec des permissions admin pour “debugger”? Il est toujours actif.

Pas de revue sécu, pas de conformité aux policies, pas de patches quand des vulnérabilités sortent.

Votre posture de sécurité est aussi solide que votre ressource la plus faible. Et vous ne savez même pas où elle se trouve!

Perte de connaissances

Le créateur finit par partir ou par oublier. Quand ça casse, vous debuggez à l’aveugle sans historique de commits ni documentation.

J’ai vu des équipes passer des jours à comprendre ce que faisait une Lambda créée à la main parce que l’auteur était parti.

Drift

L’IaC dit une chose, la réalité en dit une autre. terraform plan affiche du drift partout parce que les gens font des changements manuels.

Vous finissez par perdre confiance dans votre state. Vous n’osez plus faire d’apply. L’IaC devient de la doc au lieu d’une source de vérité.

Le mensonge du “plus rapide”

Jour 1: Créer la ressource à la main. 5 minutes. On se sent productif.

Semaine 2: Un collègue demande à quoi sert cette ressource. 15 minutes d’explications.

Mois 1: Besoin de la répliquer en staging. 2 heures à recréer de mémoire.

Mois 3: Audit sécu. 4 heures à documenter ce qu’on trouve.

Mois 6: La ressource casse. 8 heures de debug sans contexte.

An 1: Revue des coûts cloud. Personne ne sait si c’est nécessaire. On la garde au cas où.

Ces 5 minutes “gagnées” ont coûté des dizaines d’heures. Et ça continue!

Écrire le Terraform au jour 1 aurait pris 30 minutes. Revue de PR, 15 minutes. Total: 45 minutes. Avec doc, historique, et reproductibilité.

Comment corriger ça

Rendre l’IaC plus simple que la console

Si Terraform paraît lent, corrigez votre workflow. N’abandonnez pas l’IaC.

• Accélérez les revues de PR pour l’infra
• Utilisez des modules pour les patterns courants
• Mettez en place du CI/CD qui apply au merge
• Faites de terraform apply une commande unique

Quand l’IaC est plus rapide que de cliquer, les gens l’utilisent.

Détecter et importer

Utilisez des outils pour trouver la wild infrastructure:

# AWS: trouver les ressources non taguées
aws resourcegroupstaggingapi get-resources --resources-per-page 100 | jq '.ResourceTagMappingList | map(select(.Tags | length == 0))'

# Ou des outils dédiés
steampipe query "select * from aws_ec2_instance where tags is null"

Puis importez ce qui compte dans Terraform:

terraform import aws_instance.mystery i-1234567890abcdef0

Supprimez le reste. La plupart ne sert à rien.

Tout taguer

Imposez le tagging au niveau orga. Chaque ressource doit avoir:

• Owner (équipe ou personne)
• Project
• Environment
• Date de création

Les Service Control Policies AWS peuvent bloquer la création sans tags. Utilisez-les.

Audits réguliers

Mensuel: revoir les coûts cloud par tag. Tout ce qui n’est pas tagué doit être investigué.

Trimestriel: réconciliation complète. Comparer le state IaC avec les ressources réelles.

Tuez les ressources zombies sans pitié. Si personne ne sait à quoi ça sert après deux semaines de questions, supprimez. Si c’était important, quelqu’un s’en rendra compte.

Changement de culture

C’est le plus dur. Il faut que tout le monde comprenne que l’IaC n’est pas de la bureaucratie, c’est une assurance.

Chaque changement manuel est de la dette technique. Chaque clic console est un futur incident. Les 5 minutes économisées aujourd’hui coûtent des heures plus tard.

Faites-en une norme d’équipe: si c’est pas dans le code, ça n’existe pas.

Quand le manuel est acceptable

Presque jamais, mais:

• Debug one-shot supprimé dans la même session
• Exploration initiale d’un service qu’on découvre
• Fix d’urgence break-glass (à coder immédiatement après)

Même là, documentez. Un message Slack “Je crée une instance de test, je supprime dans 1h” c’est mieux que rien.

L’objectif

100% de votre infra dans le code. Pas 90%. Pas 95%. Tout.

Vous devriez pouvoir terraform destroy tout et le recréer avec terraform apply. Votre compte cloud doit être reproductible depuis un repo git.

C’est pas du perfectionnisme. C’est de la survie. La wild infrastructure grandit jusqu’à bouffer votre capacité à comprendre, sécuriser et payer vos propres systèmes.

Domptez-la ou c’est elle qui vous domptera.