Insights — Cloud et Terraform
Écrire son infrastructure n'est pas un projet : c'est une façon de travailler.
Personne ne confie ses serveurs à un script que personne ne relit. Terraform ne remplace pas la console : il la rend reproductible, révisable et réversible. Voici l'ordre dans lequel nous le posons chez une PME, sans équipe plateforme dédiée.
01 — Le constat
Sans code, votre infrastructure n'a pas d'histoire.
La question n'est pas technique, elle est documentaire : dans deux ans, qui saura pourquoi ce sous-réseau a été ouvert, qui a modifié cette règle, et comment remonter l'environnement à l'identique après un incident ?
La console répond à « quel est l'état actuel ». Le code répond à « qui a changé quoi, quand, et pourquoi ». C'est cette seconde réponse qui manque dans la plupart des PME — et c'est celle qui coûte le plus cher le jour où quelqu'un part.
01Pourquoi le code, et pas la console
Une infrastructure décrite en code se relit comme une recette : la modification passe par une revue, l'historique garde la trace de l'intention, et un retour arrière est possible. C'est aussi la seule façon de reconstruire un environnement à l'identique, ce qui rend un plan de reprise crédible au lieu d'être un document que personne n'a testé.
- Chaque changement est relu avant d'être appliqué
- L'historique dit qui a voulu quoi, et quand
- Un environnement se recrée à l'identique
- La documentation devient le code lui-même
- Les garde-fous sont appliqués, pas seulement écrits
02Les cinq étapes, dans l'ordre
L'erreur la plus fréquente est de commencer par le réseau, puis de découvrir six mois plus tard qu'aucun compte n'est cloisonné. Nous commençons toujours par la gouvernance : un compte d'administration, une organisation, un compartiment d'état verrouillé et un journal d'audit déjà allumé.
Le réseau vient ensuite, puis l'application, puis la supervision, et enfin la détection. À ce stade seulement, on peut parler sérieusement d'optimisation des coûts, parce qu'on sait qui consomme quoi.
- Compte d'administration, organisation et journal d'audit d'organisation
- État distant chiffré et verrouillé — jamais de fichier d'état local en production
- Réseau : zones, sous-réseaux privés, points de terminaison privés
- Application : conteneurs, bases, files d'attente, sauvegardes
- Garde-fous : détection, budgets, alertes progressives
03Les trois erreurs qui coûtent le plus cher
La première est l'état local : un fichier d'état conservé sur un poste de travail, sans verrouillage, appliqué par deux personnes le même jour. La deuxième est d'écrire des modules maison avant d'avoir appliqué la première version : on généralise une architecture que l'on ne maîtrise pas encore. La troisième, la plus fréquente, est de continuer à modifier la production à la main — dans ce cas, le code devient un mensonge, et la carte ne correspond plus au territoire.
02 — Questions courantes
Ce qu'on nous demande avant de commencer
Faut-il réécrire toute l'infrastructure existante ?
Non. On commence par décrire en code ce qui est créé souvent — un environnement de recette, un nouveau service — puis on « importe » progressivement l'existant, à l'occasion des changements réels. Une reprise complète d'un coup est un projet inutilement risqué.
Combien de temps pour un socle utilisable ?
Comptez deux à trois semaines pour la gouvernance, le réseau et les garde-fous d'une première application, à condition de partir d'un cahier des charges clair. Les exemples commentés que nous publions couvrent déjà ces étapes.
Faut-il une équipe dédiée pour maintenir tout cela ?
Non, à condition de rester sobre : peu de modules, des versions figées, et une revue de code à chaque changement. Une plateforme sur laquelle une seule personne sait appliquer est un risque ; c'est justement ce que le code partagé corrige.
Vous voulez voir à quoi ressemble un socle AWS lisible ?
Nous posons le socle, nous le documentons et nous le laissons à vos équipes avec la piste d'audit, les garde-fous et les alarmes déjà en place.