Analyse des outils morphosyntaxiques 

Analyse des outils textométriques

Après avoir décidé quels étiqueteurs morphosyntaxiques devaient être intégrés à l’outil, il était aussi nécessaire de déterminer quel logiciel de textométrie serait le plus adapté. Les conditions étaient ici plus difficiles à remplir : en effet, il était nécessaire de trouver un logiciel qui puisse accepter les fichiers déjà traités par un des étiqueteurs morphosyntaxiques présentés ci-dessus, et qui puisse fonctionner dans une chaîne de traitement et non seulement de façon indépendante. De plus, il était nécessaire qu’il puisse fonctionner selon les choix techniques qui ont été précédemment indiqués. Pour ce faire, il était aussi nécessaire de constituer une liste, présentée ci-dessous.

Point de départ

Pour établir cette liste, j’ai reçu l’aide de l’équipe d’ELAN une fois de plus, mais je me suis aussi basé sur un article qui m’avait été recommandé.
Cette article, intitulé Sept logiciels de textométrie [Pincemin, 2018] m’a servi de point de départ pour la constitution de cette liste en indiquant un premier échantillon de logiciels qui pourraient être utiles.

DTMVIC

DTMVIC (Data and Text Mining : Visualization, Inference, Classification) est un logiciel de textométrie développé par Ludovic Lebart. Il permet d’effectuer un grand nombre de mesures statistiques sur un texte ou un corpus de textes. Il est caractérisé par sa spécialisation dans le traitement de données textuelles lorsqu’elles sont associées à des données numériques, comme dans le cas d’un sondage par exemple. Néanmoins, cet outil reste capable de traiter des données purement textuelles aussi. Cependant, il se présente sous la forme d’un programme indépendant, ce qui rend son intégration à une chaîne de traitement difficile. De plus, il ne fonctionne que sous le système d’exploitation Windows, ce qui le rend inadapté aux besoins du projet.

HyperBase

HyperBase est un logiciel de traitement textométrique de corpus textuels, développé par Étienne Brunet. Il est capable d’effectuer un certain nombre de traitements statistiques sur les corpus de textes qui lui sont fournis comme entrées. C’est un outil très utilisé dans le domaine des sciences sociales, mais sa structure en tant que programme indépendant le rend lui aussi difficile à intégrer à une chaîne de traitement. De plus, la version téléchargeable est conçue pour Windows, ce qui le rend lui aussi inadapté aux besoins du projet.

IRaMuTeQ

IRaMuTeQ (Interface de R pour les Analyses Multidimensionnelles de Textes et de Questionnaires) est un logiciel de traitement statistique de données textuelles, développé par le LERASS (Laboratoire d’Études et de Recherches Appliquées en Sciences Sociales) de l’Université de Toulouse 3. Contrairement aux deux outils présentés précédemment, il fonctionne grâce aux langages de programmation R et Python, ce qui le rend utilisable sur la majorité des systèmes d’exploitation existants, et particulièrement adapté au projet.

Lexico

Lexico est un outil de traitement textométrique de corpus de textes, développé par l’équipe du SYLED-CLA2T (Système Linguistiques Énonciation Discursivité – Centre d’Analyse Automatique des Textes) de l’Université Paris 3. Il fonctionne sur la base de corpus de textes prétraités, ce qui peut rendre son adaptation difficile aux besoins de l’outil. De plus, il ne fonctionne que sous Windows et MacOS, ce qui veut dire qu’il ne remplit pas les conditions techniques indiquées auparavant.

Le Trameur

Le Trameur est un logicel de traitement textométrique développé aussi par le SYLED-CLA2T de l’Université Paris 3. Comme la plupart des logiciels présentés ci-dessus, il est indépendant, mais il a l’avantage de pouvoir aussi fonctionner depuis la ligne de commande, ce qui faciliterait son intégration à l’outil. De plus, bien que cela ne soit pas nécessaire dans le cas du développement du projet, Le Trameur intègre aussi l’analyseur morphosyntaxique TreeTagger. Cependant, il n’est disponible que sous Windows, ce qui le rend inadapté au projet.

TXM

TXM est un logiciel de textométrie crée dans le cadre du projet Textométrie, et décrit dans un article intitulé TXM : Une plateforme logicielle opensource pour la textométrie – conception et développement .[Heiden et al., 2010].
Ses capacités sont similaires à celles des autres logiciels présentés ci-dessus,mais contrairement à la plupart des logiciels présentés, il est compatible avec un plus grand nombre de systèmes d’exploitation, ce qui le rend plus adapté au contexte de ce projet. Cependant, son fonctionnement en tant que programme indépendant devant être lancé depuis sa propre interface fait que son intégration à une chaîne de traitement pourrait poser quelques difficultés. Néanmoins, il reste une option intéressante pour la réalisation du projet.

AnaText

AnaText[Kraif, 2014] est un programme d’analyse textométrique en ligne, développé par Olivier Kraif. Comme les autres outils, présentés ci-dessus, il est capable d’effectuer un grand nombre de traitements statistiques sur des données textuelles. Bien que son fonctionnement en ligne le rende peu adapté au projet, l’équipe d’ELAN a pu me fournir une version partielle de l’outil qui fonctionne indépendamment de toute intégration en ligne, évitant donc ce problème. Il fonctionne sur la majorité des systèmes d’exploitation, remplissant donc les conditions techniques requises.

Résultats

La sélection du programme à intégrer dans ce cas a été plus difficile car aucun d’entre eux ne remplissait les conditions techniques requises, soit car ils ne fonctionnaient pas sous les systèmes d’exploitation demandés, soit car ils ne pouvaient être facilement intégrés à une chaîne de traitement. Néanmoins, j’ai ici aussi rassemblé les spécificités de ces programme dans un tableau, reproduit dans l’annexe D. Après avoir obtenu une version hors ligne du toolkit d’AnaText grâce à l’équipe d’ELAN, j’ai décidé de l’utiliser car AnaText était le programme qui remplissait les conditions nécessaires le mieux maintenant qu’il était utilisable localement.

Les plate-formes de TAL

Une autre solution qui aurait pu être explorée lors de cette partie de conception du projet et de choix des programmes à intégrer était les plateformes de TAL. Elles remplissent une fonction très similaire au but du projet d’intégrer une multitude de programmes de traitement textuel dans une seule interface dans le but de faciliter leur utilisation. Malheureusement, j’ai découvert cette solution trop tard pour pouvoir l’intégrer à temps dans la structure du projet. Néanmoins, j’ai quand même choisi d’établir une liste de ces plate-formes qui aurait pu être très utiles dans la réalisation du projet.

GATE

La première de ces plate-formes est la plate-forme GATE (General Architecture for Text Engineering). Développée par une équipe de projet de l’Université de Sheffield, elle intègre un grand nombre de programmes ayant pour objectif de traiter des données textuelles. De plus, elle intègre aussi des outils de développement conçus pour faciliter tout travail sur de la matière linguistique, ainsi qu’un outil Web crée pour faciliter l’annotation et l’analyse de corpus textuels. Enfin, GATE est un logiciel libre, ce qui le rend très attractif pour des projets de recherche.

LinguaStream

La seconde plate-forme est la plate-forme LinguaStream. Elle a été développée par le GREYC de l’université de Caen. Tout comme GATE, elle intègre un grand nombre de programmes dont le but est de faciliter le traitement de données textuelles, notamment celles au format XML. Elle fournit aussi une interface graphique adaptée à la création de chaînes de traitement en TAL, et aurait donc pu être un outil très utile dans le cadre du projet.
Néanmoins, elle semble ne plus être maintenue, et son site Internet n’est accessible qu’au travers d’archives, donc il semble qu’il n’aurait pas été possible d’utiliser cette plate-forme dans le cadre du projet.

BabelScape NLP

La troisème plate-forme de TAL est la plateforme de TAL crée par BabelScape, intitulée BabelScape NLP. Contrairement aux deux plate-formes préce-27 dentes, celle-ci prend la forme d’une chaîne de traitement déjà construite. Elle est capable de traiter des textes dans treize langues différentes. Néanmoins, elle n’est pas capable de traiter une certaine partie des langues demandées dans le cadre du projet, donc elle n’aurait pas été très adaptée au projet. De plus, contrairement aux programmes utilisés dans le cadre du projet, cette plate-forme n’est pas un logiciel libre, ce qui aurait rendu son utilisation d’autant plus difficile.

Développement

Après avoir effectué les analyses préliminaires présentées ci-dessus, la phase suivante était le développement de l’outil lui-même. Ce chapitre détaille tout ce processus, les changements appliqués au projet, ainsi que les difficultés auxquelles j’ai fait face durant ce développement.

Le début

La première étape du développement à été la création d’un script Python simple permettant d’utiliser TreeTagger par le biais de la ligne de commande, et ce, sur un ou plusieurs fichiers fournis comme entrées au script. Ce script avait pour vocation de servir de base sur laquelle les autres outils allait pouvoir être ajoutés. A ce point, l’outil était seulement capable d’effectuer un traitement morphosyntaxique grâce à TreeTagger. Après cela, j’ai ajouté les quatre autres étiqueteurs morphosyntaxiques choisis à l’outil un par un jusqu’à ce que l’outil soit capable d’utiliser l’étiqueteur demandé par l’utilisateur parmi les cinq disponibles. A cette étape, j’ai aussi ajouté des options supplémentaires comme le choix de la langue à traiter. Au début, je comptais intégrer toutes les langues traitées par au moins un des étiqueteurs à l’outil.
Néanmoins, je me suis aperçu que cela risquait de rendre l’outil trop imposant pour un gain minime. J’ai donc fait le choix de me limiter à 10 langues seulement, en incluant en priorité les langues qui seraient utiles dans le cadre des projets de l’équipe ELAN. Les langues choisies sont divisées en deux groupes : Les langues vivantes (français, anglais, espagnol, italien, allemand, portugais, grec moderne), et les langues mortes (latin, grec antique, français médiéval, allemand médiéval).
Au terme de cette étape, l’outil était capable de recevoir des fichiers de texte bruts, ainsi que des fichiers XML/TEI comme entrées. Néanmoins, il ne pouvait fournir comme sortie que les formats supportés par les étiqueteurs, à savoir TXT dans la majorité des cas, ainsi que CSV pour ceux capables de produire ce type de sortie.
En tout, cette étape du développement a duré environ un mois. Cependant, au terme de cette étape, l’outil possèdait les fonctions de base demandées, mais certaines améliorations était nécessaires. Premièrement, la procédure d’installation était devenue complexe à cause du grand nombre de prérequis, dont il fallait trouver un meilleur moyen d’installer l’outil. Deuxièmement, le traitement du XML, pourtant but central du projet n’était pas encore au point, et nécessitait donc plus de travail. Enfin, l’interface était encore peu intuitive car basée entièrement sur la ligne de commande. La résolution des ces trois faiblesses de l’outil a formé une grande partie de mon stage, qui est décrite ci-dessous.

Migration vers Docker

Le grand nombre de prérequis de l’outil rendait son installation difficile.
Par conséquent, il était nécessaire de trouver une solution qui permettait d’éviter de demander à l’utilisateur de suivre une procédure d’installation devenue très complexe à cause du grand nombre de programmes à installer.
Afin de résoudre ce problème, l’équipe ELAN m’a recommandé d’utiliser l’outil Docker afin de créer un environnement isolé pour l’outil, et de pouvoir construire cet environnement automatiquement en incluant tous ce qui était nécessaire. La partie suivante de mon stage a donc été consacrée à la création d’un environnement Docker pour l’outil, et à lui appliquer les modifications nécessaires afin qu’il puisse fonctionner dans un environnement isolé.
Pour ce faire, la première étape a été la création d’un environnement isolé qui pourrait recevoir l’outil. Il était donc nécessaire de trouver un moyen de télécharger et de paramétrer les cinq étiqueteurs morphosyntaxiques sans aucune action de la part de l’utilisateur après le premier lancement. Heureusement, Docker permet de créer un fichier contenant une liste d’instructions afin de construite l’environnement isolé, et cette liste d’instructions accepte les instructions de ligne de commande. Vu que l’outil était en train d’être développé sous Linux, j’avais accès à un grand nombre de commandes utiles, dont la commande « wget », qui permet de télécharger un fichier directement depuis son URL. Grâce à cette commande et quelques commandes de manipulation de fichiers, j’ai pu créer une liste d’instructions qui télécharge les cinq analyseurs morphosyntaxiques et les place dans les dossiers spécifiés, ce qui créeait donc l’environnement isolé requis.
La second étape a été l’adaptation de l’outil lui-même à cette nouvelle structure. Jusqu’à maintenant, il devait être configuré par chaque utilisateur afin de connaître la position de chacun des outils, mais maintenant qu’il était déployé dans un environnement isolé qui aurait toujours la même structure de fichier, les positions de chacun des outils m’était connues et pouvaient donc être directement intégrées au code au lieu de nécessiter une configuration manuelle par chaque utilisateur. De même, il avait maintenant des fichiers de sortie et d’entrée dédiés et stables, donc j’ai pu lui intégrer cette structure aussi.
Cette solution n’est néanmoins pas parfaite : En effet, elle rend le premier lancement de l’outil très lent, parce qu’il doit d’abord télécharger les données de tous les prérequis afin de tous les installer dans l’environnement isolé.
Cependant, après cette première installation, l’outil fonctionne correctement comme auparavant. Cette solution a donc permis de simplifier grandement le processus d’installation du projet, ce qui le rend moins complexe à utiliser pour un utilisateur lambda. De plus, cette migration avait aussi pour but de faciliter l’intégration prévue de l’outil à une page Internet. Cette migration de la version indépendante vers la version Docker a pris environ un mois aussi.

Traitement du XML

L’étape suivante a été la création d’une solution pour le traitement des fichiers XML. Avant ce point, l’outil était fonctionnel, mais il n’était capable que de traiter des fichiers de texte brut, ce qui ne convenait pas encore aux besoins de l’équipe d’ELAN. Il m’a donc été nécessaire de l’adapter au traitement de fichiers XML. J’ai donc mis au point trois solutions pour traiter les fichiers XML.
La première solution que j’ai implémentée était de retirer tout élément XML afin d’obtenir seulement le texte brut contenu dans le fichier XML.
Cette solution, bien que fonctionnelle, ne préservait pas le XML original dans le résultat, ce qui limitait son utilité. De plus, elle extrayait tout texte présent dans le fichier XML, peut importe sa position, ce qui faisait qu’elle traitait les métadonnées comme une partie du texte lui-même, et que certaines balises utilisées dans le formalisme XML-TEI posait problème, comme les balises ’<choice>’ par exemple.
La deuxième solution que j’ai mise au point utilisait le même principe d’extraction du texte brut depuis le XML, mais elle inscrivait les résultats directement dans le fichier XML lui même, sous la forme d’un nouvel élément. Cette solution permettait donc de conserver l’intégrité du XML tout en y ajoutant les résultats de l’analyse. Cette version produisait des résultats satisfaisants, mais le fait que les résultats soient inscrits dans un élément séparé dans le fichier XML faisait qu’il était difficile de les exploiter, et certains problèmes présents dans la première solution était toujours présents dans la seconde solution, car les deux solutions étaient construites autour du même principe.
Avec l’aide de l’équipe d’ELAN, je suis donc arrivé à une troisième solution plus satisfaisante. Cette solution utilisait aussi le principe d’extraction de texte brut indiqué ci-dessus, mais elle procédait élément par élément, remplaçant le contenu de l’élément par les résultats de l’analyse. Cela permettait donc à l’outil de conserver la structure du fichier XML tout en inscrivant les résultats dans cette même structure. Afin de fonctionner, cette solution utilisait un système d’élément minimal : Un élément du XML, par exemple le paragraphe sert d’unité minimale : tout élément qui lui est subordonné est éliminé, tandis que tout élément qui lui est supérieur est conservé. Un exemple des résultats produits par cette approche se trouve dans l’annexe E.
Cette approche par élément minimal permet à l’outil de gérer les problèmes qui pourraient être causés par les balises XML utilisées dans les projets de l’équipe ELAN, qui ne contiennent parfois qu’un seul mot, voire une partie d’un mot en les ignorant. Elle permet aussi de n’étiqueter que certaines parties du document, permettant ainsi à l’utilisateur d’éviter d’étiqueter des choses présentes dans le document XML, mais qui ne font pas partie du texte comme les métadonnées. Cette étape a demandé environ un mois et demi de travail.

Ajout d’une interface Web

Après avoir résolu les problèmes d’installation et de traitement du XML,le dernier problème à régler était celui de l’interface. Pour résoudre ce problème ainsi que pour faciliter l’utilisation de l’outil encore plus, l’équipe ELAN m’a recommandé de le déposer sur un serveur Apache afin de le rendre accessible depuis un navigateur Internet classique, évitant ainsi tout téléchargement de la part de l’utilisateur. Sa structure sous forme d’un conteneur Docker a rendu ce processus en particulier très facile, car l’outil Compose intégré à Docker a pour but d’agréger différents services tels que Apache et Python.
Néanmoins, il a été nécessaire d’adapter l’outil lui même : En effet, depuis sa création, il était lancé depuis la ligne de commande mais ce type d’interface ne convenait plus, maintenant que les utilisateurs allaient y accéder par le biais d’un site Internet. Il m’a donc fallu lui créer une interface Web, interface que j’ai réalisé en utilisant les langages HTML et PHP. Cette interface n’a pas changé la structure de l’outil Python en lui-même, mais elle m’a permis de créer un moyen plus simple de l’utiliser, ainsi que de permettre à l’utilisateur d’accéder à des commandes qui étaient auparavant difficiles d’accès. Le développement de cette interface a occupé le reste de mon stage jusque aux tests finaux. Des exemples de captures d’écran de cette interface se trouvent ci-dessous, et des exemples supplémentaires, ainsi qu’une version agrandie.
Cependant, l’ancienne interface en ligne de commande existe encore dans le programme bien qu’elle soit indisponible sur la version Web. Cela veut dire que l’outil peut toujours être utilisé par le biais de la ligne de commande, ce qui pourrait être utile pour l’intégrer à une grande variété de chaînes de traitement si nécessaire.

Difficultés rencontrées

Le développement de l’outil n’a pas été sans son lot de problèmes. Le premier que j’ai rencontré est devenu apparent dès le début de mon stage : puisque l’équipe d’ELAN utilisait le système d’exploitation Linux, il m’a fallu m’y adapter, ce qui m’a causé quelques difficultés pendant une période au début de mon stage. L’équipe d’ELAN m’a grandement aidé à accomplir ce but, mais un certain temps d’adaptation m’a quand même été nécessaire.
Le deuxième problème est survenu peu de temps après, durant la sélection d’un logiciel de textométrie adapté à l’outil. En effet, un grand nombre de ces logiciels ne convenaient pas à la structure du projet, et certains d’entre eux possédait des problèmes de compatibilité avec Linux. Le troisième problème auquel j’ai du faire face était le problème de traitement du XML. Comme décrit ci-dessus, il m’a fallu créer trois systèmes différents avant d’en obtenir un qui remplissait les conditions attendues. Néanmoins, malgré ces problèmes, j’ai réussi à accomplir ce qui m’était demandé en concevant l’outil qui correspondait aux demandes de l’équipe d’ELAN.

Bilan personnel du développement

Malgré les difficultés que j’ai rencontrées, le processus de développement entrepris durant mon stage m’a permis de me former à l’utilisation de nombreux outils très utiles dans le domaine du TAL, ainsi que dans le domaine de l’informatique en général. Par exemple, l’utilisation de l’outil Git au sein de l’équipe ELAN m’a aidé à maîtriser l’utilisation des outils de gestion de version, en particulier dans un contexte de travail collaboratif. De même, les recommandations techniques qui m’ont été faites par l’équipe d’ELAN m’ont permis de découvrir plusieurs autres logiciels utiles pour certaines tâches spécifiques, tels que Docker. Ce stage a aussi été pour moi une opportunité d’utiliser plusieurs langages de programmation tels que Python ou PHP, ainsi que le langage de balisage HTML dans une situation de développement réelle et donc d’améliorer ma maîtrise de chacun d’entre eux. De plus, la rédaction de documents durant le stage et l’écriture de ce rapport m’ont donné l’opportunité d’apprendre à utiliser le langage LaTeX pour formater plus facilement mes productions écrites. Enfin, la situation quelque peu inhabituelle causée par la crise sanitaire m’a donné une chance de m’adapter au travail à distance et m’a permis de m’habituer à travailler de façon plus indépendante. Un lien vers le répertoire GitLab où le projet est stocké se trouve dans l’annexe G ainsi que dans la sitographie.

Conclusion

Ce qui a été accompli

Le résultat final de mon travail a été la création d’un outil complet, utilisé par le biais d’une interface Web capable d’effectuer l’étiquetage morphosyntaxique d’un ou plusieurs textes ou fichiers XML avec un ou plusieurs des cinq étiqueteurs morphosyntaxiques intégrés, puis d’afficher ces résultats sous trois formes différentes : sous la forme d’un texte brut produit par les étiqueteurs morphosyntaxiques, sous la forme d’un fichier XML modifié, ou sous la forme d’un page Web créée par AnaText. Cet outil constitue donc une chaîne de traitement comme demandé par l’équipe ELAN.

Ce qui devrait suivre

Les objectifs fixés par l’equipe ELAN ont été accomplis, néanmoins, certaines améliorations pourraient être apportées au résultat final afin de l’améliorer. Par exemple, l’interface Web actuelle n’a pas de feuille de style, ce qui lui donne une apparence encore très rudimentaire et peu ergonomique. De plus, bien que l’interface soit terminée, elle n’a pas été encore mise en ligne, ce qui la rend pour le moment inaccessible en dehors de l’équipe ELAN. De plus, l’outil n’intègre pas d’étape de normalisation, ce qui peut causer des problèmes si les textes fournis comme entrées ne suivent pas un format standardisé. Enfin, l’adaptation d’AnaText à l’outil n’est pas complète et possède encore quelques erreurs qui diminuent quelque peu son utilité. Le plus grand problème à résoudre reste l’harmonisation des étiquettes : en effet, les étiqueteurs utilisent presque tous des étiquettes différentes qui doivent être converties vers un seul jeu d’étiquettes commun, ce qui pose de nombreux problèmes de perte de précision, surtout lorsque certains jeux d’étiquettes sont plus détaillés que d’autres. L’outil intègre un système de conversion, mais il est encore très peu développé et cause donc toujours un grand nombre d’erreurs de conversion, ce qui diminue la précision des résultats.

Table des matières
Introduction 
1 Définition du besoin 
1.1 Résumé de la demande initiale
1.2 Enjeux du projet
1.3 Choix techniques
1.4 Entrées fournies
1.4.1 Types d’entrées
1.4.2 Formats d’entrée
1.5 Sorties à produire
1.5.1 Traitements à appliquer
1.5.2 Format de sortie
2 Méthodes de travail 
2.1 Outils utilisés
2.1.1 Ubuntu
2.1.2 Python
2.1.3 Git
2.1.4 Docker
2.1.5 PHP
2.2 Organisation du travail
3 Analyses préliminaires 
3.1 Analyse des outils morphosyntaxiques
3.1.1 TreeTagger
3.1.2 SpaCy
3.1.3 CoreNLP
3.1.4 UDPipe
3.1.5 NLTK
3.1.6 Talismane
3.1.7 Test et résultats
3.2 Analyse des outils textométriques
3.2.1 Point de départ
3.2.2 DTMVIC
3.2.3 HyperBase
3.2.4 IRaMuTeQ
3.2.5 Lexico5
3.2.6 Le Trameur
3.2.7 TXM
3.2.8 AnaText
3.2.9 Résultats
3.3 Les plate-formes de TAL
3.3.1 GATE
3.3.2 LinguaStream
3.3.3 BabelScape NLP
4 Développement 
4.1 Le début
4.2 Migration vers Docker
4.3 Traitement du XML
4.4 Ajout d’une interface Web
4.5 Difficultés rencontrées
4.6 Bilan personnel du développement
Conlcusion 
Bibilographie 
Sitographie
Liste des tableaux 
Table des figures 
Annexes 
A Documentation de l’outil : README
B Tableau résumé des étiqueteurs morphosyntaxiques
C Court rapport sur les outils d’analyse morphosyntaxique
D Tableau résumé des outils de textométrie
E Extrait de résultat de la version finale de l’analyse XML
F Captures d’écran
G Lien vers le répertoire GitLab du projet
H Texte de référence de l’évaluation des analyseurs morphosyntaxiques
I Annotation manuelle de réference
Résumé
Mots clefs 
Summary 
Keywords 

Télécharger le rapport complet