Soutenance mémoire
Évaluation des SDS
L’évaluation des SDS comme pour beaucoup de systèmes complexes est une tâche extrêmement difficile. En effet la nature même des ces systèmes nous empêche d’en avoir une vision complète. Le nombre de paramètres intervenant dans leur comportement est trop important et les liens de causalité entre ces paramètres et le système sont peu, mal ou pas connus. Nous ne possédons que quelques outils permettant de révéler certaines dimensions du système, qui nous le montrent sous un certain angle. Ils agissent de la même façon que si l’on voulait se représenter un objet à n dimensions sur une feuille de papier. Ces outils de mesure aplatissent, déforment le système réel et produisent dans le cas des SDS des fichiers de consignation des interactions, des transcriptions de dialogues, des questionnaires de satisfaction, des données physiométriques des l’utilisateur,…
Mais ces mesures n’ont aucune valeur intrinsèque, c’est notre interprétation qui leur donne une signification et une importance. Cela dit cette valeur ne devient pas beaucoup plus grande étant donné qu’il est souvent impossible d’interpréter pertinemment directement les données brutes récoltées. Une étape supplémentaire de traitement de ces données est donc nécessaire pour les enrichir et les rendre exploitables. Dans le cas des SDS, ces traitements se réduisent souvent en pratique à des moyennes ou des calculs de pourcentages bien qu’il soit difficile ou coûteux de les calculer. Par exemple le « Nombre de demandes d’aide émanant de l’utilisateur », le « pourcentage des énoncés du système qui sont considérés comme étant pertinents dans le contexte immédiat du dialogue » [6].
On voit bien que certains traitements peuvent nécessiter l’intervention d’un humain et peuvent devenir longs et coûteux.
Les nouvelles structures résultant de ces traitements sont nommées Key Performance Indicator (KPI) en anglais, terme que nous utiliserons par la suite. Les KPI sont alors la brique de base pour la construction d’un point de vue du système et la prise de décision.
Cette construction est donc un deuxième traitement des données brutes de départ. Laurent et al. [9] résument ce processus à trois étages à travers la figure 2 page 9.
Ce processus permet donc de créer une vision (parmi d’autres) du système qui ne retient que certains éléments, considérés comme donnant des informations pertinentes sur l’objectif recherché.
Le travail de l’évaluateur consiste à parcourir ces trois niveaux dans un sens puis dans l’autre. Il commence par définir les objectifs de l’évaluation (tels que « Est-ce que le SDS est rentable ? » ou « Est-ce que le système est capable de corriger les erreursde compréhension ? ») qui orienteront la décision à prendre. Ces objectifs sont ensuite traduits en une série de qualités que le système doit posséder auxquelles l’évaluateur associe des KPI à calculer. Ceux-ci sont choisis en fonction de l’information qu’ils peuvent apporter sur ces qualités. Ils impliquent alors l’extraction des certains paramètres « de niveau 1 ». Grâce à cette analyse stratégique, l’évaluateur a traversé les trois niveaux en commençant par le plus haut. L’étape suivante consiste alors à mettre en application cette stratégie, c’est-à-dire remonter les trois niveaux comme nous l’avons vu. Ce parcours en « V » est schématisé sur la figure 3 page 10.
Approche de la recherche
Du côté de la recherche plusieurs nouvelles métriques ou méthodologies d’évaluation ont vu le jour. Certaines comme SERVQUAL, WOZ Gold Standard [12] ou SASSI [5] ce concentrent sur la recherche d’une métrique plus fiable de la qualité perçue par les utilisateurs. Alors que l’approche de PARADISE [16] essaie de trouver le lien entre certains KPI (indicateur κ, voir Figure 17 page 39 en Annexe) et la satisfaction des utilisateurs. PARADISE peut servir alors de support de comparaison entre différents systèmes, ou àprévoir la satisfaction utilisateur en fonction des indicateurs fournis par le système, ou encore à discerner les KPI du système plus indicatifs de la qualité globale. Sur ce dernier point, T. Paek [12] pointe certaines limites. Lorsqu’un système PARADISE est entraîné sur plusieurs SDS puis testé sur d’autres, le résultat indique que les paramètres ayant le plus d’influence sur la satisfaction des utiliasteurs sont liés à la reconnaissance vocale alors que les utilisateurs utilisent d’autres arguments pour justifier leur jugement. On voit donc que le système de PARADISE est limité quant à la comparaison de différents systèmes.
Approche de l’industrie
L’industrie tente une approche différente, plus pragmatique, dans la mesure où, consciente des limites techniques, l’effort n’est pas concentré sur le dépassement de ces limites comme pour la recherche mais sur l’optimisation des performances (ou autres critères comme le coût) compte tenu des limitations techniques.
Cette approche plus pragmatique s’applique dans le domaine de l’évaluation par une technique plus artisanale qu’on appelle de « best-practice » et qui se traduit par des recommendations, une liste de pratiques à faire ou à éviter. Le développement des applications se fait par des essais répétés jusqu’à percevoir une amélioration et la qualité des systèmes est évaluée souvent plus par l’épreuve du temps. Ces « best-practices » se sont traduites avec le temps en diverses ressources, livres, articles, séminaires sur les meilleures façon de concevoir et déployer un SDS. C’est une approche basée beaucoup sur l’expérience qui, si elle peut être justifiable, doit être validée et replacée dans son contexte (e.g. domaine d’application et population d’utilisateurs) [12].
Alors que la recherche essaie d’atteindre une grande liberté de communication et une interaction la plus naturelle possible, plus de liberté ne signifie pas toujours une meilleure satisfaction des utilisateurs, compte tenu de la technologie actuelle. En particulier si la tâche est bien connue des utilisateurs, comme la réservation d’un billet de train : l’utilisateur sait qu’il faudra renseigner la date, la ville de départ et d’arrivée, d’éventuelles cartes de réduction, etc… Dans ces cas la restriction des libertés d’expression de l’utilisateur en choisissant un modèle d’interaction très contrôlé n’influence pas négativement l’utilisabilité et permet d’éviter des erreurs potentiellement plus fréquentes dans un modèle plus libre ([13]).
Une volonté de convergence
Si de nombreux articles remarquent ces divergences entre recherche et industrie, tous s’accordent aussi sur la nécessité d’une convergence, d’un langage commun concernant l’évaluation. Des systèmes d’évaluation tels que PARADISE, SERVQUAL et autres peuvent être utiles à l’industrie car le problème de commensurabilité est aussi un problème pour l’industrie. En effet les « best practices » utilisées par l’industrie doivent être validées. À l’inverse, si l’industrie des SDS a établi un certain nombre de « bestpractices » afin d’améliorer la qualité des systèmes, elle est assurée de l’optimalité de sa conception. Ainsi la recherche devrait de son côté se concentrer non seulement sur les performances relatives des systèmes mais également sur la question de comment améliorer les SDS [12].
Répondant à cette volonté de convergence et de connaissances partagées, l’UIT-T regroupe dans [6] un ensemble de KPI parmi les plus utilisés, en les groupant par catégories :
– paramètres liés au dialogue et à la communication
– paramètres liés à la métacommunication
– paramètres liés à la coopérativité
– paramètres liés à l’entrée vocale
Cette approche est en fait une taxonomie non exhaustive de points de vue possibles que l’on peut avoir sur un système. Un problème majeur reste donc même s’il est aidé par les approches vues précédemment : comment d’une part construire une vision du système qui rende compte des éléments nécessaires afin de prendre une décision ? Et comment d’autre part arriver à comparer ces multiples points de vue construits ?
C’est à ces questions que la thèse de Marianne Laurent apporte des éléments de réponse. Dans [9] par exemple Laurent et al. proposent une grille de lecture d’aide aux évaluateurs au cours des différentes phases de conception d’un SDS. Celle-ci permet de prendre en compte la subjectivité émanant de différentes communautés de pratiques et communautés d’intérêts, le point de vue des différents intervenants au cours du développement d’un tel système tels que les propriétaires du projet, les développeurs, les ergonomistes, les employés au marketing, les clients et les utilisateurs finaux. Il s’agit d’un squelette de réflexion à partir duquel construire une évaluation. Cet effort de rationalisation a abouti sur une plateforme implémentant cette grille de lecture (MPOWERS [8]).
Ici il ne s’agit plus de nouvelles métriques d’évaluation ni vraiment de « best-practices » mais plutôt d’une volonté de rationaliser l’évaluation, de mieux comprendre la procédure de conception d’une évaluation et de donner une structure globale et partagée entre tous les acteurs dans un projet de SDS. Nous comprenons alors qu’au-dessus de la taxonomisation et de la standardisation il est nécessaire de dessiner un cadre rationel global qui tiendrait lieu de langage commun.
Des mots au langage
Le panorama de l’évaluation aujourd’hui ressemble à une tour de Babel qui tente de trouver un langage commun. Certains mots sont utilisés de plus en plus (PARADISE, SASSI, SERVQUAL, WOZ Gold Standard,…). L’UIT-T tente de son côté d’organiser les connaissances en rassemblant et classifiant les KPI plus utilisés.
Suite à ces travaux, ce qui semble manquer n’est plus les mots mais une grammaire au langage commun, qui puisse poser les règles de base pour la construction de phrases à partir des mots ou même de mots à partir de phonèmes. C’est-à-dire une formalisation qui définisse le passage entre les trois niveaux vus précédemment : la création de KPI à partir des données brutes et la création de points de vue à partir des KPI. En effet le problème n’est pas seulement de chercher de nouvelles métriques ou méthodologies mais d’être capable de les comprendre, de comprendre les liens entre elles et comment ellespeuvent être construites.
Les résultats que nous avons abordés au cours de cet état de l’art témoignent d’une approche réductionniste au sens premier (en supprimant le caractère péjoratif qu’il a acquis de nos jours). C’est-à-dire basée sur l’hypothèse qu’un système peut être décrit et compris par l’analyse des éléments ou parties élémentaires le constituant. À partir de l’analyse de ces éléments, on effectue alors un travail inverse de reconstruction du système.
C’est ce qui se passe lorsque l’évaluateur conçoit une évaluation (figure en « V »).
Le travail de recherche d’une formalisation se dirige dans une direction opposée à savoir qu’au lieu de se concentrer sur des sous-éléments du système de départ on plonge le système dans une structure d’ordre supérieur, un espace de formes qui laisse une expressivité assez grande au système pour pouvoir construire des points de vue, des caractérisations, des évaluations dont les propriétés et les relations réciproques apparaissent plus clairement.
Nous avons commencé notre réflexion à partir de deux questions importantes qui apparaissent au début de ce rapport : « Comment d’une part construire une vision du système qui rende compte des éléments nécessaires afin de prendre une décision ? Et comment d’autre part arriver a comparer ces multiples points de vue construits ? ». La première question met en évidence le fait qu’une évaluation se base avant tout sur une représentation a priori d’un système. Ce peut être une vision très complète et superficielle ou au contraire très spécifique et approfondie, mais dans tous les cas, l’évaluation ne peut être déconnectée de la façon dont on se représente l’objet à évaluer. La deuxième question s’intéresse quant à elle plutôt à la description des points de vue et donc à l’évaluation à proprement parler. Elle touche aux notions, que nous laissons volontairement vagues dans cette introduction, de « point de vue », « contexte d’évaluation ». Nous allons donc dans la suite apporter des éléments de réponse à ces deux points.
Une représentation formelle du dialogue
La première étape de mon travail a été de comprendre et décrire l’objet d’évaluation. Dans notre cas cet objet est le dialogue entre l’utilisateur et le système, l’output final du dialogueur automatique et non le système lui-même. En effet c’est justement notre incapacité à comprendre le système en tant que tel qui nous pousse à analyser son comportement, plus facile à comprendre et évaluer, afin d’en déduire par la suite ses propriétés, ses défauts, ses atouts. Mon travail s’est donc d’abord concentré sur une recherche d’une description, d’une représentation formelle d’un dialogue homme-machine et non d’un dialogueur automatique, d’une représentation du comportement du système et non du système en tant que tel.
La structure générale d’un système de représentation que nous avons choisi d’adopter est celle d’un langage formel constitué d’un alphabet de départ et d’un ensemble d’opérateurs sur cet alphabet qui permettent de l’enrichir. Les éléments de cet alphabet représenteraient une valuation, un jugement ou la mesure d’une propriété élémentaire du dialogue homme-machine. Avant de vous exposer l’alphabet que nous avons choisi, réfléchissons aux qualités qu’une telle représentation doit avoir. Idéalement, elle doit être capable d’exprimer n’importe quelle caractéristique, propriété, dimension du dialogue et ce avec une précision aussi fine ou grossière que désiré. Autrement dit elle doit être flexible à la fois d’un point de vue qualitatif (possibilité d’expression de n’importe quelle propriété du dialogue) et d’un point de vue quantitatif (précision de la mesure d’une propriété).
L’alphabet de base doit être partageable et compréhensible facilement entre évaluateurs et doit donc rester le plus proche possible de la perception première, directe que l’on a du dialogue.
Cette perception première du dialogue nous est fournie par une multitude de mesures sur un ou plusieurs dialogues qui prennent la forme tantôt de fichiers de log (signalant l’heure de début et fin d’un dialogue par exemple), tantôt de transcriptions, d’annotations d’experts ou de questionnaires d’utilisateurs. Cet ensemble fournit une certaine quantité de données, très hétérogène, décrivant différents aspects d’un dialogue. C’est à partir de là que pourront alors se créer des interprétations, des jugements, des points de vue sur les dialogues et donc une évaluation du système. En nous basant sur ces mesures, nous allons créer un système de représentation des propriétés d’un ou plusieurs dialogues.
L’idée sous-jacente à la représentation que nous allons proposer est la suivante : un corpus de dialogues est une suite ordonnée et finie d’échantillons temporels auxquels on associe la présence ou non d’une propriété. Nous allons dans un premier temps, dans un souci de clarté, considérer que ces échantillons temporels sont de durée égale et correspondent à un temps très court, le temps d’échantillonnage de la parole ou la milliseconde par exemple. Ceci est important pour que même des propriétés très spécifiques, qui s’appliquent à des temps très courts puissent être exprimées. L’ensemble est fini car il commence au début du premier dialogue par exemple et se termine à la fin du dialogue, ou à la fin d’un certain nombre de dialogues ou d’un temps prédéterminé. À l’aide de cette idée de base on peut imaginer un grand nombre de « lettres » de l’alphabet, à commencer par « l’utilisateur parle ». À chaque échantillon temporel correspond une valeur booléenne qui indique la présence ou non de la propriété « l’utilisateur parle ».
La figure 5, page 15 montre une façon de représenter une telle « lettre ». Ces lettres permettent donc de représenter de manière unique toute mesure effectuée sur le système, que cette mesure vienne d’un fichier de log, d’un questionnaire de satisfaction ou autre.
Opérateurs
Ce mode de représentation permet en théorie de représenter n’importe quelle propriété associée à un échantillon temporel. Même des propriétés plus élaborées comme « le système comprend le concept énoncé par l’utilisateur » peuvent être représentées comme des éléments de F . Seulement une telle fonction, sous cette forme, est hermétique car elle ne donne aucune information sur ce qu’elle représente exactement. En reprenant l’exemple « le système comprend le concept énoncé par l’utilisateur », nous ne pouvons pas savoir par exemple ce qu’est un concept précisement ou sous quelles conditions un concept énoncé par l’utilisateur sera considéré comme compris par le système. Le sens de la propriété doit être clair et partagé. Or il est d’autant plus difficile de se mettre d’accord sur le sens d’une propriété lorsque celle-ci est sujette à de multiple interprétations. Ainsi si « l’utilisateur parle » est relativement consensuelle, « le système comprend le concept énoncé par l’utilisateur » l’est déjà beaucoup moins.
Nous allons dans la suite apporter des éléments de réponse à ce problème. Nous allons partir de l’hypothèse que les fonctions de F élaborées sont composées en réalité d’une multitude de fonctions très simples qui sont agglomérées à l’aide d’opérateurs.
Prenons un exemple. Supposons que l’on veuille calculer le taux de silence dans le dialogue. On pourrait introduire une fonction « silence » qui indique à chaque milliseconde si quelqu’un parle ou non. Cependant on remarque que cette fonction peut être aisément calculée à partir des fonctions « l’utilisateur parle » et « le système parle ». Introduisons donc deux opérateurs sur les éléments de F qui permettront de calculer cette fonction« silence ».
Soit il repère lui-même les mots bien reconnus en écoutant l’enregistrement des dialogues et en regardant les logs du système. Auquel cas, il introduit lui-même une nouvelle mesure et donc une propriété que l’on pourrait appeler « est un mot correctement reconnu par le système ». Cette nouvelle propriété est alors hermétique puisque l’on ne sait pas comment elle a été construite (sans compter les erreurs potentielles commises) et l’évaluateur devra alors convaincre les autres parties prenantes de la validité de sa mesure pour l’intégrer dans l’ensemble des propriétés de base.
Soit l’évaluateur crée la fonction « est un mot correctement reconnu par le système » à partir des propriétés de base disponibles : P F i∈J1;nombre_de_motsK (U · Emi · Rmi ) + . Cette fonction vaudra alors 1 à chaque fois qu’un mot est reconnu, il n’y a qu’à compter le nombre de « 1 » dans la fonction pour obtenir le nombre de mots correctement reconnus.
Mais contrairement au choix précédent, cette fonction laisse transparaître, à l’aide de saformule, sa construction de façon précise et non ambigue.
À ce stade, nous pouvons exprimer n’importe quelle propriété du dialogue à l’aide des éléments de F mais nous sommes désormais capables aussi d’exprimer une partie du sens attaché aux éléments de F plus élaborés. En effet, à l’aide d’un ensemble d’éléments de F simples et d’opérateurs, nous pouvons exhiber une méthode de construction ou un arbre de construction d’un élément de F plus élaboré. C’est cet arbre de construction ou cette formule qui est capable d’exprimer une partie du sens de la fonction élaborée de façon non ambigue. De plus cette approche permet également de réduire l’alphabet de départ qui doit être partagé entre toutes les parties. Cependant remarquons que ceci n’engage aucune unicité dans la construction et il se peut que l’on arrive à une même fonction à partir d’arbres de construction différents. Nous avons donc un système extensif puisqu’il permet d’exprimer toute propriété d’un dialogue et discernable car deux propriétés différentes auront une représentation différente.
Échantillons temporels de taille variable
Mais cet exemple nous laisse entrevoir dès à présent également un problème que nous allons traiter dans la suite. En effet les fonctions Emi ou Rmi représentent des propriétés sur les mots mais nous les représentons comme des propriétés associées à chaque milliseconde. Cela n’est pas dérangeant dans la mesure où un mot est constitué d’un certain nombre de millisecondes mais complique et allonge les calculs notamment en nous obligeant à utiliser l’opérateur « + » dans l’exemple précédent, dont on pourrait se passer. Nous aimerions donc trouver un moyen d’exprimer de façon minimale une propriété sur
des entités plus grandes que la milliseconde, que ce soit un mot, une phrase ou un dialogue en entier. C’est-à-dire pouvoir définir différents ensembles E et donc différentes fonctions.
Néanmoins, il ne faut pas que cela nous limite dans l’utilisation des opérateurs et nous aimerions que deux fonctions sur deux ensembles E 1 et E 2 différents continuent à être compatibles. Pour cela nous allons mettre en évidence certaines structures mathématiques connues présentes dans notre formalisme et nous montrerons comment elles permettent d’exprimer des propriétés de façon plus simple et minimale sur des entités plus grandes que la milliseconde.
Indicateurs d’ordre supérieur
Nous avons vu jusqu’à présent comment représenter un dialogue homme-machine, ses propriétés. Cette représentation constitue la base d’une évaluation. Elle se construit à partir d’un ensemble d’éléments de F qui doivent être compris, acceptés et partagés. Nous pouvons également définir des propriétés plus élaborées grâce aux opérateurs et aux projections. Mais nous ne sommes pas encore capables d’exprimer un jugement plus compliqué sur un corpus de dialogues. Un jugement qui par exemple tient compte de multiples propriétés en les hiérarchisant, en les pondérants. C’est ce que nous allons voir dans cette nouvelle section. Comment exprimer clairement un jugement sur le dialogue à partir de cette représentation formelle dans F .
Une évaluation ne peut être déconnectée d’un objectif, c’est-à-dire un aspect du système sur lequel on doit porter un jugement. « Le système est-il ergonomique ? » ou « Le taux de fautes de reconnaissance est-il assez bas pour une réussite des tâches de 90% ? » par exemple. L’évaluation va alors permettre de répondre de façon quantifiée à ces questions. Ce peut être une réponse binaire oui/non ou plus fine, en fournissant une note au système relativement à l’objectif considéré. Ces notes sont appelées dans la littérature Key Performance Indicator (KPI). Elle sont souvent définies en langage naturel ou par une formule mais sont le plus souvent difficilement partageables car elle sont construites pour un système en particulier et font appel à des notions ambigues.
Notre objectif désormais est d’arriver à exprimer ces KPI à l’aide du système de représentation que nous avons vu. Il faut donc réussir à passer de l’espace de description F à un espace tel que R car il doit être capable d’exprimer des quantités, des notes. Pour cela nous allons tout d’abord introduire une norme sur F , donc une fonction de F vers R +qui permettra d’effectuer le premier pas vers la construction d’un KPI.
Application du système formel
Afin de vérifier que ce système de description peut bien représenter n’importe quel KPI, nous l’avons appliqué à deux corpus de KPI : celui proposé par l’UIT-T dans [6] ainsi que le corpus des KPI (95 KPI) utilisés par les parties prenantes aux projets SDS chez Orange Labs. Ces derniers ont été obtenus par Diane Cros lors d’une étude commanditée par le laboratoire NADIA d’Orange. Nous avons donc représenté chaque KPI de ces corpus comme un nombre réel construit à partir de vecteurs de F .
Pour ces corpus, nous avons considéré que les KPI étaient calculés à partir d’un corpus de dialogues. La colonne « Vecteurs » introduit les vecteurs de F nécessaires pour la construction du KPI en question et les deux dernières colonnes expriment la construction du KPI dans F puis dans R. Seuls les KPI les plus représentatifs tirés de [7] sont reportés sur le tableau 3 page 23. Il s’agit de KPI représentatifs des différents types de constructions que l’on peut rencontrer. Il n’est pas utile de tous les représenter car tels qu’ils sont décrits dans [7], leur construction dépend des vecteurs de base disponibles, c’est-à-dire du système considéré et des données disponibles sur ce système. Ainsi la représentation de ces KPI n’est pas unique. Pour les KPI représentés dans le tableau 3, nous avons choisi arbitrairement certains vecteurs de base plausibles pour leur construction.
|
Table des matières
1 Présentation des SDS
1.1 Définition et contextualisation
1.2 Structure d’un SDS
2 L’évolution des IHM et de leur évaluation
2.1 Évolution des IHM
2.2 Difficultés engendrées
3 Évaluation des SDS
3.1 Approche de la recherche
3.2 Approche de l’industrie
3.3 Une volonté de convergence
3.4 Des mots au langage
4 Une représentation formelle du dialogue
4.1 Opérateurs
4.2 Échantillons temporels de taille variable
4.2.1 Sous-espace vectoriel associé à un vecteur
4.2.2 Produit scalaire et projecteur
4.3 Indicateurs d’ordre supérieur
4.4 Application du système formel
4.5 Observations et limites du système formel
5 Comparaison de KPI
5.1 Comparaison d’arbres de construction
5.2 Définition d’une hiérarchie
5.3 Mesures de similitude entre vecteurs
6 Caractérisation des CdP
6.1 Étude syntaxique des KPI utilisés chez Orange Labs
6.2 Caractérisation ensembliste des CdP
6.3 Niveau hiérarchique associé à un KPI
6.4 Signature d’une CdP
6.5 Distance entre un KPI et une CdP
Références
Table des figures
1 Structure séquentielle d’un SDS de type téléphonique [7]
2 Une définition de l’évaluation sur 3 niveaux [9]
3 Processus de conception d’une évaluation [9]
4 Relation entre Flexibilité de l’interaction et utilisabilité [14]
5 Exemple d’une fonction de F
6 Construction de la fonction « silence »
7 Opérateur dérivée « fronts montants » f +
8 Opérateur e k (f )
9 Exemple de projection d’un vecteur a sur G f
10 Représentation de p f
(a) dans la base (d i ) i∈J1,nK de F (en haut) et dans la base (e i (f ))i∈J1,ordre(f )Kde G (en bas)
11 Représentation d’un KPI mesurant l’efficacité d’un système sous forme d’arbre (les noeuds entourés d’un rectangle sont des réels tandis que ceux entourés d’une ellipse sont des éléments de F )
12 Représentation de l’arbre de construction de deux KPI – Les constructions dans F et dans R sont mises en évidence
13 Exemple de dialogue entre un utilisateur et un SDS donnant les informations sur les horaires de bus à Brest
14 analyse syntaxique d’un KPI
15 analyse syntaxique d’un KPI
16 Calcul de l’acceptation d’un nouveau KPI calculant l’efficacité, parmi les CdP d’Orange Labs
17 Paramètres liés aux tâches
Liste des tableaux
1 Opérateurs sur les éléments de F
2 Liste d’opérateurs sur les éléments de F
3 Dialogue- and communication-related interaction parameters
4 Distribution des niveaux hiérarchiques au sein des CdP d’Orange Labs
