Fixed broken links

.404-links.yml

@@ -30,6 +30,7 @@ ignore:
     - https://www.nic.in/servicecontents/national-cloud # 503
     - https://www.gov.uk/government/publications/defence-artificial-intelligence-strategy # Timeout
     - https://www.defense.gouv.fr/ema/actualites/voeux-du-chef-detat-major-armees # Timeout
+    - https://nsf.dev.nato.int/ # Timeout
 delay:  # Perform a pause of X ms at each call matching the url
   'https://gitlab.com': 500
   'https://gitlab.biterg.io': 1000

eng/README.md

@@ -1108,7 +1108,7 @@ To excel in system resilience, as in any field, training is necessary. That's wh
 To ensure that its teams are well organized in case of an incident, Google has designed two types of training[^SRETrainingsGoogle]. The goal is to reduce the _Mean Time To Mitigation_ (the average time to resolve an incident, cf. chapter "[Measuring the success of your transformation](#measuring-the-success-of-your-transformation)"), which would impact the company's service contracts.
 
 1. DiRT (_Disaster Recovery Testing_): a group of engineers plans and causes an actual failure over a defined period to test the effectiveness of its incident response. It is recommended to perform these trainings at least once a year on your critical services ;
-2. The Wheel of Misfortune: a fictional scenario drawn at random, in the form of a role-playing game similar to _Dungeons and Dragons_, where a team of engineers faces an operational emergency. They interact with a "game master" who invents consequences for the actions that the engineers announce they will take. Engineers take this opportunity to review their incident investigation procedures. This practice is particularly useful for newcomers but requires that the game master be particularly experienced (cf. Pavlos RATIS's GitHub project "[wheel of misfortune](https://dastergon.gr/wheel-of-misfortune)"[^pratiswomgithub]).
+2. The Wheel of Misfortune: a fictional scenario drawn at random, in the form of a role-playing game similar to _Dungeons and Dragons_, where a team of engineers faces an operational emergency. They interact with a "game master" who invents consequences for the actions that the engineers announce they will take. Engineers take this opportunity to review their incident investigation procedures. This practice is particularly useful for newcomers but requires that the game master be particularly experienced (cf. Pavlos RATIS's GitHub project "[wheel of misfortune](https://github.com/dastergon/wheel-of-misfortune)"[^pratiswomgithub]).
 
 Amazon Web Services (AWS) offers a similar approach named _Game days_[^AWSGameday] to Google's _Wheel of Misfortune_. The company lists its critical services and the threats that can be associated with them (e.g., data loss, overload, unavailability) to determine a "disaster" scenario. Subsequently, the idea is to provision an infrastructure identical to the production and cause the desired failure. It then observes how its teams and production tools react to the incident.
 
@@ -1886,7 +1886,7 @@ Transparency is also an excellent way to attract talent. In the industry, compan
 
 [Many companies](https://github.com/kilimchoi/engineering-blogs) like [Spotify](https://engineering.atspotify.com/), [LinkedIn](https://engineering.linkedin.com/blog), [Meta](https://engineering.fb.com), [Airbnb](https://medium.com/airbnb-engineering), and [Capgemini](https://capgemini.github.io/) share articles on their respective blogs. Topics range from postmortems to best internal practices or overcome challenges.
 
-For instance, Cloudflare is renowned for its high-quality postmortems regularly published on [its blog](https://blog.cloudflare.com/tag/postmortem/)[^PostmortemCloudflare]. Newsletters such as _SRE Weekly_ also list public incidents every week.
+For instance, Cloudflare is renowned for its high-quality postmortems regularly published on [its blog](https://blog.cloudflare.com/tag/post-mortem/)[^PostmortemCloudflare]. Newsletters such as _SRE Weekly_ also list public incidents every week.
 
 A public postmortem is typically less detailed than an internal one. The former often summarizes the latter, excluding sensitive parts.
 

fra/README.md

@@ -1112,7 +1112,7 @@ Pour exceller dans la résilience des systèmes comme dans tout domaine, il faut
 Pour garantir que ses équipes soient bien organisées en cas d'incident, Google a conçu deux types d'entraînement[^SRETrainingsGoogle]. L'objectif est de réduire le _Mean Time To Mitigation_ (le temps moyen de résolution d'un incident, cf. chapitre "[Mesurer le succès de sa transformation](#mesurer-le-succès-de-sa-transformation)"), qui aurait un impact sur les contrats de service de l'entreprise.
 
 1. DiRT (_Disaster Recovery Testing_) : un groupe d'ingénieurs planifie et provoque une panne réelle pendant une période définie afin de tester l'efficacité de sa réponse à incident. Il est recommandé d'effectuer ces entraînements au moins une fois par an sur vos services critiques ;
-2. La roue de la malchance (_Wheel of misfortune_) : scénario fictif tiré au hasard, sous forme d'un jeu de rôle type _Donjons et Dragons_ où une équipe d'ingénieurs se retrouve face à une urgence opérationnelle. Elle intéragit avec un "maître du jeu" qui invente des conséquences aux actions que les ingénieurs annoncent prendre. Les ingénieurs révisent à cette occasion leur procédure d'investigation des incidents. Cette pratique est particulièrement utile pour les nouveaux arrivants mais requiert que le maître du jeu soit particulièrement expérimenté (cf. projet GitHub "[wheel of misfortune](https://dastergon.gr/wheel-of-misfortune)"[^pratiswomgithub] de Pavlos RATIS).
+2. La roue de la malchance (_Wheel of misfortune_) : scénario fictif tiré au hasard, sous forme d'un jeu de rôle type _Donjons et Dragons_ où une équipe d'ingénieurs se retrouve face à une urgence opérationnelle. Elle intéragit avec un "maître du jeu" qui invente des conséquences aux actions que les ingénieurs annoncent prendre. Les ingénieurs révisent à cette occasion leur procédure d'investigation des incidents. Cette pratique est particulièrement utile pour les nouveaux arrivants mais requiert que le maître du jeu soit particulièrement expérimenté (cf. projet GitHub "[wheel of misfortune](https://github.com/dastergon/wheel-of-misfortune)"[^pratiswomgithub] de Pavlos RATIS).
 
 Amazon Web Services (AWS) propose une approche nommée _Game days_[^AWSGameday] similaire à la _Wheel of misfortune_ de Google. L'entreprise liste ses services critiques et les menaces qui peuvent y être associées (ex: perte de données, surcharge, indisponibilité) pour en déterminer un scénario "catastrophe". Par la suite, l'idée est de provisionner une infrastructure identique à la production et provoquer la panne souhaitée. Elle observe alors comment ses équipes et ses outils de production réagissent à l'incident.
 
@@ -1898,7 +1898,7 @@ La transparence est aussi un excellent moyen d'attirer les talents. Dans l'indus
 
 De [nombreuses entreprises](https://github.com/kilimchoi/engineering-blogs) telles que [Spotify](https://engineering.atspotify.com/), [LinkedIn](https://engineering.linkedin.com/blog), [Meta](https://engineering.fb.com), [Airbnb](https://medium.com/airbnb-engineering) ou [Capgemini](https://capgemini.github.io/) partagent des articles sur leur blog respectif. Il peut être sujet de postmortems, mais aussi présenter de bonnes pratiques internes ou des défis surmontés.
 
-Par exemple, Cloudflare est reconnue pour ses postmortems de qualité qu'elle publie régulièrement sur [son blog](https://blog.cloudflare.com/tag/postmortem/)[^PostmortemCloudflare]. Des lettres d'information comme _SRE Weekly_ répertorient également des incidents publics chaque semaine.
+Par exemple, Cloudflare est reconnue pour ses postmortems de qualité qu'elle publie régulièrement sur [son blog](https://blog.cloudflare.com/tag/post-mortem/)[^PostmortemCloudflare]. Des lettres d'information comme _SRE Weekly_ répertorient également des incidents publics chaque semaine.
 
 Un postmortem public est souvent moins fourni qu'un postmortem interne. Dans le premier cas, on ne fera qu'un résumé du second, en enlevant les parties sensibles.