correction de typos

6 files changed, 13 insertions, 13 deletions

diff --git a/content/infrastructures/guichet.md b/content/infrastructures/guichet.md
index 684f410..6a214b8 100644
--- a/content/infrastructures/guichet.md
+++ b/content/infrastructures/guichet.md
@@ -11,9 +11,9 @@ extra:
 # Guichet
 
 Guichet est une interface de gestion utilisateur LDAP pour Bottin.
-Il vise notamment à permettre aux utilisateurs de modifier leurs identifinats ainsi que leurs données personnelles.
+Il vise notamment à permettre aux utilisateurs de modifier leurs identifiants ainsi que leurs données personnelles.
 
 ## Statut du développement
 
-Guichet est actuellement utilisé en production pour deuxfleurs. Il est cependant toujours en développement actif.
+Guichet est actuellement utilisé en production pour Deuxfleurs. Il est cependant toujours en développement actif.
 Le code est ici : <https://git.deuxfleurs.fr/Deuxfleurs/guichet>
diff --git a/content/infrastructures/logiciels.md b/content/infrastructures/logiciels.md
index 7fc13b1..f931260 100644
--- a/content/infrastructures/logiciels.md
+++ b/content/infrastructures/logiciels.md
@@ -27,18 +27,18 @@ Quelques propriétés en vrac qu'on peut, ou ne pas, désirer :
 
   - Je ne veux pas que le contenu de mes messages et des fichiers que je partage soient accessibles (eg. une photo que j'ai prise, mes réactions)
   - Je ne veux pas que les métadonnées autour de mes messages soient accessibles (eg. les salons de discussions auxquels je prends pars, l'horodatage des messages, les personnes avec qui j'échange)
-  - Je ne veux pas que les métadonnées de communication soient accessibles (eg. quand je me connecte au service, depuis où, si j'intéragis sur le réseau, etc.), ces données permettent parfois d'inférer des métadonnées sur le protocol (autres personnes dans le salon de communication, horodatage, etc.)
+  - Je ne veux pas que les métadonnées de communication soient accessibles (eg. quand je me connecte au service, depuis où, si j'intéragis sur le réseau, etc.), ces données permettent parfois d'inférer des métadonnées sur le protocole (autres personnes dans le salon de communication, horodatage, etc.)
 
 ### Courrier électronique (de l'email au mixnet)
 
   - Je ne veux pas que le contenu de mes emails et pièces jointes soit lisible (eg. le doc que j'ai joint)
-  - Je ne veux pas que les métadonnées autour de mon message soient accessibles (eg. le destinaire, l'expéditeur, l'horodatage, le client email utilisé, le sujet du mail, le dossier dans lequel il est stocké)
-  - Je ne veux pas que les métadonnées de communication soient accessibles (eg. quand je me connecte au service email, depuis où, quand j'intéragis sur le réseau), ces données permettent parfois d'inférer des métadonnées sur le protocol (destinaires, présence de pièce jointe,
+  - Je ne veux pas que les métadonnées autour de mon message soient accessibles (eg. le destinataire, l'expéditeur, l'horodatage, le client email utilisé, le sujet du mail, le dossier dans lequel il est stocké)
+  - Je ne veux pas que les métadonnées de communication soient accessibles (eg. quand je me connecte au service email, depuis où, quand j'intéragis sur le réseau), ces données permettent parfois d'inférer des métadonnées sur le protocole (destinataires, présence de pièce jointe, etc.)
 
 ### Synchronisation et collaboration sur des fichiers
   - Je ne veux pas que le contenu de mes fichiers soit accessible
   - Je ne veux pas que les métadonnées de mon fichier soient accessibles (eg. nom du fichier, dossier, format, taille, hash, etc.)
-  - Je ne veux pas que les métadonnées de communication soient accessibles (eg. quand j'accède au document, depuis où, qui d'autre, combien de fois, etc.), ces données permettent parfois d'inférer des métadonnées sur le protocol (taille, collaborateurs, type, etc.)
+  - Je ne veux pas que les métadonnées de communication soient accessibles (eg. quand j'accède au document, depuis où, qui d'autre, combien de fois, etc.), ces données permettent parfois d'inférer des métadonnées sur le protocole (taille, collaborateurs, type, etc.)
 
 ## Attaquants
 
@@ -47,7 +47,7 @@ Quelques attaquants que l'on peut, ou ne pas, considérer :
   - Hébergeur de la machine (eg. branche un clavier et un écran sur l'ordi et récupère un accès admin)
   - Administrateur Système (eg. utilise ses accès privilégiés pour accéder volontairement ou non à du contenu privé)
   - Développeurs (eg. ajout d'une porte dérobée au moment de l'écriture du code)
-  - Chaine logistique (eg. ajout d'une porte dérobée au moment de déployer l'app sur les serveurs ou le terminal de l'utilisateur)
+  - Chaîne logistique (eg. ajout d'une porte dérobée au moment de déployer l'app sur les serveurs ou le terminal de l'utilisateur)
   - Opérateur Internet (eg. Orange)
   - Regroupement d'opérateurs internet (cf "Tor netflow")
   - Personne externe via internet (eg. hacker)
@@ -88,7 +88,7 @@ Concernant la seconde approche, celle-ci semble beaucoup plus à notre portée :
 
 - On peut imaginer que les clefs de chiffrement ne soient jamais stockées en clair nulle part : elles pourraient être stockées avec une passphrase qui serait le mot de passe de l'utilisateur (+ éventuellement un mécanisme de secret de shamir pour répartir les morceaux de clefs sur plusieurs machines), et c'est seulement au dernier moment (en RAM) qu'elles existent en version déchiffrée
 
-- Enfin, on peut imaginer que Deuxfleurs fournisse à la place (ou en plus) du protocole standard un protocole entièrement chiffrée + un logiciel proxy que les utilisateurices pourraient installer sur leur machine pour avoir accès au protocole standard avec toutes leurs applications habituelles. Cette dernière option permetterait d'avoir le même niveau de sécurité que la solution consistant à définir de nouveaux protocoles, sans pour autant compromettre l'interopérabilité avec l'écosystème existant.
+- Enfin, on peut imaginer que Deuxfleurs fournisse à la place (ou en plus) du protocole standard un protocole entièrement chiffrée + un logiciel proxy que les utilisateurices pourraient installer sur leur machine pour avoir accès au protocole standard avec toutes leurs applications habituelles. Cette dernière option permettrait d'avoir le même niveau de sécurité que la solution consistant à définir de nouveaux protocoles, sans pour autant compromettre l'interopérabilité avec l'écosystème existant.
 
 ## Ressources
 
diff --git a/content/infrastructures/machines.md b/content/infrastructures/machines.md
index cf6e493..d31cdf4 100644
--- a/content/infrastructures/machines.md
+++ b/content/infrastructures/machines.md
@@ -13,7 +13,7 @@ Nous avons identifié 4 rôles pour nos serveurs, en fonction de la criticité d
 et des données qu'ils auront à gérer.
 
 [Production](@/infrastructures/production.md) - Les serveurs de productions sont ceux qui font tourner les services accédés par les usager·es (eg. Plume, Matrix, Cryptpad).
-Si ils sont innaccessibles, alors les services ne fonctionnent plus. Et si une personne malveillante y accède, elle peut avoir accès à des données
+Si ils sont inaccessibles, alors les services ne fonctionnent plus. Et si une personne malveillante y accède, elle peut avoir accès à des données
 personnelles des usager·es. C'est donc le rôle le plus critique.
 
 [Support](@/infrastructures/support.md) - Les serveurs de support servent pour les sauvegardes et la supervision des serveurs de production (eg. Grafana, Minio).
@@ -23,7 +23,7 @@ et les sauvegardes, bien qu'elles soient chiffrées, contiennent tout de même d
 
 [Développement](@/infrastructures/developpement.md) - Les serveurs de développement hébergent les outils qui nous permettent de travailler sur le logiciel,
 les configurations, les tickets, ou la compilation. Ils ne contiennent pas de données personnelles mais peuvent être utilisés pour
-des attaques de chaine d'approvisionnement (*supply chain attack*). À terme, ce rôle pourrait être fusionné avec la production.
+des attaques de chaîne d'approvisionnement (*supply chain attack*). À terme, ce rôle pourrait être fusionné avec la production.
 
 [Expérimentation](@/infrastructures/xp.md) - Les serveurs d'expérimentation servent à tester les nouvelles configurations, les nouveaux logiciels,
 et le nouveau matériel. Ils permettent aux opérateur·ices de se familiariser avec leurs modifications et de minimiser l'impact d'un changement sur les serveurs de production,
diff --git a/content/infrastructures/production.md b/content/infrastructures/production.md
index d30c5ac..7d8c8a5 100644
--- a/content/infrastructures/production.md
+++ b/content/infrastructures/production.md
@@ -7,7 +7,7 @@ extra:
 ---
 
 Les serveurs de productions sont ceux qui font tourner les services accédés par les usager·es (eg. Plume, Matrix, Cryptpad).
-Si ils sont innaccessibles, alors les services ne fonctionnent plus. Et si une personne malveillante y accède, elle peut avoir accès à des données
+Si ils sont inaccessibles, alors les services ne fonctionnent plus. Et si une personne malveillante y accède, elle peut avoir accès à des données
 personnelles des usager·es. C'est donc le rôle le plus critique.
 
 **Feuille de route :** Bien que nous disposions aujourd'hui de 3 sites pour le cluster de production,
diff --git a/content/infrastructures/support.md b/content/infrastructures/support.md
index 7715481..f5d4640 100644
--- a/content/infrastructures/support.md
+++ b/content/infrastructures/support.md
@@ -26,7 +26,7 @@ Il est en charge de la surveillance de la production (métrologie, etc.) et des
 | [Microtik RB4011iGS+RM](https://mikrotik.com/product/rb4011igs_rm) | Routeur | x1 | Routeur et pare-feu, ports 1x10G SFP+ et 10x1G |
 | Serveur Dell R710  | Hyperviseur | x3 | 2 socket, Xeon E5520 (4c8t @ 2.26Ghz) <br> 80Go RAM, 500GB NVMe, 1TB RAID matériel, réseau LACP 2x1G |
 
-Seulement une partie du serveur est mise à dispsition de Deuxfleurs :
+Seulement une partie du serveur est mise à disposition de Deuxfleurs :
 
 | Désignation | Rôle | Quantité | Détails |
 | -- | -- | -- | -- | 
diff --git a/content/infrastructures/tricot.md b/content/infrastructures/tricot.md
index 0c83901..f21bbef 100644
--- a/content/infrastructures/tricot.md
+++ b/content/infrastructures/tricot.md
@@ -14,5 +14,5 @@ Tricot est un reverse-proxy HTTP et HTTPS qui s'auto-configure à partir de [Con
 
 ## Statut du développement
 
-Tricot est actuellement utilisé en production pour deuxfleurs. Il est cependant toujours en développement actif.
+Tricot est actuellement utilisé en production pour Deuxfleurs. Il est cependant toujours en développement actif.
 Le code de Tricot se trouve ici : <https://git.deuxfleurs.fr/Deuxfleurs/tricot>