Le rôle crucial d'un Infra-as-Code dans un environnement DevOps
L'Infrastructure as Code : pourquoi c'est la première chose que je mets en place
Quand j'arrive sur un nouveau projet, la question n'est jamais "faut-il faire de l'IaC ?" mais "par quel module Terraform on commence ?". En 15 ans de métier et plus de 100 projets, j'ai vu les dégâts que cause une infrastructure gérée "à la main" : des serveurs configurés différemment, des environnements qui ne se ressemblent pas, et des déploiements qui échouent pour des raisons mystérieuses.
Terraform : 25 modules pour une architecture AWS complète
Mon projet le plus ambitieux en matière d'IaC reste l'architecture AWS multi-comptes chez F2R2. En partant d'un audit de 15 jours qui avait identifié 82 actions d'optimisation, j'ai conçu une infrastructure reposant sur 25 modules Terraform : gestion des comptes AWS Organizations, EKS Fargate pour l'orchestration des conteneurs, Aurora Serverless v2 pour les bases de données, WAF pour la sécurité web, et GuardDuty pour la détection de menaces. Chaque module est versionné, testé et documenté. Le résultat : une infrastructure reproductible en quelques commandes terraform apply, et une réduction du budget cloud de 19%.
Ansible : quand l'IaC rencontre la gestion de configuration
Terraform gère l'infrastructure, Ansible gère ce qu'il y a dessus. Chez Epiconcept, mes playbooks Ansible configurent des serveurs MariaDB, déploient des conteneurs Docker et maintiennent des environnements cohérents pour des applications de santé publique sensibles (INSERM, Armées). L'avantage d'Ansible est sa simplicité : pas d'agent, du YAML lisible, et une idempotence qui garantit que lancer un playbook deux fois produit toujours le même résultat. Pour un environnement HDS où l'auditabilité est cruciale, c'est indispensable.
Docker et Kubernetes : l'IaC appliquée aux applications
L'IaC ne s'arrête pas à l'infrastructure serveur. Chez Okeiro, startup e-santé sur un cloud souverain S3NS (Thales x Google), j'ai développé un Helm Chart complet regroupant 4 composants FHIR. Chaque déploiement est déclaratif : les manifestes Kubernetes définissent exactement l'état souhaité du cluster GKE Autopilot, et ArgoCD se charge de le maintenir. Chez KNDS, dans le secteur de la défense, les manifestes Kubernetes incluent des NetworkPolicies strictes, du RBAC granulaire et des profils seccomp, le tout versionné dans Git.
CI/CD et IaC : le cercle vertueux
L'IaC prend tout son sens quand elle est intégrée dans un pipeline CI/CD. Chez TEKYN, chaque modification de l'infrastructure Terraform passe par une pull request, un terraform plan automatique dans GitHub Actions, et un review par l'équipe avant le terraform apply. Cette approche GitOps appliquée à l'infrastructure élimine les modifications en douce et garantit la traçabilité. Chez Bloomflow, j'ai mis en place le même pattern sur 3 cloud providers différents pendant mes 5 ans en CDI.
Observabilité de l'infrastructure : Prometheus et Grafana
Une infrastructure codée c'est bien, une infrastructure monitorée c'est mieux. Sur chaque projet Kubernetes, je déploie systématiquement Prometheus pour les métriques et Grafana pour la visualisation. Chez Metronome, cette stack m'a permis de détecter une fuite mémoire sur un service qui aurait coûté cher en downtime si elle était passée inaperçue. L'observabilité doit être intégrée dès le départ dans votre code d'infrastructure, pas ajoutée après coup.
Mon conseil : traitez votre infrastructure comme votre code applicatif
Versionnez-la, testez-la, reviewez-la, déployez-la automatiquement. Si vous ne pouvez pas recréer votre environnement de production en une commande, vous avez un problème. L'IaC n'est pas une mode, c'est la pratique qui distingue une infrastructure artisanale d'une infrastructure industrielle.