2 files changed, 30 insertions, 31 deletions
diff --git a/src/Technique/Jalon/CHATONS.md b/src/Technique/Jalon/CHATONS.md
index c685881..0c509bf 100644
--- a/src/Technique/Jalon/CHATONS.md
+++ b/src/Technique/Jalon/CHATONS.md
@@ -1,17 +1,17 @@
 Nous souhaiterions devenir un CHATON, pour ça il faudrait au moins :
 
-  - Avoir des backups sur les services "stables"
-  - Avoir des performances satisfaisantes sur les services, actuellement ces services cochent les cases :
-    - Jitsi
-    - Riot/Matrix
-    - CryptPad
-    - Gitea
-  - Avoir un modèle plus clair / écrire plus largement comment un membre peut nous rejoindre
-  - Corriger les problèmes de robustesse simple de l'infrastructure :
-    - Ordonancement des services au boot
-      - Nomad démarre avant que le réseau soit prêt
-      - Consul démarre avant que le réseau soit prêt
-      - GlusterFS n'a pas démarré quand le fstab est lu, donc la partition n'est pas montée
-    - Reconfiguration du NAT / des ports dans le firewall
-      - En cours via le développement de Diplonat
-  - Compléter cette liste en lisant la charte du site web des chatons
+- Avoir des backups sur les services "stables"
+- Avoir des performances satisfaisantes sur les services, actuellement ces services cochent les cases :
+  - Jitsi
+  - Riot/Matrix
+  - CryptPad
+  - Gitea
+- Avoir un modèle plus clair / écrire plus largement comment un membre peut nous rejoindre
+- Corriger les problèmes de robustesse simple de l'infrastructure :
+  - Ordonancement des services au boot
+    - Nomad démarre avant que le réseau soit prêt
+    - Consul démarre avant que le réseau soit prêt
+    - GlusterFS n'a pas démarré quand le fstab est lu, donc la partition n'est pas montée
+  - Reconfiguration du NAT / des ports dans le firewall
+    - En cours via le développement de Diplonat
+- Compléter cette liste en lisant la charte du site web des chatons
diff --git a/src/Technique/Jalon/Interconnexion.md b/src/Technique/Jalon/Interconnexion.md
index b46922a..864e376 100644
--- a/src/Technique/Jalon/Interconnexion.md
+++ b/src/Technique/Jalon/Interconnexion.md
@@ -16,9 +16,9 @@ Ce n'est pas (trop) problématique, car le réseau interne n'est pas (supposé)
 On ne peut pas consommer les services internes d'une infrastructure A depuis une infrastructure B.
 Par exemple, on voudrait que le serveur LDAP géré par Quentin soit consommable par le serveur Git géré par Adrien, avec ces propriétés :
 
-  * sans qu'il soit exposé directement sur internet, 
-  * sans que la communication entre A et B puisse être espionnée,
-  * sans que le service soit "attaché" à une machine en particulier.
+* sans qu'il soit exposé directement sur internet,
+* sans que la communication entre A et B puisse être espionnée,
+* sans que le service soit "attaché" à une machine en particulier.
 
 ## Difficultés techniques
 
@@ -32,20 +32,20 @@ C'est particulièrement critique si on commence à faire du transfert de donnée
 
 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 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
+- Avoir une IPv6 routable sur Internet
+- 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
 
 ## Trouver un service et chiffrer systématiquement
 
 Maintenant que toutes les machines de toutes les infrastructures peuvent toutes communiquer entre elles, il nous reste encore deux problèmes :
-  - Les services ne sont pas attachés à une machine, et donc pas attachés à une adresse réseau
-  - Le trafic passant en clair sur internet est supposé espionné
+- Les services ne sont pas attachés à une machine, et donc pas attachés à une adresse réseau
+- Le trafic passant en clair sur internet est supposé espionné
 
 Il nous faut donc deux propriétés qui découlent directement de ces deux besoins :
-  - Un moyen de permettre à un service C de communiquer avec un service D
-  - Chiffrer systématiquement le traffic qui part sur internet
+- Un moyen de permettre à un service C de communiquer avec un service D
+- Chiffrer systématiquement le traffic qui part sur internet
 
 Voici quelques solutions auxquelles je pense :
 
@@ -71,13 +71,12 @@ On pourrait imaginer upgrader ce modèle en rajoutant une règle IPv6 dans le fi
 
 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.
-> 
+>
 > 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 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.
 
 Solutions possibles: Wireguard/[Wesher](https://github.com/costela/wesher), `tinc`, cjdns/yggdrasil.
@@ -99,7 +98,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:**