correction de typos

1 files changed, 6 insertions, 6 deletions

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