Test-Driven Infrastructure : appliquer le TDD à l’Infrastructure as Code

Comment appliquer les principes du Test-Driven Development à l’infrastructure cloud avec Terraform, Kubernetes et GitOps, en testant les règles avant le déploiement.

Test-Driven Infrastructure  

Appliquer le TDD à l’Infrastructure as Code  

Le Test-Driven Development (TDD) est aujourd’hui bien installé côté applicatif.
En revanche, lorsqu’il s’agit d’infrastructure, beaucoup considèrent encore que le TDD est inutile, trop complexe ou inadapté.

C’est une erreur.

Le TDD appliqué à l’infrastructure existe déjà, souvent sans être nommé. Lorsqu’il est bien compris, il devient un levier majeur pour sécuriser, structurer et faire évoluer une plateforme cloud.

Cet article explique ce que signifie réellement le TDD en infrastructure, comment l’appliquer concrètement, et pourquoi il devient indispensable à mesure que les systèmes grandissent.

Rappel : qu’est-ce que le TDD ?  

Le TDD repose sur un cycle simple :

1. Red – écrire un test qui échoue
2. Green – écrire le minimum pour faire passer le test
3. Refactor – améliorer la solution sans changer son comportement

L’objectif n’est pas le test en lui-même, mais le fait que le test précède le design.

C’est précisément ce point qui rend le TDD particulièrement pertinent pour l’infrastructure.

Pourquoi l’infrastructure est un cas particulier  

L’infrastructure possède trois caractéristiques qui compliquent son test :

• elle est déclarative (Terraform, CloudFormation, manifests Kubernetes),
• elle dépend de systèmes externes réels (cloud providers, clusters),
• elle est souvent validée après déploiement, donc trop tard.

Historiquement, on considère que l’infrastructure est “testée” lorsque :

• terraform apply passe sans erreur,
• les ressources apparaissent dans la console,
• l’application fonctionne en production.

Ce ne sont pas des tests TDD.
Ce sont des constats a posteriori.

Ce que signifie vraiment “tester” une infrastructure  

En TDD infra, un test ne vérifie pas que :

“la ressource existe”

Il vérifie que :

“l’infrastructure générée respecte un ensemble de règles explicites”.

On ne teste donc pas des objets, mais des invariants.

::contentReference[oaicite:0]{index=0}

Exemples d’invariants :

• un stockage est toujours chiffré
• un service exposé est toujours protégé par TLS
• un pod définit requests et limits
• une ressource publique est explicitement déclarée comme telle

Ces règles doivent être validées avant tout déploiement.

Tester avant le déploiement : le cœur du TDD infra  

Le TDD infrastructure s’exécute avant l’exécution réelle.

Terraform : tester le plan, pas le cloud  

Avec Terraform, la cible principale du test est le plan.

On ne teste pas AWS.
On teste ce que Terraform va demander à AWS.

Exemples de règles testables :

• un bucket S3 ne doit jamais être public
• le versioning est obligatoire
• le chiffrement par défaut est activé
• les ressources critiques ne peuvent pas être détruites par erreur

Ces tests peuvent être implémentés via :

• des tests unitaires sur la sortie du plan
• des policies (OPA, Sentinel)
• des frameworks comme Terratest en mode non destructif

Le déploiement réel devient alors un détail d’implémentation, pas un moment de découverte.

Kubernetes : tester les manifests, pas le cluster  

Le raisonnement est identique pour Kubernetes.

On teste les manifests générés, pas le comportement du cluster.

Exemples de règles :

• aucune image avec le tag latest
• présence obligatoire de requests et limits
• labels standards requis
• ports ou capabilities interdits
• séparation claire des namespaces

Ces tests s’exécutent :

• avant kubectl apply
• dans la CI
• avant toute fusion dans la branche principale

Tester des règles, pas des valeurs  

Principe fondamental du TDD :

❌ Mauvais test

“le subnet doit s’appeler prod-subnet-1”

✅ Bon test

“tout subnet exposé à Internet doit être explicitement public”

Les valeurs changent.
Les règles structurantes doivent rester stables.

Un bon test infra exprime une intention métier, sécurité ou plateforme, jamais un détail cosmétique.

Le TDD infra comme outil de design  

Comme en TDD applicatif, les tests révèlent la qualité du design.

Lorsqu’on commence à écrire des tests infra :

• les modules trop gros deviennent difficiles à tester
• les dépendances implicites apparaissent
• les abstractions floues deviennent douloureuses

La règle reste la même :

si c’est difficile à tester, c’est probablement mal conçu

Le TDD infra pousse naturellement vers :

• des modules plus petits
• des responsabilités claires
• des interfaces explicites
• des invariants documentés par les tests eux-mêmes

Red / Green / Refactor appliqué à l’infrastructure  

Le cycle TDD existe réellement en infrastructure, mais à un niveau plus abstrait.

🔴 Red  

Besoin :

“exposer un service HTTP sécurisé”

Tests :

• TLS obligatoire
• aucune IP publique directe
• règles réseau strictes
• logs activés

🟢 Green  

Implémentation minimale :

• load balancer
• certificats
• règles réseau nécessaires

🔁 Refactor  

• factorisation dans un module
• renommage
• séparation public / privé
• amélioration de la lisibilité

Les tests restent inchangés.
Ils décrivent la règle, pas la solution.

TDD infra ≠ tests d’intégration  

Une confusion fréquente consiste à confondre TDD infra et tests d’intégration.

Le TDD infra permet d’éliminer une grande partie des erreurs avant même l’exécution.

Pourquoi le TDD infra reste peu adopté  

Les raisons sont souvent organisationnelles :

• pression du delivery
• confiance excessive dans terraform plan
• culture “clickops scripté”
• manque de formation et de standards

Pourtant, dès que l’on travaille avec :

• plusieurs comptes cloud
• plusieurs équipes
• du GitOps
• des contraintes de sécurité fortes

Ne pas tester l’infrastructure devient un risque systémique.

Écosystèmes favorables au TDD infra  

Le TDD infra s’intègre naturellement avec :

• :contentReference[oaicite:1]{index=1}
• :contentReference[oaicite:2]{index=2}
• policy as code (OPA, Sentinel)
• pipelines CI stricts
• plateformes internes et golden paths

Conclusion  

Le TDD en infrastructure n’est pas une surcouche de tests.
C’est un changement de posture.

On ne déploie plus pour voir si ça marche.
On prouve que l’infrastructure respecte les règles avant même d’exister.

À grande échelle, ce n’est pas un luxe.
C’est une condition de survie.