La plateforme Timeless Loop repose sur un principe simple : chaque client obtient son propre environnement. Une application Elastic Beanstalk, une base de données Amazon RDS dédiée, un secret et une clé de chiffrement qui lui appartiennent, le tout hébergé dans notre infrastructure AWS à Paris. Les données de chaque organisation restent dans leur propre périmètre. C'est ce que les DSI des grandes maisons et des organisations premium exigent, et c'est ce qu'on livre.

Le défi opérationnel derrière cette promesse est réel : comment provisionner un environnement complet, cohérent et sécurisé pour chaque nouveau client, sans que ça devienne un projet à part entière à chaque fois ? La réponse, c'est Terraform.

Le problème des environnements créés à la main

Sans Infrastructure as Code, provisionner un environnement AWS consiste à naviguer dans la console, créer les ressources une par une, configurer les permissions, les règles réseau, les paramètres de base de données. C'est faisable une fois. C'est risqué à partir de la deuxième.

La dérive s'installe discrètement. L'environnement du client A a été créé en janvier, celui du client B en avril, avec une version légèrement différente de la configuration réseau parce qu'entre-temps on avait ajusté quelque chose. En cas d'incident, on ne sait plus exactement ce qui est identique et ce qui ne l'est pas. Les audits de sécurité deviennent pénibles. Les mises à jour transverses deviennent risquées.

Terraform résout ce problème à la racine : l'infrastructure est décrite en code, versionnée dans Git, et chaque environnement est une instance de la même définition.

Un module, des instances

L'organisation qu'on a retenue repose sur les modules Terraform. Un module est un bloc de configuration réutilisable qui décrit un ensemble de ressources AWS : environnement Elastic Beanstalk (instances EC2 derrière un Application Load Balancer), instance RDS MySQL, secret dans AWS Secrets Manager, clé de chiffrement, groupes de sécurité, rôles IAM. C'est le plan de l'environnement client.

Pour chaque nouveau client, on instancie ce module avec les paramètres qui lui sont propres : identifiant client, dimensionnement des ressources, haute disponibilité de la base, domaine personnalisé. Un terraform apply plus tard, l'environnement est provisionné, identique dans sa structure à tous les autres, différent dans ses paramètres.

module "client_env" {
  source = "./modules/client-environment"

  client_id         = "acme-corp"
  db_instance_class = "db.t4g.medium"
  db_multi_az       = true
  domain            = "marketplace.acme-corp.com"
}

Ce qui était une journée de travail manuel devient une opération de quelques minutes. Et surtout, le résultat est garanti conforme à la définition du module.

La gestion du state

Terraform maintient un fichier d'état (tfstate) qui représente la correspondance entre la configuration décrite en code et les ressources réellement créées dans AWS. C'est le référentiel que Terraform consulte pour calculer les changements à appliquer lors d'un prochain apply.

Pour plusieurs environnements clients gérés en équipe, ce fichier doit être centralisé et protégé. On utilise un backend S3 avec un fichier d'état distinct par environnement client, et le verrouillage natif de Terraform sur S3 (use_lockfile) pour éviter les modifications concurrentes. Si deux personnes lancent un apply simultanément sur le même environnement, le verrou garantit que l'une d'elles attend que l'autre ait terminé.

terraform {
  backend "s3" {
    bucket       = "exemple-terraform-states"
    key          = "clients/acme-corp/terraform.tfstate"
    region       = "eu-west-3"
    use_lockfile = true
    encrypt      = true
  }
}

L'isolation par fichier d'état est également une garantie de sécurité : une opération sur l'environnement d'un client ne peut jamais affecter accidentellement celui d'un autre.

Les mises à jour transverses

L'un des bénéfices les plus concrets de cette approche se révèle lors des mises à jour d'infrastructure. Quand on améliore la configuration d'un groupe de sécurité, qu'on ajoute une règle WAF, ou qu'on met à jour la version du moteur de base de données, la modification se fait une fois dans le module. Elle se propage ensuite sur tous les environnements clients via un terraform apply sur chacun.

C'est la différence entre maintenir dix environnements et maintenir une définition dont dix instances existent. Le premier modèle ne passe pas à l'échelle. Le second, si.

Le workflow qu'on a adopté passe toujours par un terraform plan avant tout apply en production. Le plan liste précisément les ressources qui vont être créées, modifiées ou détruites, sans rien changer. C'est le filet de sécurité qui permet de valider une modification avant qu'elle s'applique sur un environnement client actif.

Traçabilité et auditabilité

Parce que toute l'infrastructure est décrite en HCL (HashiCorp Configuration Language) et versionnée dans Git, l'historique des modifications est complet et lisible. On sait exactement ce qui a changé, quand, et pourquoi, grâce aux messages de commit. Chaque modification passe aussi par des contrôles automatiques en CI : tflint vérifie la qualité du code Terraform et Trivy détecte les erreurs de configuration de sécurité en amont du déploiement. Pour un audit de sécurité ou une revue de conformité, c'est une base documentaire solide.

Chaque client a une infrastructure dont chaque composant est identifiable, documenté, et dont l'état attendu est formalisé en code. C'est un niveau de rigueur qu'une configuration manuelle ne peut pas offrir.

Ce qu'on a appris en chemin

La discipline autour du state est non négociable. Un fichier tfstate corrompu ou désynchronisé est l'une des situations les plus délicates à gérer : Terraform ne sait plus ce qui existe réellement dans AWS, et toute opération devient risquée. Les sauvegardes automatiques du bucket S3 et le versioning activé sur ce bucket sont des précautions qu'on ne remet jamais en question.

La modularisation demande également un investissement initial sérieux. Construire un module suffisamment générique pour couvrir tous les cas clients, tout en restant lisible et maintenable, prend du temps. C'est du temps bien investi : chaque heure passée à affiner le module est récupérée multipliée par le nombre d'environnements qu'il génère.

Enfin, Terraform ne gère pas tout. Les données applicatives, les secrets, les certificats : certaines ressources ont des cycles de vie différents et se gèrent via d'autres outils (AWS Secrets Manager, ACM). Terraform orchestre l'infrastructure, pas tout ce qui tourne dessus.