Chaos Engineering

Définition

Le Chaos Engineering (ingénierie du chaos) est une discipline expérimentale consistant à injecter volontairement des pannes dans un système distribué afin d'observer son comportement réel sous contrainte et de découvrir ses points de défaillance avant qu'un incident non maîtrisé ne les révèle en production. Formalisée par Netflix à partir de 2010 avec l'outil Chaos Monkey, puis codifiée dans les Principles of Chaos Engineering, elle repose sur un postulat simple : la seule façon de prouver qu'un système est résilient est de le casser dans des conditions contrôlées.

Contrairement aux tests classiques, qui vérifient qu'un comportement attendu se produit, le Chaos Engineering cherche à invalider une hypothèse de robustesse. On ne teste pas le code, on teste le système complet : infrastructure, réseau, dépendances tierces, mécanismes de basculement, mais aussi les procédures humaines et la chaîne d'alerte.

Fonctionnement technique

Une expérience de chaos suit une méthode scientifique en cinq temps :

• Définir l'état stable (steady state) : un indicateur métier ou technique mesurable — taux de commandes par minute, latence P99, taux d'erreurs HTTP 5xx. C'est la référence contre laquelle tout sera comparé.
• Formuler une hypothèse : « si une instance sur trois du service d'authentification tombe, le taux d'erreurs reste inférieur à 0,1 % ».
• Injecter la perturbation : arrêt brutal de conteneurs, saturation CPU ou mémoire, latence réseau artificielle, perte de paquets, corruption DNS, expiration de certificat, indisponibilité d'une zone de disponibilité cloud.
• Mesurer l'écart via l'observabilité en place (métriques, traces distribuées, journaux).
• Corriger puis automatiser l'expérience pour éviter toute régression.

Le principe cardinal est celui du rayon d'action (blast radius) : on commence sur un périmètre minimal — un pod, un utilisateur canari, 1 % du trafic — avec un coupe-circuit permettant d'interrompre l'expérience instantanément si l'état stable se dégrade.

Outils de référence

• Chaos Monkey (Netflix) : termine aléatoirement des instances en production. Il fait partie de la Simian Army, qui inclut Latency Monkey (dégradation réseau) et Chaos Kong (perte d'une région AWS entière).
• LitmusChaos : projet CNCF natif Kubernetes, orchestrant des expériences déclaratives via CRD (ChaosEngine, ChaosExperiment).
• Gremlin : plateforme commerciale « Failure as a Service » avec plus de dix types d'attaques et un arrêt d'urgence centralisé.
• Chaos Mesh, AWS Fault Injection Simulator, Azure Chaos Studio et Toxiproxy pour la couche réseau applicative.

Exemples concrets

Perte d'une zone de disponibilité — On coupe le trafic vers une AZ AWS. L'expérience révèle que l'auto-scaling met onze minutes à compenser, bien au-delà du SLO de trois minutes : le seuil de déclenchement est réajusté.

Dépendance tierce lente — On injecte 5 secondes de latence sur l'API du prestataire de paiement. On découvre l'absence de timeout côté client : le pool de connexions se sature et provoque une panne en cascade sur des services non liés. Correctif : disjoncteur (circuit breaker) et repli fonctionnel.

Expiration de certificat TLS — On avance l'horloge d'un service interne. On constate que la rotation automatique échoue silencieusement et qu'aucune alerte ne remonte au SOC.

Liens avec la cybersécurité

Le Chaos Engineering dépasse la seule fiabilité et rejoint directement les préoccupations de sécurité :

• Security Chaos Engineering : injection de conditions adverses — règle de pare-feu supprimée, agent EDR désactivé, secret révoqué — pour vérifier que les contrôles de détection réagissent effectivement. C'est un complément au purple teaming et à la simulation d'adversaire (Atomic Red Team, Caldera).
• Continuité d'activité : les expériences alimentent la validation du PRA/PCA et la mesure réelle du RTO et du RPO, souvent très éloignés des valeurs théoriques documentées.
• Conformité : les réglementations NIS 2 et DORA exigent des tests de résilience opérationnelle documentés. Les rapports d'expériences de chaos constituent une preuve d'audit tangible.
• Défense en profondeur : une panne provoquée révèle fréquemment des chemins de contournement — repli non authentifié, cache servant des données périmées, journalisation interrompue — exploitables par un attaquant.
• DevSecOps : les expériences s'intègrent aux pipelines CI/CD comme des tests non fonctionnels bloquants, au même titre que le SAST ou le scan de dépendances.

Bonnes pratiques

• Ne jamais démarrer en production : maîtriser d'abord les expériences en préproduction, puis élargir progressivement.
• Disposer d'une observabilité mature avant toute injection — sans métriques fiables, une expérience produit du bruit, pas de la connaissance.
• Communiquer le calendrier aux équipes d'astreinte et au SOC pour éviter qu'une expérience soit traitée comme un incident réel, sauf lors des exercices « en aveugle » délibérés.
• Automatiser un coupe-circuit lié aux SLO et limiter la durée de chaque expérience.
• Documenter systématiquement l'hypothèse, le résultat et l'action corrective ; une expérience qui confirme l'hypothèse reste une information de valeur.
• Instaurer des GameDays réguliers, exercices collectifs où équipes dev, ops et sécurité affrontent ensemble une panne majeure simulée.