Infrastructure générée par IA : un cauchemar de maintenance

J’ai demandé à ChatGPT de générer du Terraform pour un setup AWS standard : VPC, sous-réseaux, cluster ECS avec Fargate, RDS et un ALB.

Il a produit 2 400 lignes de Terraform en environ 30 secondes. J’ai lancé terraform plan. Pas une seule erreur. Chaque ressource configurée correctement, groupes de sécurité branchés, rôles IAM délimités.

C’était aussi un parfait cauchemar de maintenance.

Voilà le sale secret dont personne dans le camp “l’IA va remplacer les développeurs” ne parle : le code d’infrastructure généré par IA marche techniquement mais est structurellement épouvantable. C’est l’équivalent de réparer un pont au gros scotch. Ça tient les voitures, mais vous ne voudriez pas être en dessous.

Le vrai Terraform

Voici un vrai extrait de ce que la machine a produit :

# Définition de tâche ECS
resource "aws_ecs_task_definition" "app" {
  family                   = "app-task"
  network_mode             = "awsvpc"
  requires_compatibilities = ["FARGATE"]
  cpu                      = "256"
  memory                   = "512"
  ...
}

resource "aws_appautoscaling_target" "app" {
  max_capacity       = 10
  min_capacity       = 2
  resource_id        = "service/${aws_ecs_cluster.app.name}/${aws_ecs_service.app.name}"
  scalable_dimension = "ecs:service:DesiredCount"
  service_namespace  = "ecs"
}

resource "aws_appautoscaling_policy" "cpu" {
  name               = "cpu-scaling"
  resource_id        = aws_appautoscaling_target.app.resource_id
  scalable_dimension = aws_appautoscaling_target.app.scalable_dimension
  service_namespace  = aws_appautoscaling_target.app.service_namespace
  # ...
}

resource "aws_appautoscaling_policy" "memory" {
  name               = "memory-scaling"
  resource_id        = aws_appautoscaling_target.app.resource_id
  scalable_dimension = aws_appautoscaling_target.app.scalable_dimension
  service_namespace  = aws_appautoscaling_target.app.service_namespace
  # ...
}

Regardez ça. Ces quatre lignes sont copiées-collées à travers trois ressources :

resource_id        = aws_appautoscaling_target.app.resource_id
scalable_dimension = aws_appautoscaling_target.app.scalable_dimension
service_namespace  = aws_appautoscaling_target.app.service_namespace

Multipliez ce schéma sur 2 400 lignes et vous obtenez des centaines de lignes de duplication qui devraient être UN seul bloc locals {}.

Les cinq problèmes

1. Pas de locals, pas d’abstractions

Un ingénieur humain, même junior, écrirait :

locals {
  service_id        = "service/${aws_ecs_cluster.app.name}/${aws_ecs_service.app.name}"
  scaling_dimension = "ecs:service:DesiredCount"
  service_namespace = "ecs"
}

L’IA ne le fait pas. Chaque ressource est écrite de zéro, comme si c’était la première fois que quelqu’un branchait ces éléments ensemble. Parce que pour l’IA, c’est la première fois, à chaque fois.

2. Plus de 30 valeurs en dur

Région : eu-west-3. CPU : 256. Mémoire : 512. Nombre désiré : 2. Port de l’ALB : 443.

Chacune de ces valeurs est codée en dur, en ligne. Déployer dans une autre région ? Modifiez-la à 8 endroits. Changer la taille d’instance ? Modifiez-la à 12 endroits. Oubliez-en une, et vous obtenez une erreur d’exécution qu’il faut 45 minutes pour retrouver.

3. Aucune frontière de module

Toute l’infrastructure (réseau, calcul, base de données, monitoring, DNS) vit dans un seul répertoire plat. Pas de modules. Pas de séparation des responsabilités. Un fichier pour les gouverner tous.

Pour donner un contexte, la même infrastructure dans un vrai projet d’équipe serait :

modules/
  networking/      # VPC, sous-réseaux, NAT, IGW
  compute/         # ECS, ALB, auto-scaling
  database/        # RDS, groupes de sous-réseaux, sécurité
  monitoring/      # CloudWatch, alarmes, dashboards
  dns/             # Route 53, certificats ACM

4. Tout s’appelle “app”

resource "aws_ecs_task_definition" "app" { ... }
resource "aws_appautoscaling_target" "app" { ... }
resource "aws_appautoscaling_policy" "cpu" { ... }
resource "aws_appautoscaling_policy" "memory" { ... }
resource "aws_security_group" "app" { ... }

Dans un vrai projet avec 5 microservices, vous auriez 5 ressources toutes nommées app. Bonne chance pour déboguer ça dans les logs CloudTrail à 2 h du matin.

5. Aucun avis sur les choses difficiles

Voici ce que l’IA n’a pas demandé :

• Cette instance RDS doit-elle être en Multi-AZ ? (Coûte 2×. Est-ce que ça vaut le coup pour ce cas d’usage ?)
• Quelle est la politique de rétention des sauvegardes ? (Le défaut est de 7 jours. Est-ce assez ?)
• Faut-il utiliser Aurora Serverless ? (Ça dépend du profil de charge.)
• Et le chiffrement au repos ? (Probablement oui, mais il faut réfléchir à la gestion des clés.)

L’IA génère les défauts faciles pour les questions difficiles. Et elle ne signale même pas que ces questions existent.

Les chiffres

J’ai passé deux jours à refactoriser la sortie de l’IA en quelque chose que je mettrais vraiment en production :

Métrique	Sortie de l’IA	Après refactorisation
Lignes de code	2 400	800
Motifs répétés	12	0 (locals)
Valeurs en dur	30+	0 (toutes en variables)
Frontières de modules	0	5 modules logiques
Convention de nommage	Aucune	{env}_{service}_{resource}

La refactorisation a pris 2 jours. La génération par l’IA a pris 30 secondes.

Comment j’utilise vraiment l’IA pour l’infrastructure maintenant

J’utilise toujours l’IA pour l’infra. Mais je la traite comme un développeur junior qui travaille vite et ne pose pas de questions :

1. Générer des squelettes de modules, pas des implémentations complètes

Mauvais : “Génère du Terraform pour ECS avec auto-scaling” Bon : “Génère un module ECS réutilisable qui prend service_name, cpu, memory et port en entrée. Sors exactement : définition de tâche, service, auto-scaling et groupe cible d’ALB. Utilise des locals pour les motifs répétés. Tout le nommage via des variables.”

2. Fournir vos conventions d’emblée

"Utilise ces conventions de projet :
 - nommage {env}_{service}_{resource}
 - toute la config depuis des variables (region, cpu, memory, port)
 - extraire les motifs répétés vers des locals
 - regrouper en modules : networking, compute, database, monitoring
 - inclure des fichiers .tfvars pour dev/staging/prod"

3. Lancer tflint et checkov sur tout

tflint --recursive   # repère les variables inutilisées, la syntaxe obsolète
checkov -d . --framework terraform   # analyse de sécurité

Le code généré par IA passe terraform plan mais échoue à chaque règle de linting. Ces outils attrapent ce que l’IA rate.

4. Générer vous-même un module parfait, puis demander à l’IA de le répliquer

Écrivez votre module ECS comme vous le voulez. Puis : “Génère un module RDS qui suit exactement la même structure, les mêmes conventions et le même schéma d’entrée que le module ECS que je t’ai fourni.”

Un bon exemple vaut plus que mille prompts.

Où se trouve vraiment la limite

Que le Terraform généré par IA soit un gain de temps ou un fardeau dépend de votre situation :

• Prototype ou environnement jetable ? Livrez la sortie de l’IA telle quelle, la refactoriser serait du temps perdu.
• Un environnement durable avec plus d’un ingénieur qui y touche ? Les cinq problèmes ci-dessus s’aggravent vite. Budgétez la passe de refactorisation avant la fusion de la première PR, pas après le troisième incident.
• Vous avez déjà une bibliothèque de modules ? Sautez complètement la génération de ressources brutes : demandez plutôt à l’IA de se conformer à vos modules. Prompt différent, sortie bien meilleure.

L’exemple de 2 400 lignes de cet article a pris environ une journée à refactoriser en quelque chose qu’une équipe pourrait maintenir. C’est le vrai coût, pas les 30 secondes qu’a pris la génération.