Consultant Terraform : une Infrastructure as Code fiable, lisible et reproductible

Le problème : une infrastructure que personne n’ose toucher

Beaucoup d’entreprises ont déjà « du Terraform ». Les difficultés arrivent ensuite : un dépôt unique dont le plan prend de longues minutes et touche tout à la fois, un state local sur le poste d’un ancien prestataire, des modifications faites dans la console qui ne figurent pas dans le code, des environnements qui divergent sans que personne ne sache lequel est la référence. Résultat : chaque changement fait peur, et l’infrastructure redevient manuelle.

L’Infrastructure as Code n’apporte de valeur que si le code reste la source de vérité, si chaque changement est relu avant d’être appliqué et si l’équipe peut faire évoluer l’ensemble sans l’auteur d’origine. Cette page décrit notre façon de mettre ces principes en œuvre.

Le fondateur de Feekr construit et opère des infrastructures AWS en Infrastructure as Code (Terraform, Terraspace, OpenTofu), y compris en contexte réglementé d’hébergement de données de santé. Cette page reflète cette pratique quotidienne.

Ce que nous faisons

Structurer le code

• Découpage en stacks par domaine et par cycle de vie : réseau, identités, données, calcul, applicatif. Un changement applicatif ne doit pas produire un plan sur le réseau.
• Modules internes versionnés, avec des entrées explicites, des valeurs par défaut sûres (chiffrement, journalisation, tags) et une documentation générée. Nous utilisons les modules publics quand ils sont maintenus et adaptés, et nous les épinglons à une version.
• Environnements décrits par des variables et des fichiers de configuration, pas par des copies de code. Recette et production partagent le même code, à des paramètres près.
• Conventions : nommage, tags, structure des fichiers, versions minimales de Terraform ou OpenTofu et des providers figées dans le code et dans un fichier de verrouillage commité.

Sécuriser le state

• Backend distant chiffré (S3, Azure Storage) avec versionnement pour revenir en arrière, et verrouillage pour empêcher deux applications simultanées. Sur AWS, le verrouillage passe historiquement par DynamoDB, les versions récentes de Terraform et OpenTofu proposent un verrouillage natif sur S3.
• Un state par stack et par environnement, pour limiter le rayon d’impact d’une erreur.
• Accès au state restreint : il contient des valeurs sensibles. Les secrets eux-mêmes restent dans un coffre (AWS Secrets Manager, Azure Key Vault), référencés et non copiés.

Automatiser avec la CI/CD

• Sur chaque merge request : formatage, validation, analyse statique de sécurité, puis plan publié en commentaire pour la revue.
• Après validation : apply exécuté par le pipeline, avec une identité dédiée (fédération OIDC entre votre forge et le cloud plutôt que des clés stockées), jamais depuis un poste.
• Promotion entre environnements : le même code passe en recette, puis en production après approbation.
• Compatible GitLab CI, GitHub Actions ou Azure DevOps, selon votre forge.

Revoir les plans

La revue de plan est le moment où l’on évite les incidents. Nous formons vos équipes à lire un plan : repérer un destroy ou un remplacement inattendu, un changement d’attribut qui force la recréation d’une base de données, une modification de politique IAM plus large que prévu. Des règles de protection (prevent_destroy, politiques sur les ressources sensibles) complètent la vigilance humaine.

Détecter la dérive

Un plan planifié sur chaque stack signale l’écart entre le code et la réalité. Chaque dérive se traite de deux façons : soit le changement manuel était légitime et on le reporte dans le code, soit on réapplique le code. Associé à des garde-fous qui limitent les modifications manuelles en production, c’est ce qui garde le code fidèle à l’infrastructure.

Livrables concrets

• Audit du code existant : structure, state, sécurité, pipelines, dette, avec un plan de remise à niveau priorisé.
• Socle de dépôts et de modules documenté, avec conventions écrites.
• Backends de state configurés et sécurisés, migration des states existants si nécessaire.
• Pipelines CI/CD de plan, revue et application.
• Import de l’existant : ressources créées à la main ramenées dans le code, jusqu’à un plan sans changement.
• Guide d’exploitation : ajouter un environnement, mettre à jour un provider, traiter une dérive, restaurer un state.

Critères de choix et pièges fréquents

Sujet	Question à se poser	Piège fréquent
Outil	Terraform, OpenTofu, ou une surcouche (Terragrunt, Terraspace) ?	Ajouter une surcouche avant d’en avoir besoin
Découpage	Qu’est-ce qui change ensemble, et à quelle fréquence ?	Un state unique pour toute l’infrastructure
Modules	Qui les maintient et comment sont-ils versionnés ?	Des modules trop génériques, avec des dizaines de variables
Environnements	Code identique et paramètres différents ?	Copier-coller un dossier par environnement
Exécution	Qui a le droit d’appliquer en production ?	Des apply depuis les postes, sans trace
Versions	Providers et outil épinglés ?	Une mise à jour silencieuse qui change un plan

Le choix entre Terraform et OpenTofu n’est pas qu’une question technique : il touche à la licence, au support et à vos outils de pipeline. Nous l’instruisons avec vous et documentons la décision.

Comment nous travaillons avec vos équipes

Cadrer : audit, objectifs, conventions et découpage cible. Construire : modules, backends, premiers périmètres migrés. Industrialiser : pipelines, revue de plan, détection de dérive, politiques de sécurité. Améliorer : nouveaux périmètres, mises à jour, accompagnement des premières contributions de vos équipes.

Nous travaillons en binôme avec vos ingénieurs, par merge requests relues ensemble. Le code vous appartient, les décisions d’architecture sont écrites, et l’objectif explicite est que votre équipe maintienne l’infrastructure sans nous.

Pour qui, et quand nous appeler

Équipes qui démarrent sur AWS ou Azure et veulent partir sur de bonnes bases, entreprises dont l’infrastructure est encore manuelle, ou équipes qui ont hérité d’un code Terraform devenu difficile à faire évoluer. L’Infrastructure as Code est aussi le socle de nos projets de migration cloud, de sécurité et gouvernance et de FinOps. Nous sommes basés à Villeneuve-d’Ascq, dans la métropole lilloise, et intervenons sur site ou à distance.

[ VOS QUESTIONS ]

Questions fréquentes

Que fait un consultant Terraform ?

Il conçoit ou reprend votre code d’infrastructure : structure des dépôts, modules, gestion du state, pipelines de déploiement et règles de revue. Il intervient aussi pour migrer une infrastructure créée à la main vers du code, et forme l’équipe pour qu’elle maintienne le tout seule.

Travaillez-vous aussi avec OpenTofu ?

Oui. OpenTofu est un fork de Terraform maintenu sous l’égide de la Linux Foundation, créé après le changement de licence de Terraform par HashiCorp. Les deux partagent l’essentiel du langage et des providers, avec des fonctionnalités qui divergent progressivement. Le choix dépend de votre position sur la licence, de vos outils existants et des fonctionnalités dont vous avez besoin.

Comment importer une infrastructure existante dans Terraform ?

On inventorie les ressources, on écrit le code cible module par module, puis on importe les ressources existantes dans le state avec les blocs import. Le critère de réussite est un plan sans changement : le code décrit exactement ce qui tourne. On procède par périmètres, en commençant par le moins critique.

Où stocker le state Terraform ?

Dans un backend distant chiffré, avec versionnement et verrouillage : un bucket S3 sur AWS ou un compte de stockage Azure, ou une plateforme dédiée. Jamais dans le dépôt Git ni sur un poste de développeur, car le state contient des informations sensibles et doit être partagé sans écritures concurrentes.

Faut-il tout réécrire pour reprendre un code Terraform existant ?

Rarement. Nous partons de l’existant, sécurisons d’abord le state et les pipelines, puis refactorisons par étapes avec des blocs moved et des imports, en vérifiant à chaque étape que le plan ne détruit rien. La réécriture complète se justifie seulement quand le découpage actuel bloque toute évolution.