diff --git a/content/50_realisations.md b/content/50_realisations.md
index eccbf87..9fa4d14 100644
--- a/content/50_realisations.md
+++ b/content/50_realisations.md
@@ -4,17 +4,21 @@
 
 Automatisation upstream -> charts -> infra avec GitlabCI
 
+ATTENTION : c'est du CI/cd (continuous delivery) car intervention humaine entre staging et prod.
+
 TODO : compléter
 
 * Présentation processus automatisation : pouvoir passer d'une nouvelle version de l'application au déploiement de l'infrastructure
 
-## Contexte
+## Réalisation 1 : Livraison continue
+
+### Contexte
 
 * manque de ressources humaines (2 personnes sur 4 ne produisaient rien de concret et/ou utilisable)
 * ET de ressources de temps
 * il a fallu imaginer une façon atypique de créer une chaîne de publication logicielle avec **l'existant**
 
-## Analyse
+### Analyse
 
 * 3 dépôts (donner schéma)
 * chacun 1 pipeline existant pour les tests
@@ -22,7 +26,7 @@ TODO : compléter
 * suivant quelle(s) règle(s) ?
 * (RAPPEL chap. précédent) : Échanges avec Maxime concernant la promotion logicielle
 
-## Solution
+### Solution
 
 * 2 règles : 
   * code = tests
@@ -34,14 +38,48 @@ TODO : compléter
 
 TODO : mettre le complet plutôt qu'un autre ?
 
-## Limites
+### Limites
 
 * même tag sur tous les dépôts… que faire si on dérive/décalle les numéros de version ?
 * plus on ajoute de dépôts, plus on devra modifier les pipelines pour qu'elles s'enchaînent => travail devient colossal
 
-## Amélioration(s) possibles(s)
+### Amélioration(s) possibles(s)
 
 * dépôt indépendants avec leur propre pipeline qui **teste** puis **publie** sur des **dépôts utilisables**
 * un dépôt peut utiliser des lib en dépendances, en utilisant les dépôts précédemment complétés : avec des versions fixes !
 
+## Réalisation 2 : États Terraform
+
+### Contexte
+
+* États continuellement cassés par les collaborateurs
+* Incompréhension/ignorance des collaborateurs sur le fonctionnement
+
+### Analyse
+
+* États sur Gitlab CI : 
+  * gitlab-ci pour les pipelines de test
+  * staging pour l'env de pré-production
+  * prod pour l'env de prod
+* Nécessité d'en avoir 1 par développeur
+* Manque de documentation pour savoir comment procéder
+* Trop d'erreurs manuelles dans l'utilisation des commandes Terraform
+
+### Solution
+
+* dossier scripts avec la plupart des commandes
+* documentation
+* ajout d'un Makefile utilisant les scripts
+* préparation de fichiers pré-remplis
+
+### Limites
+
+* si modification à faire : doit être fait sur tous les dépôts
+* si template évolue : les dépôts qui l'ont utilisé n'ont plus les mises à jour. On pourrait avec rebase, mais ça casserait l'historique de chacun des dépôts
+
+### Pour aller plus loin
+
+* Forme de dépendance des nouveaux dépôts à celui de template (avec une commande de mise à jour des fichiers par exemple)
+* Possibilité de choisir/configurer Terraform ou OpenTofu
+
 ## Conclusion
diff --git a/content/60_situation_de_travail.md b/content/60_situation_de_travail.md
index 2f1b385..037ebbc 100644
--- a/content/60_situation_de_travail.md
+++ b/content/60_situation_de_travail.md
@@ -1,5 +1,14 @@
 \newpage
 
-# Mise en situation : TODO (compléter sujet)
+# Situation de travail : TODO (compléter sujet)
 
 TODO : compléter par un sujet avec une mise en situation
+
+Idées : 
+
+* promotion logicielle (mais énoncée déjà dans un autre chapitre)
+* renseignements sur EKS sous AWS (antonputra, vidéos, tests, Terraform, etc.)
+* gitlab-runner dans un Kubernetes maison pour avoir des runners ? => demande recherche, essais, mise en place, etc.
+* autre ? (sujets à venir et renseignements courants ?)
+* Terraform sur Gitlab CI (stockage sur un dépôt)
+* Makefile pour Terraform avec repo template