Chaos & Platform Engineering : transformer l’incertitude en sérénité opérationnelle

^{Cet article est tiré de la conférence de Christophe Rochefolle à l'Alenia Production Tour 2025.}

‍

‍

Et si on cessait d’espérer « zéro incident » pour apprendre à bien les traverser ?

Chaque DSI l’a vécu : malgré les projets, les process et les runbooks, l’incident finit toujours par arriver. La question n’est plus “peut-on l’éviter ?”, mais “sommes-nous prêts quand il surviendra ?”.

Lors de l’Alenia Production Tour, Christophe Rochefolle Randrianandrasana (fondateur de Caos Management) a livré une thèse forte : on développe la sérénité en pratiquant le chaos, et on industrialise la robustesse via le Platform Engineering et une observabilité moderne.

L’objectif n’est pas de créer du désordre, mais d’installer une capacité collective à voir, encaisser, décider et repartir.

Le coût réel des pannes : cinq minutes valent 700 000 €

L’argument économique est imparable : pour les 2 000 plus grandes entreprises mondiales, l’impact annuel des indisponibilités atteindrait environ 400 milliards.

Exemples : Meta a perdu ~100 M$ pour 2 h de perturbation (2024) ; Amazon ~34 M$ pour 1 h (2021) ; au pic du 11/11, Alibaba pourrait perdre 26,5 Md$ en 20 min de panne. Et pour ceux qui relativisent “5 minutes”, traduisez-les en ~700 000 € : d’un coup, tout le monde comprend qu’il s’agit d’un sujet business avant d’être technique.

Les quatre visages des incidents : ce que la « fenêtre de Johari » nous apprend

Pour sortir d’une approche naïve des incidents, Christophe mobilise la fenêtre de Johari :

• Connu de tous / connu de moi : exemple Equifax (vulnérabilité publique, patch tardif) → catastrophe évitable.
• Connu de certains / aveugle pour moi : SolarWinds (chaîne d’update contaminée) → aveuglement lourd de conséquences.
• Connu de moi / caché aux autres : Yahoo 2013 (breach dissimulé jusqu’à la vente à Verizon) → perte de valeur de 350 M$ lors de l’acquisition.
• Inconnu de tous : Crisis “CrowdStrike/Microsoft” et panne Google Cloud déclenchées par des mises à jour cœur mal testées / sans feature flag → effondrement mondial transitoire.

Morale : il y aura des incidents. La seule stratégie rationnelle consiste à mieux les gérer.

Du simple au chaotique : agir d’abord, comprendre ensuite

Autre cadre mobilisé par le conférencier : la distinction entre simple, compliqué, complexe et chaotique.

En chaos, les recettes “best practices” ne suffisent plus : il faut agir pour revenir vers un domaine complexe où l’on peut à nouveau observer et apprendre. Chercher à “revenir au simple” est un mirage ; l’enjeu est de stabiliser dans la complexité.

Robuste plutôt que seulement résilient : cinq leviers inspirés du vivant

Christophe propose de viser la robustesse : stable à court terme, viable à long terme malgré les fluctuations. Pour y parvenir, il transpose cinq principes biologiques à nos SI :

• Redondance : comme deux reins → backups hors-ligne/immutables, architectures distribuées, bascules automatiques.
• Modularité : comme le corail qui éjecte un polype infecté → compartimenter pour isoler l’avarie (micro-services, Kubernetes).
• Plasticité : comme l’arbre qui renforce ses racines au vent → plans B/C, bascule manuelle, changement de fournisseur.
• Acceptation du stress / entraînement : muscler systèmes et équipes par la pratique (chaos engineering).
• Workaround mode : plusieurs chemins pour un même résultat (bypass, feature flags, dégradations contrôlées).

Ces analogies ne sont pas décoratives : elles structurent une ingénierie de la robustesse “by design”.

Chiffrer pour décider (et convaincre le CFO)

On ne finance pas des “exercices du vendredi” sans modèle économique. Premier réflexe recommandé : calculer le prix de 5 minutes de downtime pour votre application. Ce KPI unique aligne tout le monde : CFO (arbitrages), Ops (priorités), Produit (valeur perçue).

C’est aussi l’argument-clé pour lancer une démarche chaos après (ou avant) un incident majeur : “Vous ne voulez plus que ça arrive ? Voilà le plan, voilà le ROI.

Quand l’incident coûte aussi à l’actionnaire

Le cas Yahoo illustre la partie juridico-réputationnelle : cacher un incident reporte le choc… et l’amplifie au moment d’une due diligence, d’une fusion ou d’une introduction. Les pertes de valeur et litiges associés à la dissimulation dépassent souvent le coût initial de remédiation.

Traduction opérationnelle : gouvernance claire des incidents (détection, qualification, communication, obligations), avec un périmètre légal anticipé.

Platform Engineering : la robustesse par défaut

Nos SI ne sont plus des monolithes isolés : dépendances logicielles, services tiers, API partout.

Résultat : une complexité qui explose et des équipes qu’on tente de rendre “T-shape”, puis “π-shape”… jusqu’à l’absurde. Le platform engineering répond à ce piège :

• Objectif : permettre à des équipes autonomes de développer, déployer et opérer sans devenir expertes de tous les sujets (Terraform, mesh, etc.).
• Approche produit : la plateforme est un produit vivant, avec roadmap et clients (les équipes de dev). On priorise les communs utiles à plus d’une équipe (et non “ce qui est fun” technologiquement).
• Capacités “robustesse by design” : autoscaling, isolation, sauvegardes orchestrées, feature flags natifs (pour stopper un déploiement défaillant), runbooks intégrés, tests de bascule automatisés.

Cette approche n’est pas un retour aux équipes “prod d’hier” : c’est un accélérateur de résilience au service des produits.

Observabilité : passer de “je surveille” à “je questionne”

Le monitoring répond à des questions prévues (seuils, métriques connues). En crise, les bonnes questions sont nouvelles ; il est trop tard si vous devez déployer un hotfix juste pour logger davantage. L’observabilité permet d’interroger le système sans redéploiement.

• Événements “riches” plutôt que métriques agrégées (au moins sur une fenêtre utile).
• Peu de dashboards (pour le management), mais un usage orienté investigation : établir une ligne de base et détecter les écarts (aide IA), puis creuser.
• Couverture des architectures modernes (serverless, efémère).

Référence utile : les travaux de Charity Majors sur l’observability engineering. L’idée clé : répondre vite à des questions que vous n’aviez pas imaginées hier.

Chaos Engineering : hypothèse → injection → analyse → industrialisation

« Si ce n’est pas cassé, insistez. » L’adage résume l’esprit : expérimenter pour mesurer la vraie tolérance aux pannes. La démarche proposée :

1. Formuler une hypothèse («Si la base tombe, le cache tient et l’utilisateur ne voit rien.»).
2. Définir le périmètre et les garde-fous (SLO, blast radius, fenêtres de tir).
3. Vérifier l’observabilité (peut-on voir et comprendre sans relivrer ?).
4. Injecter (kill pod/VM, latence, perte réseau, panne DC simulée…).
5. Analyser (comportement réel vs attendu, dettes révélées).
6. Industrialiser (tests récurrents : failure Fridays, game days).

Exemples cités :

• Du Chaos Monkey de Netflix à des expériences DC-level : perte simulée d’un datacenter en double-site → itérations mensuelles jusqu’à détecter vite, comprendre et basculer proprement.
• Game day multi-équipes, scoring en détection / diagnostic / résolution : un simple changement d’URL de healthcheck a fait passer un MTTR de 2 h à 10 min lorsque l’incident s’est présenté “en vrai” la semaine suivante.
• Outillage : offres SaaS (ex. Gremlin) ou open-source CNCF (Chaos Mesh, Litmus, Kube-toolkits) ; l’important n’est pas l’outil, mais la régularité.

Sérénité des équipes : entraîner, normaliser, dédramatiser

La santé mentale et la DX (developer experience) ne sont pas “annexes” : elles font lien entre plateforme et pratiques. Deux convictions :

• On s’entraîne plus qu’on éteint des feux. Comme les pompiers, la majorité du temps sert à préparer (scénarios, gestes, communication).
• On accepte le stress… à un niveau soutenable. L’ambition n’est pas de maintenir les équipes à 200 % en continu, mais d’être à 80 % au quotidien, capables de monter à 100 % en crise sans se briser.

Les game days rendent l’entraînement désirable (jeu, classement, récompense), diffusent les bons réflexes (observabilité visible, fiches réflexes), et désacralisent la crise.

Gouvernance, priorisation et “product thinking”

Quelques principes pour éviter l’“usine à outils” :

• La plateforme est un produit : découverte, priorisation par usage, feedbacks. Pas de service mesh “parce que c’est tendance” si une seule équipe en a besoin.
• Standardiser les communs, laisser respirer les spéciaux (périmètres pilotes, puis généralisation quand le besoin devient transversal).
• Mesurer (SLO/SLI), rendre visible (tableaux d’alerte, coût 5 min), raconter (post-mortems “blameless”).
• Saisir la fenêtre d’opportunité post-incident pour financer des capex de robustesse (plateforme, observabilité, chaos).

De la culture du “no incident” à la culture de la confiance éprouvée

Nous ne maîtriserons jamais toutes les causes ; nous pouvons maîtriser notre façon d’y répondre.

C’est le cœur du message : agir pour sortir du chaos, outiller pour voir venir, entraîner pour décider mieux. Les pannes majeures d’acteurs mondiaux (hyperscalers compris) nous rappellent l’évidence : la maturité se prouve en situation, pas dans une procédure.

La bonne nouvelle, c’est que cette maturité s’ingénie : platform engineering pour bâtir la robustesse, observabilité pour comprendre vite, chaos engineering pour vérifier régulièrement que tout cela tient en conditions réelles. Et, au passage, des équipes plus sereines, plus fières, plus efficaces.

Excellence is a habit. En production comme en sécurité, la différence entre subir et choisir se joue avant la crise — et se gagne par entraînement.

‍