2.1 – UniCrawl

7UniCrawl est un agent de recherche sur internet dont une des fonctionnalités premières est la surveillance et la collecte des informations diffusées en continu sur les sites d’information, quels que soient les langues et jeux de caractères utilisés par la source d’émission.

8UniCrawl visite donc régulièrement un ensemble de sources généralistes et spécialisées, sites de presse ou portails sélectionnés par des experts, à la recherche d’informations nouvelles. Sur ces sites, l’information est dite « furtive » dans la mesure où, présente un jour, elle peut avoir disparu le lendemain (c’est le cas des sites de quotidiens), voire même dans la journée. La périodicité des visites est donc variable et dépend de la fréquence de renouvellement de l’information sur chaque site.

9UniCrawl dispose d’un système de localisation automatique de l’information pertinente dans les pages de contenu. Ce système permet de masquer les éventuels rubans publicitaires et menus contextuels qui perturbent la lecture et l’analyse des documents issus des sites internet. Il est activable à souhait et ne présuppose aucune configuration manuelle, caractéristique essentielle vu que chaque source possède sa propre ligne éditoriale et que cette ligne est susceptible d’être refondue sans préavis.

10UniCrawl dispose également d’un système de filtrage et de catégorisation de l’information au sein de plans de classement. Ce système est basé sur la cooccurrence et la fréquence de mots-clés définis lors de l’initialisation de la veille et modifiables à volonté en cours de veille.

11UniCrawl est par ailleurs capable de gérer plusieurs dossiers de veille simultanément, dossiers reposant sur des périmètres variés (ensemble de sources à surveiller), des langues variées, des thématiques variées. Les mots-clés peuvent ainsi être fournis dans n’importe quelle graphie et n’importe quelle langue.

2.2 – Enjeu d’UniCrawl

12L’enjeu d’UniCrawl réside dans l’alimentation d’une plate-forme d’analyse de l’information multilingue pouvant gérer de multiples dossiers correspondant chacun à une problématique de veille particulière. Un dossier est défini par un ensemble de thématiques à considérer, un ensemble de langues ou de zones géographiques à contrôler, un ensemble de sources à surveiller.

13Plus le périmètre de la veille est vaste, et plus le nombre d’acteurs sur le dossier est important. Le projet rassemble alors des profils très variés, fonction du degré d’expertise du domaine et des compétences linguistiques de chacun. Bien évidemment les ressources humaines « rares » sont affectées à plusieurs dossiers, un expert du chinois ou du coréen pourra par exemple travailler simultanément sur quatre ou cinq dossiers.

14Se pose alors un problème de travail collaboratif, notamment pour l’accès au contenu d’une information rédigée dans une langue inconnue des experts du domaine : l’information est identifiée comme pertinente par le système mais comment y avoir accès ? Les experts linguistiques travaillant simultanément sur plusieurs dossiers ne peuvent être systématiquement réquisitionnés lors de la détection d’une nouvelle information.

15La constitution d’une plate-forme d’analyse multilingue et collaborative, construite autour d’Unicode apporte une réponse.

16Les experts du domaine ou responsables de dossier n’ayant pas les compétences linguistiques nécessaires peuvent de manière autonome visualiser l’information et demander au système une traduction automatique. Celle-ci, même de piètre qualité, permet d’avoir un premier aperçu de la pertinence de l’information. Si c’est le cas, ils peuvent alors formuler une requête de synthèse « manuelle » auprès de l’expert linguistique compétent. Celui-ci traitera alors le document en fonction de la répartition de son activité.

17C’est donc en unifiant les procédures de détection, d’archivage, de visualisation et d’analyse automatique (indexation, résumé, traduction automatique), qu’Unicode permet d’améliorer la surveillance d’une information internationale chaque jour plus abondante.

2.3 – Problématique de codage dans UniCrawl

18La constitution d’un fonds documentaire électronique à partir de sources variées nécessite, comme pour toute conception de systèmes d’information ouverts, une réflexion sur la gestion des codages des documents.

19Faut-il conserver les documents dans leur codage d’origine ? les convertir dans un codage unique dès leur entrée dans le système et ne garder que le document sous cette forme résultante ? ou bien conserver de manière permanente les deux versions ? ou bien alors convertir la version d’origine dans un codage commun uniquement lorsque le document est manipulé ? et si oui, quel codage unique choisir ? quelles propriétés doit-il avoir ?

20Et tout d’abord pourquoi ne pas tout simplement stocker et manipuler les documents sous leur forme d’origine, sans du tout se soucier de leur codage ? La réponse réside dans la nécessité d’un décodage correct des documents pour permettre un rendu visuel correct à l’utilisateur et une cohérence de l’analyse automatique de leur contenu.

21Concernant le décodage, la problématique est simple. Qui n’a jamais reçu de courriers électroniques dans lesquels les caractères accentués d’origine étaient mystérieusement et régulièrement remplacés par des caractères incongrus ? À qui la faute ? à l’auteur du message qui aurait dû se soucier de la diffusion de son document ? à son système informatique qui n’est pas compatible avec le vôtre ? ou bien au vôtre qui n’est pas compatible avec le sien ? ou bien à vous qui ne savez pas configurer votre machine pour afficher correctement un document externe ? ou bien au réseau au travers duquel a transité le fameux document ? Quoi qu’il en soit, le document ne s’affiche pas correctement et c’est plutôt rageant !

22Sur internet, auquel on accède couramment via un navigateur tel que Netscape ou Internet Explorer, les problèmes de décodage des pages ont quasiment disparu. Ceci est possible grâce à un enrichissement des protocoles d’échanges d’informations entre les systèmes informatiques distants, qui incluent des informations facultatives sur le codage utilisé, et des capacités des dits navigateurs qui assument désormais beaucoup plus correctement la gestion des codages à partir des informations contenues dans les protocoles et des techniques complémentaires d’identification automatique des codages. Cet enrichissement rend quasiment transparent pour l’utilisateur la variété des codages.

23Ceci dit, lorsque le problème est de concevoir un nouveau système d’information, ou en l’occurrence un agent de recherche, ces fonctionnalités de prise en charge des codages sont à intégrer. Elles sont d’ailleurs d’autant plus importantes à considirer si le systhme est censi jtre [2] multilingue car autant le texte reste lisible si le codage utilisé à la réception est proche de celui utilisé à l’émission, autant la compr=E9hension [3] peut xr%r$^l ^toudd^*nr [4] si les codages diffèrent totalement.

24Le rendu visuel est un premier point qui conduit à se soucier des variétés de codages ; la cohérence de l’analyse automatique du contenu en est un deuxième.

25Le rendu visuel est un premier point qui conduit à se soucier des variétés de codages ; la cohérence de l’analyse automatique du contenu en est un deuxième.

26L’agent de recherche incluant des fonctionnalités de filtrage et de catégorisation de l’information en fonction de leur contenu, il convient de gérer convenablement les codages afin de traiter de manière uniforme deux documents écrits dans la même langues et codés de manières différentes, afin de ne pas considérer deux sequences d’octets comme représentant deux mots différents, alors que la différence ne réside que dans la manière de représenter ce mot

2.4 – Stratégie de gestion des codages dans UniCrawl

27UniCrawl est un agent de recherche disposant d’une certaine autonomie. Nous souhaitions en effet disposer au minimum d’une interface de supervision permettant bien entendu de configurer des veilles mais également de composer et de publier des synthèses récapitulatives multiscripts (mêlant différents alphabets) sur l’information recueillie. La nécessité de passer par un codage unique était alors incontournable.

28Par ailleurs, UniCrawl a été conçu avec un soucis d’interfaçage avec un système d’analyse et de traitement de l’information plus général, incluant notamment des analyses linguistiques de contenu (résumé automatique, extraction de citations…). Ne souhaitant pas aborder dans tous les modules du système d’information la question du codage, nous avons choisi de régler le problème en amont, c’est-à-dire lors de l’alimentation : UniCrawl a donc été chargé de fournir des documents dans un codage unique.

29La stratégie de gestion des codages retenue dans UniCrawl est de passer par un codage unique, un format pivot dans lequel les documents sont convertis et stockés dès leur entrée dans le système. Ce codage ne devant pas induire de perte d’informations, c’est JUC [5], ou plus précisément Unicode, qui a été choisi pour sa capacité à représenter l’information multilingue. La forme stockée de caractère retenue est Unicode Transformation Format 8, à savoir UTF-8, la taille des documents devant rester raisonnable. UTF-8 convient également pour ses capacités à transmettre, traiter et stocker l’information, tout en garantissant une compatibilité avec d’autres standards (notamment IS0 4873 et ISO 2020). Avec UTF-8, le nombre d’octets nécessaires pour coder un caractère JUC varie de 1 à 6, le premier octet indiquant si besoin le nombre d’octets à suivre pour représenter le caractère. Le tableau 1 illustre ce principe. Le tableau 2 illustre la transformation de caractères JUC en UTF-8.

30La mise au point de la stratégie de gestion des codages et notamment le choix d’adopter Unicode comme format pivot n’a en fait pas suscité de longs débats. Des décisions plus délicates ont résidé dans le choix des langages et librairies permettant la manipulation aisée d’Unicode.

31L’intégration a montré que le support d’Unicode n’était encore que partiel dans beaucoup de distributions de langages de programmation, et qu’une fois réglés les derniers problèmes techniques sous-jacents, quelques lourdeurs d’utilisation liées semble-t-il à la conception même d’Unicode subsistent.

Tableau 1

Format des octets d’une séquence UTF-8

Fonction de l’octet Format binaire Nb de bits libres dans l’octet Nb de bits libres à suivre 1er d’une séquence de 1 0xxxxxxx 7 - 1er d’une séquence de 2 110xxxxx 5 6 1er d’une séquence de 3 1110xxxx 4 6+6 1er d’une séquence de 4 11110xxx 3 6+6+6 1er d’une séquence de 5 111110xx 2 6+6+6+6 1er d’une séquence de 6 1111110x 1 6+6+6+6+6 2e au 6e d’une séquence 10xxxxxx 6

Format des octets d’une séquence UTF-8

Tableau 2

Exemples de codage en UTF-8 d’un caractère JUC

Glyphe Code JUC (hexa) Nom du caractère JUC Code JUC (binaire) Code UTF-8 a 0061 LETTRE MINUSCULE LATINE A 1100001 01100001 é 00E9 LETTRE MINUSCULE LATINE E ACCENT AIGU 11101001 11000011 10101001 € 20AC SYMBOLE EURO 10000010101100 11100010 10000010 10101100

Exemples de codage en UTF-8 d’un caractère JUC

2.5 – Intégration d’Unicode dans UniCrawl

32Comme dans tout système d’information ayant abordé cette problématique, nous avons distingué deux phases dans la conversion des pages de contenu recueillies vers Unicode :

• une phase d’identification du codage de la page;
• une phase de transcodage du codage source vers Unicode

• à l’aide du paramètre optionnel « charset » du Content-Type situé dans l’entête mime définie par le protocole d’échange de documents hypertextes HTTP (c’est une des techniques utilisées par Internet Explorer) ;
• à l’aide de critères discriminants (séquences de bits caractéristiques d’un codage – technique mise en œuvre par exemple dans le package international de Mozilla de Netscape) ou par fréquence de séquences d’octets
• à l’aide de l’attribut optionnel ‘charset’ qui indique le codage utilisé dans une page HTML
• à l’aide d’un nom de codage associé à un site particulier.

33Les langages de programmation ne sont pas tous égaux face à Unicode. En fait, peu nombreux sont les langages qui supportent Unicode en natif. Le langage Perl fournit un support particulièrement agréable, notamment via les packages Unicode et utf8.

34Alors que la plupart des langages font correspondre un caractère à un octet, le support d’UTF-8 nécessite de gérer les caractères comme ayant des tailles variables en octets. Il s’ensuit que les primitives de manipulation de chaînes de caractères, conçues pour des caractères de taille fixe en octets, deviennent obsolètes. La longueur d’une chaîne n’est plus son nombre d’octets (ou un multiple du nombre d’octets), le nième caractère n’est plus le nième octet… tous les mécanismes d’itération sur les caractères sont à reconsidérer si le langage de programmation ne supporte pas UTF-8 en natif, idem pour les primitives de conversion ou de comparaison de chaînes en minuscules ou en majuscules [6]. Un des points les plus critiques concerne le support d’Unicode dans les expressions régulières, beaucoup utilisées en traitement automatique des langues [7]. Ces différents points sont abordés dans les rapports techniques Unicode accessibles en ligne à partir du site web http:// www. unicode. org. Perl a été un des premiers langages à fournir un support UTF-8 de qualité et reste aujourd’hui une excellente solution pour des mises en œuvre rapide d’Unicode.

2.6 – Analyse automatique de contenu Unicode

35Une fois réglés les problèmes de support d’Unicode par l’utilisation de primitives adaptées, l’analyse automatique de contenu avec Unicode ne pose pas de véritables problèmes. Les techniques d’analyse automatique de contenu traditionnelle restent valides. Bien entendu les éditeurs de fichiers ne fournissent pas tous un support d’Unicode et manipuler des lexiques ou des fichiers de règles Unicode dans un éditeur non compatible Unicode n’est pas toujours immédiat ! mais cela peut se régler facilement par l’utilisation d’un éditeur adapté.

36Unicode n’apporte cependant pas une réponse à tous les problèmes. On pourrait par exemple s’étonner du fait que plusieurs occurrences de caractères tels que les guillemets « à la française » ouvrant et fermant existent dans Unicode. Ce choix peut a priori surprendre. Il est motivé par le rendu visuel de ces caractères qui différent selon la langue : les ponctuations ont par exemple un alignement différent en chinois et en français. On aurait pu s’attendre à ce qu’une seule occurrence du caractère existe dans Unicode et que l’alignement soit géré contextuellement lors de la mise en page du texte, de la même manière qu’un texte en arabe est affiché contextuellement de droite à gauche lors de la mise en page. Lors d’analyse automatique de contenu, ces redondances imposent la manipulation de classes d’équivalence d’un caractère » unique » plus exactement à valeur fonctionnelle unique dans un traitement. Pour qu’un module isolant les ponctuations fonctionne de manière identique sur un segment de texte en français et un segment de texte en chinois, il faudra par exemple construire une classe d’équivalence pour chaque type de ponctuation, les points de fin de phrase ou les guillemets, et manipuler cette classe dans l’algorithme.

37En cela, Unicode peut ressembler à une mise bout à bout de codes existants et ne pas répondre complètement aux problèmes de redondances (ou de factorisation) des caractères. Mais à l’usage, on s’aperçoit que les choix conceptuels n’étaient pas si faciles et que le gain dans l’utilisation d’Unicode est substantiel.

3.1 – Unicode et l’exotisme

38L’indexation des contenus, qui se fait en grande partie automatiquement, est une pratique courante et qui désormais n’est plus limitée à une zone culturelle, comme nous l’avons évoqué plus haut. Pour revenir à des situations plus banales que la veille technologique, prenons le cas des annuaires et moteurs de recherche sur internet.

39Dans la mesure où des documents, quelle que soit leur origine, ont été indexés par un moteur de recherche tel que Yahoo ou Google, ils peuvent, à moins d’avoir été supprimés ou déplacés entre-temps, être retrouvés et visualisés. Les problèmes d’affichage ne se posent pas ou pratiquement plus, comme on le sait par expérience. Après une recherche d’information par mots-clés, la consultation des textes réputés pertinents peut dévoiler des documents de langues variées, un premier article en anglais et un autre en chinois par exemple. Bien entendu, la capacité d’utiliser l’original est conditionnée par les connaissances de l’utilisateur. Un utilisateur francophone peut fort bien lire et l’anglais et le chinois… ou se trouver démuni.

40A vrai dire, la même éventuelle frustration existait bien avant Unicode, et peut apparaître à chaque fois que l’on passe par un système d’indexation, qu’il soit automatique ou manuel. Lorsque des indexeurs humains ont répertorié des articles de toutes langues et rendu théoriquement accessibles des ressources très variées, il se peut qu’au terme d’une recherche, après avoir raffiné les descripteurs, on trouve enfin la référence tant attendue sur la mécanique des fluides en milieu fermé interdisques… et que l’on s’aperçoive qu’elle correspond à un article en russe. Déception si on ne lit pas le russe… Il ne reste alors qu’à envisager une traduction.

41La nouveauté induite par l’indexation de documents Unicode et leur signalement réside donc dans le fait que les publics concernés sont de plus en plus larges, non plus quelques spécialistes, mais la majorité des internautes. Plus le standard Unicode se répand et plus la masse des documents disponibles augmente, n’étant plus limitée de facto par le système de codage local.

3.2 – Une information transparente

42Unicode permet de donner à voir des textes, mais aussi de traiter l’information par des moyens informatiques. Le fait d’avoir accès à de l’information synthétisée à partir de nombreuses sources d’origine mondiale est un indiscutable gain de couverture, apprécié par les utilisateurs qui s’intéressent généralement à un domaine particulier. Ils sont satisfaits de ne plus avoir de zones d’ombre, dues aux barrières d’écriture et/ou de langue : les barrières de transmission électronique sont tombées.

43Mais rien ne change en apparence, dans la pratique, car les informations, entrées par exemple dans une base de données, sont normalisées pour correspondre au langage de requête de cette base, puis synthétisées. Elles sont fournies en sortie sous des formes variées, depuis la liste de descripteurs de thésaurus (normalisés) jusqu’aux statistiques, graphiques ou autres modes de représentation, avec des légendes ou commentaires adaptés à l’usage qui en est fait : pour des utilisateurs francophones, par exemple, un système convivial fournit les dénominations d’items et les légendes de schémas en français, mais aussi les menus et les aides en ligne en français. Les données traitées en interne représentent des informations abstraites, détachées de leur origine, et l’information synthétisée est fournie en sortie de façon parfaitement transparente. Cependant, elle doit être présentée dans un format lisible par quelqu’un, appartenant à une communauté culturelle et linguistique, et à un marché potentiel. Ainsi, dans la plupart des cas, Unicode permet cette transformation de données textuelles hétérogènes en information unifiée.

3.3 – Si c’est du chinois, comment évaluer ?

44Un cas particulier d’usage est l’informatique linguistique et plus précisément l’analyse textuelle, que nous aborderons tour à tour du côté des utilisateurs et à nouveau du côté des concepteurs de programmes ou systèmes informatiques. Plusieurs rapports de l’utilisateur au texte original sont possibles. Comme on l’a vu, ce rapport peut être totalement inexistant, l’information étant filtrée puis reformulée sous une forme très synthétique. Mais on souhaite souvent annoter directement le texte d’origine, fonction prévue par de nombreux systèmes d’analyse de l’information, par exemple pour surligner les citations de personnalités dans la presse. On peut aussi prévoir l’accès au texte d’origine pour valider un résultat ou raffiner une recherche. Les pratiques nouvelles d’analyse de l’information sont fondées sur des procédures de plus en plus largement automatisées notamment de résumé automatique. Si l’information apportée par le résumé est intéressante, l’utilisateur demande à consulter le texte original. Il n’y a pas de problèmes pour l’utilisateur, qui consulte les textes qu’il peut lire et comprendre.

45En ce qui concerne les concepteurs, il n’en va pas de même. Le traitement automatique de documents Unicode pose le problème de manipulation d’ensembles de textes multiscripts qui ne sont pas lisibles par ceux qui écrivent les programmes, ou lisibles seulement en partie. L’attitude des étudiants et chercheurs en informatique linguistique oscille entre deux extrêmes que nous pouvons schématiser par l’attitude de repli et l’attitude d’ouverture. Dans le premier cas, on observe un refus net de traiter des textes dans une langue inconnue du programmeur, a fortiori si la graphie lui est inconnue. Si c’est du chinois, alors on ne peut rien faire ! Le programmeur s’estime totalement incompétent, voire lésé s’il ne peut valider lui-même la pertinence ou la qualité sémantique des sorties.

46La seconde attitude, plus fréquente chez les ingénieurs, consiste à considérer qu’une chaîne de caractères n’est jamais qu’une chaîne de caractères, et que les pratiques établies pour un traitement informatique sont applicables sur n’importe quel document électronique. Ils laissent à un utilisateur final le soin de valider les aspects sémantiques, donc de décider si les résultats, qu’ils soient directement lisibles ou non par le programmeur, ont réellement un sens et répondent aux attentes du commanditaire du traitement. Comme cette attitude est plus rare que l’attitude de repli, nous avons souvent l’impression d’être des pionniers en terra incognita. Pouvoir collecter des textes en n’importe quelle graphie, en n’importe quelle langue est une situation très nouvelle et s’attacher à des traitements Unicode paraît encore un défi.

47Il n’empêche que les utilisateurs réclament pour leur part et de plus en plus souvent une couverture dite multilingue. Alors même que ce souci s’affirme, la validation du résultat passe par la confrontation avec l’original, et plus la couverture du système est grande, plus les utilisateurs doivent être nombreux et polyglottes. Les techniques Unicode sont un bon exemple de l’élargissement d’une palette de possibles ; en face d’une offre plus variée, il faut avoir en contrepartie une meilleure capacité à identifier des médiateurs, des traducteurs notamment, pour rendre l’information réellement accessible et significative pour un utilisateur final.