Fix orthograf and grammar thanks to grammalecte

tutorial/3/cgroups.md

@@ -18,7 +18,7 @@ spécifique :
 - [`blkio` (`io` dans la v2)
   :](https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/blkio-controller.html)
   limites et statistiques de bande passante sur les disques ;
-- `cpu` : cycles CPU minimum garantis ;
+- `cpu` : cycles CPU minimums garantis ;
 - [`cpuacct` (inclus dans `cpu` dans la v2)
   :](https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v1/cpuacct.html)
   statistiques du temps CPU utilisé ;
@@ -55,7 +55,7 @@ l'une de ces trois situations :
   la nouvelle version des `cgroup`s.
 
 - Votre dossier `/sys/fs/cgroup` contient d'autres dossiers au nom des
-  sous-systèmes que l'on a listé ci-dessus : il s'agit des `cgroup`s v1.
+  sous-systèmes que l'on a listés ci-dessus : il s'agit des `cgroup`s v1.
 
 - Votre dossier `/sys/fs/cgroup` est vide ou inexistant, vous pouvez choisir
   d'utiliser la version de votre choix :
@@ -94,7 +94,7 @@ sous-systèmes que l'on souhaite utiliser.
 
 ### Création d'un nouveau groupe
 
-Les *cgroup*s sont organisé autour d'une arborescence de groupe, où chaque
+Les *cgroup*s sont organisés autour d'une arborescence de groupe, où chaque
 groupe est représenté par un dossier. Il peut bien évidemment y avoir des
 sous-groupes, en créant des dossiers dans les dossiers existants, etc.\
 
@@ -192,7 +192,7 @@ adaptés.
 ### Consultation de l'état
 
 En affichant le contenu du dossier `virli`, nous pouvions constater que
-celui-ci contenait déjà un certain nombre de fichiers. Certains d'entre-eux
+celui-ci contenait déjà un certain nombre de fichiers. Certains d'entre eux
 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.
 
@@ -252,7 +252,7 @@ mémoire utilisée par le groupe monitoré.
 Vous pouvez utiliser un programme comme `memhog`[^memhog] pour remplir rapidement votre
 mémoire.
 
-[^memhog]: Ce programme fait parti du paquet `numactl`, mais vous trouverez une
+[^memhog]: Ce programme fait partie du paquet `numactl`, mais vous trouverez une
     version modifiée plus adaptée à nos tests sur
     <https://nemunai.re/posts/slow-memhog>.
 

tutorial/3/chroot.md

@@ -43,7 +43,7 @@ chroot newroot /busybox ash
 Nous voici donc maintenant dans un nouveau shell (il s'agit d'`ash`, le shell
 de `busybox`).
 
-Jusque là ... ça fonctionne, rien de surprenant ! Mais qu'en est-il pour
+Jusque-là ... ça fonctionne, rien de surprenant ! Mais qu'en est-il pour
 `bash` :
 
 <div lang="en-US">

tutorial/3/oom.md

@@ -58,7 +58,7 @@ ce sujet :\
 #### À vous de jouer  {-}
 
 Continuons l'exercice précédent où nous avions [fixé les
-limites](#Fixer-des-limites) de mémoire que pouvez réserver les processus de
+limites](#Fixer-des-limites) de mémoire que pouvaient réserver les processus de
 notre groupe. Que se passe-t-il alors si `memhog` dépasse la quantité de
 mémoire autorisée dans le `cgroup` ?
 

tutorial/3/pseudofs.md

@@ -40,12 +40,12 @@ apporter des modifications.
 
 Linux emploie de nombreux systèmes de fichiers virtuels :
 
-- `/proc` : contient, principalement, la liste des processus (`top` et ses
+- `/proc` : contiens, principalement, la liste des processus (`top` et ses
   dérivés se contentent de lire les fichiers de ce point de montage) ;
-- `/proc/sys` : contient la configuration du noyau ;
+- `/proc/sys` : contiens la configuration du noyau ;
-- `/sys` : contient des informations à propos du matériel (utilisées notamment
+- `/sys` : contiens des informations à propos du matériel (utilisées notamment
   par `udev` pour peupler `/dev`) et des périphériques (taille des tampons,
-  clignottement des DELs, ...) ;
+  clignotement des DELs, ...) ;
 - `/sys/firmware/efi/efivars` : pour accéder et modifier les variables de
   l'UEFI ;
 - ...

tutorial/3/seccomp.md

@@ -55,7 +55,7 @@ autorisé conduit à un `SIGKILL` du processus.
 
 Plus modulable que le mode strict, le mode de filtrage permet une grande
 amplitude en permettant au programmeur de définir finement quels appels
-systèmes le programme est autorisé à faire ou non, et quel sentence est
+systèmes le programme est autorisé à faire ou non, et quelle sentence est
 exécutée en cas de faute.
 
 Notons que les processus fils issus (`fork(2)` ou `clone(2)`) d'un processus

tutorial/4/howto.md

@@ -6,7 +6,7 @@ Utiliser les *namespace*s
 ### S'isoler dans un nouveau *namespace*
 
 Si l'on voit l'isolation procurée par les *namespace*s en parallèle avec les
-machines virtuelle, on peut se dire qu'il suffit d'exécuter un appel système
+machines virtuelles, on peut se dire qu'il suffit d'exécuter un appel système
 pour arriver dans un conteneur bien isolé. Cependant, le choix fait par les
 développeurs de Linux a été de laisser le choix des espaces de noms dont on veut
 se dissocier.

tutorial/4/lifetime.md

@@ -3,7 +3,7 @@
 Le noyau tient à jour un compteur de références pour chaque *namespace*. Dès
 qu'une référence tombe à 0, la structure de l'espace de noms est
 automatiquement libérée, les points de montage sont démontés, les interfaces
-réseaux sont réattribués à l'espace de noms initial, ...
+réseaux sont réattribuées à l'espace de noms initial, ...
 
 Ce compteur évolue selon plusieurs critères, et principalement selon le nombre
 de processus qui l'utilisent. C'est-à-dire que, la plupart du temps, le

tutorial/4/mount.md

@@ -11,17 +11,17 @@ systèmes de fichiers.
 ## Les points de montage
 
 Au premier abord, les points de montage dans l'arborescence d'un système de
-fichiers n'ont pas l'air d'être remplis de notions complexes : un répertoire
+fichiers n'ont pas l'air d'être remplis de notions complexes : un répertoire
 peut être le point d'entrée d'un montage vers la partition d'un disque
 physique... ou d'une partition virtuelle, comme nous l'avons vu précédemment.
 
 Mais avez-vous déjà essayé de monter la même partition d'un disque physique à
-deux endroits différents de votre arborescence ?
+deux endroits différents de votre arborescence ?
 
 Si pour plein de raisons on pouvait se dire que cela ne devrait pas être
 autorisé, ce problème s'avère être à la base de beaucoup de fonctionnalités
 intéressantes. Le noyau va finalement décorréler les notions de montage,
-d'accès et d'accroche dans l'arborescence : et par exemple, une partition ne
+d'accès et d'accroche dans l'arborescence : et par exemple, une partition ne
 sera plus forcément démontée après un appel à `umount(2)`, mais le sera
 seulement lorsque cette partition n'aura plus d'accroches dans aucune
 arborescence.
@@ -64,7 +64,7 @@ TARGET                          SOURCE      FSTYPE     OPTIONS
 ## `bind` -- montage miroir
 
 Lorsque l'on souhaite monter à un deuxième endroit (ou plus) une partition, on
-utilise le *bind mount* :
+utilise le *bind mount* :
 
 <div lang="en-US">
 ```bash
@@ -77,12 +77,12 @@ l'installe ou qu'on le répare via un *live CD*), il est nécessaire de duplique
 certains points de montage, tels que `/dev`, `/proc` et `/sys`.
 
 Sans monter ces partitions, vous ne serez pas en mesure d'utiliser le système
-dans son intégralité : vous ne pourrez pas monter les partitions indiquées par
+dans son intégralité : vous ne pourrez pas monter les partitions indiquées par
 le `/etc/fstab`, vous ne pourrez pas utiliser `top` ou `ps`, `sysctl` ne pourra
 pas accorder les paramètres du noyau, ...
 
 Pour que tout cela fonctionne, nous aurons besoin, au préalable, d'exécuter les
-commandes suivantes :
+commandes suivantes :
 
 <div lang="en-US">
 ```bash
@@ -96,7 +96,7 @@ mount --bind /sys sys
 En se `chroot`ant à nouveau dans cette nouvelle racine, tous nos outils
 fonctionneront comme prévu.
 
-Tous ? ... en fait non. Si l'on jette un œil à `findmnt(1)`, nous constatons
+Tous ? ... en fait non. Si l'on jette un œil à `findmnt(1)`, nous constatons
 par exemple que `/sys/fs/cgroup` dans notre nouvelle racine est vide, alors que
 celui de notre machine hôte contient bien les répertoires de nos *cgroups*.
 
@@ -105,7 +105,7 @@ partie de celui-ci) à un autre endroit, sans se préoccuper des points de
 montages sous-jacents. Pour effectuer cette action récursivement, et donc
 monter au nouvel emplacement le système de fichier ainsi que tous les points
 d'accroche qu'il contient, il faut utiliser `--rbind`. Il serait donc plus
-correct de lancer :
+correct de lancer :
 
 <div lang="en-US">
 ```bash
@@ -119,7 +119,7 @@ mount --rbind /sys sys
 
 ## Les types de propagation des points de montage
 
-On distingue quatre variétés de propagation des montages pour un sous-arbre :
+On distingue quatre variétés de propagation des montages pour un sous-arbre :
 partagé, esclave, privé et non-attachable.
 
 Chacun va agir sur la manière dont seront propagées les nouvelles accroches au
@@ -130,7 +130,7 @@ sein d'un système de fichiers attaché à plusieurs endroits.
 
 Dans un montage partagé, une nouvelle accroche sera propagée parmi tous les
 systèmes de fichiers de ce partage (on parle de *peer group*). Voyons avec un
-exemple :
+exemple :
 
 <div lang="en-US">
 ```bash
@@ -146,7 +146,7 @@ mount --bind /tmp /mnt/test-shared
 </div>
 
 Si l'on attache un nouveau point de montage dans `/tmp` ou dans
-`/mnt/test-shared`, avec la politique `shared`, l'accroche sera propagée :
+`/mnt/test-shared`, avec la politique `shared`, l'accroche sera propagée :
 
 <div lang="en-US">
 ```bash
@@ -178,7 +178,7 @@ mount --make-slave /mnt/test-slave
 ```
 </div>
 
-Si l'on effectue un montage dans `/mnt/test-shared` :
+Si l'on effectue un montage dans `/mnt/test-shared` :
 
 <div lang="en-US">
 ```bash
@@ -187,7 +187,7 @@ mount -t tmpfs none /mnt/test-shared/foo
 ```
 </div>
 
-Le point de montage apparaît bien sous `/mnt/test-slave/foo`. Par contre :
+Le point de montage apparaît bien sous `/mnt/test-slave/foo`. Par contre :
 
 <div lang="en-US">
 ```bash
@@ -201,11 +201,11 @@ Le nouveau point de montage n'est pas propagé dans `/mnt/test-shared/bar`.
 
 ### privé -- *private mount*
 
-C'est le mode le plus simple : ici les points de montage ne sont tout
+C'est le mode le plus simple : ici les points de montage ne sont tout
 simplement pas propagés.
 
 Pour forcer un point d'accroche à ne pas propager et à ne pas recevoir de
-propagation, on utilise l'option suivante :
+propagation, on utilise l'option suivante :
 
 <div lang="en-US">
 ```bash
@@ -224,7 +224,7 @@ mount --make-unbindable /mnt/test-slave
 ```
 </div>
 
-Il ne sera pas possible de faire :
+Il ne sera pas possible de faire :
 
 <div lang="en-US">
 ```bash
@@ -238,7 +238,7 @@ mount --bind /mnt/test-slave /mnt/test-unbindable
 
 Les options que nous venons de voir s'appliquent sur un point de montage. Il
 existe les mêmes options pour les appliquer en cascade sur les points d'attache
-contenus dans leur sous-arbre :
+contenus dans leur sous-arbre :
 
 <div lang="en-US">
 ```bash
@@ -253,7 +253,7 @@ mount --make-runbindable mountpoint
 ## Montage miroir de dossiers et de fichiers
 
 Il n'est pas nécessaire que le point d'accroche que l'on cherche à dupliquer
-pointe sur un point de montage (c'est-à-dire, dans la plupart des cas : une
+pointe sur un point de montage (c'est-à-dire, dans la plupart des cas : une
 partition ou un système de fichiers virtuel). Il peut parfaitement pointer sur
 un dossier, et même sur un simple fichier, à la manière d'un *hardlink*, mais
 que l'on pourrait faire entre plusieurs partitions et qui ne persisterait pas
@@ -272,7 +272,7 @@ faire même si un fichier est en cours d'utilisation. Il faut cependant veiller
 à ce que les programmes susceptibles d'aller chercher un fichier à l'ancien
 emplacement soient prévenus du changement.
 
-Pour déplacer un point de montage, on utilise l'option `--move` de `mount(8)` :
+Pour déplacer un point de montage, on utilise l'option `--move` de `mount(8)` :
 
 <div lang="en-US">
 ```bash
@@ -280,7 +280,7 @@ mount --move olddir newdir
 ```
 </div>
 
-Par exemple :
+Par exemple :
 
 <div lang="en-US">
 ```bash
@@ -289,7 +289,7 @@ mount --move /dev /newroot/dev
 </div>
 
 Cette possibilité s'emploie notamment lorsque l'on souhaite changer la racine
-de notre système de fichiers : par exemple pour passer de l'*initramfs* au
+de notre système de fichiers : par exemple pour passer de l'*initramfs* au
 système démarré, de notre système hôte au système d'un conteneur, ...
 
 
@@ -299,6 +299,6 @@ Voici quelques articles qui valent le détour, en lien avec les points de
 montage :
 
 * [Shared subtree](https://lwn.net/Articles/159077) (<https://lwn.net/Articles/159077>) et la
-  [documentation du noyau associée](https://kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) (<https://kernel.org/doc/Documentation/filesystems/sharedsubtree.txt>) ;
+  [documentation du noyau associée](https://kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) (<https://kernel.org/doc/Documentation/filesystems/sharedsubtree.txt>) ;
-* [Mount namespaces and shared subtrees](https://lwn.net/Articles/689856) : <https://lwn.net/Articles/689856> ;
+* [Mount namespaces and shared subtrees](https://lwn.net/Articles/689856) : <https://lwn.net/Articles/689856> ;
 * [Mount namespaces, mount propagation, and unbindable mounts](https://lwn.net/Articles/690679) : <https://lwn.net/Articles/690679>.

tutorial/4/networkns.md

@@ -63,7 +63,7 @@ des interfaces :
 Cette commande ne nous montre que l'interface de *loopback*, car nous n'avons
 pour l'instant pas encore attaché la moindre interface.
 
-D'ailleurs, cette interface est rapportée comme étant désactivée, activons-là
+D'ailleurs, cette interface est rapportée comme étant désactivée, activons-la
 via la commande :
 
 <div lang="en-US">
@@ -72,7 +72,7 @@ via la commande :
 ```
 </div>
 
-À ce stade, nous pouvons déjà commencer à lancer un `ping` sur cette interface:
+À ce stade, nous pouvons déjà commencer à lancer un `ping` sur cette interface :
 
 <div lang="en-US">
 ```

tutorial/4/pidns.md

@@ -91,7 +91,7 @@ de noms.
 [^PR_SET_CHILD_SUBREAPER]: en réalité, ce comportement est lié à la propriété
   `PR_SET_CHILD_SUBREAPER`, qui peut être définie pour n'importe quel processus
   de l'arborescence. Le processus au PID 1 hérite forcément de cette propriété\ ;
-  il va donc récupérer tous les orphelins, si aucun de leurs parents n'ont la
+  il va donc récupérer tous les orphelins, si aucun de leurs parents n'a la
   propriété définie.
 
 Lorsque l'on lance un processus via `nsenter(1)` ou `setns(2)`, cela crée un

tutorial/4/setns.md

@@ -11,7 +11,7 @@ symbolique, représentant l'espace de nom.
 #### Voir les *namespace*s d'un processus
 
 Chaque processus lancé est rattaché à une liste d'espaces de nom, y compris
-s'il est issu du système de base (« l'hôte »).
+s'il est issu du système de base (« l'hôte »).
 
 Nous pouvons dès lors consulter le dossier `/proc/<PID>/ns/` de chaque
 processus, pour consulter les différents espaces de nom de nos processus.

tutorial/4/setup.md

@@ -3,7 +3,7 @@
 
 #### Noyau Linux
 
-Pour pouvoir suivre les exercices ci-après, vous devez disposez d'un noyau
+Pour pouvoir suivre les exercices ci-après, vous devez disposer d'un noyau
 Linux, idéalement dans sa version 5.6 ou mieux. Il doit de plus être compilé
 avec les options suivantes (lorsqu'elles sont disponibles pour votre version) :
 

tutorial/devops/devops.md

@@ -57,7 +57,7 @@ Chez Google (et d'autres entreprises qui ont depuis repris l'idée), des équipe
 sont chargées de développer la fiabilité des systèmes d'information de
 production. Ce sont les équipes SRE, pour Site Reliability Engineering. On
 confie alors complètement la responsabilité de l'environnement de production
-aux développeurs qui sont chargés de l'automatiser. Au delà de l'automatisation
+aux développeurs qui sont chargés de l'automatiser. Au-delà de l'automatisation
 des déploiements de services, il s'agit ici de développer des mécanismes
 permettant au système de réagir face aux situations telles que les montées en
 charges, les pannes, ...
@@ -108,7 +108,7 @@ Dans le cas d'un programme à télécharger
 ([Python](https://buildbot.python.org/all/#/), VLC,
 [MariaDB](https://buildbot.askmonty.org/buildbot/), ...), on va placer les
 paquets sur le site internet, éventuellement mettre à jour un fichier pointant
-vers la dernière version (pour que les utilisateurs aient la notifications).
+vers la dernière version (pour que les utilisateurs aient la notification).
 
 Ou bien dans le cas d'un service en ligne (GitHub, Netflix, GMail, ...), il
 s'agira de mettre à jour le service.
@@ -166,7 +166,7 @@ outils.
 **Basée sur les métriques** comme ELK, Prometheus, InfluxDB, ... : dans la
 stack TICK que nous avons mis en place précédemment, nous avions placé un
 agent sur la machine que nous souhaitions analyser. Outre les graphiques
-présenté dans Chronograf, le dernier outil que l'on n'avait pas configuré était
+présentés dans Chronograf, le dernier outil que l'on n'avait pas configuré était
 Kapacitor, qui permet après avoir analysé les données, d'alerter en fonction
 d'une évolution.
 
@@ -177,7 +177,7 @@ faire remonter dans sa base de données de métriques.
 \
 
 La différence entre les deux techniques est que nagios va vous alerter à partir
-d'un certain seuil que vous aurez préalablement défini (s'il reste moins de 10%
+d'un certain seuil que vous aurez préalablement défini (s'il reste moins de 10 %
 d'espace disque par exemple), tandis que Kapacitor va tenter d'interpréter les
 indicateurs (et donc vous alerter seulement si la courbe représentant l'espace
 disque disponible augmente de telle sorte qu'il ne reste plus que quelques
@@ -193,7 +193,7 @@ Enfin, citons le [Chaos Monkey](https://fr.wikipedia.org/wiki/Chaos_Monkey),
 conçu par Netflix, qui est un programme qui va casser de manière aléatoire des
 éléments de l'environnement de production. Le but est de provoquer sciemment
 des pannes, des latences, ... à n'importe quel niveau du produit, afin d'en
-tester (brulatement certes) sa résilience. Cela oblige les développeurs, les
+tester (brutalement certes) sa résilience. Cela oblige les développeurs, les
 opérationnels et les architectes à concevoir des services hautement tolérant
 aux pannes, ce qui fait que le jour où une véritable panne survient, elle n'a
 aucun impact sur la production (enfin on espère !).

tutorial/devops/publish-docker.md

@@ -72,7 +72,7 @@ docker run --rm -p 8080:8080 localhost:5000/youp0m
 
 ::::: {.question}
 On notera que ceci est possible exclusivement parce que le registre
-`localhost:5000` est considéré non-sûr par défaut. C'est à dire qu'il n'a pas
+`localhost:5000` est considéré non-sûr par défaut. C'est-à-dire qu'il n'a pas
 besoin de certificat TLS sur sa connexion HTTP pour être utilisé.\
 Si on avait dû utiliser un autre nom de domaine, il aurait fallu
 [l'ajouter à la liste des

tutorial/devops/tools-drone-cmd.md

@@ -1,6 +1,6 @@
 Tout comme Gitea, Drone tire un certain nombre de paramètres depuis son
 environnement. Nous allons donc commencer par indiquer l'identifiant et le
-secret de l'application que l'on a créé précédemment dans Gitea :
+secret de l'application que l'on a créés précédemment dans Gitea :
 
 <div lang="en-US">
 ```shell

tutorial/devops/tools-drone-runner-end.md

@@ -2,7 +2,7 @@
 
 On remarquera que l'on partage notre socket Docker : l'exécution de code
 arbitraire n'aura pas lieu directement dans le conteneur, en fait il s'agit
-d'un petit orchetrateur qui lancera d'autres conteneurs en fonction des tâches
+d'un petit orchestrateur qui lancera d'autres conteneurs en fonction des tâches
 qu'on lui demandera. Le code arbitraire sera donc toujours exécuté dans un
 conteneur moins privilégié.
 

tutorial/devops/tools-drone.md

@@ -11,7 +11,7 @@ moderne, conçue tout autour de Docker. Idéale pour nous !
 Deux conteneurs sont à lancer : nous aurons d'un côté l'interface de contrôle
 et de l'autre un agent (*runner* dans le vocabulaire de Drone) chargé
 d'exécuter les tests. Dans un environnement de production, on aura généralement
-plusieurs agents, et ceux-ci seront situé sur des machines distinctes.
+plusieurs agents, et ceux-ci seront situés sur des machines distinctes.
 
 ### Interface de contrôle et de dispatch des tâches
 

tutorial/devops/tools-gitea.md

@@ -6,7 +6,7 @@ gestionnaire de versions. Nous allons ici utiliser Git.
 
 ### Problématique du stockage des produits de compilation
 
-Outre les interfaces rudimentaires fournies au dessus de Git
+Outre les interfaces rudimentaires fournies au-dessus de Git
 ([gitweb](https://git.wiki.kernel.org/index.php/Gitweb)), il y a de nombreux
 projets qui offrent davantage que le simple hébergement de dépôts. Vous pouvez
 voir sur GitHub notamment qu'il est possible d'attacher à un tag un [certain

tutorial/devops/what-gistre.md

@@ -7,18 +7,18 @@ Bienvenue dans la société Électropcool !
 
 Électropcool est une société française spécialisée dans
 l'[immotique](https://fr.wikipedia.org/wiki/Immotique), elle vend des
-équipements IoT, principalement à destination des professionels du bâtiment. Le
+équipements IoT, principalement à destination des professionnels du bâtiment. Le
 produit phare est une plate-forme de
 [GTB](https://fr.wikipedia.org/wiki/Gestion_technique_de_b%C3%A2timent)
 modulaire de suivi de la vie d'un bâtiment où sont regroupés les différents
 compteurs, capteurs et actionneurs que l'on retrouve dans les installations.
 Les nouveaux bâtiments conçus autour la plate-forme permettent de faire de
-sérieuses économies d'entretien (en ne faisant déplacer les techiciens que
+sérieuses économies d'entretien (en ne faisant déplacer les techniciens que
 lorsque c'est nécessaire) tout en permettant d'anticiper les problèmes (grâce à
 un moteur de *machine-learning* capable d'anticiper les pannes) et les besoins
 en combustible (liés à la météo)[^HOMEASSISTANT].
 
-[^HOMEASSISTANT]: Si ça vous met l'eau à la bouche, jettez un œil du côté du
+[^HOMEASSISTANT]: Si ça vous met l'eau à la bouche, jetez un œil du côté du
     projet <https://www.home-assistant.io/> qui fait un peu moins de
     *bullshit*, mais est bien réel !
 
@@ -51,7 +51,7 @@ Une grosse partie des travaux est donc réalisé avec un noyau Linux, sur du
 matériel très performant, pour de l'embarqué.
 \
 
-Tous les modules logiciels qui interragissent avec les capteurs sont
+Tous les modules logiciels qui interagissent avec les capteurs sont
 aujourd'hui intégrés dans un système construit à l'aide de
 [`bitbake`](https://www.yoctoproject.org/). L'entreprise grossissant à vue d'œil,
 il devient de plus en plus difficile de synchroniser les équipes concilier la
@@ -70,7 +70,7 @@ défaillant.
 Vous êtes également chargés de jeter les bases du système d'intégration continu
 des modules. (La partie déploiement continu, sera réalisé plus tard par
 l'équipe développant le nouveau système de base, suivant le meilleur outil que
-retiendrez.)
+vous retiendrez.)
 \
 
 Le projet qui vous servira de base pour vos tests sera

tutorial/docker-advanced/compose.md

@@ -54,7 +54,7 @@ run`.
 
 #### `volumes`
 
-Cette section est le pendant de la commandes `docker volume`.
+Cette section est le pendant de la commande `docker volume`.
 
 On déclare les volumes simplement en leur donnant un nom et un driver comme
 suit :
@@ -83,7 +83,7 @@ l'emplacement à partager :
 
 #### `network`
 
-Cette section est le pendant de la commandes `docker network`.
+Cette section est le pendant de la commande `docker network`.
 
 Par défaut, Docker relie tous les conteneurs sur un bridge et fait du NAT pour
 que les conteneurs puissent accéder à l'Internet. Mais ce n'est pas le seul
@@ -113,7 +113,7 @@ les ports ouverts par la machine hôte.
 
 Avec le driver `null`, la pile réseau est recréée et aucune interface (autre
 que l'interface de loopback) n'est présente. Le conteneur ne peut donc pas
-accéder à Internet, ni aux autres conteneur, ...
+accéder à Internet, ni aux autres conteneurs, ...
 
 Lorsque l'on exécute un conteneur qui n'a pas besoin d'accéder au réseau, c'est
 le driver à utiliser. Par exemple pour un conteneur dont le but est de vérifier
@@ -127,7 +127,7 @@ conteneurs qui la référencent.
 
 Avec cette configuration, les conteneurs ont accès à une résolution DNS des
 noms de conteneurs qui partagent leur bridge. Ainsi, sans avoir à utiliser la
-fonctionnalité de `link` au moment du `run`, il est possible de se retrouvé
+fonctionnalité de `link` au moment du `run`, il est possible de se retrouver
 lié, même après que l'on ait démarré. La résolution se fera dynamiquement.
 
 

tutorial/docker-advanced/what.md

@@ -6,9 +6,9 @@ Orchestrer un groupe de conteneurs
 Maintenant que nous savons démarrer individuellement des conteneurs et les lier
 entre-eux, nous allons voir une première manière d'automatiser cela.
 
-Plutôt que de lancer les commandes `docker` comme nous l'avons fait jusque là :
+Plutôt que de lancer les commandes `docker` comme nous l'avons fait jusque-là :
 soit directement dans un terminal, soit via un script, nous allons décrire
-l'état que nous souhaitons atteindre : quels images lancer, quels volumes
+l'état que nous souhaitons atteindre : quelles images lancer, quels volumes
 créer, quels réseaux, etc. Cette description peut s'utiliser pour lancer un
 conteneur seul, mais elle prend tout son sens lorsqu'il faut démarrer tout un
 groupe de conteneurs qui fonctionnent de concert, parfois avec des dépendances
@@ -31,7 +31,7 @@ génériques et pouvant facilement être mis à l'échelle.
 
 Nous collecterons les données d'utilisation de votre machine avec
 [Telegraf](https://www.influxdata.com/time-series-platform/telegraf/). Ces
-données seront envoyés vers
+données seront envoyées vers
 [InfluxDB](https://www.influxdata.com/time-series-platform/influxdb/), puis
 elles seront affichées sous forme de graphique grâce à
 [Chronograf](https://www.influxdata.com/time-series-platform/chronograf/).

tutorial/docker-basis/cleaning.md

@@ -7,7 +7,7 @@ d'informations dépréciées.
 
 Dans la mesure du possible, Docker essaie de ne pas encombrer inutilement votre
 disque dur avec les vieilles images qui ne sont plus utilisées. Il ne va
-cependant jamais supprimer une image encore liée à un conteneur ; il ne
+cependant jamais supprimer une image encore liée à un conteneur ; il ne
 supprimera pas non plus les conteneurs qui n'auront pas été démarrés avec
 l'option `--rm`.
 

tutorial/docker-basis/ex-owncloud.md

@@ -1,6 +1,6 @@
 ::::: {.exercice}
 
-Pour mettre en pratiques toutes les notions que l'on a vu jusque là, écrivez un
+Pour mettre en pratiques toutes les notions que l'on a vues jusque-là, écrivez un
 script `mycloud-run.sh` pour automatiser le lancement de votre instance
 personnelle de [`nextcloud`](https://hub.docker.com/_/nextcloud/) ou
 d'[`owncloud`](https://hub.docker.com/r/owncloud/server/). Une attention
@@ -29,7 +29,7 @@ exemple).
 
 L'exécution doit être la plus sécurisée possible (pas de port MySQL exposé sur
 l'hôte par exemple, etc.) et la plus respectueuse des bonnes pratiques que l'on
-a pu voir jusque là.
+a pu voir jusque-là.
 
 
 ### Exemple d'exécution {-}

tutorial/docker-basis/first.md

@@ -45,9 +45,9 @@ docker image pull ubuntu
 
 Les registres publics tels quel le Docker Hub mettent à disposition des images
 officielles, mais aussi des images créées par la communauté. Chaque utilisateur
-est libre d'envoyer une image qu'il a lui-même créé : soit car l'éditeur ne
+est libre d'envoyer une image qu'il a lui-même créée : soit car l'éditeur ne
 proposait pas d'image et que quelqu'un s'est dévoué pour la faire, soit parce
-qu'il avait des besoins plus spécifiques qui n'étaient pas couvert par l'image
+qu'il avait des besoins plus spécifiques qui n'étaient pas couverts par l'image
 originale. Il est important de garder en tête que vous téléchargez des
 exécutables, et bien qu'ils s'exécutent dans un environnement isolé, ils
 peuvent contenir du code malveillant.
@@ -62,7 +62,7 @@ assurez-vous d'avoir confiance dans la personne affiliée à l'image.**
 
 Remarquez comment on interagit avec chaque *objet Docker* : dans la ligne de
 commande, le premier mot clef est le type d'objet (`container`, `image`,
-`service`, `network`, `volume`, ...) ; ensuite, vient l'action que l'on
+`service`, `network`, `volume`, ...) ; ensuite, vient l'action que l'on
 souhaite faire dans ce cadre.[^oldcall]
 
 [^oldcall]: cela n'a pas toujours été aussi simple, cette syntaxe n'existe que

tutorial/docker-basis/installation.md

@@ -4,7 +4,7 @@ Installation
 Docker repose sur plusieurs techniques implémentées dans les noyaux Linux
 récents (et plus marginalement, Windows). Ces techniques, contrairement aux
 instructions de virtualisation qui rendent les hyperviseurs attractifs, ne sont
-pas limitées à une architecture de microprocesseur spécifique ; cependant la
+pas limitées à une architecture de microprocesseur spécifique ; cependant la
 communauté autour de Docker utilise principalement l'architecture `amd64`,
 c'est sur cette dernière que Docker pourra être exploité à son plein potentiel,
 suivi de près par l'architecture `arm64`.
@@ -97,7 +97,7 @@ Si vous rencontrez des difficultés pour vous lancer, le projet Play With
 Docker[^PlayWithDocker] vous donne accès à un bac à sable
 dans lequel vous pourrez commencer à faire les exercices à suivre.
 
-[^PlayWithDocker]: Play With Docker est accessible à cette addresse : <https://labs.play-with-docker.com/>
+[^PlayWithDocker]: Play With Docker est accessible à cette adresse : <https://labs.play-with-docker.com/>
 
 Il vous faudra disposer [d'un compte
 Docker](https://hub.docker.com/signup). Une fois identifié, vous pourrez créer

tutorial/docker-basis/linking-ex-help.md

@@ -1,10 +1,10 @@
 ### Au secours, ça veut pas se connecter !
 
 Lorsque nous lançons pour la première fois notre conteneur MySQL ou MariaDB, un
-script est chargé d'initialisé le volume attaché à `/var/lib/mysql`. Les
+script est chargé d'initialiser le volume attaché à `/var/lib/mysql`. Les
-démarrage suivant, ou si vous réutilisez un volume déjà initialisé avec une
+démarrages suivant, ou si vous réutilisez un volume déjà initialisé avec une
 base de données, le script ne refait pas d'initialisation. Même si les
-variables d'environnement ont changées.
+variables d'environnement ont changé.
 
 Si vous rencontrez des difficultés pour connecter votre conteneur à
 `my-db`, prenez le temps de recréer un volume.

tutorial/docker-basis/linking.md

@@ -21,11 +21,11 @@ Mais avant, regardons d'un peu plus près la gestion des réseaux par Docker.
 
 ## Les pilotes réseau
 
-Docker propose de base trois pilotes (*drivers*) pour « gérer » cela :
+Docker propose de base trois pilotes (*drivers*) pour « gérer » cela :
 
 - `none` : pour limiter les interfaces réseau du conteneur à l'interface de
-  loopback `lo` ;
+  loopback `lo` ;
-- `host` : pour partager la pile réseau avec l'hôte ;
+- `host` : pour partager la pile réseau avec l'hôte ;
 - `bridge` : pour créer une nouvelle pile réseau par conteneur et rejoindre un
   pont réseau dédié.
 
@@ -64,7 +64,7 @@ directement accessible, sans avoir à utiliser l'option `-p` du `run`.
 ### Créer un nouveau réseau `bridge`
 
 Afin de contrôler quels échanges peuvent être réalisés entre les conteneurs, il
-est recommandé de créer des réseaux utilisateur.
+est recommandé de créer des réseaux utilisateurs.
 
 La création d'un réseau se fait tout simplement au travers des sous-commandes
 relatives aux objets Docker `network` :

tutorial/docker-basis/volumes.md

@@ -12,7 +12,7 @@ volumes.
 Il est possible d'utiliser la dernière couche en lecture/écriture pour inscrire
 des données. Il n'est cependant pas recommandé de stocker des données de cette
 manière, car elles ne vont pas persister une fois que le conteneur aura terminé
-son exécution ; elles seront alors plus compliquées à retrouver manuellement.
+son exécution ; elles seront alors plus compliquées à retrouver manuellement.
 
 Docker met à notre disposition plusieurs mécanismes pour que les données de nos
 applications persistent et soient prêtes à migrer plus facilement vers une

tutorial/docker-basis/what.md

@@ -67,7 +67,7 @@ proposent également.
 Alors que les images constituent la partie immuable de Docker, les conteneurs
 sont sa partie vivante. Chaque conteneur est créé à partir d'une image : à
 chaque fois que nous lançons un conteneur, une couche lecture/écriture est
-ajoutée au dessus de l'image. Cette couche est propre au conteneur et
+ajoutée au-dessus de l'image. Cette couche est propre au conteneur et
 temporaire : l'image n'est pas modifiée par l'exécution d'un conteneur.
 
 ![Couches d'un conteneur](layers-multi-container.png "Couches d'un conteneur"){ width=70% }

tutorial/docker-internals/clair.md

@@ -3,7 +3,7 @@
 Un outil complet indexer et chercher des vulnérabilités est
 [`Clair`](https://github.com/coreos/clair/), du projet CoreOS. À partir des
 informations mises à disposition par les équipes de sécurités des principales
-distributions, cela alimente en continu une base de données qui sera accéder au
+distributions, cela alimente en continu une base de données qui sera accédé au
 moment de l'analyse.
 
 L'outil se présente sous la forme d'un serveur autonome dans la récupération

tutorial/docker-internals/linuxkit-content.md

@@ -68,7 +68,7 @@ shell sur la machine !
 On notera cependant que, positionné dans `services`, le shell que nous
 obtiendrons sera lui-même exécuté dans un conteneur, nous n'aurons donc pas un
 accès entièrement privilégier. Pour déboguer, il faut placer cette image dans
-la partie `init`, elle sera alors lancé comme un équivalent de
+la partie `init`, elle sera alors lancée comme un équivalent de
 `init=/bin/sh`.[^infogetty]
 
 [^infogetty]: Plus d'infos à
@@ -177,7 +177,7 @@ serveur SSH aux `services` :
 ```
 </div>
 
-Comme nous n'avons définis aucun mot de passe, il va falloir utiliser une clef
+Comme nous n'avons défini aucun mot de passe, il va falloir utiliser une clef
 SSH pour se connecter. Voilà un bon début d'utilisation de la section `files` :
 
 <div lang="en-US">

tutorial/docker-internals/oci.md

@@ -9,9 +9,9 @@ fragmentation de l'écosystème.
 
 Trois spécifications ont été écrites :
 
-- [`runtime-spec`](https://github.com/opencontainers/runtime-spec/blob/master/spec.md#platforms): définit les paramètres du démarrage d'un conteneur ;
+- [`runtime-spec`](https://github.com/opencontainers/runtime-spec/blob/master/spec.md#platforms): définis les paramètres du démarrage d'un conteneur ;
-- [`image-spec`](https://github.com/opencontainers/image-spec/blob/master/spec.md): définit la construction, le transport et la préparation des images ;
+- [`image-spec`](https://github.com/opencontainers/image-spec/blob/master/spec.md): définis la construction, le transport et la préparation des images ;
-- [`distribution-spec`](https://github.com/opencontainers/distribution-spec/blob/master/spec.md): définit la manière dont sont partagées et récupérées les images.
+- [`distribution-spec`](https://github.com/opencontainers/distribution-spec/blob/master/spec.md): définis la manière dont sont partagées et récupérées les images.
 
 
 ## `runtime-spec`
@@ -47,7 +47,7 @@ Le
 [manifest](https://github.com/opencontainers/image-spec/blob/master/manifest.md)
 est toujours le point d'entrée d'une image : il référence l'emplacement où
 trouver les différents éléments : configuration et couches. Lorsqu'une même
-image a des variation en fonction de l'architecture du processeur, du système
+image a des variations en fonction de l'architecture du processeur, du système
 d'exploitation, ... dans ce cas [l'index
 d'image](https://github.com/opencontainers/image-spec/blob/master/image-index.md)
 est utilisé pour sélectionner le bon manifest.
@@ -78,8 +78,8 @@ aussi en envoyer.
 ## Pour aller plus loin  {-}
 
 Si maintenant `docker` fait appel à un programme externe pour lancer
-effectivement nos conteneurs, c'est que l'on peut changer cette implémentation
+effectivement nos conteneurs, c'est que l'on peut changer cette
-? la réponse dans l'article :\
+implémentation ? la réponse dans l'article :\
 <https://ops.tips/blog/run-docker-with-forked-runc/>
 
 Et `containerd` dans l'histoire ?\

tutorial/docker-internals/registry.md

@@ -186,7 +186,7 @@ Pensez également à tester avec d'autres images, comme par exemple
 `nemunaire/youp0m`. Il vous faudra alors extraire plusieurs couches.
 
 Pour gérer les différentes couches, vous pouvez utiliser une stratégie
-similaire au driver `vfs` : en extrayant chaque tarball l'une au dessus de
+similaire au driver `vfs` : en extrayant chaque tarball l'une au-dessus de
 l'autre, en essayant de gérer les *whiteout files*. Ou bien en suivant le
 driver `overlayfs`, en montant un système de fichier à chaque couche (dans ce
 cas, votre script devra être lancé en `root`).

tutorial/docker-internals/runc.md

@@ -9,7 +9,7 @@ montages ou volumes, ... Attention, son rôle reste limité à la mise en place
 l'environnement conteneurisé, ce n'est pas lui qui télécharge l'image, ni fait
 l'assemblage des couches de système de fichiers, entre autres.
 
-Aujourd'hui, le lancement de conteneur est faite avec `runc`, mais il est
+Aujourd'hui, le lancement de conteneur est fait avec `runc`, mais il est
 parfaitement possible d'utiliser n'importe quel autre programme à sa place, à
 partir du moment où il expose la même interface à Docker et qu'il accepte les
 *bundle* OCI.

tutorial/docker-internals/vulnerability-scan.md

@@ -12,7 +12,7 @@ l'effort de cloisonnement mis en place.
 Mais doit-on pour autant s'arrêter là et considérer que nous avons réglé
 l'ensemble des problématiques de sécurité liées aux conteneurs ?
 
-Évidemment, non : une fois nos services lancés dans des conteneurs, il ne sont
+Évidemment, non : une fois nos services lancés dans des conteneurs, ils ne sont
 pas moins exposés aux bugs et autres failles applicatives ; qu'elles soient
 dans notre code ou celui d'une bibliothèque, accessible par rebond, ...
 
@@ -20,7 +20,7 @@ Il est donc primordial de ne pas laisser ses conteneurs à l'abandon une fois
 leur image créée et envoyée en production. Nos conteneurs doivent être
 regénérés sitôt que leur image de base est mise à jour (une mise à jour d'une
 image telle que Debian, Ubuntu ou Redhat n'apparaît que pour cela) ou bien
-lorsqu'un des programmes ou l'une des bibliothèques que l'on a installés
+lorsqu'un des programmes ou l'une des bibliothèques que l'on a installées
 ensuite est mise à jour.
 
 Convaincu ? Cela sonne encore comme des bonnes pratiques difficiles à mettre en
@@ -191,7 +191,7 @@ Total: 158 (UNKNOWN: 5, LOW: 19, MEDIUM: 64, HIGH: 61, CRITICAL: 9)
 
 Les résultats sont un peu différents qu'avec `docker scan`, mais on constate
 que l'image `mysql` contient vraiment de nombreuses vulnérabilités. Même si
-elles ne sont heureusement pas forcément exploitable directement.
+elles ne sont heureusement pas forcément exploitables directement.
 
 Voyons maintenant s'il y a des différentes avec l'image `nemunaire/fic-admin` :
 

tutorial/docker-orchestration/setup.md

@@ -6,7 +6,7 @@ notre machine hôte, même si ce n'est pas un Linux : le but va être de lancer
 plusieurs machines virtuelles dédiées à Docker pour simuler un cluster.
 
 Ce programme permet de simplifier la gestion de multiples environnements
-Docker, comme par exmple lorsque l'on souhaite gérer un cluster de machines
+Docker, comme par exemple lorsque l'on souhaite gérer un cluster de machines
 pour un projet.
 
 Ainsi, il est possible de provisionner et gérer des machines hôtes sur les
@@ -38,7 +38,7 @@ Hyper-V. Bien d'autres environnements peuvent être supportés, au moyen de
 plug-ins.
 
 Si vous utilisez KVM comme hyperviseur, vous allez avoir besoin d'installer le
-plugins
+plugin
 [`docker-machine-kvm`](https://github.com/machine-drivers/docker-machine-kvm). Vous
 n'aurez qu'à suivre les instructions du `README` :\
 <https://github.com/machine-drivers/docker-machine-kvm/>

tutorial/docker-orchestration/stack.md

@@ -101,7 +101,7 @@ consulter la documentation à ce sujet :\
 
 #### Mise à l'échelle et placement
 
-On parle depuis toute à l'heure de lancer plusieurs tâches pour le même
+On parle depuis tout à l'heure de lancer plusieurs tâches pour le même
 service. La mise à l'échelle, c'est ça : exécuter plusieurs conteneurs pour la
 même tâche afin de mieux répartir la charge, idéalement sur des machines
 physiques différentes.

tutorial/docker-orchestration/swarm.md

@@ -26,7 +26,7 @@ Swarm.
 
 #### Initialisation du cluster
 
-La première chose à faire est d'initialiser un cluster Swarm. Pour se faire,
+La première chose à faire est d'initialiser un cluster Swarm. Pour ce faire,
 ce n'est pas plus compliqué que de faire :
 
 <div lang="en-US">
@@ -46,7 +46,7 @@ attendant d'autres nœuds.
 Pour rejoindre un cluster, il est nécessaire d'avoir le jeton associé à ce
 cluster.
 
-La commande pour rejoindre un cluster et contenant le jeton est iniquée
+La commande pour rejoindre un cluster et contenant le jeton est indiquée
 lorsque vous initialisez le cluster. Si vous avez raté la sortie de la
 commande, vous pouvez retrouver le jeton avec :
 
@@ -102,7 +102,7 @@ Pour que l'algorithme de consensus fonctionne de manière optimale, il convient
 de toujours avoir un nombre impair de managers : Docker en recommande 3
 ou 5. La pire configuration est avec deux managers, car si l'un des deux tombe,
 il ne peut pas savoir si c'est lui qui est isolé (auquel cas il attendrait
-d'être à nouveau en ligne avant de se procalmer leader) ou si c'est l'autre qui
+d'être à nouveau en ligne avant de se proclamer leader) ou si c'est l'autre qui
 est tombé. Avec trois managers, en cas de perte d'un manager, les deux restants
 peuvent considérer qu'ils ont perdu le troisième et peuvent élire le nouveau
 manager entre eux et continuer à faire vivre le cluster.

tutorial/dockerfiles/dockerfile.md

@@ -151,7 +151,7 @@ suivante.
 
 Lorsqu'on lance la reconstruction du même `Dockerfile`, les images
 intermédiaires sont réutilisées, comme un cache d'instructions. Cela permet de
-gagner du temps sur les étapes qui n'ont pas changées. Ainsi, lorsque vous
+gagner du temps sur les étapes qui n'ont pas changé. Ainsi, lorsque vous
 modifiez une instruction dans votre `Dockerfile`, les instructions précédentes
 ne sont pas réexécutées mais sont ressorties du cache.
 
@@ -164,7 +164,7 @@ Il est possible de ne pas utiliser le cache et de relancer toutes les étapes du
 `Dockerfile` en ajoutant l'option `--no-cache` au moment du `docker image
 build`.
 
-Les couches du cache peuvent être partagées entre plusieurs conteneur, c'est
+Les couches du cache peuvent être partagées entre plusieurs conteneurs, c'est
 ainsi que vous pouvez partager facilement une plus grosse partie du système de
 fichiers (rappelez-vous le principe d'union FS).
 
@@ -195,7 +195,7 @@ pour indiquer que c'est vous qui maintenez cette image, si des utilisateurs ont
 besoin de vous avertir pour le mettre à jour ou s'ils rencontrent des
 difficultés par exemple.
 
-On le place dès le début, car comme c'est une information qui n'est pas amener
+On le place dès le début, car comme c'est une information qui n'est pas amenée
 à changer, elle sera toujours retrouvée en cache.
 
 

tutorial/dockerfiles/goodpractices.md

@@ -4,12 +4,12 @@ Les bonnes pratiques
 --------------------
 
 Pour chaque bonne pratique ci-dessous, vérifiez que vous la respectez
-bien, faites les modifications nécessaire dans votre `Dockerfile`.
+bien, faites les modifications nécessaires dans votre `Dockerfile`.
 
 ### Utilisez le fichier `.dockerignore`
 
 Dans la plupart des cas, vos `Dockerfile` seront dans des dossiers contenant
-beaucoup de fichiers qui ne sont pas nécessaire à la construction de votre
+beaucoup de fichiers qui ne sont pas nécessaires à la construction de votre
 conteneur (par exemple, vous pouvez avoir un `Dockerfile` placé à la racine
 d'un dépôt git).
 
@@ -22,7 +22,7 @@ vous utilisez un langage compilé, excluez également les produits de compilatio
 si votre image construit le binaire. Dans le cas de NodeJS, vous allez sans
 doute vouloir exclure le dossier `node_modules` et faire un `npm install` dans
 votre `Dockerfile`. Cela permettra au passage de s'assurer que toutes les
-dépendances ont bien été enregistrée.
+dépendances ont bien été enregistrées.
 
 Ce fichier fonctionne de la même manière que le `.gitignore` : vous pouvez
 utiliser du globing.
@@ -123,7 +123,7 @@ Il y a un certain nombre de règles à connaître pour bien utiliser ce mécanis
   dans le `Dockerfile` vont être exécutées.
 
 
-### Concevez des conteneur éphémères
+### Concevez des conteneurs éphémères
 
 Les conteneurs que vous générez doivent être aussi éphémères que possible : ils
 devraient pouvoir être arrêtés, détruits et recréés sans nécessiter d'étape de
@@ -155,7 +155,7 @@ modifier la configuration des autres logiciels contenu dans d'autres conteneurs
 puisqu'ils sont généralement configurés pour se connecter aux ports standards.
 
 S'il y a un conflit sur la machine hôte, il sera toujours temps de créer une
-redirection à ce moment là.
+redirection à ce moment-là.
 
 
 ### La bonne utilisation de l'`ENTRYPOINT`
@@ -165,7 +165,7 @@ utilisé de deux manières différentes :
 
 - Vous pouvez l'utiliser de telle sorte que la commande passée au `docker run`,
   après le nom de l'image, corresponde aux arguments attendu par le programme
-  indiqué dans l'*entrypoint*. Par exemple pour nginx :
+  indiqué dans l'*entrypoint*. Par exemple pour `nginx` :
 
 <div lang="en-US">
 ```dockerfile
@@ -208,7 +208,7 @@ prendre deux formes :
   arguments. Si d'éventuels variables se trouve dans les arguments, elles ne
   seront pas remplacées.
 - `cmd arg1 arg2` : ici l'exécution se fera au sein d'un `sh -c`, donc les
-  variables seront remplacés et étendues.
+  variables seront remplacées et étendues.
 
 Les commandes sous forme de tableau étant parsées par un parser JSON, vous ne
 pouvez pas utiliser les *simples quotes*.

tutorial/dockerfiles/interactive.md

@@ -33,7 +33,7 @@ quelles versions de nos dépendances on va récupérer.
 [^SECURITY_UPDATE]: Voir cet article :
 <https://pythonspeed.com/articles/security-updates-in-docker/>
 
-Si vous souhaitez disposez d'une nouvelle version de l'image, il est
+Si vous souhaitez disposer d'une nouvelle version de l'image, il est
 plutôt recommandé de contacter le mainteneur de l'image pour qu'il la
 mette à jour, en utilisant un nouveau tag s'il le juge nécessaire. Si
 cette solution n'est pas envisageable, alors il vaut mieux créer votre

tutorial/dockerfiles/others.md

@@ -126,7 +126,7 @@ Faites en sorte que le `Dockerfile` que vous avez créé pour `youp0m` indique u
 
 Il est aussi possible de se passer complètement de Docker. La plupart des
 outils qui sont capables de générer des images de machines virtuelles, sont
-aussi capable de générer des images Docker. Citons notamment :
+aussi capables de générer des images Docker. Citons notamment :
 
 - [Hashicorp Packer](https://www.packer.io/docs/builders/docker),
 - [Nix et Guix](https://nix.dev/tutorials/building-and-running-docker-images),

tutorial/k8s/discover.md

@@ -9,13 +9,13 @@ Découverte de `kubectl`
 programme que l'on utilise pour interagir avec notre cluster.
 
 Étant donné qu'il s'agit d'un programme client, qui ne fait rien de plus que
-discuter avec une API REST HTTP, on peut le considérer comme un gros wrapper au
+discuter avec une API REST HTTP, on peut le considérer comme un gros wrapper
-dessus de `curl`.
+au-dessus de `curl`.
 
 ### Obtenir de l'aide
 
 Commençons par apprivoiser `kubectl` en prenant quelques
-renseignements et surtout en apprennant comment obtenir de l'aide :
+renseignements et surtout en apprenant comment obtenir de l'aide :
 
 <div lang="en-US">
 ```bash
@@ -25,7 +25,7 @@ kubectl explain type
 </div>
 
 Les `type`s que vous pouvez découvrir sont ceux que l'on a vu à la
-sections précédentes : `node`, `pod`, ...
+section précédente : `node`, `pod`, ...
 
 La commande `describe` permet d'afficher l'état tel qu'il est attendu
 et tel qu'il est actuellement (cela permet de se rendre lorsque les

tutorial/k8s/discover2.md

@@ -1,7 +1,7 @@
 ::::: {.warning}
 
 Notez que le dashboard, avec cette configuration, va s'exécuter sans les
-prérequis minimum de sécurité : pas de certificat TLS, ni
+prérequis minimums de sécurité : pas de certificat TLS, ni
 d'authentification. Ceci est juste pour jouer avec l'interface, en production,
 on n'utilisera pas cette recette.
 
@@ -44,7 +44,7 @@ la partie `Service` un *node port* plus spécifique :
 ```
 
 Maintenant, nous n'allons pas recréer un nouveau dashboard : nous allons
-simplement « appliquer » la nouvelle configuration :
+simplement « appliquer » la nouvelle configuration :
 
 ```bash
 kubectl apply -f my-insecure-dashboard.yaml

tutorial/k8s/intro-book.md

@@ -6,5 +6,5 @@ Présentation du fil rouge
 Afin d'évaluer Kubernetes, nous allons travailler avec un mineur de
 pépites ... de chocolat !
 
-Alors, on se sert un bon thé, on prend sa boîte de gâteaux pour teniir le coup,
+Alors, on se sert un bon thé, on prend sa boîte de gâteaux pour tenir le coup,
 et c'est parti !

tutorial/k8s/setup.md

@@ -45,7 +45,7 @@ utiliser Kubernetes facilement :
 
 ### Docker for Mac/Windows {#dockerdesktop}
 
-*Docker Desktop* pour Mac ou pour Windows intégre Kubernetes directement. Il
+*Docker Desktop* pour Mac ou pour Windows intègre Kubernetes directement. Il
 n'est pas activé par défaut, pour cela il convient d'activer l'option dans les
 préférences de l'application :