Les validations permettent de relever des problèmes de non-conformité. Ces problèmes sont documentés dans un système de gestion unique – système de gestion des problèmes (noté SGPb), depuis leur détection jusqu’à leur résolution. Ce système inclut une base de données (BD), avec les informations nécessaires au processus de gestion des problèmes : informations sur les acteurs intervenants, et surtout descriptions et commentaires sur les problèmes apparus.

Nous nous sommes intéressés en particulier au référentiel contenant toute la nomenclature de l’entreprise, les composants cités dans le SGPb étant souvent identifiés avec les noms officiels du référentiel.

Une solide analyse du processus des validations est donc indispensable, notamment afin de définir les périmètres techniques et fonctionnels de chacun des acteurs d’entreprise (responsable pièce, service essai, architectes), coopérant au cours des validations, les périmètres représentant les zones de responsabilité, respectivement en termes de pièces et de prestations.

L’hétérogénéité du vocabulaire constitue un problème pour le cogniticien qui ne possède aucune connaissance du domaine, ni le vocabulaire propre à l’entreprise. On peut parler d’un « technolecte », vocabulaire de l’entreprise, et puis d’un « idiotechnolecte », celui qui est propre à l’expert. Mais la variation du vocabulaire d’un service à l’autre est surtout un problème reconnu au sein de l’entreprise même, et elle est à l’origine de nombreux problèmes de communication. Ce vocabulaire peut varier selon le contexte (par le contexte il faut entendre tout ce qui évolue autour de l’activité d’essai). Le vocabulaire peut donc varier en fonction du service d’essai (synthèse, design, montage, responsable pièce, architecte), de l’endroit où il est effectué (plateau, Centre de réalisation des prototypes, usine, service d’essai), de l’objet de l’essai (maquette, prototype, banc d’essai, l’ensemble des prestations), des critères d’essai (prestations fonctionnelles objectives/subjectives, techniques), de l’envergure de l’essai (plateau – sur un prototype ou sur un sous-ensemble des pièces) ou du type de problème.

Une synthèse sur les outils TALN dédiés à l’extraction des termes et relations à partir des textes est proposée dans (Aussenac-Gilles et al., 2000). Il existe plusieurs outils d’extraction des candidats termes : Lexter (Bourigault, 1994), Nomino (http :// www. ling. uqam. ca/ nomino), Ana (Enguehard, 1992). Pour l’acquisition de relations sémantiques, il existe des approches basées sur l’exploitation des contextes syntaxiques (Grefenstette, 1994), ou sur l’utilisation des patrons lexico-syntaxiques (Hearst 1992 ; Jouis 1993) ainsi que quelques outils, Coatis (Garcia 1998) pour des relations causales, Cameleon (Seguela 1999 ; Seguela et Aussenac-Gilles 1999, Seguela 2001) pour des hyponymes et méronymes.

Samovar (Golebiowska, 2000) permet de structurer les connaissances des champs textuels de la base SGPb, et d’y effectuer des recherches afin de trouver des questions similaires. A partir des diverses BDs de l’entreprise, nous avons construit une ontologie offrant plusieurs vues sur le processus des validations : problème, projet, prestations, pièces. Après avoir ainsi amorcé manuellement l’ontologie, nous l’avons complétée progressivement avec les éléments issus des données textuelles de SGPb à l’aide de techniques et outils linguistiques. Cette étape est automatique, mais l’aide de l’expert est nécessaire tout au long du processus. Puis les problèmes de la base SGPb ont été annotés automatiquement avec les concepts de ces ontologies. En utilisant le moteur de recherche Corese intégré dans Samovar, l’utilisateur peut alors accéder à la base des problèmes pour effectuer des recherches guidées par l’ontologie.

La composante Projet contient, entre autres, les références aux différents acteurs comme les responsables pièces ou encore les architectes. Les deux permettent des points de vue correspondant aux découpages possibles des pièces d’un véhicule : point de vue par zone d’architecte et point de vue par zone de responsable pièces. Par exemple, grâce aux références au responsable pièces Planche de Bord il sera possible de connaître les pièces du périmètre Planche de Bord : tableau de bord, console, aérateur, etc.

La composante Prestation reflète un service rendu au client et correspondant à ses attentes. Par exemple, l’aspect ergonomique d’un véhicule : le confort d’un siège, l’acoustique du poste de conduite, les performances d’endurance ou son comportement dans des conditions extrêmes : hautes ou basses températures, fort ensoleillement, etc. Les prestations reflètent, entre autres, l’organisation métier des services d’essai (endurance, bruit, ergonomie, etc.).

Ainsi, les différentes composantes de l’ontologie de Samovar fournissent les points de vus spécifiques pour l’ensemble du processus des validations. Ces points des vue permettent de gérer et d’accéder à l’information de façon sélective, facilitant par là leur exploitation. Ils facilitent aussi l’identification et la détection du vocabulaire propre à chaque métier. Ils améliorent ainsi l’interaction entre les différents acteurs du processus des validations au cours de la gestion d’un problème.

L’« ossature » de l’ontologie est amorcée avec les données des bases existantes (cf. figure 3) :

Une première extraction des données d’origine (2) est effectuée suivant le modèle du domaine. Elle fournit ainsi un sous-ensemble de la base d’origine (3) que l’on traduit ensuite sous forme d’ontologie (4), en respectant le format RDFS (prévu pour Corese).

En parallèle, une autre extraction est faite à partir du référentiel Pièce (5), afin de compléter les données précédentes avec les informations supplémentaires. Une fois l’ontologie construite, elle sert pour annoter les données extraites (3) avec les éléments de l’ontologies (4). On obtient ainsi la base initiale annotée (6).

Un deuxième processus traite les données textuelles (l’objectif final étant d’enrichir le résultat de la première extraction avec l’information issue des textes). Ce processus exploite les sorties obtenues après application de l’outil linguistique Nomino sur les données textuelles issues des commentaires textuels dans la base SGPb. Nomino [1] est un outil d’extraction des groupes nominaux (GN) d’un corpus représentatif d’un domaine. Nomino prend un corpus textuel en entrée et produit en sortie un ensemble de « lexiques » – listes de noms, unités complexes nominales (UCN), unités complexes nominales additionnelles (UCNA), verbes, adjectifs, adverbes. Les UCN(A) correspondent aux groupes prépositionnels (GP) ou groupes nominaux (GN). Les lexiques des UCN(A) sont accessibles sous forme de graphes qui illustrent les dépendances existantes pour un GP ou GN.

Nous utilisons les lexiques et graphes produits par Nomino afin de :

Les termes retenus pour l’amorce sont tous ceux qui sont exploitables en tant qu’indices sémantiques pour un problème : par exemple un problème de Centrage va être détecté grâce à la présence d’indices comme indexage, coaxialité, entraxe, etc. La validité des termes a été confirmée par des experts.

L’amorce de l’ontologie étant ainsi constituée, pour l’enrichir, nous avons utilisé les groupes prépositionnels issus de Nomino.

L’analyse de ces UCN nous a fourni les structures que nous avons exploitées pour construire les règles heuristiques. Ces structures sont composées d’un terme Indicateur de probleme, indiquant l’existence d’un problème (difficulté, effort, impossibilité), suivi par ce problème (chaussage, clipsage). Ainsi on peut trouver des cas comme :

Les règles correspondent donc aux combinatoires possibles entre les éléments des ontologies Pièce et Problème, et attestées dans les textes. Une règle se présente comme une suite de catégories, chacune pouvant être décorée avec un ensemble de traits (par exemple type=Problème pour signifier que l’élément fait partie de l’ontologie Problème, type=Pièce pour un élément de l’ontologie Pièce, etc.).

Prenons comme exemple, la règle heuristique R1. Elle précise que si l’on rencontre l’expression <terme₁> de <terme₂> où <terme₁> est déjà connu comme correspondant à un concept concept₁ de l’ontologie Problème, alors le système peut suggérer de rattacher un concept dénoté par <terme₂> comme un fils de concept₁ dans l’ontologie Problème.

Cette règle appliquée à l’UCN(A) bruit de frottement du volant pendant son reglage en hauteur permettra de proposer un concept « Frottement » comme fils du concept « Bruit » déjà connu de l’ontologie Problème.

Remarque. — une notation différente (accolades et flèche →) permet de distinguer la partie déduction de la règle.

La règle heuristique R2 précise que si le système rencontre l’expression <terme₁> de <terme₂> où <terme₂> est déjà connu comme dénotant un concept concept₂ de l’ontologie Pièce, alors il suggérera de rattacher un concept désigné par <terme₁> comme un concept dans l’ontologie Problème.

Cette règle appliquée au UCN(A) Broutement du bras-balais Ar sur PPP3 permet de découvrir le concept « Broutement », connaissant la pièce « Bras-balai AR ».

La règle heuristique R3 précise que si le système rencontre l’expression <terme₁> de <terme₂> où <terme₁> est soit difficulté soit effort soit dureté, soit risque, alors il suggérera de rattacher un concept désigné par <terme₂> comme un concept dans l’ontologie Problème.

Cette règle appliquée à l’UCN(A) Difficulte d’encliquetage tuyaux carburant sur reservoir permet de découvrir le concept « encliquetage »

Ces trois types de règles reflètent trois façons d’enrichir l’ontologie :

En sortie, on obtient des candidats-problèmes à placer dans l’ontologie Problème. L’utilisateur valide chaque candidat et décide si l’endroit proposé pour l’insérer dans la hiérarchie existante est correct : le terme est alors inséré dans l’ontologie et acquiert le statut de concept.

Pour formaliser l’ontologie, nous avons choisi le langage RDF Schema (RDFS) proposé par le W3C pour décrire l’ontologie à laquelle sont relatives les annotations RDF décrivant des ressources accessibles par le web. Or de telles annotations RDF sont aussi pertinentes pour décrire les ressources faisant partie de la mémoire d’un projet-véhicule, comme les descriptions des problèmes rencontrés dans ce projet.

De ce fait, nous avons développé un parseur qui, à la fin du processus, génère une version de l’ontologie dans RDF Schema. Après la génération de la version RDF(S) de l’ontologie, les annotations des problèmes de la base SGPb sont mises à jour automatiquement.

Comme on peut voir sur la figure 5, la démarche de Corese repose sur la correspondance entre deux formats : RDF(S) et les GC, les RDF Schema étant traduits dans le support de GC et les annotations RDF dans la base des GC. Une requête se présente comme un énoncé RDF, traduit en un graphe requête qui est ensuite projeté sur la base des GC afin d’isoler les graphe s’appariant. Les graphes résultats sont ensuite traduits en retour vers RDF. Le mécanisme de la projection prend en compte les hiérarchies et les relations de spécialisation décrites dans les schémas RDF et traduites en GC.

Pour pouvoir exploiter Corese, nous avons traduit automatiquement l’ontologie de Samovar dans le langage RDFS et annoté automatiquement en RDF les problèmes de la base SGPb avec des concepts de ces ontologies. Après ces 2 étapes, l’utilisateur peut faire des recherches (cf. figure 6) : les réponses aux requêtes prendront en compte les liens modélisés dans l’ontologie de Samovar.

Soit l’extrait de l’ontologie Pièce illustré par la figure 7, et l’ontologie Problème illustré par la figure 8.

Dans le premier exemple, l’utilisateur cherche à retrouver les problèmes de fixation sur le soufflet de levier de vitesse. Une seule réponse est obtenue :

En revanche, en étendant la requête aux termes plus généraux, suivant les liens des ontologies (dans notre cas, Montage), on retrouve un 2^ème cas, et il s’agit bien d’une description-de-problème similaire :

Ainsi par un parcours successif des ontologies dans le sens de la généralisation ou de la spécialisation, l’utilisateur peut étendre la requête aux concepts subsumant et aux concepts « frères ». Dans l’exemple, il peut explorer, niveau par niveau, les problèmes de soufflet de levier de vitesse : partant de Fixation, remonter vers le concept-père (Montage) et redescendre ensuite sur les autres fils (MEP) (cf. figure 7).

Dans le second exemple, l’utilisateur aimerait retrouver les problèmes de centrage sur les traverses de poste de conduite. Le système retourne 3 cas dont 2 s’avèrent être des descriptions-de-problèmes pointant l’une sur l’autre :

Si on n’obtient pas de réponses quant au problème de centrage, il est possible donc d’étendre le résultat aux concepts pères : planche de bord ou montage pour le premier cas, ou géométrie pour le second. Le parcours de l’ontologie permet donc de se déplacer dans l’ensemble de la base, suivant les axes sémantiques modélisés sous forme de liens dans les ontologies, et de retrouver des descriptions-de-problèmes similaires.

De plus, via le lien hypertexte (par exemple Pb_Centrage rdf about=http ://host.renault.fr/SAMOVARXML/MO-00403.xml), l’utilisateur peut accéder au contenu intégral d’un problème, c’est-à-dire au texte d’origine.

Mentionnons que la gestion de synonymes et de termes sémantiquement proches constitue une solution intéressante face au vocabulaire hétérogène, rendant ainsi possible l’exploitation du système par les acteurs de métier ou culture différents.

Les recherches des descriptions-de-problèmes similaires effectuées pour le premier lot démontrent que la démarche est intéressante : les descriptions-de-problèmes ayant des pointeurs réciproques ont toutes été retrouvées (pour tous les cas où les descriptions-de-problèmes pointées par un lien faisaient partie du périmètre couvert – les tests étant effectués pour le périmètre de Planche de Bord, les descriptions-de-problèmes traitées peuvent pointer vers d’autres appartenant au même périmètre ou bien à un périmètre différent). La validité de la démarche a été démontrée ainsi : les utilisateurs courants de la base SGPb marquaient les doublons par un code spécifique dans un des champs de la base d’une part, et d’autre part de façon explicite dans le texte du commentaire. Au cours de nos tests, toutes les descriptions-de-problèmes ayant ce marquage ont été retrouvées. De plus, le nombre de réponses s’en trouve automatiquement réduit. L’exploitation immédiate de la recherche des doublons de validations a fortement intéressé les responsables de projets-véhicule. L’annotation des descriptions-de-problèmes avec les problèmes issus des textes et leur structuration en ontologies que l’on parcourt en cours de généralisation des requêtes, donne donc des résultats intéressants.

On peut constater aussi que la modélisation de l’ontologie est essentielle dans cette démarche. Des modifications dans l’ontologie Problème, faites à titre de tests, ont eu des répercussions plus ou moins heureuses sur les résultats. Il est important de s’assurer de la validité de l’ontologie auprès des experts.

Plus généralement, la démarche est fortement dépendante du corpus du domaine traité : dans le cas de sa réutilisation pour un autre domaine, il sera probablement nécessaire d’actualiser les règles qui permettent d’extraire de nouveaux concepts afin de couvrir les structures non traitées. Les règles sont en effet très liées au domaine.

D’autres « réglages » nécessaires sont apparus au cours du processus. Par exemple les annotations avec des problèmes se font actuellement par appariement – l’annotation avec une étiquette est déclenchée sur la présence d’indices (par exemple Centrage va être détecté grâce à la présence des indices comme indexage, coaxialité, entraxe. Selon l’ordre de déclenchement, une description-de-problèmes peut se trouver annotée avec des termes différents : il serait intéressant d’ordonner leur déclenchement. Par ailleurs, il semble qu’adjoindre d’autres outils TALN (tagger et analyseurs) raffinerait davantage les résultats dans la construction de l’ontologie Problème.

Dans les deux cas, exploiter le modèle conceptuel construit préalablement, afin de restreindre l’extraction à l’information pertinente ;

Samovar peut se comparer à plusieurs approches de construction d’ontologies exploitant des outils TALN à partir de corpus textuels. Terminae (Biébow et Szulman, 1999) propose une méthodologie et un environnement pour la constitution d’une ontologie à partir d’un corpus de textes. La méthode est basée sur l’étude des occurrences des termes dans un corpus afin d’un extraire la définition conceptuelle, et l’environnement aide l’utilisateur dans sa modélisation. Lexiclass (Assadi, 1998) permet de construire une ontologie régionale à partir d’une documentation technique, grâce à un outil classant, en fonction de leur contexte terminologique, les syntagmes extraits du corpus et aidant le cogniticien à découvrir les champs conceptuels importants du domaine. (Aussenac-Gilles et al., 2000) décrivent une méthodologie générale de construction d’ontologies à partir des textes en combinant différents outils TALN existants (i.e., Lexter pour l’extraction des candidats termes, et Cameleon pour l’extraction des relations, Terminae aidant à la construction de la hiérarchie). Notre démarche s’en rapproche : nous utilisons aussi différents outils spécifiques à chaque étape du processus, mais avec un corpus d’origines diverses (des interviews et des données textuelles issues des BDs existantes). (Maedche et Staab, 2000) proposent aussi une architecture générale pour la construction d’une ontologie à partir des textes : ils exploitent (a) différents outils TALN pour construire une taxonomie de concepts et (b) des techniques d’apprentissage pour extraire d’autres relations des textes. Enfin, notons que Samovar permet la recherche des problèmes similaires comme un système de raisonnement à partir de cas (Moussavi, 1999).