Anthony, Engineering Lead, vingt ans de code. Autodidacte : de l'usine au cybercafé, jusqu'aux systèmes que tu utilises tous les jours.


Anthony Capirchio


Un incident qui n'aurait dû concerner qu'un recoin du système finit par les toucher tous. Un petit bout se fait avoir, une entrée mal validée, un accès qui fuite, et de proche en proche, c'est l'ensemble qui est atteint. Quand on remonte le fil, la cause de départ est presque toujours ridicule au regard des dégâts. Ce qui a transformé un bobo en catastrophe, ce n'est pas la taille du trou initial. C'est que rien ne l'a empêché de se propager.

Parce que tout se faisait confiance. Une seule clé ouvrait toutes les portes, la base de données répondait à qui la sonnait, le moindre service pouvait parler à n'importe quel autre. Un système où tout communique avec tout, c'est un système où une seule brèche donne accès au tout.

## Le gruyère et l'alignement des trous

C'est là qu'entre le modèle du gruyère. Chaque protection est une tranche de fromage : un pare-feu, une authentification, une validation. Aucune n'est parfaite, chacune a ses trous. Prises isolément, ces failles ne posent pas de drame. Le désastre arrive quand les trous s'alignent d'une tranche à l'autre et forment un couloir droit, du dehors jusqu'au cœur.

La défense en profondeur, c'est empiler des couches imparfaites mais indépendantes, pour qu'un trou dans l'une soit couvert par la suivante. Le piège, c'est le mot indépendantes. Un système plat, où tout se fait confiance, ce n'est pas un empilement de tranches : c'est une pile où les trous sont déjà alignés d'avance. Une seule brèche, et le couloir est ouvert.

## Cloisonner, c'est bâtir les murs

Cloisonner, c'est isoler des zones pour qu'un problème reste là où il est né. La base de données n'est pas joignable depuis le web public : un trou dans le front n'atteint pas les données. Chaque service ne reçoit que les droits dont il a strictement besoin : un composant compromis ne peut rien faire de plus que son travail. Des identifiants séparés, des frontières réseau, des permissions au plus juste. Tout ça décide d'une seule chose : jusqu'où une brèche peut se propager avant de heurter un mur. C'est le rayon d'explosion, et le cloisonnement le raccourcit.

## Ce que l'IA relie un peu trop volontiers

Demande à un assistant de faire marcher un système, et il reliera tout à tout : c'est le chemin le plus court, celui qui produit le moins d'erreurs. Il n'ajoutera pas de lui-même une frontière de permissions ou un cloisonnement que tu n'as pas demandé, parce qu'une frontière ressemble à un obstacle, et qu'un obstacle ressemble à un bug pour une machine qui optimise le « ça marche ». Décider de ce qui ne doit surtout pas pouvoir se parler, de ce qu'un composant ne doit jamais pouvoir atteindre, ça naît d'un réflexe précis : imaginer la brèche. Et imaginer la brèche, c'est du jugement, pas de la complétion.

## Ce que je te conseille

Pars du principe que ça arrivera. Non pas « est-ce qu'on se fera avoir », mais « le jour où ce bout-là est compromis, jusqu'où l'attaquant peut-il aller depuis là ? ». Conçois pour que la réponse soit « pas bien loin ». Applique le moindre privilège par défaut : donne à chaque partie le minimum, pas le maximum confortable. Et à chaque nouvelle connexion que tu ouvres, pose la question : si ce côté tombe, qu'est-ce que ça ouvre de l'autre ?

Tu n'empêcheras jamais tous les trous. La défense en profondeur n'est pas le fantasme du mur parfait. C'est s'assurer que le jour où l'un cède, le suivant tient encore.

Ce satellite fait partie du dossier [Le modèle du gruyère](/dossier/gruyere), sur la défense en profondeur. Le vocabulaire : le [cloisonnement](/definition/segmentation), le [moindre privilège](/definition/moindre-privilege) et la [défense en profondeur](/definition/defense-en-profondeur).


Un incident qui n'aurait dû toucher qu'un coin du système les a tous emportés, parce que tout se faisait confiance : une clé ouvrait toutes les portes, la base répondait à l'internet entier. Le trou de départ était minuscule. Les dégâts, totaux. Cloisonner, c'est empêcher les trous de s'aligner.

Ce qui tombe ne doit pas tout emporter


« 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](/dossier/gruyere), sur la défense en profondeur. Le vocabulaire : le [chaos engineering](/definition/chaos-engineering), la [résilience](/definition/resilience) et le [rayon d'explosion](/definition/rayon-d-explosion).


Chaque équipe a ce serveur-là. Fragile, personne ne sait vraiment ce qui se passe s'il tombe, alors personne ne le teste. Et c'est précisément celui qui se réveille à 3h du matin. Le chaos engineering, c'est réveiller le dragon toi-même, à midi, avec un plan de secours.

L'autodidacte

Résilience

Ce qui tombe ne doit pas tout emporter

Le serveur que tu n'oses pas redémarrer