Conception Et Developpement Dun Formalisme de Correction Grammaticale Automatique-Applicaion Au Fracais

UNIVERSIT STENDHAL GRENOBLE 3 LABORATOIRE LIDILEM
CONCEPTION ET DVELOPPEMENT D'UN FORMALISME DE CORRECTION GRAMMATICALE AUTOMATIQUE - APPLICATION AU FRANAIS -
Agns Souque Juin 2007
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
Directeur de mmoire : Thomas Lebarb, Matre de confrences
Table des matires

Introduction......................................................................................................................9 Chapitre 1 : Existant......................................................................................................11 1. Structure gnrale d'un correcteur grammatical......................................................11
1.1. Tokenization.................................................................................................................11 1.2. Tagging et dsambigusation.......................................................................................12 1.3. Segmentation en syntagmes minimaux.......................................................................12 1.4. Dtection des fautes.....................................................................................................12
2. Travail de M. Lechelt : adaptation au franais d'un correcteur existant..................13

2.1. Analyse de diffrents correcteurs................................................................................13 2.1.1. Rejet de GRAC et de LanguageTool...................................................................13 2.1.2. Slection de An Gramadir.................................................................................14 2.2. Adaptation de An Gramadir la correction grammaticale du franais.....................14 2.2.1. La tokenization....................................................................................................14 2.2.2. Le tagging............................................................................................................15 2.2.3. La dtection des fautes........................................................................................15 2.2.4. La rdaction des rgles........................................................................................16 2.3. valuation et perspectives...........................................................................................17 2.3.1. valuation et limites de An Gramadir...............................................................17 2.3.2. Perspectives.........................................................................................................19
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
3 1.2. Problme de l'ambigut catgorielle..........................................................................26 1.3. Tentative de contournement du problme...................................................................28
2. Implantation d'un dsambiguseur...........................................................................28

2.1. Choix d'un type de dsambiguseur.............................................................................28 2.2. Choix d'un formalisme pour les rgles........................................................................29 2.3. Intgration dans LanguageTool...................................................................................29
3. Importation des rgles de An Gramadir dans LanguageTool................................30

3.1. Importation des rgles de dsambigusation...............................................................30 3.1.1. Reprsentation en XML.......................................................................................30 3.1.2. Rcriture des rgles............................................................................................31 3.2. Importation des rgles d'erreurs..................................................................................35 3.2.1. Rcriture automatique........................................................................................35 3.2.2. Rcriture des rgles sur les syntagmes verbaux.................................................36 3.2.3. Rcriture des rgles sur les syntagmes nominaux.............................................37
4. Augmentation des rgles partir d'un corpus de fautes..........................................39

4.1. Analyse des fautes commises......................................................................................39 4.1.1. Fautes d'orthographe............................................................................................39 4.1.2. Fautes dj dtectes par LanguageTool.............................................................40 4.1.3. Fautes a priori non dtectables............................................................................40 4.1.4. Fautes dtectables avec un nouveau formalisme.................................................40 4.1.5. Fautes dtectables avec le formalisme actuel de LanguageTool.........................41 4.2. Rdaction de nouvelles rgles d'erreurs......................................................................41 4.2.1. Accord Dterminant + Nom + Verbe..................................................................41 4.2.2. Accord en nombre tre + Participe pass ou Adjectif........................................42 4.2.3. Confusion entre la forme verbale et la forme nominale......................................42 4.2.4. Confusion entre "on" et ont"................................................................................43 4.2.5. Confusion entre "cet", "cette", "ces" et "c'est".....................................................43 4.2.6. Accord Pronom relatif "qui" + Verbe :................................................................44
5. Typologie des erreurs corriges...............................................................................44

5.1. Les erreurs corriges par LanguageTool.....................................................................44 5.1.1. Les erreurs de proximit phontique...................................................................45 5.1.2. Les erreurs d'accord dans le syntagme nominal..................................................45 5.1.3. Les erreurs dans le groupe verbal........................................................................45
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
2. Premire volution du formalisme...........................................................................56

2.1. Segmentation en chunks et unification de structures de traits.....................................57 2.1.1. Chunks.................................................................................................................57 2.1.2. Rappels sur les structures de traits et l'unification...............................................59 2.2. Intrt de la combinaison chunks-unification pour la correction grammaticale.........59 2.2.1. Correction "intra-chunk".....................................................................................59 2.2.2. Correction "inter-chunks"....................................................................................60 2.2.3. Aide la dsambigusation..................................................................................60 2.3. Vrification orthographique........................................................................................61
3. Dveloppement d'un nouveau formalisme...............................................................61

3.1. Description du formalisme..........................................................................................61 3.1.1. lment <rule>....................................................................................................61 3.1.2. lment <example>.............................................................................................63 3.1.3. lment <message>.............................................................................................63
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
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.
1. Structure gnrale d'un correcteur grammatical

L'objectif de notre travail est de dvelopper un correcteur grammatical. Il semble donc naturel de commencer par prsenter, de manire gnrale, comment ce type d'outils fonctionne. La figure 1 ci-dessous illustre la succession des diffrentes tapes de traitement dont nous parlons : la tokenization, l'tiquetage, la dsambigusation, la segmentation en syntagmes minimaux, et enfin la dtection des fautes. Ces tapes sont identiques d'un correcteur l'autre, mais avec des mthodes variables. En revanche, certaines ne sont pas toujours prsentes. Les zones hachures, dans la figure 1, correspondent aux tapes qui ne sont pas effectues systmatiquement par tous les outils de correction grammaticale.
Texte vrifier
phrases et tokens
texte tiquet
texte tiquet dsambigus
phrases segmentes en chunks
Texte corrig
TOKENIZATION
tiquetage Dsambigusation morphosyntaxique TAGGING

probabilits et rgles
CHUNKING
DETECTION DES FAUTES
corpus
ou
rgles o rgles de d'erreurs u grammaire
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
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.
1.2. Tagging et dsambigusation

L'tiqueteur (ou tagger) effectue ensuite l'tiquetage morphosyntaxique (ou tagging). Chaque mot se voit attribuer une ou plusieurs tiquettes (tag), contenant des informations sur la catgorie grammaticale (verbe, nom, pronom, etc), ainsi que sur ses traits de souscatgorisation (genre, nombre, temps, personne, etc). Ces tags proviennent d'un lexique de formes flchies tiquetes. Les mots qui reoivent plusieurs tags sont les mots ambigus. Il s'agit de mots ayant des homographes avec des informations morphosyntaxiques diffrentes, comme le mot bte qui peut tre "nom fminin singulier", "adjectif masculin singulier" ou "adjectif fminin singulier". Une dsambigusation est ncessaire pour limiter le nombre d'tiquettes de ces mots et amliorer par la suite la dtection de fautes de grammaire. Une premire mthode pour dsambiguser les mots est la mthode probabiliste. Elle ncessite un corpus d'apprentissage sans erreurs, tiquet avec les informations morphosyntaxiques. Des calculs sont alors effectus. Il s'agit de la probabilit que tel mot ait tel tag, ou encore la probabilit qu'un mot ait un certain tag en fonction des tags des mots qui l'entourent. Lors de l'tiquetage, ces probabilits sont appliques aux mots du texte analys, et chaque mot reoit alors le tag qui correspond la plus forte probabilit. L'algorithme de (Brill, 1994) permet de gnrer des rgles de dsambigusation tablies statistiquement. Une autre mthode consiste utiliser des rgles manuelles de dsambigusation (Vergne, 2000), sous forme d'expressions rgulires et fondes sur le contexte immdiat. Chaque rgle consiste en un modle (ou pattern) d'un contexte en prsence duquel tel mot prend tel tag. Certains correcteurs utilisent la mthode probabiliste, d'autres les rgles manuelles, certains combinent les deux mthodes, enfin d'autres ne font pas du tout de dsambigusation.
1.3. Segmentation en syntagmes minimaux

Le dcoupage en syntagmes minimaux, (ou chunking), permet de travailler un niveau intermdiaire entre la phrase et le mot, en dfinissant des groupes de mots. Cette tape concerne peu de correcteurs, mais nous la mentionnons tout de mme car, comme nous le verrons par la suite, ce type de segmentation peut tre trs utile dans le traitement automatique des langues (Abney, 1991). Ceci nous intresse particulirement pour l'outil que nous souhaitons dvelopper, et nous en reparlons donc de manire plus dtaille dans le point 2.1.1. du chapitre 3.
10
1.4. Dtection des fautes

Une fois l'tiquetage termin, commence alors l'tape de vrification de la grammaire. Il existe l encore deux manires de procder, toutes deux fondes sur le principe du pattern-matching, c'est--dire sur la correspondance exacte entre un lment et un modle. Certains correcteurs utilisent des rgles de grammaire. Elles dcrivent des patterns grammaticalement corrects. Si une partie du texte ne correspond aucun pattern, une erreur est dtecte. D'autres correcteurs utilisent au contraire des rgles d'erreurs. Ils comparent alors le texte non pas des modles corrects, mais des modles de fautes. Une erreur est dtecte lorsque le texte et le pattern concident.
2. Travail de M. Lechelt : adaptation au franais d'un correcteur existant

Dans le cadre de son mmoire de Master 2, (Lechelt, 2005) a initi un travail dont nous prenons la suite, et dont l'objectif est, terme, de crer un outil de correction grammaticale libre pour le franais, pouvant tre intgr OpenOffice.org. Afin de ne pas raliser entirement un nouvel outil, (Lechelt, 2005) a analys plusieurs correcteurs grammaticaux libres dj existants dans d'autres langues, afin de dterminer lequel pourrait tre le plus facilement adapt au franais. Suite cette analyse, elle a modifi et complt l'outil slectionn, pour pouvoir prendre en charge la correction du franais. L'valuation du systme ainsi transform, bien qu'assez satisfaisante, a mis en vidence certaines limites. Quelques amliorations supplmentaires ont donc t suggres, ainsi qu'une approche alternative pour la cration d'un outil entirement nouveau.
2.1. Analyse de diffrents correcteurs

2.1.1. Rejet de GRAC et de LanguageTool
Trois correcteurs grammaticaux libres, disponibles dans des langues trangres, ont t analyss. Le premier a t rapidement cart, sa ralisation n'tant pas encore acheve. Il s'agit de GRAC (GRAmmar Checker) (Web : GRAC), un correcteur indpendant de toute langue, dvelopp par M. Biais. Il utilise la mthode probabiliste pour la dsambigusation, et des rgles de grammaire pour la dtection des fautes. L'analyse a ensuite port sur LanguageTool (Web : LAN), un correcteur libre de style et de grammaire, dvelopp initialement pour l'anglais par (Naber, 2003). L'outil a retenu l'attention, mais aprs comparaison avec le troisime, il a finalement t lui aussi rejet. En effet, la version de LanguageTool analyse l'poque faisait appel une mthode probabiliste pour dsambiguser les mots, mthode dont nous verrons les inconvnients par la suite, au chapitre 1 dans le point 3.1.2. C'est donc An Gramadir (Web : Gramadir), le dernier outil analys, qui a finalement t retenu pour l'adaptation au franais.
11
2.1.2. Slection de An Gramadir

An Gramadir est un correcteur dvelopp en Perl par K. Scannell. Il a t initialement cr pour le galique, puis adapt d'autres langues, principalement minoritaires, telles que le gallois, le breton, ou encore le tagalog. C'est un systme base de rgles. Les rgles sont crites manuellement, sous forme d'expressions rgulires, et s'appuient sur le contexte. Certaines servent la dsambigusation, les autres sont des rgles d'erreurs pour la vrification grammaticale. Aprs avoir segment le texte en phrases, puis en tokens, le systme procde l'tiquetage morphosyntaxique des mots. Chacun reoit une tiquette, ou plusieurs s'il est ambigu. Les rgles de dsambigusation interviennent alors pour retirer les tags inappropris, en fonction de leur contexte immdiat. Le dernier traitement consiste ensuite dtecter les fautes grammaticales l'aide des rgles d'erreurs. Si le texte analys concide avec une rgle, cela signifie qu'il contient une erreur. Un message est alors renvoy l'utilisateur pour lui dcrire la faute dtecte et lui suggrer une correction. Nous illustrons les diffrentes tapes de traitement dans An Gramadir avec la figure 2, dans laquelle nous voyons galement apparatre les traitements qui sont effectus par d'autres correcteurs. Nous pouvons ainsi situer An Gramadir par rapport aux autres outils dans le domaine.
Texte vrifier
phrases et tokens
texte tiquet
phrases segmentes en chunks
Texte corrig
TOKENIZATION

probabilits ou rgles
CHUNKING
corpus
Figure 2: Structure du correcteur An Gramadir
2.2. Adaptation de An Gramadir la correction grammaticale du franais

Pour adapter le correcteur de K. Scannell la langue franaise, plusieurs modifications ont t ncessaires, sur les diffrentes tapes de traitement.
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.
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.
2.2.3. La dtection des fautes

Dans (Lechelt, 2005), le premier travail concernant cette tape a t d'observer de nombreux textes produits sur internet, afin de dterminer les fautes de grammaire les plus courantes, et de traiter si possible celles-ci en priorit. Les principales erreurs mises en vidence par cette observation, et qui pouvaient a priori tre traites par An Gramadir, sont les diverses fautes d'accords (au sein du groupe nominal, entre
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.
2.2.4. La rdaction des rgles

Nous avons vu que An Gramadir utilise des rgles la fois pour la dsambigusation et pour la dtection des fautes. Les deux types ont peu prs la mme structure. Elles sont constitues de balises et de noms de macros, dfinies dans un fichier part. Les macros sont des expressions rgulires qui dcrivent des types de mots, en fonction de leur catgorie et de leurs traits. Elles vitent d'avoir citer tous les mots dans les rgles en donnant un identifiant gnral ceux de certains types. Par exemple, la macro suivante permet d'utiliser l'identifiant ANYDFS dans les rgles pour dsigner tout dterminant fminin singulier :
s/ANYDFS/(?:<[^>]*>)*<D m s.>(?:<[^>]*>)*/g
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.
a) Les rgles de dsambigusation

Dans les rgles de dsambigusation, les balises entourent le mot ambigu et ses tags, qui sont eux-mmes entours des balises <Z></Z>. Un espace spare le mot ambigu de son contexte droit et/ou gauche, qui est lui aussi entour de balises. La catgorie grammaticale du contexte dfinit le nom de ses balises. Ainsi, un nom sera entre <N> et </N> et un verbe entre <V> et </V>. La rgle est spare en deux parties par deux points ":". gauche se trouvent le mot ambigu et son contexte ; la partie droite consiste en une balise contenant le tag attribuer au mot ambigu. Une rgle de dsambigusation est donc du type :
<Z>ANYDFS</Z>ANYTHING <N>ANYTHING</N>:<D f s> ANYDMS correspond au nom de la macro que nous avons donne en exemple plus haut. ANYTHING correspond une macro qui dcrit une chane quelconque de caractres.
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>).
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.
b) Les rgles d'erreurs

Tout comme les rgles de dsambigusation, les rgles d'erreurs sont constitues de balises et de noms de macros. La partie gauche dcrit le contexte de la faute, c'est--dire les lments proches du mot qui entretiennent une relation avec lui, et la partie droite indique le type d'erreur. Ainsi, la rgle suivante dcrit une erreur d'accord en nombre entre un dterminant singulier (macro DS) et un nom pluriel (macro NP) :
<DS>ANYTHING</DS> <NP>ANYTHING</NP>:NOMBRE
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.
2.3. valuation et perspectives

Nous venons d'exposer les diffrents traitements dont An Gramadir a fait l'objet dans (Lechelt, 2005) pour son adaptation au franais. Il tait ncessaire ensuite d'valuer la version ainsi modifie, afin d'observer son efficacit et ses limites, puis de dterminer les amliorations apporter pour obtenir un outil bien adapt la langue franaise.
2.3.1. valuation et limites de An Gramadir a) valuation par GRACE

L'valuation a principalement port sur la nouvelle version du tagger, aprs modifications. La dtection des fautes tant dpendante du tagging, il tait primordial de mesurer celui-ci pour pouvoir ensuite travailler sur la vrification grammaticale. Cette valuation du tagger a t ralise l'aide des outils de GRACE (Grammaire et Ressources pour les Analyseurs de Corpus et leur valuation) [Web : GRC]. Ces outils permettent, entre autre, de mesurer la qualit des analyseurs morphosyntaxiques en termes de dcision (proportion de mots dsambiguss) et de prcision (proportion de mots dsambiguss correctement). Les rsultats obtenus ont permis d'effectuer les modifications ncessaires dans l'ordre des rgles de dsambigusation, afin d'obtenir les meilleurs taux de dcision et de prcision possibles. Finalement, les rgles permettent donc de dsambiguser 98,88% des mots ambigus (dcision), dont 84,49% avec le bon tag (prcision). L'valuation a aussi permis de mettre en vidence des erreurs d'tiquetage et des mots non dsambiguss.
15
b) Limites du systme pour la correction du franais

Comme nous l'avons dit, la dtection des fautes est dpendante de l'tiquetage. Or, l'valuation du tagger a montr ses faiblesses. Ce qui conduit une premire limitation que nous pouvons voquer. Elle concerne les rgles de dsambigusation. Nous avons vu qu'elles sont fondes sur l'environnement immdiat du mot ambigu. Or ceci peut poser plusieurs problmes. Tout d'abord, certains mots dpendent d'un contexte loign et ne peuvent donc pas tre dsambiguss d'aprs leur environnement immdiat. Ensuite, le contexte sur lequel s'appuient les rgles est susceptible d'tre faux, ou inconnu. Il ne faut pas oublier que le but final de l'outil est de dtecter des fautes, et qu'il y a donc probablement des fautes dans le texte, et donc dans le contexte. D'autre part, il est tout fait possible que l'environnement immdiat d'un mot ambigu soit lui-mme ambigu. Dans ce cas, les rgles ne peuvent pas non plus s'appliquer. Ces diffrents problmes sont l'origine de nombreuses erreurs ou absences de dsambigusation. La seconde limite dcoule en partie de la premire et concerne les rgles de dtection des fautes. En effet, les rgles d'erreurs s'appliquent principalement sur les tiquettes des mots. Si celles-ci sont errones suite une mauvaise dsambigusation, certaines rgles deviennent inutilisables et laissent passer des fautes de grammaire. Mais les erreurs d'tiquetage peuvent aussi venir directement du lexique utilis pour le tagging. S'il contient des erreurs, des mots mal tiquets, ou bien au contraire s'il ne contient pas certains mots avec certaines tiquettes, les anomalies sont rpercutes directement sur le texte. Nous pouvons enfin rappeler qu'un des dfauts des rgles est d'imposer la prvision de toutes les fautes susceptibles d'tre commises, ce qui est impossible. (Lechelt, 2005) a calcul par exemple qu'il y avait 1458 combinaisons possibles pour un syntagme nominal du type dterminant + nom + adjectif et dterminant + adjectif + nom. Ceci est d au fait que chacune de ces trois catgories peut avoir le genre masculin, fminin ou picne (masculin et fminin identiques), et le nombre singulier, pluriel ou invariable. Mme si nous ne tenons pas compte des combinaisons correctes, qui n'ont pas leur place parmi les rgles d'erreurs, si nous voulons crer une rgle pour chaque combinaison fausse possible, la quantit de rgles ncessaires reste trs lourde. De plus, nous n'avons voqu ici que des combinaisons relatives aux syntagmes nominaux, avec un seul dterminant, nom et adjectif. En ralit, les mots ne se combinent pas toujours de manire aussi simple, et il est en fait impossible, en franais, d'numrer exhaustivement toutes les combinaisons de mots qui peuvent tre rencontres. Nous pourrions crer un trs grand nombre de rgles, mais elles ne couvriraient jamais toute les possibilits de la langue, et alourdiraient considrablement le traitement.
2.3.2. Perspectives a) Amliorations de An Gramadir

Nous avons vu que les erreurs d'tiquetage sont un point faible du systme. Ces erreurs peuvent venir du lexique ou dcouler d'une mauvaise dsambigusation, et sont responsables ensuite d'autres erreurs de dsambigusation, et de mauvaises dtections des fautes de grammaire.
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.
b) Approche alternative pour la conception d'un nouvel outil

An Gramadir n'a pas t conu pour une langue comme le franais, et son adaptation a permis de mettre en vidence ses limites pour traiter une telle langue. Une approche alternative a donc t propose dans (Lechelt, 2005) pour concevoir entirement un nouvel outil. La nouvelle approche propose combine deux principes linguistiques : le dcoupage en chunks et l'unification de structures de traits. Le dcoupage en chunks Le chunk, que nous venons d'voquer, est une unit constitue d'une srie de mots tous contigus les uns aux autres et regroups autour d'une tte lexicale, le plus souvent un nom ou un verbe, plus rarement un adverbe, un adjectif ou un pronom. (E. Giguet 98). Cette notion de groupe de mots peut s'avrer trs utile, notamment pour vrifier les accords sujet-verbe lorsque le sujet n'est pas un simple pronom personnel. Les chunks ont la proprit de ne pas pouvoir se chevaucher ou s'imbriquer. Le dbut d'un chunk implique donc la fin du chunk prcdent. Il est aussi facile de les dfinir en fonction de leurs limites, qui peuvent tre la ponctuation, les conjonctions, les pronoms relatifs, les prpositions, les dterminants, etc. Il n'est alors pas ncessaire de construire une liste fige de tous les modles de chunks possibles, ce qui serait impossible en franais.
Chapitre 1 : Existant L'unification de structures de traits
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.
3.1. Rejet de la premire version de l'outil

3.1.1. Structure de LanguageTool l'poque
La figure 3 ci-dessous reprsente la structure de la premire version de LanguageTool. Elle utilisait la fois des rgles, pour la correction, et des probabilits pour la dsambigusation. Elle tait compose de plusieurs modules programms dans le langage python.
phrases et tokens phrases segmentes en chunks
18
Texte vrifier
texte tiquet
Texte corrig
TOKENIZATION

probabilits ou rgles
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.
19
3.1.2. Points faibles l'origine du rejet

Le rejet de LanguageTool, lors de l'analyse des diffrents correcteurs, avait sa principale origine dans l'utilisation de probabilits pour le tagging. Mais les tests raliss sur l'outil avaient aussi mis en vidence d'autres points faibles. Tout d'abord, comme nous venons de l'voquer, le tagger utilisait une mthode probabiliste qui avait sembl moins matrisable qu'un tagging base de rgles. En effet, s'il y a une erreur de dsambigusation, il est impossible de savoir d'o elle vient. En utilisant des rgles, il est plus facile de retrouver et modifier la rgle qui gnre une erreur de dsambigusation. Par contre, les rgles ont l'inconvnient de devoir tre trs nombreuses pour couvrir le plus de cas possibles. Ensuite, pour dterminer les probabilits ncessaires au tagger, il fallait effectuer une phase d'apprentissage sur un corpus tiquet, or il n'en existait pas de libre. Il aurait donc fallu en constituer un, contenant le plus de structures syntaxiques possibles, afin d'avoir des probabilits pour un maximum de cas. Cela aurait demand un travail considrable, et il n'tait de toutes manires pas possible de construire un corpus exhaustif. Par ailleurs, le fait de devoir recourir un corpus pour l'apprentissage entrane une dpendance totale ce corpus, pour tous les traitements et les dtections de fautes ultrieures. En ce qui concerne les rgles d'erreurs, elles s'appliquaient sur des mots ou des chunks. Or, les rgles de formation des syntagmes induisaient que dans certains cas, comme par exemple un nom singulier seul, un mot n'tait pas intgr un chunk alors qu'il aurait d l'tre. Les rgles s'appuyant normalement sur un syntagme pour dtecter une erreur, ne pouvaient donc plus s'appliquer si elles rencontraient un mot la place, mme s'il y avait effectivement une erreur. Ces rgles devaient par ailleurs tre les plus exhaustives possibles, et le chunking le plus prcis possible, afin de couvrir un maximum de fautes et de limiter ainsi le silence (non-dtection de certaines fautes). Pour finir, rappelons que LanguageTool a t initialement cr pour la langue anglaise. Sa grammaire est telle qu'elle permet de crer une liste assez complte des patrons de chunks. Or, en franais, il n'est pas envisageable d'numrer tous les syntagmes.
3.2. volutions et nouvelle version de l'outil

3.2.1. volutions du systme
LanguageTool a beaucoup volu depuis l'analyse de la premire version, et semble pouvoir tre mieux adapt pour la correction du franais. Le programme a tout d'abord t entirement rcrit en Java, pour un meilleur support du format XML utilis pour les rgles. La DTD de ces rgles a d'ailleurs t amliore. Un nouvel tiqueteur morphosyntaxique, plus compact, a t implant. En revanche, tel que nous pouvons le voir dans la figure 4 qui suit, le dsambiguseur a t supprim, ainsi que le dcoupage en chunks. Ils taient en effet peu utiles pour les langues supportes (l'anglais principalement), et surtout l'origine d'erreurs d'tiquetage, entranant par la suite beaucoup de bruit (dtection de fautes qui n'en sont pas).
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.
3.2.2. Structure actuelle de LanguageTool Texte vrifier

phrases et tokens texte tiquet texte tiquet dsambigus phrases segmentes en chunks
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 :

la segmentation du texte en phrases, puis en mots
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.
Les rgles d'erreurs sont formalises en XML, et composes de plusieurs lments :
id et name : l'identifiant et le nom de la rgle.
: 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
Chapitre 1 : Existant Voici un exemple de rgle en franais :

<rule name="ma (m'a)" id="MA"> <pattern mark_to="-1"> <token>ma</token> <token postag="V.*" postag_regexp="yes"/> </pattern> <message>Voulez vous crire<suggestion>m'a</suggestion>? </message> <example type="incorrect">Il <marker>ma</marker>rpondu. </example> <example type="correct">Il <marker>m'a</marker>rpondu. </example> </rule>
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).
Chapitre 2 : Adaptation de LanguageTool la correction du franais
22

Comme nous l'avons dj indiqu, LanguageTool pourrait devenir, aprs quelques modifications, un correcteur grammatical bien adapt au franais. C'est pourquoi nous avons dcid de commencer travailler sur cet outil. Ce chapitre dcrit comment nous avons dot le correcteur des rgles ncessaires la dtection des fautes de grammaire. Tout d'abord, nous avons test rapidement quelques rgles en franais, dj prsentes dans le correcteur. Ce test nous a permis de mettre en vidence les inconvnients de l'absence de dsambiguseur dans LanguageTool. Nous avons donc t amene en dvelopper un prototype. Notre travail a consist ensuite importer les rgles crites pour An Gramadir. Nous allons voir les problmes rencontrs, ainsi que les diffrentes modifications que nous avons d apporter aux rgles pour qu'elles fonctionnent correctement dans LanguageTool. Nous avons aussi complt la base de rgles d'erreurs, partir d'un corpus de fautes que nous avons tudi, et dont nous avons extrait des erreurs non encore traites par le programme. Pour finir avec ce travail sur les rgles, nous verrons quelle est la typologie des fautes que LanguageTool est finalement capable de dtecter en franais.
1. Test des rgles existantes

Parmi les rgles d'erreurs crites par Lechelt (2005) pour An Gramadir, une petite dizaine avait t importe dans LanguageTool par Marcin Mikowski, un des principaux dveloppeurs du programme. Dans un premier temps notre travail a consist tester rapidement ces quelques rgles, afin de nous familiariser avec le formalisme utilis, et de reprer des problmes ventuels, pour nous permettre par la suite de raliser l'importation des nouvelles rgles dans les meilleures conditions.
1.1. Test et erreurs dtectes

Les rgles franaises dj prsentes dans LanguageTool concernent la confusion entre des mots grammaticaux homophones : a/sa, a/, se/ce, ma/m'a et sont/son. Nous avons test ces rgles sur des petites phrases trs simples, que nous avons crites. Chacune contient au moins un des mots sur lesquels portent les rgles. Le tableau ci-aprs reprend quelques unes de ces phrases, et donne en colonne de droite la suggestion de correction indique par le programme. Les phrases prcdes de "*" sont des phrases agrammaticales.
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.
1.2. Problme de l'ambigut catgorielle

Nous avons vu prcdemment que la dernire version de LanguageTool ne fait pas de dsambigusation. Sachant cela, les rsultats obtenus notre test n'ont rien de surprenant. Les mots ambigus ont plusieurs tags. Lors de l'application des rgles d'erreurs, il suffit que l'un d'entre eux corresponde une rgle pour que celle-ci soit applique, mme si un ou plusieurs autres tags du mot ne correspondent pas cette rgle. Prenons en exemple les deux rgles portant sur la confusion entre sa et a : 1. Si sa est suivi d'un verbe ou d'un pronom, alors il y a une erreur. Il faut remplacer sa par a. 2. Si a est suivi d'un nom, alors il y a une erreur. Il faut remplacer a par sa.
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>]
b) *a voiture est en panne.

<S> a [a/A, a/R dem m 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 [est/V etre ind pres 3 s, est/J e p,est/J e s, est/N m s] en [en/P, en/R pers obj e sp] panne [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.
1.3. Tentative de contournement du problme

Nous avons tent de rduire le bruit provoqu par la rgle 1 en la modifiant. Par exemple : sa, suivi d'un verbe, suivi de tout mot l'exclusion d'un verbe. Il est rare que deux verbes se suivent, sauf dans les temps composs. En dehors des auxiliaires, s'il y a deux verbes aprs sa, c'est alors sans doute parce que le premier est en fait ambigu avec un nom. Dans ce cas, aucune erreur ne doit tre dtecte, et la rgle doit donc tre applique au contraire s'il n'y a pas deux verbes aprs sa. La rgle ainsi modifie permet de pallier en partie le problme de l'ambigut de voiture, mais nous avons ralis alors qu'il serait ncessaire d'avoir des rgles beaucoup plus complexes et prcises pour contourner l'absence de dsambigusation, et le fait que beaucoup de mots ont plusieurs tiquettes. Nous avons donc pris conscience du fait qu'il est absolument ncessaire d'ajouter un dsambiguseur LanguageTool, entre le tagging et la vrification des phrases. Le petit test ralis n'avait pas pour but d'valuer la qualit du programme. Il nous a juste permis de nous familiariser un peu avec lui, et surtout de mettre en vidence un des principaux problmes de l'outil, savoir l'ambigut des tags d'un grand nombre de mots.
2. Implantation d'un dsambiguseur

La version de LanguageTool sur laquelle nous avons travaill disposait depuis peu d'une interface pour l'implantation d'un dsambiguseur, mais l'outil en lui mme n'avait pas t dvelopp. Nous avons donc rflchi la manire de le raliser.
2.1. Choix d'un type de dsambiguseur

Comme nous l'avons expliqu dans le chapitre 1 dans le point 1.2. sur la structure d'un correcteur grammatical, il existe deux types de dsambiguseurs : statistiques, ou base de rgles. Nous avons dj mentionn plusieurs dfauts des outils statistiques, comme la ncessit d'un corpus d'apprentissage et la dpendance celui-ci. Notre choix a donc port sur un dsambiguseur base de rgles. De plus, nous disposions dj d'une base de rgles que nous pouvions rutiliser, savoir celle crite par Lechelt (2005), pour An Gramadir.
26
2.2. Choix d'un formalisme pour les rgles

Un formalisme est un langage qui permet de dcrire des phnomnes linguistiques de manire non-ambigu, afin de pouvoir tre compris et trait par un ordinateur. Il possde pour cela les mmes caractristiques que les langages informatiques, savoir la non-ambigut smantique et syntaxique. Notre choix ayant port sur un dsambiguseur base de rgles, il nous fallait dfinir un formalisme pour reprsenter ces rgles. Nous avions plusieurs possibilits : Nous pouvions les rcrire dans un simple format texte, en supprimant les balises (, <Z>, etc.) et en sparant les informations par des tabulations par exemple. L'avantage de cette mthode est la rapidit de traitement par le programme. Nous pouvions aussi utiliser des expressions rgulires, un peu comme dans An Gramadir, avec le systme "rechercher-remplacer". Mais de telles rgles sont compliques rdiger, et leur traitement coteux en Java. La solution qui nous a sembl la meilleure tait la rcriture en XML. Bien que plus lourd traiter par le programme, ce formalisme a plusieurs avantages. Tout d'abord, il est dj utilis pour les rgles d'erreurs. Il semble plus cohrent que les diffrents types de rgles soient reprsents de manire similaire au sein d'un mme programme. C'est aussi un formalisme assez ouvert qui permet l'implantation de nombreuses fonctionnalits et l'criture simplifie de rgles. Mais il est surtout beaucoup plus facilement lisible et modifiable par des linguistes, qui ne sont pas ncessairement informaticiens. Ceci est un point trs important si nous voulons raliser un correcteur accessible toute personne souhaitant contribuer son dvelopement et l'enrichissement de la base de rgles. Dans le chapitre 2 dans le point 3.1., nous expliquons comment nous avons rcrit les rgles de dsambigusation pour les adapter au formalisme que nous avons choisi.
2.3. Intgration dans LanguageTool

Aprs avoir dfini le type d'outil ncessaire, il ne nous restait plus qu' en crire le code en Java. Nous avons commenc par tudier la manire dont les rgles d'erreurs en XML sont charges, puis utilises par le programme, puisque nous devons raliser un traitement peu prs similaire pour les rgles de dsambigusation. Nous avons identifi les classes impliques dans le processus, et que nous devions adapter pour l'implantation d'un dsambiguseur. Comme nous ne matrisions pas suffisamment le langage Java pour raliser nous mme le code dans un dlai raisonnable, Mikowski, un dveloppeur de LanguageTool qui avait ralis l'importation des premires rgles franaises, nous a propos son aide. Pour crire le code ncessaire l'implantation de notre dsambiguseur, il avait besoin d'un fichier XML contenant quelques rgles, de la DTD1 correspondante, ainsi que d'un petit corpus de phrases pour effectuer des tests. Pour la DTD, nous avons repris celle des rgles d'erreurs, rules.dtd, puisque nous avons choisi
1
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.
3. Importation des rgles de An Gramadir dans LanguageTool

Dans le chapitre prcdent, nous avons parl des rgles construites par (Lechelt, 2005) pour An Gramadir, savoir les rgles pour la dsambigusation et pour la dtection des fautes. Nous avons rcrit toutes ces rgles de manire ce qu'elles soient utilisables dans le formalisme de LanguageTool.
3.1. Importation des rgles de dsambigusation

3.1.1. Reprsentation en XML
LanguageTool ne disposait pas de dsambiguseur avant que Mikowski ne nous aide en implanter un. Il n'existait pas de fichier de rgles de dsambigusation au sein du programme. Nous avons donc cr un nouveau fichier de rgles, et dfini une manire de reprsenter ces rgles en XML, le formalisme choisi. Pour commencer, rappelons la structure des rgles de dsambigusation de An Gramadir :
<Z>ANYDFS</Z>ANYTHING <N>ANYTHING</N>:<D f s>
De manire gnrale, le mot ambigu et ses tags sont entours des balises , 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 :

<rule name="ma (m'a)" id="MA"> <pattern mark_to="-1"> <token>ma</token> <token postag="V.*" postag_regexp="yes"/> </pattern> <message>Voulez vous crire<suggestion>m'a</suggestion>? </message> <example type="incorrect">Il <marker>ma</marker>rpondu. </example> <example type="correct">Il <marker>m'a</marker>rpondu. </example> </rule>
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").
3.1.2. Rcriture des rgles

Une fois leurs structures dfinies, nous avons pu commencer la rcriture des rgles de dsambigusation de An Gramadir. Comme elles n'taient pas trs nombreuses (environ 150), nous avons procd manuellement, en prenant soin d'effectuer quelques tests de contrle au fur et mesure.
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.
a) Gnralisation et regroupement de certaines rgles

Nous avons trs vite pu remarquer que le formalisme XML, beaucoup plus souple que celui de An Gramadir, permettrait de gnraliser, de regrouper certaines rgles, et d'en rduire ainsi le nombre. Les rgles concernant la dsambigusation des verbes conjugus s'appuient toutes directement sur les pronoms personnels je, tu, il, nous et vous, et non sur leurs tiquettes. Nous avons prfr utiliser l'tiquette de chaque pronom, plutt que le pronom lui-mme. Ainsi, au lieu de : je + V, nous avons crit : R pers suj 1 s + V. Ceci a par ailleurs permis d'tendre elles, ou elle et on, les rgles qui ne prenaient en compte que ils ou il.
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 :
ne + X + X + pas : ne + X + pas : ne + pas :
[Nn]e ANYTHING ANYTHING pas:<A> [Nn]e ANYTHING pas:<A> [Nn]e pas:<A>
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 :
Dterminant ambigu + Nom = Dterminant

<Z>ANYDMS</Z>ANYTHING <N>ANYTHING</N>:<D m s>
Dterminant ambigu + Adjectif = Dterminant

<Z>ANYDMS</Z>ANYTHING <J>ANYTHING</J>:<D m s>
Nous les avons runies pour ne faire qu'une seule srie de rgles : Dterminant ambigu + Nom OU Adjectif = Dterminant

<rule name="Det ambigu"> <pattern mark="0"> <token postag="D.*" postag_regexp="yes"/> <token postag="N.*|J.*" postag_regexp="yes"/> </pattern> <disambig> <match no="1" postag_regexp="yes" postag="D.*"/> </disambig> </rule>
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.
3.2. Importation des rgles d'erreurs

D'une part, nous avons parl plus haut d'une dizaine de rgles sur les homophones grammaticaux (a/sa, a/, se/ce, ma/m'a et sont/son), dj importes dans LanguageTool par Mikowski. D'autre part, le fichier de rgles d'erreurs cr par Lechelt (2005) pour An Gramadir comporte environ 520 entres. Il nous restait donc un peu plus de 500 rgles importer. Parmi elles, environ 90% concernent les syntagmes nominaux, et les 10% restant concernent les syntagmes verbaux.
3.2.1. Rcriture automatique

Nous n'avons pas rcrit toutes les rgles la main car elles taient trop nombreuses. Nous avons donc cr un petit programme en Python permettant de les transformer automatiquement en XML, c'est--dire de dfinir leur nom (name), leur identifiant (id), le modle de la faute (pattern), le message (message) et les exemples (example) destination de l'utilisateur. Ainsi, par exemple, la rgle de An Gramadir du type :
<DS>ANYTHING</DS> <JS>ANYTHING</JS> <NP>ANYTHING</NP>:NOMBRE
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
3.2.2. Rcriture des rgles sur les syntagmes verbaux

Nous avons en premier lieu travaill sur la partie pattern des rgles, avant de personnaliser les messages et exemples retourns l'utilisateur.
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 verbe la 1re personne du pluriel

[Jj]e <VUNP>ANYTHING</VUNP>:AGGREEMENT
je est suivi d'un verbe la 2me ou 3me personne

[Jj]e <VUN>ANYTHING</VUN>:AGGREEMENT
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
Dans LanguageTool, nous avons tout regroup en une seule rgle :

<rule name="je + (x) + V"> <pattern> <token postag="R pers suj 1 s" postag_regexp="yes" skip="1"/> <token postag="V.* 1 p|V.* 2 .*|V.* 3.*" postag_regexp="yes"/> </pattern> <message>Le pronom personnel n'est pas accord avec le verbe </message> <example type="correct">je travaille</example> <example type="incorrect">je travaillons</example> </rule>
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.
b) Le message et les exemples

Le programme que nous avons crit, pour transformer les rgles automatiquement, a gnr pour chacune d'elle un message et des exemples par dfaut, qu'il a fallu par la suite personnaliser. Nous avons donc rdig un message pour chaque type de faute, et des exemples adapts chaque situation. Ainsi, pour les rgles d'accord entre le pronom personnel et le verbe, nous avons crit le message : "Il y a une faute d'accord entre le pronom personnel et le verbe", et nous avons cr des exemples, corrects et incorrects, pour chaque rgle : "je travaille" et "*je travaillez", "tu travailles" et "*tu travaillent", etc.
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".
b) Des dtections multiples

En testant les rgles importes de An Gramadir, nous avons trs vite t confronts un problme de dtection multiple d'une mme faute. La raison en est trs simple. Prenons par exemple le syntagme erron *un jupe longue bleue. Le dterminant masculin un n'est pas accord avec le reste du syntagme qui est au fminin. L'erreur va tre dtecte une premire fois par la rgle D N J J qui correspond exactement au modle du syntagme. La liste de rgles continue ensuite d'tre parcourue par le programme, et l'erreur va alors tre dtecte une seconde fois par la rgle D N J, car son pattern correspond aux 3 premiers mots du syntagme. Puis une dernire rgle D N dtectera la faute une troisime fois. Selon la composition du syntagme, et la place de la faute dans celui-ci, une mme erreur peut tre dtecte jusqu' trois fois. Nous avons alors essay de crer des rgles, trs gnrales, pour remplacer toutes les rgles prcdentes. Au lieu de prendre en compte chaque combinaison possible, nous avons simplement dit qu'un dterminant, un nom, ou un adjectif singulier ne peut pas tre suivi ou prcd d'un dterminant, d'un nom ou d'un adjectif pluriel. Voici les patterns des deux rgles que nous obtenons :
<pattern> <token postag="D .* s|J .* s|N .* s" postag_regexp="yes"/> <token postag="J .* p|N .* p" postag_regexp="yes"/> </pattern> <pattern> <token postag="D .* p|J .* p|N .* p" postag_regexp="yes"/> <token postag="J .* s|N .* s" postag_regexp="yes"/> </pattern>
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.
4. Augmentation des rgles partir d'un corpus de fautes

Grce l'importation des rgles que nous venons de raliser, LanguageTool est dsormais capable de corriger plusieurs types de fautes en franais. Pour complter notre base de rgles d'erreurs, et tendre ainsi la couverture des fautes dtectes, J.P. Chevrot et A. Millet ont mis notre disposition un corpus de fautes (COVAREC, 1994) constitu par l'quipe COVAREC du laboratoire LIDILEM de l'Universit Stendhal-Grenoble 3. Ce corpus runit les "variations orthographiques" extraites de 337 documents manuscrits divers, produits par 306 scripteurs : 31 prises de notes et 31 copies d'examen d'tudiants en licence de Lettres Modernes, 31 devoirs de franais de 31 lves de B.E.P. Comptabilit Administration Secrtariat, 93 demandes d'emploi, dont 44 pour un emploi dans le secteur priv, et 49 pour un poste d'opratrice de saisie dans le secteur public, 100 lettres de 100 locataires des H.L.M. un service administratif, 51 notes d'ducateurs dans des cahiers de liaison.
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.
4.1. Analyse des fautes commises

4.1.1. Fautes d'orthographe
D'un point de vue informatique, une faute d'orthographe est dtecte dans un mot lorsque celuici est inconnu du lexique utilis par le correcteur. LanguageTool n'ayant pas cette fonction de correction il ne lui est pas possible de traiter de telles fautes. Nous avons donc cart du corpus toutes les phrases ne comportant, aux yeux d'un informaticien, que des fautes d'orthographe. Nous verrons cependant, dans le point 5.2 du chapitre 2, que contrairement l'informatique, la linguistique rattache certaines de ces erreurs la grammaire.
4.1.2. Fautes dj dtectes par LanguageTool

Le corpus contient un certain nombre de fautes qui sont dj traites par les rgles que nous avons importes de An Gramadir. Il s'agit principalement des erreurs d'accord dans le groupe nominal, des erreurs d'accord entre le pronom personnel sujet et le verbe, des confusions entre les infinitifs et les participes passs, et de la mauvaise formation du participe pass. Nous reviendrons plus en dtail sur ces fautes dans le chapitre 2 point 5.
37
4.1.3. Fautes a priori non dtectables

Nous avons repr un certain nombre de fautes qui semble impossibles dtecter, ni avec LanguageTool, ni mme avec les outils TAL (Traitement Automatique des Langues) dont nous disposons actuellement. Il s'agit par exemple des rfrences anaphoriques, des reprises d'informations d'une phrase prcdente. Dans une phrase comme : "Jean l'a laiss tomber hier soir" dans laquelle le complment d'objet l' a en fait pour rfrent une femme cite plus tt dans le texte, il n'est pas possible de dtecter que laiss est mal accord et aurait d tre au fminin : laisse. La dtection de ce type de fautes impliquerait un traitement un niveau suprieur celui de la phrase, c'est--dire au niveau du texte ou du paragraphe. Or la correction grammaticale est pour le moment limite la phrase. Nous pouvons signaler cependant que des travaux sur le traitement des anaphores en TAL sont en cours, mais ne sont pas encore trs avancs (Boudreau & Kittredge, 2005). Le niveau smantique serait parfois aussi ncessaire pour dtecter certaines erreurs, comme les problmes de concordance des temps par exemple. Dans la phrase : "Occupant un emploi saisonnier, je ne serais disponible qu' partir du 1er septembre." comment savoir, sans le contexte de la phrase et sans une interprtation smantique, s'il faut bien utiliser le conditionnel, ou au contraire le futur, dans quel cas une faute aurait pu tre dtecte sur la forme conjugue serais. Nous laissons donc de ct les phrases contenant ce type de fautes, puisque nous ne serons pas en mesure de rajouter des rgles pour les dtecter.
4.1.4. Fautes dtectables avec un nouveau formalisme

Le formalisme actuel de LanguageTool ne permet pas de corriger un grand nombre de fautes de grammaire. L'accord du verbe avec le sujet, lorsque ce dernier n'est pas un pronom personnel, l'accord du participe pass avec le complment d'objet antpos, ou encore l'accord du verbe aprs un pronom relatif en sont autant d'exemples. Ainsi, les erreurs suivantes ne peuvent pas tre identifies actuellement : "*... les enfants ralise ...", "*... tre entour de gens qui vous considre ...", "*... les diffrents stages que j'ai effectu ...". Un formalisme fond sur les chunks et l'unification de structures de traits, tel que Lechelt (2005) l'a suggr, et dont nous reparlons dans la suite de ce mmoire, permettra de traiter une partie de ces fautes.
4.1.5. Fautes dtectables avec le formalisme actuel de LanguageTool

Les autres erreurs contenues dans le corpus semblent dtectables par LanguageTool, si nous constituons quelques nouvelles rgles. Nous pensons ainsi pouvoir traiter, entre autres, les cas suivants : Participe pass au pluriel lorsque l'auxiliaire tre est au singulier, et inversement : "*...le prix est trs exagres...", "*Ces diffrences en gnral sont li...", "*...nous ne sommes pas venu..."
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.
4.2. Rdaction de nouvelles rgles d'erreurs

Nous avons rdig quelques rgles en fonction des erreurs que nous avons observes dans le corpus et que nous pensions pouvoir traiter. Pour chacune, nous donnons en exemple le patron de la faute, donc la partie pattern de la rgle, telle que nous l'avons dfinie pour que celle-ci fonctionne comme nous le souhaitions.
4.2.1. Accord Dterminant + Nom + Verbe

Nous avons tout d'abord cr deux rgles pour dtecter une faute d'accord entre un verbe et son sujet, constitu d'un dterminant et d'un nom, et situ en dbut de phrase. Une rgle concerne le cas d'un nom au singulier avec un verbe au pluriel, et l'autre rgle s'applique au cas contraire. Voici le patron de l'erreur tel que nous l'avons dfini dans les rgles :
<pattern mark_from="1"> <token postag="SENT_START"/> <token postag="D.*" postag_regexp="yes"/> <token postag="N .* s" postag_regexp="yes"/> <token postag="V.*" postag_regexp="yes"> <exception postag="V .* 3 s" postag_regexp="yes"/> </token> </pattern>
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
4.2.2. Accord en nombre tre + Participe pass ou Adjectif

Nous avons ensuite ajout une rgle permettant de vrifier que le participe pass est bien accord en nombre avec l'auxiliaire tre. Des rgles similaires existaient dj avec les pronoms personnels comme sujets, mais pas avec un autre groupe nominal.
<pattern mark_from="1"> <token postag="V etre .* s" postag_regexp="yes" skip="1"> <exception>t</exception> </token> <token postag="V ppa .* p|J .* p" postag_regexp="yes"/> </pattern>
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.
4.2.3. Confusion entre la forme verbale et la forme nominale

La rgle suivante, que nous avons crite, permet de traiter les cas o un nom est utilis la place d'un verbe, aprs le pronom personnel sujet, comme dans "* je travail" ou "* on dsir".
<pattern mark_from="1"> <token postag="R pers suj .*" postag_regexp="yes"/> <token postag="N.*" postag_regexp="yes"/> </pattern>
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.
4.2.4. Confusion entre "on" et ont"

Le pronom sujet on est souvent confondu avec la forme conjugue de l'auxiliaire avoir ont. La rgle que nous avons cre pour dtecter cette erreur prend en compte ont suivi d'un verbe conjugu.
<pattern mark_to="-1"> <token>ont</token> <token postag="V.*" postag_regexp="yes"> <exception postag="V ppa .*" postag_regexp="yes"/> </token> </pattern>
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
4.2.5. Confusion entre "cet", "cette", "ces" et "c'est"

Pour que la rgle suivante fonctionne, nous avons d utiliser directement les mots et non les tags. Il s'agit d'une rgle pour signaler l'utilisation errone de cette ou cet la place de c'est.
<pattern mark_to="-1"> <token regexp="yes">cette|cet</token> <token regexp="yes">un|une</token> </pattern>
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>
4.2.6. Accord Pronom relatif "qui" + Verbe :

Il n'est pas possible avec le formalisme actuel de vrifier que le verbe d'une relative est bien accord en nombre. En revanche, nous pouvons signaler une erreur s'il n'est pas la 3me personne. En effet, le verbe aprs un relatif (ici qui) est la 3me personne, singulier ou pluriel, sauf lorsqu'un pronom personnel de la 1re ou 2me personne est utilis dans la construction c'est ... qui .... ("c'est nous qui avons..."). Nous avons donc essay de rdiger une rgle en tenant compte de tous ces lments. Nous avons alors obtenu beaucoup de fausses alarmes lors de la prsence d'une prposition avant qui. En effet, dans ce cas, le verbe suivant peut avoir pour sujet un pronom la 1re ou 2me personne. ("...la personne qui vous confieriez..."). Nous avons finalement pu crire une rgle qui convient. Elle s'applique lorsque le pronom relatif qui n'est pas prcd d'un pronom personnel ou d'une prposition, et lorsque le verbe n'est pas la 3me personne.
<pattern mark_from="1"> <token postag="R pers .*|P" postag_regexp="yes" negate_pos="yes"/> <token postag="R rel .*" postag_regexp="yes" skip="1">qui</token> <token postag="V .* 1 .*|V .* 2 .*" 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.
5. Typologie des erreurs corriges

5.1. Les erreurs corriges par LanguageTool
L'analyse du corpus avec lequel nous avons travaill, ralise par A. Millet et V. Lucci (Lucci & Millet, 1994), a mis en vidence les erreurs grammaticales les plus frquentes. Il s'agit principalement de l'omission des marques de genre ou de nombre sur les mots des groupes nominaux, de substitution des marques de temps, de mode ou de personne sur les verbes, et d'erreurs de proximit phontique. Nous allons voir que ce sont ces mmes fautes que LanguageTool est dsormais capable de dtecter, depuis que nous avons import des rgles d'erreur de An Gramadir et que nous en avons cr de nouvelles.
5.1.1. Les erreurs de proximit phontique

Les mots grammaticaux homophones sont souvent confondus l'crit. Des rgles permettent donc de les vrifier. Les confusions suivantes sont traites : a la place de sa ex. : "* je suis all a maison" sa la place de a ex. : "* sa se voit" a la place de ex. : "* ne plus avoir a faire..." se la place de ce ex. : "* se sont des gens..." ce la place de se ex. : "* l'auteur ce demande..." ma la place de m'a ex. : "* a ma tait refus" son la place de sont ex. : "* ils son dans la mme classe" sont la place de son ex. : "* elle n'a pas sont mot de passe" cette ou cet la place de c'est ex. : "* cette une grande tendue..." c'est la place de ces, cet ou cette ex. : "* c'est phrase veut dire..." en temps que la place de en tant que ex. : "* en temps que locataires..." ont la place de on ex. : "* ont a tendance..." Nom la place du Verbe aprs un pronom personnel sujet ex. : "* on dsir..." Beaucoup d'autres erreurs de ce type pourraient tre corriges avec de nouvelles rgles. Mais nous n'aurons jamais une liste exhaustive de toutes les confusions possibles.
5.1.2. Les erreurs d'accord dans le syntagme nominal

Il peut s'agir aussi bien d'accord en genre qu'en nombre. Les erreurs sont dtectes dans les syntagmes correspondant aux patrons suivants, o D est un dterminant, J un adjectif, N un nom, et Y un nombre :

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.
5.1.3. Les erreurs dans le groupe verbal

LanguageTool reconnat les erreurs dans l'utilisation de l'infinitif ou du participe pass, qui sont souvent confondus l'un avec l'autre. Aprs un auxiliaire, une faute est dtecte si le verbe est l'infinitif, comme dans les exemples suivants : "* qui serait neutraliser" "* j'ai trouver" "* nous avons essayer" Au contraire, aprs un verbe conjugu (sauf si c'est un verbe d'tat), si le verbe n'est pas l'infinitif, alors une rgle s'applique pour signaler l'erreur. C'est le cas dans ces extraits : "* ils vont entrs" "* il faut utilis" "* j'ai pu constat"
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
5.1.4. Les erreurs d'accord avec le sujet

Tout comme les rgles ci-dessus, les suivantes fonctionnent correctement mais ont une couverture limite par un pattern prcis et fig. Une premire srie de rgles concerne l'accord entre les pronoms personnels sujets et les verbes. "* j'tait" - "* on devrez" "* je me permet" sont des exemples de fautes reconnues par l'outil.
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..."
5.2. Des fautes d'orthographe ou de grammaire ?

Lorsque nous avons analys le corpus pour en extraire de nouvelles rgles, nous avons dit avoir cart toutes les phrases ne contenant que des fautes considres comme orthographiques en informatique. Nous sommes cependant aussi linguiste, et nous avons d liminer des phrases dont les erreurs taient nos yeux plutt de l'ordre de la grammaire. Cela nous amne parler des diffrences de points de vue entre les linguistes et les informaticiens, sur les domaines de la grammaire et de l'orthographe.
5.2.1. Point de vue linguistique : orthographe lexicale et orthographe grammaticale

En linguistique, nous parlons d'orthographe pour tout ce qui touche la manire d'crire les mots. Les fautes communment appeles "d'orthographe" et "de grammaire", sont respectivement du domaine de l'orthographe lexicale et de celui de l'orthographe grammaticale. Ainsi, il n'y a pas d'opposition entre grammaire et orthographe, mais plutt entre grammaire et lexique. L'orthographe lexicale, ou orthographe d'usage, correspond la manire d'crire les mots tels qu'indiqus dans les dictionnaires, sans que soit prise en compte leur fonction dans la phrase. Chaque mot a une orthographe dfinie, qui ne dpend pas de la grammaire, mais uniquement du lexique. Certains phonmes peuvent tre crits de diffrentes manires, comme par exemple [] dans balai, marais, souhait, procs, poney, etc. Ces diffrentes graphies n'ont pas de signification grammaticale. Pour savoir laquelle correspond au mot que nous souhaitons crire, il faut avoir recours un dictionnaire. Une "faute d'orthographe" correspond une diffrence de graphie d'un mot, par rapport celle dfinie dans les dictionnaires. Les mots dits invariables ne sont concerns que par l'orthographe lexicale, de mme que le radical des mots variables. En revanche, les variations dont sont sujets certains mots , comme les marques flexionnelles, sont du ressort de l'orthographe grammaticale. L'orthographe grammaticale est aussi appele orthographe de rgle ou orthographe d'accord. Elle correspond aux modifications des mots en fonction de leur rle dans la phrase. Elle rgit
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.
5.2.2. Point de vue informatique : correction orthographique et correction grammaticale

En informatique, les notions de grammaire et d'orthographe ne sont pas exactement les mmes qu'en linguistique. La distinction entre les deux types de fautes se fait en fonction du correcteur automatique qui est capable de la dtecter. Nous prcisons ici que le terme "correcteur" communment utilis en informatique n'est pas tout fait appropri. En effet, les outils recherchent les fautes et font ventuellement des suggestions de correction, que l'utilisateur est libre d'accepter ou pas, mais en aucun cas ils ne corrigent automatiquement les erreurs. Il existe deux sortes de correcteurs : orthographiques et grammaticaux. Les correcteurs orthographiques fonctionnent partir d'un lexique de formes flchies, c'est-dire de toutes les flexions des mots, et non partir des seules entres des dictionnaires, qui sont constitues par les lemmes. Lorsqu'ils rencontrent un mot qui ne figure pas dans leur lexique, ils signalent une erreur d'orthographe. Le mot "orthographe" a ici un sens plus restreint qu'en linguistique. Il se rfre toujours la graphie des mots, mais sans qu'il soit question de distinction entre les fautes sur la graphie des radicaux par exemple, qui sont d'ordre lexical, et les fautes sur la graphie des dsinences qui sont de l'ordre du grammatical, d'un point de vue linguistique. Il serait plus appropri, en informatique, de parler d'erreur de graphie, ou d'pellation au lieu de faute d'orthographe. L'anglais utilise d'ailleurs le terme spellchecker pour dsigner ce que nous appelons maladroitement "correcteur orthographique". Pour un informaticien, tout mot qui n'appartient pas au lexique utilis par le correcteur est donc considr comme mal orthographi. partir de l, les fautes de grammaire sont trs faciles dfinir. Elles recouvrent toutes les erreurs qui ne sont pas dtectables par un correcteur orthographique. Les correcteurs grammaticaux, tels LanguageTool, ont pour vocation de corriger, ou plutt de dtecter et signaler ce type de fautes, mais ils ne sont en ralit capables d'en traiter qu'une partie. D'un point de vue informatique, les exemples "* toujoures" ou "* ils dorments" sont des fautes d'orthographe, mais "* j'ai cris" est une erreur grammaticale.
45
5.2.3. Chevauchement des fautes d'orthographe et de grammaire

Linguistes et informaticiens n'ont donc pas tout fait la mme notion de l'orthographe et de la grammaire. Du point de vue de l'un ou de l'autre, certaines fautes ne sont pas classes dans la mme catgorie. Il y a un chevauchement des niveaux orthographique et grammatical, en informatique et en linguistique, que nous reprsentons dans la figure 5. Nous voyons sur ce schma, dans la zone hachure, un exemple des fautes qui sont cheval sur les deux niveaux.
INFORMATIQUE :
ORTHOGRAPHE chevauchement orth./gram
GRAMMAIRE
LINGUISTIQUE :
ORTHOGRAPHE
GRAMMAIRE
Exemples de fautes :
- toujoures - namoins - aquis
- ils dorments - vous comprendrer - lequelle
- j'ai cris - des formule - sa se voit
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.
5.3. Les fautes du dactylographe

Nous avons parl des erreurs que corrige LanguageTool, de la distinction entre les fautes "de grammaire" et les fautes "d'orthographe" pour le linguiste et pour l'informaticien, mais il y a encore un autre type d'erreurs que nous n'avons pas abord. Il s'agit des fautes particulires commises par les dactylographes. Il est frquent, lorsque nous n'crivons pas la main mais avec un clavier , de commettre ce qui est communment appel des fautes de frappe. Dans un prcdent travail, nous avions dj
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.
Chapitre 3 : Amlioration du formalisme de LanguageTool
48

Les formalismes grammaticaux sont avant tout des langages destins servir la description des langues elles-mmes, soit, en dautres termes, dcrire lensemble des phrases possibles dune langue (lensemble des chanes bien formes), les proprits structurales de ces phrases (leur syntaxe) et leur signification (leur smantique). Chaque grammaire particulire est crite dans un formalisme grammatical (le mtalangage) qui code une analyse dune langue objet (Miller & al., 1990) Dans ce chapitre, aprs avoir critiqu les limites de LanguageTool, nous prsentons une volution possible du formalisme, dans lequel nous ne dcrivons pas des phrases de la langue, comme dans la dfinition ci-dessus, mais un ensemble de sous-structures incorrectes de la langue. Ce formalisme se fonde sur des principes linguistiques que nous expliquons.
1. Critique des limites du formalisme actuel

L'criture des rgles nous a permis de prendre conscience du problme du pattern-matching rigide, mentionn dans (Lechelt, 2005) lors de l'adaptation de An Gramadir. En effet, le texte erron doit coller parfaitement au patron d'une rgle d'erreur, pour que la faute soit signale. Nous expliquons en quoi un tel fonctionnement est problmatique. Nous mentionnons ensuite d'autres points faibles de l'outil, l'origine de nombreuses fausses alarmes dans la dtection des fautes.
1.1. Le "pattern-matching" rigide

Mme si le formalisme de LanguageTool permet un pattern-matching plus souple que dans An Gramadir, il n'en reste pas moins contraignant pour l'criture de rgles. Le principal reproche que nous ferons une telle mthode est d'imposer de prvoir tous les contextes de fautes possibles et de les numrer dans autant de rgles. Mais nous verrons qu'il n'est pas possible d'tre exhaustif, ce qui conduit un grand nombre de fautes non dtectes.
1.1.1. Explosion combinatoire des rgles

Lors de l'importation et de la rdaction des rgles, nous avons vu que, pour dtecter toutes les fautes d'un type donn, il faut prvoir tous les combinaisons de mots o elles sont susceptibles d'apparaitre. Prenons l'exemple des fautes au sein d'un syntagme nominal. Lechelt (2005) a rdig quelques 450 rgles s'appliquant diverses combinaisons possibles de dterminants, noms et adjectifs. (Nous en donnons la liste au chapitre 2 point 5.1.2). Il s'agit d'un nombre relativement important de rgles, qui ne couvrent cependant qu'une faible partie des cas possibles. En effet, les mots picnes et les mots invariables ne sont par exemple pas pris en compte. Des syntagmes comme "* un clbre actrice" ou "* des procs interminable.", qui contiennent respectivement un mot picne et un mot invariable, ne seront donc jamais signals comme faux.
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.
1.1.2. Ncessit et impossibilit de prvoir tous les contextes a) numration de rgles

Pour couvrir toutes les fautes, l'unique solution est de faire l'inventaire des contextes o elles peuvent apparaitre, ce qui revient numrer des combinaisons de mots errones. Nous venons de voir l'explosion combinatoire laquelle conduit une telle numration pour les syntagmes nominaux, mais d'autres contextes sont tout autant impossibles numrer exhaustivement. Nous avons d'ailleurs rencontr ce problme dans presque toutes les rgles sur lesquelles nous avons travaill. Les fautes de proximit phontique en sont un autre exemple. Nous sommes obligs de crer une rgle pour chaque confusion d'homophones, ce qui revient dresser une liste aussi complte que possible de ces fautes. Il s'ensuit de trs nombreuses rgles, qui ne permettent pourtant pas de couvrir toutes les erreurs de cette catgorie. Par ailleurs, pour viter de fausses alarmes, nous avons d limiter beaucoup de rgles des contextes trs prcis. Ce qui conduit aussi la ncessit de crer de nombreuses rgles.
50
b) Silence dans la dtection des fautes

Puisque nous ne pouvons pas dcrire tous les contextes de fautes, mme en rdigeant des centaines de rgles, il y aura toujours des combinaisons de mots que nous n'aurons pas prvues et qui ne correspondront aucun pattern. Ce sont donc autant d'erreurs qui seront passes sous silence, et ce pour les diverses raisons que nous allons voir. Mots mal orthographis Tout d'abord, il est impossible de prvoir toutes les fautes d'orthographe qui peuvent tre commises. Or, si un mot est mal orthographi, il ne peut pas tre reconnu par les rgles qui auraient d le concerner. LanguageTool ne dispose en effet d'aucune fonction de traitement de l'orthographe. Les mots mal crits ne sont pas tiquets par le tagger s'il ne les trouve pas dans son lexique. Toutes les rgles qui ont dans leur pattern, soit le mot tel qu'il aurait d tre orthographi, soit l'tiquette qu'il aurait d avoir, deviennent alors inutilisables. Ce sont autant d'erreurs ventuelles qui ne sont pas dtectes. Mots mal tiquets Les mots mal tiquets peuvent avoir les mmes consquences que les mots mal orthographis. Une mauvaise tiquette peut empcher l'application d'une rgle et gnrer ainsi du silence. Un mot peut avoir un mauvais tag parce qu'il a t mal tiquet ds le dbut, cause d'une erreur ou d'un oubli dans le lexique. En effet, nous avons eu l'occasion de relever plusieurs problmes ce niveau. Par exemple, le mot trompe ne figure que sous l'entre "nom fminin singulier". S'il a en ralit la fonction de verbe conjugu dans la phrase, en ayant le tag "nom", il empche toutes les rgles portant sur un verbe de s'appliquer si besoin est. Un mot peut aussi avoir t mal dsambigis, parce qu'une autre rgle de dsambigusation que celle attendue a t applique, ou parce qu'une erreur dans sa graphie en a fait un mot d'une autre catgorie, comme nous l'avons vu lorsque nous avons parl des fautes de frappe. Mots ajouts, omis ou mal ordonns Une autre cause de silence peut tre l'insertion d'un mot non prvu dans un pattern, ou bien au contraire l'omission d'un mot attendu. Nous avons vu le cas de l'ajout de mots, par exemple, lorsque que nous avons crit la rgle sur la confusion entre l'utilisation de la forme nominale et de la forme verbale ("* je travail", "* on dsir"). Cette rgle devient inefficace si un ou plusieurs mots viennent s'intercaler entre le pronom personnel sujet et la forme errone, car cela n'est pas prvu par le pattern. C'est pourtant un contexte qui peut se rencontrer frquemment, comme dans une phrase ngative par exemple. Ainsi, aucune des fautes suivantes ne sera dtecte : "* je ne travail pas", "* il m'emploi", "* elle ne le soutien pas". En ce qui concerne l'oubli de certains mots, nous pouvons reprendre la rgle dont nous venons de parler et donner l'exemple d'une phrase imprative "* Travail, au lieu de discuter !". Pour que l'erreur sur la forme "travail" soit dtecte par la rgle correspondante, il faut qu'il y ait un pronom personnel avant la forme errone. Mais comme il n'y en a pas, la rgle ne peut pas s'appliquer. Enfin s'il y a bien tous les mots attendus par le pattern, mais qu'ils ne sont pas dans l'ordre indiqu par celui-ci, la rgle est aussi inefficace que dans les deux cas prcdents. Ainsi, la rgle d'accord en nombre d'un verbe avec le groupe nominal sujet (dterminant + nom) qui le prcde, ne s'applique pas dans le cas suivant "* un plat ... que mangeait les canuts". Le sujet se trouve en effet aprs le verbe, alors que dans la rgle, il est attendu avant celui-ci
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.
1.1.3. Limitation au contexte immdiat

Chaque erreur est dcrite dans le pattern des rgles en fonction du contexte dans lequel elle apparait. Toute dtection de faute se fonde donc uniquement sur l'environnement immdiat de cette erreur. Il est alors impossible de dtecter des erreurs lies des relations de dpendance distantes, tels des accords sujet-verbe ("* Les personnes en situation de test s'autosurveille normment."), les accords de complments d'objet antposs ("* Les mots que le conducteur a prononc..."), les accords des verbes de relatives avec leur antcdent ("* ...des formule de remplissage qui n'apporte rien..."), etc. Il est possible d'largir le contexte dans le pattern, en utilisant l'attribut skip, dont nous avons parl lors de l'importation des rgles, et qui permet de "sauter" un certain nombre de tokens. Il est cependant impossible de prvoir toutes les combinaisons et le nombre de mots ignorer. Dans des phrases comme "* Ce qui tire le maximum de profit de distinction sont ceux des classes dominantes" ou "* Jean, en faisant le con avec la portire du trafic, fini par la dtraquer.", le sujet et le verbe sont trs loigns. Il faudrait dfinir un grand nombre de tokens ignorer avec skip, ce qui, en rduisant la prcision de la rgle, accroitrait les risques de fausses alarmes.Par ailleurs, dans les exemples que nous avons donns, il serait difficile de grer le fait que d'autres verbes peuvent se trouver entre le sujet et le verbe principal. Nous avons en fait un problme de granularit de l'analyse, qui est rduite au mot. Il serait utile ici d'utiliser un niveau d'analyse intermdiaire entre le mot et la phrase, qui permettrait la dtection des fautes sur les relations distantes, qui restent non traites pour le moment. Elles sont pourtant relativement frquentes. En effet, plus les deux lments accorder sont loigns, plus les risques que l'accord soit erron sont levs.
1.2. De nombreuses fausses alarmes

Les fausses alarmes sont un peu la "bte noire" en matire de correction grammaticale automatique. Elles sont bien plus gnantes que le silence dont nous venons de parler, et conduisent souvent l'utilisateur de traitement de texte dsactiver le correcteur grammatical dans le logiciel. Elles sont d'ailleurs souvent l'origine de la dsactivation de l'outil de correction dans les traitements de textes. Ainsi, il est nettement prfrable de corriger moins de vraies fautes tout en ayant peu de fausses alarmes, que de dtecter la fois beaucoup d'erreurs relles et beaucoup d'autres qui n'en sont pas. Nous avons t confronte au problme du bruit lors de notre travail sur les rgles d'erreurs. Pour diverses raisons, certaines gnraient beaucoup plus de fausses alarmes qu'elles ne dtectaient de vraies fautes.
52
1.2.1. Mots ambigus

Les rgles d'erreurs de LanguageTool fonctionnent sur un systme de "correspondance positive" entre les tokens et le pattern. Nous voulons dire par l qu'une rgle s'applique si tel mot possde telle mauvaise tiquette. Or, un mot qui a plusieurs tags en a forcment au moins un qui n'est pas bon. Ce mauvais tag est donc susceptible de dclencher une rgle, mme si un autre tag du mot est correct. Ce problme concerne tout mot ambigu. Il se trouve que le dsambiguseur que nous avons implant dans LanguageTool permet justement de laisser plusieurs tiquettes un mot. En effet, pour les noms par exemple, pour ne pas avoir crire une rgle pour chaque combinaison genre-nombre possible (masculin-singulier, fminin-singulier, etc.), nous rattribuons au mot le tag "nom" qu'il possdait. Mais s'il en possdait plusieurs, ils lui sont tous raffects. Normalement, les mots qui sont la fois masculin et fminin devraient tre tiquets picnes, et les mots qui sont singulier et pluriel devraient tre invariables. Pourtant, dans la pratique, beaucoup de noms et adjectifs de ce type apparaissent sous deux entres distinctes dans le lexique, comme livre par exemple, qui a la double tiquette fminin et masculin. Ces mots conservent donc deux tiquettes contradictoires la suite de la dsambigusation. Nous liminerons beaucoup de ces fausses alarmes si nous retravaillons le lexique, afin que ces mots soient tiquets picnes ou invariables, et n'apparaissent alors plus que sous une seule entre.
1.2.2. Mots mal tiquets

Nous n'allons pas revenir sur les raisons d'un mauvais tiquetage, dont nous avons dj parl plusieurs reprises. Nous pouvons juste redonner l'exemple du mot trompe qui, dans le lexique utilis par le tagger, n'a que l'tiquette "nom fminin singulier". Le verbe tromper est souvent utilis dans sa forme pronominale se tromper. Or, dans toutes les phrases o il apparaitra la 3me personne du singulier, une erreur sera signale, car il sera dtect un nom prcd de se, ce qui est une faute. Ainsi, pour "il se trompe", il sera suggr de remplacer se par ce. Il nous faudrait donc, pour ce problme aussi, revoir le lexique et complter toutes les tiquettes et entres manquantes. Mais si un mot n'a pas la bonne tiquette, il ne s'agit pas forcment d'un problme de lexique, ou de dsambigusation. Il se peut qu'une faute de frappe ou une confusion d'homophones ait transform le mot souhait en un autre mot, appartenant une catgorie diffrente. Nous ne pouvons peut-tre pas vraiment parler ici d'erreur d'tiquetage, puisque le mot crit possdera bien le tag qui lui correspond. Le problme vient plutt du fait que l'tiquette attribue au mot n'est pas celle qu'aurait d avoir le mot initialement prvu. S'il est crit par exemple "* Les premiers linguistes on donc cout...", on n'aura pas l'tiquette "auxiliaire" et conduira la mauvaise dtection d'une faute sur cout, qui ne correspond pas la forme verbale attendue aprs le pronom personnel sujet on.
1.2.3. Dtections multiples

Nous avons aussi t confronte du bruit gnr non pas par de mauvaises alarmes, mais par des alarmes multiples sur une mme erreur.
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.
1.2.4. Dtections en cascade

Lors de la dtection, toutes les fautes d'une phrase sont traites en mme temps, ce qui peut tre une autre source de fausses alarmes. Prenons l'extrait : "* ont a tendance croire...". Avec les rgles actuellement disponibles, nous obtenons les trois dtections de fautes suivantes : ont : utiliser le pronom personnel on au lieu de l'auxiliaire ont (rgle : ont + verbe conjugu => erreur) a: il faut un participe pass aprs l'auxiliaire ont (rgle : auxiliaire + verbe conjugu => erreur) a: utiliser la prposition au lieu de l'auxiliaire a (rgle : verbe + a => erreur)
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.
2. Premire volution du formalisme

Nous venons de voir que les principales limites de LanguageTool sont lies au systme de pattern-matching utilis dans la dtection des fautes. Les correcteurs grammaticaux, de manire gnrale, fonctionnent de cette manire. Ils dtectent les erreurs partir d'une base de rgles qui dcrivent des squences, et non des phnomnes linguistiques. Il semblerait pourtant logique que de tels phnomnes soient utiliss pour corriger des fautes linguistiques. Elles pourraient permettre d'amliorer la correction grammaticale, et de pallier les limites dont nous avons parl au sujet de LanguageTool. Ainsi, nous allons prsenter le dcoupage en chunk et l'unification de structures de traits. Nous verrons qu'en combinant ces deux principes au sein de LanguageTool, il sera possible de dtecter les fautes d'accords sans avoir numrer tous les contextes possibles. Par ailleurs, certaines fautes qui ne sont pas dtectables par le formalisme actuel du correcteur pourront tre traites.
54
2.1. Segmentation en chunks et unification de structures de traits

Pour commencer, nous allons dfinir ce que sont les chunks, et voir comment ils sont traits actuellement dans LanguageTool. Nous ferons ensuite un rappel sur la notion d'unification de structures de traits, dont nous avons parl dans le premier chapitre.
2.1.1. Chunks a) Dfinition d'un chunk

Abney (1991) dfinit les chunks de la manire suivante : The typical chunk consists of a single content word surrounded by a constellation of function words, matching a fixed template Cette dfinition est reprise en franais dans (Lebarb, 2002) : Le chunk est constitu d'un mot lexical (au sens restreint : nominal ou verbal) entour d'une constellation de mots fonctionnels (au sens large : dterminants, pronoms, adverbes, adjectifs...). Un chunk, appel aussi syntagme, est un groupe de mots contigus, runis autour d'une tte lexicale dont ils dpendent. Ces relations de dpendance font de la structure interne des chunks une structure relativement fige, dans laquelle les contraintes d'accords sont assez fortes. Les syntagmes sont dlimits grce aux mots grammaticaux, la ponctuation ou aux marques morphologiques, et sont donc relativement faciles dfinir. En gnral, un chunk commence par un mot grammatical ou juste aprs une ponctuation, et se termine juste avant une ponctuation ou le mot grammatical suivant, qui marquent alors le dbut d'un nouveau chunk. Ainsi, les syntagmes ne sont pas dfinis en fonction de leur contenu, mais en fonction de marqueurs de dbut et de fin. C'est une proprit trs intressante qui permet, au contraire du pattern-matching, d'viter la description exhaustive de toutes les combinaisons de mots. Il existe principalement deux types de syntagmes : nominaux et verbaux. Le chunk nominal contient obligatoirement un nom (la tte lexicale) et commence gnralement par un dterminant. Cependant, ce dernier n'est pas pris en compte s'il est prcd d'une prposition, qui marque alors le dbut d'un chunk prpositionnel, et non nominal. Le chunk verbal contient obligatoirement un verbe et commence gnralement par celui-ci. Les pronoms personnels et adverbes de ngation lui sont aussi inclus car ils sont fortement lis au verbe. Il peut tre utile par ailleurs de distinguer le chunk verbal principal des autres syntagmes verbaux que la phrase peut contenir, comme par exemple les chunks contenant un infinitif, ou ceux spars par un pronom relatif. Il existe aussi des chunks adjectivaux ou adverbiaux, mais ils sont beaucoup plus rares. L'exemple suivant (Abney, 1991), illustre un dcoupage simple en chunks, en anglais : [I begin] [with an intuition]: [when I read] [a sentence], [I read it] [a chunk] [at a time]. Un chunk est donc un outil de calcul, qui permet de dlimiter des groupes de mots, runis autour d'une tte lexicale. Cependant, il n'est pas reconnu comme une unit linguistique part entire par toute la communaut de linguistes.
55
b) Relations entre chunks

Au sein d'une phrase, les diffrents chunks sont permutables. La structure est moins fige qu' l'intrieur d'un chunk. Dans l'exemple suivant, extrait du Bourgeois Gentilhomme de Molire, nous pouvons voir que la phase est constitue de cinq syntagmes qui peuvent permuter, mais au sein desquels les lments ont une place fixe : [Belle Marquise], [vos beaux yeux] [me font] [mourir] [d'amour]. [D'amour] [mourir] [me font], [belle Marquise], [vos beaux yeux]. [Vos yeux beaux] [d'amour] [me font], [belle Marquise], [mourir]. [Mourir] [vos beaux yeux], [belle Marquise], [d'amour] [me font]. [Me font] [vos yeux beaux] [mourir], [belle Marquise], [d'amour]. Leur mobilit dans la phrase n'empche pas les chunks d'entretenir des relations de dpendance entre eux. Un syntagme dpend gnralement de son prdcesseur, sauf dans le cas d'un chunk verbal. Ce dernier dpend du chunk sujet, qui correspond en principe au premier syntagme nominal gauche. Ces proprits de dpendance vont s'avrer trs utiles pour vrifier les accords entre diffrents groupes.
c) Chunking dans LanguageTool

La notion de chunk existe dans LanguageTool, mais sous forme de chunks implicites, dcrits en fonction de leur contenu dans les patterns de certaines rgles d'erreurs. Lorsque, dans une rgle, nous avons le pattern suivant :
<token <token <token <token postag="SENT_START"/> postag="D.*" postag_regexp="yes"/> postag="N .* s" postag_regexp="yes"/> postag="V.*" postag_regexp="yes"/>
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.
2.1.2. Rappels sur les structures de traits et l'unification

Dans le premier chapitre de ce mmoire, au chapitre 1 point 2.3.2.b , nous avons rapidement expliqu ce que sont l'unification et les structures de traits. Les tiquettes des mots sont des structures de traits. Elles consistent en l'numration des
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.
2.2. Intrt de la combinaison chunks-unification pour la correction grammaticale

Le fait de combiner le dcoupage en chunks et l'unification peut tre discutable. En effet, nous mlons ainsi deux concepts manant d'coles opposes. Les chunks font partie des grammaires robustes du TAL, dans lesquelles la notion de syntagme diffre de celle des grammaires chomskyennes, d'o est issu le principe d'unification. Dans (Chomsky,1979), les syntagmes sont rcursifs par exemple, ce qui signifie qu'ils peuvent contenir d'autres syntagmes du mme type. Ainsi, "un code labor et un code restreint" est considr comme un syntagme nominal constitu de deux autres syntagmes nominaux. Pour les grammaires robustes au contraire, l'exemple ci-dessus consiste en trois syntagmes distincts, ou chunks : [un code labor] [et] [un code restreint]. C'est cette dfinition que nous faisons rfrence lorsque nous employons le mot syntagme dans ce mmoire. Le fait de combiner le dcoupage en chunks et l'unification de structures de traits va permettre de faciliter la vrification grammaticale. L'intrt le plus vident concerne les accords entre les divers lments de la phrase. Il peut s'agir d'accords dans un groupe nominal tout comme d'accords entre le sujet et le verbe par exemple.
2.2.1. Correction "intra-chunk"

Les mots fonctionnels contenus dans un chunk sont dpendants de la tte lexicale et contraints de s'accorder avec elle. En attribuant des traits morphosyntaxiques tous les lments d'un syntagme et en utilisant une mthode d'unification des traits, il est assez facile de dtecter une erreur d'accord au sein d'un syntagme. En effet, si les traits de tous les lments d'un chunk ne peuvent pas s'unifier, c'est qu'il y a une erreur. Autrement dit, dans un chunk nominal qui serait du type "Dterminant + Adjectif + Nom", les traits de genre et de nombre du dterminant et de l'adjectif doivent tous deux s'unifier avec ceux du nom, qui est la tte du syntagme. D'autre part, en utilisant l'unification, nous travaillons directement sur les traits des mots, et non plus sur leur catgorie. Nous n'accordons par exemple plus un "dterminant masculin singulier" avec un "nom masculin singulier", mais un lment "masculin singulier" avec un autre lment "masculin singulier". Nous vitons ainsi de devoir prvoir toutes les combinaisons de mots pouvant constituer un syntagme, et nous en rduisons d'autant le nombre de rgles ncessaires.
57
2.2.2. Correction "inter-chunks"

La dtection des fautes de grammaire passe aussi par une bonne mise en relation des lments dans la phrase. Les chunks doivent s'unifier entre eux, de la mme manire que les lments d'un chunk. Un syntagme dpend gnralement de son prdcesseur, sauf dans le cas d'un syntagme verbal. La mthode d'unification des traits, comme pour les relations "intra-chunk", peut donc permettre d'accorder facilement les syntagmes, en fonction des relations qu'ils entretiennent entre eux et avec le syntagme verbal. Par exemple, si le chunk verbal a les traits "3me personne singulier", alors le chunk sujet doit obligatoirement avoir les traits "3me personne singulier" pour que l'unification des deux syntagmes puisse se faire. Dans le cas contraire, une erreur d'accord sujet-verbe sera dtecte. Comme les accords se font entre groupes, il n'est plus ncessaire de construire un trs grand nombre de rgles dcrivant toutes les combinaisons de mots possibles. Nous n'avons par exemple plus besoin d'numrer toutes les combinaisons de mots qui peuvent se trouver avant un verbe, en tant que sujet. Nous avons d'ailleurs vu que cela est de toutes manires impossible. Le traitement de certaines relations de dpendance distantes, souvent problmatique pour les correcteurs grammaticaux, est aussi facilit . Un simple accord entre un sujet et un verbe loigns peut tre trs difficile vrifier. Or, une proprit du chunk sujet est d'tre gnralement le premier syntagme gauche du chunk verbal, condition que ce syntagme soit nominal. Le dcoupage en chunks peut donc aider rsoudre le problme de dtection de certaines fautes, auquel se heurte une grande partie des correcteurs.
2.2.3. Aide la dsambigusation

Par ailleurs, la segmentation en syntagmes peut avoir un intrt au niveau de la dsambigusation. Par exemple, mme si cela semble vident, un chunk nominal doit obligatoirement contenir un nom. Si ce n'est pas le cas, le systme recherche dans le syntagme un mot ambigu qui peut avoir le tag "nom", mais qui ne lui a pas t attribu. Il rectifie alors l'tiquetage afin que le chunk contienne un nom. Un chunk nominal sans nom peut tre dfini lorsque le systme rencontre un dterminant (condition d'ouverture d'un chunk nominal) et lorsque le nom qui le suit est ambigu (avec un verbe par exemple) et mal tiquet. Le chunk nominal ainsi obtenu est constitu d'un dterminant, puis d'un verbe. Nous pourrions donc avoir ici un moyen de vrifier la cohrence de l'tiquetage.
2.3. Vrification orthographique

Nous avons voqu l'absence de vrification de l'orthographe, qui constitue une limite du formalisme de LanguageTool. Les erreurs dans la graphie des mots empchent beaucoup de rgles de s'appliquer. Le systme considre que le texte corriger a t pralablement vrifi par un correcteur orthographique, ce qui n'est pas ncessairement le cas. Nous pensons qu'il serait utile de rajouter une telle fonction. Un pr-traitement du texte consisterait rechercher tous les mots inconnus du lexique, et les signaler l'utilisateur, qui pourrait alors corriger ceux dont la graphie est errone. Il n'est pas question ici de faire de LanguageTool un correcteur orthographique part entire, qui suggrerait des corrections par exemple. Mais le fait de donner la possibilit l'utilisateur
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.
3. Dveloppement d'un nouveau formalisme

Nous avons prsent les principes de la segmentation en chunks et de l'unification de structure de traits, et avons mis l'hypothse qu'ils pourraient permettre d'amliorer la correction grammaticale. Nous avons donc dvelopp un nouveau formalisme, rendant possible l'utilisation de ces principes par le moteur de dtection des fautes. Ce formalisme permet de dcrire des rgles de correction, qui sont fondes sur un motif constitu de chunks, dont les proprits peuvent tre spcifies. Le systme tente alors de raliser l'unification des lments de ce motif. En cas d'chec, un message d'erreur est affich. Nous commenons par dcrire ce nouveau formalisme, puis nous expliquons la manire dont il sera interprt par le moteur de correction. Enfin, pour montrer la faisabilit, nous prsentons le prototype d'interprteur que nous avons dvelopp.
3.1. Description du formalisme

Le formalisme que nous dcrivons est en XML, et complte celui de LanguageTool. Il dcrit des motifs linguistiques, en utilisant le vocabulaire prsent dans la figure 6, page suivante.
3.1.1. lment <rule>

Cet lment constitue le niveau le plus lev de la hirarchie, et englobe tous les autres. Il permet de dlimiter chaque rgle, et donc de dcrire chaque motif, le traitement effectuer, et les messages retourner l'utilisateur. Il possde 2 attributs, ID et name, dont la fonction est de dfinir respectivement un identifiant unique et un nom pour la rgle. Dans le formalisme XML, l'lment <rule> se prsente ainsi :
<rule ID="EXEMPLE_REGLE" name="exemple de rgle"> ... </rule>
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)
<feature +> <token +>

cat inflected regexp negate skip genre nombre temps mode pers type fonction cat inflected regexp negate
<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
3.1.2. lment <example>

Il s'agit d'un lment servant donner des exemples d'noncs corrects ou incorrects, en rapport avec l'erreur dtecte par le motif de la rgle. Il contient un attribut type indiquant le type d'exemple qu'il donne et qui a donc pour valeur soit "correct" soit "incorrect". Il y a gnralement au moins 2 <example> pour chaque motif. L'exemple peut galement contenir un ou plusieurs autres lments <marker>, qui permettent, lors de l'affichage, de mettre en vidence le ou les mots que les balises de cet lment encadrent. Nous pouvons complter notre reprsentation du formalisme en XML :
<rule> ... <example type="correct">Ceci est <marker>correct</marker></example> <example type="incorrect">Ceci est pas correct</example> </rule>
3.1.3. lment <message>

Cet lment contient un message pour expliquer l'utilisateur quelle faute a t dtecte. Il n'a pas d'attribut. En revanche il peut contenir des lments <suggestion>, dont les balises entourent des mots qui seront suggrs en correction. L'exemple ci-dessous permet de proposer d'crire a.
<rule> ... <message>Vouliez-vous crire <suggestion>a</suggestion>?</message> <example>...<marker>...</marker>...</example> <example>...</example> </rule>
3.1.4. lment <unify>

Cet lment de <rule> est nouveau, par rapport au formalisme de LanguageTool. Il est facultatif. C'est lui qui permet l'interprteur d'appeler la fonction d'unification sur le motif, lors de la correction. Pour cela, il contient les attributs chunk et token, qui, selon la valeur qui leur est affecte ("yes" ou "no"), indiquent si l'unification doit avoir lieu entre des chunks ou entre les tokens du chunk. Il possde aussi un attribut feature servant dfinir une liste des traits unifier. Ainsi, dans l'exemple ci-aprs, le moteur de correction essaie d'unifier le trait "genre" et le trait "nombre" des tokens qui compose le motif dcrit dans le pattern :
<rule> <pattern> ... </pattern> <unify chunk="no" token="yes" feature="genre|nombre"/> <message>...<suggestion>...</suggestion>...</message> <example>...<marker>...</marker>...</example> <example>...</example> </rule>
61
3.1.5. lment <pattern>

C'est le dernier lment de <rule> que nous prsentons. Il dlimite la description du motif. Il est compos d'un ou de plusieurs lments <chunk> et/ou <token>. Il possde aussi 2 attributs optionnels, mark_from et mark_to, qui servent simplement dfinir la partie du motif renvoyer l'utilisateur pour situer sa faute.
<rule> <pattern mark_from="1" mark_to="-1"> ... </pattern> <message>...<suggestion>...</suggestion>...</message> <example>...<marker>...</marker>...</example> <example>...</example> </rule>
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>.
3.1.6. lment <token>

Les tokens du motif sont dcrits dans autant d'lments <token>. Chacun contient plusieurs attributs facultatifs : cat spcifie la catgorie grammaticale du token, sous forme d'une lettre majuscule, telle que dfinie dans le tagset. Ainsi, cat="V" dsigne un verbe, inflected permet d'utiliser un lemme (mot figurant en entre dans un dictionnaire) plutt que de devoir numrer toutes les flexions possibles du mot. Si <token> a l'attribut inflected="yes", alors en utilisant "beau" dans le motif, "beaux", "bel", "belle", "belles" seront galement traits, regexp, signifie expression rgulire (regular expression). Cet attribut, s'il a la valeur "yes", permet de mettre plusieurs mots dans un mme <token>, en les sparant avec la barre verticale "|", pour les traiter similairement comme "enfant|gosse|mme", negate, lorsque sa valeur est "yes", indique que le token ne doit pas faire partie du motif. skip, dont nous avons parl lors de l'importation des rgles, est un attribut qui spcifie un nombre de tokens pouvant tre ignors, avant de trouver le token suivant dans le motif. skip="2" permet de sauter 0, 1 ou 2 tokens, entre l'lment <token> qui possde cet attribut, et celui qui suit dans la description du motif.
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 :

<rule> <pattern> <token cat="N" regexp="yes" skip="1">appartement|logement ... </token> <token cat="V" inflected="yes">louer ... </token> </pattern> <unify/> <message>...<suggestion>...</suggestion>...</message> <example>...<marker>...</marker>...</example> <example>...</example> </rule>
62
<token> contient galement un ou plusieurs lments <feature>, pour dfinir les traits morphosyntaxiques des mots, et <exception>.
3.1.7. lment <chunk>

Cet lment fonctionne un peu comme <token>, avec des attributs similaires, mais un niveau suprieur, car il reprsente un groupe de mots. Les attributs negate et skip qu'il possde ont la mme fonction que dans <token>, la diffrence prs qu'ils s'appliquent des groupes de mots. S'il a pour valeur "yes" cela signifie que le chunk ne doit pas appartenir au motif, et skip indique le nombre maximum de chunks ignorer. L'attribut cat ne prend pas pour valeur la catgorie grammaticale, mais le type du chunk : par exemple, chunk="SV" pour un syntagme verbal, chunk="SN" pour un syntagme nominal, ou chunk="SP" pour un syntagme prpositionnel.
<rule> <pattern> <chunk cat="SN" skip="1"> ... </chunk> <chunk cat="SV" negate="yes"> ... </chunk> </pattern> <unify/> <message>...<suggestion>...</suggestion>...</message> <example>...<marker>...</marker>...</example> <example>...</example> </rule>
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
3.1.8. lment <feature>

C'est cet lment qui contient les informations morphosyntaxiques des tokens ou des chunks. Pour que l'unification puisse s'effectuer simplement, il est ncessaire que les mots et les syntagmes aient des tiquettes qui contiennent la fois le nom et la valeur des traits morphosyntaxiques. En effet, le correcteur doit comparer les valeurs de traits du mme nom pour effectuer l'unification. Nous pensons que le formalisme XML est bien adapt ce que nous souhaitons obtenir. Nous pouvons dfinir un lment pour chaque catgorie grammaticale (<D></D>, <V></V>). Les tokens sont alors entours par les balises de l'lment correspondant leur catgorie. Nous pouvons ensuite utiliser des attributs dans chaque balise pour reprsenter les traits du token. Pour illustrer ceci, nous donnons ci-dessous un exemple d'un tiquetage de ce type:
<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>
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
3.1.9. lment <exception>

Nous terminons cette description des lments du formalisme avec <exception>. Il permet de dfinir une exception, comme son nom l'indique, ce qui est dcrit dans l'lment du niveau suprieur, savoir <chunk> ou <token>. Il pourra tre utilis, par exemple, pour formuler des descriptions du type : "le motif doit contenir un chunk nominal, sauf un chunk nominal au pluriel". C'est l'exemple que nous donnons la fin de ce point. L'exception est du mme type que l'lment auquel elle s'applique. Ainsi, une exception dans <chunk> sera un chunk, et une exception dans <token> sera un token. Pour cette raison, elle possde les mmes attributs (sauf skip) que l'lment dans lequel elle se trouve : cat, inflected, regexp et negate. Nous ne revenons pas sur ces attributs, que nous venons dfinir aux points 3.1.6 et 3.1.7 de ce chapitre pour <token> et <chunk>. L'exception possde aussi un lment <feature>, toujours pour la mme raison que celle mentionne ci-dessus.
<rule> <pattern> <chunk cat="SN"> <feature/> <exception cat="SN"> <feature nombre="p"/> </exception> </chunk> </pattern> <unify/> <message>...<suggestion>...</suggestion>...</message> <example>...<marker>...</marker>...</example> <example>...</example> </rule>
3.2. Interprtation du formalisme

Actuellement, l'interprtation du formalisme de LanguageTool se fonde sur un systme de pattern-matching, dont nous avons critiqu la rigidit. Le nouveau formalisme, que nous venons de dcrire fonctionne galement selon ce systme, dans la mesure o le principe est toujours de rechercher, dans le texte, des motifs identiques ceux dcrits dans les rgles. Mais cela se fait de manire beaucoup plus souple.
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. Conception d'un calculateur d'unification

Suite la description du nouveau formalisme, nous avons dvelopp un prototype d'interprteur, dans le but de montrer la faisabilit de la dtection des fautes d'accord l'aide des chunks et de l'unification. Ce programme est crit dans le langage Python. Il prend en entre des phrases pralablement tiquetes et segmentes en chunks, il recherche des erreurs d'accord en s'aidant d'expressions rgulires, puis cre un fichier de sortie contenant des informations sur les erreurs dtectes.
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> avec <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.
3.3.2. Fonctionnement du module de calcul d'unification

L'interprteur de rgles fait appel au module de calcul d'unification quand il en a besoin, c'est-dire quand l'lment <unify/> est dfini dans la rgle. Le niveau o doit s'effectuer l'unification, chunks ou tokens, est alors spcifi par l'attribut chunk="yes" ou token="yes". L'outil que nous avons dvelopp permet de raliser l'unification entre chunks ou entre tokens.
a) Utilisation d'expressions rgulires

L'outil que nous avons conu fonctionne l'aide d'expressions rgulires, qui permettent de trouver facilement des motifs dans les chaines de caractres. Comme tout l'tiquetage des phrases se fonde sur des balises, il est facile de dfinir des motifs pour reprer une phrase, un chunk, un lment ou un trait. Pour commencer, le texte est parcouru par le programme. Les phrases, dont les limites sont facilement identifiables l'aide des balises de fin <M fin="yes">.</M>, sont traites les unes aprs les autres. Pour chacune, les diffrents niveaux d'lments tiquets sont alors reprs et stocks dans un tableau, pour tre traits par la suite. Le premier niveau est celui des chunks. Ils sont faciles isoler avec une expression rgulire permettant de rechercher dans le texte les motifs "<S" et "</S.>"2, qui correspondent au dbut et la fin d'un syntagme. Avec l'extrait "Les charges sont leves", nous isolons ainsi 2 chunks :
Le point utilis dans le motif sert remplacer n'importe quel caractre

<SN pers="3" genre="f" nombre="p">
68
<D genre="e" nombre="p">les</D> <N genre="f" nombre="p">charges</N>

</SN>
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
3.3.4. Test du prototype

Nous avons test notre programme sur quelques phrases, extraites du corpus de variations orthographiques (COVAREC, 1994). Avant de lancer leur vrification dans le programme, nous les avons bien sr tagges et segmentes en chunks. Voici quelques exemples de phrases que nous avons donnes corriger au prototype. Nous avons soulign les fautes qui ont t dtectes :
"*Les enfants linguistique" : qui choue l'cole ont des grandes capacit
<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> <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.

"*Les personnes en situation de test s'autosurveille" : <SN genre="e" nombre="p"> <D genre="e" nombre="p">Les</D> <N genre="f" nombre="p">personnes</N> </SN> <SP> en <N genre="f" nombre="s">situation</N> </SP> <SP> de <N genre="m" nombre="s">test </SP> <SV type="ppal"> <V mode="ind" temps="pres" pers="3" nombre="s">s'autosurveille</V> </SV>
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.

"*Ces diffrences en gnral sont li au social" : <SN genre="f" nombre="p"> <D genre="e" nombre="p">Ces</D> <N genre="f" nombre="p">diffrences</N> </SN> <SP> en <N genre="m" nombre="s">gnral</N> </SP> <SV type="ppal"> <V mode="ind" temps="pres" pers="3" nombre="p">sont</V> <V mode="ppa" pers="3" genre="m" nombre="s">li</V> </SV> <SP> <D genre="m" nombre="s">au</D> <N genre="m" nombre="s">social</N> </SP>
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.
Chapitre 4 : Conclusions et perspectives
73

Pendant 5 mois, nous avons effectu un travail de recherche trs intressant sur la correction grammaticale et ses outils. Nous avons adapt un outil au franais et avons propos des volutions de son formalisme, permettant d'amliorer la dtection des fautes. Nous allons poursuivre notre recherche dans ce domaine, afin de dvelopper un nouveau moteur de correction adapt l'interprtation de rgles suivant le formalisme que nous avons prsent. Nous constituerons par ailleurs un corpus de fautes partir duquel nous crerons de nouvelles rgles de correction.
1. Premier correcteur grammatical OpenOffice.org

La correction grammaticale est une fonctionnalit trs demande par les utilisateurs de traitement de texte, et qui fait dfaut OpenOffice.org. L'intgration de LanguageTool, sous forme d'extension dans le traitement de texte, ralise il y a plusieurs mois, a en partie combl ce vide. En partie seulement, car peu de langues sont prises en charge, et certaines ne corrigent que trs peu de fautes. Avec notre travail de ces dernires semaines, nous avons donn au correcteur la capacit de traiter le franais. Aprs avoir tudi la mise en uvre et les rsultats de l'adaptation de An Gramadir, nous nous sommes consacre au correcteur LanguageTool. Pour lui permettre de prendre en charge notre langue, nous lui avons ajout un dsambiguseur, et nous avons transcrit toutes les rgles de An Gramadir dans son formalisme. Cette premire adaptation termine, l'utilisateur franais d'OpenOffice.org peut prsent vrifier ses productions, en installant l'extension LanguageTool dans son programme de traitement de texte. La correction grammaticale, se passe alors peu prs comme la correction orthographique. Une fentre indique la faute dtecte, le contexte, un commentaire, et ventuellement une suggestion de correction. Il est alors possible soit d'ignorer la faute, soit d'appliquer une correction, qui peut tre celle suggre ou une nouvelle. Bien sr, la dtection des erreurs est pour le moment loin d'tre parfaite, si tant est qu'elle puisse l'tre. Il ne s'agit l que d'un premier correcteur, qui requiert encore beaucoup de travail pour tre rellement efficace. Parmi les amliorations prvues, l'implantation du nouveau formalisme que nous avons prsent, et bien sr la rdaction de nouvelles rgles de correction.
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
2.1. Nouvelle structure

Nous avons critiqu les limites du formalisme actuel de LanguageTool, et plus particulirement le pattern-matching, qui mne une explosion combinatoire des rgles d'accords. Nous avons galement montr qu'il est possible de dtecter efficacement ces fautes d'accord en combinant l'unification et la segmentation en chunks. Il nous faut donc prsent penser au dveloppement d'un moteur d'infrence adapt, capable de fonctionner partir de ces principes. Nous avons alors deux possibilits. La premire est de partir de la version actuelle de LanguageTool comme base, et de la transformer selon nos besoins. La seconde est de concevoir un outil entirement nouveau. Quelle que soit la solution adopte, l'outil que nous dvelopperons aura la structure suivante, schmatise dans la figure 7 :

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
Vrification TOKENIZA- orthographique TION
tiquetage en XML TAGGING
Dsambigusation (rgles)
CHUNKING
Erreurs dans l'utilisation des mots
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.
2.2. Dveloppement de rgles partir d'un corpus

2.2.1. Constitution d'un corpus d'erreurs
Pour constituer un corpus de fautes de grammaire, nous devrons au pralable nous poser plusieurs questions. Quels types de textes allons-nous collecter ? A quels scripteurs allons-nous nous intresser ? Quelle utilisation allons-nous faire du corpus ? Pour pouvoir rpondre aux deux premires interrogations, commenons par rflchir la dernire. Quelle utilisation du corpus ? Nous souhaitons constituer un corpus de fautes de grammaire afin de complter la base de rgles de correction. Nous devrons donc effectuer une analyse, qui nous permettra de dfinir une typologie prcise des erreurs commises. Nous pourrons ensuite modliser ces fautes pour crer de nouvelles rgles, structurellement compatibles avec le formalisme du correcteur. Quels documents ? La correction grammaticale automatique s'effectue sur des textes dactylographis. Ce sont donc des textes de ce type que nous runirons, et nous laisserons de ct les documents manuscrits. D'autre part, nous devrons choisir quels types de documents dactylographis nous allons collecter. Ils peuvent en effet tre de nature trs varie : des documents rdigs dans un cadre professionnel : compte-rendus, rapports, lettres, articles, sites web professionnels, etc. des documents rdigs dans un cadre scolaire : exposs, dissertations, mmoires, etc. des documents internet : mails, forums de discussion, messagerie instantane, sites web personnels, etc. Nous devons cependant garder l'esprit que, pour des raisons juridiques (Droits de la Proprit Intellectuelle et Industrielle, Liberts individuelles), beaucoup de ces documents ne pourront pas, ou alors difficilement, tre intgrs notre corpus. La situation d'criture et le degr de formalit vont beaucoup influencer la quantit et la typologie des fautes commises, qui seront donc trs variables d'un document l'autre. Il est par exemple vident qu'un message post dans un forum de discussion est susceptible de contenir beaucoup plus d'erreurs qu'une lettre caractre professionnel, ou une dissertation, rdiges avec plus de soins et d'attention. Nous devrons donc tenir compte de ces paramtres lors du choix des documents que nous collecterons.
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.
2.2.2. Analyse du corpus

partir de l'analyse du corpus et des fautes que nous observerons, nous devrons dfinir une typologie approfondie des erreurs du dactylographe. Nous avons dj mentionn la variabilit des types de fautes en fonction de la situation d'criture, mais aussi selon le scripteur, son ge, son origine, son niveau d'tude, etc. La dfinition de cette typologie est indispensable pour pouvoir ensuite modliser les erreurs dans des rgles de correction. Une fois ces rgles crites, elles devront tre appliques au corpus pour tre valides. Nous pourrons alors observer les erreurs restant, qui seront leur tour modlises, puis valides. Les nouvelles rgles ainsi cres viendront alors s'ajouter au prcdentes. Nous appliquerons donc une mthode de type "cycle empirique", illustre dans la figure 8, pour affiner notre modle de correction.
OBSERVATION (corpus d'erreurs) VALIDATION (application et vrification)
MODLISATION (rgles de correction)
Figure 8: Le cycle empirique
3. Intgration au projet OpenOffice.org

Les bnfices du travail communautaire Le travail communautaire est la base de projets comme OpenOffice.org, ou LanguageTool. Chacun peut apporter sa contribution, qu'il soit informaticien, linguiste, ou
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.
4. Vers une autre approche de la correction grammaticale

L'approche top-down (de haut en bas : la phrase entire est dcompose en sous-units linguistiques) de la dtection de fautes reste prisonnire d'un cercle vicieux : pour effectuer un bon tiquetage syntaxique, la phrase doit tre sans faute, car celles-ci induisent des erreurs d'tiquetage, soit d'un point de vue morphologique, soit d'un point de vue contextuel. Il est donc ncessaire d'envisager une autre approche du traitement que nous pourrions nommer left-right : construire simultanment l'analyse morphosyntaxique et la correction grammaticale au fur et mesure de la rdaction / lecture de la phrase (gauche-droite). Plus prcisment, en se fondant sur le principe de latences (Tesnire, 1959) ou d'attentes rciproques (Lebarb, 2002), construire la structure syntaxique dans l'ordre de lecture des tokens, valider les attentes rciproques (un dterminant attend un substantif), construire les chunks et tester l'unification : l'chec de l'un des trois constitue une dtection d'erreur de grammaire et donne son explication. L'analyse de "*ils son dans la mme classe" gnrerait une erreur ds le deuxime mot tap, le pronom personnel "ils" ayant une latence droite pour un syntagme verbal (commenant ventuellement par des pronoms) et l'adjectif possessif "son" tant un indicateur de syntagme nominal. Un message du type "un verbe est attendu" serait alors gnr pour indiquer l'erreur l'utilisateur. Cette approche impliquera une reconsidration complte du formalisme (dclaration non plus des fautes possibles, mais de ce qui est attendu) et du traitement.
Glossaire
79
Glossaire
Chunk (Abney, 1991), aussi appel syntagme minimal (Vergne, 1999)

Syntagme constitu d'un groupe de mots fonctionnels (dterminants, pronoms, adjectifs, etc.) runis autour d'un mot lexical (nom ou verbe le plus souvent). Unit de calcul au sein d'une phrase, dlimite par des mots grammaticaux, ponctuations ou marques morphologiques. Par exemple, une prposition marque le dbut d'un chunk prpositionnel, un dterminant ouvre gnralement un chunk nominal, et un verbe un chunk verbal. Exemple d'un dcoupage en chunks : *[Les enfants] [en situation] [de blocage] [vont utilis] [le code restreint]
chunk nominal chunk prep. chunk prep. chunk verbal chunk nominal
Chunker (segmenteur en chunks)

Outil permettant de calculer automatiquement les chunks dans un texte.
Chunking (segmentation en chunks)

Dcoupage des phrases en chunks.
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 (motif, patron)

Dans ce mmoire, le pattern est un lment contenu dans les rgles qui dcrit des combinaisons possibles de mots. Dans les rgles de correction, les patterns dcrivent des modles d'erreurs. La description dans les patterns se fait gnralement l'aide d'expressions rgulires. Par exemple, le pattern "D m s + N m p" dcrit le modle de l'erreur o un dterminant masculin singulier est suivi par un nom masculin pluriel.
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
Tagging (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" - 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"
Tagset (jeu d'tiquettes)

Liste de toutes les tiquettes utilisables par l'tiqueteur morphosyntaxique (tagger). Par exemple, dans le tagset franais utilis dans LanguageTool, nous avons, entre autres, les tiquettes N, D, V, J, A pour dsigner respectivement les noms, dterminants, verbe, adjectifs et adverbes. Nous avons galement les tiquettes m, f, s, p pour dsigner le masculin, fminin, singulier puis pluriel.
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.
Tokenization (segmentation en jetons)

Segmentation du texte en phrases puis en tokens. Le dcoupage s'effectue au niveau des sparateurs, constitus des espaces et des ponctuations. Par exemple, la tokenization de "*Les caves sont pourri, surtout les fentres." aboutit : *| Les | caves | sont | pourri | , | surtout | les | fentres | . |
Tokenizer (segmenteur en jetons)

Outil permettant de segmenter automatiquement le texte en phrases puis en tokens.
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

Conception Et Developpement Dun Formalisme de Correction Grammaticale Automatique-Applicaion Au Fracais

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Conception Et Developpement Dun Formalisme de Correction Grammaticale Automatique-Applicaion Au Fracais

Transféré par

Droits d'auteur :

Formats disponibles

UNIVERSIT STENDHAL GRENOBLE 3 LABORATOIRE LIDILEM

CONCEPTION ET DVELOPPEMENT D'UN FORMALISME DE CORRECTION GRAMMATICALE AUTOMATIQUE - APPLICATION AU FRANAIS -

Agns Souque Juin 2007

Directeur de mmoire : Thomas Lebarb, Matre de confrences

Table des matires

2. Travail de M. Lechelt : adaptation au franais d'un correcteur existant..................13

3 1.2. Problme de l'ambigut catgorielle..........................................................................26 1.3. Tentative de contournement du problme...................................................................28

2. Implantation d'un dsambiguseur...........................................................................28

3. Importation des rgles de An Gramadir dans LanguageTool................................30

4. Augmentation des rgles partir d'un corpus de fautes..........................................39

5. Typologie des erreurs corriges...............................................................................44

2. Premire volution du formalisme...........................................................................56

3. Dveloppement d'un nouveau formalisme...............................................................61

1. Structure gnrale d'un correcteur grammatical

texte tiquet dsambigus

phrases segmentes en chunks

tiquetage Dsambigusation morphosyntaxique TAGGING

DETECTION DES FAUTES

rgles o rgles de d'erreurs u grammaire

1.2. Tagging et dsambigusation

1.3. Segmentation en syntagmes minimaux

1.4. Dtection des fautes

2. Travail de M. Lechelt : adaptation au franais d'un correcteur existant

2.1. Analyse de diffrents correcteurs

2.1.2. Slection de An Gramadir

texte tiquet dsambigus

phrases segmentes en chunks

tiquetage Dsambigusation morphosyntaxique TAGGING

DETECTION DES FAUTES

rgles o rgles de d'erreurs u grammaire

Figure 2: Structure du correcteur An Gramadir

2.2. Adaptation de An Gramadir la correction grammaticale du franais

2.2.3. La dtection des fautes

2.2.4. La rdaction des rgles

a) Les rgles de dsambigusation

b) Les rgles d'erreurs

2.3. valuation et perspectives

2.3.1. valuation et limites de An Gramadir a) valuation par GRACE

b) Limites du systme pour la correction du franais

2.3.2. Perspectives a) Amliorations de An Gramadir

b) Approche alternative pour la conception d'un nouvel outil

Chapitre 1 : Existant L'unification de structures de traits

3.1. Rejet de la premire version de l'outil

texte tiquet dsambigus

tiquetage Dsambigusation morphosyntaxique TAGGING

DETECTION DES FAUTES

rgles o rgles de d'erreurs u grammaire

3.1.2. Points faibles l'origine du rejet

3.2. volutions et nouvelle version de l'outil

3.2.2. Structure actuelle de LanguageTool Texte vrifier

tiquetage Dsambigusation morphosyntaxique TAGGING

DETECTION DES FAUTES

rgles o rgles de d'erreurs u grammaire

la segmentation du texte en phrases, puis en mots

Les rgles d'erreurs sont formalises en XML, et composes de plusieurs lments :

id et name : l'identifiant et le nom de la rgle.

Chapitre 1 : Existant Voici un exemple de rgle en franais :

Chapitre 2 : Adaptation de LanguageTool la correction du franais

Chapitre 2 : Adaptation de LanguageTool la correction du franais

1. Test des rgles existantes

1.1. Test et erreurs dtectes

1.2. Problme de l'ambigut catgorielle

Chapitre 2 : Adaptation de LanguageTool la correction du franais

b) *a voiture est en panne.