diff --git a/tutorial/3/cgroups-influx.md b/tutorial/3/cgroups-influx.md
index 9958b11..ab643a5 100644
--- a/tutorial/3/cgroups-influx.md
+++ b/tutorial/3/cgroups-influx.md
@@ -1,11 +1,11 @@
 ::::: {.exercice}
 
-### Exercice (obligatoire pour les SRS -- optionnel pour les GISTRE)
+### Exercice (obligatoire pour les SRS -- optionnel pour les GISTRE) {-}
 
 Poursuivons [notre script de monitoring](#script-monitoring) afin d'envoyer nos
 résultats vers InfluxDB : nous l'appellerons `./telegraf.sh`.
 
-#### Rappel d'InfluxDB
+### Rappel d'InfluxDB
 
 Commençons par lancer le conteneur Docker d'InfluxDB (pour éviter de
 l'installer sur notre machine) :
@@ -16,6 +16,15 @@ docker container run --name mytsdb -d -p 8086:8086 influxdb:1.8
 ```
 </div>
 
+::::: {.warning}
+
+Nous utilisons la version 1.8 d'influxDB qui est plus simple à administrer pour
+faire des tests. Vous pouvez partir sur la version 2, une API compatible avec
+la version 1 est disponible, elle est plus simple à utiliser à partir d'un
+shell.
+
+:::::
+
 Il nous faut ensuite créer une base de données pour y stocker nos
 métriques. Voici comment on s'était débrouillé précédemment pour interagir avec
 InfluxDB :
@@ -32,7 +41,7 @@ EOF
 Vérifiez que la base de données `metrics` a bien été créée.
 
 
-#### Monitoring vers InfluxDB
+### Monitoring vers InfluxDB
 
 Maintenant, envoyons nos données vers la base
 <https://docs.influxdata.com/influxdb/v1.8/guides/write_data/> :
@@ -54,7 +63,7 @@ SELECT * from "$my_cgroup_name";
 </div>
 
 
-#### Monitorer davantage de données
+### Monitorer davantage de données
 
 Liste non exhaustive de données à monitorer :
 
@@ -70,16 +79,16 @@ accessible ici :
 - v2 : <https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html>
 
 
-#### Permettre à l'utilisateur de monitorer des processus
+### Permettre à l'utilisateur de monitorer des processus
 
 Maintenant, séparons notre script en deux parties afin qu'un utilisateur normal
 (non-root) puisse utiliser la partie monitoring de notre script.
 
 Un premier script doit s'occuper de créer le(s) *cgroup*s et lui attribuer les
-bons droits, tandis que le deuxième va effectuer le monitoring, sans privilèges
-particuliers.
+bons droits (`chown $EUID`), tandis que le deuxième va effectuer le monitoring,
+sans privilèges particuliers.
 
-##### Exemple {-}
+#### Exemple {-}
 
 <div lang="en-US">
 ```
diff --git a/tutorial/3/cgroups.md b/tutorial/3/cgroups.md
index 23a2a7c..9a76c75 100644
--- a/tutorial/3/cgroups.md
+++ b/tutorial/3/cgroups.md
@@ -175,16 +175,29 @@ echo $PID > /sys/fs/cgroup/{,freezer/}virli/cgroup.procs
 
 Il faut ici remplacer `$PID` par le PID du shell que l'on a relevé juste avant.
 
+::::: {.question}
+
+#### Ne devrait-on pas utiliser `>>` pour ajouter le processus au fichier ? {-}
+
+Malgré l'utilisation de la redirection `>` (et non `>>`), il s'agit bel et bien
+d'un ajout au fichier et non d'un écrasement. Il faut garder en tête que le
+système de fichier est entièrement simulé et que certains comportements sont
+adaptés.
+
+:::::
+
 En validant cette commande, nous avons déplacé le processus dans ce groupe, il
 n'est alors plus dans aucun autre groupe (pour ce *cgroup*, il ne bouge pas
-dans les autres *cgroup*s).
+dans les autres *cgroup*s de la v1).
 
 ::::: {.question}
 
-Malgré l'utilisation de la redirection `>` (et non `>>`), il s'agit bel et
-bien d'un ajout au fichier et non d'un écrasement. Il faut garder en tête que
-le système de fichier est entièrement simulé et que certains comportements sont
-adaptés.
+#### Où sont placés les nouveaux processus ? {-}
+
+Les nouveaux processus héritent des groupes de leur père.
+
+Si vous lancez un `top` dans votre nouveau terminal, son PID sera présent dans
+le fichier `cgroup.procs`.
 
 :::::
 
@@ -197,12 +210,19 @@ sont en lecture seule et permettent de lire des statistiques instantanées sur
 le groupe ; tandis que d'autres sont des propriétés que nous pouvons modifier.
 
 Nous pouvons consulter l'état de gel du groupe en affichant le contenu du
-fichier\
-`/sys/fs/cgroup/freezer/virli/freezer.state` ou `/sys/fs/cgroup/virli/cgroup.freeze`.
+fichier :
+
+<div lang="en-US">
+```bash
+42sh$ cat /sys/fs/cgroup/freezer/virli/freezer.state      # v1
+42sh$ cat /sys/fs/cgroup/virli/cgroup.freeze              # v2
+```
+</div>
 
 Pour plus d'informations sur les différents fichiers présents dans ce *cgroup*,
 consultez
-[la documentation associée](https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/freezer-subsystem.html).
+[la documentation associée](https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/freezer-subsystem.html) :\
+<https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/freezer-subsystem.html>
 
 
 ### Changement d'état
@@ -216,7 +236,7 @@ for i in $(seq 9999); do echo -n $i; sleep .1; echo -n " - "; sleep .1; done
 ```
 </div>
 
-Maintenant, nous avons donné l'ordre au noyau de ne plus allouer de temps de
+Maintenant, nous alloner donné l'ordre au noyau de ne plus allouer de temps de
 calcul à notre shell et ses fils :
 
 <div lang="en-US">
@@ -241,8 +261,8 @@ echo 0 > /sys/fs/cgroup/virli/cgroup.freeze               # v2
 
 ### Script de monitoring {- #script-monitoring}
 
-À nous maintenant de concevoir un script qui va enregistrer vers une base de
-données des statistiques issues des *cgroup*s, tel `telegraf`.
+À nous maintenant de concevoir un script de collecte de statistiques issues des
+*cgroup*s, similaire à `telegraf`.
 
 Dans un premier temps, commençons par afficher dans la console, la quantité de
 mémoire utilisée par le groupe monitoré.
@@ -297,6 +317,9 @@ activé par défaut par votre système. Si vous êtes dans ce cas, essayez
 d'ajouter `cgroup_enable=memory` à la ligne de commande de votre noyau.
 :::::
 
+Gardez ce script dans un coin, nous allons le compléter dans les sections
+suivantes.
+
 :::::
 
 ### Fixer des limites {#Fixer-des-limites}
@@ -306,8 +329,8 @@ quantité de ressources mises à disposition à un groupe de processus.
 
 Pour définir une limite, nous allons écrire la valeur dans le fichier
 correspondant à une valeur limite, comme par exemple
-`memory.max_usage_in_bytes`/`memory.max`, qui limite le nombre d'octets que
-notre groupe de processus va pouvoir allouer au maximum :
+`memory.max_usage_in_bytes` (v1) ou `memory.max` (v2), qui limite le nombre
+d'octets que notre groupe de processus va pouvoir allouer au maximum :
 
 <div lang="en-US">
 ```
@@ -339,6 +362,8 @@ Chaque *cgroup*s définit de nombreux indicateurs et possède de nombreux
 limiteurs, n'hésitez pas à consulter la documentation associée à chaque
 *cgroup*.
 
+::::: {.exercice}
+
 Mettez à jour votre script de monitoring pour prendre en compte les
 limites que vous avez définies :
 
@@ -358,6 +383,8 @@ limites que vous avez définies :
 ```
 </div>
 
+:::::
+
 
 ### Pour aller plus loin  {-}