Refonte modulaire d'une infra Terraform multi-cloud
+30modules Terraform consolidés
L'infra Terraform d'une plateforme IA en production était devenue un bloc monolithique, lourd à faire évoluer.
Je l'ai redécoupée en modules réutilisables et porté moi-même une douzaine de composants (Kubernetes, VPC, bases de données, observabilité) sur AWS, GCP et Scaleway.
Chaque brique évolue désormais de son côté, sans risquer d'en casser une autre.
La sécurité est posée par les mêmes modules que le reste : réseau privé, rôles IAM dédiés et droits au plus juste pour chaque environnement, plutôt qu'une couche ajoutée après coup.
Le chemin de destruction est distinct du chemin de création et repasse par le plan de contrôle : rien ne disparaît par effet de bord.
Refondre une infra critique fait peur tant qu'on ne peut pas prouver que rien ne bouge.
J'ai contribué à un script (Bash + pipeline Jenkins) qui compare le plan Terraform de deux branches, diff des resource_changes stage par stage, avec choix de l'environnement à la volée.
De quoi valider une migration sans la déployer à l'aveugle.
Tester au plus près de la prod imposait des données réalistes, sans jamais exposer de données clients.
J'ai écrit un script (Docker + Bash) qui copie la base RDS de prod vers les environnements de test en l'anonymisant au passage ; infra provisionnée en Terraform (rôles IAM stricts) et exécutée via GitHub Actions.
Les environnements de test reflètent fidèlement la prod, ce qui fiabilise la reproduction de bugs, sans risque sur la confidentialité.
Les notes de version se rédigeaient à la main et l'équipe produit découvrait les livraisons en retard.
Sur chaque merge vers main, un pipeline Jenkins lit l'historique Git, génère le changelog, met à jour la page de release via l'API Notion et notifie le canal Slack produit.
Plus personne n'a à y penser, et tout le monde sait ce qui est parti en prod.
Les accès aux bases RDS devaient être contrôlés et tracés, sans laisser d'accès permanents ouverts.
J'ai construit un système d'approbation dynamique via Slack, appuyé sur AWS SSM, Lambda, CloudTrail et EventBridge, avec des connexions sécurisées par tunnels SSH/VPN et authentification SSO.
Chaque demande est validée, surveillée en temps réel (CloudWatch, New Relic) et laisse une trace complète.
Diagnostiquer un incident obligeait à sauter d'un outil à l'autre.
J'ai centralisé les métriques (collectées par Prometheus, visualisées dans Grafana) et les logs (OpenObserve), avec des alertes Slack contextualisées qui renvoient directement vers le runbook concerné.
On lit l'état des instances en temps réel et on remonte à la cause bien plus vite.
StackPrometheus · Grafana · OpenObserve · Slack
Monitoring full-stack avec New Relic
Peu de visibilité temps réel sur la santé de l'infra AWS et des applications.
J'ai intégré New Relic de bout en bout : agent infra sur ECS, APM sur EC2, Browser agent côté front, relié aux services AWS (RDS, ECS) par API.
Dashboards et alertes temps réel (CPU, mémoire, perf BDD) poussés dans Slack, pour repérer et traiter les incidents plus vite.
Personne ne savait vraiment d'où venait la facture cloud.
J'ai construit un tableau de bord qui interroge AWS Cost Explorer, agrège les données en Python et les restitue dans Grafana, avec des alertes quand la consommation par service ou par équipe dérape.
Il a surtout servi à débusquer les ressources orphelines et les snapshots oubliés qu'on payait sans le savoir.
StackAWS Cost Explorer · Python · Grafana
Open source · GitHub
Projets open source
Des projets personnels dont le code est public, du FinOps aux agents IA.
wasteless.io
Mon projet de référence en FinOps, open source et auto-hébergé : rendre le gaspillage AWS visible avant qu'il n'arrive sur la facture.
Neuf familles de détecteurs — EC2 et RDS inactifs, volumes EBS orphelins, IP élastiques, snapshots et AMI oubliés, load balancers, passerelles NAT et VPC inutilisés, gp2 à migrer en gp3. Chaque recommandation porte sa preuve, un indice de confiance et un coût mensuel estimé.
Sûr par construction : la collecte passe par un rôle IAM en lecture seule, toute écriture exige un second rôle optionnel et échoue en son absence, et le mode simulation est actif par défaut.
Boucle fermée : trois chemins d'exécution — action AWS directe, pull request Terraform ou tâche manuelle — puis vérification. Un suivi Cost Explorer confirme l'économie réelle une fois sept jours de facturation écoulés.
Trier une boîte mail à la main est répétitif et chronophage.
Cinq agents Python, orchestrés derrière une API FastAPI, se passent le relais sur la boîte Gmail : lecture et classement des messages, rédaction d'une réponse, validation avant l'envoi.
Un terrain d'expérimentation pour orchestrer plusieurs agents autour d'une tâche concrète.
StackPython · FastAPI · Gmail API · React · Docker