Merge branch 'spellcheck' into 'master'

Spellcheck

See merge request acides/website!1

content/docs/hepto/_index.md

@@ -8,7 +8,7 @@ L'hébergement de services et de données sur Internet est aujourd'hui très
 centralisé, ce qui est néfaste à plusieurs titres :
 
  - pour la sécurité, l'appât du gain étant d'autant plus grand que les
-   victimes potentielles sont nombreux, et les principales plateformes
+   victimes potentielles sont nombreuses, et les principales plateformes
    n'ayant que peu d'intérêt à protéger les individus ;
  - pour la vie privée, l'accumulation de données rendant leur exploitation
    lucrative, tant pour la commercialisation de services de ciblage que pour
@@ -30,7 +30,7 @@ ou bien les héberger à leur domicile, au détriment de la disponibilité,
 principalement en raison des aléas électriques et de l'accès à Internet.
 
 hepto vise à faciliter l'hébergement au domicile, en permettant à plusieurs
-individus ou structure, domiciliés séparément mais disposant de connexions à
+individus ou structures, domiciliés séparément mais disposant de connexions à
 Internet de qualité, de mettre en commun leurs ressources pour construire et
 exploiter un *cluster* d'hébergement résilient.
 
@@ -46,7 +46,7 @@ Les *clusters* résultants sont :
    composants, peut être hébergé pour parties en différents endroits ;
  - résilients, c'est à dire qu'un service peut reposer sur un composant
    déployé simultanément en plusieurs endroits et gérer automatiquement
-   la réponse à incident ;
+   la réponse à un incident ;
  - économes en ressources, c'est à dire que les équipements requis pour
    héberger un cluster coûtent peu, consomment peu, et que les
    communications à travers Internet sont limitées lorsque possibles afin
@@ -78,7 +78,7 @@ Le projet hepto était initialement nommé « hosto » (en référence simple à
 *host*) ; il a ainsi débuté en juin 2019, regroupant principalement des
 volontaires des deux associations CryptOn et TeDomum.
 
-En semptembre 2019, les premières orientations architecturales étaient fixées
+En septembre 2019, les premières orientations architecturales étaient fixées
 et les premiers choix technologiques ont penché du côté de Wireguard et
 de Kubernetes pour débuter un laboratoire. Le laboratoire a été assemblé
 à base de matériel récupéré et installé jusqu'en décembre 2019.
@@ -90,4 +90,4 @@ version exploitable a ainsi vu le jour en mai 2020.
 
 Il reste aujourd'hui de nombreux aspects à améliorer dans les configurations
 proposées, mais hepto fournit un socle réutilisable pour déployer des
-*clusters* de petits hébergeurs. Il compte 5 contributeurs actifs.
+*clusters* de petits hébergeurs. Il compte 5 contributeurs actifs.
\ No newline at end of file

content/docs/hepto/architecture.md

@@ -9,14 +9,14 @@ title: Architecture
 Un *cluster* hepto est constitué :
 
  - d'hôtes physiques, possédés par les contributeurs au *cluster* ;
- - de noeuds du cluster, chaque noeud étant instancié sur un hôte physique ;
- - d'une surcouche réseau, regroupant ces noeuds sur un même réseau privé
+ - de nœuds du cluster, chaque nœud étant instancié sur un hôte physique ;
+ - d'une surcouche réseau, regroupant ces nœuds sur un même réseau privé
    virtuel (VPN) sécurisant les communications à suivre ;
  - d'une surcouche orchestration, exploitant le CPU, la RAM et le stockage
-   des noeuds pour y déployer des applications et rendre des services ;
+   des nœuds pour y déployer des applications et rendre des services ;
  - d'une surcouche de contribution, permettant le travail collaboratif sur
    les ressources du *cluster*, l'historisation des modifications, le
-   déploiement contrinu, etc. ;
+   déploiement continu, etc. ;
  - d'outils pré-déployés, tels que les *reverse proxy* d'accès aux services,
    la gestion des certificats TLS, la supervision des ressources, la
    collecte et le traitement des journaux, etc.
@@ -25,14 +25,14 @@ Il est distribué, c'est à dire que les ressources sont mises à disposition
 par des individus collaborant, mais pas nécessairement appartenant à la même
 association, entreprise, collectif, etc. Chaque contributeur peut par exemple
 disposer d'un hôte à son domicile, et décider de l'allouer pour partie à un
-noeud d'un premier *cluster*, pour partie à un noeud d'un autre *cluster*, et
+nœud d'un premier *cluster*, pour partie à un nœud d'un autre *cluster*, et
 d'en conserver la maîtrise pour stocker ses documents personnels.
 
 Il est résilient, c'est à dire qu'une application déployée et ses données ne
-sont pas gérées sur le noeud d'un unique contributeur. En cas de panne de
+sont pas gérées sur le nœud d'un unique contributeur. En cas de panne de
 courant, d'accès à Internet, de déménagement, ou simplement si le contributeur
-décide subitement de déconnecter son noeud, le *cluster* continue d'exister
-et les applications continuent de fonctoinner sur les autres noeuds.
+décide subitement de déconnecter son nœud, le *cluster* continue d'exister
+et les applications continuent de fonctionner sur les autres nœuds.
 
 Il est économe, c'est à dire qu'il peut reposer sur des machines à faible
 consommation, et que la somme des ressources peut approcher la somme des
@@ -48,17 +48,17 @@ personnel de récupération ou d'un micro-serveur. Il peut être utilisé pour
 contribuer à un ou plusieurs *clusters* hepto, voire servir en parallèle
 d'autres applications de son propriétaire.
 
-Un noeud matérialise l'allocation de tout ou partie des ressources de
-l'hôte sur lequel il repose au profit d'un *cluster* hepto. Un noeud est
+Un nœud matérialise l'allocation de tout ou partie des ressources de
+l'hôte sur lequel il repose au profit d'un *cluster* hepto. Un nœud est
 concrètement constitué de deux programmes : la contribution à la surcouche
 réseau et la contribution à la surcouche orchestration.
 
-Le *cluster* hepto est réalisé par l'ensemble des noeuds qui le constituent,
+Le *cluster* hepto est réalisé par l'ensemble des nœuds qui le constituent,
 il fournit les primitives réseau et d'orchestration aux applications qui
 y sont hébergées.
 
 Dans le contexte de hepto, un *pod* peut techniquement faire référence à
-un *pod* Podman, technologie employée pour gérer les noeuds, ou bien un
+un *pod* Podman, technologie employée pour gérer les nœuds, ou bien un
 *pod* kubernetes, technologie employée pour la couche d'orchestration.
 Sauf précision, il s'agit d'un *pod* au sens kubernetes.
 
@@ -73,10 +73,10 @@ laboratoires hepto. Elles sont susceptibles d'évoluer régulièrement :
 
  - les hôtes sont limités aux machines de l'architecture AMD64, avec
    au minimum 1Go de mémoire vive et 50Go de stockage ;
- - les noeuds sont constitués par des *pods* Podman, eux-mêmes
+ - les nœuds sont constitués par des *pods* Podman, eux-mêmes
    organisés en deux conteneurs, l'un pour la surcouche réseau, l'autre
    pour la surcouche orchestration ;
- - la surcouche réseau est opérée par wesher, qui négocie et conigure des
+ - la surcouche réseau est opérée par wesher, qui négocie et configure des
    VPN Wireguard en *full-mesh* entre tous les membres du cluster ;
  - la surcouche orchestration est opérée par k3s, une version allégée
    de l'orchestration de conteneur kubernetes ;
@@ -92,18 +92,18 @@ d'administration du *cluster* au niveau de la surcouche d'orchestration
 et dispose de l'ensemble des clés de sécurité du *cluster*, y compris
 celles protégeant la surcouche réseau.
 
-Un noeud hepto fait partie du *cluster*, et est donc sous la
+Un nœud hepto fait partie du *cluster*, et est donc sous la
 responsabilité du responsable du *cluster*, de même que l'ensemble des
 ressources qui y sont orchestrées, sauf délégation.
 
-Un hôte abritant un noeud hepto est sous la responsable du propriétaire
-de l'équipement. Il peut s'agit de la même entité que le responsable du
-*cluster*, mais il peut également s'agit d'un individu ou d'un groupement
+Un hôte abritant un nœud hepto est sous la responsabilité du propriétaire
+de l'équipement. Il peut s'agir de la même entité que le responsable du
+*cluster*, mais il peut également s'agir d'un individu ou d'un groupement
 tiers. Par exemple, des associations peuvent mettre à disposition chacune
-des hôtes pour héberger les noeuds d'un *cluster* hepto géré en fédération
+des hôtes pour héberger les nœuds d'un *cluster* hepto géré en fédération
 d'associations ; ou bien une association gérer un *cluster* hepto reposant
-pour une part sur des noeuds hébergés sur ses propres hôtes et sur des
-noeuds contribués par ses membes mais dont l'association n'est pas
+pour une part sur des nœuds hébergés sur ses propres hôtes et sur des
+nœuds contribués par ses membes mais dont l'association n'est pas
 propriétaire.
 
 Au sein d'un *cluster* hepto, le responsable du *cluster* peut décider
@@ -142,7 +142,7 @@ Aussi, il apparaît que les deux types de ressources doivent être gérés par
 deux technologies distinctes bien que complémentaires. En résultent deux
 approches envisageables :
 
- - soit disposer d'une connectivité réseau sécurisée entre les noeuds du
+ - soit disposer d'une connectivité réseau sécurisée entre les nœuds du
    cluster, sur la base de laquelle l'orchestration est construite ;
  - soit construire une orchestration indépendamment des propriétés de
    sécurité réseau et déployer en sus les outils pour sécuriser les
@@ -184,15 +184,15 @@ pour hepto est repoussée.
 #### VPN et mesh
 
 Pour qu'une surcouche réseau à base de VPN soit efficace, il faut que le
-trafic circule entre les noeuds sans transiter par un noeud central. Il faut
-également que tous les noeuds puissent échanger avec tous les autres noeuds,
+trafic circule entre les nœuds sans transiter par un nœud central. Il faut
+également que tous les nœuds puissent échanger avec tous les autres nœuds,
 et que chacun puisse disposer d'un espace d'adressage complet pour les
 applications hébergées.
 
 Une telle infrastructure, dénommée *VPN full-mesh*, n'est pas triviale à
 mettre en place. C'est en reprenant et en étendant un logiciel existant,
 « wesher », que hepto parvient à gérer un *VPN full-mesh* entre l'ensemble
-des noeuds garantissant la confidentialité et l'intégrité du trafic échangé,
+des nœuds garantissant la confidentialité et l'intégrité du trafic échangé,
 et servant de base à la surcouche orchestration.
 
 ### Machines virtuelles, conteneurs, processus
@@ -205,4 +205,4 @@ TODO
 
 ### Optimisations topologiques
 
-TODO
+TODO
\ No newline at end of file