Fix typos & spelling

4 files changed, 20 insertions, 20 deletions

diff --git a/src/Technique/Infra/Internet.md b/src/Technique/Infra/Internet.md
index 1f35d45..d067ff2 100644
--- a/src/Technique/Infra/Internet.md
+++ b/src/Technique/Infra/Internet.md
@@ -24,7 +24,7 @@ Certains FAI ne donnent pas d'IPv4 publique du tout (même pas au niveau du rout
 À la place, ils mettent en place un NAT nommé carrier-grade NAT que vous ne pouvez pas configurer.
 Parfois, il suffit de les appels.
 
-Exemple : Ora/Viti en Polynésie Française
+Exemple : Ora/Viti en Polynésie française
 
 #### Pas d'IPv6 du tout
 
@@ -77,7 +77,7 @@ Routeurs connus pour avoir des problèmes de NAT hairpinning :
 
   * Orange : Probablement toutes les box
     * Livebox 2 Sagem
-    * Livebox 4
+    * Livebox 4 Sagemcom
   * Bouygues : Suspicions sur toutes les box
   * Free : 100% OK
   * Numéricable : Inconnu
diff --git a/src/Technique/Jalon/Interconnexion.md b/src/Technique/Jalon/Interconnexion.md
index 0030db5..b46922a 100644
--- a/src/Technique/Jalon/Interconnexion.md
+++ b/src/Technique/Jalon/Interconnexion.md
@@ -1,6 +1,6 @@
 # Interconnectons nos infrastructures
 
-*Ce document est une "demande de commentaire". Amendez-le, modifiez le, ajoutez vos réserves ou vos solutions alternatives librement.*
+*Ce document est une "demande de commentaire". Amendez-le, modifiez-le, ajoutez vos réserves ou vos solutions alternatives librement.*
 
 ## Contexte
 
@@ -9,7 +9,7 @@ Chaque service n'est pas attaché à une machine, il peut en changer pour mieux
 La plupart de ces services sont consommés en interne, leur adresse est découverte grâce au serveur DNS exposé par Consul. Ils ne sont donc pas exposés sur internet.
 Principe de minimisation de la surface d'attaque : consommé en interne donc pas de raison d'être disponible en externe.
 Qui plus est, la communication entre ces services se fait souvent en clair pour des raisons de simplicités.
-Ce n'est pas (trop) problématique car le réseau interne n'est pas (supposé) surveillé.
+Ce n'est pas (trop) problématique, car le réseau interne n'est pas (supposé) surveillé.
 
 ## Problème
 
@@ -30,10 +30,10 @@ C'est particulièrement critique si on commence à faire du transfert de donnée
 
 ## Être adressable sur Internet
 
-Cette complexité devrait évitée à mon avis. Pour cela je propose de baser nos communications de cluster via IPv6 seulement pour pouvoir adresser tout le mone directement. Je propose d'éditer un cahier des charges de la configuration minimale qu'une personne doit remplir pour s'interconnecter à l'infrastructure Deuxfleurs. Voilà une ébauche :
+Cette complexité devrait être évitée à mon avis. Pour cela je propose de baser nos communications de cluster via IPv6 seulement pour pouvoir adresser tout le monde directement. Je propose d'éditer un cahier des charges de la configuration minimale qu'une personne doit remplir pour s'interconnecter à l'infrastructure Deuxfleurs. Voilà une ébauche :
 
   - Avoir une IPv6 routable sur Internet
-  - Ne pas avoir de filtrage de port (exception possible pour le port 25 en sortie...)
+  - Ne pas avoir de filtrage de port imposé par son fournisseur d'accès (exception possible pour le port 25 en sortie...)
   - Avoir au minimum 1Go de RAM
   - Avoir un processeur x86
 
@@ -51,8 +51,8 @@ Voici quelques solutions auxquelles je pense :
 
 ### La *low-tech* : TLS au niveau applicatif et Consul DNS en service discovery
 
-Étant donné que toutes les machines sont adressables en IPv6, on pourrait imaginer continuer dans la lancée actuelle et enregistrer l'IPv6 publique plutôt que l'IPv4 privée. Il faudrait s'assurer que les applications fassent elles-même le TLS au niveau applicatif. Mais ça voudrait dire que les services seraient exposés sur Internet en IPv6 et que notre seule protection serait le controle d'authentification réalisée par l'application (pour l'auth) et le TLS applicatif pas oublié (pour le chiffrement - et l'auth potentiellement en mutual auth).
-On pourrait imaginer upgrader ce modèle en rajoutant une règle IPv6 dans le firewall des serveurs pour autoriser le trafic IPv6 global qu'entre serveurs de l'infra. Et seul les ports des services publics actuels seraient ouverts à tous en IPv6.
+Étant donné que toutes les machines sont adressables en IPv6, on pourrait imaginer continuer dans la lancée actuelle et enregistrer l'IPv6 publique plutôt que l'IPv4 privée. Il faudrait s'assurer que les applications fassent elles-mêmes le TLS au niveau applicatif. Mais ça voudrait dire que les services seraient exposés sur Internet en IPv6 et que notre seule protection serait le controle d'authentification réalisée par l'application (pour l'auth) et le TLS applicatif pas oublié (pour le chiffrement - et l'auth potentiellement en mutual auth).
+On pourrait imaginer upgrader ce modèle en rajoutant une règle IPv6 dans le firewall des serveurs pour autoriser le trafic IPv6 global qu'entre serveurs de l'infra. Et seuls les ports des services publics actuels seraient ouverts à tous en IPv6.
 
 **Avantages:**
 
@@ -63,20 +63,20 @@ On pourrait imaginer upgrader ce modèle en rajoutant une règle IPv6 dans le fi
 **Inconvénients:**
 
 - Complexité de mise en place, car il faut s'assurer que **tous** les services internes du cluster utilisent une authentification et que celle-ci est bien configurée
-- Pas de défense en profondeur donc il restera toujours le risque d'un service mal configuré qui permet de compromettre le système
+- Pas de défense en profondeur, donc il restera toujours le risque d'un service mal configuré qui permet de compromettre le système
 - Certains services ne savent peut-être pas faire d'authentification ? Par exemple GlusterFS (pour l'instant on ne s'en est pas débarassés) est-il capable de faire du TLS entre les noeuds ?
-- Si on choisit de rajouter un firewall, sait-on le configurer automatiquement lorsque les services changes de machine/de port ?
+- Si on choisit de rajouter un firewall, sait-on le configurer automatiquement lorsque les services changent de machine/de port ?
 
 ### La *networking* : Ajouter un VPN
 
 Solution étudiée par TeDomum/ACID. Ils partent sur Wesher. Voici leur avis :
 
 
-> On s'est posé la question d'utiliser un service mesh plutôt qu'un mesh d'infrastructure. Et il se trouve que ça collait peu à notre besoin. Il y a trop de choses au dessus pas conçues pour être à poil sur internet et qui rentreraient pas dans le service mesh.
+> On s'est posé la question d'utiliser un service mesh plutôt qu'un mesh d'infrastructure. Et il se trouve que ça collait peu à notre besoin. Il y a trop de choses au-dessus pas conçues pour être à poil sur internet et qui rentreraient pas dans le service mesh.
 > 
 > Consul est top si tu veux interconnecter des clusters k8s dans des régions différentes. Mais si tu fais un cluster étendu y'a trop de choses exposées par défaut sans tls ou sans authent sur le réseau d'infra k8s. Et trop de choses dans plein de techno où il attend une forme de l2 partagé ou une proximité réseau, même virtuelle, comme les acl par préfixe IP dans les solutions de stockage, l'allocation de préfixe d'adressage dans les ipam de la plupart des cni, etc.
 > 
-> On pourrait probablement s'en sortir en oubliant le clusters étendu géographique et en dégainant des solutions de synchro multi clusters avec plein de petits clusters et un service mesh par dessus. Mais c'est beaucoup plus complexe de mise en oeuvre et beaucoup plus coûteux qu'un bon vieux vpn en dessous.
+> On pourrait probablement s'en sortir en oubliant le cluster étendu géographique et en dégainant des solutions de synchro multi clusters avec plein de petits clusters et un service mesh par-dessus. Mais c'est beaucoup plus complexe de mise en oeuvre et beaucoup plus coûteux qu'un bon vieux vpn en dessous.
 > 
 > Bref. On veut faire simple et efficace.
 
@@ -99,7 +99,7 @@ Solutions possibles: Wireguard/[Wesher](https://github.com/costela/wesher), `tin
 
 ### La *micro-service architecture* : utiliser un service mesh
 
-Consul Connect permet de reporter le problème de l'interconnexion des infrastructures non plus au niveau des applications mais au niveau du cluster. Une fois Consul et Consul Connect bien configuré, tout le trafic sera alors chiffré d'un micro service à un autre avec du TLS et de l'authentification mutuelle. Consul sera lui même en charge de trouver comment faire communiquer les éléments. 
+Consul Connect permet de reporter le problème de l'interconnexion des infrastructures non plus au niveau des applications mais au niveau du cluster. Une fois Consul et Consul Connect bien configuré, tout le trafic sera alors chiffré d'un micro service à un autre avec du TLS et de l'authentification mutuelle. Consul sera lui-même en charge de trouver comment faire communiquer les éléments. 
 
 **Avantages:**
 
@@ -111,8 +111,8 @@ Consul Connect permet de reporter le problème de l'interconnexion des infrastru
 
 - Nécessite sans doute pas mal de travail pour le mettre en place
 - Ajoute un outil potentiellement complexe et peu maîtrisé
-- Les applications ne se parlent plus directement sur le réseau -> problèmes dans certains cas (par exemple Garage peut-il toujours fonctionner?)
+- Les applications ne se parlent plus directement sur le réseau -> problèmes dans certains cas (par exemple Garage peut-il toujours fonctionner ?)
 - Consommateur de CPU à haut débit
 - Protocole encore moins standard que le VPN (en estimant que si Wireguard a atterri dans le noyau, c'est que c'est relativement standard quand même)
 
-**Conclusion:** L'arbitrage entre la solution VPN et la solution service mesh se fait sur les deux points suivants: outil permettant de sécuriser les connections en les autorisant au cas-par-cas (ACL+intent) vs. outil permettant de préserver un fonctionnement comme en LAN et où les applications peuvent utiliser les propriétés d'un tel réseau "classique".
+**Conclusion:** L'arbitrage entre la solution VPN et la solution service mesh se fait sur les deux points suivants: outil permettant de sécuriser les connexions en les autorisant au cas-par-cas (ACL+intent) vs. outil permettant de préserver un fonctionnement comme en LAN et où les applications peuvent utiliser les propriétés d'un tel réseau "classique".
diff --git a/src/Technique/Operations/Jitsi.md b/src/Technique/Operations/Jitsi.md
index 8e87d8f..354710e 100644
--- a/src/Technique/Operations/Jitsi.md
+++ b/src/Technique/Operations/Jitsi.md
@@ -33,7 +33,7 @@ Voilà les conclusions que nous avons tirées de nos tests :
 
   - L'appel avec Firefox a déclenché le bug immédiatement, peu importe la version de Firefox ou de l'OS (firefox stable/nightly, fedora stable/beta, etc.)
   - Le passage de tout le monde sous Chrome/Chromium a permis d'avoir une conversation stable.
-  - Adrien avait sa Livebox avec pare-feu configuré en mode "élevé" et a du ajouter dans sa liste blanche les ports utilisés par Jitsi (`4443/tcp` et `10000/udp` au moment du test, seul un des deux a besoin d'être accessible)
+  - Adrien avait sa Livebox avec pare-feu configuré en mode "élevé" et a dû ajouter dans sa liste blanche les ports utilisés par Jitsi (`4443/tcp` et `10000/udp` au moment du test, seul un des deux a besoin d'être accessible)
 
 Nous avons donc demandé à Adrien quels étaient les ports ouverts par défaut dans le mode élevé de sa box :
 
@@ -50,7 +50,7 @@ Les utilisateurs activant le parefeu en mode élevé devront ajouter une excepti
 [Tedomum](https://tedomum.net/) a eu connaissance de problèmes similaires.
 Ils ont également identifié Firefox et assurent qu'avec l'application Android ça marche bien.
 Ils me confirment que le problème vient bien du logiciel et non pas de notre déploiement.
-Ils m'ont pointé entre autre vers cette issue github [#4758](https://github.com/jitsi/jitsi-meet/issues/4758)
+Ils m'ont pointé entre autres vers cette issue github [#4758](https://github.com/jitsi/jitsi-meet/issues/4758)
 Apparemment une issue est dédiée en particulier au problème que nous rencontrons de déconnexion partielle d'un participant, mais nous ne l'avons pas encore retrouvée.
 
 ### Correctifs
@@ -59,7 +59,7 @@ Apparemment une issue est dédiée en particulier au problème que nous rencontr
     * [#4758](https://github.com/jitsi/jitsi-meet/issues/4758)
     * [#5439](https://github.com/jitsi/jitsi-meet/issues/5439)
     * _À compléter_
-  2. Pour relayer la vidéo à travers la plupart des parefeux, notre `videobridge` Jitsi devait écouter sur le port `443/tcp`. Hors, ce port est déjà utilisé par notre frontal HTTPS. À défaut, Jitsi est maintenant configuré avec `8080/tcp` et `10000/udp` (contre `4443/tcp` et `10000/udp` avant).
+  2. Pour relayer la vidéo à travers la plupart des parefeux, notre `videobridge` Jitsi devait écouter sur le port `443/tcp`. Or ce port est déjà utilisé par notre frontal HTTPS. À défaut, Jitsi est maintenant configuré avec `8080/tcp` et `10000/udp` (contre `4443/tcp` et `10000/udp` avant).
     * Un déploiement en IPv6 pourrait résoudre le problème pour une partie des utilisateurs
     * Avoir un cluster géo-distribué avec plusieurs IPv4 pourrait également résoudre le problème
     * Avoir un frontend layer 4 (niveau TCP) qui trouve une signature pour router du DTLS vers videobridge et du TLS vers traefik
@@ -89,6 +89,6 @@ WebRTC utilise deux formats de paquets selon [Mozilla Developer Network|RTCDataC
   - `UDP/DTLS/SCTP`
   - `TCP/DTLS/SCTP`
 
-On a donc un format de données arbitraire encapsulé dans du SCTP lui même encapsulé dans du DTLS.
+On a donc un format de données arbitraire encapsulé dans du SCTP lui-même encapsulé dans du DTLS.
 DTLS est prévu pour les datagrammes à l'origine, car WebRTC est prévu d'abord pour fonctionner sous UDP.
 Le TCP est là en mode dégradé, en secours, il sert juste de tunnel pour relayer des datagrammes.
diff --git a/src/Technique/index.md b/src/Technique/index.md
index 8aea90f..e8c0677 100644
--- a/src/Technique/index.md
+++ b/src/Technique/index.md
@@ -13,7 +13,7 @@ Les services proposés sont les suivants:
 - Email (Postfix, Dovecot, SoGo)
 - Stockage (Seafile)
 
-Par ailleurs, nous avons développés nous-même un certain nombre d'outils pour compléter la stack:
+Par ailleurs, nous avons développé nous-même un certain nombre d'outils pour compléter la stack:
 
 - [Bottin](https://bottin.eu), un serveur LDAP (gestion des comptes utilisateurs) basé sur le stockage clef/valeur de Consul
 - [Guichet](https://git.deuxfleurs.fr/Deuxfleurs/Guichet/), une interface web de gestion des utilisateurs