Terraform @Scale - Partie 2 : L’art du dimensionnement optimal des States

L’Infrastructure-as-Code n’est plus optionnelle. Les entreprises qui souhaitent exploiter et faire évoluer leur infrastructure cloud de manière sérieuse misent sur Terraform. Mais avec le succès croissant et la complexité qui augmente, une question essentielle se pose : quelle doit être la taille d’un Terraform State ?

Un State trop volumineux bloque les équipes, ralentit les processus et engendre des risques inutiles. Un State trop petit, en revanche, entraîne une surcharge inutile et une cohérence fragile. Il s’agit donc de trouver la juste mesure - ni trop, ni trop peu, mais exactement ce qu’il faut. Bienvenue dans le principe de Boucles d’or appliqué à Terraform.

 

Le principe de Boucles d’or dans le monde de l’IaC

Le fameux principe de Boucles d’or vient à l’origine d’un conte anglais. Le personnage principal, Boucles d’or, teste différentes options - trop chaud, trop froid, puis juste comme il faut - et opte finalement pour la solution intermédiaire. Cette image se transpose parfaitement à l’univers de Terraform.

Ici aussi, nous cherchons l’équilibre idéal. L’objectif est une configuration ni trop granulaire, ni trop monolithique. Trois objectifs centraux sont à privilégier :

1. Efficacité maximale dans le déploiement et la gestion de l’infrastructure
2. Éviter les redondances inutiles, telles qu’on les retrouve souvent dans des States trop vastes
3. Éviter les états incomplets, causés par une fragmentation excessive

Concrètement, cela signifie que nous avons besoin d’une structure qui accorde à la fois l’autonomie nécessaire aux équipes et une vue cohérente sur l’ensemble du système.

 

Le défi du bon dimensionnement des States

La question de la "bonne" taille d’un Terraform State se pose tôt ou tard dans tout environnement de grande envergure. Il n’existe pas de recette universelle - ce qui fonctionne dépend fortement du cas d’usage concret, qui est toujours spécifique aux besoins du client.

Cependant, après plusieurs projets menés pour divers clients, des défis typiques apparaissent clairement.

Que se passe-t-il lorsque les States deviennent trop gros ?

Les grands Terraform States peuvent sembler attrayants à première vue : tout est centralisé, facile à versionner, clair... le rêve de nombreux managers et décideurs - un centre de données sur simple pression d’un bouton - semble réalisable grâce à Terraform. Je parle ici d’expérience, car lorsque j’ai moi-même commencé à utiliser Terraform il y a près d’une décennie, je suis tombé dans ce piège. Oui, cela semble impressionnant, et on a l’impression que de nombreux problèmes sont résolus. Mais cette impression est trompeuse. Car la réalité s’avère vite bien différente.

Très vite apparaissent :

• Problèmes de performance : terraform plan ou apply prennent une éternité, car les gros States consomment énormément de temps de calcul et de bande passante réseau. Le pire que j’aie rencontré jusqu’à présent : un terraform apply qui tentait d’installer, en plus des réseaux et des VMs, un cluster complet de bases de données Oracle, et qui nécessitait au mieux 75 minutes. C’était l’incarnation même d’une erreur de débutant. 
• Verrous bloquants : Lorsque plusieurs équipes ou collaborateurs travaillent sur le même State, cela entraîne des conflits et des temps d’attente. Résultat : frustration, plaintes bruyantes et perte de productivité.
• Gestion des risques complexe : Une erreur dans un module peut affecter de vastes parties de l’infrastructure. C’est particulièrement critique dans les environnements de production. Plus un module Terraform tente d’implémenter de ressources, plus le rayon d’impact sera important en cas d’échec. Même avec Terraform, une règle bien connue de l’exploitation s’applique : plus un système est complexe, plus il explose rapidement et bruyamment.
• Cycles de développement ralentis : Les changements prennent plus de temps, le time-to-market augmente, et le Continuous Delivery devient un défi. Les boucles de feedback doivent être aussi courtes que possible. Attendre 60 minutes pour tenter un déploiement d’infrastructure, ce n’est pas court.

Et si les States sont trop petits ?

L’autre extrême est tout aussi problématique. Fragmenter l’infrastructure en trop de petits States mène vite à une autre boîte remplie d’éclats :

• Charge administrative : Des dizaines voire des centaines de States doivent être maintenus, versionnés et coordonnés. Cela consomme du temps et génère de la complexité. Dans le pire des cas, la complexité devient de la complication, et plus personne ne s’y retrouve. Le dernier objectif de l’Infrastructure-as-Code est bien de ne pas recréer un ancien problème issu du monde IT traditionnel : un système si ancien et historiquement chargé que plus personne ne veut y toucher, et qui devient peu à peu une bombe à retardement critique. 
• Problèmes de cohérence : Les dépendances entre States - par exemple VPCs, Subnets ou Security Groups - deviennent difficiles à suivre. Les sources d’erreurs se multiplient. Une modification dans une partie de l’infrastructure peut entraîner un dysfonctionnement totalement inattendu ailleurs. Ce n’est pas souhaitable, surtout si l’on souhaite éviter les gardes de nuit passées à recoller les morceaux de States corrompus.
• Duplication de code : La logique réutilisable n’est plus maintenue de manière centralisée, mais recodée dans de nombreux modules. Cela va à l’encontre du principe DRY et pousse l’infrastructure vers un état de plus en plus obscur, même s’il est encore défini. On voulait justement éviter de devoir faire du reverse-engineering d’infrastructure. Mais quand chacun réinvente la roue, on finit par y être contraint.
• Gestion fragmentée des ressources : Sans vue centrale de l’infrastructure, la compréhension globale est entravée. Qui a modifié quoi, où, et quand ? Souvent, la seule réponse est un haussement d’épaules.

 

Exemples d’architectures pour des Terraform States optimisés

La théorie de la « juste mesure » ne vaut que si elle est appliquée correctement dans la pratique. Il est donc utile d’examiner des modèles d’architecture éprouvés qui se sont imposés dans les environnements Terraform évolutifs. Deux approches se sont particulièrement distinguées : l’approche en couches pour les stratégies multi-comptes et une structure fondée sur les domaines pour les environnements de microservices.

Exemple 1 : stratégie multi-comptes dans le cloud avec approche en couches

Un modèle largement éprouvé consiste à diviser les States en couches fonctionnelles. Ce principe s’aligne sur le cycle de vie et la fréquence de changement des éléments d’infrastructure. Le résultat est une structure de State clairement segmentée :

├── Foundation Layer
│ ├── network-state.tf # VPCs, Subnets, Transit Gateways
│ ├── security-baseline-state.tf # Security Groups, NACLs, IAM Baseline
│ └── monitoring-state.tf # CloudWatch, Logging, Alarming
│
├── Platform Layer
│ ├── data-services-state.tf # Databases, Queues, Storage
│ ├── kubernetes-state.tf # EKS/OKE Cluster, Node Groups
│ └── ci-cd-state.tf # CI/CD Infrastructure
│
└── Application Layer
 ├── app-team-a-state.tf # Team A's Applications
 ├── app-team-b-state.tf # Team B's Applications
 └── shared-services-state.tf # Shared Application Services

Qu’est-ce qui rend cette approche si attrayante ?

Cette approche correspond à la logique des ingénieurs. Il existe trois couches :

• Foundation Layer : Contient des ressources stables avec une faible fréquence de changement. Les réseaux, les bases de sécurité et les composants d’observabilité sont durables et dépendent davantage des exigences infrastructurelles que des exigences métier. Le taux de changement est faible, car personne ne renomme régulièrement les plages CIDR ou ne modifie fréquemment les politiques de sécurité.
• Platform Layer : Les composants comme les bases de données ou les clusters Kubernetes changent à une fréquence modérée. Ils sont importants pour le métier mais ne sont pas modifiés quotidiennement. On observe ici souvent des processus de gestion du changement classiques avec des cycles de publication de 3, 6 ou 12 mois, selon les exigences métier et de conformité.
• Application Layer : Cette couche est très dynamique. Le développement de nouvelles fonctionnalités et les innovations produit entraînent des déploiements et des tests fréquents, ce qui induit des modifications régulières de l’infrastructure. À ce niveau, le mot-clé est « on demand » - les ressources ne sont déployées que lorsqu’elles sont nécessaires, puis supprimées pour économiser les coûts. Les States sont donc petits et isolés par équipe. Si l’équipe A provoque une erreur, l’équipe B n’est pas impactée.  

Cette structure favorise à la fois une répartition claire des responsabilités et une parallélisation efficace du travail entre les équipes. Elle réduit également le risque d’effets secondaires involontaires lors des modifications.

Exemple 2 : Terraform orienté domaine pour les environnements microservices

Une approche très différente mais tout aussi performante est utilisée dans les organisations orientées microservices : la répartition des States selon les domaines métier. L’Infrastructure-as-Code est ici structurée selon les domaines métier - de manière similaire au Domain-Driven Design.

├── Infrastructure Domain
│ ├── networking-state.tf # Shared Networking
│ └── security-state.tf # Security Controls
│
├── Service Domains
│ ├── user-service-domain.tf # User Management Services + Infrastructure
│ ├── payment-domain.tf # Payment Processing + Infrastructure
│ └── content-domain.tf # Content Management + Infrastructure
│
└── Cross-cutting Concerns
 ├── monitoring-state.tf # Observability Infrastructure
 ├── backup-state.tf # Backup and Recovery Systems
 └── compliance-state.tf # Compliance Controls

Pourquoi cela fonctionne-t-il bien ?

Cette approche correspond à la logique des responsables IT.

• Alignement avec la logique métier : L’infrastructure technique reflète l’organisation des domaines métier. Cela facilite la communication entre les équipes Dev, Ops et le management.
• Autonomie des équipes : Chaque équipe gère son propre domaine, y compris l’infrastructure associée. La dépendance vis-à-vis d’équipes centrales est réduite au minimum. Lorsque différents silos (réseau, base de données, stockage, etc.) collaborent sur un même service, ces responsabilités sont regroupées par service. Cela renforce l’agilité et réduit le time-to-market - deux notions très appréciées du management.
• Moins de coordination nécessaire : Les modifications d’infrastructure dans un domaine impactent rarement les autres équipes, ce qui diminue fortement les besoins de coordination inter-équipes. Cet aspect est également très apprécié du management, car il met en valeur la responsabilité propre des Value Streams et des équipes Scrum. 

Un avantage particulièrement fort de cette méthode est sa flexibilité en matière d’organisation des équipes. De nouveaux services ou domaines peuvent être ajoutés facilement sans perturber ou devoir réorganiser les structures existantes. Les collaborateurs peuvent intervenir aussi bien dans les équipes d’infrastructure de base que dans les équipes de service (équipes virtuelles). Cette flexibilité favorise néanmoins la duplication de code, raison pour laquelle les couches Infrastructure Domain et Cross-Cutting Concerns sont essentielles pour éviter les conflits dans le code, définir des règles claires et créer des modules de base que les équipes de service doivent obligatoirement utiliser. L’introduction de Policy-as-Code est ici indispensable, car les règles ne doivent pas seulement être définies, mais également appliquées de manière contraignante au sein de Terraform. 

 

Value Streams et gestion des Terraform States

La structuration des Terraform States ne doit pas se limiter aux couches ou modules techniques. Il est bien plus pertinent de s’appuyer sur les flux de valeur (Value Streams) de l’organisation. Structurer les States en fonction des flux de valeur, c’est s’aligner sur ce qui génère réellement de la valeur. Cela vaut aussi bien pour la fourniture d’infrastructure que pour le déploiement de nouvelles fonctionnalités.

Deux flux de valeur centraux se sont révélés particulièrement pertinents dans la pratique : Infrastructure Provisioning et Application Deployment.

Value Stream 1 : Infrastructure Provisioning

Lors du déploiement d’un environnement complet – par exemple pour un nouveau projet ou une nouvelle région – il est crucial que les Terraform States soient construits de manière logique, mais avec un minimum d’interdépendances. L’objectif est de pouvoir provisionner de grandes parties de l’infrastructure de façon autonome.

Un modèle éprouvé se présente ainsi :

Que se cache-t-il derrière ?

• Remote State Layer : Les configurations globales comme les politiques IAM, la gestion centralisée des secrets ou les backends de State forment la base.
• Network Layer : Les ressources régionales comme les VPC, subnets ou transit gateways sont ensuite créées.
• Platform Layer : Les services cloud-natifs comme les clusters Kubernetes, les bases de données ou les systèmes de messaging suivent.
• Application Layer : On y retrouve les workloads, configurations CI/CD et la logique applicative. Cette couche doit pouvoir être déployée de manière aussi indépendante que possible.

La modularité de cette architecture permet aux équipes de bootstrapper rapidement et de manière contrôlée des environnements entiers. Cela est particulièrement utile pour les nouveaux clients, régions ou domaines d’activité.

Value Stream 2 : Application Deployment

Un second flux de valeur tout aussi critique est le déploiement de fonctionnalités. Ici, la priorité est donnée à la rapidité, la stabilité et à l’absence d’impact sur les autres composants. Idéalement, les modifications peuvent être déployées de façon isolée, sans effets secondaires sur d’autres States.

Le modèle cible est le suivant :

Qu’est-ce qui compte ici ?

• Séparation par environnement : Les environnements de développement, test et production ont chacun leurs propres States. Ainsi, les nouvelles fonctionnalités peuvent être validées en environnement isolé avant d’être mises en production. Même si les environnements doivent être représentatifs et identiques, une séparation stricte des States est indispensable pour éviter qu’une modification en test n’ait d’effet accidentel sur la production.
• Dépendances minimales : Les States sont volontairement compacts afin de minimiser les risques de modification. Les ressources comme les bases de données ou les réseaux sont référencées via des outputs, mais jamais modifiées directement.
• Forte parallélisabilité : Les branches de fonctionnalités dans Git entraînent des modifications isolées sur un nombre réduit de States. L’équipe de déploiement peut ainsi réagir rapidement sans entrer en conflit avec d’autres équipes.

La combinaison entre logique de flux de valeur et structure de State bien pensée crée un cadre robuste pour des déploiements efficaces, sûrs et scalables. De la base infrastructurelle au Go-Live d’une nouvelle fonctionnalité, cette approche permet à la fois une grande flexibilité et un contrôle du rayon d’impact en cas d’erreur. L’état bien défini de l’ensemble du centre de données devient ainsi un objectif atteignable.

L’application concrète du principe de Boucles d’or

Le principe de Boucles d’or est plus qu’une simple métaphore. C’est un outil pratique pour concevoir des modules Terraform robustes et maintenables. L’art consiste à choisir le juste nombre de variables, de configurations et d’outputs. Ni trop, ni trop peu, mais juste ce qu’il faut.

Le diagramme suivant illustre cette tension : à gauche, la sous-dimension, à droite, la sur-optimisation. Au centre se trouve la zone dite de Boucles d’or - l’espace dans lequel les modules sont à la fois flexibles, stables et bien maintenables.

Quand il y en a trop peu...

Un module sous-dimensionné paraît souvent séduisant au premier abord, car il est simple. Mais cette simplicité est trompeuse. On reconnaît généralement ce cas à :

• Monolithes : Un fichier State unique et centralisé contenant tout - du réseau à la sécurité, jusqu’aux workloads
• Incomplétude : Peu voire pas de paramètres, ce qui engendre une dépendance vis-à-vis de la qualité du provider et la codification rigide de valeurs
• Code statique : Réutilisabilité limitée car le module est conçu pour un cas d’usage très spécifique et n’est pas entièrement dynamique
• Outputs inadéquats : Structures de sortie rigides, difficiles à intégrer dans d’autres modules
• Absence de garde-fous : Vérification incomplète des entrées (appelée Variable Validations), Lifecycle Conditions et Runtime Checks pour vérifier les valeurs calculées ou retournées par l’API sont essentielles pour garantir l’interopérabilité correcte entre les ressources provisionnées 

Ces modules sont difficilement adaptables et ont tendance à s’écrouler à la moindre exigence de flexibilité.

Quand il y en a trop...

À l’autre extrémité du spectre se cache le piège de la surstructuration. Elle se reconnaît à :

• Micromanagement : Une multitude de petits modules et States difficiles à appréhender
• Paramétrage excessif : Chaque détail est contrôlé depuis l’extérieur, même les configurations triviales. Les valeurs par défaut sont mal définies ou absentes
• Dépendances complexes : Les outputs s’entrelacent dans tous les sens, conduisant à une véritable « orgie d’outputs »
• Flux de données inutile : Outputs redondants ou trop génériques, avec peu de valeur ajoutée, au lieu d’outputs clairs et concis sous forme de maps Key/Value

Cela génère un overhead inutile, aussi bien dans le code que mentalement. La barrière à l’entrée pour les nouveaux membres d’équipe augmente, tout comme le risque d’erreurs.

La zone Boucles d’or : juste ce qu’il faut

Au centre se trouve le modèle idéal : des modules Terraform modulaires, compréhensibles et adaptés au travail en équipe. Caractéristiques typiques :

• States modulaires avec des frontières claires : Les States et modules sont séparés selon les couches, les domaines ou les environnements
• Paramètres suffisants mais non excessifs : Les modules fonctionnent avec des valeurs par défaut pertinentes, couvrant 80 % des cas d’usage
• Modules réutilisables : Grâce à une structure bien pensée, ces composants dynamiques peuvent être utilisés par plusieurs équipes
• Structures d’output cohérentes : Les outputs sont logiquement nommés et facilement référencés

Trouver cet équilibre permet de poser les bases d’une architecture IaC stable, capable de croître avec l’entreprise au lieu de lui faire obstacle.

 

Bonnes pratiques pour des implémentations Terraform évolutives

Terraform est un outil puissant – mais sa pleine efficacité ne se révèle que s’il est utilisé de manière systématique et stratégique. Dans des environnements en pleine croissance, certains principes de base sont essentiels pour construire des setups durables, robustes et efficaces. Voici quatre bonnes pratiques éprouvées qui ont fait leurs preuves dans des paysages cloud complexes.

1. Segmentation des States selon la vitesse de changement (Change Velocity)

Tous les éléments d’infrastructure ne changent pas à la même fréquence – et cela doit se refléter dans la structure Terraform. Une segmentation en fonction de la fréquence de modification permet de réduire les conflits et d’accélérer les cycles de développement.

Exemple d’une telle structure dans un environnement AWS :

└── AWS Infrastructure
    ├── low-velocity/        # Changements rares (ex. : réseaux, IAM)
    │   ├── network/
    │   ├── security/
    │   └── dns/
    │
    ├── medium-velocity/     # Changements occasionnels (ex. : bases de données)
    │   ├── rds/
    │   ├── elasticache/
    │   └── sqs/
    │
    └── high-velocity/       # Changements fréquents (ex. : compute, workloads)
        ├── app-cluster-a/
        ├── app-cluster-b/
        └── batch-processing/

Pourquoi cela fonctionne : Les équipes peuvent travailler indépendamment sans se bloquer mutuellement. Les éléments d’infrastructure rarement modifiés sont découplés des déploiements rapides – ce qui améliore à la fois la stabilité et l’agilité.

2. Modules Terraform dynamiques avec variables validées

Un module bien structuré est bien plus qu’un conteneur de ressources. Il doit pouvoir s’adapter à divers contextes tout en restant maîtrisable.

Éléments clés :

• Validation des variables : Chaque variable devrait – dans la mesure du possible – être validée via des blocs validation. Cela permet de détecter les valeurs invalides dès le départ.
• Sécurité de typage : Utilisez des définitions de type précises (string, number, bool, list(object), etc.) pour éviter toute ambiguïté.
• Variables optionnelles avec prise en charge de null : De nombreuses variables sont optionnelles – mais elles doivent explicitement être définies comme nullables pour fonctionner proprement avec des expressions conditionnelles.

Exemple :

variable "mounts" {
  type = map(object({
    audit_non_hmac_request_keys  = optional(list(string))
    audit_non_hmac_response_keys = optional(list(string))
    allowed_managed_keys         = optional(set(string))
    default_lease_ttl_seconds    = optional(number)
    description                  = optional(string)
    external_entropy_access      = optional(bool)
    identity_token_key           = optional(string)
    listing_visibility           = optional(string)
    local                        = optional(bool)
    max_lease_ttl_seconds        = optional(number)
    namespace                    = optional(string)
    options                      = optional(map(any))
    passthrough_request_headers  = optional(list(string))
    plugin_version               = optional(string)
    seal_wrap                    = optional(bool)
    allowed_response_headers     = optional(list(string))
    delegated_auth_accessors     = optional(list(string))
    path                         = string
    type                         = string
  }))
  default = null

description = <<-EOT
Defines the configurations for Vault mounts. Each mount configuration should specify the following keys:\

\[...]
EOT

  validation {
condition = (
var.mounts == null ? true : alltrue(\[
for mount in var.mounts : (
mount.listing\_visibility == null ||
mount.listing\_visibility == "unauth" ||
mount.listing\_visibility == "hidden"
)
])
)
error\_message = "The 'listing\_visibility' value must be either 'unauth' or 'hidden' if specified."
}

validation {
condition = (
var.mounts == null ? true : alltrue(\[
for mount in var.mounts : (
mount.path == null || (
!startswith(mount.path, "/") &&
!endswith(mount.path, "/")
)
)
])
)
error\_message = "The 'path' value must not start or end with a '/'."
}
\[... etc. ...]
}

Ces modules peuvent être utilisés transversalement par plusieurs équipes et réduisent considérablement l’effort de support.

3. Dépendances inter-States via Remote State

Dans des environnements complexes, il est rarement possible d’éviter totalement les dépendances entre ressources. Au lieu de les modéliser directement, il est recommandé d’utiliser les Remote State Outputs. Le principe est simple : un State produit des outputs pertinents, un autre les consomme via la data source terraform_remote_state.

Pour un Deep Dive, consultez la première partie de notre série d’articles "Terraform @ Scale", où ce sujet est traité en détail sur plusieurs sous-chapitres.

4. Le HashiCorp Toolstack comme catalyseur de stratégies de State

Les implémentations Terraform évolutives ne reposent pas uniquement sur du bon code. Elles s’appuient sur un écosystème qui favorise la sécurité, l’orchestration et la réutilisabilité. Chez *ICT.technology*, nous misons résolument sur le HashiCorp Stack pour répondre à ces exigences. Les composants clés sont les suivants :

• Terraform / Terraform Enterprise
  Gestion centralisée des States, Policy-as-Code (par exemple avec Sentinel), et isolation des Workspaces pour les équipes
• Vault / Vault Enterprise
  Gestion sécurisée des secrets, identifiants dynamiques pour l’accès cloud, rotation et audit-trails
• Consul / Consul Enterprise
  Service Discovery, vérification de l’état de santé, configuration dynamique et intégration avec les services de plateforme
• Nomad / Nomad Enterprise
  Orchestration de conteneurs, de VMs et de serveurs bare metal – avec un encombrement moindre que Kubernetes
• Packer
  Création d’images standardisées (Golden Images) avec versioning, idempotence et intégration CI/CD
• Boundary / Boundary Enterprise (uniquement si vous exploitez déjà des clusters PostgreSQL de niveau Enterprise avec les SLA et OLA appropriés)
  Accès sécurisé et basé sur l’identité aux composants d’infrastructure – particulièrement pertinent pour les bases de données de production ou les workloads réglementés

Ces outils permettent une pratique Terraform cohérente, traçable et sécurisée – même dans des environnements Enterprise hétérogènes et fortement dynamiques.

Guide pratique pour le dimensionnement des States

La taille optimale d’un Terraform State ne découle pas d’un modèle standard, mais d’un processus structuré qui concilie réalités techniques et exigences organisationnelles. Ce qui suit esquisse un guide pratique éprouvé pour aider à la planification et à la mise en œuvre.

1. Analyse de la structure organisationnelle

La première étape consiste à bien comprendre sa propre organisation :

• Qui gère quelles ressources ? Existe-t-il des équipes d’infrastructure centralisées ou les équipes applicatives travaillent-elles de manière autonome ?
• Où l’autonomie est-elle nécessaire ? Les équipes ayant une fréquence élevée de déploiement devraient disposer de leurs propres States afin d’éviter de se bloquer mutuellement.
• Quels sont les cycles de vie ? Les ressources qui évoluent ou sont supprimées ensemble devraient idéalement être regroupées dans le même State.

2. Analyse des dépendances

La deuxième étape concerne les interconnexions techniques entre les ressources :

• Quelles ressources sont fortement couplées ? Exemple : Security Groups et instances EC2, ou Subnets et Load Balancer.
• Que peut-on découpler ? Le monitoring, les rôles IAM ou les systèmes de sauvegarde peuvent souvent être gérés séparément – ce qui réduit la complexité.

3. Test et itération

Avant d’engager une réorganisation à grande échelle, un test ciblé est recommandé :

• Projets pilotes avec une structure de State variable : Par exemple une équipe qui expérimente entre une approche monolithique et une approche segmentée.
• Critères mesurables : Performance (Plan/Apply), fréquence des erreurs, satisfaction des équipes, rapidité des cycles de release.

Étude de cas : migration cloud d’un client Enterprise

Un exemple parlant est celui d’un prestataire de services financiers qu’*ICT.technology* a accompagné dans sa transition d’une infrastructure on-premise vers Oracle Cloud Infrastructure (OCI).

Situation initiale :
L’environnement Terraform consistait en un seul State de grande taille. Résultat :

• Près de 45 minutes d’exécution pour chaque terraform apply
• Conflits fréquents de verrouillage du State
• Cycles de développement et de publication lents

Approche adoptée :
Nous avons appliqué le principe de Boucles d’or et segmenté l’infrastructure comme suit (les équipes et services ont ensuite été mappés sur ces segments via les capacités multi-tenant de Terraform Enterprise, en fonction des besoins) :

├── Foundation
│   ├── network/
│   │   ├── transit/
│   │   ├── network/
│   │   └── interconnect/
│   └── security/
│       ├── iam/
│       ├── security-groups/
│       └── baseline/
├── Data Services
│   ├── databases/
│   ├── storage/
│   └── analytics/
└── Applications
    ├── frontend/
    ├── backend/
    ├── batch/
    └── monitoring/

Résultats :

• Temps d’application réduit à moins de 5 minutes, car les changements d’infrastructure étaient livrés bien plus rapidement
• Travail en parallèle facilité, les équipes pouvant déployer indépendamment sans se bloquer mutuellement
• Releases 70 % plus rapides grâce à des cycles de feedback plus courts et une réduction des frictions
• Stabilité accrue par des changements plus petits, bien délimités, limitant le Blast Radius en cas d’erreurs ou de mauvaises configurations
• Réduction massive des coûts grâce à un provisioning dynamique et à la demande de serveurs Bare Metal et de VMs – avec déploiement uniquement en cas de besoin réel, puis suppression automatique

Conclusion : vers une mise à l’échelle optimale de Terraform

Le dimensionnement des Terraform States n’est pas un problème d’architecture ponctuel. Il s’agit d’un processus de maturation continue. Le principe de Boucles d’or permet d’éviter les extrêmes : la base de code ne doit être ni trop monolithique, ni trop fragmentée.

L’essentiel est de comprendre sa propre organisation, de clarifier les responsabilités et d’aligner la mise en œuvre technique sur les workflows réels.

ICT.technology accompagne les entreprises sur cette voie – depuis les premières étapes de Cloud Adoption jusqu’à la transition complète vers l’excellence Infrastructure-as-Code. Grâce à une expertise approfondie de Terraform, de l’écosystème HashiCorp et des architectures cloud, nous construisons des solutions techniquement robustes et organisationnellement durables.

Des Terraform States bien structurés ne sont pas une fin en soi. Ils constituent un levier stratégique essentiel pour la scalabilité, la rapidité et la stabilité opérationnelle – et donc un facteur de succès décisif pour toute organisation IT moderne.