« Ne touche pas à celui-là. » Chaque équipe a son serveur, son service, son bout d'infra qu'on traite comme un dragon endormi. Il est fragile, personne n'est tout à fait sûr de ce qui arrive s'il tombe, alors personne n'essaie de le savoir. On marche sur la pointe des pieds autour, on prie pour qu'il tienne.
Et c'est exactement celui-là qui se réveille en pleine nuit, sans prévenir, et emporte le reste avec lui. Le problème n'est pas qu'il soit fragile. Le problème, c'est que tu ne l'as jamais vu tomber dans des conditions où tu pouvais l'observer tranquillement. Il a choisi son moment. Le chaos engineering, c'est lui reprendre ce choix.
Supposer résilient n'est pas être résilient
Tu crois ton système solide. Il a des réessais, des répliques, des mécanismes de repli, tout ce qu'il faut sur le papier. Sauf que « sur le papier » et « dans la réalité » sont deux mondes, et l'écart entre les deux, c'est précisément là que vivent les incidents. Tu supposes que si une machine tombe, une autre prend le relais. Tu ne l'as jamais vérifié en conditions réelles. Tu l'espères.
Le chaos engineering renverse ça : au lieu d'attendre la panne, tu la provoques. Tu tues une machine volontairement, tu coupes une dépendance, tu ajoutes de la latence, et tu regardes comment le système réagit vraiment, pas comment tu imagines qu'il réagit. L'outil canonique, Chaos Monkey, va jusqu'à tuer des instances au hasard en production, en continu, pour que « survivre à la perte d'une machine » ne soit plus un espoir mais un fait prouvé tous les jours.
La clé, c'est le contrôle. Tu ne fous pas le feu à la maison pour voir. Tu délimites le rayon d'explosion, tu le fais en pleine journée, équipe présente, avec un bouton d'arrêt à portée de main. Tu paies un petit prix connu, maintenant, pour ne pas payer un grand prix inconnu à 3h du matin.
Le voyant rouge, c'est ta peur
La bonne nouvelle, c'est que ton système te dit déjà où il est faible. Ce serveur que personne n'ose toucher, ce déploiement qu'on repousse toujours, cette dépendance dont on parle à voix basse : cette peur est une information, pas un tabou. Elle marque exactement l'endroit que tu n'as jamais testé, donc l'endroit où l'incident t'attend. Le chaos engineering, c'est décider d'aller voir là où ça fait peur, plutôt que d'attendre que ça décide pour toi.
Ce que l'IA affirme et ne prouve pas
L'assistant écrit du code qui a l'air résilient. Il ajoute le réessai, le try/catch, le repli, parce que ce sont des motifs fréquents. Mais que l'ensemble survive vraiment à une panne, ça, aucune génération ne peut te le garantir, parce que ça ne se lit pas dans le code : ça se constate en le cassant. La machine te livre une résilience supposée. Seul le chaos la transforme en résilience vérifiée. C'est la même différence qu'entre un test qui passe et un comportement qu'on a réellement prouvé : tant que tu n'as pas coupé le courant, tu ne sais pas si le groupe électrogène démarre.
Ce que je te conseille
Fais la liste des choses que ton équipe n'ose pas toucher. Elle est courte, et c'est ta carte des dangers. Prends-en une, la moins risquée, et provoque sa panne dans un cadre maîtrisé : périmètre réduit, en journée, avec un retour arrière prêt. Tu apprendras en une heure ce qu'un incident t'aurait appris en pire, plus tard, et plus cher.
Un système que tu n'as jamais vu tomber n'est pas un système résilient. C'est un système dont tu ignores encore comment il tombe.
Ce satellite fait partie du dossier Le modèle du gruyère, sur la défense en profondeur. Le vocabulaire : le chaos engineering, la résilience et le rayon d'explosion.