Skip to main content

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
Lis l’article complet pour voir comment.

Table des Matières


Les Principes Fondateurs

Avant de coder, j’ai défini trois principes non-négociables:
  1. Zéro Euro/mois → Respect strict du Free Tier AWS
  2. Infrastructure as Code → Tout en Terraform, rien à la main
  3. Zero-Trust Security → Pas de clés d’accès longue durée
Ces trois piliers ont guidé chaque décision technique.

É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

Ma première idée fut de déployer un site sur Kubernetes (EKS) ou Docker (ECS/Fargate). Après tout, c’est une techno que je maîtrise. Mais arrêt. Réflexion. KISS Principle (Keep It Simple, Stupid).

Analyse Comparative

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
Une approche DevOps pragmatique, c’est de choisir la techno qui résout le problème avec le moins de friction, pas forcément la plus complexe.

É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.
  1. Commit Code → Je pousse mon code sur main
  2. Trigger Workflow → GitHub Actions lance automatiquement
  3. Terraform Plan → Analyse les changements d’infrastructure
  4. Terraform Apply → Crée/modifie les ressources AWS
  5. Build Statique → Astro génère le site (HTML optimisé)
  6. S3 Sync → Upload le site sur le bucket
  7. 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:
  1. Créer un utilisateur IAM sur AWS
  2. Générer des clés (Access Key + Secret Key)
  3. Copier/coller ces clés dans GitHub “Secrets”
  4. Problème: Ces clés sont “longue durée” (ne changent jamais)
  5. Problème: Une fuite = accès complet pendant longtemps
  6. 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:
  1. GitHub Actions demande un “OIDC Token” à GitHub
  2. Le token contient: identité du repo, branche, workflow…
  3. GitHub envoie le token à AWS
  4. AWS vérifie la signature et l’origine
  5. AWS délivre des credentials temporaires (1h max)
  6. Pas de clés à gérer
  7. 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
C’est le standard des meilleures pratiques 2025.

É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:
  1. Compression Agressive
    • Images: Conversion WebP (80% de réduction)
    • CSS/JS: Minification + gzip
    • HTML: Générés par Astro (zéro bloat)
  2. Cache Strategy
  1. 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 (2550/mois)ouPingdom(25-50/mois) ou Pingdom (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

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 minimal

Challenge #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:
Solution: Unlock manuel (avec prudence)
Leçon: Toujours avoir un protocole pour briser le lock en cas d’urgence.

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

Leçons Techniques

  1. 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
  2. Security by Default
    • OIDC > Clés longue-durée
    • Least privilege = policy minimaliste
    • Audit trail = chaque action enregistrée
  3. 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
  4. Automation Everything
    • La CI/CD doit être le single source of truth
    • Jamais de modifications manuelles en production
    • Tests = assurance qualité automatique
  5. 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é


Conclusion: Mon approche du DevOps

Beaucoup de gens associent DevOps à “complexité”. Kubernetes, Microservices, Docker, ArgoCD… Pour moi, l’essentiel 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
Voilà l’essence du bon DevOps: faire plus avec moins, en restant lucide sur les vrais besoins.

Quick Start (5 min)

Copier/coller pour démarrer immédiatement:
Résultat: Infrastructure + site live en ~10 min

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 raisonne l’architecture. Pas de buzzwords, des choix expliqués et un retour concret sur l’implémentation.

Pour les Développeurs

Reproduire ce setup:
  1. Clone le repo: github.com/YOUR_USERNAME/YOUR_REPO_NAME
  2. Adapte les variables (domaine, email, etc)
  3. Crée ton AWS Free Tier
  4. Modifie les tests Playwright pour ton domaine
  5. 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


Dernière mise à jour: Janvier 2025
Portfolio DevOps v1.0 - Zero Cost, Production-Ready