Rapport de Stage

Rapport de stage
Services web et interface graphique pour des

démonstrations d’outils du Traitement Automatique
du Langage
Baptiste Monchicourt
Année 2017–2018
Stage de deuxième année réalisé dans l’entreprise Emvista
Maître de stage : Cédric Lopez
Encadrant universitaire : Gérald Oster

Déclaration sur l’honneur de non-plagiat
Je soussigné,
Nom, prénom : Monchicourt, Baptiste
Élève-ingénieur régulièrement inscrit en 2e année à TELECOM Nancy
Numéro de carte de l’étudiant : 31622091
Année universitaire : 2017–2018
Auteur du document, mémoire, rapport ou code informatique intitulé :
Développement de Services web et interface graphique pour des

démonstrations d’outils du Traitement Automatique du Langage
développés par Emvista
Par la présente, je déclare m’être informé sur les différentes formes de plagiat existantes et sur
les techniques et normes de citation et référence.
Je déclare en outre que le travail rendu est un travail original, issu de ma réflexion personnelle,
et qu’il a été rédigé entièrement par mes soins. J’affirme n’avoir ni contrefait, ni falsifié, ni copié
tout ou partie de l’œuvre d’autrui, en particulier texte ou code informatique, dans le but de me
l’accaparer.
Je certifie donc que toutes formulations, idées, recherches, raisonnements, analyses, programmes,
schémas ou autre créations, figurant dans le document et empruntés à un tiers, sont clairement
signalés comme tels, selon les usages en vigueur.
Je suis conscient que le fait de ne pas citer une source ou de ne pas la citer clairement et com-
plètement est constitutif de plagiat, que le plagiat est considéré comme une faute grave au sein
de l’Université, et qu’en cas de manquement aux règles en la matière, j’encourrais des poursuites
non seulement devant la commission de discipline de l’établissement mais également devant les
tribunaux de la République Française.
Fait à Montpellier, le 27 août 2018
Signature :
i
ii
Rapport de stage
Services web et interface graphique pour des
démonstrations d’outils du Traitement Automatique
du Langage
Année 2017–2018
Stage de deuxième année réalisé dans l’entreprise Emvista
1, rue Charles le Téméraire
21160, PERRIGNY-LÈS-DIJON
+33 6 89 79 52 57
baptiste.monchicourt@telecomnancy.eu
TELECOM Nancy
193 avenue Paul Muller,
CS 90172, VILLERS-LÈS-NANCY
+33 (0)3 83 68 26 00
contact@telecomnancy.eu
Emvista
Cap Oméga, Rond-point Benjamin Franklin
34960, MONTPELLIER
+33 4 67 13 01 44
Maître de stage : Cédric Lopez
Encadrant universitaire : Gérald Oster
iii
iv
Remerciements
Je tiens à remercier toutes les personnes qui ont contribué au succès de mon stage et qui m’ont
aidé lors de la rédaction de ce rapport.
Tout d’abord, j’adresse mes remerciements à Pierre Achard qui m’a aidé dans ma recherche de
stage et m’a permis de postuler chez Emvista. C’est grâce à lui que j’ai pu trouver ce stage qui
était en totale adéquation avec mes attentes.
Je tiens ensuite à remercier vivement mon maitre de stage, Cédric Lopez, directeur de recherche
au sein de cette entreprise, ainsi que Melissa Mekaoui, ingénieure logiciel d’Emvista, pour leur
accueil, leur accompagnement mais également leur confiance, le temps passé ensemble et le par-
tage de leurs expertises au quotidien. Ils furent d’une aide précieuse tout au long de ces douze
semaines de stage.
Je remercie également le reste de l’équipe d’Emvista, Philippe Garnier et Jean Bort pour leur
accueil, leur esprit d’équipe et les viennoiseries du matin ! Et j’adresse aussi mes remerciements
à Johan Pompon, graphiste de Penbase, pour son écoute et son aide pour la conception du site
des démonstrations.
Enfin, je tiens à remercier Cédric Lopez et Jean Bort encore une fois pour leurs conseils et
relectures lors de la rédaction de ce rapport de stage.
v
vi
Table des matières
Remerciements v
Table des matières vii
1 Introduction 1
2 Présentation de l’entreprise 3
2.1 Informations générales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3 Produits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3.1 Prevyo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3.2 Prevyo Semantic Services (PSS) . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4 L’équipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3 Contexte du stage 7
3.1 Problématique du stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1 Contexte du stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.2 Analyse du problème . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Technologies à disposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.1 Linguistic Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.2 Jeux De Mots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.3 Authentification et API Key . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 Gestion de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4 Travail effectué 11
4.1 Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.1 Anonymiseur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.2 Désanonymiseur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.3 Highlighter ou reconnaissance d’entités nommées . . . . . . . . . . . . . 19
vii
4.1.4 Mots clés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.5 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.6 Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1.7 Sentiments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2 Interface web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.1 Contexte/Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.2 Technologies utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.3 Résultats sur le site web . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2.4 Documentation des APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5 Bilan du stage 39
5.1 Résultats obtenus et impacts des solutions . . . . . . . . . . . . . . . . . . . . . . 39
5.2 Difficultés rencontrées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.3 Développements futurs des solutions . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.4 Devenir des produits développés . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6 Conclusion 41
Bibliographie / Webographie 43
Liste des illustrations 45
Listings 47
Annexes 50
A Première Annexe 51
A.1 Anonymiseur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
A.2 Highlighter ou reconnaissance d’entités nommées . . . . . . . . . . . . . . . . . . 53
A.3 Démonstration générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Résumé 55
Abstract 55
viii
1 Introduction
Le Traitement Automatique du Langage (TAL) est un domaine regroupant linguistique, informa-

tique et intelligence artificielle [4]. Il a l’ambition de comprendre et traiter le langage naturel à
travers notamment l’analyse syntaxique et sémantique.
Les applications du TAL sont variées, mais Emvista en traite une grande partie, grâce à son ex-
pertise, avec son outil d’analyse linguistique. Parmi ces applications on compte la reconnaissance
d’entités nommées, l’identification de thèmes dans un texte, la reconnaissance d’actions, dont dé-
coule l’extraction de tâches, et enfin l’analyse d’opinion. Chacune de ces compétences peut être
identifiée à une brique technologique, qui une fois toutes assemblées constituent une solution
développée par l’entreprise. Alors que cette dernière est en cours de construction, un nouveau
besoin grandit pour Emvista : la possibilité de montrer et visualiser les résultats obtenus pour
chaque brique technologique à travers des démonstrations interactives et variées.
Par exemple, la confidentialité des données personnelles est actuellement un enjeu majeur des
prochains mois, voire prochaine années. C’est pourquoi Emvista a décidé de concevoir une solu-
tion d’anonymisation automatique de textes, permettant ainsi de traiter de grandes quantités de
données rapidement. Le développement de cette solution fait partie des objectifs du stage, tout
comme la création de divers services web se reposant sur les briques technologiques du TAL
d’Emvista dans le but de réaliser des démonstrations sur une interface web.
Au cours de ce rapport, nous présenterons tout d’abord l’entreprise Emvista, son histoire, son
équipe (section 2 Présentation de l’entreprise) ; puis nous décrirons les objectifs et enjeux du stage
ainsi que les divers outils à disposition (section 3 Contexte du stage) ; ensuite nous détaillerons
le travail effectué en présentant les différentes solutions proposées (section 4 Travail effectué) ;
et enfin nous réaliserons un bilan général du stage, notamment pour mettre en perspective les
résultats obtenus avec ceux attendus (section 5 Bilan du stage).
1
2
2 Présentation de l’entreprise
Nous allons dans un premier temps présenter Emvista où le stage s’est déroulé, en fournissant
tout d’abord des informations générales avant de revenir sur l’historique et l’origine de la société,
pour enfin présenter un peu plus en détails l’équipe de l’entreprise.
2.1 Informations générales
Emvista est une société par actions simplifiée est en activité depuis février 2018. Elle fait partie
du groupe INDIA JULIET, et est actuellement basée à Cap Omega, un incubateur d’entreprises,
au Ront-point Benjamin Franklin, Montpellier (34000), France [8]. La Société a pour objet, en
France et à l’étranger :
— le développement et la commercialisation d’agents virtuels intelligents ;

— le développement et la commercialisation d’outils informatiques, de traitement des don-
nées, de technologies de l’information et de la communication.
Le capital social est fixé à la somme de CENT MILLE EUROS (100 000 euros).
Les co-fondateurs de l’entreprise sont Philippe Garnier (Président) et Jean Bort (Directeur
technique). Emvista compte deux employés : Cédric Lopez (Directeur de recherche) et Melissa
Mekaoui (ingénieure logiciel).
2.2 Historique
Emvista a pour origine un projet né au sein de la société Penbase. Le directeur technique et le

directeur général de cette société ont l’idée en 2008 de construire une application internet qui
récupère les textes des e-mails, des SMS et des réseaux sociaux pour les afficher sous forme d’une
liste unifiée qui centralise et met à disposition sur un seul écran web toute l’information reçue
par un utilisateur donné.
L’idée est alors de faciliter l’accès aux différentes sources Internet de données textuelles. Elle évo-
lue en 2010 vers un système dénommé « P2 » dont l’objectif est de dégager les thèmes principaux
de tous les messages centralisés pour en faciliter la lecture. À partir de 2013, un programme de
recherche est lancé au sein de Penbase pour classer les thèmes ainsi trouvés par ordres d’urgence
et d’importance. Mais les résultats sont insuffisants et les deux porteurs de projet envisagent fin
2016 de créer une entreprise dédiée au projet renommé « Prevyo » afin de mobiliser des fonds
pour embaucher une équipe de chercheurs et d’ingénieurs. Les deux porteurs suivent une for-
mation « Jump’in Création » au sein du BIC de Montpellier pendant tout le mois de juin 2017,
3
demandent à une stagiaire de l’Université de Montpellier de reprendre leurs travaux de recherche
en juillet 2017, obtiennent l’agrément du BIC et une bourse French Tech (BFT) auprès de bpifrance
en octobre 2017, sont rejoints par le chercheur spécialiste du traitement automatique du langage
naturel Cédric Lopez et créent la société Emvista en février 2018 et l’installent dans la pépinière
Cap Oméga de Montpellier Méditerranée Métropole en juin 2018.
Emvista est donc un éditeur de services logiciels, spécialiste de la compréhension du langage

naturel. Elle propose une gamme de services logiciels qui permet à une machine d’analyser fine-
ment le langage naturel pour en extraire du sens. Les applications sont multiples : accélération du
traitement des e-mails, anonymisation de messages, compression du stockage de messages, . . .
2.3 Produits
Emvista est encore une jeune start-up et se trouve actuellement dans une phase de recherche et
développement intensive. Elle a l’intention de débuter sa mise en production vers fin 2019.
2.3.1 Prevyo
Prevyo est le produit phare de l’entreprise.
C’est un assistant virtuel, personnel et intelligent qui, sous la forme d’un chatbot, propose chaque
matin à l’utilisateur la liste des dix tâches les plus prioritaires à mener pour optimiser son temps
de travail. Cette liste est construite à partir de l’analyse sémantique des e-mails de l’utilisateur que
Prevyo classe en projets avant d’en extraire les actions puis de les prioriser. Prevyo est accessible
en mode SaaS (logiciel en tant que service ou software as a service).
2.3.2 Prevyo Semantic Services (PSS)
Prevyo Semantic Services est constitué d’un ensemble de web services à la disposition des éditeurs
pour doter leurs logiciels de capacités d’analyse sémantique :
— anonymisation réversible (pseudonymisation) pour anonymiser des données textuelles

sensibles ;
— reconnaissance des entités nommées dans les textes (noms de personnes, noms d’organi-
sations, noms de produits, etc.), par exemple pour développer un système de veille indus-
trielle ;
— liage des entités nommées à une base de connaissance, par exemple pour enrichir en temps
réel la navigation sur Internet (affichage d’informations complémentaires) ;
— extraction de termes clés (présents dans le texte analysé) et de concepts (absent dans le
texte analysé), par exemple pour l’indexation automatique des pages Web ;
— annotation en rôles sémantiques (qui fait quoi, quand, comment, où. . . ), par exemple pour
l’extraction d’événements, d’actions, de tâches, . . . ;
— analyse de l’opinion et des émotions (texte plutôt positif ou négatif qui exprime des émo-
tions telles que la colère, la joie, la tristesse), par exemple pour évaluer automatiquement
l’opinion populaire sur un produit dans les réseaux sociaux ;
— structuration automatique de texte, par exemple pour élaborer un système de question-
réponse.
4
2.4 L’équipe
Philippe Garnier, ingénieur informatique Supinfo Paris, a débuté sa carrière chez Apple en 1994
avant de rejoindre le projet Penbase en 2000. Spécialiste des compilateurs, il devient directeur
technique de la société pour laquelle il conçoit et réalise un environnement de développement
JavaScript complet (éditeur, compilateur, machine virtuelle) adapté aux appareils mobiles (PDAs,
smartphones). Il reprend la direction de la société en 2005 et définit une nouvelle stratégie visant à
équiper les employés travaillant sur site d’applications mobiles métiers. Grâce à une avance tech-
nologique importante et à des accords de distribution passés avec de grands partenaires (Orange,
Edenred, Berger Levrault), Penbase devient le leader en France des éditeurs de « télégestion mo-
bile » dans les secteurs du service à la personne et du nettoyage industriel.
Philippe Garnier crée en 2016 le groupe India Juliet qui devient l’actionnaire principal de Penbase
puis d’Odéale, un autre éditeur de logiciels métiers, et enfin d’Emvista, créée en février 2018.
Jean Bort, titulaire d’un DUT Informatique de l’Université de Montpellier, a démarré sa carrière
chez Penbase qu’il a rejoint en tant que premier employé et développeur. Spécialiste des techno-
logies cloud, il est ensuite devenu chef de projet puis directeur technique de la société Penbase
avant de co-fonder Emvista en 2018.
Cédric Lopez a rejoint Emvista en tant que directeur de recherche en février 2018. Cédric a reçu
son titre de docteur au LIRMM (Laboratoire d’Informatique, de Robotique et de Microélectronique
de Montpellier). Ses recherches se situent à l’intersection du Traitement Automatique du Langage
Naturel, de la Représentation des Connaissances et du Web Sémantique. Cédric a été impliqué
dans de nombreux projets de recherche collaboratifs nationaux et européens tels que REUs (FUI),
SMILK (Laboratoire Commun avec INRIA, LabCom ANR), SOMA (EU), SUD4SCIENCE (MSH-M),
TIER (EU), SYNODOS (ANR), LEILAS (Eurostars) qui ont donné lieu à de nombreuses publications
internationales. Il fait partie de comités scientifiques de plusieurs conférences.
5
6
3 Contexte du stage
Présentons à présent le contexte du stage, c’est-à-dire ses objectifs et enjeux, les technologies à
disposition afin de réaliser ces objectifs et également son cadre en terme de gestion de projet.
3.1 Problématique du stage
Commençons par nous intéresser à ce qui doit être réalisé, dans quel but, et comment cela peut
être fait, de manière assez générale et théorique pour le moment.
3.1.1 Contexte du stage
L’objectif du stage était initialement de concevoir un système d’anonymisation de texte et une

interface pour en faire une démonstration. Cependant, au vu du bon avancement de cette première
mission, le sujet a évolué et s’est élargi : il s’agit à présent de concevoir le back-office (web service)
et le front-office s’interfaçant sur ce back-office d’une application de démonstration pour des
outils du Traitement Automatique du Langage (TAL) développés par Emvista.
La finalité de ces web services est double : tout d’abord, et avant toute chose, ils doivent permettre
de réaliser des démonstrations pour présenter les résultats obtenus suite à l’analyse du texte ; et,
dans une moindre mesure, ils doivent pouvoir être directement utilisés par des clients lorsque
l’entreprise passera dans la phase de production. Pour la partie front-office il faut également
choisir une représentation des résultats et l’implémenter en HTML/JavaScript/CSS comme les
résultats seront exposés sur le site web de l’entreprise. Les représentations doivent être variées
par la forme afin de proposer plusieurs points de vue à l’utilisateur.
3.1.2 Analyse du problème
Les objectifs fixés doivent être réalisés en se basant sur l’analyseur linguistique développé par
Emvista, décrit ci-après, et effectuer un travail de recherche afin d’avoir une idée de l’état de l’art
actuel sur les outils et démonstrations du TAL. Une bonne compréhension et appropriation du
sujet est une des clés pour la réussite de ce stage.
7
3.2 Technologies à disposition
Plusieurs technologies sont à notre disposition pour réaliser les missions attribuées. Il est impé-
ratif de les utiliser puisqu’on cherche à exposer leurs résultats, isolés au niveau de chaque brique
technologique. Voyons donc ce qu’ils sont et comment ils peuvent nous être utiles.
3.2.1 Linguistic Analyzer
L’outil principal sur lequel mon travail se base est l’analyseur linguistique développé par Emvista.
Il structure le texte en phrases composées de tokens, tokens qui correspondent à des mots enrichis
par des informations syntaxiques (catégories grammaticales, relations syntaxiques de type sujet
ou objet par exemple), sémantiques (synonymes, domaines par exemple), et lexicales (form ou
lemma). Les actions ou tâches du texte peuvent également être extraites, ainsi que les opinions et
sentiments associées à celles-ci.
L’appel à l’analyseur se fait de la manière suivante :

1 Document document = new Document ( ) ;
2 A n a l y z e a n a l y s e = new A n a l y z e ( ) ;
3 Map< S t r i n g , O b j e c t > p a r a m e t e r s = new HashMap < > ( ) ;
4 parameters . put ( " t e x t " , t e x t ) ;
5 document = a n a l y s e . l i n g u i s t i c A n a l y z e ( f a l s e , / / n o r m a l i z a t i o n
6 false , / / languageDetection
7 true , / / lexicalEnrichment
8 true , / / ner
9 true , / / timeRecognition
10 f a l s e , / / sentenceType
11 false , // coreference
12 true , / / sentiment
13 false , // titleAnalysis
14 false , // entityLinking
15 parameters ) ;
Listing 3.1 – Exemple d’appel au Linguistic Analyser
Le texte à analyser lui est fourni via le paramètre parameters, et ensuite les modules à utiliser lui
sont indiqués par les autres paramètres. Les modules appelés par les web services développés au
cours de ce stage sont décrits par la suite.
Parmi les briques technologiques développées par Emvista, il y a celle qui effectue la reconnais-
sance d’actions (par exemple des tâches qu’un utilisateur doit réaliser) dont le principe consiste à
repérer les verbes à la forme active du texte et, ensuite, récupérer les composants de l’action dé-
crite (composants qui répondent aux questions qui ? Quoi ? Où ? Comment ? Quand ? Pourquoi ?
etc.). Ce module n’est pas directement inclus dans l’analyseur linguistique et doit être appelé une
fois la première analyse effectuée comme illustré dans le listing 3.2.
1 document = A c t i o n R e c o g n i z e r . i n s t a n c i a t e A c t i o n ( document ) ;
Listing 3.2 – Exemple d’appel au module de reconnaissance d’actions
Ensuite, il est possible de travailler directement à partir de l’objet Document renvoyé, ou bien de
le traduire sous la forme d’un JSON grâce à un objet ObjectMapper . Le JSON ainsi obtenu est
8
trop imposant pour que nous le présentions en détails ici, mais sa structure générale est donnée
dans le listing 3.3.
1 {
2 / ∗ En− t e t e a v e c ID , d a t e de c r e a t i o n , . . . ∗ /
3 ...
4 / ∗ Contenu s u r l e q u e l on t r a v a i l l e ∗ /
5 " actions " : [
6 ...
7 ],
8 " sentences " : [ {
9 " idSentence " : 0 ,
10 / ∗ En− t e t e de l a p h r a s e ∗ /
11 ...
12 / ∗ L i s t e d e s t o k e n s de l a p h r a s e ∗ /
13 " tokens " : [ {
14 " idToken " : 0 ,
15 " form " : " Mardi " ,
16 " lemma " : " m a r d i " ,
17 " start " : 0 ,
18 " end " : 5 ,
19 " e n t i t y T y p e " : " n e r d : Time >DATE " ,
20 " pos " : "NC " ,
21 " opinion " : " " ,
22 " e m o t i o n s " : [ ] , / ∗ P o u r r a i t ê t r e [ j o y , s u r p r i s e ] pour un a u t r e mot ∗ /
23 " p h r a s e " : " Mardi 28 û a o t " ,
24 " uri " : " " ,
25 " relationMap " : { } ,
26 " actionVerb " : false ,
27 " negative " : false ,
28 / ∗ A u t r e s champs que nous n ’ u t i l i s o n s p a s i c i ∗ /
29 ...
30 },
31 / ∗ A u t r e s t o k e n s de l a p h r a s e ∗ /
32 ...
33 },
34 / ∗ A u t r e s p h r a s e s du t e x t e ∗ /
35 ...
36 ]
37 }
Listing 3.3 – Structure du JSON obtenu à partir de l’analyse linguistique
Le module de reconnaissance d’actions enregistre le résultat de son analyse dans le champs

”actions”. On y trouve une énumération des actions détectées dans le texte, composées de to-
kens, ainsi que les phrases du texte (”sentences”) elles aussi composées de tokens. Un token peut
être identifié dans une phrase par son id, ou bien grâce aux indices de début et de fin du mot.
Ensuite, il apporte des informations lexicales telles que le ”f orm”, ou bien le ”lemma” qui est la
forme canonique du mot. S’il fait partie d’un groupe de mots, au niveau sémantique, ce dernier
peut être récupéré grâce au JSON Array ”phrase”. Il y a également son type avec ”entityType”,
et sa catégorie grammaticale (ou part of speech en anglais) avec ”pos”. Si le token représente un
verbe, les champs ”actionV erb” et ”neдative” indiquent respectivement si c’est un verbe d’action
ainsi que s’il est accompagné d’une négation ou pas. Enfin, le champs ”relationMap” donne des
informations sémantiques sur le mot avec par exemple ses synonymes, ou les domaines auxquels
il peut appartenir, tandis que le champs ”uri” fournit le lien DBpedia [6] (base de connaissance
constituant une version structurée de Wikipedia) qui correspond au mot.
Ensuite, en ce qui concerne l’analyse d’opinion, qui sera développée lorsque le web service asso-
9
cié sera introduit, ce sont les champs ”opinion” et ”emotions” qui sont intéressants. Ils indiquent
respectivement si le mot ou l’action est plutôt ressentie de manière positive, négative ou neutre,
et les émotions fondamentales qui y sont associées. La liste exhaustive de ces émotions fonda-
mentales [7] est la suivante : joie, colère, tristesse, surprise, dégoût et peur.
C’est donc à partir de ces informations que sont développés les différents services décrits dans la
section suivante de ce rapport.
3.2.2 Jeux De Mots
Jeux de Mots (JDM) est une ressource construite et mise à jour par Mathieu Lafourcade, professeur
au Laboratoire d’Informatique, de Robotique et de Microélectronique de Montpellier (LIRMM).
C’est une base de données relationnelle contenant des mots et des liens qui caractérisent les
relations entre les mots comme les synonymes, holonymes, domaines, etc. Elle est enrichie grâce
aux personnes qui jouent sur le site de Mathieu Lafourcade, http://www.jeuxdemots.org/
jdm-accueil.php. Cette ressource permet d’apporter de la sémantique aux mots rencontrés et est
ainsi particulièrement utile pour l’extraction de concepts.
3.2.3 Authentification et API Key
Actuellement, il y a une API key unique propre à chaque web service.
Cependant, dans les semaines ou mois à venir, un système d’authentification sera mis en place et intégré
aux web services. Il faudra faire une demande de token JWT, une API spécialisée dans la sécurité d’APIs,
pour pouvoir le transmettre au web service et ainsi obtenir le résultat escompté.
3.3 Gestion de projet
L’équipe d’Emvista fonctionne selon la méthodologie agile Scrum. Ainsi, le travail était défini par sprints
de quelques jours à une semaine au maximum. Tous les matins, nous effectuions un stand-up meeting de
quelques minutes afin d’actualiser nos tâche à faire, en cours, et terminées et partager notre avancée et les
difficultés rencontrées avec le reste de l’équipe.
Pour la communication, l’outil principal était Slack, ainsi que les e-mails. Les différentes technologies
développées étaient partagées et versionnées sur GitHub et les documents hors code (PDF, images, articles,
etc.) étaient mis en commun en ligne sur Google Drive.
10
4 Travail effectué
Le travail a été réalisé tout au long des douze semaines de stage. Les différents services web ont été déve-
loppés les uns après les autres, que ce soit le back-office avec le service en soi, ou le front-office avec leurs
représentations respectives, et sont présentés ici selon la chronologie du travail effectué. Ce n’est qu’après
qu’ils aient tous été conçus qu’ils ont été intégrés à l’interface graphique web finale.
Nous allons tout d’abord nous concentrer sur le back-office, puis sur les représentations graphiques des
résultats obtenus.
4.1 Web Services
Pour l’ensemble des web services, les échanges HTTP sont gérés avec Jersey, un framework qui permet
de développer des web services REST f ul, c’est-à-dire qui respectent l’architecture REST (REpresentational
State Transfer). Ce style d’architecture impose un cadre pour construire des applications faciles d’utilisation
et standardisées, grâce à des opérations uniformes et sans état. Pour qu’un service soit considéré RESTful,
il faut respecter les cinq contraintes suivantes :
1. Architecture Client/Serveur : le client émet une requête, le service la traite et renvoie une réponse.
2. Aplication sans état : ne garde pas en mémoire les requêtes précédentes, par conséquent le résultat
obtenu ne varie jamais en fonction des requêtes déjà effectuées.
3. Service cachable : une fois une requête effectuée une première fois la réponse est enregistrée pour
ne pas avoir à refaire tous les calculs les prochaines fois.
4. Système à plusieurs couches : le client ne doit pas savoir ni se soucier de comment la réponse
est renvoyée.
5. Interface uniforme : une ressource doit posséder un identifiant unique (son URI), avoir une re-
présentation (un format constant dans le temps), le type de la réponse doit être renseignée (JSON,
XML, ...).
Une classe Controller gère ces échanges et fait appel à la classe principale du service qui est chargée de
faire les calculs. L’appel aux différents web services se fait par une requête GET avec un JSON contenant
les informations nécessaires. Ces JSON seront détaillés par la suite.
Il y a quatre types de services au sens du traitement automatique du langage : ceux qui concernent les
entités nommées (anonymisation, reconnaissance et mise en valeur d’entités nommées), ceux sur l’identi-
fication de thème dans un texte (mots clés et concepts), sur l’extraction de tâches ou actions et enfin sur
l’analyse d’opinion ou sentiment. Expliquons déjà en quoi consistent ces thèmes du TAL avant de discuter
des différents objetifs et solutions proposées.
11
4.1.1 Anonymiseur
Le G29 (groupe des CNIL européens) donne la définition suivante de l’anonymisation [3] :
“l’anonymisation est le résultat du traitement des données personnelles afin d’empêcher, de façon
irréversible, toute identification.”
De plus, toujours d’après le G29, une solution d’anonymisation peut être évaluée sur les trois critères
suivants :
— L’individualisation : est-il possible d’isoler un individu ?

— La corrélation : est-il possible de relier entre eux des ensembles de données distincts concernant
un même individu ?
— L’inférence : peut-on déduire de l’information sur un individu ?
À qui un tel service peut être utile ? Tous les organismes disposant de données textuelles sensibles (hô-
pitaux par exemple). En effet, la protection des données personnelles est un enjeu majeur actuellement,
notamment avec l’émergence du deep learning. Ce dernier a engendré un besoin énorme de données d’où
résultent des problèmes éthiques ou légaux majeurs. Or une solution d’anonymisation participeraient à la
résolution de ces problèmes.
Objectifs/Principe
D’après Michel Charolles, une entité nommée est une expression linguistique référentielle [2]. Pour com-
prendre un texte, la première chose à faire est d’identifier les mots et locutions présentes. Quel mot corres-
pond à une personne ? A un lieu ? Etc. Le but est donc de réaliser une classification des mots pour ensuite
en tirer des informations.
L’objectif de ce web service est de proposer une solution d’anonymisation, remplaçant les entités nommées
par des balises, paramétrable par le client que ce soit pour les types d’entités à anonymiser (noms, lieux,
dates, e-mails, numéros de téléphones, ...), pour les paramètres du JSON de sortie ou bien pour le caractère
irréversible ou non de l’opération (on parle alors de pseudoanonymisation [5]).
La solution devra se baser sur les technologies développées par Emvista et prendra en entrée un JSON
contenant le texte initial ainsi que différents paramètres cités précédemment.
Technologies utilisées
Le langage de programmation choisi est le Java, par souci d’uniformité par rapport aux autres technologies
et produits développés par Emvista. Aussi, pour la même raison, l’IDE utilisé est Eclipse Oxygen et le
projet créé est un projet Maven afin de faciliter la gestion des dépendances.
Pour la gestion des requêtes HTTP c’est le framework Spring Boot qui a été sélectionné car facile d’utili-
sation, notamment pour la phase de développement. Et dans le but de respecter l’architecture REST nous
utilisons le framework opensource Jersey Client qui rend cette tâche plus simple.
Enfin, pour laisser la possibilité au client de paramétrer le service comme réversible, nous avons besoin
d’une base de données pour stocker les informations pseudoanonymisées. Pour sa vitesse d’exécution, et
le fait qu’elle est opensource, nous utilisons la base clé-valeur Redis.
12
Solution proposée
Afin d’anonymiser le texte, les entités nommées sont repérées, grâce au typage des mots réalisé par l’ana-
lyse linguistique où le préfixe "nerd :" est ajouté pour celles-ci, puis remplacées par des balises. En effet,
ce sont elles qui portent des informations non génériques et permettent donc d’obtenir des données sur
un lieu, une personne, une organisation, ou autre, précise. Une balise est formée de la manière suivante :
[TYPE_X_Y], avec TY PE les quatre premières lettres du type de l’entité anonymisée (ex : PERS, LOCA,
TIME, ...), X la longueur de l’entité anonymisée, et Y la clé en base64 qui permet de retrouver l’entité dans
la base de donnée Redis.
Figure 4.1 – Anonymiser – Structure d’une balise
L’objectif est donc de modifier le texte de manière à n’avoir plus que des balises à la place des entités
nommées. L’appel au web service se fait par requête HTTP avec comme body un JSON dont la structure
est la suivante :
1 {
2 " t e x t " : " Le t e x t e que j e s o u h a i t e a n o n y m i s e r . " ,
3 " parameters " : {
4 " entities " : {
5 " person " : true ,
6 " location " : false ,
7 ...
8 },
9 " outputParameters " : {
10 " nerdsUsed " : true ,
11 " tagsUsed " : false ,
12 ...
13 },
14 " l e x i c a l −enrichment " : true ,
15 " normalization " : false ,
16 ...
17 }
Listing 4.1 – JSON en entrée de l’anonymiseur
Le champs ”text” contient le texte à anonymiser sous format Strinд. L’objet ”parameters” contient les
paramètres suivant :
— ”cleaner ” : active l’utilisation du cleaner qui va supprimer les retours à la ligne et ajouter des points
en bout de phrases non ponctuées. Cette option est notamment utile en cas de copier/coller de texte
venant d’un document au format .pdf par exemple où des caractères invisibles peuvent être ajoutés
et risquent de biaiser l’analyse syntaxique.
— ”f usion − taдs” : active la fusion de balises successives ayant le même type en une seule balise.
13
— ”lanдuaдe − detection” : active la détection de langage. Cette option sera utile lorsque l’analyseur
sera capable de gérer plusieurs langues différentes, et actuellement pour éviter de tenter d’analyser
un texte non-français voire du code informatique (HTML par exemple).
— ”lexical − enrichment” : active l’enrichissement du lexique, ce qui permet d’avoir les synonymes,
domaines, holonymes des mots et d’autres types de relations sémantiques.
— ”normalization” : active la normalisation du texte, permettant d’analyser une partie du langage

abrégé, dit langage SMS.
— ”reversible” : active la réversibilité du processus, qui devient alors de la pseudoanonymisation.
— ”entities” : active l’anonymisation des entités avec comme attribut true. La liste des 20 types d’en-
tités est la suivante : animal, brand, emails, event, facility, fictionalperson, location, measure, media,
method, organization, person, phonenumber, product, productrange, reward, species, sportsteam, trans-
portline, url.
— ”outputParameters” : indique les paramètres voulus en sortie. Peuvent être demandés : ”nerdsU sed”
(le nombre d’occurrences de chaque sous-type d’entités rencontré), ”taдsU sed” (le nombre d’occur-
rences de chaque type global - les 20 cités ci-dessus - d’entités rencontré), ”wordsAndT aд” (5-uplet
contenant la balise [taд], le/s mot/s correspondant [word], la ligne [line], l’indice [index] et le type
de l’entité [type]), oriдinalT ext (le texte original), inputParameter (les paramètres d’entrée que
nous décrivons ici).
Le caractère paramétrisable du web service service est donné par ce JSON en entrée. Une fois ce dernier ré-
cupéré, le texte à anonymiser en est extrait et placé dans un objet Strinд. Ensuite, les opérations présentées
sur la figure 4.2 qui dépendent du paramétrage d’entrée sont appliquées. Celles-ci comprennent :
— l’utilisation du cleaner si demandé par l’utilisateur ;

— l’instanciation d’un objet Jedis pour pouvoir communiquer avec la base Redis si la réversibilité de
l’opération d’anonymisation est désirée ;
— un appel à l’analyseur linguistique pour structurer le texte et obtenir le Document ou JSON corres-
pondant et pouvoir ensuite travailler dessus ;
— enfin on extrait les tokens dans une liste de Token pour les parcourir par la suite.
Figure 4.2 – Anonymiser – Opérations préalables à l’anonymisation du texte
Un Token est un objet contenant le JSONObject correspondant aux informations d’un token du JSON
14
retournée par la Linguistic Analyzer, ainsi que d’autres champs utiles pour les données à retourner dans
le JSON qu’on construit par la suite (comme par exemple le numéro de ligne dans le texte).
On a donc à ce moment le texte sous la forme dont il doit être traité et la liste des Tokens extraits du texte
par le Linguistic Analyzer et le Linguistic Model. On parcourt alors ces deux objets en parallèle en testant
à chaque caractère du texte s’il est au début du token courant à traiter :
— Si c’est le cas : on vérifie son type pour savoir si c’est une entité nommée, et s’il fait partie de la
liste des types d’entités à anonymiser.
— Si c’est le cas : on ajoute au texte anonymisé la balise correspondante (voir plus loin pour la
description de la balise), on passe au token suivant et on place le curseur du texte à la fin du
mot courant.
— Sinon : on ajoute la mot courant au texte anonymisé et on met à jour l’indice de parcours à la
fin du mot.
— Sinon : on ajoute au texte anonymisé le caractère courant. Et on continue le parcours.
Ci-dessous le diagramme de classe de l’Anonymiseur. La classe principale est Anonymiser et la méthode

principale de cette classe est anonymise(Strinд, JSONObject) : JSONObject. C’est là où le parcours est
effectué. Le stockage est base de données Redis se fait via la classe JedisFunction.
Figure 4.3 – Anonymiseur – Diagramme de classe
Une fois le parcours des tokens terminé, la fin du texte à traiter est ajoutée au texte anonymisé. Enfin, le
15
JSON de sortie est créé et construit grâce à la classe JsonOutput où ont été enregistrées les informations
nécessaires tout au long du parcours du texte lorsqu’on remplaçait un mot par une balise. Les champs qui
y sont insérés dépendent de ce qui a été demandé dans la requête. Puis il est renvoyé dans une réponse
HTTP. Voyons sa composition plus en détails à présent, pour le texte initial : "Anonymise-moi, Baptiste
Monchicourt. John Snow".
1 {
2 " anonymised " : " Anonymise −moi , [ PERS_20_Bu ] . [ PERS_9_gOt ] " ,
3 " nerdsUsed " : {
4 { " nerd : Person " : 2 }
5 },
6 " tagsUsed " : {
7 { " PERS " : 2 }
8 },
9 " wordsAndTags " : {
10 {
11 " t a g " : " [ PERS_20_Bu ] " ,
12 " word " : " B a p t i s t e M o n c h i c o u r t " ,
13 " type " : " nerd : Person " ,
14 " index " : 15 ,
15 " lineNUmber " : 0
16 },
17 {
18 " t a g " : " [ PERS_9_gOt ] " ,
19 " word " : " John Snow " ,
21 " index " : 36 ,
22 " lineNumber " : 0
23 }
24 }
26 " entities " : {
29 ...
30 },
31 " lexicalEnrichment " : true ,
33 ...
34 }
Listing 4.2 – JSON en sortie de l’anonymiseur
La clé ”anonymised” est associée au texte anonymisé. La clé ”parameters” est associée aux paramètres
d’entrée. Détaillons à présent les trois autres :
— ”nerdsU sed” : compte le nombre de chaque type d’entité rencontré. Dans les exemples deux per-
sonnes (nerd :Person) ont été anonymisées.
— ”taдsU sed” : compte le nombre de chaque type de tag utilisé.
— ”wordsAndT aдs” : est composé de quatre champs :

— ”taд” : la balise utilisée pour l’anonymisation (voir plus loin pour la formation de la balise) ;
— ”word” : le mot anonymisé ;
— ”type” : le type de l’entitié anonymisée ;
— ”index” : l’indice dans la ligne du début du mot anonymisé ;
— ”lineNumber ” : le numéro de la ligne où se trouve le mot anonymisé.
16
Excepté ”anonymised”, tous les éléments de ce JSON sont optionnels et peuvent être renvoyés ou non
suivant les paramètres d’entrée (”parameters”/”outputParameters”).
Enfin, il est possible de modifier la structure de la balise en ajoutant un paramètre ou modifiant la fonction
qui forme les balises afin de répondre aux exigences particulières d’un client. L’algorithme a été conçu de
manière à ce que cette modification puisse être réalisée facilement.
Tests et évaluation
Les tests ont été majoritairement réalisés avec des extraits d’articles Wikipedia générés aléatoirement. Ils
ont été effectués au cours et après le développement du web service, puisqu’il y a énormément de cas
particuliers à traiter. La validation et l’optimisation de l’outil se sont donc faites de manière empirique.
Bilan
Lorsque l’analyse linguistique détecte une entité nommée et que celle-ci est d’un des types qu’on doit ano-
nymiser, elle est bien remplacée par une balise. Si l’option de réversibilité est activée, le mot est enregistré
dans la base Redis, associé à la clé de sa balise.
Les résultats dépendent ensuite de l’analyseur qui est en cours de construction.
4.1.2 Désanonymiseur
Objectifs/Principe
L’objectif est de pouvoir retrouver le texte original à partir d’un texte (pseudo)anonymisé avec l’anonymi-
seur mais uniquement si l’option de réversibilité a été sélectionnée.
Le langage de programmation choisi est le Java, par souci d’uniformité par rapport aux autres technologies
et produits développés par Emvista. Aussi, pour la même raison, l’IDE utilisé est Eclipse Oxygen et le
projet créé est un projet Maven afin de faciliter la gestion des dépendances.
Pour la gestion des requêtes HTTP c’est le framework Spring Boot qui a été sélectionné car facile d’utili-
sation, notamment pour la phase de développement. Et dans le but de respecter l’architecture REST nous
utilisons le framework opensource Jersey Client qui rend cette tâche plus simple.
Enfin, pour retrouver les mots correspondant aux balises nous utilisons la même base clé-valeur Redis
que pour l’Anonymiseur.
Solution proposée
L’appel au web service se fait par requête HTTP avec comme body un JSON dont la structure est ci-après.
1 {
2 " t e x t " : " Le t e x t e que j e s o u h a i t e d e s a n o n y m i s e r . " ,
17
4 " entities " : {
7 ...
8 },
10 " tagsUsed " : false ,
11 " wordsAndTags " : t r u e ,
12 " orginalText " : false ,
13 " inputParameters " : true
14 }
15 }
Listing 4.3 – JSON en entrée du désanonymiseur
Le champs ”text” contient le texte à anonymiser sous format Strinд. L’objet ”parameters” contient les
paramètres suivants : ”entities” qui indique les entités à désanonymiser (ce sont les mêmes que pour l’ano-
nymiseur) ; ”outputParameters” donnant les champs du JSON de sortie (ce sont les mêmes que pour l’ano-
nymiseur, sauf ”nerdsU sed” qui n’y est pas).
Une fois le JSON récupéré et envoyé à la fonction de désanonymisation, dans la classe U nanonymiser , le
texte est parcouru caractère par caractère. A chaque fois qu’une balise respectant la forme définie précé-
demment est trouvée (la vérification se fait sur les trois composantes de la balise), le(s) mot(s) correspondant
sont recherchés dans la base Redis à partir de la clé, et la balise est alors remplacée par le mot originel.
Lorsqu’une balise est remplacée, on ajoute le 5-uplet wordsAndT aдs et l’élément taдsU sed correspondant
est incrémenté. Les éléments du JSON de sortie sont donc actualisés au fur et à mesure des modifications.
Une fois le parcours terminé, le JSON est renvoyé dans le body de la réponse. Voici le résultat pour
l’exemple : "Désanonymise-moi, [PERS_20_Bu]. [PERS_9_gOt]".
1 {
2 " o r i g i n a l T e x t " : " Desanonymise −moi , [ PERS_20_Bu ] . [ PERS_9_gOt ] " ,
3 " unanonymised " : " Desanonymise −moi , B a p t i s t e M o n c h i c o u r t . John Snow " ,
4 " tagsUsed " : {
5 { " PERS " : 2 }
6 },
7 " wordsAndTags " : [
8 { " t a g " : " [ PERS_20_Bu ] " ,
9 " word " : " B a p t i s t e M o n c h i c o u r t " ,
11 " index " : 18 ,
12 " lineNUmber " : 0 } ,
13 { " t a g " : " [ PERS_9_gOt ] " ,
14 " word " : " John Snow " ,
16 " index " : 32 ,
17 " lineNumber " : 0 }
18 ],
20 " entities " : {
23 ...
24 }
25 }
Listing 4.4 – JSON en sortie du désanonymiseur
18
Les premiers tests ont été effectués sur les méthodes de la classe JedisFunctions qui permettent d’interagir
avec la base Redis. Ensuite, l’évaluation du bon fonctionnement du service se fait grâce à des extraits
d’articles Wikipedia générés aléatoirement qui sont anonymisés puis désanonymisés, et on compare avec
le texte initial.
Bilan
L’opération de désanonymisation se passe correctement. Un seul cas peut éventuellement poser problème,
c’est lorsque dans le texte il y a un enchaînement de caractères qui est de la même forme que les balises.
Dans ce cas on risque d’avoir un faux-positif sur la présence d’une balise et de le remplacer par un des
mots de notre base Redis.
4.1.3 Highlighter ou reconnaissance d’entités nommées
Ce service fait également partie de ceux concernant les entités nommées. La reconnaissance d’entités nom-
mées est au centre de la problématique d’extraction d’informations d’un corpus. La mise en valeur de ces
entités est un classique et il est facile de trouver de nombreuses démonstrations développées par diffé-
rents organismes de recherche sur Internet. Citons par exemple l’Université de Stanford qui propose une
démonstration en ligne à l’adresse suivante : (http://nlp.stanford.edu:8080/ner/).
Objectifs/Principe
Le principe est de repérer et mettre en avant les entités nommées, c’est-à-dire les noms de personnes, les
noms d’organisations, de marques, les expressions temporelles, les noms de lieux, etc. Ceci doit être fait
sans modifier le texte pour que la sortie puisse être utilisée dans n’importe quel langage (HTML, Java,
Python, etc.).
On utilise les mêmes technologies que pour l’Anonymiseur et le Désanonymiseur, excepté Redis dont
nous n’avons pas besoin ici. Par contre, on utilise des requêtes SPARQL pour communiquer avec la base
de connaissance DBpedia.
Solution proposée
L’appel au webservice se fait de l’exacte même manière que pour l’Anonymiseur (voir code 4.1). Seule la
clé d’API change.
Et tout comme l’Anonymiseur, le texte est parcouru pour repérer les entités nommées et restituer le même
texte que celui fournit en entrée (rappelons que l’analyse linguistique peut modifier les mots lors du dé-
coupage en tokens). La différence entre ces deux services réside dans le traitement des entités nommées
reconnues. En effet, ici, plutôt que de les remplacer par une balise, on va plutôt renseigner ses informations
(type, valeur, indice de début, indice de fin et URI DBpedia).
19
Figure 4.4 – Highlighter – Diagramme de classe
La classe principale est Hiдhliдhter dont la fonction hiдhliдht(Strinд, JSONObject) : JSONObject est
appelée par HiдhliдhterController (voir diagramme de classe, figure 4.4). C’est là où le parcours du texte
est effectué après avoir récupéré les différents token et géré la normalisation si nécessaire.
Une fois le parcours terminé, on construit le JSON de sortie à partir des informations enregistrées dans la
classe JsonHiдhliдhter . Un exemple de JSON en sortie du Highlighter est présenté figure 4.5.
1 {
2 " o r i g i n a l T e x t " : " I l f a u t que J e a n e n v o i e n o t r e d o s s i e r d ’ i n s c r i p t i o n à M a r i e
pour l e s e m i n a i r e TAL . En c a s de p r o b l e m e pour l ’ i n s c r i p t i o n , M a r i e d o i t
c o n t a c t e r Mme V e i l au 06 12 34 56 7 8 . " ,
4 " fusion −tags " : true ,
5 " language − d e t e c t i o n " : f a l s e ,
7 " cleaner " : false ,
8 " entities " : {
9 " r e wa rd " : t r u e ,
10 " product " : true ,
11 " method " : t r u e ,
12 ...
13 },
15 " o r i g i n a l T e x t " : true ,
16 " parameters " : true ,
17 " valuesTypesFound " : true ,
18 " globalTypesCount " : true ,
19 " detailedTypesCount " : true ,
20 " entityTypes " : true
21 }
22 },
23 ...
24 }
20
Listing 4.5 – JSON en sortie du highlighter - partie 1
Le champs ”oriдinalT ext” contient le texte de départ, tandis que le champs ”parameters” contient les para-
mètres passés dans la requête. On remarque que, comme pour l’Anonymiseur, les fonctionnalités utilisées
par le Linguistic Analyzer sont paramétrables tout comme les types d’entités nommées à extraire ainsi que
la présence d’une partie des champs du JSON de sortie.
En ce qui concerne les autres champs de ce JSON de sortie, ils sont données au listing 4.6
1 {
2 ...
3 " globalTypesCount " : {
4 " Event " : 1 ,
5 " PhoneNumber " : 1 ,
6 " Person " : 4
7 },
8 " detailedTypesCount " : {
9 " Event " : 1 ,
10 " PhoneNumber " : 1 ,
11 " Person " : 4
12 },
13 " valuesTypesFound " : {
14 " E v e n t " : { " TAL " : 1 } ,
15 " PhoneNumber " : {
16 " 06 12 34 56 7 8 . " : 1
17 },
18 " Person " : {
19 " Marie " : 2 ,
20 "Mme V e i l " : 1 ,
21 " Jean " : 1
22 }
23 },
24 " entities " : [
25 {
26 " en t i ty T y pe " : " nerd : Person " ,
27 " wiki " : " " ,
28 " value " : " Jean " ,
29 " indexEnd " : 15 ,
30 " indexStart " : 12 ,
31 " depiction " : " "
32 },
33 {
34 " en t i ty T y pe " : " nerd : Event " ,
35 " wiki " : " " ,
36 " v a l u e " : " TAL " ,
37 " indexEnd " : 97 ,
38 " indexStart " : 95 ,
39 " depiction " : " "
40 },
41 ...
42 ],
43 " entityTypes " : [
44 " Event " ,
45 " PhoneNumber " ,
46 " Person "
47 ]
48 }
Listing 4.6 – JSON en sortie du highlighter - partie 2
21
”дlobalTypesCount” et ”detailedTypesCount” énumèrent le nombre d’occurrences de chaque type d’enti-
tés nommées. Leur différence réside dans le fait que ”detailedTypesCount” peut aller plus dans les détails.
Par exemple, on aura deux champs différents ”T ime > Month” et ”T ime > Day” pour "les jeudis en
août" tandis que dans ”дlobalTypesCount” ils seront regroupés sous l’étiquette ”T ime”. Quant au champ
”valuesTypesFound” il renseigne combien de fois, en fonction du type d’entité, apparaît une certaine en-
tité. Ce n’est pas pareil que compter le nombre d’apparition d’une entité. En effet, prenons comme exemple
"David Beckham" : M. Beckham est une personne, mais David Beckham est aussi une marque. On peut donc
avoir plusieurs fois la même entité dans un texte mais avec des types sémantiques différents. Ensuite, nous
avons le JSON Array ”entities” qui est le plus important dans le JSON puisqu’il indique quelles sont les
entités nommées qui ont été reconnues ainsi que toutes les informations spécifiques à celles-ci : sa valeur
(le(s) mot(s) qui compose(nt) l’entité) ; son type ; ses indices de départ et de fin dans le texte (permettant
de retrouver et mettre en valeur l’entité) ; un lien vers l’abstract et la photo Wikipedia correspondant à
l’entité, obtenus grâce à la base de connaissance DBpedia. Enfin, il est possible d’avoir une simple énu-
mération des types présents dans le texte, sans plus d’informations dessus contrairement aux champs
”дlobalTypesCount”, ”detailedTypesCount” ainsi que ”valuesTypesFound”.
En ce qui concerne la manière de mettre en valeur les entités nommées, le choix revient au client qui peut
le faire grâce aux résultats décrits précédemment. Un exemple, réalisé en HTML, est de les surligner (cf
figure 4.5).
Figure 4.5 – Highlighter – Exemple de mise en valeur d’entités nommées
Les tests ont été similaires à ceux effectués pour l’anonymisation puisque les deux services sont très
proches l’un de l’autre en terme d’algorithme, bien qu’opposés dans l’affichage du résultat.
Bilan
Comme pour l’Anonymiseur, les entités nommées sont correctement repérées et renseignées dans le JSON
de sortie. Et en ce qui concerne la justesse des résultats, cela dépend de l’analyse linguistique.
4.1.4 Mots clés
Ce service fait partie du domaine de l’identification de thèmes dans un texte.
Quand on essaye de comprendre un texte, un exercice qui revient régulièrement est l’extraction de mots
clés. Mais avant d’avoir l’ambition de les extraire, il s’agirait de définir cette notion de mot clé. Une première
définition, générale, pourrait être :
“Mot ayant un sens plus important que les autres dans une phrase. ” – linternaute.fr
Dans notre cadre, on considérera le texte tout entier plutôt qu’une phrase seulement. De plus, remarquons
que deux notions apparaissent dans cette définition : tout d’abord c’est un mot qui se trouve dans le texte, et
ensuite il doit y être important. Cependant, cette dernière notion d’importance n’est pas objective. Suivant
la méthode utilisée un même mot ne se verra pas attribuer la même "note d’importance".
22
Une des méthodes les plus populaires est celle du TF-IDF (Term Frequency - Inverse Document Frequency).
Elle consiste à calculer, pour chaque mot du texte, une note en deux étapes. La première étape est un simple
comptage du nombre d’occurrence de chaque mot dans le texte, c’est le TF. Puis, on divise ce premier
décompte par la fréquence respective de chaque mot dans un corpus important (IDF) afin de réduire la
note des mots les plus communs (tels que les déterminants, les verbes être et avoir, etc.) et augmenter celle
de ceux qui sont plus rares, et donc qu’on considère comme plus représentatifs du texte.
Objectifs/Principe
L’objectif est d’extraire des mots représentatifs du texte, permettant d’en comprendre son contenu général
sans le besoin de le lire en entier. La méthode choisie est le TF-IDF, et le corpus permettant de calculer l’IDF
est le dataset du projet Google Books. Google Books est un projet de Google qui consiste à numériser une
très grande quantité de livres, de tokeniser leurs contenus par mot, et compter leurs nombres d’occurrences
selon les années. En plus de considérer les mots simples, les N-grams sont également comptés (un N-gram
est une séquence de N mots consécutifs). La base de données de Google Books est constituée de fichiers
qui regroupent des N-grams d’un même grammage, et commençant par les mêmes lettres. Il y a donc une
quarantaine de fichiers pour les 1-gram (à cause des caractères spéciaux et chiffres), et environ 600 fichiers
pour les N-grams avec N > 1 (ces N-grams sont classés en fonction des deux premières lettres de leur
premier mot). Il nous est alors possible d’extraire des N-grams clés plutôt que de ne se contenter que de
mots simples après avoir récupéré ces données.
Il faudra être capable de sélectionner les mots par rapport à leur catégorie grammaticale (noms communs,
noms propres, verbes, déterminants, etc.).
On garde le même environnement de travail et on utilise toujours les mêmes technologies pour gérer les
échanges HTTP.
Comme dit précédemment, le calcul de l’IDF est réalisé grâce au dataset du projet Google Books qu’on a
extrait et filtré par rapport à nos besoins.
Solution proposée
Comme dit ci-dessus, les données du projet Google Books sont fragmentées en plusieurs fichiers selon le
nombre de grams des locutions, et selon les premières lettres de ces locutions. Ce format de fragmentation,
qui peut être assimilé à une hash map et permet ainsi de chercher les mots dans des volumes de données
bien réduits, est conservé. Aussi, pour chaque mot, Google Books fournit son nombre d’occurrences par
année, ce qui induit un volume important et superflu de données par rapport à ce dont on a besoin. Un
premier filtre est donc réalisé sur l’année pour ne conserver que les mots de la dernière année complète
disponible dans la base : 2008. On ne conserve et ne considère que les 1-grams et 2-grams car pour N > 3
les phrases données par l’analyse sont actuellement peu pertinentes, et l’extraction des données de la base
de Google Books prend énormément de temps.
Ensuite, il y a de nombreuses redondances de mots à cause des majuscules ou bien du type qui a parfois
été ajouté à la fin du mot, comme par exemple : "redondance", "Redondance", "redondance_NOUN", "Re-
dondance_NOUN". Les mots qui contiennent le caractère "_" sont donc supprimés, et les mots composés
des mêmes lettres mais avec une casse différente sont réunis.
Enfin, le dernier filtre se fait sur les déterminants et conjonctions de coordination qui peuvent être le
premier mot d’un 2-gram. En effet, ces données ne sont pas pertinentes pour nous, puisqu’on cherche à
23
extraire des mots clés, ou expressions clés.
Le paramétrage à l’appel du service est le suivant :

1 {
2 " t e x t " : " J ’ a i m e r a i s s a v o i r q u e l s s o n t l e s mots c l e s que t u t r o u v e s i c i . " ,
4 " pos " : {
5 " ADJ " : 1 2 ,
6 "NC" : 2 0 ,
7 ...
8 },
9 " max−gram " : 2
10 }
11 }
Listing 4.7 – JSON en entrée du service de génération de mots clés
Le champs ”pos” correspond aux Part Of Speech ou catégories grammaticales des mots. La liste complète
se trouve ici : http://www.lattice.cnrs.fr/sites/itellier/SEM.html. Pour chaque
catégorie, le nombre maximum de mots clés désirés en réponse est indiqué.
Contrairement aux services précédents, le texte n’est pas parcouru caractère par caractère. On va plutôt
directement utiliser les tokens renvoyés par le LinдuisticAnalyzer . Le déroulé de l’algorithme peut être
décomposé en trois étapes :
1. On enregistre et compte le nombre d’occurrences de chaque mot (= token) dont la catégorie gram-
maticale fait partie de celles demandées.
2. L’opération est réitérée avec les N-grams, pour N inférieur ou égal à max − дram. Ceci est possible
en considérant toutes les shortPhrase des tokens.
3. Pour tous les mots et locutions enregistrés, leurs fréquences sont recherchées dans la base de don-
nées extraite de celle de Google Books, et sont utilisées pour calculer les notes finales des N-grams.
Si elles ne sont pas trouvées dans la base, on utilise une valeur par défaut qui est la moyenne des
notes pour les N-grams composés du même nombre de mots.
Tout ceci se passe dans la classe TfIdf. Tout comme la création des ressources de données extraites du
dataset de Google Books, comme on peut le voir sur le diagramme de classe (figure 4.6).
Figure 4.6 – Mots clés – Diagramme de classe
Une fois toutes les notes attribuées, elles sont triées puis le JSON de sortie est construit dans la classe
JsonTfIdf en fonction du nombre de mots clés maximum renseigné pour chaque catégorie grammaticale
24
demandée. Ce dernier est semblable à celui montré ci-dessous. Les résultats sont stockés dans le champs
”keywords”, et répartis selon leur grammage puis leur catégorie grammaticale.
1 {
2 " o r i g i n a l " : " J ’ a i m e r a i s s a v o i r q u e l s s o n t l e s mots c l e s que t u t r o u v e s i c i
." ,
4 ...
5 },
6 " keywords " : {
7 " 1−gram " : {
8 "NC" : {
9 " cle " : 0 . 09027924231109405 ,
10 " mot " : 0 . 0 8 2 0 3 2 3 0 6 3 6 0 4 9 3 8 8
11 }
12 },
13 " 2−gram " : {
14 "NC" : {
15 " mots c l e s " : 0 . 1 5 1 8 9 8 4 9 8 4 3 5 4 3
16 }
17 }
18 }
19 }
Listing 4.8 – JSON en sortie du service Mots clés
La qualité du résultat de l’algorithme repose sur la complétude des données récupérées du projet Google
Books. 10 articles Wikipedia ont été récupérés aléatoirement et on a testé la présence des mots dans notre
base de données. Voici les résultats :
— Adjectifs : 98,84% (255 sur 258) ;

— Adverbes : 98,80% (82 sur 83) ;
— Déterminants : 100% (31 sur 31) ;
— Noms communs : 99,46% (742 sur 746) ;
— Noms propres : 90,55% (460 sur 508) ;
— Pronoms : 100% (27 sur 27) ;
— Verbes : 100% (198 sur 198)
— 2-gram Noms communs : 88,28% (211 sur 239).
Les résultats sont très satisfaisants. Le minimum est pour les noms communs 2-grams, mais avec 88% ce qui
est assez remarquable étant donné le nombre de combinaisons possibles. Pour ceux non trouvés, on attribue
la note IDF par défaut qui permet de ne pas donner une trop bonne note aux mots mal orthographiés, mais
laisse une chance aux mots avec une forte occurrence pour se positionner vers la tête de liste des mots
clés.
Bilan
Les résultats obtenus sont pertinents dans la plupart des cas et permettent de connaître les sujets principaux
du texte sans avoir besoin de le lire entièrement. Le paramétrage du service le rend également adaptable à
divers besoins. On remarque empiriquement que la pertinence des résultats semble dépendre de la longueur
du texte : plus il sera long, meilleurs seront les résultats obtenus.
25
4.1.5 Concepts
Tout comme pour les mots clés, les concepts concernent l’identification de thèmes dans un texte.
Pour identifier le sujet d’un texte, on a en général recours aux mots clés, comme vu précédemment. Ce-
pendant, il est possible d’aller plus loin en essayant d’extraire les concepts qui sont plus généraux et qui
peuvent ne pas apparaître directement dans le texte.
La difficulté vient justement du fait qu’ils peuvent ne pas être présents dans le texte, ou bien un nombre
réduit de fois. Par exemple dans un document où les mots "armée", "arme", "guerre", "combat" font référence
au domaine militaire en général, bien que ce mot puisse ne pas être écrit explicitement ou peu. Il faut donc
être capable de comprendre le sens des mots, ce qu’ils représentent.
Objectifs/Principe
L’objectif est d’extraire les concepts d’un texte. Pour ce faire, la ressource Jeux de Mots (JDM) est utilisée.
En faisant appel à JDM, avec l’option d’enrichissement lexical, l’analyse linguistique fournit les synonymes,
holonymes et domaines de chaque mot. Il devient donc possible de compter le nombre d’occurrences de
tous ces mots et de les classer selon leur pertinence calculée.
L’environnement, le langage utilisé et la technologie pour gérer les requêtes HTTP restent les mêmes que
pour les web services précédents. Cependant ici on ne fait appel ni à Redis ni aux données de Google
Books.
L’analyseur linguistique fait appel à la ressource JDM qui est stockée dans MongoDB.
Solution proposée
Tout comme pour les mots clés, il n’y a de parcours du texte caractère par caractère, mais directement
une utilisation les tokens présents dans le JSON renvoyé par l’analyse linguistique. Cependant cette fois-ci
seuls les noms communs sont considérés, qu’ils soient 1-gram ou N-grams avec N > 1. Pour obtenir les N-
grams avec N > 1 on utilise les shortPhrase des tokens, et pour leur attribuer une catégorie grammaticale
c’est celui de son token principal qui est retenu.
L’algorithme peut se décomposer en quatre étapes :
1. Comptage des occurrences de chaque nom commun.

2. Comptage des occurences de chaque N-gram étiqueté nom commun, avec N>1.
3. Ajout des synonymes aux locutions jusqu’à présent obtenues grâce à la resource JDM.
4. On récupère les holonymes et les domaines des locutions récupérées jusqu’à présent, toujours grâce
à JDM, et on les y ajoute.
Une fois ces étapes terminées, on obtient une liste de N-grams avec comme score attribué leur nombre
d’occurrence + leur nombre de fois où ils apparaissent comme synonyme + le nombre de fois où ils ap-
paraissent comme holonyme + le nombre de fois où ils apparaissent comme domaine. On a stocké ces
résultats dans les classes NC et NCs (voir figure 4.7). Le JSON de sortie est alors construit dans la classe
JsonConcepts.
26
Figure 4.7 – Concepts – Diagramme de classe
Un exemple de réponse est donné en figure 4.9, illustrant la manière dont la liste de concepts est retournée :
elle se trouve dans le champs ”concepts” sous la forme d’une énumération (non triée).
1 {
2 " o r i g i n a l " : " L ’ armee e n v o i e d e s s o l d a t s pour l a d e f e n s e d e s c i t o y e n s . " ,
3 " parameters " : { } ,
4 " concepts " : {
5 " militaire " : 4 ,
6 " defense " : 3 ,
7 " armee " : 4 ,
8 ...
9 }
10 }
Listing 4.9 – JSON en sortie du service Concepts
Il n’y a pour le moment pas de paramétrage pour limiter la taille de la liste renvoyée. Aussi, elle est triée
aléatoirement lorsqu’elle est transmise avec Jersey, il faut donc effectuer à nouveau le tri un fois la réponse
reçue.
Comme pour les services précédents, les textes qui ont servi aux tests et à l’évaluation de la solution
proposée sont des extraits d’articles Wikipedia générés aléatoirement.
27
Les résultats ont dû être analysés à la main par une observation du JSON obtenu après analyse du texte
pour les comparer aux relations de chaque nom commun (synonymes, holonymes et domaines).
Bilan
On obtient régulièrement des concepts clés qui n’apparaissent pas dans les mots clés, voire qui n’appa-
raissent pas dans le texte du tout, ce qui est très satisfaisant puisque cela rend ces deux sevices com-
plémentaires. Par contre, on remarque d’autant plus l’impact de la longueur du texte sur la qualité des
résultats. Il faut avoir un texte d’au moins 4-5 phrases pour obtenir des concepts intéressants.
Les résultats obtenus, surtout si couplés aux mots clés, peuvent par exemple servir à indexer des documents,
ou à scanner rapidement des articles dans le but de repérer ceux qui concernent un ou plusieurs thèmes
donnés.
4.1.6 Actions
Ce service se concentre sur l’extraction de tâches ou d’actions dans un texte. Une action est caractérisée
par un verbe à la forme active ou passive, appelé prédicat, et les autres mots qui apportent de l’information
sur le prédicat.
Le produit principal d’Emvista, actuellement en développement, est Prevyo, un assistant de gestion de

e-mails qui effectue l’extraction de tâches à partir du contenu textuel des mails reçus.
Afin de mettre en avant et illustrer cette compétence, ce web service est créé.
Objectifs/Principe
L’objectif est d’extraire des actions à partir d’un texte, en caractérisant ces actions par ses composants : un
prédicat, un agent (et des co-agents), un thème, une temporalité, un lieu, etc. Ces composants sont aussi ap-
pelés rôles thématiques (aller sur https://ipfs.io/ipfs/QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDD
wiki/Thematic_relation.html pour la liste des principaux rôles thématiques).
Grâce au module de reconnaissance d’actions développé par Emvista, on obtient une liste d’actions avec
leurs différents composants. On extrait alors les informations qui nous intéresse, et le lien entre les diffé-
rents composants des différentes actions est effectué.
Le but est de permettre une représentation du texte sous forme de graphe.
Books.
Le module ActionRecognizer développé par Emvista est utilisé pour l’extraction des données.
28
Solution proposée
Cette fois, c’est l’objet ”actions” du JSON renvoyé par l’analyse linguistique et la reconnaissance d’actions
qui va être parcouru. Pour chaque token composant l’action, sa phrase d’origine est recherchée pour avoir
le couple (idToken, idSentence) qui est unique pour chaque token, permettant ainsi d’identifier un mot et
de faire le lien entre deux actions reliées par un mot en commun.
Il est ensuite enregistré dans une ArrayList afin de le traiter à la construction du JSON de sortie (qui est
effectuée dans la même classe que le reste des calculs, voir figure 4.8).
Figure 4.8 – Actions – Diagramme de classe
Les informations conservées des tokens sont les suivantes : idToken, idSentence, sa valeur qui peut être
son lemme ou bien sa shortPhrase ou phrase, sa co-référence, et ses indices de début et fin dans sa phrase.
Ces champs sont indiqués pour chaque rôle non vide de chaque action. Ci-dessous, un exemple de sortie
du service.
1 {
2 " t e x t " : " J e a n a c h e t e du p a i n a M a r i e . " ,
3 " actions " : [
4 {
5 " agent " : {
6 " coref " : [] ,
8 " idToken " : 0 ,
9 " start " : 0 ,
10 " lemma " : " J e a n " ,
11 " end " : 4
12 },
13 " predicate " : {
14 " coref " : [] ,
16 " idToken " : 1 ,
17 " start " : 5 ,
18 " lemma " : " a c h e t e r " ,
19 " end " : 1 1
20 },
21 " beneficiary " : {
22 " coref " : [] ,
24 " idToken " : 5 ,
25 " s t a r t " : 22 ,
26 " lemma " : " M a r i e " ,
27 " end " : 2 7
28 },
29 " theme " : {
30 " coref " : [] ,
32 " idToken " : 3 ,
33 " s t a r t " : 15 ,
34 " lemma " : " p a i n " ,
29
35 " end " : 1 9
36 },
37 " consequence " : { } ,
38 " goal " : { } ,
39 ...
40 " negative " : false ,
41 " id " : 0 ,
42
43 }
44 ]
45 }
Listing 4.10 – JSON en sortie du service Actions
Pour chaque action, l’id est indiqué tout comme l’information qui précise si le verbe est accompagné d’une
négation ou pas.
Concernant ce web service, la plus grosse partie du travail a été consacrée à la représentation graphique
du résultat qui sera montrée et détaillée dans la partie Interface graphique.
Les résultats ont dû être analysés à la main, en observant directement dans le JSON obtenu après analyse
du texte les différents composants des actions reconnues (aдent, recipient, theme, etc.).
Bilan
Le service extrait correctement les actions et filtre les informations pour ne garder que celles intéressantes
pour la représentation graphique. La qualité des résultats dépend du module ActionRecoдnizer qui est en
cours de construction, mais ceux obtenus à présent sont déjà pertinents. Aussi, l’analyseur syntaxique gère
la co-référence mais le service ne l’utilise pas encore. Une fois que cela sera fait, la qualité des résultats en
sera bien augmentée.
Une des applications de ce service est représenté par le produit Prevyo d’Emvista qui extrait des tâches
d’e-mails pour en faciliter le traitement.
4.1.7 Sentiments
Ce dernier service porte sur l’analyse d’opinion.
L’analyse d’opinion ou sentiment est un autre enjeu majeur du Traitement Automatique des Langues (TAL).
Le but ici est de définir l’opinion associée à un texte par rapport à un ou plusieurs sujets.
De façon générale, l’analyse d’opinion porte sur le niveau de la phrase. Emvista cherche à affiner l’analyse
d’opinion en combinant les modules précédemment exposés.
30
Objectifs/Principe
L’analyseur linguistique identifie les sentiments et émotions associées aux différentes actions. Le but ici
est d’extraire les données utiles pour ensuite se concentrer sur la représentation graphique dans le cadre
de démonstrations sur un site Internet, tout comme pour les services précédents.
Books.
Les modules ActionRecognizer et d’analyse d’opinion développés par Emvista sont appelés.
Solution proposée
L’algorithme est très similaire à celui du service Actions. Là où ils diffèrent c’est au niveau de l’extraction
des informations pour chaque action. En effet, ici on se contente d’extraire le prédicat et les agents ainsi
que l’opinion et les émotions associées à l’action.
En ce qui concerne les émotions, il y en a six qui sont considérés comme fondamentales : la joie, la peur, la
tristesse, la colère, le dégoût et la surprise. Une même action pour être associée à plusieurs émotions dif-
férentes. Cette association est actuellement réalisée grâce au lexique FrenchExpandedEmotionLexicon(Feel) [1],
une ressource développée par le Laboratoire d’Informatique, de Robotique et de Microélectronique de
Montpellier (LIRMM).
Avant de passer à l’interface web, regardons le format du JSON de sortie de ce web service :
1 {
2 " t e x t " : " M a r i e a d o r e l e s b i s c u i t s au c h o c o l a t . " ,
3 " sentiments " : [
4 {
5 " idAction " : 0 ,
6 " opinion " : " p o s i t i v e " ,
7 " emotions " : [
8 " fear "
9 ],
10 " agents " : [
11 {
12 " form " : " M a r i e " ,
13 " idT " : 0 ,
14 " idS " : 0
15 }
16 ],
17 " predicate " : {
18 " idT " : 1 ,
19 " lemma " : " a d o r e r " ,
20 " idS " : 0
21 },
22 " negative " : false
23 }
24 ]
25 }
Listing 4.11 – JSON en sortie du service Actions
31
Les sentiments associés aux actions se trouvent dans le JSON Array ”sentiments” où chaque élément est
composé des informations décrites précédemment.
Les résultats ont dû être analysés à la main, en observant directement dans le JSON obtenu après analyse
du texte les opinions et émotions associées aux actions reconnues.
Bilan
Les opinions et émotions associées aux actions sont bien extraites par le service, comme souhaité. La qualité
des résultats dépend ensuite du module d’extraction de sentiment de l’analyseur linguistique qui pour le
moment repose sur le lexique Feel qui est déjà satisfaisant. Comme pour l’extracteur d’actions, l’analyseur
syntaxique gère la co-référence mais le service ne l’utilise pas encore. Une fois que cela se fera fait, la
qualité des résultats en sera bien augmentée.
Enfin, un exemple d’utilisation de ce service pourrait être l’analyse d’une décision politique ou d’un évé-
nement majeur à travers les réactions provoqués sur les réseaux sociaux.
4.2 Interface web
Après avoir décrit les principes et fonctionnements des services développés, il est temps de se concentrer
sur la seconde partie du travail qui concerne leur représentations ainsi que l’interface graphique en général.
4.2.1 Contexte/Objectifs
L’objectif principal des différents web services présentés est de mettre en lumière les briques technolo-
giques développées par Emvista. La première étape était donc d’isoler les informations utiles à chaque
brique pour pouvoir ensuite les représenter graphiquement. Il s’agit donc à présent d’effectuer cette repré-
sentation, de manière à simplifier la compréhension des résultats et attirer l’attention de potentiels clients
ou partenaires.
J’ai été aidé dans cette tâche par un graphiste du groupe qui a conçu le template du site où se trouvent
les démonstrations, après que je lui ai communiqué, sous la forme de mini cahier des charges, les besoins
pour chaque service et quelques idées de design ou du moins d’architecture générale du site.
Enfin, il fallait trouver des représentations bien distinctes les unes des autres.
4.2.2 Technologies utilisées
Le framework Symfony a été choisi pour le langage PHP. Quant au CSS utilisé, il provient principalement
de Bootstrap. La gestion des événements a été fait en JavaScript (dont une partie en jQuery), et j’ai eu
également recours au langage HTML, évidemment. Enfin, pour les représentations des services Actions et
Sentiments, j’ai eu recours à des outils de la bibliothèque d3.js.
32
4.2.3 Résultats sur le site web
Ci-après sont présentés des explications sur le choix des représentations. Les screens se trouvent en Pre-
mière Annexe, auxquels il est conseillé de se référer puisqu’une image est parfois plus explicite qu’un long
discours.
Notons que le service de désanonymisation n’a pas encore été intégrée au site web, et que, à l’heure où est
rédigé ce rapport, le site web n’est pas encore en production mais accessible uniquement en local.
Avant d’aller plus loin, je tiens à préciser que les technologies sur lesquelles sont basés les résultats présentés
sont encore en cours de développement, il est donc possible qu’il y ait quelques erreurs ou imperfections sur
les résultats affichés. Les screens ci-après sont là pour montrer la visualisation des résultats, ce sur quoi j’ai
travaillé, pas les résultats en soi.
Anonymiseur
Pour ce premier service, il a été choisi de laisser un résultat graphique simple, en restituant le texte et en
mettant les balises en gras, illustré figure A.1 en annexe. De plus, le service est paramétrable sur le site.
Vous trouverez la page paramètre de l’anonymiseur à la figure A.2.
Highlighter
Pour le service de reconnaissance d’entités nommées, le but n’est pas de cacher mais au contraire de mon-
trer les entités. Par conséquent, la représentation retenue a été un surlignage léger des entités en couleur en
fonction de leur type. Ce surlignage est foncé au survol de l’entité concernée ou en cliquant sur le bouton
du type correspondant. Ceci permet d’isoler et de mieux visualiser des types d’entité qui nous intéresse
plus. Vous trouverez une illustration à la figure A.3.
Aussi, au niveau des boutons, on trouve le nombre de chaque type d’entité du texte. Lorsqu’une entité
surlignée est cliquée, plusieurs informations sont affichées, comme illustré figure 4.9.
Figure 4.9 – Highlighter – Informations au survol
Il y a tout d’abord le type de l’entité, puis le nombre de fois où elle apparaît dans le texte. Si elle apparaît
plusieurs fois, les autres occurrences sont soulignées en rouge au survol.
De plus, si une entrée qui correspond dans la base de connaissance DBpedia a été trouvée, la photo de
l’article et le début du résumé sont affichés. Et lorsqu’un utilisateur clique sur l’image, la page Wikipedia
associée s’ouvre dans un nouvel onglet. C’est intéressant pour l’étude du langage puisqu’à partir de l’article
Wikipedia, structuré sur DBpedia, il est possible d’identifier de nombreuses autres entités nommées qui
auront peut-être également un lien avec le reste de notre texte. Un graphe de plus en plus complexe peut
alors être construit permettant un enrichissement du texte au niveau sémantique et de désambiguïser
certains termes.
Un exemple d’entité nommées dont une correspondance a été trouvée dans DBpedia est présenté sur la
figure 4.10.
33
Figure 4.10 – Highlighter – Lien avec DBpedia
Mots clés
Pour les mots clés il y a deux informations à afficher : les mots clés eux-mêmes, ainsi que leur note, ou du
moins leur importance les uns par rapport aux autres. En effet, le mot clé avec la meilleure note ne doit
pas être représenté de la même manière que celui avec la moins bonne note.
Comme il s’agit de proportion, nous avons choisi d’utiliser un graphe camembert :
Figure 4.11 – Mots clés – Représentation graphique
Dans l’exemple choisi, un extrait d’article sur le budget de la défense américaine, le mot clé le mieux noté
est budget, on a ensuite armée et milliard.
34
Concepts
Le résultat du service Concepts est proche, dans sa forme, à celui du service Mots clés : c’est une liste de
mots associés à des notes. Afin de varier la visualisation et exprimer par la forme l’esprit plus abstrait des
concepts par rapport aux mots clés, on a décidé de les représenter sous la forme de nuage de mots :
Figure 4.12 – Concepts – Représentation graphique
Dans l’exemple choisi, le même que pour Mots clés, on voit que le concept qui ressort le plus est militaire.
Ensuite, on retrouve budget et armée, qui étaient aussi dans les mots clés. Ceci n’est pas très étonnant
puisque le texte est relativement court.
Actions
Pour le service Actions, l’idée est de représenter le texte sous la forme d’un graphe (connexe, si possible). La
représentation est donc déjà toute choisie. On personnalise le graphe en ajoutant des couleurs sur les liens
et les nœuds qui représentent les composants des actions, en fonction du type de l’entité correspondante.
On ajoute également des légendes sur les liens qui caractérisent une relation entre deux entités, afin de
préciser le type de la relation.
Pour le texte "Jérémy achète du pain tous les matins. Lorsqu’il arrive à la boulangerie, Jérémy s’arrête devant
la porte dans le but de sentir la bonne odeur des viennoiseries que Rémi le boulanger sort du four." on obtient
le graphe suivant :
Figure 4.13 – Actions – Représentation graphique
On remarque que non seulement une même entité peut avoir un rôle dans deux actions différentes (Jérémy
est relié à deux prédicats en tant que agent), mais en plus une certaine hiérarchie des actions est représentée
grâce aux liens directs entre les prédicats. Ici l’action "Sentir" découle de l’action "Arrêter".
35
Sentiments
Pour l’analyse d’opinion, le but est d’être capable d’associer des sentiments à un couple (action, pointdevue)
avec un agent ou un expérienceur comme pointdevue. On a donc choisi de présenter les résultats dans un
tableau avec cinq colonnes :
— Action : c’est l’action concernée par l’opinion.

— Point de vue : c’est l’agent ou l’expérienceur qui ressent les sentiments décrits.
— Sentiment associé à l’action : il peut être soit positif, soit négatif, soit neutre. On les représente
sous la forme d’un pouce en l’air ou vers le bas, ou un signe équal pour la neutralité.
— Emotions associées à l’action : ce sont les six émotions dont nous avons parlé plus haut. On les
représente sous forme de smiley, avec une légende au survol.
— Sentiment général de l’agent : c’est le bilan, sur l’ensemble du texte, de ce que ressent l’agent
ou l’expérienceur de la colonne point de vue. Par exemple s’il est concerné par deux actions où
l’opinion est positive, et une autre où elle est négative, le bilan général sera considéré comme positif.
Pour le texte "Christine déteste la pluie depuis toute petite. Elle possède une quinzaine de parapluies de toutes
les couleurs et Robert lui achète régulièrement de nouvelles bottes. Robert est son mari. Christine et Robert
s’aiment profondément depuis leur adolescence, lorsqu’ils se sont rencontrés au collège. Et de cet amour est né
le petit Kilian qui adore sauter dans les flaques ! Christine a décidé de quitter la Bretagne avec sa famille pour
s’installer à Montpellier." on obtient le tableau suivant :
Figure 4.14 – Sentiments – Représentation graphique
Fonctionnalités générales
Plusieurs fonctionnalités générales ont été implémentées de manière à améliorer l’expérience de l’utilisa-
teur. Il y a par exemple la possibilité de télécharger les JSON des résultats, ou bien de télécharger/copier
les textes des services Anonymiseur et Highlighter, ou bien encore une image au format PNG des résultats
des autres services.
Démonstration générale
Enfin, l’utilisateur a la possibilité d’effectuer une démonstration avec plusieurs web services à la fois si-
multanément. Cela permet d’avoir un aperçu global des résultats obtenus à partir d’un même texte. Cette
démonstration se trouve sur la page d’accueil où il trouvera aussi une description rapide de chaque service,
qui correspond à une brique technologique.
36
Cette démonstration générale appelle en fait un autre web service que nous n’avons pas décrit précédem-
ment. Celui-ci effectue simplement un appel à chaque service demandé, et concatène les différents résultats
obtenus avant de les renvoyer à son tour. Il est possible de sélectionner autant de web services que désiré.
Pour cette démonstration, l’utilisateur doit tout d’abord rentrer son texte et sélectionner les services qu’il
souhaite utiliser (voir figure A.4 en Annexe). Ensuite il est redirigé vers une nouvelle page où les résultats
sont affichés (voir figure A.5 en Annexe).
4.2.4 Documentation des APIs
Le dernier travail réalisé au cours de ce stage est la rédaction des documentations pour chaque service. Au
moment où ce rapport est rédigé ce n’est d’ailleurs pas terminé, puisqu’il me reste encore du temps avant
la fin du stage.
Ci-dessous, à la figure 4.15, est présenté un exemple de page de la documentation afin d’avoir un visuel que
j’ai réalisé moi-même avec le framework BootStrap. En ce qui concerne le contenu, c’est une description
pour chaque API du principe général du service, des ressources à utiliser, de la construction de la requête
et de la composition de la réponse.
Figure 4.15 – Documentation des services – Exemple de page
Une fois qu’elle sera complètement rédigée, la documentation sera intégrée au site où se trouvent les
différentes démonstrations. Cependant, il est possible qu’elle soit modifiée d’ici la phase de production.
37
38
5 Bilan du stage
Après avoir présenté l’entreprise, le contexte et les objectifs du stage ainsi que les solutions proposées et
les résultats obtenus, il s’agit à présent de prendre un peu de hauteur sur tout cela afin d’en faire un bilan.
5.1 Résultats obtenus et impacts des solutions
Le sujet initial était de concevoir un anonymiseur de texte et implémenter une représentation graphique
dans le but de réaliser des démonstrations. Cet objectif a été rempli, et complété par le développement du
back-office et du front-office de cinq autres web services, en plus de la solution de désanonymisation.
Aussi, j’ai pu travailler en collaboration avec un graphiste du groupe et être force de propositions que ce
soit pour le design général du site des démonstrations ou pour les choix de représentations graphiques des
résultats renvoyés par les web services.
Les solutions proposées vont permettre à Emvista de valoriser ses briques technologiques via un support
visuel interactif. Les résultats obtenus dépassent donc les attentes du sujet initial et offrent des perspectives
nouvelles à Emvista, avec notamment un autre stage qui assurera la poursuite et l’amélioration du travail
effectué.
Ceci a été possible grâce à l’encadrement et l’accompagnement de grande qualité de l’ensemble de l’équipe
Emvista : Philippe Garnier, Jean Bort, Cédric Lopez et Melissa Mekaoui.
5.2 Difficultés rencontrées
Les premières difficultés rencontrées ont été de s’approprier les outils déjà développés par l’équipe d’Em-
vista et que j’ai dû utiliser, et évidemment de comprendre en quoi consiste vraiment l’étude du langage
naturel et quels en sont les enjeux majeurs. Ce sujet est un domaine très vaste de l’informatique, et de
l’intelligence artificielle, et ce depuis plusieurs décennies. Je n’ai bien évidemment pas pu acquérir des
connaissances et compétences pointues dessus, mais grâce à de nombreuses recherches et les précieuses
explications de mon encadrant de stage, Cédric Lopez, j’ai pu au moins en cerner les concepts principaux.
Ensuite, j’ai dû prendre en main et utiliser de nouvelles technologies telles que le framework Sym f ony
ou Jersey. Ces difficultés ont vite été dépassées grâce à l’aide de Melissa Mekaoui qui s’est montrée très
pédagogue et patiente.
Enfin, les autres difficultés majeures auxquelles j’ai dû faire face concernent l’interface graphique où j’ai
utilisé des outils CSS et JavaScript que je ne connaissais pas et dont la documentation n’était pas toujours
très complète contrairement aux outils eux-mêmes. Je pense notamment à l’excellente bibliothèque d3.js.
Mais des recherches poussées sur des sites d’échange comme StackOverFlow ou GitHub m’ont permis de
réaliser ce que je souhaitais faire.
39
5.3 Développements futurs des solutions
La poursuite du travail peut être divisée en deux : la première partie consistera à améliorer les web services
eux-mêmes, donc le code Java ; la seconde portera sur les représentations graphiques.
Tout d’abord, concernant les web services, la prochaine grande étape va être d’intégrer les services d’au-
thentification et de demande d’autorisation qui sont en cours de développement. En effet, actuellement,
une simple comparaison avec une clé API par défaut a été implémentée pour l’utilisation du service. Il
faudra également passer les services sur Docker afin de faciliter leur transmission pendant la phase de
développement.
Puis, pour les représentations graphiques, il y a plusieurs pistes sur lesquelles il est possible de se pencher :
— Ajout d’un filtre pour le graphique des mots clés permettant de n’afficher que les noms communs,
verbes, adjectifs, etc. Ceci a déjà été implémenté mais il reste à l’intégrer au site.
— Enregistrer les résultats de la démonstration générale dans une base de données et qu’ils soient
accessibles grâce à l’ID de session. En effet, pour le moment les résultats sont passés via les cookies,
ce qui limite la taille du texte en entrée pour le texte de la démonstration générale.
— Optimisation de l’affichage de certains résultats et/ou fonctionnalités (notamment pour Concepts,
Mots clés et Actions).
— Intégrer au site le système de Drag&Drop pour le texte. Cette fonctionnalité a déjà été implémen-
tée, mais il faut l’adapter au design final réalisé par un des graphistes du groupe.
En ce qui concerne la pertinence des résultats affichés, cela dépend de l’analyse du texte qui est préalable
aux solutions développées dans le cadre de ce stage. Le LinдuisticAnalyzer et l’ActionRecoдnizer sont
améliorés chaque jour par l’équipe de recherche et développement d’Emvista, en effet ils représentent le
cœur du travail de l’entreprise.
5.4 Devenir des produits développés
Les produits développés vont permettre, et permettent déjà, de réaliser des démonstrations afin de proposer
une visualisation du travail effectué par l’équipe d’Emvista. Ces démonstrations ont principalement lieu
avec des chercheurs (de l’INRIA, du LIRMM, ...) qui peuvent être intéressés par une collaboration avec
l’entreprise dans le cadre de leurs recherches, avec de futurs potentiels partenaires ou clients, ou même
avec des députés du parlement européen qui visiteront l’entreprise mi-septembre.
Enfin, il est possible qu’une fois la phase de production lancée, les web services deviennent des produits à
par entière et soient proposés à la clientèle d’Emvista indépendamment de l’assistant de gestion d’e-mails
qui est au centre du projet de l’entreprise.
40
6 Conclusion
Au cours de ce stage six web services ont été conçus : l’Anonymiseur (avec la solution de désanonymi-
sation), la reconnaissance d’entités nommées, l’extraction de mots clés et de concepts, la reconnaissance
d’actions et enfin l’analyse d’opinion ou sentiment. Chacun de ces web services a été intégré au site web
d’Emvista où on trouve des démonstrations avec visualisation des résultats.
Chacun de ces services répond à des problématiques du Traitement Automatique de Langage, et, basés sur
les technologies développées par Emvista, ils illustrent l’expertise et le savoir-faire de l’entreprise.
Ce stage a été une expérience très riche car il m’a permis de découvrir le Traitement Automatique du Lan-
gage, un domaine de l’informatique qui m’était complètement inconnu, ses enjeux et toutes les possibilités
qu’il offre. A travers le développement des web services et surtout la réflexion sur les représentations gra-
phiques des résultats, j’ai pu découvrir de nouvelles technologies, et les travaux de nombreux chercheurs.
Je suis également très fier d’avoir participé activement à la phase de recherche et développement de la
toute jeune entreprise qu’est Emvista dont je ne doute pas un seul instant de la réussite future. J’espère, et
je pense, avoir su apporter ma pierre à l’édifice en développant ces solutions de visualisation des résultats
des différentes briques technologiques d’Emvista. Ces derniers vont permettre à l’équipe de l’entreprise de
réaliser des démonstrations au cours de leurs présentations, et peut-être de les proposer directement à des
clients en tant que produits.
41
42
Bibliographie / Webographie
[1] Amine Abdaoui. Feel : French expanded emotion lexicon. 31

[2] Michel Charolles. La référence et les expressions référentielles en français. Ophrys, 2002. 12
[3] Groupe de travail «Articles 29» sur la protection des données. Avis 05/2014 sur les techniques d’anony-
misation. CNIL, 2014. 12
[4] evariste.org. Ingéniérie linguistique. 1
[5] Charlotte Galichet. Données personnelles : anonymisation ou pseudoanonymisation ? village-justice.com,
2017. 12
[6] Max Jakob Anja Jentzsch Dimitris Kontokostas Pablo N. Mendes Sebastian Hellmann Mohamed Mor-
sey Patrick van Kleef Sören Auer Christian Bizer Jens Lehmann, Robert Isele. Dbpedia – a large-scale,
multilingual knowledge base extracted from wikipedia. 9
[7] David G. Myers. Psychology, Seventh Edition, in Modules, chapter « Theories of Emotion. ». Worth
Publishers, 2004. 10
[8] societe.com. Emvista. 3
43
44
Liste des illustrations
4.1 Anonymiser – Structure d’une balise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2 Anonymiser – Opérations préalables à l’anonymisation du texte . . . . . . . . . . . . . . . 14
4.3 Anonymiseur – Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.4 Highlighter – Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.5 Highlighter – Exemple de mise en valeur d’entités nommées . . . . . . . . . . . . . . . . . 22
4.6 Mots clés – Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.7 Concepts – Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.8 Actions – Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.9 Highlighter – Informations au survol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.10 Highlighter – Lien avec DBpedia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.11 Mots clés – Représentation graphique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.12 Concepts – Représentation graphique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.13 Actions – Représentation graphique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.14 Sentiments – Représentation graphique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.15 Documentation des services – Exemple de page . . . . . . . . . . . . . . . . . . . . . . . . 37
A.1 Anonymiseur – Interface graphique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
A.2 Anonymiseur – Paramètres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
A.3 Highlighter – Interface graphique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
A.4 Démonstration générale – Sélection des services . . . . . . . . . . . . . . . . . . . . . . . . 54
A.5 Démonstration générale – Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
45
46
Listings
3.1 Exemple d’appel au Linguistic Analyser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Exemple d’appel au module de reconnaissance d’actions . . . . . . . . . . . . . . . . . . . 8
3.3 Structure du JSON obtenu à partir de l’analyse linguistique . . . . . . . . . . . . . . . . . . 9
4.1 JSON en entrée de l’anonymiseur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2 JSON en sortie de l’anonymiseur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3 JSON en entrée du désanonymiseur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.4 JSON en sortie du désanonymiseur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.5 JSON en sortie du highlighter - partie 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.6 JSON en sortie du highlighter - partie 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.7 JSON en entrée du service de génération de mots clés . . . . . . . . . . . . . . . . . . . . . 24
4.8 JSON en sortie du service Mots clés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.9 JSON en sortie du service Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.10 JSON en sortie du service Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.11 JSON en sortie du service Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
47
48
Annexes
49
50
A Première Annexe
A.1 Anonymiseur
Figure A.1 – Anonymiseur – Interface graphique
51
Figure A.2 – Anonymiseur – Paramètres
52
A.2 Highlighter ou reconnaissance d’entités nommées
Figure A.3 – Highlighter – Interface graphique
53
A.3 Démonstration générale
Figure A.4 – Démonstration générale – Sélection des services
Figure A.5 – Démonstration générale – Résultats
54
Résumé
Le Traitement Automatique du Langage est le domaine d’expertise d’Emvista qui, à travers une analyse
syntaxique et sémantique, traite le langage naturel. L’entreprise conçoit plusieurs briques technologiques
qui reposent sur des connaissances linguistiques et ontologiques fines.
Les missions principales de ce stage sont de développer des services web qui font appel aux briques tech-
nologiques d’Emvista, dont une solution d’anonymisation automatique de textes, et de concevoir une in-
terface graphique où des démonstrations de ces services pourront être réalisées.
Ce rapport décrit les services réalisés au cours du stage et leurs enjeux, ainsi que la visualisation de leurs
résultats dans les démonstrateurs. Ils sont au nombre de six : un anonymiseur (accompagné d’une solu-
tion de désanonymisation), un outil de reconnaissance et de mise en valeur d’entité nommées, un service
d’extraction de mot clés et un autre de concepts, un outil de reconnaissance d’actions et enfin une solution
d’analyse d’opinion.
Mots-clés : Services web, Traitement Automatique du Langage, Visualisation.
Abstract
Natural language processing is Emvista’s area of expertise. The company processes natural language
through syntactical and semantic analysis and uses Artificial intelligence technologies based on fine grai-
ned linguistic and ontological knowledge.
The main tasks of this internship are to develop web services that use the technological bricks made by
Emvista, including an automatic text anonymisation solution, and to design a graphical interface where
demonstrations of these services can be realized.
This report describes the services developed during the internship and their challenges, as well as the
visualization of their results in the demonstrations. There are six of them : two named entity recognition
tools for highlighting and anonymisation, keyword and concept extraction services, an action recognition
tool and finally an opinion analysis solution.
Keywords : Web Services, Natural Language Processing, Visualization.

Langue

Bienvenue sur Scribd !

Rapport de Stage

Transféré par

Informations du document

Description :

Date du transfert

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Description :

Droits d'auteur :

Formats disponibles

Rapport de Stage

Transféré par

Description :

Droits d'auteur :

Formats disponibles

Titres liés

Rapport de stage

Services web et interface graphique pour des

Stage de deuxième année réalisé dans l’entreprise Emvista

Maître de stage : Cédric Lopez

Encadrant universitaire : Gérald Oster

Nom, prénom : Monchicourt, Baptiste

Élève-ingénieur régulièrement inscrit en 2e année à TELECOM Nancy

Numéro de carte de l’étudiant : 31622091

Année universitaire : 2017–2018

Auteur du document, mémoire, rapport ou code informatique intitulé :

Développement de Services web et interface graphique pour des

Fait à Montpellier, le 27 août 2018

Stage de deuxième année réalisé dans l’entreprise Emvista

Maître de stage : Cédric Lopez

Encadrant universitaire : Gérald Oster

Table des matières vii

Liste des illustrations 45

Le Traitement Automatique du Langage (TAL) est un domaine regroupant linguistique, informa-

2.1 Informations générales

— le développement et la commercialisation d’agents virtuels intelligents ;

Emvista a pour origine un projet né au sein de la société Penbase. Le directeur technique et le

Emvista est donc un éditeur de services logiciels, spécialiste de la compréhension du langage

Prevyo est le produit phare de l’entreprise.

2.3.2 Prevyo Semantic Services (PSS)

— anonymisation réversible (pseudonymisation) pour anonymiser des données textuelles

3.1 Problématique du stage

3.1.1 Contexte du stage

L’objectif du stage était initialement de concevoir un système d’anonymisation de texte et une

3.1.2 Analyse du problème

3.2.1 Linguistic Analyzer

L’appel à l’analyseur se fait de la manière suivante :

Listing 3.1 – Exemple d’appel au Linguistic Analyser

Listing 3.2 – Exemple d’appel au module de reconnaissance d’actions

Listing 3.3 – Structure du JSON obtenu à partir de l’analyse linguistique

Le module de reconnaissance d’actions enregistre le résultat de son analyse dans le champs

3.2.2 Jeux De Mots

3.2.3 Authentification et API Key

Actuellement, il y a une API key unique propre à chaque web service.

3.3 Gestion de projet

4.1 Web Services

— L’individualisation : est-il possible d’isoler un individu ?

Figure 4.1 – Anonymiser – Structure d’une balise

Listing 4.1 – JSON en entrée de l’anonymiseur

— ”normalization” : active la normalisation du texte, permettant d’analyser une partie du langage

— ”reversible” : active la réversibilité du processus, qui devient alors de la pseudoanonymisation.

— l’utilisation du cleaner si demandé par l’utilisateur ;

Figure 4.2 – Anonymiser – Opérations préalables à l’anonymisation du texte

Ci-dessous le diagramme de classe de l’Anonymiseur. La classe principale est Anonymiser et la méthode

Figure 4.3 – Anonymiseur – Diagramme de classe

Listing 4.2 – JSON en sortie de l’anonymiseur

— ”taдsU sed” : compte le nombre de chaque type de tag utilisé.

— ”wordsAndT aдs” : est composé de quatre champs :

Les résultats dépendent ensuite de l’analyseur qui est en cours de construction.

Listing 4.3 – JSON en entrée du désanonymiseur

Listing 4.4 – JSON en sortie du désanonymiseur

4.1.3 Highlighter ou reconnaissance d’entités nommées

Listing 4.6 – JSON en sortie du highlighter - partie 2