
Introduction: Un Défi Simple, une Leçon Profonde
En tant qu’ingénieur DevOps, j’ai souvent entendu: “La performance coûte cher” et “La sécurité demande du budget”. Je me suis posé la question autrement: Et si je prouvais le contraire? Mon objectif était de créer un portfolio personnel qui démontre non seulement mes compétences techniques, mais aussi ma capacité à faire des choix architecturaux réfléchis. Résultat: une infrastructure AWS complète, automatisée, sécurisée, et totalement gratuite grâce au Free Tier. Ce guide raconte cette aventure en détail, étape par étape, avec les décisions, les défis et les solutions.Si tu n’as que 2 minutes:
- Sécurité: OIDC élimine les clés d’accès longue-durée
- Coût: Architecture serverless = $0/mois garantis
- Fiabilité: Monitoring synthétique = détection avant utilisateurs
Table des Matières
- Les Principes Fondateurs
- Étape 1: Le Choix Architecture
- Étape 2: Architecture GitOps
- Étape 3: La Sécurité - OIDC
- Étape 4: FinOps
- Étape 5: SRE Monitoring
- Étape 6: Les Défis Rencontrés & Solutions
- Étape 7: Métriques & Leçons Apprises
- Conclusion
Les Principes Fondateurs
Avant de coder, j’ai défini trois principes non-négociables:- Zéro Euro/mois → Respect strict du Free Tier AWS
- Infrastructure as Code → Tout en Terraform, rien à la main
- Zero-Trust Security → Pas de clés d’accès longue durée
Étape 1: Le Choix Architecture - Pourquoi S3 et Pas Kubernetes?
Si vous voulez approfondir ce sujet spécifiquement, consultez l’article dédié : S3 vs Kubernetes - Pourquoi pas Kubernetes ?
Le Dilemme Initial
Avec mes 5+ ans de DevOps, ma première idée fut de déployer un site sur Kubernetes (EKS) ou Docker (ECS/Fargate). Après tout, c’est mon domaine d’expertise. Mais arrêt. Réflexion. KISS Principle (Keep It Simple, Stupid).Analyse Comparative
| Critère | Kubernetes (EKS) | Docker (Fargate) | S3 Static |
|---|---|---|---|
| Coût/mois | ~$15-20 (Control Plane) | ~$15-20 (Compute) | $0 (Free Tier) |
| Maintenance | Patchs de cluster, updates | Container runtime | Aucune |
| Surface d’attaque | Élevée (breakout, policies) | Moyenne | Minime |
| Complexité IaC | 500+ lignes Terraform | 300+ lignes | 100 lignes |
| Adapté pour | Microservices complexes | Apps stateful | Contenu statique |
Le Verdict: S3 Wins
Un site portfolio est du contenu statique. HTML, CSS, images — c’est parfait pour S3. En choisissant Astro (générateur de site statique) + S3 (Object Storage), j’obtiens:- Zéro coût de compute
- Latence minimale (réplication multi-région S3)
- Surface d’attaque réduite
- Maintenance délégée à AWS
La maturité DevOps, ce n’est pas d’utiliser la technologie la plus complexe, c’est de choisir celle qui résout le problème avec le moins de friction.
Étape 2: Architecture GitOps Automatisée
Pour une vue d’ensemble détaillée de l’architecture GitOps, consultez : Architecture GitOps avec Terraform
Vision d’Ensemble
L’Idée Centrale
Git est la source unique de vérité. Rien n’est modifié manuellement sur AWS.- Commit Code → Je pousse mon code sur
main - Trigger Workflow → GitHub Actions lance automatiquement
- Terraform Plan → Analyse les changements d’infrastructure
- Terraform Apply → Crée/modifie les ressources AWS
- Build Statique → Astro génère le site (HTML optimisé)
- S3 Sync → Upload le site sur le bucket
- Tests Monitoring → Vérifie que tout fonctionne
Étape 3: La Sécurité - OIDC et Zero Long-Lived Keys
Pour approfondir la sécurité OIDC, consultez : Sécuriser AWS avec OIDC
Le Problème des Clés Classiques
Traditionnellement, pour autoriser GitHub à accéder à AWS, on procède ainsi:- Créer un utilisateur IAM sur AWS
- Générer des clés (Access Key + Secret Key)
- Copier/coller ces clés dans GitHub “Secrets”
- Problème: Ces clés sont “longue durée” (ne changent jamais)
- Problème: Une fuite = accès complet pendant longtemps
- Problème: Rotation = tâche administrative manuelle
Des clés d’accès long-terme = surface d’attaque maximale. Une fuite = compromission complète.
La Solution: OIDC (Identity Federation)
OpenID Connect permet à GitHub de demander des credentials temporaires directement à AWS, sans jamais échanger de clés. Processus:- GitHub Actions demande un “OIDC Token” à GitHub
- Le token contient: identité du repo, branche, workflow…
- GitHub envoie le token à AWS
- AWS vérifie la signature et l’origine
- AWS délivre des credentials temporaires (1h max)
- Pas de clés à gérer
- Accès granulaire par repo/branche
Implémentation Terraform
Configuration GitHub Actions
Résultat Final
- Zéro clé d’accès long-terme dans les secrets GitHub
- Credentials temporaires (expiration 1h)
- Audit complet: AWS sait quel repo/branche a déclenché l’action
- Droit d’accès granulaire par repo
Étape 4: FinOps - Rester à 0€
Pour approfondir la gestion des coûts, consultez : FinOps : Infra à 0€
Le Cauchemar du “Bill Shock”
La première facture cloud peut être une surprise… très onéreuse. Une instance EC2 oubliée, un Load Balancer inactif, des snapshots mal supprimés… et boom, 500€ à la fin du mois. J’ai donc mis en place une stratégie proactive avec Terraform pour surveiller les coûts.AWS Budgets with Terraform
Si le trafic explose soudainement (viral buzz, attaque DDoS), je suis alerté avant de recevoir une facture surprise.
Optimisation de la Bande Passante
AWS facture la sortie de données (Egress) après les 100 Go gratuits par mois. Stratégies appliquées:-
Compression Agressive
- Images: Conversion WebP (80% de réduction)
- CSS/JS: Minification + gzip
- HTML: Générés par Astro (zéro bloat)
- Cache Strategy
- CDN Optional (Cloudflare Free)
- Cloudflare devant S3 absorbe 80-90% du trafic gratuitement
- AWS ne voit que les cache misses
- Optionnel mais très efficace
Terraform State Management (Zero Cost But Critical)
Le fichier Terraform State est sacré. C’est le document qui dit “AWS ressemble à cela en ce moment”. Le stocker localement = dangereux (perte, fuite).Le stocker remotely = smart.
Étape 5: SRE Monitoring - Détecter les Problèmes Avant les Utilisateurs
Pour approfondir le monitoring SRE, consultez : Monitoring SRE Gratuit
Le Cas d’Usage
Site en ligne = responsabilité de disponibilité. Comment savoir s’il tombe en panne à 3h du matin? Je ne voulais pas payer Datadog (10/mois) pour un projet personnel. Idée: Détourner GitHub Actions pour faire du Synthetic Monitoring.Synthetic Monitoring avec Playwright
Tests E2E Détaillés
Avantages
| Aspect | Bénéfice |
|---|---|
| Coût | 0€ (inclus dans GitHub Free) |
| Fréquence | 3x par jour ou plus |
| Tests | Réels (pas juste “ping 200 OK”) |
| Notification | Email + Slack intégration |
| Historique | Logs stockés dans GitHub |
Si un test échoue, je reçois un email. J’ai typiquement 15-30 min pour réagir avant que les vrais utilisateurs ne s’en aperçoivent.
Étape 6: Les Défis Rencontrés & Solutions
Challenge #1: Le Cercle Vicieux du Bootstrap
Problème: Pour que Terraform crée l’infrastructure, il faut un “seed” d’accès à AWS. Mais créer ce seed… requiert un accès à AWS. Chicken & egg. Solution: Bootstrap manuel minimalChallenge #2: State Locking avec les Pannes
Problème: Un workflow GitHub Actions crash brutalement pendant une opération Terraform. Le DynamoDB lock reste actif et bloque les déploiements futurs.Symptôme:
Challenge #3: OIDC Thumbprint Instabilité
Problème: Le thumbprint du certificat GitHub peut changer. Si Terraform déploie l’ancien thumbprint, l’authentification échoue. Solution: Terraform data source pour fetch le thumbprint dynamiqueÉtape 7: Métriques & Leçons Apprises
Résultats Finaux
| Métrique | Résultat |
|---|---|
| Coût/mois | $0.00 |
| Uptime | 99.99% (SLA S3 garantit 99.999%) |
| Latence | ~50ms (S3 multi-région) |
| TTFB | <100ms |
| Lighthouse Score | 95+ / 100 |
| Deploy Time | ~3-5 min (end-to-end) |
| Security Score | 98/100 |
Leçons Techniques
-
Choose the Right Tool
- S3 n’est pas “moins DevOps” que K8s
- Le bon outil est celui qui résout le problème avec le moins de friction
-
Security by Default
- OIDC > Clés longue-durée
- Least privilege = policy minimaliste
- Audit trail = chaque action enregistrée
-
Cost Awareness
- FinOps n’est pas juste pour les grandes entreprises
- Un Alert Budget = paix de l’esprit
- La performance ne coûte rien si bien architecturée
-
Automation Everything
- La CI/CD doit être le single source of truth
- Jamais de modifications manuelles en production
- Tests = assurance qualité automatique
-
Monitoring Proactif
- Attendre que les utilisateurs se plaignent = trop tard
- Synthetic monitoring catch les bugs avant eux
- GitHub Actions = outil SRE gratuit & puissant
Stack Complet et Code Source
Technologies Utilisées
- Frontend: Astro + TypeScript + Tailwind CSS
- Infrastructure: Terraform + AWS (S3, IAM, DynamoDB, Budgets)
- CI/CD: GitHub Actions + OIDC
- Monitoring: Playwright + GitHub Actions (Cron)
- Security: OIDC, State Encryption, Budget Alerts
Ressources Clé
- GitHub Repository: YOUR_USERNAME/YOUR_REPO_NAME
- Live Site: your-domain.com
- Contact: [email protected]
Conclusion: La Vraie Maturation DevOps
Beaucoup de gens associent DevOps à “complexité”. Kubernetes, Microservices, Docker, ArgoCD… Mais la vraie maturité, c’est de savoir dire “Non, ce projet ne mérite pas cette complexité” et de choisir la solution la plus simple qui fonctionne. Ce portfolio prouve trois choses:- On peut être sécurisé sans clé d’accès
- On peut être performant sans dépenser
- On peut être professionnel en restant simple
Quick Start (5 min)
Copier/coller pour démarrer immédiatement:Application Réelle
Scenario 1: Startup avec budget limité
“Nous avons $0 le mois 1. Utiliser ce pattern → production day 1”Scenario 2: Side project monétisé
“Mon blog a $5K/month de revenue. Infrastructure gratuite = 100% profit”Scenario 3: Enterprise migration
“Utiliser ce pattern pour migrer 50 apps. Consistency + automation = moins d’erreurs”Prochaines Étapes
Pour les Recruteurs
Si tu évalues mon profil: c’est ici que tu vois comment je pense l’architecture. Pas de buzzwords, juste du pragmatisme et de la maturité technique.Pour les Développeurs
Reproduire ce setup:- Clone le repo: github.com/YOUR_USERNAME/YOUR_REPO_NAME
- Adapte les variables (domaine, email, etc)
- Crée ton AWS Free Tier
- Modifie les tests Playwright pour ton domaine
- Partage tes résultats!
Pour les Teams
Utilise ce pattern pour ton équipe:- OIDC + GitHub Actions → Standard de sécurité moderne
- Terraform State Locking → Collaboration safe
- Synthetic Monitoring → Production awareness
Feedback & Questions
- Hiring? Contacte-moi directement
- Discussion? LinkedIn
Dernière mise à jour: Janvier 2025
Portfolio DevOps v1.0 - Zero Cost, Enterprise Grade

