Deux objectifs ont fortement orientés nos choix techniques :
A priori, ces deux objectifs semblent difficilement conciliables. En effet, pour pouvoir intégrer le correcteur orthographique dans des applications existantes, on peut, de manière générale, être amené à recourir à des technologies propriétaires et, par conséquent, spécifiques à une plateforme donnée.
Imaginons qu´on souhaiterait, sans autre objectif, implémenter un correcteur orthographique devant s´intégrer au traitement de texte « Word » de la société Microsoft. La solution la plus simple consisterait à étendre ce logiciel bureautique au moyen d´une macro écrite en VBA (VisualBasic for Applications). On aurait alors réalisé une solution dépendant d´une plateforme particulière, dans la mesure où VBA est un langage de programmation propriétaire, disponible sur les systèmes Windows exclusivement.
De ce fait, l´approche ébauchée ci-dessus était exclue d´office.
Pour répondre au premier objectif, nous avons décidé d´implémenter l´essentiel du correcteur orthographique en Java. Le langage de programmation Java a atteint un degré de maturité tel que rien ne s´oppose à son utilisation dans des projets d´envergure. Comme, par conception, le langage Java est indépendant d´une architecture matérielle et d´une plateforme système particulières, la portabilité de la plus grande partie du correcteur était garantie.
Néanmoins, afin de pouvoir intégrer le correcteur orthographique dans des outils existants (Word, StarOffice etc.), certaines parties ont dû être implémentées au moyen de langages propriétaires (VisualBasic, StarBasic, etc.). De manière à minimiser l´effort de portage (nécessaire pour intégrer le correcteur dans un nouvel outil), cette partie du correcteur devait être réduite au maximum.
Le problème qu´il faillait ensuite résoudre consistait à faire communiquer la partie la plus importante du correcteur, écrite en Java, avec la partie intégrée à l´application hôte, écrite dans un autre langage de programmation.
Ici encore, notre souci était d´être liés le moins possible à une plateforme spécifique. Afin de garder une flexibilité maximale, nous avons décidé de nous orienter vers une solution client/serveur, le client et le serveur communiquant au moyen de « sockets ». En effet, le mécanisme de communication inter-processus des « sockets » est un mécanisme qui est disponible pratiquement sur tous les systèmes et peut être utilisé à partir de n´importe quel langage de programmation. Qui plus est, ce mécanisme permet de distribuer les processus communiquants à travers un réseau informatique, ajoutant encore à la flexibilité.
Ainsi, les prototypes intégrés aux logiciels de traitement de texte « Word » et « StarOffice » se présentent comme suit :
Les modules en bleu foncé constituent les prototypes. Les modules du côté gauche de la figure s´exécutent en local sur la machine de l´utilisateur, ceux du côté droit sur les serveurs distants (actuellement les serveurs au CRP-Gabriel Lippmann).
La flexibilité de cette architecture nous a permis de mettre au point, sans trop d´efforts, des prototypes qui n´étaient pas prévus au début du projet mais qui nous ont permis d´augmenter la visibilité du projet. Ainsi un prototype permet de faire vérifier des mots isolés dans une page HTML :
D´autres prototypes, pouvant ètre utilisés sur la toile et nécessitant des architectures à étages multiples, ont également été développés assez rapidement. Nous disposons ainsi d´un prototype de correction de mots isolés (utilisant HTTP et, de ce fait, pouvant ètre utilisé derrière un firewall) et de deux prototypes de correction de textes (l´un utilisant du HTML pur, l´autre du HTML et du JavaScript) :
