De l'inclusif, partout

Signed-off-by: Emmy D'ANELLO <ynerant@crans.org>

docs/external_services/cas.rst

@@ -3,7 +3,7 @@ Service d'Authentification Centralisé (CAS)
 
 Un `CAS <https://fr.wikipedia.org/wiki/Central_Authentication_Service>`_ est
 déployé sur la Note Kfet. Il est accessible à l'adresse `<https://note.crans.org/cas/>`_.
-Il a pour but uniquement d'authentifier les utilisateurs via la note et ne communique
+Il a pour but uniquement d'authentifier les utilisateur⋅rices via la note et ne communique
 que peu d'informations.
 
 Configuration

docs/external_services/index.rst

@@ -12,9 +12,9 @@ Applications externes
    L'utilisation de la note par des services externes est actuellement en beta. Il est
    fort à parier que cette utilisation sera revue et améliorée à l'avenir.
 
-Puisque la Note Kfet recense tous les comptes des adhérents BDE, les clubs ont alors
+Puisque la Note Kfet recense tous les comptes des adhérent⋅es BDE, les clubs ont alors
 la possibilité de développer leurs propres applications et de les interfacer avec la
-note. De cette façon, chaque application peut authentifier ses utilisateurs via la note,
+note. De cette façon, chaque application peut authentifier ses utilisateur⋅rices via la note,
 et récupérer leurs adhésion, leur nom de note afin d'éventuellement faire des transferts
 via l'API.
 
@@ -25,4 +25,4 @@ Deux protocoles d'authentification sont implémentées :
 
 À ce jour, il n'y a pas encore d'exemple d'utilisation d'application qui utilise ce
 mécanisme, mais on peut imaginer par exemple que la Mediatek ou l'AMAP implémentent
-ces protocoles pour récupérer leurs adhérents.
+ces protocoles pour récupérer leurs adhérent⋅es.

docs/external_services/oauth2.rst

@@ -2,12 +2,12 @@ OAuth2
 ======
 
 L'authentification `OAuth2 <https://fr.wikipedia.org/wiki/OAuth>`_ est supportée par la
-Note Kfet. Elle offre l'avantage non seulement d'identifier les utilisateurs, mais aussi
-de transmettre des informations à un service tiers tels que des informations personnelles,
-le solde de la note ou encore les adhésions de l'utilisateur, en l'avertissant sur
-quelles données sont effectivement collectées. Ainsi, il est possible de développer des
-appplications tierces qui peuvent se baser sur les données de la Note Kfet ou encore
-faire des transactions.
+Note Kfet. Elle offre l'avantage non seulement d'identifier les utilisateur⋅rices, mais
+aussi de transmettre des informations à un service tiers tels que des informations
+personnelles, le solde de la note ou encore les adhésions de l'utilisateur⋅rice, en
+l'avertissant sur quelles données sont effectivement collectées. Ainsi, il est possible
+de développer des appplications tierces qui peuvent se baser sur les données de la Note
+Kfet ou encore faire des transactions.
 
 
 Configuration du serveur
@@ -79,7 +79,7 @@ Il vous suffit de donner à votre application :
 * Les scopes, qui peuvent être récupérées sur cette page : `<https://note.crans.org/permission/scopes/>`_
 * L'URL d'autorisation : `<https://note.crans.org/o/authorize/>`_
 * L'URL d'obtention de jeton : `<https://note.crans.org/o/token/>`_
-* Si besoin, l'URL de récupération des informations de l'utilisateur : `<https://note.crans.org/api/me/>`_
+* Si besoin, l'URL de récupération des informations de l'utilisateur⋅rice : `<https://note.crans.org/api/me/>`_
 
 N'hésitez pas à consulter la page `<https://note.crans.org/api/me/>`_ pour s'imprégner
 du format renvoyé.
@@ -88,14 +88,14 @@ du format renvoyé.
 
    Un petit mot sur les scopes : tel qu'implémenté, une scope est une permission unitaire
    (telle que décrite dans le modèle ``Permission``) associée à un club. Ainsi, un jeton
-   a accès à une scope si et seulement si le/la propriétaire du jeton dispose d'une adhésion
+   a accès à une scope si et seulement si læ propriétaire du jeton dispose d'une adhésion
    courante dans le club lié à la scope qui lui octroie cette permission.
 
    Par exemple, un jeton pourra avoir accès à la permission de créer des transactions en lien
-   avec un club si et seulement si le propriétaire du jeton est trésorier du club.
+   avec un club si et seulement si læ propriétaire du jeton est trésorièr⋅e du club.
 
-   La vérification des droits du propriétaire est faite systématiquement, afin de ne pas
-   faire confiance au jeton en cas de droits révoqués à son propriétaire.
+   La vérification des droits de læ propriétaire est faite systématiquement, afin de ne pas
+   faire confiance au jeton en cas de droits révoqués à saon propriétaire.
 
    Vous pouvez donc contrôler le plus finement possible les permissions octroyées à vos
    jetons.
@@ -118,8 +118,8 @@ du format renvoyé.
 
    Par exemple, vous pourriez demander la permission d'accéder
    aux membres d'un club ou de faire des transactions, et agir
-   uniquement dans le cas où l'utilisateur connecté possède la
-   permission problématique.
+   uniquement dans le cas où l'utilisateur⋅rice connecté⋅e
+   possède la permission problématique.
 
 Avec Django-allauth
 ###################
@@ -152,7 +152,7 @@ Le paramètre ``DOMAIN`` permet de changer d'instance de Note Kfet. Par défaut,
 se connectera à ``note.crans.org`` si vous ne renseignez rien.
 
 Le paramètre ``SCOPE`` permet de définir les scopes à demander.
-Dans l'exemple ci-dessous, les permissions d'accéder à l'utilisateur
+Dans l'exemple ci-dessous, les permissions d'accéder à l'utilisateur⋅rice
 et au profil sont demandées.
 
 En créant l'application sur la note, vous pouvez renseigner
@@ -200,7 +200,7 @@ cas où elle n'est pas explicitement indiquée lors de l'autorisation.
 
 Lorsqu'un client veut s'authentifier via la Note Kfet, il va devoir accéder à une page
 d'authentification. La page d'autorisation est `<https://note.crans.org/o/authorize/>`_,
-c'est sur cette page qu'il faut rediriger les utilisateurs. Il faut mettre en paramètre GET :
+c'est sur cette page qu'il faut rediriger les utilisateur⋅rices. Il faut mettre en paramètre GET :
 
 * ``client_id`` : l'identifiant client de l'application (public) ;
 * ``response_type`` : mettre ``code`` ;
@@ -211,10 +211,10 @@ c'est sur cette page qu'il faut rediriger les utilisateurs. Il faut mettre en pa
 * ``state`` : optionnel, peut être utilisé pour permettre au client de détecter des requêtes
   provenant d'autres sites.
 
-Sur cette page, les permissions demandées seront listées, et l'utilisateur aura le choix
-d'accepter ou non. Dans les deux cas, l'utilisateur sera redirigée vers ``redirect_uri``,
-avec pour paramètre GET soit le message d'erreur, soit un paramètre ``code`` correspondant
-au code d'autorisation.
+Sur cette page, les permissions demandées seront listées, et l'utilisateur⋅rice aura le
+choix d'accepter ou non. Dans les deux cas, l'utilisateur⋅rice sera redirigée vers
+``redirect_uri``, avec pour paramètre GET soit le message d'erreur, soit un paramètre
+``code`` correspondant au code d'autorisation.
 
 Une fois ce code d'autorisation récupéré, il faut désormais récupérer le jeton d'accès.
 Il faut pour cela aller sur l'URL `<https://note.crans.org/o/token/>`_, effectuer une