IaC : Terraform + Ansible
Infrastructure as Code : Terraform et Ansible — module 5HASH, Supinfo.
En septembre 2026, j’ai animé le module 5HASH « Infrastructure as Code » pour une promotion de Master de Supinfo Tours : quatre jours de cours et d’ateliers pratiques, suivis d’un projet en groupe et d’une soutenance orale.
Avant la session, j’ai mis à jour le support fourni par l’école et réécrit l’ensemble des ateliers pour qu’ils tournent entièrement en local, sur Floci, un émulateur AWS : aucun compte cloud, aucun frais, aucun risque pour les étudiants.
| Format | 4 jours · 7 cours, 8 ateliers pratiques et 1 atelier bonus, projet en solo, binôme ou trinôme |
| Niveau | Master 2 — Cursus Grande École |
| Promotion | Tours, PGE 2026-2027 · 11 étudiants |
| Outils | Terraform, Ansible, AWS (EC2, VPC, ALB, Auto Scaling, RDS, S3, Secrets Manager, IAM), Floci, Docker, GitLab CI |
Jour 1 — Les fondamentaux de Terraform
Théorie
Pourquoi l’Infrastructure as Code, du serveur physique au cloud, panorama des outils (Terraform, OpenTofu, Pulumi, Ansible) et concepts clés : providers, ressources, state, cycle plan / apply. Puis le langage HCL et la lecture de l’existant avec les data sources.
Pratique
Un premier atelier parcourt le cycle de vie complet d’une infrastructure avec des conteneurs Docker, de la création à la destruction. Le second pilote des services AWS émulés (S3, DynamoDB, SSM, SQS, EC2) au milieu d’une infrastructure existante : ce que Terraform possède, et ce qu’il se contente de lire.
Jour 2 — Structurer, collaborer, sécuriser
Théorie
Les modules, variables, outputs et locals ; la gestion du state, les backends et workspaces, les secrets et la dérive d’infrastructure.
Pratique
Un fil rouge, CatCompressor, un pipeline de miniatures d’images (S3, SQS, conteneurs), grandit d’atelier en atelier : découpage en modules réutilisables, environnements dev et staging composés à partir du même code, state partagé sur S3 avec verrouillage natif, workspaces, secrets dans AWS Secrets Manager, détection et correction d’une dérive, migration du state vers GitLab. En bonus : intégration continue avec terraform test.
Jour 3 — Ansible : configurer des serveurs par le code
Théorie
Le fonctionnement d’Ansible, l’inventaire, les playbooks, les rôles et l’idempotence ; la gestion des fichiers, les handlers et le contrôle d’exécution.
Pratique
Le matin, configurer deux serveurs web identiques sans jamais s’y connecter à la main : inventaire, playbook déclaratif, rôles réutilisables, modèle Jinja2 alimenté par les informations de chaque machine. L’après-midi, écrire une automatisation qui ne fait que ce qui est nécessaire : le bon module plutôt qu’une commande, des handlers, des conditions, et la lecture critique d’un récapitulatif d’exécution.
Atelier bonus — La Médiathèque : reprendre un projet hérité
Trois heures dans une situation fréquente en entreprise : reprendre un projet Ansible écrit par quelqu’un d’autre. Avant de toucher à quoi que ce soit, les étudiants posent un diagnostic : lire un projet inconnu dans un ordre qui évite de se perdre, confronter ce que croit l’inventaire à ce qui existe réellement, distinguer ce qui empêche le projet de démarrer de ce qui le rend dangereux. Ils mesurent ensuite l’écart entre le code et les machines sans rien modifier, décident au cas par cas qui a raison, puis corrigent étape par étape, jusqu’à prouver le résultat.
Jour 4 — Terraform et Ansible ensemble
Théorie
Ansible Vault, Ansible Galaxy et l’intégration entre Terraform et Ansible.
Pratique
Terraform décrit l’infrastructure (réseau, instances, secrets) et aussi l’inventaire d’Ansible, lu par un inventaire dynamique : plus aucune adresse recopiée à la main. Les secrets sont protégés par Vault, et chaque étudiant vérifie que la configuration ne crée aucune dérive. La suite de la journée porte sur l’exploitation : durcissement SSH et système, HTTPS, pare-feu, supervision Prometheus avec alertes, sauvegardes dans deux régions avec des droits minimaux, et restauration.
Le projet — Taylor Shift’s Ticket Shop
Pour clore le module, chaque équipe avait deux semaines pour déployer la billetterie en ligne d’une tournée de concerts (PrestaShop) et la rendre capable d’encaisser le pic de l’ouverture des ventes. Terraform pour l’infrastructure AWS, Ansible pour la configuration, et un README court qui permette à une équipe technique de reprendre la solution.
Les équipes ont proposé des architectures variées : répartiteur de charge devant plusieurs instances réparties sur deux zones, groupes Auto Scaling avec politiques de montée en charge, base RDS dans des sous-réseaux privés, secrets dans Secrets Manager et Ansible Vault, environnements dev, staging et prod isolés, state partagé et verrouillé.
L’évaluation et l’oral
J’ai relu le code de chaque projet en entier et noté chaque critère du barème (30 points) avec une justification écrite. Les limites de l’émulateur rencontrées par tous les groupes n’ont pas été pénalisées.
La soutenance comprenait une démonstration et des questions préparées pour chaque projet, formulées de manière ouverte : que se passe-t-il quand le trafic triple, quand une instance tombe, où se trouvent réellement les secrets, pourquoi le second passage d’Ansible ne change rien. L’objectif : vérifier la compréhension des choix techniques plutôt que la récitation.
Mon approche pédagogique
- Un fil rouge : le même projet grandit d’atelier en atelier, de la première ressource au pipeline d’intégration continue.
- Des ateliers guidés : on donne le bloc de code, l’étudiant l’adapte et en observe l’effet.
- Des consignes testées : chaque atelier est rejoué automatiquement, étape par étape, avant chaque séance.
- Un contenu à jour : verrouillage natif du state S3, provider AWS 6, Floci en remplacement de LocalStack Community.
- De vrais réflexes de production : idempotence, secrets hors du code, environnements isolés, lecture d’un plan avant de l’appliquer.