Bâtir des plateformes DevOps résilientes

Pourquoi ce livre ?

Construire, tester et défendre des plateformes capables de tenir en conditions réelles.

Ce que tu vas parcourir

1. ·Avant-propos
2. ·Introduction
3. ·Fondamentaux : le vocabulaire et les concepts avant de commencer

   • 0.1 Qu'est-ce que le DevOps, au juste ?
   • 0.2 Le code source et Git : la brique de base
   • 0.3 Les conteneurs : empaqueter une application pour qu'elle tourne partout
   • 0.4 Kubernetes : orchestrer des conteneurs à grande échelle
   • 0.5 CI/CD : automatiser build, test et déploiement
   • 0.6 Le cloud et l'Infrastructure as Code
   • 0.7 Une carte pour la suite du livre
4. 01Construire le socle : une plateforme CI/CD industrialisée

   • 1.1 Le contexte : livrer vite sans sacrifier la qualité
   • 1.2 Architecture cible
   • 1.3 La chaîne CI/CD, étape par étape
   • 1.4 Fiabiliser les livraisons : la pyramide de tests
   • 1.5 Authentification centralisée et gestion des secrets
   • 1.6 Erreurs classiques observées en production
   • 1.7 Vers le déploiement continu : GitOps comme évolution naturelle
   • 1.8 Dérouler la chaîne en conditions réelles
   • 1.9 Observabilité : ce que montrent réellement les dashboards
   • 1.10 Bilan chiffré
   • Labo pratique 1 — Reproduire un socle CI/CD minimal en local
   • Labo pratique 2 — Vérifier une politique Vault/LDAP de bout en bout
5. 02Reprise d'activité et haute disponibilité en environnement hybride

   • 2.1 Le contexte : une contrainte qui ne se négocie pas
   • 2.2 Architecture cible : un site actif, un site de secours au repos
   • 2.3 Provisionnement et bootstrap automatisés
   • 2.4 Sauvegardes et intégrité des données
   • 2.5 GitOps et bascule automatisée
   • 2.6 Observabilité du site de secours : que surveiller quand rien ne tourne ?
   • 2.7 Dérouler un exercice de bascule réel
   • 2.8 Actif-actif ou actif-passif : un arbitrage FinOps autant que technique
   • 2.9 La sécurité du site de secours n'est pas une option différée
   • 2.10 Bilan chiffré
   • Labo pratique 1 — Simuler une bascule active/passive avec deux clusters locaux
   • Labo pratique 2 — Mesurer un RTO réel
6. 03FinOps : maîtriser la facture cloud avant qu'elle ne dérive

   • 3.1 Le contexte : une facture qui dérive silencieusement
   • 3.2 Le double mécanisme : proactif et réactif
   • 3.3 Le mécanisme proactif en détail
   • 3.4 Le mécanisme réactif : une fonction de gouvernance
   • 3.5 L'attribution des coûts : le tagging comme prérequis
   • 3.6 Étude comparative chiffrée : revisiter l'arbitrage actif-actif / actif-passif
   • 3.7 Rightsizing : la correction la plus simple, la plus souvent négligée
   • 3.8 Autres erreurs classiques observées
   • 3.9 FinOps et Green IT : deux disciplines liées
   • 3.10 Bilan chiffré
   • Labo pratique 1 — Générer un rapport de coût Infracost sur un projet Terraform local
   • Labo pratique 2 — Simuler le mécanisme réactif sans compte cloud
7. 04Sécurité « zero secret » et gestion des identités

   • 4.1 Le contexte : ce que coûte réellement une fuite
   • 4.2 Le principe zero secret, du commit au runtime
   • 4.3 Défense en profondeur : quatre couches de scan complémentaires
   • 4.4 Rotation et secrets dynamiques
   • 4.5 Le principe du moindre privilège, appliqué systématiquement
   • 4.6 Étude de cas approfondie : la fuite de kubeconfig
   • 4.7 Sécuriser la chaîne CI elle-même
   • 4.8 RGPD et hébergement de données sensibles : ce que « conforme » veut dire concrètement
   • 4.9 Bilan chiffré
   • Labo pratique 1 — Générer un secret dynamique Vault avec expiration
   • Labo pratique 2 — Détecter et purger un secret accidentellement commité
8. 05Sobriété énergétique : mesurer avant d'optimiser

   • 5.1 Le contexte : le piège du monitoring trop lourd
   • 5.2 Trois niveaux de mesure, du plus grossier au plus précis
   • 5.3 Instrumentation légère : Telegraf et InfluxDB
   • 5.4 Mesurer au niveau du pod : attribution fine avec Kepler
   • 5.5 Convertir en CO2 : la formule et ses limites
   • 5.6 Erreur classique : sur-instrumenter au détriment de la charge utile
   • 5.7 Rightsizing énergétique : le même geste, une motivation double
   • 5.8 Au-delà de l'infrastructure : l'écoconception logicielle
   • 5.9 Bilan chiffré
   • Labo pratique 1 — Comparer la charge de deux dispositifs de supervision
   • Labo pratique 2 — Estimer une empreinte carbone à partir d'une mesure système
9. 06Observabilité multi-cluster et culture de l'incident

   • 6.1 Le contexte : des îlots de supervision qui ne se parlent pas
   • 6.2 Les trois piliers, mis à l'échelle
   • 6.3 Fédérer les métriques sans perdre la granularité locale
   • 6.4 Centraliser les logs sans les noyer
   • 6.5 Suivre une requête à travers plusieurs services : le tracing distribué
   • 6.6 Deux grilles de lecture complémentaires : RED et USE
   • 6.7 SLI, SLO et le budget d'erreur
   • 6.8 La culture de l'incident : documenter comme un actif, pas comme un aveu
   • 6.9 Bilan chiffré
   • Labo pratique 1 — Fédérer deux Prometheus locaux via remote-write
   • Labo pratique 2 — Rédiger un post-mortem à partir d'un incident simulé
10. 07Kubernetes multi-tenant et Platform Engineering

    • 7.1 Le contexte : un cluster qui devient un goulot d'étranglement humain
    • 7.2 Deux philosophies du multi-tenant : cluster par équipe ou namespace par équipe
    • 7.3 Architecture cible : le namespace comme unité de self-service
    • 7.4 Le portail self-service : automatiser la création d'environnement
    • 7.5 Erreur classique — Le namespace fantôme jamais nettoyé
    • 7.6 Bilan chiffré
    • Labo pratique — Créer un namespace self-service avec quota, réseau et RBAC
11. 08Sécurité des conteneurs et supply chain logicielle

    • 8.1 Le contexte : une CVE critique, et personne ne sait où elle vit
    • 8.2 Trois questions que la sécurité conteneurs doit pouvoir trancher instantanément
    • 8.3 Le SBOM : un inventaire vérifiable plutôt qu'une confiance implicite
    • 8.4 Signer une image : garantir sa provenance, pas seulement son contenu
    • 8.5 Bloquer à l'admission ce qui n'est pas signé
    • 8.6 Rescan continu : traiter la découverte d'une CVE comme un événement, pas une date de build
    • 8.7 Erreur classique — Le registre qui accumule des images jamais nettoyées
    • 8.8 Bilan chiffré
    • Labo pratique — Générer un SBOM, signer une image et vérifier sa provenance
12. 09Chaos Engineering et résilience applicative

    • 9.1 Le contexte : un site de secours validé, une panne que personne n'avait imaginée
    • 9.2 La boucle expérimentale : formuler une hypothèse avant d'agir
    • 9.3 Maîtriser le rayon d'impact avant toute injection
    • 9.4 Dégradation gracieuse : le disjoncteur applicatif
    • 9.5 Les Game Days : institutionnaliser l'expérience plutôt que la répéter au hasard
    • 9.6 Erreur classique n° 2 — Le Game Day sans audience
    • 9.7 Bilan chiffré
    • Labo pratique 1 — Injecter une panne de pod avec Chaos Mesh
    • Labo pratique 2 — Observer un disjoncteur applicatif se déclencher sous latence injectée
13. 10Bases de données en environnement DevOps

    • 10.1 Le contexte : un déploiement applicatif ordinaire, une base de données qui se fige
    • 10.2 Migrations versionnées : traiter le schéma comme du code
    • 10.3 Le pattern expand/contract : changer un schéma sans jamais bloquer les écritures
    • 10.4 Réplication et bascule : la base de données face au Chapitre 2
    • 10.5 Sauvegardes automatisées et testées : au-delà de la réplication
    • 10.6 Erreur classique — La migration destructive sans plan de retour arrière
    • 10.7 Bilan chiffré
    • Labo pratique 1 — Appliquer une migration expand/contract avec Flyway
    • Labo pratique 2 — Automatiser et vérifier une sauvegarde
14. 11Compliance-as-code et gouvernance

    • 11.1 Le contexte : un audit qui prend six semaines pour répondre à une question simple
    • 11.2 Trois familles de règles, un même principe : vérifier avant d'appliquer
    • 11.3 Vérifier avant de provisionner : Conftest sur le plan Terraform
    • 11.4 Vérifier en continu : Gatekeeper sur le cluster
    • 11.5 Produire la preuve : le rapport de conformité comme artefact généré, pas rédigé
    • 11.6 Bilan chiffré
    • Labo pratique — Bloquer un plan Terraform non conforme avec Conftest
15. 12Architecture multi-cloud et portabilité

    • 12.1 Le contexte : un fournisseur unique, une facture qui devient un levier de négociation à sens unique
    • 12.2 Un arbitrage explicite, jamais un dogme du « tout portable »
    • 12.3 La couche d'orchestration : Kubernetes comme dénominateur commun
    • 12.4 Les services managés propriétaires : un choix assumé, pas une fatalité
    • 12.5 La donnée : le véritable verrou, plus que le calcul
    • 12.6 Erreur classique — La portabilité de façade
    • 12.7 Bilan chiffré
    • Labo pratique — Déployer un cluster identique sur deux implémentations différentes
16. 13Edge Computing et déploiements distribués

    • 13.1 Le contexte : un déploiement qui suppose une connexion permanente qui n'existe pas
    • 13.2 Repenser GitOps pour une connectivité intermittente
    • 13.3 K3s : un Kubernetes allégé pour des sites aux ressources limitées
    • 13.4 Tamponner les données en cas de coupure : la file d'événements locale
    • 13.5 Erreur classique — Le déploiement identique poussé simultanément sur tous les sites
    • 13.6 Bilan chiffré
    • Labo pratique — Simuler une coupure réseau et observer la reprise de synchronisation
17. 14Feature flags et delivery progressive avancée

    • 14.1 Le contexte : un rollback qui exige un nouveau déploiement, pas un simple interrupteur
    • 14.2 Le principe : un interrupteur, pas un redéploiement
    • 14.3 Cibler l'activation : segments, pourcentages, listes explicites
    • 14.4 Le test A/B : le feature flag comme outil de décision, pas seulement de sécurité
    • 14.5 Erreur classique — La dette de drapeaux jamais nettoyée
    • 14.6 Bilan chiffré
    • Labo pratique — Activer, cibler puis désactiver une fonctionnalité sans redéploiement
18. ·Conclusion — Ce que ces cas ont en commun
19. AGlossaire
20. BGrille de maturité détaillée
21. CRessources et outils cités