Fix spelling and grammar mistakes across EN and FR content (chapter C)

content/fr/3.serveex/2.core/1.installation.md

@@ -40,7 +40,7 @@ Si vous êtes en dual boot avec Windows, désactivez son *démarrage rapide* : i
 
 Récupérez l'image **netinst** `amd64` sur [debian.org](https://www.debian.org/download.fr.html). Elle fait environ 700 Mo et récupère le reste des paquets sur le réseau pendant l'installation, ce qui est exactement ce qu'on veut sur un serveur branché en ethernet : vous obtenez des paquets à jour au lieu d'installer depuis un instantané vieux de plusieurs mois puis de tout mettre à jour derrière. Les images DVD complètes n'ont de sens que si la machine n'a pas de réseau pendant l'installation.
 
-#### Créer une clée bootable avec Rufus
+#### Créer une clé bootable avec Rufus
 
 Sous Windows, utilisez [Rufus](https://rufus.ie/) (portable, aucune installation nécessaire). Branchez une clé USB de 2 Go ou plus, en gardant en tête qu'**elle sera entièrement effacée**, puis :
 
@@ -160,7 +160,7 @@ Toujours sur l'autre machine, générez une clé.
 ssh-keygen -t ed25519
 ```
 
-Appuyez sur :kbd{value="Enter"} pour accepter le chemin par défaut, et mettez une passphrase (elle protège le fichier de clé lui-même, votre système la retiendra après le premier déverrouillage). Il s'agit ensuite de transmettre la clée publique à votre serveur. A noter que Windows n'a pas de `ssh-copy-id`, nous pousserons donc la clé manuellement dans ce cas :
+Appuyez sur :kbd{value="Enter"} pour accepter le chemin par défaut, et mettez une passphrase (elle protège le fichier de clé lui-même, votre système la retiendra après le premier déverrouillage). Il s'agit ensuite de transmettre la clé publique à votre serveur. À noter que Windows n'a pas de `ssh-copy-id`, nous pousserons donc la clé manuellement dans ce cas :
 
 ::code-group
 ```bash [macOS]

content/fr/3.serveex/2.core/3.wireguard.md

@@ -19,11 +19,11 @@ Il existe aussi des clients Windows, macOS, iOS et Android.
 Le principe est le suivant :
 
 - Sur internet, n'importe qui peut contacter n'importe quel box internet et donc essayer de contacter n'importe quel serveur exposé.
-- Votre serveur est sur votre réseau local. Il est accessible depuis le réseau local mais pas depuis internet, mis à part les services exposés (comme nous l'avons fait avec Dockge). Pour accéder aux ressources non exposées, vous devez être connecté sur le même réseau que votre serveur et donc être chez vous. De plus, vous devez laisser ouvert les ports utilisés par vos services à travers le pare feu de votre serveur.
+- Votre serveur est sur votre réseau local. Il est accessible depuis le réseau local mais pas depuis internet, mis à part les services exposés (comme nous l'avons fait avec Dockge). Pour accéder aux ressources non exposées, vous devez être connecté sur le même réseau que votre serveur et donc être chez vous. De plus, vous devez laisser ouverts les ports utilisés par vos services à travers le pare-feu de votre serveur.
 - Nous souhaitons ici au contraire, depuis n'importe où, pouvoir accéder de manière sécurisée aux services non exposés sur internet du serveur, comme la console SSH qui permet de se connecter à la machine par exemple.
 - Nous souhaitons aussi accéder aux services d'autres serveurs, et par exemple relier de manière sécurisée deux instances de Dockge pour tout contrôler depuis la même interface.
 
-Pour cela nous allons créer un **réseau privé virtuel**, ou VPN, c'est-à-dire un tunnel sécurisé auquel personne n'a accès à part les machines que vous relierez entre elles. Elles feront partie d'un nouveau réseau et pourront dialoguer entre elle comme dans un réseau local. 
+Pour cela nous allons créer un **réseau privé virtuel**, ou VPN, c'est-à-dire un tunnel sécurisé auquel personne n'a accès à part les machines que vous relierez entre elles. Elles feront partie d'un nouveau réseau et pourront dialoguer entre elles comme dans un réseau local. 
 
 D'autre part, vous pourrez ajouter votre téléphone, un ordinateur portable ou n'importe quel appareil au réseau pour pouvoir utiliser vos ressources depuis vos appareils quotidiens, où que vous soyez.
 
@@ -34,9 +34,9 @@ Dans cette illustration, la machine 1 est sur deux réseaux :
 - son réseau local (tous les appareils liés à la box, avec une adresse IP du type `192.168.x.x ` donc ici la machine 1 et la machine 2)
 - le réseau du VPN (tous les appareils reliés au VPN, avec une seconde adresse IP du type `10.8.x.x` donc ici la machine 1 et 4)
 
-On peut aussi faire en sorte que les machines reliées au réseau virtuel partagent les accès à leur réseau local. Ici nous ne le ferons pas, pour des raisons de sécurité, et de complexité en terme de sous-réseau (si les deux machines distantes ont des machines locales qui utilisent la même adresse IP locale, par exemple `192.168.1.1`, cela posera des conflits). 
+On peut aussi faire en sorte que les machines reliées au réseau virtuel partagent les accès à leur réseau local. Ici nous ne le ferons pas, pour des raisons de sécurité, et de complexité en termes de sous-réseau (si les deux machines distantes ont des machines locales qui utilisent la même adresse IP locale, par exemple `192.168.1.1`, cela posera des conflits). 
 
-Ainsi, sur le réseau virtuel, seules les machines directement reliées pourront dialoguer entre elle depuis ce réseau. Elles ne pourront pas dialoguer avec une machine situées sur un autre réseau local et non reliée au VPN.
+Ainsi, sur le réseau virtuel, seules les machines directement reliées pourront dialoguer entre elles depuis ce réseau. Elles ne pourront pas dialoguer avec une machine située sur un autre réseau local et non reliée au VPN.
 
 ## Côté serveur
 ::note{icon=""}