# Processing with AI
## Partie 2: 👩‍⚖️ Ethics of AI

Nom - Prénom :
> Simon Tsafack
>
Sujet :
> Improve dating apps matching algorithms using NLP

>[TOC]

## Cahier des charges

### Biais

Si notre jeu de données n'est pas conçu avec suffisamment de rigueur, les biais suivant risquent d'apparaître :

>1. Des languages non communs et non repertorié ne seront pas reconnus
>2. Ces personnes se verront desavantagées en raison de leur facon de parler lors de la hierachisation
>3.

Nous allons donc nous assurer que notre modèle n'est pas biaisé en :

>1. Sourçant nos données depuis une large variété de languages et conversation
>2. S'assurant que nos données prennent en compte l'aspect rapide des abbreviations, verlan pour ne pas penaliser
>3. En s'assurant d'une proportionalité dans tous les languages enregistrés.

### Overfitting

Nous allons nous assurer que notre modèle ne sera pas dans une situation de sur-apprentissage (overfit) en :
> Vérifiant la précision de notre modèle en ayant une base de données d'entrainement assez large
> Mais aussi en se servant de la technique de “cross validation” consistant à diviser les données d’entrainement en plusieurs groupes

### Usages détournés

>Nous devons nous mettre un point d'honneur sur le fait que notre application pourrait être utilisée de façon malveillante par certaines categories de personnes. La prevention sur ce type de comportement pourrait sensibliser les gens. Pour detecter notamment des personnes adaptant leur description et leur façon d’écrire, qui pourraient tenter de contacter des personnes bien plus jeune. (Voir des mineurs, même si l’application est sensé être interdite aux moins de 18 ans)

### Fuite de données

> **🔐 Closed source:** Dans un scénario catastrophe, au cours duquel l’entièreté de notre jeu de données d’entrainement serait volé ou récupéré à partir de notre modèle, le risque relèverait de la sécurité de nos utilisateurs. En effet, si notre code, qui est normalement fermé au public, se retrouve exposé, de nombreuses failles pourraient être découverte, entrainant un risque potentiel pour les utilisateurs, qui pourraient se voir subtiliser leurs données ou meme jusqu'a se faire pirater.
Nous avons fait le choix de ne pas avoir un code open source, car notre application contiendra des données personelles et sensibles sur les utilisateurs. Ces données au vue de leur caractères, ne doivent jamais fuiter, pour maintenir une certaine confiance.
Enfin, le code pourrait même être par la même occasion volé et utilisé par des concurrents et nous affecté economiquement. Cela nous priverait d'un avantage quelconque sur les innovations que notre entreprise a pu trouver.
Dans l'ensemble c’est un parti pris pour éviter que les données sensibles fuitent.

### Piratage

> Si une personne trouvait un moyen de “tromper” notre modèle et modifier son comportement à volonté, le risque serait de mettre à mal toute l’application et risquer de la mettre dans une situation où on se questionnerait sur sa survie économique. Car si les recommendations ne correspondent plus aux attentes des utilisateurs, ils n’utiliseront plus l’application, conduisant à la faillite de l’entreprise qui la développe.