Fix typos & spelling

src/Association/Réunion_1.md

@@ -43,10 +43,10 @@ Continuer sans ? (mais c'est dans les statuts)
 
 **Motion voté.**
 
-### Gestion de la compta
+### Gestion de la comptabilité
 
 Quentin a un compte courant vide. Mais à son avis pas une bonne idéee.  
-Gestion de la compta sur un logiciel (lequel ?)  
+Gestion de la comptabilité sur un logiciel (lequel ?)  
 Trésorier ?  
 
 Alex a trouvé une boite.  
@@ -60,11 +60,11 @@ Pour les présents, les cotisations sont payables à la fin de l'AG.
 
 ### Charte
 
-Trouver pour la prochaine AG (voire avant) une base. Maximilien doit envoyer des idées sur la base de ce qui est fait en conférence.   Quentin envoie des idée pour les projets Open-Source. 
+Trouver pour la prochaine AG (voire avant) une base. Maximilien doit envoyer des idées sur la base de ce qui est fait en conférence.   Quentin envoie des idées pour les projets Open-Source. 
 
 ### Site web
 
-Intégrer la documentation au site web, afin qu'elle soit consultable et plus transparent par rapport aux infrastructure.
+Intégrer la documentation au site web, afin qu'elle soit consultable et plus transparent par rapport aux infrastructures.
 
 Outil pour build du Markdown avec un blog statique.  
 Utiliser les outils de templating des trucs web.  

src/Association/index.md

@@ -7,7 +7,7 @@ que nous passons dessus, de
 <a href="https://fr.wikipedia.org/wiki/%C3%89conomie_de_la_surveillance">collecter et recouper des données</a>
 à notre insu pour nous influencer, de
 <a href="https://www.april.org/le-parlement-europeen-valide-la-generalisation-de-la-censure-automatisee">limiter nos possibilités d'expression</a>
-au delà du cadre légal et de
+au-delà du cadre légal et de
 <a href="https://fr.wikipedia.org/wiki/Embrace,_extend_and_extinguish">créer de nouveaux monopoles</a>.
 Ces effets nous montrent que la technologie n'est pas
 neutre et a un réel impact sur nos vies. En choisissant et en hébergeant nos
@@ -25,7 +25,7 @@ et allez lire le manifeste <a href="https://chatons.org/fr/manifeste">des CHATON
 
 Que ce soit à l'école, par l'expérimentation, via un forum d'échange, lors d'un
 atelier, via une publicité à la télévision, un tutoriel, lors d'une discussion
-avec un ami, il y toujours une phase d'apprentissage en informatique.
+avec un ami, il y a toujours une phase d'apprentissage en informatique.
 Malheureusement, dans ces conditions, dur de lutter pour des services libres
 face à la puissance de frappe d'une entreprise et des logiciels ayant une base
 d'utilisateurs immense. Nous pensons donc qu'une personne souhaitant s'héberger

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

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).
+É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 seul les ports des services publics actuels seraient ouverts à tous en IPv6.
+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:**
 
@@ -115,4 +115,4 @@ Consul Connect permet de reporter le problème de l'interconnexion des infrastru
 - 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".

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.

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