L'importance de l'automatisation des infrastructures cloud

Introduction

"Plus jamais de clic dans la console AWS." C'est la premiere phrase que je dis a chaque nouveau client. Et ce n'est pas un slogan : c'est une lecon apprise a la dure. Un vendredi soir chez un client, quelqu'un a supprime un security group en console parce qu'il "ne servait plus". Ce security group etait reference par une base de donnees RDS. L'application est tombee instantanement. Avec Terraform, cette suppression aurait ete detectee au plan et bloquee. Depuis, ma conviction est inébranlable : ce qui n'est pas code finit par diverger, se casser et couter cher.

Terraform : 25 modules pour une architecture complete

Terraform est au coeur de tous mes projets d'infrastructure. Mon cas d'usage le plus abouti est chez F2R2 : 25 modules Terraform couvrant une architecture AWS Multi-Compte de bout en bout. Chaque module est une brique independante, versionnee dans un registry Terraform prive :

• Reseau : VPC avec subnets publics/prives, NAT Gateway, route tables, VPC endpoints pour les services AWS (S3, ECR, STS)
• Cluster : EKS Fargate avec Fargate profiles par namespace, IAM roles IRSA, addons managés (CoreDNS, kube-proxy, VPC CNI)
• Donnees : Aurora PostgreSQL avec replicas en lecture, chiffrement KMS, backups automatiques
• Securite : WAF avec regles gerees AWS, GuardDuty pour la detection de menaces, CloudTrail pour l'audit
• IAM : roles cross-account pour l'acces entre comptes dev/staging/prod, OIDC pour GitHub Actions

Le resultat concret : creer un nouvel environnement complet prend 45 minutes avec un terraform apply, contre 3 jours de configuration manuelle dans la console. Et cet environnement est strictement identique aux precedents.

Ansible : la configuration qui survit aux incidents

Si Terraform gere le provisionning, Ansible gere la configuration des machines. Chez Epiconcept, pendant 4 ans, j'ai maintenu une base de plus de 50 playbooks Ansible pour les applications de l'INSERM et des Armees. Configuration MariaDB (replication master-slave, tuning des buffers), durcissement SSH (desactivation du root login, cles ed25519 uniquement), deploiement des agents de monitoring, gestion des certificats Let's Encrypt.

Le vrai test de l'automatisation, c'est l'incident. Quand un serveur physique a rendu l'ame un dimanche matin, la reconstruction complete sur un nouveau serveur a pris 20 minutes : provisionning de la VM, execution du playbook Ansible, restauration du backup MariaDB. Sans Ansible, cette operation aurait pris une journee de configuration manuelle sous stress, avec le risque d'oublier un parametre critique. L'automatisation, c'est de la serenite operationnelle.

L'audit : la premiere etape avant d'automatiser

On n'automatise pas du chaos. Chez F2R2, mon premier travail a ete un audit AWS de 15 jours. J'ai analyse chaque service actif, chaque ressource provisionnee, chaque ligne de facture avec AWS Cost Explorer et Trusted Advisor. Le diagnostic :

• Instances EC2 oversizees : des t3.xlarge qui consommaient en moyenne 8% de CPU. Passage en t3.medium, soit -60% sur ces postes.
• Volumes EBS non attaches : 12 volumes orphelins totalisant 800 Go, restes d'instances terminees manuellement.
• Snapshots obsoletes : 450 Go de snapshots EBS vieux de plus d'un an, jamais nettoyes.
• NAT Gateways redondants : deux NAT Gateways dans la meme AZ par erreur de configuration manuelle.
• Security groups trop permissifs : un group avec 0.0.0.0/0 sur le port 5432 (PostgreSQL ouvert au monde).

Bilan : 19% d'economies sur la facture mensuelle, et des failles de securite corrigees. Cet audit a finance l'integralite de la mission d'automatisation.

Multi-cloud : l'abstraction necessaire

Chez Bloomflow, on operait sur trois providers : AWS (production principale), Outscale SecNumCloud (exigence DGE), et OVH Cloud (workloads specifiques). L'automatisation multi-cloud impose une discipline d'abstraction :

Les modules Terraform generiques couvrent les concepts communs (reseau, compute, stockage) avec des variables qui s'adaptent au provider. Les modules specifiques gerent les fonctionnalites propres a chaque cloud (IAM AWS, policies Outscale, VRack OVH). Le state Terraform est stocke dans un backend S3 avec DynamoDB pour le locking. Ce locking est critique : j'ai vu des equipes perdre des heures a diagnostiquer un state corrompu parce que deux personnes appliquaient du Terraform simultanement.

GitOps infra : le dernier kilometre

L'automatisation atteint sa maturite quand elle devient GitOps. Chez Padam Mobility, chaque modification d'infrastructure passait par une pull request Terraform. Le workflow CI affichait automatiquement le terraform plan dans la PR. Un reviewer validait les changements proposes. Le terraform apply ne se declenchait qu'apres merge et approbation.

Cette approche offre une tracabilite complete : qui a change quoi, quand, pourquoi, et avec quelle approbation. Elle elimine aussi les modifications sauvages en console. Chez Bloomflow, cette discipline a ete un argument decisif lors de l'audit ISO 27001 : chaque changement d'infrastructure etait documente automatiquement dans l'historique Git.

Conclusion

L'automatisation des infrastructures cloud n'est pas un projet, c'est une discipline permanente. Terraform pour le provisionning, Ansible pour la configuration, et une approche GitOps pour la gouvernance forment le trio gagnant. Commencez par un audit de l'existant, codez progressivement, et ne tolerez plus jamais de clics en console pour la production. Le retour sur investissement est rapide, mesurable, et durable.