Professional Documents
Culture Documents
Mmoire de Master 2 Sciences du Langage, mention Industries de la Langue, Spcialit parole, crit et conception d'outils pour l'apprentissage des langues, Parcours Traitement Automatique de la Langue Ecrite et de la Parole Orientation Recherche
3. LanguageTool .........................................................................................................20
3.1. Rejet de la premire version de l'outil.........................................................................20 3.1.1. Structure de LanguageTool l'poque................................................................20 3.1.2. Points faibles l'origine du rejet.........................................................................22 3.2. volutions et nouvelle version de l'outil.....................................................................22 3.2.1. volutions du systme.........................................................................................22 3.2.2. Structure actuelle de LanguageTool....................................................................23
4. Conclusion...............................................................................................................24 Chapitre 2 : Adaptation de LanguageTool la correction du franais.....................25 1. Test des rgles existantes.........................................................................................25
1.1. Test et erreurs dtectes...............................................................................................25
4 5.1.4. Les erreurs d'accord avec le sujet........................................................................46 5.2. Des fautes d'orthographe ou de grammaire ?..............................................................46 5.2.1. Point de vue linguistique : orthographe lexicale et orthographe grammaticale. .47 5.2.2. Point de vue informatique : correction orthographique et correction grammaticale..................................................................................................................47 5.2.3. Chevauchement des fautes d'orthographe et de grammaire................................48 5.3. Les fautes du dactylographe........................................................................................49
6. Conclusion...............................................................................................................50 Chapitre 3 : Amlioration du formalisme de LanguageTool.....................................51 1. Critique des limites du formalisme actuel...............................................................51
1.1. Le "pattern-matching" rigide......................................................................................51 1.1.1. Explosion combinatoire des rgles......................................................................51 1.1.2. Ncessit et impossibilit de prvoir tous les contextes......................................52 1.1.3. Limitation au contexte immdiat.........................................................................54 1.2. De nombreuses fausses alarmes..................................................................................54 1.2.1. Mots ambigus.......................................................................................................55 1.2.2. Mots mal tiquets...............................................................................................55 1.2.3. Dtections multiples............................................................................................56 1.2.4. Dtections en cascade..........................................................................................56
5 3.1.4. lment <unify>..................................................................................................63 3.1.5. lment <pattern>...............................................................................................64 3.1.6. lment <token>.................................................................................................64 3.1.7. lment <chunk>.................................................................................................65 3.1.8. lment <feature>...............................................................................................66 3.1.9. lment <exception>...........................................................................................67 3.2. Interprtation du formalisme.......................................................................................67 3.3. Conception d'un calculateur d'unification...................................................................69 3.3.1. Pr-requis.............................................................................................................69 3.3.2. Fonctionnement du module de calcul d'unification.............................................70 3.3.3. Dveloppement....................................................................................................72 3.3.4. Test du prototype.................................................................................................73
4. Conclusion...............................................................................................................75 Chapitre 4 : Conclusions et perspectives ....................................................................77 1. Premier correcteur grammatical OpenOffice.org....................................................77 2. Proposition de formalisme.......................................................................................77
2.1. Nouvelle structure ......................................................................................................78 2.2. Dveloppement de rgles partir d'un corpus............................................................79 2.2.1. Constitution d'un corpus d'erreurs.......................................................................79 2.2.2. Analyse du corpus...............................................................................................80
3. Intgration au projet OpenOffice.org.......................................................................81 4. Vers une autre approche de la correction grammaticale..........................................82 Glossaire..........................................................................................................................83 Bibliographie..................................................................................................................87 Webographie...................................................................................................................89
Remerciements
Thomas Lebarb, mon directeur de recherche prfr, pour sa patience et la confiance qu'il m'a accorde,
la socit Nuxeo pour sa collaboration, et plus particulirement Laurent Godard pour son soutien technique et ses conseils aviss,
Jean-Pierre Chevrot et Agns Millet, pour m'avoir fourni le prcieux corpus sur lequel s'appuie une partie de mon travail,
la communaut LanguageTool, et en particulier Marcin Mikowski pour le temps qu'il m'a consacr, et sans l'aide de qui une partie de mon travail n'aurait pu tre ralise,
Virginie, pour ses relectures... "pointilleuses", pour ses petites ritournelles qui me poursuivront vie : "on est un... lapin" et "on ne se base pas...",
tout le bureau I110 et ses pices rapportes : Ninie, Alexia, Mathieu, Delphine, Tiphaine, Julien et Nico pour leur bonne humeur constante et leurs minutes culturelles,
toute l'quipe du DIP, en particulier Roseline pour sa gentillesse, Marie-Christine et Antoine pour avoir partag leur bureau, et Claude et Olivier pour leur acte hroque,
mon Hros, mon Dieu, mon Matre, pour m'avoir pousse, sans jamais me laisser tomber...
mon pre, ma mre, Irne et Daniel pour leurs prcieux encouragements et leurs coups de main ponctuels.
Introduction
Introduction
Ce travail s'inscrit dans le cadre du projet communautaire OpenOffice.org dans la continuit du stage de Master 2 Industrie de la langue de Myriam Lechelt. Il est encadr par Thomas Lebarb, matre de confrences l'universit Stendhal, qui a initi cette recherche avec Laurent Godard de la socit Nuxeo-InDesko. L'objectif de ce travail interdisciplinaire (linguistique et informatique) est la cration d'un outil de correction grammaticale libre pour le franais, pouvant tre intgr l'environnement bureautique, ou utilis indpendamment de celui-ci. Dans ce domaine, les outils existants sont gnralement des logiciels propritaires aux cots d'intgration levs, qui sont peu ou pas dcrits dans la littrature, et ferms toute amlioration externe. Nos travaux de recherche visent donc, de manire plus gnrale, dvelopper un outil de correction grammaticale gnrique, dont les ressources langagires seront accessibles et modifiables. Dans un premier chapitre, nous exposons le fonctionnement gnral des correcteurs grammaticaux. Nous rsumons ensuite le travail qui a t ralis par Myriam Lechelt pour adapter l'un d'entre eux au franais. Il s'agit de An Gramadir, un outil libre cr pour le galique. Les conclusions sur cette adaptation en ont montr les limites, et pour cette raison, nous avons dcid de travailler sur un autre correcteur, LanguageTool, que nous prsentons et dont nous pensons qu'il est mieux adaptable au franais. Le second chapitre est consacr la transcription des travaux de M. Lechelt dans le formalisme actuel de LanguageTool. Nous avons tout d'abord combl une lacune de l'outil, en ralisant l'implantation d'un module de dsambigusation, puis nous avons import les rgles de An Gramadir. Nous dtaillons alors comment nous les avons modifies et simplifies. L'analyse d'un corpus de fautes de grammaire nous a ensuite permis de complter ces rgles, et pour finir nous dfinissons la typologie des erreurs traites. Dans le chapitre 3, aprs avoir critiqu certaines limites de LanguageTool, telle que l'explosion combinatoire des rgles, nous proposons un nouveau formalisme pour y remdier. Fond sur la combinaison de deux principes linguistiques, la segmentation en chunks et l'unification, ce formalisme permet la dtection des fautes d'accords avec seulement quelques rgles gnriques. Nous le dcrivons, puis nous prsentons un prototype d'outil de calcul d'unification que nous avons dvelopp, permettant de montrer la faisabilit de ce que nous avons dcrit.
Chapitre 1 : Existant
Chapitre 1 : Existant
Dans ce chapitre, nous commenons par expliquer le fonctionnement gnral des correcteurs grammaticaux. Nous rsumons ensuite le travail qui a t effectu pour adapter au franais un de ces outils : "An Gramadir", sans oublier les conclusions auxquelles ce travail a men, qui ne sont pas toutes positives. Pour cette raison, nous nous sommes tourne vers un autre correcteur, LanguageTool, que nous prsentons et sur lequel nous travaillons dans les chapitres suivants.
Texte vrifier
phrases et tokens
texte tiquet
Texte corrig
TOKENIZATION
CHUNKING
corpus
ou
Figure 1: Structure gnrale d'un correcteur grammatical (les zones hachures correspondent aux traitements facultatifs)
1.1. Tokenization
Le premier traitement consiste dcouper le texte en phrases, puis les phrases en mots, ou plus exactement en tokens. C'est la segmentation, ou tokenization, ralise par le tokenizer. Nous emploierons indiffremment les termes mot, au sens forme graphique, et token, pour dsigner l'unit issue de la segmentation, bien que le terme le plus appropri soit token. En effet, le mot en linguistique peut dsigner une unit smantique constitue de plusieurs mots graphiques. Par exemple pomme de terre est une unit compose de 3 mots graphiques, et sera segmente en 3 tokens distincts. Par ailleurs, les units obtenues aprs la tokenization peuvent aussi tre des signes de ponctuation. La segmentation du texte en phrase s'appuie principalement sur les marqueurs de dbut et de fin
Chapitre 1 : Existant
de phrases que sont les majuscules ou les points par exemple. La tokenization des phrases en mots prend elle aussi appui sur la ponctuation, ainsi que sur les espaces. Dans certaines langues comme le franais, les points des abrviations ou des sigles, les apostrophes, et les tirets dans certains mots, peuvent induire le tokenizer en erreur, et conduire une mauvaise segmentation.
Chapitre 1 : Existant
10
Chapitre 1 : Existant
11
Texte vrifier
phrases et tokens
texte tiquet
Texte corrig
TOKENIZATION
CHUNKING
corpus
2.2.1. La tokenization
Les premires modifications concernent la segmentation. Le tokenizer initial, cr pour le galique, n'tait en effet pas capable de traiter les apostrophes, les traits d'union, et les points contenus dans les sigles, trs frquents en franais.
Chapitre 1 : Existant
12
La solution adopte dans (Lechelt, 2005) consiste rechercher dans le lexique les chanes de caractres qui contiennent un de ces signes problmatiques, et que le tokenizer rencontre. Les chanes prsentes dans le lexique sont conserves telles quelles, car elles sont considres comme un seul token. En revanche, les chanes qui ne figurent pas dans ce lexique sont dcomposes en deux units distinctes.
2.2.2. Le tagging
La mthode de tagging en elle-mme n'a pas t modifie dans (Lechelt, 2005). En revanche, il a bien sr fallu adapter un lexique tiquet franais en amont, et des rgles de dsambigusation en aval du tagger.
a) Le lexique tiquet
Pour effectuer le tagging, il est ncessaire d'avoir un lexique de formes flchies tiquetes morphosyntaxiquement. Le jeu d'tiquettes (ou tagset) de ce lexique doit tre dfini de manire permettre une bonne correction grammaticale, et doit tre compatible avec l'outil qui va l'utiliser. Le lexique DICO [Web : DIC], de la Bibliothque Universelle ABU [Web : ABU], a t choisi pour tre implant dans An Gramadir. Pour cela, il a d subir plusieurs transformations, qui ont abouti la cration d'un nouveau lexique : InDico. Un nouveau jeu d'tiquettes a d'abord t dfini, en fonction de celui de DICO, et des informations ncessaires une bonne correction. Des entres du lexique ont t modifies, supprimes ou ajoutes. Les informations morphosyntaxiques ont ensuite t traduites dans le formalisme de An Gramadir, et certaines ont t modifies en fonction du nouveau tagset. l'issu de toutes ces transformations, le nouveau lexique InDico a pu tre utilis dans An Gramadir pour tiqueter des textes en franais.
b) La dsambigusation
Une fois l'tiquetage effectu, s'est pos le problme de la dsambigusation. Des tests sur corpus ont fait ressortir 46% de mots ambigus, les plus nombreux tant les noms, les adjectifs, les dterminants et les verbes. Une base de rgles de dsambigusation a donc t construite, en s'appuyant sur la mthode des rgles par dfaut explique par J. Vergne et E. Giguet (Vergne & Giguet, 1998). Ainsi, une premire srie de rgles particulires dsambiguse des cas prcis. Elle est suivie de rgles par dfaut qui sont un peu plus gnrales, et pour finir des rgles dites brutes traitent tous les cas d'ambigut non rsolus par les rgles prcdentes. Ces dernires rgles sont ncessaires dans la mesure o la vrification grammaticale dans An Gramadir ne tolre aucune ambigut.
Chapitre 1 : Existant
13
le sujet et le verbe) et les confusions entre homophones (a et sa / m'a et ma / et er / ces, ses, c'est et s'est). D'autres types de fautes sont ressortis, mais ne semblaient pas pouvoir tre traits avec An Gramadir. Il s'agit des erreurs de concordance des temps, des oublis de mots, comme la particule ne de la ngation par exemple, des fautes de style, ou encore des erreurs morphologiques, comme la contraction de de + le en du par exemple, ou bien l'lision devant une voyelle de certains mots grammaticaux comme que ou le. Ce travail d'observation effectu, des rgles de dtection des fautes ont pu tre crites. Il s'agit de rgles d'erreurs, qui dcrivent des modles de fautes de grammaire, et qui permettent de signaler les erreurs dans le texte lorsqu'elles concident avec ceux-ci. L'ensemble des rgles cres dans (Lechelt, 2005) permet de dtecter des fautes d'accords dans les syntagmes nominaux (dterminants, adjectifs et noms), entre le sujet et le verbe lorsqu'ils sont proches, ou bien entre le sujet et les adjectifs attributs, ou les participes passs, prcds de l'auxiliaire tre. Les rgles couvrent aussi quelques fautes de proximit phontique, comme ce et se, ou encore son et sont.
NB : les * dans les rgles signifient que le caractre prcdent peut tre prsent entre 0 et x fois. Ils sont distinguer de ceux qui prcdent les exemples agrammaticaux.
Ainsi, la rgle ci-dessus signifie qu'un dterminant fminin singulier ambigu, suivi d'un nom quelconque, est un dterminant fminin singulier (<D f s>).
Chapitre 1 : Existant
14
Nous avons vu plus haut que les rgles de dsambigusation sont de trois types : particulires, par dfaut et brutes. L'ordre dans lequel les diffrents types de rgles apparaissent dans le fichier est trs important. Les rgles les plus gnrales doivent se trouver la fin, pour que toutes les rgles plus prcises puissent s'appliquer auparavant.
Nous pouvons d'ores et dj constater que les macros et les rgles de An Gramadir sont difficilement lisibles et comprhensibles. Il parat peu envisageable que des linguistes se lancent dans la rdaction de nouvelles rgles, moins qu'ils ne soient aussi de bons informaticiens.
Chapitre 1 : Existant
15
Chapitre 1 : Existant
16
Parmi les propositions pour amliorer An Gramadir, outre la ncessit d'augmenter le nombre de rgles de dsambigusation, il a donc d'abord t suggr, dans (Lechelt, 2005), de retravailler le lexique : Il faudrait commencer par vrifier et uniformiser les entres, dont certaines sont incohrentes. En effet, des mots picnes ou invariables apparaissent sous deux entres distinctes : masculin et fminin, ou bien singulier et pluriel. Il serait bon de n'avoir qu'une seule entre, avec un tag "picne" ou "invariable" selon les cas. Les pronoms auraient aussi besoin d'tre uniformiss.
Certains tags pourraient ensuite tre complts avec de nouveaux traits, pour affiner la dsambigusation. Par exemple, le trait antpos ou postpos pour les adjectifs, le traits verbe d'tat, un trait sur la transitivit des verbes, etc.
L'ajout d'une transcription phontique permettrait une meilleure dtection des fautes de proximit phontique.
Nous pourrions enrichir le lexique avec d'autres lexiques spcialiss disponibles, comme celui des noms propres.
Le lexique et ses tags devraient tre rcrits au format XML, ce qui faciliterait le traitement des donnes par le correcteur.
Un autre point faible de An Gramadir concerne les rgles d'erreurs, qui ne dtectent qu'une petite varit de fautes et ne sont pas assez nombreuses. Il faudrait donc les complter, mais aussi utiliser les possibilits offertes par le dcoupage en chunks, ou syntagmes. Comme nous allons le voir dans le point suivant, les chunks seraient utiles pour dtecter d'autres types d'erreurs, comme la concordance des temps, les accords sujet-verbe, ou encore les accords des participes passs aprs l'auxiliaire avoir. Il n'est en effet pas possible de dtecter de telles fautes avec un systme uniquement fond sur le contexte immdiat.
17
Les structures de traits dcrivent chaque lment d'une phrase un numrant ses caractristiques linguistiques, syntaxiques ou smantiques, sous la forme de liste de couples trait-valeur. Les tiquettes des mots en sont un exemple. Les informations contenues dans les tags correspondent aux traits. L'unification consiste combiner les traits de deux tags et vrifier leur compatibilit. Deux structures de traits peuvent s'unifier si elles ont les mmes valeurs pour des traits identiques, mais pas dans le cas de valeurs contradictoires pour un mme trait. Par exemple, l'unification n'est pas possible entre le tag du nom genoux et celui du dterminant le, car la valeur du trait nombre n'est pas identique : Le genoux genre = masculin U genre = masculin = chec nombre = singulier nombre = pluriel En utilisant l'unification de structure de traits, la dtection des fautes au sein d'un chunk est possible, mme si un mot est ambigu ou mal tiquet. De plus, en attribuant des traits au chunks, ils peuvent alors s'unifier entre eux, et des erreurs entre groupes de mots peuvent ainsi tre dtectes, comme par exemple l'accord entre le groupe nominal sujet et le groupe verbal. Il faut cependant veiller corriger d'abord les fautes "intra-chunk", de manire ce que le chunk possde les bons traits, pour pouvoir s'unifier par la suite aux autres chunks lors de la vrification "inter-chunks".
3. LanguageTool
Parmi les correcteurs analyss dans (Lechelt, 2005), LanguageTool de D. Naber a t rejet l'poque, avec hsitation. Comme An Gramadir, il se fondait sur des rgles d'erreurs rdiges la main, mais il procdait diffremment quant au tagging et la dtection des fautes. Nous allons voir que depuis l'analyse ralise par Lechelt (2005), LanguageTool a beaucoup volu. La version disponible aujourd'hui semble tre bien mieux adapte la correction du franais que ne l'tait celle de l'poque.
Chapitre 1 : Existant
phrases et tokens phrases segmentes en chunks
18
Texte vrifier
texte tiquet
Texte corrig
TOKENIZATION
CHUNKING
corpus
Figure 3: Structure de LanguageTool - version 1 Le texte tait d'abord dcoup en phrases, puis en mots. Les mots taient ensuite tiquets, et dsambiguss par une mthode statistique, qui ncessitait au pralable un apprentissage sur corpus. Pour chaque mot, LanguageTool dterminait la probabilit que ce mot ait tel tag, puis la probabilit qu'il se trouve dans un certain contexte (entre un tag A et un tag B ). Le tag pour lequel la somme de ces deux probabilits tait la plus forte tait appliqu au mot. Des rgles crites manuellement venaient en complment pour dsambiguser les mots qui n'avaient pas pu l'tre avec le systme de probabilits. Suite au tagging, LanguageTool effectuait une tape de chunking, c'est--dire de segmentation des phrases en syntagmes minimaux (chunks), principalement nominaux ou verbaux. Les chunks taient dtermins en fonction de patrons prdfinis, contenus dans un fichier. Les rgles dfinissant les patrons de chunks taient du type : dbut de chunk, fin de chunk, nom du chunk. Lors de l'analyse de la phrase, si une suite de mots correspondait un modle, alors cette suite tait dfinie comme chunk. C'tait un atout par rapport An Gramadir, mme s'il ne s'agissait que d'un chunker trs basique. Arrivait enfin l'tape de dtection des fautes de grammaire. Cette tape utilisait une base de rgles d'erreurs formalises en XML. Chaque rgle contenait un identifiant (id), un nom (name), le modle de l'erreur (pattern), une explication de la rgle (message) destination de l'utilisateur, et un exemple de l'erreur commise (example). Les rgles pouvaient aussi bien porter sur les mots que sur les tags ou sur les chunks. L'exemple suivant correspond un extrait d'une rgle d'erreur d'accord entre un dterminant et un nom en anglais, dans le cas o a, an ou one sont suivis d'un chunk nominal pluriel (NPP) :
<rule id="DET_NOUN" name="Determiner/noun agreement"> <pattern lang="en">"(a|an|one)"_NPP</pattern> <message>For plural nouns use the plural article the</message> </rule>
Pour dtecter les fautes, le systme comparait le texte avec les rgles d'erreurs, et plus prcisment avec le pattern de chaque rgle. S'il y avait correspondance, le systme indiquait qu'une erreur avait t dtecte.
Chapitre 1 : Existant
19
Chapitre 1 : Existant
20
Un dveloppement de l'intgration de l'outil dans la suite OpenOffice.org a par ailleurs t ralis. Ceci nous intresse particulirement puisque l'un de nos objectifs est d'y implanter la correction grammaticale du franais. Signalons aussi d'autres amliorations de LanguageTool, qui ne nous concernent pas toutes directement pour l'adaptation au franais. Par exemple, de nombreuses rgles ont t ajoutes, pour la gestion notamment des majuscules, des faux-amis ou de la ponctuation, et de nouveaux tags sont venus complter le jeu d'tiquettes existant.
Texte corrig
TOKENIZATION
CHUNKING
corpus
probabilits ou
rgles
Figure 4: Structure de LanguageTool - Version 2 La nouvelle structure de LanguageTool, telle qu'illustre dans la figure 4, est actuellement compose de plusieurs classes Java qui effectuent :
l'tiquetage morphosyntaxique des mots : partir d'un lexique de formes flchies, chacune ayant une tiquette avec des informations morphosyntaxiques (catgorie grammaticale et traits de sous-catgorisation), chaque mot du texte reoit une tiquette, ou plusieurs s'il est ambigu. Aucune dsambigusation n'tant effectue, les mots qui ont plusieurs tiquettes les conservent toutes. Ainsi bte aura 3 tags : "nom fminin singulier", "adjectif masculin singulier" et "adjectif fminin singulier". la dtection des erreurs de grammaire : elle s'effectue par comparaison du texte avec une base de rgles dcrivant des erreurs. Si une partie du texte correspond une rgle, alors une faute est signale.
: le modle de l'erreur. Le texte lui est compar lors de la vrification. Il se prsente gnralement sous forme d'expressions rgulires. message : une description de la rgle, l'usage de l'utilisateur. example : un exemple d'nonc correspondant la faute commise. Il y a en gnral au moins deux exemples : un exemple d'nonc correct et un exemple d'nonc incorrect.
pattern
21
Cette rgle dtecte une confusion dans l'utilisation des homophones m'a et ma. Si le texte vrifier contient ma suivi d'un verbe (V.*), alors il y a une erreur. Dans ce cas, un message est renvoy l'utilisateur : le token ma est mis en vidence ( mark_to="-1" ), et le message et les exemples s'affichent.
4. Conclusion
Dans ce chapitre, aprs avoir fait une prsentation gnrale des correcteurs grammaticaux, nous avons rsum le travail ralis par Lechelt (2005) sur l'un d'entre eux, An Gramadir pour l'adapter la correction grammatical du franais. Cette adaptation a mis en vidence les limites de l'outil, pour le traitement du franais. Ces limites viennent d'une part de rgles qui s'appuient sur un contexte potentiellement faux ou ambigu, d'autre part de rgles qui reposent sur un systme de pattern matching rigide et qui impliquent de prvoir toutes les combinaisons de mots possibles. Malgr les propositions de Lechelt (2005) afin d'amliorer l'adaptation de An Gramadir, le systme reste limit pour la correction du franais. La conception d'un nouvel outil, fond sur l'unification de structures de traits et sur le chunking, a sembl tre la meilleure alternative. Il a donc t dcid de laisser An Gramadir de ct. Nous avons aussi prsent le correcteur LanguageTool. S'il a t rejet l'poque dans (Lechelt, 2005), pour l'adaptation au franais, il a aujourd'hui beaucoup volu. Sa structure actuelle permettrait de dpasser les limites atteintes par An Gramadir. Dans le chapitre suivant, nous prsentons le travail effectu sur LanguageTool, dont l'importation de toutes les rgles crites par Lechelt (2005).
22
Chapitre 2 : Adaptation de LanguageTool la correction du franais Phrase teste 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Sa voiture est en panne. *a voiture est en panne. La visite a dur longtemps. *La visite dur longtemps. Il se livre la police. *Il ce livre la police. Je peux utiliser ce tlphone ? *Je peux utiliser se tlphone ? Ces traits ne sont pas droits. *Ces traits ne son pas droits. Il a publi son livre. *Il a publi sont livre. Il a publi son livre. Correction suggre *a voiture est en panne Sa voiture est en panne. *La visite dur longtemps. Phrase correcte *Il ce livre la police. Il se livre la police. *Je peux utiliser se tlphone ? Phrase correcte *Ces traits ne son pas droits. Phrase correcte *Il a publi sont livre.
23
Le tableau ci-dessus permet de faire plusieurs observations. Tout d'abord, les phrases correctes (1, 3, 5, 7, 9 et 11) sont toutes dtectes comme fausses, et les suggestions de correction les concernant contiennent toutes une erreur. Ensuite, parmi les phrases agrammaticales (2, 4, 6, 8, 10 et 12), la moiti d'entre elles est corrige correctement, mais dans l'autre moiti, l'erreur n'est pas dtecte. Par ailleurs, pour les phrases 1-2, 5-6 et 11-12, la correction d'une phrase teste correspond l'autre phrase teste. Ainsi, 2 est la correction de 1, et 1 est la correction de 2. Que nous crivions a ou sa dans les phrases 1 et 2, ce ou se dans les phrases 5 et 6, ou encore son ou sont dans les phrases 11 et 12, la phrase n'est donc finalement jamais considre comme correcte.
24
Prenons maintenant les deux phrases suivantes, ainsi que leur tiquetage ralis par LanguageTool : a) Sa voiture est en panne.
<S> Sa [Sa/D f s] voiture [voiture/V sub pres 1 s, voiture/V sub pres 3 s, voiture/V imp pres 2 s, voiture/V ind pres 1 s, voiture/V ind pres 3 s, voiture/N f s] est en panne [est/V etre ind pres 3 s, est/J e p,est/J e s, est/N m s] [en/P, en/R pers obj e sp] [panne/V sub pres 1 s, panne/V sub pres 3 s, panne/V imp pres 2 s, panne/V ind pres 1 s, panne/V ind pres 3 s, panne/N f s] [./M fin,
. </S>]
25
Nous voyons que le mot voiture a plusieurs tiquettes. Il peut s'agir du nom fminin voiture
(voiture/N f s) ou du verbe voiturer (voiture/V ...). Il est donc ambigu au niveau de la
catgorie. Lors de la vrification des phrases, tous les tags d'un mot sont pris en compte pour l'application des rgles. La rgle 1 s'applique, tort, la phrase a) car elle trouve sa, suivi d'un mot tiquet "verbe". Il aurait fallu ici que le tag "verbe" soit ignor et que seul le tag "nom" soit pris en compte puisque c'est celui qui correspond au mot voiture dans cet exemple. La rgle 2. s'applique la phrase b) car elle trouve a, suivi du mot tiquet "nom". Il est alors suggr de remplacer a par sa. Ici, la dtection est correcte. Il y a bien une faute. Les noncs a) et b) sont donc tout deux considrs comme faux cause de la prsence de plusieurs tiquettes pour le mot voiture.
26
La DTD (Document Type Definition) est document associ des fichiers XML, et qui dfinit le modle de structure que ces fichiers XML doivent respecter. Elle indique les noms des lments pouvant apparatre, ainsi que leur contenu (sous-lments et attributs) http://fr.wikipedia.org/wiki/DTD
27
d'utiliser le mme formalisme. Nous y avons ajout un lment <disambig> et son attribut postag, et avons retir les lments inutiles pour la dsambigusation, comme par exemple <message> , ou <example> . Le fichier XML a ensuite t cr avec quelques rgles simples de dsambigisation extraites de An Gramadoir dont la structure est prsente dans le point suivant. Nous avons enfin rdig quelques phrases pour tester le dsambiguseur. Ce sont des phrases elles aussi trs simples, mais qui ont la particularit de gnrer de nombreuses fausses alarmes lors de la dtection des fautes, du fait de la mauvaise, ou plutt de l'absence de dsambigusation. Ces trois fichiers ont permis Mikowski d'implanter trs rapidement un dsambiguseur oprationnel pour le franais. Notre travail d'importation des rgles de An Gramadir en a t facilit. Il en est de mme quant la rdaction ultrieure de nouvelles rgles. Sans ce nouvel outil, nous aurions t obligs de contourner les ambiguts en grant des exceptions au sein des rgles d'erreurs, qui auraient alors t beaucoup plus complexes et sans doute moins efficaces.
De manire gnrale, le mot ambigu et ses tags sont entours des balises <B></B>, son contexte, droit ou gauche, est entour de balises indiquant sa catgorie, et la partie droite de la rgle, isole par ":", prcise le tag appliquer. Pour rcrire les rgles en XML, nous devons donc pouvoir indiquer quel est le mot ambigu, de quoi est constitu son contexte immdiat, et quel est le tag appliquer pour supprimer ou rduire l'ambigut. Nous avons choisi de garder une structure aussi proche que possible de celle dj utilise pour les rgles d'erreurs. Redonnons en exemple la structure de la rgle prsente au point 3.2.2 du chapitre 1 :
28
Pour les rgles de dsambigusation, nous avons modifi cette structure de la manire suivante :
Les attributs mark_to et mark_from , permettant d'indiquer l'emplacement de l'erreur, ont simplement t remplacs par mark. Cet attribut de <pattern> permet de dsigner le mot qui est ambigu. Mark="0" indique que c'est le premier token du <pattern> qui doit tre dsambigus. Les lments <message> et <example> ont t supprims car il n'y a pas d'information renvoyer l'utilisateur. Un lment <disambig> a t ajout. Il contient la nouvelle tiquette appliquer au mot ambigu, la place de celles qu'il possde dj.
Voici la reprsentation que nous obtenons de la rgle de dsambigusation donne en exemple plus haut :
<rule name="dt fem sing ambigu + nom" id="DET_AMBIG_NOM"> <pattern mark="1"> <token postag="D f s"/> <token postag="N.*" postag_regexp="yes"/> </pattern> <disambig postag="D f s"/> </rule>
Le token dsign comme ambigu par l'attribut mark du pattern est le dterminant D f s . Certains dterminants peuvent en effet avoir aussi une tiquette "Nom", "Adjectif", ou encore "Pronom personnel objet". La rgle indique que si le dterminant est suivi d'un nom quelconque ("N.*"), il doit alors prendre le tag : dterminant fminin singulier ("D f s"). Ainsi, dans la phrase "la fuite est rpare", cette rgle peut dsambiguser la, qui a 3 tiquettes possibles ("nom fem. sing.", "pronom pers. obj. 3me pers. fem. sing.", "dt. fem. sing.") et lui donner le tag de dterminant fminin singulier ("D f s").
29
Comme nous l'avons mentionn dans le chapitre 1, Lechelt (2005) a dfini trois types de rgles de dsambigusation (particulires, par dfaut, brutes), dont l'ordre d'apparition a une grande importance. Nous avons donc cr notre fichier de rgles en XML en essayant de conserver cet ordre.
L'attribut skip dans une balise <token> dfinit le nombre de mots qui peuvent tre facultativement ignors avant de trouver le token suivant. Cet attribut nous a permis de runir plusieurs rgles en une seule. Par exemple, les 3 rgles de la ngation permettant de dsambiguser pas dans An Gramadir :
ont pu tre rduites une seule rgle, en indiquant qu'un maximum de 2 mots pouvait tre ignors entre ne et pas :
<pattern mark="1"> <token regexp="yes" skip="3">ne|n</token> <token regexp="yes">pas|point|plus|jamais</token> </pattern> <disambig postag="A"/>
Nous avons ainsi galement tendu la rgle point, plus et jamais. Grce la possibilit d'utiliser l'oprateur logique "OU" dans les expressions rgulires, nous avons regroup d'autres rgles proches. Par exemple, An Gramadir contient deux sries de rgles du type :
Nous les avons runies pour ne faire qu'une seule srie de rgles : Dterminant ambigu + Nom OU Adjectif = Dterminant
30
Dans sa toute premire version, le dsambiguseur fonctionnait en remplaant tous les tags du mot ambigu par le nouveau tag indiqu par <disambig> . Cette mthode avait l'inconvnient de nous obliger crire une rgle pour chaque combinaison possible dans un tag. Par exemple, les combinaisons genre-nombre des tags de dterminants, noms ou adjectifs :
une rgle pour "Dterminant masculin singulier" une deuxime rgle pour "Dterminant masculin pluriel" une troisime rgle pour "Dterminant masculin invariable" etc. Dans certains cas, il aurait t utile de pouvoir filtrer les mauvais tags en conservant les bons, au lieu d'effectuer un remplacement de tous les tags par celui indiqu dans <disambig>, ce qui nous permettrait de rduire le nombre de rgles. Nous avons expos notre problme Mikowski, qui a rapidement modifi le fonctionnement de l'outil selon nos indications. Grce l'ajout d'un lment match dans la balise <disambig> , il est dsormais possible de rcuprer les tiquettes du mot ambigu et de lui rattribuer uniquement les bonnes. L'outil agit donc comme un filtre, qui permet de retirer les mauvais tags tout en conservant les bons. Mais il est aussi toujours possible d'utiliser la premire mthode, celle du remplacement. Grce cette modification de l'outil, nous avons encore rduit considrablement le nombre de rgles en les gnralisant. Il n'tait en effet plus ncessaire d'avoir une rgle pour chaque combinaison. Ainsi, nous avons par exemple exprim dans une rgle unique les rgles pour dsambiguser les noms, qui taient au nombre de 9 dans An Gramadir (toutes les combinaisons avec masculin, fminin ou picne, et singulier, pluriel ou invariable).
<rule name="RB : noms" id="RB:NOMS"> <pattern mark="0"> <token postag="N.*" postag_regexp="yes"/> </pattern> <disambig> <match no="1" postag_regexp="yes" postag="N.*"/> </disambig> </rule>
Dans cette rgle, lorsque le dsambiguseur rencontre un mot qui a un tag "nom", l'lment match rcupre les informations compltes de ce tag (catgorie, genre et nombre), et les applique au mot pour le dsambiguser. Ainsi, bien qu'ils aient des genres et nombres diffrents, les noms farfadet et btises seront tous deux dsambiguss par cette mme rgle, qui leur redonnera respectivement leur tag "N m s" et "N f p".
31
b) Autres modifications
Ajout de rgles Les petits tests de contrle que nous avons raliss au fur et mesure nous ont conduit effectuer quelques ajustements. Il nous est par exemple apparu ncessaire d'ajouter quelques rgles. Nous avons complt les rgles sur les pronoms personnels objet en ajoutant les cas de l', le, la, les et lui.
Aux rgles sur les verbes, nous avons ajout le cas de l'imparfait aux 1re et 2me personnes du singulier, ainsi que le cas du conditionnel prsent aux 1re et 3me personnes du singulier. Nous avions en effet de fausses dtections d'erreurs dues aux ambiguts entre ces personnes ces temps et mode.
Nous avons aussi ajout une rgle provisoire pour attribuer un tag aux nombres. Ceux-ci ne sont en effet pas tiquets par le tagger car ils ne figurent pas dans le lexique. Un travail ultrieur sur ce lexique sera ncessaire pour le corriger et le complter, afin que cette rgle n'ait plus lieu d'tre.
Modification de rgles Nous avons ensuite modifi quelques rgles afin d'augmenter un peu leur couverture, car nous avions remarqu que des ambiguts n'taient pas leves dans certains cas : Nous avons ajout la possibilit de trouver la particule ne de la ngation entre deux pronoms personnels, car dans le cas de phrases ngatives, les rgles de dsambigusation des pronoms personnels objet ne pouvaient pas s'appliquer.
Les rgles sur les deux pronoms personnels sujet nous et vous ne permettaient de dsambiguser les pronoms que s'ils taient suivis d'un verbe. Or, ils peuvent tout aussi bien tre suivis par un adverbe ("nous ne sommes pas ...") ou par un pronom personnel objet ("nous les avons quitts"). Pour que la dsambigusation soit effectue dans plus de cas, nous avons donc modifi les rgles en question, en faisant suivre nous et vous par un verbe, un adverbe ou un pronom personnel objet.
Dplacement de rgles Aprs l'importation des rgles, nous avons remarqu que certaines d'entre elles ne s'appliquaient pas, car le mot avait dj t dsambigus auparavant, par une rgle plus gnrale. Les rgles sur les verbes ambigus prcds d'un pronom personnel sujet taient dans ce cas. Lorsque un verbe tait ambigu avec un nom, une premire rgle lui donnait par dfaut l'tiquette "Nom", et il ne pouvait alors plus tre identifi comme un verbe prcd d'un pronom par une rgle suivante. Pour rsoudre ce problme, nous avons dplac les rgles sur les verbes conjugus avant les rgles sur l'ambigut nom-verbe.
Nous avons aussi hsit intervertir deux rgles : 1. Dterminant + Nom ambigu = Nom 2. Dterminant + Adjectif ambigu + Nom = Adjectif
32
Le problme est qu'un trs grand nombre de mots ont les deux tiquettes "Nom" et "Adjectif", et en franais, bien que les adjectifs soient gnralement placs aprs le nom, il arrive aussi frquemment qu'ils se trouvent avant. En effet, dans (Tesnires, 1959) le franais est class parmi les langues centrifuges mitiges, dans lesquelles les adjectifs sont majoritairement postposs. En cas d'ambigut, la premire rgle attribue automatiquement le tag "Nom" au mot qui suit le dterminant. Nous perdons alors tous les cas o l'adjectif est antpos. Si nous intervertissons les deux rgles, supposer que le nom soit lui aussi ambigu avec un adjectif, nous perdons dans ce cas les adjectifs postposs. Finalement, aprs avoir compar la dsambigusation dans les deux cas, il est apparu que les rsultats taient lgrement meilleurs en intervertissant les rgles. Nous avons donc modifi leur ordre initial, tout en restant conscients qu'il faudra raliser des tests plus complets, pour valuer rellement l'incidence d'une telle modification sur la dsambigusation.
a t automatiquement rcrite en :
<rule> <pattern> <token postag="D .* s" postag_regexp="yes"/> <token postag="J .* s" postag_regexp="yes"/> <token postag="N .* p" postag_regexp="yes"/> </pattern> <message>Il y a une erreur d'accord en nombre</message> <example type="correct">exemple correct</example> <example type="incorrect">exemple incorrect</example> </rule>
Les balises <message> et <example> des rgles sur les syntagmes verbaux ont ensuite t personnalises, et les patterns quelquefois modifis.
33
a) Le pattern
Les rgles d'erreurs qui s'appliquent aux syntagmes verbaux concernent principalement l'accord entre le pronom personnel et le participe pass ou l'adjectif, aprs l'auxiliaire tre, l'accord entre le pronom personnel et le verbe, et les confusions dans l'utilisation des diffrentes formes verbales. Tout comme dans les rgles de dsambigusation, nous avons pu gnraliser quelques rgles et effectuer certains regroupements. Nous avons tout d'abord remplac chaque pronom personnel sujet par son tiquette. Cela nous a permis de traiter il et on avec la mme rgle, sur l'accord du participe pass ou de l'adjectif, puisqu'ils sont tous deux taggs "masculin singulier". Dans les rgles d'accord avec le verbe, nous avons galement ainsi group il, elle et on d'une part, et ils et elles d'autre part. Nous avons d'ailleurs en mme temps complt ces rgles puisque le cas des fminins elle et elles n'taient pas traits par An Gramadir. Le cas de l'lision de je qui devient j' n'tait pas non plus pris en compte. Nous avons remdi ce problme en gnralisant la rgle sur je tout pronom personnel sujet 1re personne du singulier.
Nous avons ensuite pu runir plusieurs rgles. Dans An Gramadir, il faut par exemple 4 rgles pour dire qu'il y a une erreur si :
je est suivi d'un mot quelconque, puis d'un verbe la 1re personne du pluriel
[Jj]e ANYTHING <VUNP>ANYTHING</VUNP>:AGGREEMENT
je est suivi d'un mot quelconque, puis d'un verbe la 2me ou 3me personne
[Jj]e ANYTHING <VUN>ANYTHING</VUN>:AGGREEMENT
Tout comme dans les rgles de dsambigusation, nous avons ici utilis l'attribut skip pour autoriser un mot facultatif entre le pronom personnel et le verbe, et pour ainsi viter d'avoir rdiger plusieurs rgles.
34
Nous avons aussi runi deux rgles qui concernaient l'accord du pronom personnel sujet, soit avec le participe pass aprs l'auxiliaire tre, soit avec l'adjectif aprs l'auxiliaire tre. Nous avons juste utilis l'oprateur logique "OU" pour que la rgle s'applique au participe pass OU l'adjectif. Ainsi : Pronom personnel sujet + tre + adjectif et Pronom personnel sujet + tre + Participe pass ont pu tre exprims dans une seule rgle : Pronom personnel sujet + tre + Participe pass OU Adjectif Nous avons finalement rduit 15 le nombre des rgles d'erreurs sur les groupes verbaux, qui tait de 62 dans An Gramadir, tout en augmentant leur couverture, ce qui nous permet de dtecter plus de fautes ventuelles. Une fois les patterns des rgles bien dfinis, nous avons spcifi pour chacun les attributs mark_from et mark_to, permettant l'affichage prcis de la faute lors de la correction.
3.2.3. Rcriture des rgles sur les syntagmes nominaux a) De rgles trs nombreuses
Les rgles sur les groupes nominaux sont trs nombreuses (environ 450). Les lments sur lesquels elle portent - dterminants, noms et adjectifs peuvent se combiner de diffrentes manires. Ils peuvent tre masculin, fminin ou picne et singulier, pluriel ou invariable, et tre pour certains en quantit variable (les adjectifs principalement). Les combinaisons d'erreurs possibles deviennent alors vite trs nombreuses. Si nous reprenons le jeu d'tiquettes cr par Lechelt (2005) pour an An Gramadir, savoir D pour dterminant, N pour nom et J pour adjectif, nous avons alors des rgles pour toutes les combinaisons suivantes :
D J J N J J - D J N J J - D J J N J - D J N J - D N J J - D J J N D J N - D N J - DN
De plus, les rgles de An Gramadir prennent galement en compte les nombres, taggs Y. Nous avons donc les combinaisons suivantes qui viennent se rajouter aux premires :
D Y J J N - D Y N J J - D Y J N - D Y N J - D Y N - Y J N - Y N
Nous avons conserv les rgles telles que rcrites par notre programme en Python, sans en modifier le pattern comme nous l'avons fait pour les rgles sur les syntagmes verbaux, puisqu'il n'y avait pas de regroupement possible. Nous n'avons pas non plus personnalis les attributs mark_from et mark_to, ni les exemples,
35
car cela aurait pris normment de temps, et comme nous allons le voir par la suite, nous n'allons pas conserver ces rgles dans leur structure actuelle. Pour tester les rgles et savoir si elles dtectent bien les erreurs, il nous suffisait d'avoir des patterns bien dfinis. Nous n'avions pas besoin des exemples ou des messages. Nous avons simplement crit deux messages par dfaut qui couvrent eux deux tous les types de fautes : "Il y a une erreur d'accord en nombre" et "Il y a une erreur d'accord en genre".
Nous avons fait la mme rgle pour traiter l'accord en genre. Un dterminant, un nom, ou un adjectif masculin ne peut pas tre suivi ou prcd d'un dterminant, d'un nom ou d'un adjectif fminin. Les patterns de ces 2 rgles sont les suivants :
<pattern> <token postag="D m .*|J m .*|N m .*" postag_regexp="yes"/> <token postag="J f .*|N f .*" postag_regexp="yes"/> </pattern> <pattern> <token postag="D m .*|J m .*|N m .*" postag_regexp="yes"/> <token postag="J f .*|N f .*" postag_regexp="yes"/> </pattern>
36
Avec seulement ces 4 rgles gnrales, nous obtenons des rsultats assez proches des 450 rgles dtailles, et nous n'avons plus de dtection multiple. En revanche, certaines erreurs ne sont pas dtectes, et nous ne traitons pas le cas des nombres. Nous garderons cependant ces rgles gnrales la place des rgles initiales, car les dtections multiples provoques par ces dernires peuvent tre trs gnantes pour l'utilisateur. D'autre part, le traitement de 450 rgles est bien plus lourd, pour le programme et pour nous-mme. En effet, nous ne pouvions pas personnaliser plusieurs centaines de rgles, mais nous avons pu le faire trs rapidement pour les 4 rgles ci-dessus.
Nous avons analys les diffrents types d'erreurs commises, nous les avons classs, et en avons extrait quelques uns pour lesquels nous pensions pouvoir crer de nouvelles rgles. Les exemples de fautes que nous donnons dans la suite de ce mmoire sont issus du corpus.
37
38
Verbe la 1re ou 2me personne aprs le pronom relatif : "*...ce journal qui nous permets...", "*...un homme qui parcours...", "*...ce qui distingues..." Mots homophones sont confondus : "*...ont a tendance...", "*En temps qu'agent...", "*C'est phrase veut dire...", "*...cette une tendue d'herbe..."
Forme nominale confondue avec la forme verbale : "*...on dsir...", "*...je travail...", "*...on l'envoi..."
Verbe mal accord avec un syntagme nominal simple (dt + nom), en dbut de phrase : "*Le monde m'appartenais...", "*Les femmes aurait tendance...", "*Leurs charges s'lve..."
Mot venant ventuellement s'intercaler entre le verbe conjugu et le verbe qui doit tre l'infinitif : "*...n'a pas pu lui amen...", "*Je viens vous propos...", "*...il faut peut-tre pay..."
Ces quelques erreurs font partie des plus frquentes que nous avons releves dans le corpus. Il y a d'autres types de faute pour lesquels nous n'avons trouv que trs peu d'occurrences, et que nous n'allons pas traiter dans un premier temps. Par la suite, ces fautes pourront faire l'objet de rgles qui dtecteront des cas assez particuliers.
Cette rgle s'applique ds qu'elle rencontre un dterminant en dbut de phrase, suivi d'un nom singulier, puis de tout verbe qui n'est pas la 3me personne du singulier. En remplaant s par p, nous obtenons la rgle pour le cas contraire, c'est--dire lorsque le sujet au pluriel est suivi d'un verbe qui n'est pas la 3me personne du pluriel. Cette rgle fonctionne, mais nous voyons toutefois qu'elle est limite un cas bien prcis. Si une phrase est ngative, si le syntagme nominal contient un adjectif ou un adverbe, ou bien encore si un complment d'objet vient s'intercaler entre le sujet et le verbe, une faute ventuelle ne pourra plus tre dtecte.
39
Avec cette rgle, un participe pass ou un adjectif au pluriel ne peuvent pas suivre l'auxiliaire tre au singulier. Nous avons galement cr la rgle inverse, avec l'auxiliaire au pluriel. Nous avons d ajouter une exception, pour tenir compte de tous les cas de formes passives ("* ont t construit") qui gnraient du bruit ou du silence dans la dtection. En effet, t correspond l'expression rgulire du premier token de la rgle, et donc tout participe pass au pluriel qui le suit est dtect comme faux. Dans la forme errone "* ont t construit", la faute n'tait donc pas signale. Dans le mme exemple, mais cette fois sans erreur, "ont t construits", une faute tait signale tort.
Nous avons essay d'tendre un peu sa couverture, afin que la prsence de la ngation, ou d'un pronom personnel objet ventuels entre le pronom et le verbe, par exemple soit prise en compte . Mais nous obtenions alors beaucoup de fausses alarmes. Nous avons donc conserv la rgle telle quelle, bien qu'elle ait une couverture trs limite.
Si ont est suivi d'un verbe qui n'est pas au participe pass, il est trs probable qu'il s'agisse d'une confusion avec on.
40
Nous voulions que la rgle s'applique lorsqu'elle trouvait cet ou cette suivis d'un dterminant. Mais un problme li l'tiquetage, faisait que la rgle ne marchait pas. En effet, les confusions que nous avons pu relever, entre les mots que nous traitons ici, avaient lieu uniquement lorsque le dterminant tait un ou une. Or, lors de la dsambigusation, lorsqu'ils sont prcds d'un autre mot tiquet "dterminant" (ici cet ou cette), un et une sont eux tiquets "adjectif" au lieu de "dterminant". La rgle est alors sans effet. Nous l'avons donc rendue plus prcise afin qu'elle fonctionne. Pour traiter le cas contraire, c'est dire le cas o c'est est utilis la place de ces, cet ou cette, nous avons cr une rgle un peu moins particulire que la prcdente. Elle s'applique c'est suivi d'un nom quelconque.
<pattern mark_to="-1"> <token skip="1">c</token> <token>est</token> <token postag="N.*" postag_regexp="yes"/> </pattern>
41
Nous n'avons pas rdig plus de nouvelles rgles. Les ajouts raliss nous ont fait prendre conscience de la difficult de crer des rgles simples permettant de traiter un grand nombre de fautes. Ils nous a fallu quasi systmatiquement limiter la porte de chacune des rgles pour viter les fausses alarmes, et nous ne traitons ainsi qu'une partie des fautes vises. En fait, dans la majorit des cas, plusieurs rgles seraient ncessaires pour dtecter toutes les fautes d'un certain type.
D J J N J J - D J N J J - D J J N J - D J N J - D N J J - D J J N - D J N - D N J - DN DYJJN-DYNJJ-DYJN-DYNJ-DYN-YJN-YN
42
Les fautes suivantes, par exemple, sont toutes traites par LanguageTool : "* vos unit" "* du bureaux" "* un certaine ge" "* des grandes capacit linguistique" "* nos salutations distingus" Les rgles qui concernent ce type d'erreurs sont trs nombreuses, mais elles sont loin de couvrir toutes les situations, c'est--dire toutes les combinaisons possibles au sein d'un groupe nominal. Elles ne tiennent par exemple pas compte de l'existence de mots picnes ou invariables. Si l'un de ces mots se trouve dans un groupe nominal mal accord, l'erreur ne sera pas dtecte, aucune rgle ne correspondant au modle de la faute. D'autre part, la prsence ventuelle d'adverbes n'est pas non plus prise en compte.
Une rgle permet galement de signaler un verbe qui suit une prposition et qui n'est pas l'infinitif : "* pour remplacs" "* dans l'attente de vous rencontrez" "* nous aimerions en parlaient" Cette rgle gnre du bruit car en est souvent suivi d'un verbe au participe prsent, qui est dtect comme faux puisque ce n'est pas un infinitif.
Un participe pass au singulier aprs un auxiliaire tre au pluriel est une faute d'accord en nombre qui est aussi dtecte, de mme que le cas inverse. Il est donc par exemple possible de signaler les erreurs suivantes : "* les caves sont pourri" "* ces diffrences en gnral son li au social" "* le prix est trs exagres"
Les participes passs sont souvent mal crits, et il est assez frquent de trouver une forme conjugue leur place, aprs un auxiliaire. Une rgle permet donc de grer des erreurs telles que : "* j'ai cris" "* il a vcut" "* j'ai entreprit".
Toutes ces rgles fonctionnent convenablement, mais aucune ne dtecte toutes les occurrences du type de faute qu'elle traite. Ds qu'une erreur diffre un peu du pattern de la rgle, celle-ci devient inefficace. Ce sera le cas si le segment o se trouve la faute contient un ou des mots non prvus dans le pattern. L'erreur dans "* ils vont entrs" sera signale, mais pas dans "* ils vont peut-tre entrs" par exemple.
43
Une autre srie de rgles s'applique lorsque les participes passs ou les adjectifs ne sont pas bien accords en genre et/ou en nombre avec les pronoms personnels sujets, comme ici : "* nous serons oblig" - "* nous ne sommes pas venu" "* ils se sont trouv"
Un dernier type de faute dtect est l'accord en nombre d'un groupe nominal simple, c'est-dire Dterminant + Nom, avec le verbe qui suit. Le verbe doit tre la 3me personne, du singulier ou du pluriel, en fonction du nombre du nom. "* Les femmes aurait tendance...", "* Leurs charges s'lve..."
44
principalement les accords entre les mots : dterminant et nom, nom et adjectif, sujet et verbe, sujet et participe-pass, etc. Elle dtermine donc, entre autres, les marques du pluriel ou du fminin, les dsinences de conjugaison, et implique de savoir identifier les rapports qu'entretiennent les mots d'une phrase afin de pouvoir les accorder. L'orthographe grammaticale concerne aussi les homophones grammaticaux, comme a et , on et ont, quelle et qu'elle, et bien d'autres encore. Pour le linguiste, si l'erreur se trouve au niveau du radical du mot, il s'agit gnralement d'une faute d'orthographe lexicale, mais si elle se situe dans la partie flexionnelle, nous parlons alors de faute d'orthographe grammaticale. D'un point de vue linguistique, "* toujoures" est donc du domaine du lexique, mais "* j'ai cris" et "* ils dorments" sont des erreurs grammaticales.
45
GRAMMAIRE
LINGUISTIQUE :
ORTHOGRAPHE
GRAMMAIRE
Exemples de fautes :
Figure 5: Chevauchement de l'orthographe et de la grammaire, en linguistique et en informatique Nous avons rencontr, dans le corpus, beaucoup de phrases dans lesquelles des fautes, sur les verbes en particulier, se situent dans la zone de chevauchement entre la grammaire et l'orthographe. Nous pouvons donner les exemples suivants : "* ...des jeunes rsidants dans d'autres quartiers...", "* je seraie intress...", "* ...tout le monde atteind le stade 4.", "* Il faut d'autres mthodes et remetrent en cause...", "* Vous comprendrer...". Les mots que nous avons mis en gras ci-dessus n'appartiennent pas au lexique, et ne peuvent donc pas tre tiquets par le tagger pour la vrification grammaticale. D'un point de vue informatique, ils sont du ressort d'un correcteur orthographique, au mme titre que * appercevoir, *himmeuble ou *velourt. En tant que linguistes, nous situons ces erreurs sur le plan de la grammaire. Elles n'ont pas en effet pour origine l'ignorance de la graphie du mot. Il s'agit ici, dans les exemples sur les verbes, d'un problme de comptence dans la formation des formes conjugues. Mais mme si ces fautes sont grammaticales d'un point de vue linguistique, nous ne pouvons pas les traiter comme telles avec des outils comme LanguageTool, ou tout autre correcteur grammatical.
46
analys ce type de fautes (Souque, 2006). Des lettres peuvent tre interverties, oublies, rajoutes, doubles ou encore substitues d'autres. Ainsi, il nous arrive par exemple frquemment de taper "ne" la place de "en", et vice-versa, "amis" la place de "mais", ou bien encore "* aps" au lieu de "pas", ou "* eereur" au lieu de "erreur". Lorsque ces fautes de frappe gnrent un mot dont la graphie n'appartient pas au lexique du correcteur orthographique, comme pour "* aps" ou "* eereur", celui-ci dtectera une faute d'orthographe. Cependant, d'un point de vue linguistique, nous pensons que ce type d'erreur ne fait partie ni de l'orthographe lexicale, ni de l'orthographe grammaticale. Il ne s'agit en effet pas d'un dfaut de connaissance dans la manire d'crire ou d'accorder un mot, mais plutt d'une erreur qui pourrait tre qualifie "d'inattention". Les fautes de frappe peuvent aussi aboutir l'criture de mots qui existent dans le lexique, mais qui ne sont pas ceux attendus. Ces mots tant corrects au niveau de la graphie, le correcteur orthographique ne peut pas les dtecter. En revanche, ils peuvent perturber l'analyse lors de la vrification grammaticale, et tre ainsi l'origine d'erreurs dans la dtection des fautes. Si nous crivons par exemple "amis" au lieu de "mais", le tagger va tiqueter le mot comme un nom, et non comme une conjonction de coordination. Tout l'tiquetage de la phrase risque alors d'tre erron, et la dtection des fautes en sera perturbe d'autant. D'un point de vue linguistique, nous pourrions considrer ce type de fautes comme de grammaire, ou plutt de syntaxe, puisqu'il s'agit de l'utilisation d'un mot erron la place d'un autre. Mais l encore, l'erreur n'a pas pour origine un problme de comptence au niveau de la langue. Il nous semble par ailleurs difficile de dtecter de telles fautes avec un correcteur grammatical. Nous pourrions crer une liste de rgles traitant les erreurs au cas par cas, comme celles qui existent pour les confusions d'homophones, mais nous ne pourrons jamais prvoir tous les contextes pour des fautes de ce type, et nous n'en traiterions qu'une petite partie.
6. Conclusion
Dans ce chapitre, nous avons prsent les prmisses de notre adaptation de LanguageTool la correction de la grammaire franaise. Nous avons tout d'abord voqu les problmes poss par l'absence de dsambigusation au sein de l'outil. Mikowski nous a aid y remdier en ralisant l'implantation d'un dsambiguseur, selon nos indications. Nous avons ainsi import toutes les rgles de dsambigusation et d'erreurs contenues dans An Gramadoir. Les rgles de dsambigusation ont t rcrites manuellement en XML, en utilisant une structure trs proche de celle des rgles d'erreurs. De plus, nous avons utilis les possibilits offertes par ce formalisme pour simplifier, grouper, modifier et complter ces rgles. Notons toutefois, qu'il sera ncessaire d'valuer cette dsambigusation. Les rgles d'erreurs, quant elles, ont t rcrite automatiquement en XML l'aide d'un petit programme en python que nous avons ralis. Puis nous les avons modifies, personnalises et beaucoup simplifies. Un corpus de fautes a ensuite t analys afin d'en extraire de nouvelles rgles, et complter ainsi la base existante. Pour que ces nouvelles rgles fonctionnent sans gnrer trop de bruit,
47
nous avons d les rendre relativement prcises. Chacune n'a donc finalement qu'une couverture assez rduite. Nous avons par ailleurs vu que les fautes ne peuvent tre dtectes qu' la condition de coller parfaitement au pattern de la rgle qui leur correspond. Nous avons ensuite numr les types d'erreurs que LanguageTool est dsormais capable de traiter, suite l'importation et l'augmentation des rgles. Nous en sommes alors venus voquer le chevauchement des fautes de grammaire et d'orthographe en linguistique et en informatique, ainsi que la typologie particulire des fautes du dactylographe. Dans le chapitre suivant, nous prsenterons un nouveau formalisme, fond sur des principes linguistiques, qui devrait permettre l'amlioration de la dtection des fautes.
48
49
Si nous crivons une rgle pour chaque combinaison errone contenant simplement un dterminant et un nom, dclins chacun aux trois nombres (singulier, pluriel, invariable) et trois genres (fminin, masculin, picne), nous obtenons 42 rgles d'erreurs. L'ajout d'un adjectif ces combinaisons fait passer ce nombre prs de 1200. Si maintenant nous prenons les rgles de Lechelt (2005), qui contiennent donc 1 dterminant, 1 nom, et de 0 4 adjectifs, et si nous calculons la quantit de combinaisons possibles en tenant compte des mots invariables et picnes, nous trouvons alors environ 670 700 possibilits ! Il va de soi que le systme ne pourrait grer un fichier contenant autant de rgles, qui ne seraient par ailleurs pas exhaustives, puisqu'il existe d'autres combinaisons que nous n'avons pas comptabilises. Nous pouvons en effet trouver des syntagmes nominaux contenant en plus des adverbes ou des nombres. Cette explosion combinatoire s'tend beaucoup d'autres rgles, notamment toutes celles qui concernent des syntagmes nominaux. Nous pouvons donner comme autre exemple la rgle que nous avons crite, concernant l'accord entre le verbe et un groupe nominal sujet constitu d'un dterminant et d'un nom. Nous avons dit que cette rgle est trs limite puisqu'elle ne concerne que les phrases qui suivent le modle "dterminant + nom + verbe (+...)". Avec le formalisme actuel de LanguageTool, si nous voulons une couverture maximale des fautes de ce type, nous devons crire presque autant de rgles que de combinaisons sujet-verbe. Or, rien que pour un simple groupe nominal sujet, nous venons de voir, avec l'explosion combinatoire des rgles, qu'il y a plusieurs centaines de milliers de combinaisons possibles. Et ce, sans tenir compte de tous les syntagmes qui peuvent venir se glisser entre le sujet et le verbe, comme les syntagmes prpositionnels par exemple : Les rgles [de grammaire] [de An Gramadir] [sur les syntagmes nominaux] sont trs nombreuses. Il est donc tout simplement impossible, en ce qui concerne les syntagmes nominaux, de rdiger des rgles pour tous les contextes d'erreur, sans nous heurter un problme d'explosion combinatoire des rgles.
50
51
Le pattern de la rgle dfinit donc le nombre de mots du contexte de l'erreur, et les caractristiques que chacun doit avoir. Tous les carts, qu'ils soient ds l'orthographe, l'tiquetage, l'ordre des mots ou bien leur nombre, peuvent conduire au silence de la rgle.
52
53
Les rgles sur les syntagmes nominaux, telles que Lechelt (2005) les avait cres, taient source de dtections redondantes. Nous avons dj vu que si nous crivions par exemple : "* un jupe longue bleue", l'erreur d'accord en genre entre le dterminant et le reste du syntagme tait signale 3 fois par 3 rgles diffrentes. Cet exemple ne se produit plus depuis que nous avons rcrit ces rgles en les gnralisant, mais il est fort probable que nous rencontrions d'autres cas. En effet, partir du moment o nous avons de nombreuses rgles pour couvrir le plus possible de fautes d'un type donn, il se peut que plusieurs rgles s'appliquent de manire redondante une mme faute.
Dans cet exemple, nous voyons qu'il n'y a en ralit qu'une seule vraie faute : la confusion entre on et ont. Le problme est que cette erreur conduit l'application d'autres rgles, dont les patterns s'appuient sur un contexte faux, savoir un contexte contenant ont. Ainsi, une faute de grammaire peut tre l'origine de dtections en cascade de plusieurs fausses erreurs. S'il tait possible de corriger les erreurs au fur et mesure, au lieu de tout vrifier d'un coup, beaucoup de bruit serait vit. Dans notre exemple, si la confusion entre on et ont pouvait tre corrige avant de vrifier la suite de la phrase, plus aucune erreur ne serait signale sur a.
54
55
nous dfinissons en fait un chunk nominal de manire implicite, qui commence au dbut de la phrase, et qui est constitu d'un dterminant et d'un nom. Il est donc possible de dfinir des syntagmes, mais ce ne peut tre que des chunks implicites, qui ne possdent pas la proprit de pouvoir tre dlimits en fonction de marqueurs de dbut et de fin. C'est pourtant grce cette proprit que le traitement des fautes pourra se faire sans avoir dcrire toutes les combinaisons de mots possibles. Nous nous retrouvons alors avec le problme du pattern-matching, dont nous avons parl dans le point prcdent sur les limites du formalisme de LanguageTool. Il faut prvoir toutes les combinaisons de mots qui peuvent constituer un chunk pour dfinir celui-ci. Si cela peut tre envisageable dans certaines langues, a ne l'est pas pour le franais. Il faudrait donc complter le formalisme de LanguageTool avec un vritable chunker, qui permette de dfinir des syntagmes avec toutes les proprits des chunks et les traits morphosyntaxiques ncessaires par la suite pour l'unification.
56
caractristiques morphosyntaxiques. Selon la catgorie du mot, elles sont constitues des traits de genre, de nombre, de personne, de temps, de mode, etc. Lorsque deux traits identiques sont dfinis dans deux tiquettes et qu'ils n'ont pas une valeur diffrente, nous disons qu'ils s'unifient, ou plus prcisment, que l'unification retourne "vrai". Par exemple, si deux tags ont chacun le trait "genre=masculin", ces deux traits s'unifient. En revanche, si un tag a le trait "genre=masculin" et l'autre le trait "genre=fminin", l'unification choue, car les valeurs ne sont pas identiques. Ce principe d'unification de structures de traits permet donc de vrifier l'accord entre deux lments.
57
58
de corriger certains mots, avant la vrification grammaticale, permettrait d'viter des problmes d'tiquetage, qui conduisent ensuite de mauvaises dtections de fautes de grammaire.
Entre les balises <rule></rule>, nous avons ensuite les lments du niveau infrieur : pattern, unify, message, example.
59
<feature +>
genre nombre temps mode pers type fonction cat inflected regexp negate
<chunk +>
cat negate skip
(3.1.7)
(3.1.9)
<feature +>
genre nombre temps mode pers type fonction
(3.1.9)
<exception +>
<pattern>
mark_from mark_to
(3.1.5)
(3.1.8)
<rule +>
ID name
(3.1.1)
(3.1.9)
<feature +>
genre nombre temps mode pers type fonction
(3.1.9)
<unify>
chunk token feature
(3.1.4)
(3.1.6)
<exception +>
(3.1.8)
<message>
(3.1.3)
<suggestion +>
(3.1.3)
<example +>
type
(3.1.2)
<marker +>
(3.1.2)
Figure 6: Description d'un nouveau formalisme pour la correction grammaticale dans LanguageTool Cette figure illustre la hirarchie des lments du formalisme que nous dcrivons. Chaque cadre reprsente un lment, dont le nom est indiqu entre balises. Le signe "+" qui apparat parfois, signifie qu'il peut y avoir plusieurs occurrences de l'lment. Ainsi, <rule> contient un seul <pattern>, mais peut avoir plusieurs <example>. Les listes de mots en italique dans certains cadres constituent les attributs que chaque lment peut avoir. Pour finir, les cadres dont le fond est blanc correspondent des lments qui sont falcutatifs et sont employs occasionnellement. Ils sont pour cela relis en pointills l'lment de niveau suprieur. Sous chaque cadre figure le numro de la section o nous le traitons.
60
61
Avec l'exemple ci-dessus, ce sont, dans le motif, les lments situs entre le premier (mark_from="1") et le dernier (mark_to="-1") qui seront affichs l'utilisateur. Ces lments peuvent tre des chunks ou des tokens. Dans les balises <pattern></pattern>, nous trouvons les lments du niveau infrieur : <token> et <chunk>.
Dans l'exemple que nous donnons ci-aprs, le motif recherch est constitu du nom "appartement" ou "logement", d'un ventuel mot quelconque, puis du verbe "louer", quelle que soit sa forme :
62
<token> contient galement un ou plusieurs lments <feature>, pour dfinir les traits morphosyntaxiques des mots, et <exception>.
Tout comme <token>, <chunk> contient galement un ou plusieurs lments <exception>, et surtout <feature> pour dfinir ses traits morphosyntaxiques. En effet, pour que l'unification puisse avoir lieu entre les chunks, nous leur avons attribu des traits. Ainsi, un syntagme nominal a les mmes traits "genre" et "nombre" que la tte lexicale qu'il contient, et il possde en plus le trait de personne "pers" pour l'unification avec les verbes. Un syntagme verbal contient un trait indiquant s'il s'agit du verbe principal, d'un verbe infinitif, du verbe d'une relative, etc. Cette distinction est utile pour savoir quel syntagme accorder avec le sujet.
63
Si nous le comparons avec l'tiquetage actuel de LanguageTool, nous pouvons constater que celui que nous proposons est plus facile lire, comprendre et donc utiliser :
<S> les [les/D e p] gens [gens/N e p] qui [qui/R rel m p] l' [qui/R pers obj 1 m s] entourent [entourent/V ind pres 3 p] . [./M fin, </S>]
L'lment <feature> permet donc de dcrire les caractristiques morphosyntaxiques en utilisant les proprits XML. Il possde pour cela des attributs du noms des diffrents traits possibles : genre prend pour valeur "m" (masculin), "f" (fminin) ou "e" (picne) nombre prend pour valeur "s" (singulier), "p" (pluriel) ou "sp" (invariable) temps prend pour valeur "pres" (prsent), "futu" (futur), "impa" (imparfait) ou "psim" (pass simple) mode prend pour valeur "ind" (indicatif), "sub" (subjonctif), "con" (conditionnel), "imp" (imparfait), "inf" (infinitif), "ppr" (participe prsent) ou "ppa" (participe pass) personne prend pour valeur "1" (je/nous), "2" (tu/vous) ou "3" (il/ils/etc.) fonction prend pour valeur "suj" (sujet) ou "obj" (objet) type prend pour valeur : pour les pronoms : "rel" (relatif), "pers" (personnel), "dem" (dmonstratif), "refl" (rflchi) ou "inte" (interrogatif) pour les conjonctions : "sub" (subordination) ou "coor" (coordination) pour les chunks verbaux : "ppal" (verbe principal), "sub" (verbe d'une subordonne)
Chapitre 3 : Amlioration du formalisme de LanguageTool Voici un exemple d'utilisation de l'lment <feature> et de ses attributs :
<rule> <pattern> <chunk> <feature genre="m" nombre="s"/> </chunk> <chunk> <feature type="ppal"/> </chunk> </pattern> <unify/> <message>...<suggestion>...</suggestion>...</message> <example>...<marker>...</marker>...</example> <example>...</example> </rule>
64
65
En effet, grce aux balises dlimitant les chunks, il est possible de rechercher directement des groupes de tokens, au lieu de faire du mot mot. Pour trouver un syntagme nominal, il n'est ainsi plus ncessaire de prvoir les milliers de combinaisons de dterminants, noms et adjectifs possibles. Il suffit simplement par exemple d'identifier les balises <SN> et </SN> dans la phrase. Le principe gnral de fonctionnement reste donc le mme, par rapport celui de LanguageTool. Outre l'ajout d'une fonction d'unification, les diffrences apportes par notre formalisme sont surtout au niveau de la description des tiquettes. En effet, en utilisant le langage XML et en spcifiant le nom de chaque trait, le nouveau formalisme facilite la comprhension des tags par l'interprteur et permet l'unification. Les rgles qui ne s'appliquent pas des fautes d'accords sont interprtes comme dans LanguageTool actuellement. Si la correspondance exacte entre les motifs de la rgles et du texte est vrifi, le moteur de correction affiche le message d'erreur l'utilisateur. Seule la manire de lire les tiquettes change, puisque le formalisme de ces tiquettes a lui-mme chang. En revanche, l'interprtation des rgles sur les fautes d'accords est diffrente. Ces rgles intgrent l'lment <unify>, qui appelle un module de calcul d'unification. Celui-ci teste alors l'unification, selon les arguments donns sous formes d'attributs de l'lment. Ces arguments sont : le type d'lment qui doit tre unifi : des syntagmes (chunk="yes") ou des tokens (token="yes"), les traits prendre en compte pour cette unification, lists dans l'attribut feature.
Dans l'exemple suivant, l'interprteur tentera d'unifier les traits "genre" et "nombre" des tokens que contient le syntagme nominal dans le <pattern>.
<rule> <pattern> <chunk cat="SN"/> </pattern> <unify token="yes" feature="genre|nombre"/> ... </rule>
L'unification des lments du pattern s'effectue de manire trs simple. Il suffit l'interprteur de comparer les valeurs des traits spcifis en arguments. En cas de valeurs diffrentes pour un mme trait, la fonction d'unification renvoie "faux". Cela entrane l'affichage l'utilisateur du message et des exemples dfinis dans la rgle. Pour illustrer l'interprtation du formalisme, prenons en exemple la rgle suivante :
<rule> <pattern> <chunk cat="SN"/> </pattern> <unify token="yes" feature="genre|nombre"/> <message>Les mots du syntagme ne sont pas bien accords</message> <example type="correct">des grandes capacit linguistique</example> <example type="incorrect">d'normes craintes</example> </rule>
Chapitre 3 : Amlioration du formalisme de LanguageTool Supposons ensuite que le syntagme suivant appartienne une phrase tiquete du texte : <SN genre="f" nombre="s"> nombre="s">phrase</N></SN> <D genre="m" nombre="s">un</D> <N
66
genre="f"
Lorsque le moteur de correction parcourt le texte, il rencontre le chunk nominal ci-dessus, qui correspond au motif de la rgle. Cette dernire est donc active. Elle contient l'lment <unify> qui appelle alors la fonction d'unification. Les attributs de cet lment indiquent que l'unification doit se faire entre les tokens du syntagme nominal dcrit dans le motif. Elle doit par ailleurs se faire entre les traits "genre" et "nombre". L'interprteur trouve les traits "genre" et "nombre" pour les deux tokens qui constituent le syntagme. Il compare alors leurs valeurs. Pour le trait "nombre", elles sont identiques. En revanche, pour le trait "genre", une vaut "m" et l'autre "f". Ces valeurs n'tant pas identiques, la fonction renvoie donc "faux". L'interprteur peut alors afficher l'utilisateur le message de la rgle : "Les mots du syntagme ne sont pas bien accords." ainsi que les deux exemples.
3.3.1. Pr-requis
Pour pouvoir tester cet outil d'unification, nous avions besoin de phrases tiquetes en XML, tel que nous l'avons dfini dans le formalisme, dans le point 3.1.8. de ce chapitre :
<D <N <R <R <V <M genre="e" nombre="p">les</D> genre="e" nombre="p">gens</N> type="rel" genre="m" nombre="p" >qui</R> type="pers" fonction="obj" pers="3" genre="e" nombre="s">l'</R> temps="pres" mode="ind" pers="3" nombre="p">entourent</V> fin="no">.</M>
Comme nous ne disposions pas de tagger prenant en charge des tags en XML, nous avons tiquet nous-mme quelques phrases la main. Mais par la suite, nous aurons bien sr besoin d'un tagger capable de grer les tiquettes sous forme de balises. Nous avions aussi besoin de phrases segmentes en chunks, puisque c'est sur eux que se fonde l'unification. N'ayant pas encore de chunker, nous avons galement procd manuellement cette segmentation des phrases que nous avions tiquetes. Pour dlimiter les syntagmes, nous avons naturellement utilis des balises XML, comme pour les tags. Nous avons dfini principalement des chunks nominaux (SN), verbaux (SV), et prpositionnels (SP). Pour cela, nous avons utilis leurs proprits respectives : le syntagme nominal commence par un dterminant, le syntagme prpositionnel par une prposition, et le syntagme verbal par un verbe, un pronom personnel, ou la ngation.
Chapitre 3 : Amlioration du formalisme de LanguageTool Voici un exemple de la segmentation que nous obtenons pour la phrase "*Il vit avec les gens qui l'entoure" :
67
<SV type="ppal"> <R type="pers" fonction="suj" pers="3" nombre="s"> Il</R> <V aux="avoir" mode="ind" temps="pres" pers="3" nombre="s">vit</V> </SV> <SP> <P>avec</p> <D genre="e" nombre="p">les</D> <N genre="e" nombre="p">gens</N> </SP> <R type="rel" genre="e" nombre="p" > qui</R> <R type="pers" fonction="obj" pers="3" genre="e" nombre="s"> l'</R> <SV type="rel"> <V temps="pres" mode="ind" pers="3" nombre="s">entoure</V> </SV> <M fin="yes">.</M>
Dans cet exemple, nous voyons qu'il y a deux chunks verbaux. Le premier, le principal, inclut le pronom personnel sujet, avec lequel la dpendance est trs forte. Le second est li au pronom relatif qui, qui constitue un chunk lui tout seul.
68
et
<SV type="ppal"> <V mode="ind" temps="pres" pers="3" nombre="p">sont</V> <V mode="ppa" genre="f nombre="p">leves</V> </SV>
Dans chaque chunk, nous avons ensuite des lments (dterminants, noms, etc.). Pour les trouver, de la mme manire que pour les syntagmes, il faut rechercher les motifs "<" et "</.>"4. Avec le syntagme nominal ci-dessous, nous obtenons les 2 lments suivants :
<D genre="e" nombre="p">Les</D>
et
<N genre="f" nombre="p">charges</N>
Les lments contiennent leur tour des traits ( genre="m", pers="3", etc.). Pour les reprer, l'expression rgulire isole les chaines de caractres qui sont prcdes par un espace et suivies, soit par un espace, soit par la balise de fin ">". Ce qui nous donne, avec le premier lment ci-dessus : genre="e" et nombre="p" Enfin, le nom et la valeur, qui sont le niveau le plus bas, sont spars, toujours par expression rgulire. Pour le nom du trait, le motif recherch commence au dbut de la chaine genre="e", et se termine juste avant le caractre "=". La valeur est repre par les guillemets qui l'entourent. Une fois tous les chunks, lments, traits, noms et valeurs isols et stocks, le programme peut s'en resservir facilement, sans avoir parcourir le texte chaque fois pour rechercher des motifs.
b) Vrification "intra-chunk"
Dans les syntagmes nominaux et prpositionnels, les traits unifier sont le genre et le nombre. Pour vrifier que tous les tokens du syntagme sont bien accords, le programme va comparer la valeur de chaque trait d'un lment, avec la valeur du mme trait dans tous les lments suivants. Dans les chunks verbaux qui contiennent un pronom personnel sujet, ce sont la personne, le genre et le nombre qui doivent s'unifier. L'outil compare donc la valeur de ces traits entre le verbe et le pronom. Si deux traits compars n'ont pas la mme valeur, l'unification choue et renvoie "faux". Dans ce cas, le programme indique le chunk mis en cause, la phrase laquelle il appartient pour le situer, un commentaire sur le type d'erreur dtecte, et une suggestion de correction. Ces indications se font dans un fichier de sortie HTML. Pour le moment, notre outil n'est pas capable d'effectuer de correction dans les chunks. Seules des suggestions sont donnes. En effet, le programme est uniquement un prototype de calculeur d'unification, et n'a pas pour but de corriger les erreurs, qui sont du ressort de l'interprteur de rgles.
69
c) Vrification "inter-chunks"
Lorsque l'attribut chunk="yes" est spcifi, le programme essaye d'unifier les syntagmes. Il s'agit principalement d'unification entre le sujet et le verbe. Cette unification s'effectue plus prcisment entre les traits d'un syntagme nominal (gnralement le plus gauche) et ceux des lments du syntagme verbal principal, sauf bien sr si celui-ci contient dj un sujet sous forme de pronom personnel. Comme pour la vrification "intra-chunk", l'outil d'unification compare la valeur de traits identiques. Ainsi, pour l'accord du verbe, il faut une comparaison des traits de personne et de nombre. Si le chunk verbal contient en plus un participe pass aprs un auxiliaire tre, les traits "genre" et "nombre" de ce participe pass devront avoir une valeur identique celle des mmes traits du syntagme nominal. Pour plus de clart, nous illustrons ceci avec l'exemple "Les charges sont leves":
<SN pers="3" genre="f" nombre="p"> <D genre="e" nombre="p">Les</D> <N genre="f" nombre="p">charges</N> </SN> <SV type="ppal"> <V mode="ind" temps="pres" pers="3" nombre="p">sont</V> <V mode="ppa" genre="f nombre="p">leves</V> </SV> <M fin="yes">.</M>
Les traits "pers" et nombre" du verbe sont sont compars avec les mmes traits du syntagme nominal Les charges. De mme, les traits "genre" et nombre" de ce dernier sont compars avec ceux du participe pass leves. Si l'unification choue, c'est--dire si deux traits identiques n'ont pas la mme valeur, le programme rapporte une dtection d'erreur dans le fichier de sortie, de la mme manire que lors de la vrification "intra-chunk".
3.3.3. Dveloppement
Nous prsentons ci-dessous l'algorithme gnral de notre outil : SI le motif est dtect ET la rgle contient la balise <unify/> ALORS : SI chunk="yes" ALORS : POUR chaque chunk FAIRE : POUR chaque trait du chunk FAIRE : Comparer valeur avec valeur de trait du chunk suivant SI la valeur de ces traits est diffrente ALORS : unification="faux" SI token="yes" ALORS : POUR chaque token FAIRE : POUR chaque trait du token FAIRE : Comparer valeur avec valeur du trait de l'lment suivant SI la valeur de ces traits est diffrente ALORS : unification="faux" SI unification="faux" ALORS : Renvoyer "faux" l'interprteur
70
<SN genre="e" nombre="p"> <D genre="e" nombre="p">Les</D> <N genre="e" nombre="p">enfants</N> </SN> <R type="rel" genre="e" nombre="p">qui</R> <SV type="rel"> <V mode="ind" temps="pres" pers="3" nombre="s">choue</V> </SV> <SP> <P></P> <D genre="e" nombre="s">l'</D> <N genre="f" nombre="s">cole</N> </SP> <SV type="ppal"> <V mode="ind" temps="pres" pers="3" nombre="p">ont</V> </SV> <SN> <D genre="e" nombre="p">des</D> <J genre="f" nombre="p">grandes</J> <N genre="f" nombre="s">capacit</N> <J genre="e" nombre="s">linguistique</J> </SN>
Les erreurs d'accord en nombre dans le dernier syntagme nominal ont t bien identifies. De mme que l'accord du verbe de la relative, qui aurait d tre au pluriel, comme son antcdent.
71
Le programme a bien dtect la faute d'accord entre le chunk nominal sujet au pluriel et le verbe au singulier.
"*Les gens que j'ai vu n'avait pas l'air au courant" : <SN genre="e" nombre="p"> <D genre="e" nombre="p">Les</D> <N genre="e" nombre="p">gens</N> </SN> <R type="rel" genre="e" nombre="p">que</R> <SV type="rel"> <R type="pres" fonction="suj" pers="1" nombre="1">j'</R> <V mode="ind" temps="pres" pers="1" nombre="s">ai</V> <V mode="ppa" pers="3" genre="m" nombre="s">vu</V> </SV> <SV> <A>n'</A> <V mode="ind" temps="pres" pers="3" nombre="s">avait</V> <A>pas</A> </SV> <SN genre="m" nombre="s"> <D genre="e" nombre="s">l'</D> <N genre="m" nombre="s">air</N> </SN> <SP> <D genre="m" nombre="s">au</D> <N genre="m" nombre="s">courant</N> </SP>
Dans cette phrase, l'erreur d'accord du syntagme nominal sujet avec le verbe principal a t dtecte. En revanche, notre algorithme actuel n'est pas capable de trouver la faute dans l'accord du participe pass "vu" avec le complment d'objet antpos "que" qui a le nombre pluriel.
72
Le programme a bien dtect la faute d'accord en nombre et en genre du sujet et du participe pass aprs le verbe tre. Les premires rgles dans notre formalisme ne permettent de traiter que des cas relativement simples, qui sont les accords intra-chunks et les accords sujet-verbe et sujetparticipe pass. Toutes les erreurs de ce type ont t correctement dtectes. En revanche, certaines erreurs comme l'accord du participe pass avec les complments d'objets antposs ne sont pas prises en compte. De mme, nous vrifions l'accord du syntagme verbal avec le pronom relatif, mais nous ne nous occupons pas de l'unification de ce pronom avec son antcdent. La coordination n'est pas non plus traite. Notre prototype ne donne donc qu'un aperu de ce qui est possible, mais il permet tout de mme de montrer que la combinaison chunks-unification fonctionne bien pour dtecter les fautes d'accords.
4. Conclusion
Dans cette partie, nous avons expos les limites du formalisme actuel de LanguageTool, dont la principale est le pattern-matching. Ce systme induit en effet la rdaction d'un nombre dmesur de rgles de correction. Nous avons alors propos de complter le formalisme avec les principes linguistiques de la segmentation en chunks et de l'unification de structures de traits. Nous avons dcrit un nouveau formalisme se fondant sur ces deux principes, et avons montr que leur combinaison permet l'utilisation de rgles gnriques simples pour dtecter les erreurs d'accords. Elle permet galement d'viter la rptition de rgles en intgrant une abstraction (chunk, catgories) et des outils linguistiques (unification). Nous avons ainsi rduit 4 les 450 rgles sur les syntagmes nominaux, contenues dans An Gramadir. Pour montrer la faisabilit, nous avons ensuite conu un prototype d'interprteur de ce nouveau formalisme, capable de dtecter les fautes d'accords, partir de phrases pralablement tiquetes en XML et segmentes en chunks. Les rsultats positifs que nous avons obtenus nous permettent prsent d'envisager le dveloppement d'un nouveau moteur de correction grammaticale, intgrant un dcoupage en chunk et une fonction d'unification.
73
2. Proposition de formalisme
Pour amliorer la correction grammaticale, et en particulier pour prendre en compte la fonction d'unification, un interprteur compatible avec le nouveau formalisme est ncessaire. Le dveloppement d'un tel outil constitue une partie de notre recherche, que nous poursuivons dans le cadre d'un doctorat. Nous travail consistera alors galement complter la base de rgles. Dans ce but, il nous faudra raliser, de manire approfondie, l'analyse d'un corpus d'erreurs que nous aurons constitu. Nous pourrons alors en extraire des fautes, dont nous dfinirons la typologie, et partir desquelles nous crerons de nouvelles rgles.
74
Tokenization : segmentation du texte en phrases, puis en tokens Tagging : tiquetage, correction orthographique, puis dsambigusation
Les tokens seront tiquets en XML. L'utilisateur sera invit corriger, au fur et mesure, les ventuelles fautes d'orthographe dans les mots inconnus, qui pourront alors recevoir un tag. Les tokens seront ensuite dsambiguss, avec une mthode base de rgles
Chunking : dlimitation des chunks au sein des phrases Dtection des fautes : succession de plusieurs types de dtection.
La substitution d'un mot par un autre, comme une confusion d'homophones ou une faute de frappe, aboutit souvent la prsence d'un mot d'une catgorie grammaticale inattendue. Certaines de ces erreurs pourront tre dtectes, puis corriges par l'utilisateur. Un retour l'tape du tagging permettra ensuite de rectifier l'tiquetage, ainsi que la segmentation en chunk. Les erreurs d'accords au sein des chunks seront signales l'utilisateur qui pourra les corriger au fur et mesure. Les traits de ces chunks seront alors rectifis. Les accords errons entre chunks pourront enfin tre dtects, signals, et corrigs.
phrases et tokens orthographe corrig par l'utilisateur texte tiquet en XML texte dsambigus phrases segmentes en chunks substitution de mots corrige par l'utilisateur chunks corrigs par l'utilisateur
Texte vrifier
Texte corrig
Dsambigusation (rgles)
CHUNKING
Accords intra-chunks
Accords inter-chunks
DTECTION DES FAUTES (rgles d'erreurs; unification) Retour sur le tagging pour rectifications aprs corrections de l'utilisateur
Figure 7: Proposition d'une structure pour un nouvel outil. Le texte gris correspond aux tapes similaires la version actuelle de LanguageTool Par rapport d'autres correcteurs que nous avons eu l'occasion d'analyser, parmi les outils libres bien sr, puisque la structure des logiciels propritaires n'est pas accessible, celui que nous
75
souhaitons dvelopper aura donc plusieurs avantages. Une vrification orthographique permettra d'abord de limiter le nombre de mots inconnus non taggs. Ensuite, des retours en arrire dans le traitement seront possibles, pour rectifier l'tiquetage notamment, ce qui conduira ainsi moins de fausses alarmes dues de mauvais tags. Mais la principale amlioration sera bien sr de pouvoir corriger les trs frquentes erreurs d'accords, grce l'utilisation combine d'tiquettes en XML, d'une segmentation en chunks, et du principe de l'unification. Cette mthode de dtection permettra de corriger toute faute d'accord, quel que soit son contexte, sans ncessiter d'interminables listes numratives de rgles.
76
Quels scripteurs ? Les erreurs commises dpendent de la situation d'criture, mais aussi beaucoup du scripteur. Il y a des diffrences selon l'ge (enfant, jeunes, adultes), selon le niveau d'tude (primaire, secondaire, suprieur), selon la langue maternelle (Franais Langue Maternelle, trangre, Seconde). La typologie des fautes de grammaire ne sera pas la mme pour un francophone et un apprenant. Dans son mmoire de DEA, S. Echinard (2004) dresse une typologie des erreurs d'apprenants en Franais Langue trangre. Il en ressort de nombreuses fautes de morphologie, dans la formation des fminins, des pluriels, des formes conjugues, dans l'lision ou la contraction des dterminants. Ces erreurs sont typiques des non francophones, mais il est galement possible d'en retrouver dans des productions d'enfants. Nous devrons donc dterminer quels publics notre correcteur grammatical sera principalement destin, et collecter majoritairement des documents produits par ces types d'utilisateurs.
77
utilisateur, et faire rapidement progresser les outils dvelopps. Ainsi, les utilisateurs font part de leurs besoins, les linguistes les modlisent et les informaticiens les dveloppent. La communaut OpenOffice.org est trs active et trs vaste. Elle runit des gens du monde entier. Nous l'avons rejointe lors d'un stage que nous avons effectu au sein de la socit Nuxeo-InDesko. L'objectif tait la cration d'un outil d'extraction automatique d'affixes partir d'une liste de mots, afin de pouvoir gnrer automatiquement, pour toute langue, un fichier d'affixes et un dictionnaire compatibles avec le correcteur orthographique de la suite bureautique. Un article sur ce travail a t soumis pour la confrence annuelle OpenOffice.org en septembre 2007. Nous avons alors reu de l'aide de diverses personnes pour dvelopper notre outil, et nous avons par la suite, notre tour, aid d'autres personnes ce sujet. L'entraide est donc trs importante. Elle permet d'obtenir efficacement des solutions aux problmes qui peuvent survenir, et participe l'volution rapide des outils dvelopps. Nous voyons ici l'intrt d'utiliser, pour notre correcteur grammatical, un formalisme qui soit pour tous aussi lisible et comprhensible que possible. Cela permet de recevoir de l'aide plus facilement, tant pour dvelopper l'outil que pour enrichir la base de rgles de correction par exemple. Le travail que nous avons entrepris dans ce mmoire s'intgre la fois dans le projet OpenOffice.org et dans le projet LanguageTool. Nous contribuons ainsi au dveloppement communautaire de ces outils, et nous recevons de l'aide pour mener bien notre projet. Les apports rciproques de la linguistique et de l'informatique Le travail communautaire contribue beaucoup ces apports, que nous avons pu mesurer plusieurs occasions tout au long de notre travail sur LanguageTool. Nous avons beaucoup chang avec Naber (2003), et Mikowski en particulier. Nous avons soulev des problmes linguistiques, auxquels ils ont rpondus avec leurs connaissances informatiques. Par exemple, Mikowski a implant le dsambiguseur en suivant le formalisme que nous lui avions indiqu. Par la suite, il a ajout aux fichiers XML une fonctionnalit dont nous avions besoin pour la rcriture des rgles de An Gramadir. Pour dvelopper des outils de traitement automatique des langues, il est ncessaire d'avoir la fois de trs bonnes connaissances en linguistique et en informatique. Mais dans la pratique, il est difficile d'tre parfaitement pluridisciplinaire. Ainsi, un trs bon informaticien est gnralement moins spcialiste en linguistique que peut l'tre un linguiste, et vice-versa. C'est pourquoi nous pensons que la collaboration entre linguistes et informaticiens est vraiment bnfique, voire indispensable en TAL. Les apports de la recherche publique Dans le domaine de la correction grammaticale automatique, il existe majoritairement des logiciels propritaires ferms, dont les ressources linguistiques ne sont pas accessibles, et au sujet desquels il n'y a quasiment aucune publication. Nous esprons combler ces lacunes avec le travail de recherche que nous venons de commencer, et que nous allons approfondir pendant les annes venir. En associant la recherche publique en linguistique et informatique, aux besoins des industriels et des utilisateurs, nos travaux futurs mneront la cration d'un outil gnrique de correction grammaticale, ainsi que d'une interface de rdaction de rgles de correction. Ces outils seront
78
conus de manire permettre des non-informaticiens d'y contribuer facilement et librement, dans un esprit communautaire. D'autres part, nous pourrons publier les rsultats que nous obtiendrons au cours de notre recherche, et qui pourront par la suite tre la base d'autres travaux. Nous pouvons galement mentionner les apports d'autres recherches qui sont en cours. Par exemple, Blanchard (2006) travaille actuellement sur la morphologique des rponses d'apprenants et l'interprtation des erreurs de constructions morphologiques. Une analyse morphologique des erreurs nous intresserait particulirement dans le domaine de la correction grammaticale. Nous pourrions aussi envisager de travailler sur un corpus commun aux deux thmes de recherche, corpus dont la constitution plusieurs serait ainsi plus efficace.
Glossaire
79
Glossaire
chunk nominal chunk prep. chunk prep. chunk verbal chunk nominal
Dsambigusation
Rduction du nombre d'tiquettes (ou tags) possdes par un mot (ou token) ambigu, c'est--dire pouvant avoir plusieurs catgories grammaticales ou sous-catgories possibles. Cette rduction se fait l'aide de rgles statistiques ou manuelles. Les rgles statistiques consistent appliquer aux mots ambigus les probabilits qu'ils aient tel ou tel tag, et ne conserver que le ou les tags les plus probables. Les probabilits sont calcules pralablement partir d'un corpus d'apprentissage. Les rgles manuelles se fondent sur le contexte immdiat des mots ambigus et dcrivent des modles de contextes en prsence desquels tels mots prennent tel(s) tag(s). LanguageTool utilise des rgles manuelles. Exemple : Le mot porte peut tre nom ou verbe. Il est donc ambigu Il a alors une tiquette "nom" et une autre "verbe". Dans une phrase comme "Il porte une chemise bleue", l'tiquette "nom" peut tre retire car le pronom personnel il devant porte indique que nous sommes en prsence du verbe et non du nom. porte est ainsi dsambigus.
tiquetage morphosyntaxique
Fait d'attribuer chaque forme graphique (token) du texte la ou les tiquette(s) morphosyntaxique(s) (tag) qui lui correspond(ent). L'tiquetage se fait partir d'un lexique contenant tous les mots de la langue et les informations sur les catgories et sous-catgories de chacun. Par exemple, dans la phrase "Nous sommes 4 personnes", lors de l'tiquetage morphosyntaxique : - Nous reoit les tags "pronom pers. sujet 1re pers. pluriel" et "pronom pers. objet 1re pers. pluriel"
Glossaire
80 - sommes reoit les tags "verbe tre indicatif prsent 1re pers. pluriel" et "nom fminin pluriel" - 4 reoit le tag "nombre" - personnes reoit le tag "nom fminin pluriel"
Expression rgulire
Suite de caractres typographiques permettant de dfinir un modle de chanes de caractres et de trouver les chanes correspondantes dans un bloc de texte.
L'expression rgulire ".*tion" permet de trouver tous les mots finissant par "tion"
Pattern-matching
En informatique et dans le traitement automatique des langues, le pattern-matching est le fait de vrifier la prsence dans un texte d'lments dcrits dans un motif (ou pattern). Dans ce mmoire, le pattern-matching consiste vrifier si une partie du texte correspond exactement la description faite dans le pattern des rgles. Si le pattern d'une rgle dcrit un dterminant pluriel suivi d'un nom singulier, il y aura un pattern-matching avec les deux premiers mots de la phrase "*Les enfant qui choue...". En effet, cette phrase contient un dterminant pluriel (les) suivi d'un nom au singulier (enfant), ce qui correspond exactement la description faite par le pattern de la rgle.
Tag (tiquette)
tiquette attribue chaque token du texte et contenant les informations morphosyntaxiques de ce token, c'est--dire sa catgorie grammaticale (nom, verbe, adjectif, etc.) et ses sous-catgories (genre, nombre, temps, personne, etc.). Par exemple, le tag de rapport est "Nom masculin singulier", o "Nom" est la catgorie grammaticale, et "masculin" et "singulier" sont les sous-catgories.
Tagger (tiqueteur)
Outil permettant automatiquement. d'effectuer l'tiquetage morphosyntaxique (ou tagging)
Glossaire
81
Token (jeton)
Unit issue de la tokenization. Il s'agit gnralement d'un mot, ou plutt d'une forme graphique. En effet, le mot en linguistique peut dsigner une unit smantique constitue de plusieurs formes graphiques. Par exemple, "pomme de terre" est une unit compose de 3 formes graphiques, qui correspondent 3 tokens. Un token peut aussi tre un signe de ponctuation.
Bibliographie
82
Bibliographie
[Abney, 1991] Abney, S. (1991). "Parsing by chunks". In R.C., Berwick, S. Abney, et C. Tenny, diteurs, Principle-Based Parsing : Computation and Psycholinguistics, pages 257-278. Kluwer Academic Publishers, Boston. [Blanchard, 2006] Blanchard, A. (2006). Analyse morphologique des rponses d'apprenants en environnement d'apprentissage assist par ordinateur. Mmoire de Master 2 Recherche, Industries de la Langue, Universit Stendhal Grenoble 3. [Boudreau, Kittredge, 2005] Boudreau, S. et Kittredge, R. (2005). "Rsolution des anaphores et dtermination des chanes de corfrences". Modles et algorithmes pour la rsolution d'anaphores. Traitement automatique des langues, Volume 46 n1/2005. Herms, Lavoisier [Bouillon, 1998] Bouillon, P. (1998). Traitement automatique des langues naturelles. ditions Duculot. [Bonnard, 1981] Bonnard, H. (1981). Code du franais courant. ditions Magnard. [Brill, 1994] Brill, E. (1994). Unsupervised learning of disambiguation rules for part of speech tagging. http://acl.ldc.upenn.edu/W/W95/W95-0101.pdf [Chomsky, 1979] Chomsky, N. (1959). Structures syntaxiques. ditions Seuil. [COVAREC, 1994] Equipe COVAREC (1994). Corpus de variations orthographiques. Laboratoire LIDILEM, Universit Stendhal-Grenoble 3. [Dubois et al. 2002] Dubois, J., Giacomo, M., Guespin, L., Marcellesi, C., Marcellesi, J.-B. et Mvel J.-P. (2002). Dictionnaire de linguistique. ditions Larousse. [Echinard, 2004] Echinard, S. (2004). Vers la cration d'un systme d'analyse des rponses d'apprenants. Mmoire de DEA Industries de la Langue, Universit Stendhal-Grenoble 3. [Giguet, 1998] Giguet, E. (1998). Mthode pour l'analyse automatique des structures formelles sur documents multilingues. Thse de doctorat, Universit de Caen. [Grevisse, 1993] Grevisse, M. (1993). Le Bon Usage. Treizime dition par Andr Goosse. ditions De Boeck - Duculot. [Lebarb, 2002] Lebarb, T. (2002). Hirarchie inclusive des units linguistiques en analyse syntaxique cooprative; le segment, unit intermdiaire entre chunk et phrase dans le traitement linguistique par systme multi-agents. Thse de doctorat, Universit de Caen. [Lechelt, 2005] Lechelt, M. (2005). Analyse et conception d'un correcteur grammatical libre pour le franais. Mmoire de stage, Master 2 Industries de la Langue, Universit StendhalGrenoble 3. http://blogs.nuxeo.com/sections/blogs/myriam_lechelt/2005_11_30_gramooo-memoireslides/downloadFile/attachedFile_f0/MEMOIRE_Lechelt_Myriam_GramOOo.pdf?nocache=11 33784640.61
Bibliographie
83
[Lucci & Millet, 1994] Lucci, V. & Millet, A. (1994). L'orthographe de tous les jours, enqute sur les pratiques orthographiques des franais. ditions Champion. [Miller & Toris, 1990] Miller, P., & Toris, T. (1990). Formalisme pour le TALN. Hermes. [Naber, 2003] Naber, D. (2003). A rule-based and grammar checker. Mmoire. Technische Fakultt, Universitt Beilefeld. [Riegel et al. 2003] Riegel, M., Pellat, J.-C., Rioul, R. (2003). Grammaire mthodique du franais. ditions PUF. [Souque, 2006] Souque, A. (2006). Analyse critique des produits IdL : analyse comparative des correcteurs orthographiques de Word 2000 et OpenOffice.org 2.0. Master 1 Industries de la Langue, Universit Stendhal-Grenoble3. [Tesnires, 1959] Tesnires, L. (1959). lments de syntaxe structurale. Klincksieck [Vergne, 1999] Vergne, J. (1999). tude et modlisation de la syntaxe des langues l'aide de l'ordinateur, analyse syntaxique automatique non combinatoire. Habilitation Diriger des Recherches. Universit de Caen. [Vergne & Giguet, 1998] Vergne, J. et Giguet, E. (1998). Regards thoriques sur le tagging. Cinquime confrence annuelle : Le traitement automatique des Langues Naturelles (TALN 1998). http://users.info.unicaen.fr/~giguet/taln98/
Webographie
84
Webographie
[Web : ABU] Bibliothque Universelle ABU http://abu.cnam.fr [Web : AGR] An Gramadir http://borel.slu.edu/gramadoir/ [Web : DIC] DICO http://abu.cnam.fr/DICO [Web : GRA] GRAC http://grac.sourceforge.net/ http://grac.sourceforge.net/grac_architecture.pdf [Web : GRC] Grammaire et Ressources pour les Analyseurs de Corpus et leur valuation http://www.limsi.fr/RS99FF/CHM99FF/TLP99FF/tlp10/ [Web : LAN] LanguageTool http://www.languagetool.org/ http://sourceforge.net/projects/languagetool/ [Web : NUX] Nuxeo, Blogs http://blogs.nuxeo.com/ http://blogs.nuxeo.com/sections/blogs/agnes-souque http://blogs.nuxeo.com/sections/blogs/myriam_lechelt [Web : SOU] Souque, A. (2006). Cration de Aff-Finder. Rapport de stage. http://w3.u-grenoble3.fr/lebarbe/agnes/ [Web : SYN] Synapse. propos de la correction grammaticale franaise et des correcteurs informatiques. La Correction grammaticale franaise. http://www.synapse-fr.com/descr_technique/A_propos_des_correcteurs.htm [Web : TLF] Trsor de la Langue Franaise Informatis http://atilf.atilf.fr/tlf.htm [Web : WIK] Wikipedia http://fr.wikipedia.org/wiki/Orthographe