+Les membres du groupe `docker` peuvent obtenir les privilèges root sur la
+machine. Pour un environnement plus sécurisé, considérez :
+
+- **Docker en mode rootless** : permet d'exécuter le daemon Docker sans
+ privilèges root
+- **Podman** : alternative à Docker fonctionnant sans daemon et sans privilèges
+ root par défaut
+
:::::
diff --git a/tutorial/docker-basis/linking.md b/tutorial/docker-basis/linking.md
index 6011c3d..99f06e8 100644
--- a/tutorial/docker-basis/linking.md
+++ b/tutorial/docker-basis/linking.md
@@ -88,3 +88,21 @@ docker network connect NETWORK CONTAINER
Lorsque plusieurs conteneurs ont rejoint un réseau utilisateur, ils peuvent
mutuellement se découvrir grâce à un système de résolution de nom basé sur leur
nom de conteneur.
+
+::::: {.question}
+
+#### Et l'option `--link` ? {-}
+
+Vous trouverez peut-être dans d'anciens tutoriels l'utilisation de l'option
+`--link` pour connecter des conteneurs. Cette option est **dépréciée** depuis
+Docker 1.13 et ne devrait plus être utilisée.
+
+Les réseaux utilisateurs (`user-defined bridge networks`) sont la méthode
+recommandée pour faire communiquer des conteneurs, car ils offrent :
+
+- Une meilleure isolation réseau
+- La découverte automatique des noms (DNS intégré)
+- La possibilité de connecter/déconnecter dynamiquement des conteneurs
+- Plus de flexibilité et de sécurité
+
+:::::
diff --git a/tutorial/docker-basis/secrets.md b/tutorial/docker-basis/secrets.md
index 46fcbe6..db6120c 100644
--- a/tutorial/docker-basis/secrets.md
+++ b/tutorial/docker-basis/secrets.md
@@ -3,4 +3,113 @@
Garder des secrets
==================
-TODO
+Lorsque nous déployons des applications conteneurisées, celles-ci ont souvent
+besoin d'informations sensibles : mots de passe de base de données, clefs API,
+certificats, tokens d'authentification, etc. La gestion de ces secrets est
+cruciale pour la sécurité de nos applications.
+
+
+## Ce qu'il ne faut pas faire
+
+Avant de voir les bonnes pratiques, commençons par les erreurs courantes à
+éviter absolument :
+
+::::: {.warning}
+
+**Ne jamais inclure de secrets dans une image Docker !**
+
+Lorsque vous construisez une image avec un `Dockerfile`, tout ce qui est copié
+dans l'image y reste, même si vous le supprimez dans une couche ultérieure. Les
+images peuvent être inspectées, et les secrets peuvent être extraits de
+l'historique des couches.
+
+:::::
+
+::::: {.warning}
+
+**Ne jamais passer de secrets via la ligne de commande !**
+
+Les arguments de la ligne de commande sont visibles via `ps`, `docker inspect`,
+et sont souvent enregistrés dans l'historique du shell.
+
+
+```bash
+# MAUVAIS EXEMPLE - À NE PAS FAIRE
+docker container run -e DB_PASSWORD=monmotdepasse myapp
+```
+
+
+:::::
+
+
+## Variables d'environnement avec fichiers
+
+Pour éviter que les secrets n'apparaissent dans l'historique de commandes ou
+dans les processus, Docker permet de charger les variables d'environnement
+depuis un fichier :
+
+
+```bash
+docker container run --env-file secrets.env myapp
+```
+
+
+Le fichier `secrets.env` contiendrait :
+
+
+```
+DB_PASSWORD=monmotdepasse
+API_KEY=ma_clef_secrete
+```
+
+
+::::: {.warning}
+
+Pensez à ajouter ce fichier dans votre `.gitignore` ou `.dockerignore` pour éviter qu'il se retrouve accidentellement dans la nature !
+
+:::::
+
+
+## Montage de fichiers secrets
+
+Une approche plus sécurisée consiste à monter les secrets comme fichiers en
+lecture seule dans le conteneur :
+
+
+```bash
+docker container run \
+ --mount type=bind,source=$HOME/.secrets/db_password,target=/run/secrets/db_password,readonly \
+ myapp
+```
+
+
+L'application peut ensuite lire le secret depuis `/run/secrets/db_password`.
+Cette approche présente plusieurs avantages :
+
+- Les secrets ne sont pas visibles via `docker inspect`
+- Les secrets peuvent avoir des permissions restrictives sur l'hôte
+- Les applications peuvent être conçues pour lire les secrets depuis des
+ fichiers, ce qui est compatible avec les systèmes d'orchestration
+
+
+## Docker Secrets (Docker Swarm)
+
+Docker propose un système de gestion de secrets natif, mais celui-ci n'est
+disponible qu'en mode Swarm.
+
+
+```bash
+# Création d'un secret (nécessite Swarm mode)
+echo "monmotdepasse" | docker secret create db_password -
+
+# Utilisation dans un service
+docker service create --secret db_password myapp
+```
+
+
+Dans ce mode, les secrets sont :
+
+- Chiffrés pendant le transit et au repos
+- Montés dans `/run/secrets/` sous forme de fichiers temporaires en RAM
+- Distribués uniquement aux conteneurs qui en ont besoin
+- Gérés de manière centralisée
diff --git a/tutorial/docker-basis/volumes.md b/tutorial/docker-basis/volumes.md
index bd7f7e2..882538a 100644
--- a/tutorial/docker-basis/volumes.md
+++ b/tutorial/docker-basis/volumes.md
@@ -41,6 +41,31 @@ exemple :
:::::
+::::: {.question}
+
+Pour activer le listing de répertoires avec nginx, il faudrait créer un fichier
+de configuration personnalisé avec la directive `autoindex on;` et le monter
+dans le conteneur via un volume supplémentaire.
+
+:::::
+
+::::: {.question}
+
+#### Syntaxes `-v` et `--mount` {-}
+
+Vous remarquerez dans cette partie l'utilisation de deux syntaxes différentes
+pour monter des volumes :
+
+- **`-v` ou `--volume`** : syntaxe courte et concise
+ (ex: `-v ~/Downloads:/usr/share/nginx/html:ro`)
+- **`--mount`** : syntaxe explicite avec des paires clé-valeur
+ (ex: `--mount type=bind,source=...,target=...,readonly`)
+
+La syntaxe `--mount` est recommandée pour sa clarté, mais `-v` reste très
+utilisée car plus courte. Les deux sont équivalentes en fonctionnalité.
+
+:::::
+
## Les volumes
Les volumes sont des espaces créés via Docker (il s'agit d'objets Docker). Ils
diff --git a/tutorial/docker-basis/what.md b/tutorial/docker-basis/what.md
index d020452..567b48b 100644
--- a/tutorial/docker-basis/what.md
+++ b/tutorial/docker-basis/what.md
@@ -67,13 +67,13 @@ défaut.
### Les plugins Docker
L'architecture de Docker est devenue très modulable. Le projet est parti dans
-de nombreuses directions, chacun voulant tirer la couverture vers soit, et
+de nombreuses directions, chacun voulant tirer la couverture vers soi, et
l'équipe maintenant le projet a parfois eu du mal à arbitrer les bonnes choses
à ajouter ou non au projet.
-Afin de palier aux besoins complémentaires, parfois accessoires, parfois
+Afin de pallier aux besoins complémentaires, parfois accessoires, parfois
salvateurs, un système de plugins a été intégré. Il permet d'appeler d'autres
-programmes comme s'il s'agissait de composant de Docker.
+programmes comme s'il s'agissait de composants de Docker.
Certains plugins ajoutent des options à la ligne de commande (`docker-compose`,
`docker-scan`, `docker-buildx` ...). D'autres ajoutent des typologies de