Improved French translation and layout

content/_index.fr.md

@@ -1,58 +1,74 @@
 +++
-title = "PRINCIPES D’INGENIERIE DU CHAOS"
+title = "LES PRINCIPES DE L'INGÉNIERIE DU CHAOS"
 date = 2020-01-28T16:25:57+02:00
 draft = false
 +++
 
-# PRINCIPES D’INGENIERIE DU CHAOS
-Mise à jour : Mai 2018
+# LES PRINCIPES DE L'INGÉNIERIE DU CHAOS
+Mise à jour : Mai 2025
 
-*L’Ingénierie du Chaos est une discipline de l’expérimentation sur un système distribué afin de renforcer la confiance dans la capacité du système à résister à des conditions turbulentes en production.*
+*L'Ingénierie du Chaos est une discipline qui consiste à expérimenter la capacité d'un système informatique à résister à des conditions turbulentes en environnement de production afin de renforcer la confiance en ce système.*
 
-Les progrès dans les systèmes logiciels distribués à grande échelle changent le jeu pour l'ingénierie logicielle. En tant qu'industrie, nous adoptons rapidement des pratiques qui augmentent la flexibilité de développement et la rapidité de déploiement. Une question urgente émerge alors de ces évolutions : Quelle confiance pouvons-nous avoir dans les systèmes complexes que nous mettons en production ?
+---
 
-Même lorsque chacun des services d'un système réparti fonctionne individuellement correctement, les interactions entre ces services peuvent entraîner des résultats imprévisibles. Des résultats imprévisibles, aggravés par des événements rares mais perturbateurs du monde réel qui affectent les environnements de production, et rendent ces systèmes distribués intrinsèquement chaotiques.
+## I. Introduction
 
-Nous devons identifier les faiblesses avant qu'elles ne se manifestent dans des comportements aberrants à l'échelle du système. Les faiblesses systémiques peuvent prendre la forme de : paramètres de fallback inadéquats lorsqu'un service est indisponible ; tentative de reprise avec effets cataclysmique à la suite de timeout incorrectement réglées ; pannes lorsqu'une dépendance en aval reçoit trop de trafic ; échecs en cascade à la suite de la défaillance d’un seul point ; etc. .  Nous devons aborder les faiblesses les plus significatives de manière proactive, avant qu'elles n'affectent nos clients en production. Nous avons besoin d'un moyen de gérer le chaos inhérent à ces systèmes, de tirer parti de la flexibilité et de la vitesse croissantes, et de faire confiance à nos déploiements de production malgré la complexité qu'ils représentent.
+Les progrès dans les systèmes logiciels distribués à grande échelle changent drastiquement l'ingénierie logicielle. En tant qu'industrie, nous adoptons rapidement des pratiques qui augmentent la flexibilité de développement et la rapidité de déploiement. Une question urgente émerge alors de ces évolutions : Quelle confiance pouvons-nous avoir dans les systèmes complexes que nous mettons en production ?
 
-Une approche empirique basée sur les systèmes aborde le chaos dans les systèmes distribués à grande échelle et renforce la confiance dans la capacité de ces systèmes à résister aux conditions du monde réel. Nous apprenons le comportement d'un système distribué en l'observant lors d'une expérience contrôlée. Nous appelons cela *l'Ingénierie du Chaos*.
+Même lorsque chacun des services d'un ensemble logiciel fonctionne individuellement correctement, les interactions entre ces services peuvent entraîner des résultats imprévisibles. Ces résultats imprévisibles, aggravés par des événements rares mais perturbateurs du monde réel qui affectent les environnements de production, rendent ces systèmes logiciels distribués intrinsèquement chaotiques.
 
+Nous devons identifier les faiblesses avant qu'elles ne se manifestent dans des comportements aberrants à l'échelle du système. Les faiblesses systémiques peuvent prendre la forme de : paramètres de "fallback" inadéquats lorsqu'un service est indisponible ; tentative de reprise avec effets cataclysmiques à la suite de "timeouts" incorrectement réglés ; pannes lorsqu'une dépendance en aval reçoit trop de trafic ; échecs en cascade à la suite de la défaillance d'un seul point, etc. Nous devons aborder les faiblesses les plus significatives de manière proactive, avant qu'elles n'affectent nos clients en production. Nous avons besoin d'un moyen de gérer le chaos inhérent à ces systèmes, de tirer parti de cette flexibilité forte et de cette accélération croissante, et de faire confiance à nos déploiements en production malgré la complexité qu'ils représentent.
 
-## CHAOS EN PRATIQUE
+Une approche empirique aborde le chaos dans ces systèmes et renforce la confiance en la capacité de ces systèmes à résister aux conditions de production du monde réel. Nous apprenons le comportement d'un système en l'observant lors d'une expérience contrôlée. Nous appelons cela *l'Ingénierie du Chaos*.
 
-Pour répondre spécifiquement à l'incertitude des systèmes distribués à grande échelle, l'Ingénierie du Chaos peut être considérée comme la facilitation d’expériences pour découvrir les faiblesses systémiques. Ces expériences suivent quatre étapes :
+---
 
-1. Définir un « état stable » comme une sortie mesurable d'un système qui indique un comportement normal.
-2. Faire l’hypothèse que cet état d'équilibre se poursuivra dans le groupe témoin et dans le groupe expérimental.
-3. Introduire des variations qui reflètent des événements réels, tels que les serveurs en panne, les disques durs défectueux, les connexions réseau coupées, etc.
-4. Tenter de réfuter l'hypothèse en recherchant une différence d'état d'équilibre entre le groupe témoin et le groupe expérimental.
+## II. L'Ingénierie du Chaos, en pratique
 
-Plus il est difficile de perturber l'état stable, plus nous avons confiance dans le comportement du système. Si une faiblesse est découverte, nous avons maintenant un objectif d'amélioration pour éviter que ce comportement ne se manifeste un jour.
+Pour répondre spécifiquement à l'incertitude de nos systèmes logiciels distribués, l'Ingénierie du Chaos peut être considérée comme un moyen facile d’expérimenter pour découvrir les faiblesses de ces derniers. Ces expériences suivent quatre étapes :
 
-## PRINCIPES AVANCÉS
+1. Définir l'état « stable », comme une sortie ou une donnée mesurable, d'un système qui agit avec un comportement nominal.
+2. Faire l’hypothèse que cet état stable se poursuivra dans le groupe témoin et dans le groupe expérimental.
+3. Introduire des variations qui reflètent des événements réels, tels que des serveurs en panne, des disques durs défectueux, des connexions réseau coupées, etc.
+4. Tenter de réfuter l'hypothèse en recherchant une différence d'état entre le groupe témoin et le groupe expérimental.
 
-Les principes suivants décrivent une application idéale de l’Ingénierie du Chaos, en appliquant le processus d'expérimentation décrits ci-dessus. Le degré d’application de ces principes est fortement corrélé à la confiance que nous pouvons avoir dans un système distribué à grande échelle.
+Plus il est difficile de perturber l'état stable d'un système, plus nous avons confiance en le comportement de ce dit système. Si une faiblesse est découverte, nous avons maintenant un objectif d'amélioration pour éviter que ce comportement ne se manifeste un jour dans un environnement non contrôlé.
 
-### Définir l’hypothèse “Etat Stable” 
+---
 
-Il est préférable de se concentrer sur la sortie mesurable d'un système plutôt que sur les attributs internes du système. Il faut ensuite effectuer ces mesures sur une courte période de temps afin de définir les valeurs constituant l'état stationnaire du système. Le débit global du système, les taux d'erreur, les percentiles de latence, etc. sont tous des indicateurs intéressant sur le comportement en régime nominal. En se concentrant sur les modèles de comportement systémique pendant les expériences d’ingénierie du Chaos, on vérifie que le système fonctionne, plutôt que d'essayer de valider *comment il fonctionne*.
+## III. Application idéale
 
-### Multiplier les événements réels
+Les étapes suivantes décrivent un exemple d'application idéale du principe d'Ingénierie du Chaos, en appliquant le processus d'expérimentation décrit ci-dessus. Le degré d'approfondissement de ces principes est fortement corrélé à la confiance que nous pouvons avoir en un système logiciel.
 
-Les variations d’événements Chaotiques permettent de refléter le monde réel. Il faut alors hiérarchiser les événements soit par impact potentiel ou fréquence estimée. Prenez en compte les événements qui correspondent à des défaillances matérielles telles que la mort des serveurs, les défaillances logicielles telles que les réponses mal formées et les événements sans échec tels qu'un pic de trafic ou un événement de mise à l'échelle. Tout événement capable de perturber l'état d'équilibre est une variable potentielle dans une expérience Chaos.
+### 1. Définir notre « État Stable »
 
-### Effectuer des expérimentations en Production
+Il est préférable de se concentrer sur la sortie mesurable d'un système plutôt que sur les attributs internes du système. Il faut ensuite effectuer ces mesures sur une courte période afin de définir les valeurs constituant l'état stable du système. Le débit global du système, les taux d'erreur, les percentiles de latence, etc. sont tous des indicateurs intéressants sur le comportement d'un système en fonctionnement nominal. En se concentrant sur les modèles de comportement systémique pendant les expériences, on vérifie que le système fonctionne, plutôt que d'essayer de valider *comment il fonctionne*.
 
-Les systèmes se comportent différemment selon l'environnement et les modèles de trafic. Comme le comportement d'utilisation peut changer à tout moment, l'échantillonnage du trafic réel est le seul moyen de capturer un modèle de requêtes de manière fiable. Pour garantir à la fois l'authenticité de la manière dont le système est utilisé et la pertinence par rapport au système déployé actuel, l’Ingénieur du Chaos préfère fortement expérimenter directement le trafic de production..
+### 2. Varier les événements réels
 
-### Automatiser les expérimentations pour les lancer en continu
+Les variations d'événements chaotiques permettent de refléter le monde réel. Il faut alors hiérarchiser les événements soit par impact potentiel, soit par fréquence estimée. Prenez en compte les événements qui correspondent à des défaillances matérielles telles que la casse des serveurs, des défaillances logicielles telles que les réponses mal formées ou des événements qui n'entraînent pas d'échec tels qu'un pic de trafic ou un événement de mise à l'échelle du système. Tout événement capable de perturber l'état stable de notre système est une variable potentielle dans une expérience d'Ingénierie du Chaos.
 
-L’exécution des expériences manuellement nécessite beaucoup de main-d'œuvre et n'est finalement pas viable. Il est fortement recommandé d’automatiser les expériences pour pouvoir les exécuter en continu. L’Ingénierie du Chaos intègre l'automatisation dans le système pour piloter à la fois l'orchestration et l'analyse.
+### 3. Effectuer des expérimentations en environnement de production
 
-### Minimiser le rayon de l’explosion
+Les systèmes se comportent différemment selon l'environnement et les modèles de trafic. Comme le comportement d'utilisation peut changer à tout moment, l'échantillonnage du trafic réel en condition de production est le seul moyen de capturer un modèle de requêtes de manière fiable. Pour garantir à la fois l'authenticité de la manière dont le système est utilisé et la pertinence par rapport au système déployé actuel, nous préférons fortement expérimenter directement sur le trafic en environnement de production.
 
-L’Ingénierie du Chaos est une pratique puissante qui change déjà la façon dont les logiciels sont conçus et fabriqués dans le cadre de certaines des plus grandes opérations au monde. 
+### 4. Automatiser les expérimentations pour des essais continus
 
-Là où d'autres pratiques traitent de la vitesse et de la flexibilité, le Chaos s'attaque spécifiquement à l'incertitude systémique des systèmes distribués. Les Principes du Chaos fournissent la confiance nécessaire pour innover rapidement à grande échelle et offrir aux clients un expériences avec le niveau de haute qualité qu'ils méritent.
+L’exécution manuelle des expériences nécessite beaucoup de main-d'œuvre et n'est finalement pas viable. Il est fortement recommandé d’automatiser les expériences pour pouvoir les exécuter en continu. L’Ingénierie du Chaos intègre l'automatisation dans le système pour piloter à la fois l'orchestration et l'analyse.
 
-Vous pouvez nous rejoindre pour échanger sur ces principes du Chaos et leur mise en application dans le groupe Google [Chaos Community](https://groups.google.com/forum/#!forum/chaos-community).
+### 5. Minimiser le rayon d'impact des expériences
+
+Les expérimentations en production peuvent engendrer des difficultés inutiles pour les clients. Bien qu'il faille prévoir un impact négatif à court terme, il est de notre responsabilité et de notre obligation de veiller à ce que les retombées des expérimentations soient minimisées, contenues et encadrées.
+
+---
+
+## IV. Conclusion
+
+L'Ingénierie du Chaos est une pratique puissante qui impacte déjà la façon dont les logiciels sont conçus et fabriqués dans le cadre de certaines des plus grandes opérations au monde. Là où d'autres pratiques traitent de la vitesse et de la flexibilité, l'Ingénierie du Chaos s'attaque spécifiquement à l'incertitude systémique des systèmes logiciels distribués à grande échelle. Ces principes fournissent la confiance nécessaire pour innover rapidement à grande échelle et offrir aux clients une expérience de haute qualité continue qu'ils méritent.
+
+---
+
+## V. Informations utiles
+
+- Vous pouvez nous rejoindre pour échanger sur ces principes de l'Ingénierie du Chaos et leur mise en application dans le groupe Google [Chaos Community](https://groups.google.com/forum/#!forum/chaos-community).
+- Vous pouvez contribuer à la traduction de cette page via [Github](https://github.com/chaos-eng/chaos-eng.github.io).