Améliorer la cohérence des cours finaux

README.md

@@ -269,11 +269,15 @@ Voici l'arborescence de notre dossier :
 
 Chaque semaine sera un dossier à la racine :
 
-- `week_01/` pour la semaine 1
-- `week_02/` pour la semaine 2
-- `week_06/` pour la semaine 6
-- `week_10/` pour la semaine 10
-- and so on
+ - `week_01/` pour la semaine 1
+ - `week_02/` pour la semaine 2
+ - `week_06/` découverte Docker et Kubernetes
+ - `week_07/` Infrastructure as Code avec Terraform
+ - `week_08/` Observabilité et monitoring
+ - `week_09/` Sécurité DevOps
+ - `week_10/` containerisation avancée
+ - `week_11/` automatisation avancée
+ - `week_12/` projet final
 
 Chaque semaine aura :
 

week_01/day_03/project_01.md

@@ -11,7 +11,7 @@ Avec ta prise d'initiative d'hier sur la mise en place d'un script de création
 Le CTO a de nouveau regardé ton CV afin d'estimer ton vrai potentiel. 
 En parcourant ton CV, cette fois-ci attentivement, il remarque tu as des connaissances en virtualisation.
 
-Ça tombe bien s'exclame-t-il ! J'avais justement besoin de faire quelques testes sur une application avant sa mise en production.
+Ça tombe bien s'exclame-t-il ! J'avais justement besoin de faire quelques tests sur une application avant sa mise en production.
 Tout joyeux, il se met à rédiger des instructions concernant le test qu'il veut que tu réalises.
 
 

week_05/day_01/day_title.txt

@@ -1 +1 @@
-Découvrir de Github Actions.
+Découvrir GitHub Actions

week_05/day_01/lesson_01.md

@@ -8,7 +8,7 @@ Depuis longtemps les devs ont voulu maitriser ce processus et quand je dis longt
 Depuis le début des années 90, pour être précis.
 
 Mais avant de rentrer dans les détails, il nous faut d'abord comprendre précisément 
-la signification du terme `Contiuous Integration` en abrégé ,`CI`, et `Continuous Delivery`, `Continuous Deployement` qui en abrégé se prononcent/s'écrivent, `CD`. 
+la signification du terme `Continuous Integration` en abrégé ,`CI`, et `Continuous Delivery`, `Continuous Deployment` qui en abrégé se prononcent/s'écrivent, `CD`. 
 Je sais, c'est peut-être un peu flou pour toi, mais ces trois termes ne veulent pas dire la même.
 
 Mais je vais t'expliquer chaque terme un par un 😃.
@@ -202,7 +202,7 @@ D'autres champs existent, mais je vais te laisser les découvrir toi-même leurs
 D'un point de vue globale chaque `job`, représente la machine virtuelle sur laquelle le workflow va se lancer.
 Tu peux définir l'OS de ces VMs (ubuntu, windows, debian, etc.) avec le champ `runs-on`, 
 il est également possible de lancer des VMs des customs avec plus de RAM, CPU, Os avec license, etc.
-Les VMs de base de Github viennent tous avec des logiciels (git, npm, yarn, pip, ...) et langages (ruby, pyton, Go, Nodejs..) préinstallés afin de nous faciliter la vie, mais libre à toi d'en rajouter d'autres. :smiley:
+Les VMs de base de Github viennent tous avec des logiciels (git, npm, yarn, pip, ...) et langages (ruby, python, Go, Nodejs..) préinstallés afin de nous faciliter la vie, mais libre à toi d'en rajouter d'autres. :smiley:
 
 Voici la [liste](https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners#preinstalled-software) des logiciels préinstallés.
 

week_05/day_02/day_title.txt

@@ -1 +1 @@
-Les variables dans Github Actions : Notions avancées.
+Variables avancées dans GitHub Actions

week_05/day_02/lesson_01.md

@@ -1,17 +1,39 @@
-# Monitorer des instances EC2 avec AWS CloudWatch
-Description de la ressource au format texte et en 1 paragraphe max (pas plus)
+# Variables avancées dans GitHub Actions
 
-## 1. Introduction/Historique et contexte
+## 1. Introduction
+Tu sais désormais lancer un workflow basique. Aujourd'hui, on va pousser un peu plus loin afin de le rendre vraiment dynamique. Pour cela, GitHub Actions met à ta disposition un grand nombre de variables que tu peux exploiter pour adapter ton pipeline à toutes les situations.
 
+## 2. Historique et contexte
+GitHub Actions a été lancé en 2018. Les variables, secrets et contextes sont apparus pour personnaliser les workflows tout en restant sécurisés.
 
-## 2. La ressource
-### 2.1. ...
+## 3. La ressource
+### 2.1. Les variables d'environnement
+Dans un fichier de workflow, la clé `env` permet de définir des variables accessibles dans toutes les étapes. Elles sont très utiles pour partager un chemin ou une option entre plusieurs actions.
 
+```yaml
+env:
+  APP_ENV: production
+  PACKAGE_VERSION: 1.0.0
+```
 
-### 2.2. ...
+Ces variables sont ensuite disponibles dans chaque `run` ou action avec la syntaxe `${{ env.APP_ENV }}`.
 
-## 3. Points importants à retenir
+### 2.2. Les secrets
+GitHub propose un coffre-fort pour stocker des informations sensibles comme des clés API. Les secrets sont appelés avec `${{ secrets.NOM_DU_SECRET }}` et ne sont jamais affichés en clair dans les logs.
 
+### 2.3. Les contextes
+Lorsque tu as besoin de données spécifiques au repo ou au job, les contextes entrent en jeu. Le contexte `github` te donne par exemple accès au nom de la branche ou du dépôt. Combine-les avec des expressions pour créer des conditions plus intelligentes.
 
-## 4. Pour aller plus loin
-Pas besoin pour l'instant
+### 2.4. Stratégies d'environnements
+Depuis la console GitHub, tu peux définir des variables et secrets propres à un environnement. Cela permet d'avoir des valeurs différentes en fonction de la branche ou du contexte de déploiement (`staging`, `production`, etc.).
+
+### 2.5. Utiliser les variables de sortie
+Certaines actions retournent des valeurs au moyen de la commande `set-output`. Tu peux récupérer ces résultats dans les étapes suivantes pour chaîner intelligemment tes jobs ou déclencher des déploiements conditionnels.
+
+## 4. Points importants à retenir
+- `env` partage des variables simples entre toutes les étapes.
+- Les secrets sont chiffrés et cachés dans les logs.
+- Les contextes fournissent une multitude d'informations utiles sur ton workflow.
+
+## 5. Pour aller plus loin
+La [documentation officielle](https://docs.github.com/fr/actions) regorge d'exemples. Jette aussi un oeil à l'article "Environment variables" dans la doc pour découvrir toutes les possibilités.

week_05/day_02/project_01.md

@@ -1,17 +1,22 @@
-# Monitorer des instances EC2 avec AWS CloudWatch
-Description de la ressource au format texte et en 1 paragraphe max (pas plus)
+# Projet : pipeline avec variables
 
-## 1. Introduction/Historique et contexte
+## 1. Introduction
+L'objectif est de manipuler les variables et les secrets dans un workflow concret.
 
-
-## 2. La ressource
-### 2.1. ...
-
-
-### 2.2. ...
+## 2. Tâches
+- Initialise un dépôt GitHub et ajoute un simple fichier Python ou Node.
+- Crée un workflow déclenché sur chaque push qui:
+  - installe les dépendances,
+  - exécute une commande de test,
+  - affiche la valeur d'une variable définie dans la section `env`.
+- Ajoute un secret appelé `SUPER_TOKEN` et affiche les dix premiers caractères dans une étape dédiée.
+ - Utilise également une variable de sortie d'une action officielle pour récupérer la version de Node installée et affiche-la.
+ - Ajoute enfin un environnement `staging` et associe un second secret à cet environnement pour simuler un déploiement sécurisé.
 
 ## 3. Points importants à retenir
+Ce projet te montre comment passer des informations à tes jobs et comment sécuriser les données sensibles.
+Tu comprendras aussi comment distinguer plusieurs environnements et chaîner intelligemment les étapes grâce aux sorties d'actions.
 
+### Pour aller plus loin
+Lis l'article [Using environments for deployment](https://docs.github.com/fr/actions/deployment/targeting-different-environments/using-environments-for-deployment) afin de découvrir toutes les options offertes par GitHub pour isoler tes secrets.
 
-## 4. Pour aller plus loin
-Pas besoin pour l'instant

week_05/day_03/day_title.txt

@@ -1 +1 @@
-Jouer avec les conteneurs dans Github Actions.
+Jouer avec les conteneurs dans GitHub Actions

week_05/day_03/lesson_01.md

@@ -1,17 +1,43 @@
-# Monitorer des instances EC2 avec AWS CloudWatch
-Description de la ressource au format texte et en 1 paragraphe max (pas plus)
+# Jouer avec les conteneurs dans GitHub Actions
 
-## 1. Introduction/Historique et contexte
+## 1. Introduction
+GitHub Actions permet d'exécuter tes jobs dans des conteneurs Docker. C'est pratique pour maîtriser ton environnement et partager des images communes entre plusieurs workflows.
 
+## 2. Historique et contexte
+L'utilisation de Docker s'est généralisée dès 2013 et GitHub l'a intégré à ses workflows pour garantir des environnements identiques.
 
-## 2. La ressource
-### 2.1. ...
+## 3. La ressource
+### 2.1. Utiliser une image officielle
+Dans la section `jobs.<nom>.container`, indique simplement l'image Docker à utiliser. GitHub téléchargera celle-ci depuis Docker Hub ou ton registry préféré.
 
+```yaml
+jobs:
+  tests:
+    runs-on: ubuntu-latest
+    container: node:20
+    steps:
+      - uses: actions/checkout@v4
+      - run: npm test
+```
 
-### 2.2. ...
+### 2.2. Construire sa propre image
+Pour plus de contrôle, tu peux builder ton image à la volée grâce à l'action `docker/build-push-action`. Elle est utile lorsque ton projet nécessite des dépendances spécifiques.
 
-## 3. Points importants à retenir
+### 2.3. Matrices de conteneurs
+Combine la stratégie `matrix` avec différents conteneurs pour tester plusieurs versions d'un langage ou outil en parallèle.
 
+### 2.4. Services additionnels
+Un job peut utiliser plusieurs conteneurs "services" pour simuler une base de données ou un cache. Déclare-les dans `services:` et relie-les au conteneur principal via un réseau virtuel.
+
+### 2.5. Partage de données
+Pense à monter un volume pour partager des fichiers entre plusieurs étapes ou pour mettre en cache les dépendances et accélérer les builds suivants.
+
+## 4. Points importants à retenir
+- Les conteneurs garantissent une exécution cohérente de tes jobs.
+- Builder l'image au sein du workflow permet de tester exactement ce qui sera déployé.
+- Les matrices multiplient les environnements de test sans configuration complexe.
+
+## 5. Pour aller plus loin
+Rends-toi sur le dépôt `docker/build-push-action` pour voir tous les paramètres disponibles. Expérimente aussi avec GitHub Packages pour héberger tes propres images.
+N'hésite pas à coupler ces conteneurs avec [Docker Compose](https://docs.docker.com/compose/) pour reproduire un environnement complet lors des tests.
 
-## 4. Pour aller plus loin
-Pas besoin pour l'instant

week_05/day_03/project_01.md

@@ -1,17 +1,18 @@
-# Monitorer des instances EC2 avec AWS CloudWatch
-Description de la ressource au format texte et en 1 paragraphe max (pas plus)
+# Projet : tests en conteneur
 
-## 1. Introduction/Historique et contexte
+## 1. Introduction
+L'objectif est de faire tourner ton outil de test dans une image Docker dédiée.
 
-
-## 2. La ressource
-### 2.1. ...
-
-
-### 2.2. ...
+## 2. Tâches
+- Prépare un `Dockerfile` qui installe toutes les dépendances de ton application.
+- Dans le workflow, utilise cette image via la clé `container` pour exécuter les tests.
+- Paramètre une matrice avec deux versions de Node ou Python pour t'assurer que ton code fonctionne partout.
+- Configure un service de base de données dans `services:` pour tester l'intégration complète de ton application.
+- Stocke les rapports de tests en artefacts pour pouvoir les consulter après exécution.
 
 ## 3. Points importants à retenir
+En emballant ton environnement dans une image, tu garantis des résultats identiques en local et dans ton pipeline.
 
+### Pour aller plus loin
+Lis la documentation [GitHub Actions: using containerized services](https://docs.github.com/fr/actions/using-containerized-services) pour comprendre comment chaîner plusieurs images dans un même workflow.
 
-## 4. Pour aller plus loin
-Pas besoin pour l'instant

week_05/day_04/day_title.txt

@@ -1 +1 @@
-Rendre tes workflow performantes et event-driven.
+Des workflows performants et event-driven

week_05/day_04/lesson_01.md

@@ -1,17 +1,33 @@
-# Monitorer des instances EC2 avec AWS CloudWatch
-Description de la ressource au format texte et en 1 paragraphe max (pas plus)
+# Des workflows performants et event-driven
 
-## 1. Introduction/Historique et contexte
+## 1. Introduction
+Les workflows peuvent rapidement devenir longs et coûteux s'ils sont mal optimisés. Nous allons voir comment les déclencher intelligemment et réduire leur durée.
 
+## 2. Historique et contexte
+Au départ limités au push, les workflows GitHub Actions se sont enrichis d'événements et d'un système de cache pour accélérer les CI.
 
-## 2. La ressource
-### 2.1. ...
+## 3. La ressource
+### 2.1. Les événements personnalisés
+GitHub Actions supporte une grande liste d'événements : push, pull_request, mais aussi un simple appel HTTP grâce aux `workflow_dispatch` et `repository_dispatch`. Utilise-les pour lancer des tâches uniquement quand cela est nécessaire.
 
+### 2.2. La mise en cache
+L'action `actions/cache` permet de sauvegarder des dépendances ou des fichiers entre deux exécutions. Ton workflow gagne ainsi plusieurs minutes.
 
-### 2.2. ...
+### 2.3. Le parallélisme
+Avec `strategy.matrix` et `max-parallel`, tu peux contrôler le nombre de jobs qui s'exécutent en même temps, évitant de saturer tes runners auto-hébergés.
 
-## 3. Points importants à retenir
+### 2.4. Les artefacts
+Pense à sauvegarder tes binaires ou rapports de tests grâce à `actions/upload-artifact` pour les réutiliser dans d'autres jobs ou les partager avec ton équipe.
 
+### 2.5. Les dépendances conditionnelles
+Certaines étapes peuvent s'exécuter seulement si la précédente réussit via `if: success()`. Cela permet d'éviter des étapes inutiles en cas d'erreur.
+
+## 4. Points importants à retenir
+- Choisis le bon événement pour limiter les déclenchements inutiles.
+- Le cache réduit le temps d'installation des dépendances.
+- Contrôler le parallélisme permet d'utiliser au mieux les ressources disponibles.
+
+## 5. Pour aller plus loin
+Explore la documentation sur `repository_dispatch` pour déclencher un workflow depuis un autre dépôt ou un script externe.
+Tu peux également regarder l'action [`actions/cache`](https://github.com/actions/cache) pour optimiser la durée de tes builds.
 
-## 4. Pour aller plus loin
-Pas besoin pour l'instant

week_05/day_04/project_01.md

@@ -1,17 +1,18 @@
-# Monitorer des instances EC2 avec AWS CloudWatch
-Description de la ressource au format texte et en 1 paragraphe max (pas plus)
+# Projet : workflow déclenché à la demande
 
-## 1. Introduction/Historique et contexte
+## 1. Introduction
+Nous allons créer un workflow qui ne s'exécute qu'à la demande et qui utilise un cache pour accélérer les dépendances.
 
-
-## 2. La ressource
-### 2.1. ...
-
-
-### 2.2. ...
+## 2. Tâches
+- Mets en place un workflow avec l'événement `workflow_dispatch`.
+- Ajoute une étape pour installer tes dépendances (npm ou pip) en utilisant `actions/cache`.
+- Prévoyez un job de build qui tourne uniquement si l'installation a réussi.
+- Upload le binaire résultant en utilisant `actions/upload-artifact`.
+- Définis une matrice de tests pour valider ta build sur plusieurs versions de Node ou Python.
 
 ## 3. Points importants à retenir
+En déclenchant manuellement ton pipeline, tu maîtrises parfaitement quand tu consommes du temps de CI et l'usage du cache évite bien des temps morts.
 
+### Pour aller plus loin
+Lis la page [Events that trigger workflows](https://docs.github.com/fr/actions/using-workflows/events-that-trigger-workflows) pour comprendre toutes les possibilités offertes par GitHub Actions.
 
-## 4. Pour aller plus loin
-Pas besoin pour l'instant

week_05/day_05/day_title.txt

@@ -1 +1 @@
-Coder Actions et les utiliser sur Github Actions
+Coder ses propres Actions

week_05/day_05/lesson_01.md

@@ -1,17 +1,33 @@
-# Monitorer des instances EC2 avec AWS CloudWatch
-Description de la ressource au format texte et en 1 paragraphe max (pas plus)
+# Coder ses propres Actions
 
-## 1. Introduction/Historique et contexte
+## 1. Introduction
+Parfois, aucune action existante ne répond exactement à ton besoin. Tu peux alors créer ta propre Action, soit avec Docker, soit en JavaScript.
 
+## 2. Historique et contexte
+Dès 2019 la communauté a partagé ses propres Actions, permettant d'automatiser des tâches spécifiques avec de simples dépôts.
 
-## 2. La ressource
-### 2.1. ...
+## 3. La ressource
+### 2.1. Action JavaScript
+Une action JS est un dépôt contenant un script Node exécuté par GitHub. Avec quelques dépendances et un `action.yml`, tu peux publier une action réutilisable par la communauté.
 
+### 2.2. Action Docker
+Si tu préfères exécuter un binaire ou un outil en particulier, l'action Docker est idéale. Elle encapsule tout ce qu'il faut dans une image.
 
-### 2.2. ...
+### 2.3. Publication
+Une fois ton action prête, crée un tag et publie-la sur la marketplace GitHub. Pense à rédiger un README clair pour expliquer son utilisation.
 
-## 3. Points importants à retenir
+### 2.4. Gérer les versions
+Les utilisateurs d'une action s'appuient souvent sur un numéro de version. N'oublie pas de créer un tag Git puis de publier un `release` lorsque tu ajoutes une fonctionnalité majeure.
 
+### 2.5. Tester son action
+Avant de la rendre publique, écris un workflow dédié qui lance ton action sur différentes plateformes. Cela évite les mauvaises surprises une fois en production.
+
+## 4. Points importants à retenir
+- Les actions permettent de factoriser du code réutilisable dans plusieurs workflows.
+- Une action JavaScript s'exécute très vite, tandis qu'une action Docker offre plus de liberté sur l'environnement.
+- Documente toujours les entrées et sorties de ton action pour faciliter son adoption.
+
+## 5. Pour aller plus loin
+La [création d'une action](https://docs.github.com/fr/actions/creating-actions) est très bien détaillée par GitHub. Inspire-toi aussi des actions populaires pour comprendre les bonnes pratiques.
+Pour voir un exemple complet, consulte le dépôt [`actions/setup-node`](https://github.com/actions/setup-node) qui illustre la gestion des versions et des tests automatisés.
 
-## 4. Pour aller plus loin
-Pas besoin pour l'instant

week_05/day_05/project_01.md

@@ -1,17 +1,18 @@
-# Monitorer des instances EC2 avec AWS CloudWatch
-Description de la ressource au format texte et en 1 paragraphe max (pas plus)
+# Projet : créer une action personnalisée
 
-## 1. Introduction/Historique et contexte
+## 1. Introduction
+Tu vas développer une petite action qui vérifie la présence d'un fichier et affiche son contenu.
 
-
-## 2. La ressource
-### 2.1. ...
-
-
-### 2.2. ...
+## 2. Tâches
+- Initialise un dépôt dédié à ton action avec `action.yml`.
+- Écris un script JavaScript prenant en entrée le chemin d'un fichier à lire.
+- Publie cette action et réutilise-la depuis un autre projet grâce au tag que tu auras créé.
+- Configure un workflow de test pour valider ton action sur plusieurs systèmes d'exploitation.
+- Documente clairement les paramètres dans le `README` et ajoute un exemple d'usage.
 
 ## 3. Points importants à retenir
+Ce projet illustre le cycle complet de création et de partage d'une action sur la marketplace.
 
+### Pour aller plus loin
+Parcourez le guide [Publishing actions in GitHub Marketplace](https://docs.github.com/fr/actions/creating-actions/publishing-actions-in-github-marketplace) pour promouvoir au mieux votre travail.
 
-## 4. Pour aller plus loin
-Pas besoin pour l'instant

week_06/day_01/day_presentation.txt

@@ -1 +1 @@
-Description de la première journée au format texte et en un paragraphe.
+Premiers pas avec l'outil Docker et ses concepts.

week_06/day_01/day_title.txt

@@ -1 +1 @@
-Titre de la première journée
+Découverte de Docker