New spelling fixes

tutorial/devops/ci-about-webhook.md

@@ -3,7 +3,7 @@
 #### Que fait Drone pour « surveiller » un dépôt ? {-}
 \
 
-Grâce aux permissions de que Drone a récupéré lors de la connexion OAuth à
+Grâce aux permissions que Drone a récupéré lors de la connexion OAuth à
 Gitea, il peut non seulement lire et récupérer le code des différents dépôts
 auxquels vous avez accès, mais il peut aussi changer certains paramètres.
 
@@ -17,5 +17,5 @@ dépôt, sous l'onglet *Déclencheurs Web*.
 
 À chaque fois qu'un événement va se produire sur le dépôt, Gitea va prévenir
 Drone qui décidera si l'évènement doit conduire à lancer l'intégration continue
-ou non, selon les instructions qu'on lui a donné dans la configuration du
+ou non, selon les instructions qu'on lui a données dans la configuration du
 dépôt.

tutorial/devops/ci-tags.md

@@ -6,7 +6,7 @@ lors que la compilation est terminée, car nous n'en faisons rien.
 
 ::::: {.exercice}
 
-Ajoutons donc une nouvelle règle à notre `.droneci.yml` pour placer le binaire
+Ajoutons donc une nouvelle règle à notre `.drone.yml` pour placer le binaire
 au sein de la liste des fichiers téléchargeables aux côtés des tags.
 
 Vous aurez sans doute besoin de :

tutorial/devops/devops.md

@@ -13,7 +13,7 @@ en tête.\
 Ces contraintes : tant liées à la **sécurité** (il faut s'assurer
 qu'un service n'utilise pas une bibliothèque vulnérable par exemple, donc soit
 utilisé sur un système à jour, et qu'il ne tourne pas en `root`), qu'à la
-**disponibilité** (si le service est mal codé est contient beaucoup de fuites
+**disponibilité** (si le service est mal codé et contient beaucoup de fuites
 mémoire, il ne faut pas que les autres services présents sur la même machine en
 pâtissent).
 
@@ -29,7 +29,7 @@ Le même principe est aussi valable pour Python, Ruby, ... : les développeurs
 ont toujours eu tendance à vouloir utiliser les dernières améliorations d'un
 langage, mais les administrateurs système n'ont alors pas de paquets stables
 dans la distribution. En effet, les distributions stables telles que Debian,
-RedHat ou CentOS ont des cycles de vie assez long et se concentrent plus sur la
+RedHat ou CentOS ont des cycles de vie assez longs et se concentrent plus sur la
 stabilité.\
 Cette stabilité est obtenue grâce à l'utilisation de versions éprouvées des
 langages et des bibliothèques, qui assurent un temps de maintenance et de
@@ -197,6 +197,6 @@ conçu par Netflix, qui est un programme qui va casser de manière aléatoire de
 é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 (brutalement certes) sa résilience. Cela oblige les développeurs, les
-opérationnels et les architectes à concevoir des services hautement tolérant
+opérationnels et les architectes à concevoir des services hautement tolérants
 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-end-gistre.md

@@ -1,4 +1,4 @@
 ### Et ensuite ?
 
 Nous avons vu une manière possible de distribuer notre projet. Essayons-en une
-autre parmis celles proposées.
+autre parmi celles proposées.

tutorial/devops/publish-docker-end.md

@@ -7,7 +7,7 @@ Vous pouvez néanmoins tester les plugins
 [`scp`](http://plugins.drone.io/appleboy/drone-scp/) ou
 [`ansible`](http://plugins.drone.io/drone-plugins/drone-ansible/) si vous avez
 une machine virtuelle avec une connexion SSH. N'hésitez pas à l'ajouter à votre
-`.droneci.yml`.
+`.drone.yml`.
 
 
 ### Profitons !

tutorial/devops/renovate-cmd.md

@@ -12,7 +12,7 @@ La commande que nous allons utiliser pour lancer Renovatebot est la suivante :
 <div lang="en-US">
 ```shell
 docker container run --name renovate --network my_ci_net \
-    -e RENOVATE_ENDPOINT="http://gitea:3000/api/v1/" RENOVATE_PLATFORM=gitea \
+    -e RENOVATE_ENDPOINT="http://gitea:3000/api/v1/" -e RENOVATE_PLATFORM=gitea \
     -e RENOVATE_TOKEN -e RENOVATE_GIT_AUTHOR="Renovatebot <renovate@sample>" \
     -e RENOVATE_AUTODISCOVER=true -e RENOVATE_LOG_LEVEL=info -d \
     renovate/renovate

tutorial/devops/renovate-end.md

@@ -2,7 +2,7 @@ Dès que le conteneur sera lancé, nous devrions voir apparaître une ou plusieu
 *pull-requests* pour le projet `youp0m`. Si votre CI est configurée
 correctement, des tests automatiques seront lancés.
 
-Le conteneur s'arrête dès qu'il a terminé d'analysé tous les dépôts. Vous
+Le conteneur s'arrête dès qu'il a terminé d'analyser tous les dépôts. Vous
 devrez le relancer si vous attendez une nouvelle action de la part de
 Renovatebot. Il est courant de le lancer entre chaque heure et 2 ou 4 fois par
 jour.
@@ -18,7 +18,7 @@ consultez la liste des éléments de configuration :
 
 Ne soyez pas effrayé par la liste interminable d'options. Il est vrai que la
 première fois, on peut se sentir submergé de possibilités, mais il faut noter
-que le projet arriver avec des options par défaut plutôt correctes, et que l'on
+que le projet arrive avec des options par défaut plutôt correctes, et que l'on
 peut facilement avoir une configuration commune pour tous nos dépôts, à travers
 les *presets*.
 
@@ -26,7 +26,7 @@ Un certain nombre de *presets* sont distribués par défaut, voici la liste
 (humainement lisible cette fois) :
 <https://docs.renovatebot.com/presets-default/>
 
-Voici un exemple de configuration que vous pouvez utilisé comme base de tous
+Voici un exemple de configuration que vous pouvez utiliser comme base de tous
 vos projets :
 
 <div lang="en-US">
@@ -69,7 +69,7 @@ Voici un exemple de fichier `default.json` que vous pourriez vouloir utiliser :
 Attention, on ne le répétera jamais assez, mais Renovatebot peut vite devenir
 infernal, car il va créer de nombreuses *pull-requests*, inlassablement. Il
 convient de rapidement activer la fusion automatique des mises à jour pour
-lesquelles vous avez confiances et pour lesquelles vous ne feriez qu'appuyer
+lesquelles vous avez confiance et pour lesquelles vous ne feriez qu'appuyer
 sur le bouton de fusion, sans même tester vous-même. La fonctionnalité est
 décrite en détail dans la documentation[^RENOVATE_AUTOMERGE] et explique les
 différentes stratégies. Néanmoins, il est nécessaire d'avoir une bonne suite de

tutorial/devops/renovate.md

@@ -1,13 +1,13 @@
 Autres outils indispensables
 ----------------------------
 
-### Maintient à jour des dépendances
+### Maintien à jour des dépendances
 
 Une opération fastidieuse, souvent oubliée sitôt le projet envoyé en
 production, c'est la mise à jour des dépendances applicatives. Fastidieux car
 il faut d'une part être informé qu'une mise à jour est disponible, c'est-à-dire
 qu'il faut suivre les mails, parfois nombreux, informant des nouvelles
-*releases*, parfois il s'agir de newslettre, ou encore parfois aucune
+*releases*, parfois il s'agit de newsletters, ou encore parfois aucune
 notification ne peut être programmée, il faut se rendre régulièrement sur un
 site pour savoir si oui ou non une mise à jour est disponible.
 

tutorial/devops/run-gistre.md

@@ -64,7 +64,7 @@ accès au périphérique correspondant au compteur.
 
 ### Conteneur LXC
 
-LXC peut s'utiliser de multiple manière différentes, y compris avec des images
+LXC peut s'utiliser de multiples manières différentes, y compris avec des images
 OCI. Choisissez la méthode qui vous semble la plus appropriée, il est attendu
 au moins un script pour lancer notre conteneur, s'il est différent d'un
 

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

@@ -2,7 +2,7 @@ Voici à quoi pourrait ressembler le playbook Ansible démarrant notre agent Dro
 
 <div lang="en-US">
 ```yaml
-- name: Launch drone runer
+- name: Launch drone runner
   docker_container:
     name: droneci-runner
     image: "drone/drone-runner-docker:1"

tutorial/devops/what-gistre.md

@@ -44,10 +44,10 @@ fundation*, notamment les [Compute Module 3 et
 4](https://www.raspberrypi.com/products/compute-module-4/) et les [Raspberry Pi
 Zero 2 W](https://www.raspberrypi.com/products/raspberry-pi-zero-2-w/), ainsi
 que de nombreux PCB fait par l'entreprise, à base de micro-contrôleurs AVR,
-lorsqu'il est nécessaire de pour s'interfacer avec des équipements
+lorsqu'il est nécessaire pour s'interfacer avec des équipements
 propriétaires non prévu pour l'immotique.
 
-Une grosse partie des travaux est donc réalisé avec un noyau Linux, sur du
+Une grosse partie des travaux est donc réalisée avec un noyau Linux, sur du
 matériel très performant, pour de l'embarqué.
 \
 
@@ -68,7 +68,7 @@ entraver la stabilité de la plate-forme en cas de déploiement d'un module
 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
+des modules. (La partie déploiement continu, sera réalisée plus tard par
 l'équipe développant le nouveau système de base, suivant le meilleur outil que
 vous retiendrez.)
 \
@@ -90,5 +90,5 @@ quelques tests automatiques. Puis nous publierons automatiquement le binaire
 `linky2influx` comme fichier associé à un tag au sein de l'interface web du
 gestionnaire de versions.
 
-Nous testerons enfin différentes solution pour déployer notre binaire, afin
+Nous testerons enfin différentes solutions pour déployer notre binaire, afin
 d'établir quelle est la solution adéquate.

tutorial/devops/what.md

@@ -13,7 +13,7 @@ le projet `youp0m`, que l'on connaît déjà bien.
 \
 
 Dans un premier temps, on voudra juste compiler notre projet, pour s'assurer
-que chaque *commmit* poussé ne contient pas d'erreur de compilation (dans
+que chaque *commit* poussé ne contient pas d'erreur de compilation (dans
 l'environnement défini comme étant celui de production, donc avec une version
 précise des outils de compilation). Ensuite, nous ajouterons quelques tests
 automatiques, puis nous publierons automatiquement le binaire `youp0m` comme