diff --git a/content/30_specifications_techniques.md b/content/30_specifications_techniques.md
index b37654d..64d7bc6 100644
--- a/content/30_specifications_techniques.md
+++ b/content/30_specifications_techniques.md
@@ -16,38 +16,153 @@ de l'application pour garantir un certain niveau de service.
 
 ## Étude de l'application
 
+Le dépôt Git contenant l'application **existait déjà**. Une étude des composants fournis par le projet a donc été nécessaire. Ce qui a été fournis aux développeurs également. Ce qui a permis d'en mesurer les implications.
+
 ### Composants de l'application
 
-### Implications
+L'équipe de développement a fait le choix du **monorepo** pour contenir l'ensemble des éléments de l'application. L'application est composée de : 
 
-Ce que cela implique pour la suite
+* une base de données PostgreSQL,
+* un backend écrit en Python et construit sur FastAPI,
+* un frontend écrit en TypeScript et construit avec ReactJS.
+
+L'ensemble se comprend mieux à l'aide du schéma suivant : 
+
+![Schéma des composants de l'application](./media/schema_composants_application.png){height=55%}
+
+### Outils fournis aux développeurs
+
+Via le dépôt, les développeurs ont accès à : 
+
+* une documentation principale via un fichier **README.md**,
+* une documentation secondaire via : 
+  * un fichier **backend/README.md** pour les développeurs du Backend,
+  * un fichier **frontend/README.md** pour les développeurs du Frontend,
+* plusieurs fichiers **Docker Compose** afin de déployer localement : 
+  * une **base de données (BDD) PostgreSQL** avec un **jeu de données préchargé**,
+  * une interface Web, via l'outil adminer, à la BDD,
+  * le backend (FastAPI),
+  * le frontend (ReactJS),
+* une documentation **deployment.md** pour déployer le projet à l'aide de **Docker Compose**,
+* un fichier **docker-compose.traefik.yml** afin de déployer une instance locale du **proxy Traefik** configuré pour utiliser Docker
+
+Ces éléments sont un bon point de départ pour l'équipe de DevOps qui prendra connaissance des particularités de cette application.
+
+### Points d'attentions
+
+La **partie Frontend** permet de générer des fichiers dits « statiques », du **serverless** est envisageable. L'application, bien que faisant des appels à une API, fonctionne de manière **autonome**. Ce qui, a priori, facilite la préparation pour un déploiement. Cependant **un nom de domaine est inscrit en dur dans le fichier Dockerfile**, ce qui peut compliquer un déploiement sur plusieurs domaines et environnements.
+
+La partie Backend s'appuie sur une base de données de type PostgreSQL. Elle est donc **dépendante de la BDD**.
+
+La partie proxy utilise actuellement **Traefik comme outil**. Ce qui n'est pas une obligation d'usage pour déploiement en production.
+
+Ces trois parties ont une influence sur le choix de l'infrastructure à mettre en place. Il reste cependant une **marge de manœuvre sur la partie proxy**.
 
 ## Infrastructure d'accueil
 
+Afin d'accueillir l'application dans le Cloud, l'infrastructure de base va poser les fondations de l'environnement complet nécessaire à un usage quotidien.
+
 ### Couche basse
 
+La couche basse pourrait définir le minimum nécessaire avant d'installer quoique ce soit pour exploiter l'application. En ce sens, on utilise des éléments de base d'Amazon Web Services (AWS) pour fabriquer notre infrastructure :
+
+* un espace privé, Virtual Private Cloud (**VPC**),
+* sur plusieurs **régions**,
+* avec plusieurs zones de disponibilités (**Availability Zone**),
+* contenant chacune, d'un point de vue réseau informatique, des réseaux publics (**public subnet**) et des réseaux privés (**private subnet**),
+* en utilisant une passerelle entre le VPC et Internet, appelée **Internet Gateway** (IGW),
+* en utilisant des passerelles **NAT** (Network Access Translation) entre les réseaux privés et les réseaux publics pour un accès à l'IGW,
+* avec des groupes de sécurité (**Security groups**) pour définir les règles d'entrée/sortie,
+* et des équilibreurs de charge de type réseau (**Network Load Balancer**) afin de gérer les accès aux services de manière équilibrée.
+
+Le schéma de la couche basse de l'infrastructure ressemble donc à : 
+
+![Schéma de la couche basse de l'infrastructure](./media/schema_couche_basse.png){width=100%}
+
+C'est sur cette base qu'il est possible d'intégrer un environnement capable de déployer, automatiser et gérer des applications conteneurisées.
+
 ### Environnement Kubernetes
 
-* EKS
-* cert-manager (avec Let's Encrypt) - gratuit
-* externaldns + Route53 (domaines) ~ 16€/mois pour nos routes
-* AWS LoadBalancer, couche 4 du modèle OSI (pour le lien entre l'extérieur et le cluster)
-* Nginx ingress controller pour le lien entre les services du cluster et l'AWS LoadBalancer
+Kubernetes est un système capable de faire tourner des applications conteneurisées, d'automatiser le déploiement et de gérer la mise à l'échelle (**auto-scaling**).
 
-### Déploiement
+Sur l'infrastructure présentée dans le paragraphe précédent il va falloir ajouter quelques éléments comme : 
 
-* Terraform
-* Pipelines automatisées
+* un cluster Kubernetes appelé EKS (**Elastic Kubernetes Service**) géré par Amazon,
+* avec l'usage d'une mise à l'échelle (**autoscaling**) des serveurs virtuels EC2 (Elastic Container) d'Amazon,
+* un équilibreur de charge de type réseau entre l'extérieur du cluster et le cluster (**AWS Elastic LoadBalancer** ou ELB) ; présent d'ailleurs dans le schéma de la couche basse de l'infrastructure dans le paragraphe précédent,
+* un équilibreur de charge de type réseau (couche 4 du modèle OSI - Open Systems Interconnection) qui fait le lien entre les services et l'extérieur du cluster : **NGINX Ingress Controller** ; il va notamment échanger avec l'AWS Elastic LoadBalancer précédent,
+* l'utilisation d'un agent **externaldns** qui va mettre à jour les routes DNS (Domain Name System) de **Route53** pour les sous-domaines utilisés (~16€/mois pour 3 routes),
+* et avec l'usage de **cert-manager** pour faire la demande de certificats SSL (Secure Sockets Layer) via le service - gratuit - de **Let's Encrypt** pour nos sous-domaines.
+
+Le contenu du cluster EKS, une fois implémenté, pourrait ressembler à ceci : 
+
+![Schéma des applications et services contenu(e)s dans le cluster EKS](./media/schema_contenu_eks.png){width=100%}
+
+Dans le cluster pourra donc tourner, en plus des agents précédemment cités, les applications suivantes : 
+
+* le serveur de BDD postgreSQL,
+* le backend de l'application (FastAPI),
+* et le frontend de l'application (en fichiers statiques).
+
+Afin de permettre une livraison régulière de l'application, il va falloir automatiser au maximum les étapes entre la publication d'une nouvelle version de l'application et sa livraison. Puis son déploiement en production via une intervention humaine.
+
+### Livraison continue et déploiement
+
+Il est visé une CI/cd, c'est à dire une Intégration Continue (Continuous Integration) et une livraison continue (continuous delivery). **L'automatisation est donc essentielle.**
+
+Le déploiement en production passera par une validation manuelle.
+
+Doivent être automatisés : 
+
+* les tests du backend,
+* les tests du frontend,
+* l'étude de sécurité sur les dépendances des composants de l'application,
+* la génération d'une image Docker pour le frontend et le backend,
+* la publication de cette image sur un dépôt d'images,
+* le déploiement d'un environnement de pré-production (appelé *staging*, dont nous parlerons dans le chapitre [Démarche suivie](#demarche)),
+* le déploiement, une fois la validation manuelle sur l'environnement de pré-production faite, d'un environnement de production,
+* et la mise en place initiale de l'infrastructure (appelée boostrap).
+
+Nous retrouverons ces éléments dans les chapitres suivants.
 
 ## Services et outils divers
 
-Pas si annexes que ça tout de même !
+Plusieurs sujets tournent autour des services mis en place : 
+
+* les données : définit les éléments enregistrés à l'usage quotidien de l'application,
+* la supervision : définit tous les éléments permettant de mesurer les différents services et d'alerter si les métriques dépassent des seuils définis,
+* la sécurité : définit tout ce qui peut être mis en œuvre pour palier rapidement à des problèmes de sécurité de l'application, de l'infrastructure et des outils utilisés.
 
 ### Données
 
+Le sujet des données ne couvre pas uniquement les données brutes enregistrées par l'application, mais aussi la manière de les stocker, de les sauver via un plan de sauvegarde et de les restaurer si besoin.
+
+#### Où sont les données ?
+
+Les données de ce projet sont multiples. En voici une liste non-exhaustive :
+
+* les dépôts contenant le **code applicatif** (backend + frontend),
+* les dépôts contenant la **description de l'infrastructure**,
+* les données brutes de l'application, stockées dans la **base de données postgreSQL**,
+* les **données sensibles** (mots de passe, clés d'accès),
+* les **copies de sauvegardes** des données elle-même,
+* et les **fichiers de journalisation** des services en production.
+
+#### TODO
+
+sous-chapitres : 
+
+* Cas de la BDD ? Adapter une fois la solution choisie + déployée ?
+* Stockage : où stocker les sauvegardes ? => Bucket S3 à part ? Si oui : le mettre dans le bootstrap Terraform
+* Sauvegardes : fréquence
+
 #### BDD postgreSQL
 
-Aurora, MAIS soucis lors de l'implémentation. Faute de temps : postgresql-ha
+Choix entre : 
+
+* opérateur postgreSQL
+* RDS en mode postgreSQL (Aurora ?) sur plusieurs zones ?
+* postgresql-ha via une chart Helm
 
 #### Stockage
 
@@ -65,6 +180,8 @@ Prévu de :
 
 Pas fait faute de temps.
 
+TODO: SLA (Service Level Agreement) à définir ICI !!!!
+
 #### Surveillance (monitoring)
 
 Choix indicateurs
diff --git a/content/40_demarche.md b/content/40_demarche.md
index 1440510..a9ff92e 100644
--- a/content/40_demarche.md
+++ b/content/40_demarche.md
@@ -1,6 +1,6 @@
 \newpage
 
-# Démarche suivie et opportunité(s) de collaboration
+# Démarche suivie et opportunité(s) de collaboration {#demarche}
 
 TODO: introduction
 
diff --git a/media/schema_composants_application.png b/media/schema_composants_application.png
new file mode 100644
index 0000000..35c1c39
Binary files /dev/null and b/media/schema_composants_application.png differ
diff --git a/media/schema_contenu_eks.png b/media/schema_contenu_eks.png
new file mode 100644
index 0000000..5298d43
Binary files /dev/null and b/media/schema_contenu_eks.png differ
diff --git a/media/schema_couche_basse.png b/media/schema_couche_basse.png
new file mode 100644
index 0000000..a3f58bb
Binary files /dev/null and b/media/schema_couche_basse.png differ