Vous êtes sur la page 1sur 84

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
2
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
6
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 Mi!kowski 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 7
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 8
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.
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
TOKENIZATION
DETECTION
DES
FAUTES
rgles
d'erreurs
rgles de
grammaire
o
u
Texte
vrifier
phrases
et
tokens
texte
tiquet
texte tiquet
dsambigus
TAGGING
tiquetage
morphosyntaxique
Dsambigusation
rgles probabilits et
ou
corpus
Texte
corrig
phrases
segmentes
en chunks
CHUNKING
Chapitre 1 : Existant 9
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 sous-
catgorisation (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.
Chapitre 1 : Existant 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.
Chapitre 1 : Existant 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.
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.
CHUNKING TOKENIZATION
DETECTION
DES
FAUTES
rgles
d'erreurs
rgles de
grammaire
o
u
Texte
vrifier
phrases
et
tokens
texte
tiquet
texte tiquet
dsambigus
TAGGING
tiquetage
morphosyntaxique
Dsambigusation
rgles probabilits ou
corpus
Texte
corrig
phrases
segmentes
en chunks
Chapitre 1 : Existant 12
La solution adopte dans (Lechelt, 2005) consiste rechercher dans le lexique les chanes
de caractres qui contiennent un de ces signes problmatiques, et que le tokenizer rencontre.
Les chanes prsentes dans le lexique sont conserves telles quelles, car elles sont considres
comme un seul token. En revanche, les chanes qui ne figurent pas dans ce lexique sont
dcomposes en deux units distinctes.
2.2.2. Le tagging
La mthode de tagging en elle-mme n'a pas t modifie dans (Lechelt, 2005). En revanche, il
a bien sr fallu adapter un lexique tiquet franais en amont, et des rgles de dsambigusation
en aval du tagger.
a) Le lexique tiquet
Pour effectuer le tagging, il est ncessaire d'avoir un lexique de formes flchies tiquetes
morphosyntaxiquement. Le jeu d'tiquettes (ou tagset) de ce lexique doit tre dfini de manire
permettre une bonne correction grammaticale, et doit tre compatible avec l'outil qui va
l'utiliser.
Le lexique DICO [Web : DIC], de la Bibliothque Universelle ABU [Web : ABU], a t
choisi pour tre implant dans An Gramadir. Pour cela, il a d subir plusieurs transformations,
qui ont abouti la cration d'un nouveau lexique : InDico.
Un nouveau jeu d'tiquettes a d'abord t dfini, en fonction de celui de DICO, et des
informations ncessaires une bonne correction. Des entres du lexique ont t modifies,
supprimes ou ajoutes. Les informations morphosyntaxiques ont ensuite t traduites dans le
formalisme de An Gramadir, et certaines ont t modifies en fonction du nouveau tagset.
l'issu de toutes ces transformations, le nouveau lexique InDico a pu tre utilis dans
An Gramadir pour tiqueter des textes en franais.
b) La dsambigusation
Une fois l'tiquetage effectu, s'est pos le problme de la dsambigusation. Des tests sur
corpus ont fait ressortir 46% de mots ambigus, les plus nombreux tant les noms, les adjectifs,
les dterminants et les verbes.
Une base de rgles de dsambigusation a donc t construite, en s'appuyant sur la mthode
des rgles par dfaut explique par J. Vergne et E. Giguet (Vergne & Giguet, 1998).
Ainsi, une premire srie de rgles particulires dsambiguse des cas prcis. Elle est suivie de
rgles par dfaut qui sont un peu plus gnrales, et pour finir des rgles dites brutes traitent tous
les cas d'ambigut non rsolus par les rgles prcdentes. Ces dernires rgles sont ncessaires
dans la mesure o la vrification grammaticale dans An Gramadir ne tolre aucune ambigut.
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
Chapitre 1 : Existant 13
le sujet et le verbe) et les confusions entre homophones (a et sa / m'a et ma / et er / ces, ses,
c'est et s'est).
D'autres types de fautes sont ressortis, mais ne semblaient pas pouvoir tre traits avec
An Gramadir. Il s'agit des erreurs de concordance des temps, des oublis de mots, comme la
particule ne de la ngation par exemple, des fautes de style, ou encore des erreurs
morphologiques, comme la contraction de de + le en du par exemple, ou bien l'lision devant
une voyelle de certains mots grammaticaux comme que ou le.
Ce travail d'observation effectu, des rgles de dtection des fautes ont pu tre crites. Il
s'agit de rgles d'erreurs, qui dcrivent des modles de fautes de grammaire, et qui permettent
de signaler les erreurs dans le texte lorsqu'elles concident avec ceux-ci.
L'ensemble des rgles cres dans (Lechelt, 2005) permet de dtecter des fautes d'accords
dans les syntagmes nominaux (dterminants, adjectifs et noms), entre le sujet et le verbe
lorsqu'ils sont proches, ou bien entre le sujet et les adjectifs attributs, ou les participes passs,
prcds de l'auxiliaire tre. Les rgles couvrent aussi quelques fautes de proximit phontique,
comme ce et se, ou encore son et sont.
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 <B></B> 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 :
<B><Z>ANYDFS</Z>ANYTHING</B> <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>).
Chapitre 1 : Existant 14
Nous avons vu plus haut que les rgles de dsambigusation sont de trois types :
particulires, par dfaut et brutes. L'ordre dans lequel les diffrents types de rgles apparaissent
dans le fichier est trs important. Les rgles les plus gnrales doivent se trouver la fin, pour
que toutes les rgles plus prcises puissent s'appliquer auparavant.
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.
Chapitre 1 : Existant 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.
Chapitre 1 : Existant 16
Parmi les propositions pour amliorer An Gramadir, outre la ncessit d'augmenter le
nombre de rgles de dsambigusation, il a donc d'abord t suggr, dans (Lechelt, 2005), de
retravailler le lexique :
! Il faudrait commencer par vrifier et uniformiser les entres, dont certaines sont
incohrentes. En effet, des mots picnes ou invariables apparaissent sous deux entres
distinctes : masculin et fminin, ou bien singulier et pluriel. Il serait bon de n'avoir qu'une
seule entre, avec un tag "picne" ou "invariable" selon les cas. Les pronoms auraient aussi
besoin d'tre uniformiss.
! Certains tags pourraient ensuite tre complts avec de nouveaux traits, pour affiner la
dsambigusation. Par exemple, le trait antpos ou postpos pour les adjectifs, le traits verbe
d'tat, un trait sur la transitivit des verbes, etc.
! L'ajout d'une transcription phontique permettrait une meilleure dtection des fautes de
proximit phontique.
! Nous pourrions enrichir le lexique avec d'autres lexiques spcialiss disponibles, comme
celui des noms propres.
! Le lexique et ses tags devraient tre rcrits au format XML, ce qui faciliterait le
traitement des donnes par le correcteur.
Un autre point faible de An Gramadir concerne les rgles d'erreurs, qui ne dtectent qu'une
petite varit de fautes et ne sont pas assez nombreuses. Il faudrait donc les complter, mais
aussi utiliser les possibilits offertes par le dcoupage en chunks, ou syntagmes. Comme nous
allons le voir dans le point suivant, les chunks seraient utiles pour dtecter d'autres types
d'erreurs, comme la concordance des temps, les accords sujet-verbe, ou encore les accords des
participes passs aprs l'auxiliaire avoir. Il n'est en effet pas possible de dtecter de telles fautes
avec un systme uniquement fond sur le contexte immdiat.
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 17
L'unification de structures de traits
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 :

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.
Le
genre = masculin
nombre = singulier
genoux
genre = masculin
nombre = pluriel
U
=
chec
Chapitre 1 : Existant 18
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.
TOKENIZATION
DETECTION
DES
FAUTES
rgles
d'erreurs
rgles de
grammaire
o
u
Texte
vrifier
phrases
et
tokens
texte
tiquet
texte tiquet
dsambigus
TAGGING
tiquetage
morphosyntaxique
Dsambigusation
rgles probabilits ou
corpus
Texte
corrig
phrases
segmentes
en chunks
CHUNKING
Chapitre 1 : Existant 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).
Chapitre 1 : Existant 20
Un dveloppement de l'intgration de l'outil dans la suite OpenOffice.org a par ailleurs t
ralis. Ceci nous intresse particulirement puisque l'un de nos objectifs est d'y implanter la
correction grammaticale du franais.
Signalons aussi d'autres amliorations de LanguageTool, qui ne nous concernent pas toutes
directement pour l'adaptation au franais. Par exemple, de nombreuses rgles ont t ajoutes,
pour la gestion notamment des majuscules, des faux-amis ou de la ponctuation, et de nouveaux
tags sont venus complter le jeu d'tiquettes existant.
3.2.2. Structure actuelle de LanguageTool
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.
# pattern : 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.
CHUNKING
TAGGING
Dsambigusation
tiquetage
morphosyntaxique
TOKENIZATION
DETECTION
DES
FAUTES
rgles
d'erreurs
rgles de
grammaire
o
u
Texte
vrifier
phrases
et
tokens
texte
tiquet
texte tiquet
dsambigus
rgles probabilits ou
corpus
Texte
corrig
phrases
segmentes
en chunks
Chapitre 1 : Existant 21
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>
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
Chapitre 2 : Adaptation de LanguageTool la correction
du franais
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 Mi!kowski, 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 23
Phrase teste Correction suggre
1. Sa voiture est en panne. *a voiture est en panne
2. *a voiture est en panne. Sa voiture est en panne.
3. La visite a dur longtemps. *La visite dur longtemps.
4. *La visite dur longtemps. Phrase correcte
5. Il se livre la police. *Il ce livre la police.
6. *Il ce livre la police. Il se livre la police.
7. Je peux utiliser ce tlphone ? *Je peux utiliser se tlphone ?
8. *Je peux utiliser se tlphone ? Phrase correcte
9. Ces traits ne sont pas droits. *Ces traits ne son pas droits.
10. *Ces traits ne son pas droits. Phrase correcte
11. Il a publi son livre. *Il a publi sont livre.
12. *Il a publi sont livre. Il a publi son livre.
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.
Chapitre 2 : Adaptation de LanguageTool la correction du franais 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 [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>]
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>]
Chapitre 2 : Adaptation de LanguageTool la correction du franais 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.
Chapitre 2 : Adaptation de LanguageTool la correction du franais 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 (<B>,
<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, Mi!kowski, 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 DTD
1
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
Chapitre 2 : Adaptation de LanguageTool la correction du franais 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 Mi!kowski 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 Mi!kowski 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 :
<B><Z>ANYDFS</Z>ANYTHING</B> <N>ANYTHING</N>:<D f s>
De manire gnrale, le mot ambigu et ses tags sont entours des balises <B></B>, son
contexte, droit ou gauche, est entour de balises indiquant sa catgorie, et la partie droite de la
rgle, isole par ":", prcise le tag appliquer.
Pour rcrire les rgles en XML, nous devons donc pouvoir indiquer quel est le mot ambigu, de
quoi est constitu son contexte immdiat, et quel est le tag appliquer pour supprimer ou
rduire l'ambigut.
Nous avons choisi de garder une structure aussi proche que possible de celle dj utilise
pour les rgles d'erreurs. Redonnons en exemple la structure de la rgle prsente au point 3.2.2
du chapitre 1 :
Chapitre 2 : Adaptation de LanguageTool la correction du franais 28
<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>
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.
Chapitre 2 : Adaptation de LanguageTool la correction du franais 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 : [Nn]e ANYTHING ANYTHING <B>pas</B>:<A>
ne + X + pas : [Nn]e ANYTHING <B>pas</B>:<A>
ne + pas : [Nn]e <B>pas</B>:<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
<B><Z>ANYDMS</Z>ANYTHING</B> <N>ANYTHING</N>:<D m s>
Dterminant ambigu + Adjectif = Dterminant
<B><Z>ANYDMS</Z>ANYTHING</B> <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
Chapitre 2 : Adaptation de LanguageTool la correction du franais 30
<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>
! 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 Mi!kowski, 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".
Chapitre 2 : Adaptation de LanguageTool la correction du franais 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
Chapitre 2 : Adaptation de LanguageTool la correction du franais 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
Mi!kowski. 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.
Chapitre 2 : Adaptation de LanguageTool la correction du franais 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.
Chapitre 2 : Adaptation de LanguageTool la correction du franais 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,
Chapitre 2 : Adaptation de LanguageTool la correction du franais 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>
Chapitre 2 : Adaptation de LanguageTool la correction du franais 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 celui-
ci 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.
Chapitre 2 : Adaptation de LanguageTool la correction du franais 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..."
Chapitre 2 : Adaptation de LanguageTool la correction du franais 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.
Chapitre 2 : Adaptation de LanguageTool la correction du franais 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.
Chapitre 2 : Adaptation de LanguageTool la correction du franais 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>
Chapitre 2 : Adaptation de LanguageTool la correction du franais 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
# 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
Chapitre 2 : Adaptation de LanguageTool la correction du franais 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.
Chapitre 2 : Adaptation de LanguageTool la correction du franais 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
Chapitre 2 : Adaptation de LanguageTool la correction du franais 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.
Chapitre 2 : Adaptation de LanguageTool la correction du franais 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.
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
chevauchement
orth./gram
ORTHOGRAPHE GRAMMAIRE
INFORMATIQUE :
ORTHOGRAPHE GRAMMAIRE
LINGUISTIQUE :
Exemples
de fautes :
- toujoures
- namoins
- aquis
- ils dorments
- vous comprendrer
- lequelle
- j'ai cris
- des formule
- sa se voit
Chapitre 2 : Adaptation de LanguageTool la correction du franais 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. Mi!kowski 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,
Chapitre 2 : Adaptation de LanguageTool la correction du franais 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
Chapitre 3 : Amlioration du formalisme de LanguageTool
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.
Chapitre 3 : Amlioration du formalisme de LanguageTool 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.
Chapitre 3 : Amlioration du formalisme de LanguageTool 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
Chapitre 3 : Amlioration du formalisme de LanguageTool 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.
Chapitre 3 : Amlioration du formalisme de LanguageTool 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.
Chapitre 3 : Amlioration du formalisme de LanguageTool 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.
Chapitre 3 : Amlioration du formalisme de LanguageTool 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.
Chapitre 3 : Amlioration du formalisme de LanguageTool 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 postag="SENT_START"/>
<token postag="D.*" postag_regexp="yes"/>
<token postag="N .* s" postag_regexp="yes"/>
<token 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
Chapitre 3 : Amlioration du formalisme de LanguageTool 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.
Chapitre 3 : Amlioration du formalisme de LanguageTool 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
Chapitre 3 : Amlioration du formalisme de LanguageTool 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.
Chapitre 3 : Amlioration du formalisme de LanguageTool 59
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.
<pattern>
mark_from
mark_to
<message>
<example +>
type
<chunk +>
cat
negate
skip
<suggestion +>
<marker +>
<token +>
cat
inflected
regexp
negate
skip
<feature +>
genre
nombre
temps
mode
pers
type
fonction
<feature +>
genre
nombre
temps
mode
pers
type
fonction
<exception +>
cat
inflected
regexp
negate
<exception +>
cat
inflected
regexp
negate
<feature +>
genre
nombre
temps
mode
pers
type
fonction
<feature +>
genre
nombre
temps
mode
pers
type
fonction
<unify>
chunk
token
feature
<rule +>
ID
name
(3.1.1)
(3.1.2)
(3.1.3)
(3.1.2)
(3.1.3)
(3.1.4)
(3.1.5)
(3.1.8)
(3.1.6)
(3.1.7)
(3.1.9)
(3.1.9)
(3.1.9)
(3.1.9)
(3.1.8)
Chapitre 3 : Amlioration du formalisme de LanguageTool 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>
Chapitre 3 : Amlioration du formalisme de LanguageTool 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 :
Chapitre 3 : Amlioration du formalisme de LanguageTool 62
<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>
<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.
Chapitre 3 : Amlioration du formalisme de LanguageTool 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 genre="e" nombre="p">les</D>
<N genre="e" nombre="p">gens</N>
<R type="rel" genre="m" nombre="p" >qui</R>
<R type="pers" fonction="obj" pers="3" genre="e" nombre="s">l'</R>
<V temps="pres" mode="ind" pers="3" nombre="p">entourent</V>
<M 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 64
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>
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.
Chapitre 3 : Amlioration du formalisme de LanguageTool 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 66
Supposons ensuite que le syntagme suivant appartienne une phrase tiquete du texte :
<SN genre="f" nombre="s"> <D genre="m" nombre="s">un</D> <N genre="f"
nombre="s">phrase</N></SN>
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 genre="e" nombre="p">les</D>
<N genre="e" nombre="p">gens</N>
<R type="rel" genre="m" nombre="p" >qui</R>
<R type="pers" fonction="obj" pers="3" genre="e" nombre="s">l'</R>
<V temps="pres" mode="ind" pers="3" nombre="p">entourent</V>
<M 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 67
Voici un exemple de la segmentation que nous obtenons pour la phrase
"*Il vit avec les gens qui l'entoure" :
<SV type="ppal">
<R type="pers" fonction="suj" pers="3" nombre="s">Il</R>
<V aux="avoir" mode="ind" temps="pres" pers="3"
nombre="s">vit</V>
</SV>
<SP>
<P>avec</p>
<D genre="e" nombre="p">les</D>
<N genre="e" nombre="p">gens</N>
</SP>
<R type="rel" genre="e" nombre="p" >qui</R>
<R type="pers" fonction="obj" pers="3" genre="e" nombre="s">l'</R>
<SV type="rel">
<V temps="pres" mode="ind" pers="3" nombre="s">entoure</V>
</SV>
<M fin="yes">.</M>
Dans cet exemple, nous voyons qu'il y a deux chunks verbaux. Le premier, le principal,
inclut le pronom personnel sujet, avec lequel la dpendance est trs forte. Le second est li au
pronom relatif qui, qui constitue un chunk lui tout seul.
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 :
2
Le point utilis dans le motif sert remplacer n'importe quel caractre
Chapitre 3 : Amlioration du formalisme de LanguageTool 68
<SN pers="3" genre="f" nombre="p">
<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.
Chapitre 3 : Amlioration du formalisme de LanguageTool 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
Chapitre 3 : Amlioration du formalisme de LanguageTool 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 qui choue l'cole ont des grandes capacit
linguistique" :
<SN genre="e" nombre="p">
<D genre="e" nombre="p">Les</D>
<N genre="e" nombre="p">enfants</N>
</SN>
<R type="rel" genre="e" nombre="p">qui</R>
<SV type="rel">
<V mode="ind" temps="pres" pers="3" nombre="s">choue</V>
</SV>
<SP>
<P></P>
<D genre="e" nombre="s">l'</D>
<N genre="f" nombre="s">cole</N>
</SP>
<SV type="ppal">
<V mode="ind" temps="pres" pers="3" nombre="p">ont</V>
</SV>
<SN>
<D genre="e" nombre="p">des</D>
<J genre="f" nombre="p">grandes</J>
<N genre="f" nombre="s">capacit</N>
<J genre="e" nombre="s">linguistique</J>
</SN>
Les erreurs d'accord en nombre dans le dernier syntagme nominal ont t bien identifies.
De mme que l'accord du verbe de la relative, qui aurait d tre au pluriel, comme son
antcdent.
Chapitre 3 : Amlioration du formalisme de LanguageTool 71
"*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>
<P>en</P>
<N genre="f" nombre="s">situation</N>
</SP>
<SP>
<P>de</P>
<N genre="m" nombre="s">test
</SP>
<SV type="ppal">
<V mode="ind" temps="pres" pers="3" nombre="s">s'autosurveille</V>
</SV>
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.
Chapitre 3 : Amlioration du formalisme de LanguageTool 72
"*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>
<P>en</P>
<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>
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 sujet-
participe 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
Chapitre 4 : Conclusions et perspectives
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.
Chapitre 4 : Conclusions et perspectives 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.
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
DTECTION DES FAUTES
(rgles d'erreurs; unification)
Texte
vrifier
phrases
et
tokens
texte
tiquet
en XML
texte
dsam-
bigus
TAGGING
Dsambigusa-
tion (rgles)
Texte
corrig
phrases
segmentes
en chunks
CHUNKING
orthographe
corrig par
l'utilisateur
chunks
corrigs par
l'utilisateur
TOKENIZA-
TION
tiquetage
en XML
Accords
inter-chunks
Vrification
orthographique
Erreurs dans
l'utilisation
des mots
substitution
de mots
corrige par
l'utilisateur
Accords
intra-chunks
Retour sur le tagging
pour rectifications aprs
corrections de l'utilisateur
Chapitre 4 : Conclusions et perspectives 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.
Chapitre 4 : Conclusions et perspectives 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.
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
MODLISATION
(rgles de correction)
VALIDATION
(application et
vrification)
OBSERVATION
(corpus
d'erreurs)
Chapitre 4 : Conclusions et perspectives 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 Mi!kowski en particulier. Nous avons soulev des problmes
linguistiques, auxquels ils ont rpondus avec leurs connaissances informatiques.
Par exemple, Mi!kowski 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
Chapitre 4 : Conclusions et perspectives 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 d'effectuer l'tiquetage morphosyntaxique (ou tagging)
automatiquement.
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 Stendhal-
Grenoble 3.
http://blogs.nuxeo.com/sections/blogs/myriam_lechelt/2005_11_30_gramooo-memoire-
slides/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

Vous aimerez peut-être aussi