Avant de nous lancer dans la conception d'un outil de désambiguïsation, prenons le temps de faire un petit point sur ce sujet. Nous verrons d'abord quelles sont les différentes méthodes existantes pour désambiguïser les mots polycatégoriels (appartenant à plusieurs catégories morpho-syntaxiques). Nous parlerons ensuite de la méthode choisie par Myriam, ainsi que des problèmes qu'elle a rencontrés, et pour finir nous ferons des suggestions pour résoudre certaines difficultés et améliorer la désambiguïsation.

Méthodes de désambiguïsation

Les désambiguïseurs sont de deux types. Certains sont probabilistes et d'autres à base de règles. Ils ont tous deux des avantages et des inconvénients.

1. Méthode statistique

Des probabilités sont calculées à partir d'un apprentissage sur un corpus étiqueté. Selon le système, les probabilités calculées sont celles de la contiguïté de 3 tags (ex.: GRAC), de 2 tags (ex.: première version de LanguageTool), ou celles que tel mot prenne tel tag.

Cette méthode a l'avantage d'être automatique et donc relativement facile à mettre en place. Un outil probabiliste peut par ailleurs être facilement appliqué à des langues diverses. Il suffit de fournir le corpus adéquat pour l'apprentissage des probabilités.

Par contre, la désambiguïsation est par la suite entièrement dépendante du corpus sur lequel a été effectué l'apprentissage. Ce corpus ne doit pas être trop spécialisé et doit être suffisamment grand pour contenir le maximum de structures, tout en ne pouvant jamais les contenir toutes. Qui plus est, il n'existe pas pour le français par exemple de corpus étiqueté qui soit librement utilisable, ce qui constitue donc un obstacle.

Par ailleurs,  en cas d'erreur de désambiguïsation, il n'y a aucun  recours possible au texte. Cette méthode n'est donc pas vraiment maîtrisable.

2. Méthode par règles

Les règles sont construites manuellement, elles se présentent généralement sous forme d'expressions régulières (ex.: Gramadoir) et portent sur le contexte immédiat.
Comme les règles de détection d'erreurs, elles fonctionnent sur le système du "pattern matching". Le mot et son contexte proche doivent donc correspondre exactement aux descriptions faites dans les règles pour pouvoir être désambiguïsés.
Si les systèmes appliquent les règles dans l'ordre où elles apparaissent dans le fichier, elles doivent être ordonnées (les plus générales en dernier).

L'avantage de cette méthode, par rapport à la méthode statistique, est qu'elle est bien plus maitrîsable. En cas d'erreur de désambiguïsation, il est facile de retrouver et modifier la règle qui pose problème. Il est par ailleurs possible de rajouter de nouvelles règles ou d'en supprimer selon les besoins.

Par contre, cette méthode requiert la rédaction, longue et coûteuse, de nombreuses règles.

Désambiguïsation pour Gramadoir

Myriam Lechelt a réalisé un important travail sur la désambiguïsation dans le cadre de l'adaptation de Gramadoir au français.
Elle a réalisé des règles de désambiguïsation dont elle a pu tester l'efficacité, en terme de décision (nombre de mots désambiguïsés) et de précision (nombre de mots désambiguïsés correctement), avec les outils de la campagne d'évaluation GRACE.

Ces règles sont de trois types :

• Au début du fichier se trouvent les règles particulières, qui désambiguïsent des cas bien précis. Ces règles ne fonctionnent que sur contexte non ambigu (au niveau de la catégorie morpho-syntaxique).
• Viennent ensuite les règles par défaut. Ces règles sont appliquées par exemple lorsque qu'un contexte ambigu empêche l'application des règles particulières. L'utilisation de règles par défaut est suggérée par Jacques Vergne et Emmanuel Giguet (Regards théoriques sur le tagging, 1998, GREYC, Université de Caen).
• Pour finir, des règles brutes très générales désambiguïsent tout (ou presque) ce qui n'a pas pu être désambiguïsé avec les règles précédentes. Ces règles sont nécessaires pour que plus aucun mot ne soit ambigu, car sinon la correction échoue. Le système de Gramadoir ne tolère en effet aucune ambiguïté.
  

Avec ses règles, Myriam a pu désambiguïser 98,88% des mots (décision), dont 84,49% avec la bonne étiquette (précision), ce qui est plutôt encourageant même s'il reste encore beaucoup de travail et de problèmes à résoudre.

Par exemple, la désambiguïsation de la négation ne pas, ainsi que des modes et des personnes pour les verbes, pose un problème qui n'a pas été résolu.
Ce problème est dû notamment au fait que la désambiguïsation utilise le contexte immédiat du mot à désambiguïser. Dans le cas des modes, le contexte immédiat ne suffit pas et une analyse de la phrase entière est nécessaire pour désambiguïser.
Par ailleurs, le contexte peut parfois être inconnu, ambigu ou faux, et dans ce cas la désambiguïsation est mal ou pas du tout effectuée. Une règle disant que "si pas est précédé de ne, alors pas est adverbe de négation" ne désambiguïsera que si elle trouve ne dans le contexte. Or, l'oubli de ne est justement une faute très fréquente en français.

Suggestions d'amélioration

La désambiguïsation a pour but de définir pour chaque mot une étiquette unique, parmi celles attribuées par le tagger. Mais une désambiguïsation erronée, conduisant donc à un mauvais étiquetage, peut entraîner de fausses détections lors de la vérification grammaticale. Or, le bruit est très gênant pour l'utilisateur, bien plus que le silence.

Ne vaudrait-il pas mieux laisser plusieurs étiquettes dans certains cas ? En particulier dans le cas d'une ambiguïté au niveau des traits pour une même catégorie ? Nous pourrions limiter la désambiguïsation aux seules catégories, et non aux tags complets.

Par exemple, si l'utilisateur a écrit une livre, le désambiguïseur déduira sans doute sans difficulté, grâce au déterminant, que livre est ici un nom et non le verbe livrer. Mais une ambiguïté persiste alors au niveau du genre de ce nom, puisqu'il peut être masculin ou féminin. Si une règle par défaut attribue le tag "N sing masc" à livre, lors de la détection d'erreurs, le système va repérer un problème d'accord entre une et livre, alors que l'utilisateur n'avait en fait pas commis d'erreur. En laissant l'ambiguïté au niveau du trait genre, aucune erreur n'aurait été détectée.

L'avantage de cette méthode est qu'elle privilégie le silence au bruit. Elle peut en effet laisser passer de vraies fautes puisque l'étiquetage est moins précis, mais elle permet aussi de réduire les mauvaises détections dues à un mauvais étiquetage. La faute est détectée seulement si aucune des étiquettes ne convient.

L'intérêt réside aussi dans la résolution partielle des problèmes dus à un contexte faux. Il faut en effet garder à l'esprit que le tagging s'effectue sur des phrases potentiellement fausses, puisque le but est justement d'en vérifier la grammaire. Ainsi, si nous avons le syntagme le plante, (plante pouvant être un nom ou un verbe) avec une règle qui dit que "si un nom féminin singulier ambigu est précédé d'un déterminant féminin singulier, alors c'est un nom féminin singulier", dans ce cas la règle ne correspond pas puisque le déterminant est masculin. La désambiguïsation n'est donc pas effectuée.
En ne travaillant qu'avec les catégories des mots ambigus, on aurait une règle du type : "si un nom ambigu est précédé d'un déterminant, alors c'est un nom". Dans ce cas, la règle de désambiguïsation peut s'appliquer.

Par contre, LanguageTool fonctionne actuellement d'une manière différente de celle que nous venons d'évoquer, à savoir la non application d'une règle d'erreur si un des tags ne lui correspond pas. En effet, lorsqu'il rencontre un mot ambigu (il n'a pas de désambiguïseur), il essaye d'appliquer les règles à tous les tags du mot. Il suffit qu'un seul d'entre eux corresponde à la règle pour qu'elle s'applique (cf. test des règles). Il faudrait au contraire que la règle ne s'applique que si tous les tags lui correspondent. Autrement dit, une seule étiquette ne remplissant pas les conditions de la règle devrait suffire à empêcher son application.

Par ailleurs, la désambiguïsation pourrait aussi être améliorée en utilisant des règles de déduction négative, c'est-à-dire des règles permettant de dire que, dans tel contexte, un mot ne peut pas avoir telle étiquette.
Gramadoir ne prend pas en charge ce genre de règles. Il n'utilise que la déduction "affirmative", pour laquelle il est nécessaire d'écrire des règles parfois nombreuses pour énumérer tous les contextes dans lesquels tel mot prend tel tag. Il serait utile dans ces cas-là de pouvoir utiliser des règles fonctionnant sur le principe de l'élimination.
Cependant, tout comme l'application des règles "affirmatives" dépend du contexte immédiat, les règles négatives dépendent de l'exhaustivité de la liste des tags attribués à chaque mot. En effet, il faut impérativement que l'étiquette attendue fasse partie de la liste. Or les lexiques ne sont pas nécessairement exhaustifs.

Conclusion

Nous voyons un peu mieux ce qu'il en est de la désambiguïsation, les différentes manières de la réaliser, avec leurs avantages et leurs inconvénients, les problèmes qui peuvent se poser, les solutions et améliorations que l'on peut apporter.
Nous pouvons donc maintenant réfléchir plus sérieusement à la manière dont nous allons construire le désambiguïseur que nous implanterons dans LanguageTool, pour traiter les nombreux cas d'ambiguïté morpho-syntaxique que compte la langue française.

L'intérêt le plus évident concerne les accords entre les divers éléments de la phrase. Il peut s'agir aussi bien d'accords dans un groupe nominal que d'accords entre le sujet et le verbe par exemple.

Correction "intra-chunk"

Les mots fonctionnels contenus dans un chunk sont dépendants de la tête du chunk et contraints de s'accorder avec elle. En attribuant des traits morpho-syntaxiques à tous les éléments d'un syntagme et en utilisant une méthode d'unification des traits, il est assez facile, au niveau de la correction grammaticale, de détecter une erreur au sein d'un syntagme. Tous les éléments d'un chunk doivent avoir leurs traits qui s'unifient entre eux. Si ça n'est pas le cas, c'est qu'il y a une erreur.
Autrement dit, dans un chunk nominal qui serait du type "DET ADJ N" (ex: les grandes vacances), le déterminant "DET" et l'adjectif "ADJ" doivent tous deux s'accorder avec le nom "N" qui est la tête du chunk. Leurs traits doivent donc s'unifier.
En utilisant un découpage par chunks et l'unification de traits, on ne fait plus d'accord mot à mot et entre catégories de mots. On n'accorde plus un "déterminant masculin singulier" avec un "nom masculin singulier", mais un élément "masculin singulier" avec un autre "masculin singulier". En s'intéressant aux traits et non plus aux catégories, on évite ainsi d'avoir à prévoir toutes les combinaisons de mots pouvant constituer un syntagme nominal par exemple ("DET NOM", "DET ADJ NOM", "DET NOM ADJ", "DET ADV ADJ NOM ADJ", etc).

Correction "inter-chunks"

La détection des fautes de grammaire passe ensuite par une bonne mise en relation des éléments dans la phrase. De la même manière que tous les éléments d'un chunk doivent s'unifier entre eux, tous les chunks d'une phrase doivent aussi s'unifier. La méthode d'unification des traits 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 le trait "3ème pers sing", alors le chunk sujet doit obligatoirement avoir le trait "3ème pers sing" pour que l'unification des 2 chunks puisse se faire. Dans le cas contraire, une erreur d'accord sujet-verbe sera détectée.
Les accords se font entre groupes. Il n'est plus nécessaire de construire un nombre très important de règles décrivant toutes les combinaisons possibles. On évite par exemple d'avoir à prévoir toutes les combinaisons de mots que l'on peut trouver avant un verbe, en tant que sujet, ce qui est par ailleurs impossible. Les chunks permettent le traitement par groupes de mots, ayant chacun des règles spécifiques selon leur type, ce qui permet de beaucoup simplifier l'analyse syntaxique.

Correction dans les relations distantes

Ce type de traitement peut aussi s'avérer utile pour traiter certaines relations de dépendance distantes, qui posent beaucoup de problèmes aux correcteurs grammaticaux. Un simple accord entre un sujet et un verbe éloignés peut être très difficile à vérifier. Or, une propriété du chunk sujet est d'être généralement le premier syntagme à gauche du chunk verbal, à condition que ce syntagme soit nominal. Le découpage en chunks peut donc aider à résoudre les problèmes de détection de certaines fautes auxquels se heurtent une grande partie des correcteurs.

Aide à la désambiguïsation

Par ailleurs, la segmentation en syntagmes peut avoir un intérêt au niveau de la désambiguïsation. Par exemple, même si cela semble évident, un chunk nominal doit obligatoirement contenir un nom. Si un syntagme nominal ne contient pas de nom, le système recherche dans le chunk un mot ambigu qui peut avoir le tag "nom" mais qui ne lui a pas été attribué, et rectifie alors l'étiquetage afin que le chunk contienne un nom. Un chunk nominal sans nom peut être défini lorsque le système rencontre un déterminant (condition d'ouverture d'un chunk nominal) et lorsque le nom qui le suit est ambigu (avec un verbe par exemple) et mal étiqueté. On obtient ansi un chunk nominal constitué d'un déterminant, puis d'un verbe.

Conclusion

L'utilisation combinée des chunks et de l'unification peut donc nous permettre de réduire considérablement le nombre de règles nécessaires à la bonne correction de la grammaire française. Elle peut aussi aider à la détection problématique de certaines fautes entre chunks distants, et éventuellement compléter la désambiguïsation.

Nous avons pu noter, à travers quelques tests, que les points faibles de LanguageTool, pour la correction grammaticale du français en particulier, sont l'absence de désambiguïsation et les règles de détection des fautes.

Une partie de notre travail va donc consister à réaliser un outil de désambiguïsation qui nous permettra de réduire le nombre de tags des mots ambigus (sans toutefois le limiter nécessairement à un tag unique). Nous pourrons nous aider pour cela des règles de désambiguïsation écrites par Myriam Lechelt pour Gramadoir.

Pour ce qui est des règles d'erreurs, nous allons utiliser l'approche proposée par Myriam, à savoir la segmentation en chunks et l'unification de structures de traits. Voici une petite explication sur ce qui se cache derrière ces deux notions.

Qu'est-ce qu'un chunk ?

Un chunk, ou syntagme, est "une unité constituée d'une série de mots tous contigus les uns aux autres et regroupés autour d'une tête lexicale, le plus souvent un nom ou un verbe, plus rarement un adverbe, un adjectif ou un pronom." (GIGUET, 1998).

Les chunks sont délimités grâce aux mots grammaticaux, à la ponctuation ou aux marques morphologiques. En général, un chunk commence par un mot grammatical ou juste après une ponctuation, et se termine juste avant une ponctuation ou le mot grammatical suivant, qui marquent le début d'un nouveau syntagme.

Par exemple, un syntagme nominal contient obligatoirement un nom (tête du chunk) et commence généralement par un déterminant. Un syntagme verbal commence par un verbe, parfois un pronom personnel ou un adverbe de négation, et contient nécessairement un verbe.

Un chunk dépend généralement de son prédécesseur, sauf dans le cas d'un chunk verbal. Ce dernier dépend du chunk sujet, qui correspond en principe au premier syntagme à gauche, à condition qu'il soit nominal.

La structure interne d'un chunk est relativement figée. Les mots fonctionnels qu'il contient entretiennent des relations de dépendance avec la tête lexicale et les contraintes d'accords sont assez fortes. Par contre, au sein d'une phrase, les différents chunks sont permutables. Dans l'exemple suivant extrait du Bourgeois Gentilhomme de Molière, nous pouvons voir que la phase est constituée de cinq syntagmes que l'on peut permuter, mais au sein desquels les éléments 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].

Un chunk dépend généralement de son prédécesseur, sauf dans le cas d'un chunk verbal.

Qu'est-ce que l'unification de structure de traits ?

Les structures de traits décrivent chaque élément d'une phrase un énumérant ses caractéristiques linguistiques, syntaxiques ou sémantiques, sous la forme de listes de couples trait-valeur.
Un trait peut avoir pour valeur un ou plusieurs couples trait-valeur. Dans ce cas, la structure de trait est dite récursive.

L'unification consiste à combiner les informations (sous forme de structures de traits) de deux éléments d'une phrase et permet de vérifier leur compatibilité.
Si 2 structures de traits ont les mêmes valeurs pour des traits identiques, alors elles peuvent s'unifier. Si 2 traits identiques n'ont pas la même valeur dans les 2 structures de traits, alors l'unification échoue. Si un trait n'est présent que dans une des deux structures, cela n'influe pas sur l'unification, qui échoue dans le cas de valeurs contradictoires pour un même trait, mais pas dans le cas d'absence d'un trait.

Il y a unification entre les et chats dans l'exemple 1 ci-dessous, mais pas entre les et chat dans l'exemple 2, car les traits "nombre" ont deux valeurs contradictoires :

Tests de règles existantes

Nous avons rapidement testé LanguageTool avec quelques règles en français, écrites par Myriam Lechelt pour Gramadoir, et adaptées ensuite au formalisme de LanguageTool.

Conséquences de l'absence de désambiguïsation

Nous avons alors pu remarquer beaucoup de problèmes dans la détection des erreurs, dus principalement à l'absence de désambiguïsation après le tagging. En effet, les mots ambigus ont plusieurs tags et lors de l'application des règles d'erreurs, il suffit qu'un des tags corresponde à une règle pour que celle-ci soit appliquée, même si un ou plusieurs autres tags du mot ne correspondent pas à cette règle.
On peut constater cela avec l'exemple suivant, portant sur la confusion entre sa et ça.

Nous disposons des deux règles suivantes :

1. si sa est suivi d'un verbe puis d'un mot quelconque, alors il y a une erreur et il faut remplacer sa par ça.
2. si ça est suivi d'un nom puis d'un mot quelconque, alors il y a une erreur et il faut remplacer ça par sa.
   

Prenons maintenant les deux phrases :

• (a) Sa voiture est en panne.
• (b)*Ça voiture est en panne.

Le mot voiture est ambigu. Il peut s'agir du nom voiture ou du verbe voiturer. Le mot a donc 2 étiquettes : "nom" et "verbe".

Lors de la vérification des phrases, tous les tags d'un mot sont pris en compte pour l'application des règles.
La règle 1. s'applique donc (à tort) à la phrase (a) car elle trouve un tag "verbe" pour voiture, précédé de sa. Il est alors suggéré de remplacer sa par ça. 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 règle 2. s'applique à la phrase (b) car elle trouve un tag "nom" pour voiture, précédé de ça. Il est alors suggéré de remplacer ça par sa. Ici, la détection est correcte. Il y a bien une faute.

Les énoncés (a) et (b) sont donc tous deux considérés comme faux, chacun donnant l'autre comme correction, ce qui est contradictoire.

Tentative de contournement du problème...

Nous avons tenté de réduire le bruit provoqué par la règle 1. en la modifiant : ça suivi de 2 verbes au lieu d'un seul. Cela permet de pallier en partie le problème de l'ambiguïté de voiture, mais nous réalisons alors qu'il est nécessaire d'avoir des règles plus complexes et précises pour contourner l'absence de désambiguïsation et le fait que beaucoup de mots ont plus d'une étiquette.

D'autres exemples sur ce problème

Les autres règles aussi entraînent beaucoup de mauvaises détections d'erreurs, dues à l'ambiguïté verbe-nom le plus souvent.
Par exemple :
La visite a duré longtemps             est corrigé :     La visite à duré longtemps            car le tag "verbe" de visite correspond à la règle.
Il se trompe toujours de numéro    est corrigé :     Il ce trompe toujours de numéro    car le tag "nom" de trompe correspond à la règle.
Tu peux utiliser ce téléphone         est corrigé :     Tu peux utiliser se téléphone        à cause du tag "verbe" de téléphone qui correspond à la règle.
Ces lignes ne sont pas droites        est corrigé :     Ces lignes ne son pas droites        car pas a le tag "nom" qui entraine l'application de la règle.
Il a publié son livre                        est corrigé :     Il a publié sont livre                      car le tag "verbe" de livre correspond à la règle.

Création de nouvelles règles

Nous avons aussi tenté de créer des règles nouvelles pour nous confronter aux problèmes d'écriture de règles d'erreur.

La négation

Nous avons écrit une règle pour la détection d'erreur sur la négation, qui permet de détecter l'omission de la particule ne dans une phrase négative avec pas ou jamais.
Si dans une phrase un verbe n'est pas précédé de ne ou n', mais qu'il est suivi de pas ou jamais (eux-mêmes non précédés d'un déterminant pour éviter la confusion avec le nom pas), avec une suite quelconque de mots entre le verbe et pas, alors une faute est détectée.

Même si la règle fonctionne relativement bien, nous nous rendons compte là encore qu'il est nécessaire de contourner l'absence de désambiguïsation par des règles plus compliquées.

L'accord déterminant-nom

Nous avons voulu faire une règle pour l'accord entre un déterminant et un nom qui détecterait une erreur dans le cas où un nom masculin singulier ne serait pas précédé d'un déterminant autre que masculin singulier. Mais nous avons eu un souci avec l'expression régulière qui n'a jamais voulu fonctionner...

Cependant, cela nous a quand même permis de prendre conscience du très grand nombre de règles qu'il est nécessaire de rédiger pour couvrir le plus de cas possibles. Dans son mémoire, Myriam avait calculé le nombre de combinaisons possibles déterminant, adjectif, nom et déterminant, nom, adjectif. Étant donné que chacune de ces catégories peut avoir trois genres (masculin, féminin, épicène) et trois nombres (singulier, pluriel, invariable), on obtient 1458 combinaisons possibles, donc presque autant de règles à rédiger (il faut enlever les combinaisons correctes puisque les règles décrivent des erreurs).
Il y a bien sûr moyen de créer un programme qui génère ces règles automatiquement, mais c'est un nombre tout de même très important et qui correspond au traitement d'une petite partie de la syntaxe seulement. On voit donc que la liste de règles à créer peut vite devenir considérable, sans jamais pouvoir être exhaustive, car il n'est pas possible de prévoir toutes les erreurs qui peuvent être commises dans un texte.

Conclusion

En conclusion de ces petits tests, nous pouvons dire que le principal problème que nous avons rencontré est celui de l'absence de désambiguïsation, que nous allons essayer de combler. Nous allons par ailleurs modifier la méthode actuelle de détection des fautes, qui nécessite trop de règles, afin qu'elle soit plus adaptée à la grammaire française.

LanguageTool est un correcteur libre de style et de grammaire, développé initialement pour l'anglais par Daniel Naber et adapté par la suite à d'autres langues comme l'allemand, le hongrois ou encore le polonais.

Il était à l'origine programmé en python mais a été entièrement réécrit en java (pour un meilleur support du format XML utilisé notamment pour les fichiers de règles d'erreurs, comme nous allons le voir pas la suite).

Il est composé de plusieurs modules qui effectuent successivement :

1. la segmentation du texte à vérifier en phrases
2. la segmentation des phrases en mots
3. l'étiquetage morpho-syntaxique des mots : les mots ambigus reçoivent plusieurs étiquettes correspondant aux diverses catégories morpho-syntaxiques auxquelles ils peuvent appartenir ainsi qu'aux différents traits qu'ils peuvent avoir dans une catégorie, et ils les conservent toutes car aucune désambiguïsation n'est effectuée. Ainsi bête aura les étiquettes <nom féminin singulier>, <adjectif masculin singulier> et <adjectif féminin singulier>.
4. la détection des erreurs de grammaire : elle s'effectue par comparaison de chaque segment de phrase avec une base de règles décrivant des erreurs. Si un segment correspond à une règle, alors une erreur est détectée.

Les règles d'erreurs sont formalisées en XML et sont composées de plusieurs éléments :

• id et name : respectivement l'identifiant et le nom de la règle
• pattern : modèle de l'erreur
• message : description de la règle à l'usage de l'utilisateur
• example  : exemple d'énoncé correspondant à la faute commise. Il y a en général au moins deux exemples : un exemple d'énoncé correct et un exemple d'énoncé incorrect.

L'élément pattern est le plus important. C'est lui qui décrit le modèle de l'erreur et avec lui que les phrases sont comparées lors de la détection. Le modèle se présente généralement sous la forme d'expression(s) régulière(s).

Voici un exemple de règle en français :

<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>répondu.</example>
    <example type="correct">Il <marker>m'a</marker>répondu.</example>
</rule>

Cette règle détecte une confusion dans l'utilisation des homophones m'a  et ma. Si le texte à vérifier contient ma suivi d'un verbe (V), suivi de n'importe quel mot (.*), alors il y a une erreur.

Avant de décrire la structure de LanguageTool, nous pouvons commencer par expliquer le fonctionnement des correcteurs grammaticaux de manière générale.

Le texte à vérifier est d'abord découpé en phrases, puis les phrases en mots. C'est la tokenisation.

Vient ensuite la phase d'étiquetage morpho-syntaxique (ou tagging). Chaque mot se voit attribuer une ou plusieurs étiquettes (tags) contenant des informations telles que la catégorie morpho-syntaxique (verbe, nom, adjectif, pronom, etc), ainsi que le genre et le nombre (pour les noms, les adjectifs...), le temps, le mode, la personne, etc... pour les verbes.

Lors du tagging, les très nombreux mots ambigus reçoivent plusieurs tags. Une désambiguïsation est nécessaire pour limiter le nombre d'étiquettes de chaque mot et améliorer par la suite la détection de fautes de grammaire.
Certains correcteurs utilisent une méthode probabiliste pour désambiguïser les mots. Ils nécessitent un corpus d'apprentissage sans erreurs et étiqueté avec les informations morpho-syntaxiques. Ils calculent alors la probabilité que tel mot ait tel tag plutôt qu'un autre, ou encore la probabilité qu'un mot ait un certain tag en fonction des tags des mots qui l'entourent. Lors du tagging, ces probabilités sont appliquées aux mots du texte à analyser et chaque mot reçoit alors le tag qui correspond à la plus forte probabilité.
Cette méthode est contraignante dans la mesure où la détection des fautes est très dépendante du corpus ayant servi à l'apprentissage. Par ailleurs, le corpus étiqueté nécessaire doit être le plus grand possible. Il n'en existe pas forcément de disponible ou de convenable, et la constitution d'un tel corpus est très coûteuse.
Une autre méthode consiste à utiliser des règles manuelles de désambiguïsation sous forme d'expressions régulières, basées sur le contexte immédiat. Cette méthode est plus contrôlable que la méthode statistique, mais elle nécessite des règles descriptives qui doivent être suffisamment nombreuses pour couvrir le plus de cas possibles, des règles qui sont rédigées manuellement et donc longues à produire, et qui ne peuvent par ailleurs pas être exhaustives.
Certains correcteurs combinent les 2 méthodes, d'autres ne font pas de désambiguïsation.

Une fois l'étiquetage terminé, commence alors l'étape de détection des erreurs. Il existe là encore deux manières de procéder.
Certains correcteurs utilisent des règles prescriptives et d'autres des règles d'erreurs. Les premiers comparent donc le texte avec une liste de formes correctes. Dans le cas où ils ne trouvent pas de correspondance, ils détectent une erreur. Les seconds, au contraire, comparent le texte avec des règles décrivant des erreurs. S'il y a correspondance, c'est qu'il y a une faute.
Dans les deux cas, plus il y a de règles, meilleure sera la détection. Mais il est impossible de prévoir et donc de décrire toutes les erreurs possibles. Il y aura donc potentiellement toujours des erreurs non décrites dans les règles, non détectables par le correcteur, et donc beaucoup de silence.
Les règles de grammaire sont moins nombreuses mais tout de même difficiles à rédiger de manière exhaustive, et tout ce qui ne correspond pas à une règle étant considéré comme une faute, il peut y avoir beaucoup de bruit, c'est-à-dire beaucoup de détections d'erreurs qui n'en sont pas.

Je vais ici faire un résumé rapide de l'important travail effectué par Myriam Lechelt sur le projet de correcteur grammatical dont je prends la suite.

Dans le cadre de son mémoire de DEA, Myriam a donc initié un travail dont l'objectif est, à terme, de créer un outil de correction grammaticale libre pouvant être intégré à OpenOffice.org. Plutôt que de chercher à réaliser entièrement un nouvel outil, elle a réalisé une analyse de plusieurs correcteurs grammaticaux libres déjà existants, afin de déterminer lequel serait le plus adaptable au français.

Parmi les correcteurs analysés (GRAC , LanguageTool et  An Gramadoir), c'est Gramadoir qui a été retenu pour être adapté au français. Son adaptation s'est traduite par la définition d'un jeu d'étiquettes pour l'étiquetage morpho-syntaxique des mots ( tagging), par l'écriture de règles de désambiguïsation pour la phase du tagging, puis par la création de quelques règles  pour la détection des fautes.

L'adaptation de Gramadoir au français n'a pas été achevée, et malgré des résultats plutôt satisfaisants lors des premiers tests, l'outil a montré des limites pour le traitement du français.

Une approche alternative a finalement été proposée, dans l'éventualité de la conception d'un nouveau correcteur. Elle consiste à introduire un niveau intermédiaire entre le mot et la phrase, le chunk (ou syntagme), lors de la segmentation des phrases et à utiliser le principe de l'unification de structures de traits au niveau de la vérification grammaticale. Nous reviendrons ultérieurement sur les notions de chunk et d'unification.

Les travaux de Myriam ayant montré que le traitement du français par Gramadoir restera limité, nous n'allons pas continuer à exploiter ce système. Nous avons décidé par ailleurs de ne pas non plus concevoir un correcteur entièrement nouveau. Nous allons plutôt réaliser une adaptation de la dernière version de LanguageTool. En effet, il y a eu beaucoup d'évolutions entre l'ancienne version rejetée à l'époque, et la nouvelle, qui semble mieux adaptable au français. Nous allons la compléter en suivant les pistes données par Myriam pour la conception d'un nouveau correcteur.

Je suis étudiante en 2ème année de Master recherche Industries de la langue. Mon mémoire de recherche s'inscrit dans le prolongement du travail initié par Myriam Lechelt en 2005, à savoir le projet de développement d'un correcteur grammatical libre pouvant être intégré à la suite OpenOffice.org.

Le travail effectué par Myriam a permis de montrer les limites des outils Gramadoir (http://borel.slu.edu/gramadoir/) de Kevin Scannell et LanguageTool (http://www.danielnaber.de/languagetool/) de Daniel Naber pour leur adaptation à la correction grammaticale du français.
LanguageTool a entre temps beaucoup évolué et la nouvelle version semble plus adaptable au français que ne l'étaient l'ancienne version et Gramadoir.

Mon travail va donc consister

• à reprendre le travail de Myriam Lechelt, notamment sur les règles d'erreurs à compléter
• à étudier la nouvelle version de LanguageTool et lui apporter les modifications nécessaires à une meilleure adaptation à la grammaire française,
• dans le but d'obtenir un outil générique et libre adapté au français et pouvant être intégré à OpenOffice.org ou à d'autres projets.
  

J'ai par ailleurs effectué un stage au sein de la société Nuxeo-InDesko durant l'été 2006. L'objectif était la création d'un outil d'extraction automatique d'affixes à partir d'une liste de mots, afin de pouvoir générer automatiquement, pour toute langue, un fichier d'affixes et un dictionnaire compatibles avec le correcteur orthographique d'OpenOffice.org. Les fichiers actuels sont construits manuellement et très coûteux à produire.
http://w3.u-grenoble3.fr/lebarbe/agnes/index.php