Étatdeslieuxdelacollaboration...

Première partie

État des lieux de la collaborationdans un contexte centré Produit

15

Introduction

Dans cette première partie nous souhaitons présenter un état de l'art dans les do-maines de recherche concernés par notre problématique. Elle se décompose en troischapitres :

Le premier chapitre a pour objectif de présenter une analyse ayant trait aux spé-ci�cités des SIP : leurs évolutions, leurs caractéristiques fonctionnelles, les modèles quiles régissent - dits PPO, ainsi que les méthodes de conception. En�n, nous abordons lesnotions d'intégration des SIP et quelques architectures dédiées à l'intégration ; en e�etces questions se posent dès lors qu'on se retrouve dans un contexte d'entreprise étendue.

Le deuxième chapitre passe en revue la collaboration et les processus collaboratifs.Dans un premièr temps, sont présentés les principaux concepts liés à la collaborationainsi que les di�érentes formes des pratiques collaboratives. Dans un second temps nousabordons les processus collaboratifs dans un contexte de système d'information, ainsique les di�érentes méthodes de modélisation.

En�n le troisième chapitre est consacré à la notion de pilotage et de performancedans l'entreprise industrielle. Nous exposons les di�érents concepts d'évaluation des per-formances et d'élaboration des systèmes d'indicateurs de performance ; ensuite, nousdétaillons les techniques d'évaluation qualitative de la performance. Ce chapitre faitégalement l'objet d'une présentation des modèles d'observation pour le suivi des acti-vités menées au sein du SIP. En e�et, ces systèmes sont dotés de grandes capacités detraçabilité, et o�rent plusieurs sources d'observation pour e�ectuer un suivi des activités.

17

Introduction

18

1

Systèmes d'information centrés surle cycle de vie du Produit

Sommaire1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 191.2 Les systèmes d'information orientés Produit . . . . . . . 20

1.2.1 Évolution du SI des entreprises industrielles . . . . . . . . 201.2.2 Autour du SI Produit . . . . . . . . . . . . . . . . . . . . . 25

1.3 La gestion du cycle de vie produit - PLM . . . . . . . . 291.3.1 Le PLM : concepts, état des lieux, périmètre . . . . . . . . 291.3.2 Les modèles Produit, Processus, Organisation . . . . . . . 32

1.4 Les architectures d'intégration au sein du Système In-formatique . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

1.4.1 Le besoin d'intégration . . . . . . . . . . . . . . . . . . . . 351.4.2 Les architectures d'intégration . . . . . . . . . . . . . . . . 38

1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

1.1 Introduction

Le besoin fondamental d'une entreprise est de développer ses marchés en accrois-sant ses marges a�n de garder une rentabilité su�sante pour assurer sa survie et sondéveloppement. Selon Marc Prido [Sys03], ce désir fait appel à des besoins simples maisgénérateurs de motivations et de gains :

� répondre aux demandes de ses clients,� proposer des coûts attractifs répondant à ces demandes,� o�rir des services qualitatifs de �délisation nécessaires à sa pérennité.

Dans ce contexte, le système d'information - SI - est devenu, au �l des ans, une despréoccupations majeures des entreprises. Parmi toutes les démarches d'amélioration dela compétitivité qui ont été explorées, la rationalisation du SI est loin d'avoir été com-plètement exploitée ; cet enjeu mobilise de plus en plus les entreprises produisant desbiens manufacturiers. De nombreux besoins sont à l'origine de cette démarche :

19

Chapitre 1. Systèmes d'information centrés sur le cycle de vie du Produit

� L'accroissement des besoins de communication en interne avec tous les acteurs del'entreprise.

� L'accroissement des besoins de collaboration avec les di�érents partenaires (clients,fournisseurs, donneurs d'ordre, etc.).

� La réduction des coûts et des délais de développement des produits.

Il est donc essentiel de posséder un SI e�cace et robuste : l'e�cacité pour répondre par-faitement aux besoins de l'entreprise, la robustesse pour garantir cette e�cacité malgréun environnement instable.

L'objectif de ce chapitre est de présenter un état de l'art sur les Systèmes d'Informa-tion Produit (SIP). Dans une première étape, nous décrivons le processus d'évolution desSI, leurs méthodes de conception, ainsi que les spéci�cités qui ont favorisé l'apparitiondes SIP. Puis dans une deuxième étape, nous présentons les principaux concepts qui vontpermettre de caractériser un SIP a�n de mettre en évidence son rôle dans le dévelop-pement des produits. Nous aborderons également les di�érents travaux de modélisationautour des trois composantes du SIP : le produit, le processus et l'organisation. En�n,nous présenterons un ensemble d'architectures dédiées à l'intégration des SIP ; en e�etdes questions d'intégration se posent généralement dès lors qu'on se retrouve dans uncontexte d'entreprises multi-sites, ou multi-partenaires.

1.2 Les systèmes d'information orientés Produit

1.2.1 Évolution du SI des entreprises industrielles

Contexte et positionnement

Avant d'analyser l'évolution du SI ainsi que les spéci�cités qui ont favorisé l'ap-parition du concept des SIP, il convient de préciser cette notion, à travers quelquesdé�nitions.

Avec l'approche systémique, Le Moigne [Moi90] pose les fondements des SI actuelsen s'appuyant sur une théorisation de la notion de système. Classiquement, le systèmeest un ensemble de ressources interdépendantes transformant des éléments entrants,et organisé en vue d'atteindre un objectif. L'objectif de toute "approche système" estde décomposer le système en des composants simples pour réduire sa complexité, puisd'aboutir à sa modélisation a�n de pouvoir agir sur lui : la décomposition permet de com-prendre sa con�guration et sa structure dynamique (ensemble des �ux). Dans l'approchesystémique, l'entreprise en tant que système est dé�nie à l'aide de trois composantes :

� Le système opérationnel (ou opérant) active les processus et procédures chargésde transformer les entrées (matières, composant, etc.) en sorties sous des formestrès variées (produit, sous-produit, composant, etc.).

� Le système de pilotage coordonne l'ensemble des activités des sous-systèmes et �xeles objectifs stratégiques.

� Le système d'information est le centre nerveux par lequel transitent les �ux d'infor-mation. Il gère et stocke les di�érentes événements et transformations caractérisantles deux autres sous-systèmes.

20

1.2. Les systèmes d'information orientés Produit

Ainsi, le SI est vu comme l'articulation des systèmes de pilotage et opérant [Bri00]. Ilest donc un sous-système de l'entreprise. La démarche systémique demeure un fonde-ment qui est particulièrement adaptée à l'entreprise manufacturière qui peut être vuesimplement comme un système qui transforme des matières premières en produit, enutilisant des ressources matérielles, �nancières et humaines. Elle permet de traiter lesystème dans sa globalité notamment grâce à une décomposition descendante qui meten évidence les éléments caractéristiques ainsi que les relations entre éléments. Grâceà ces décompositions rigoureuses, il devient possible de mettre en ÷uvre une démarched'optimisation dans la mesure où les éléments ne sont pas trop complexes.

Les di�érentes dé�nitions des systèmes d'information mettent simplement en évi-dence la di�érence de point de vue entre l'informaticien, le gestionnaire, l'économiste,ou l'ingénieur.

Un SI est un réseau complexe de relations structurées où interviennent hommes,machines et procédures, qui a pour but d'engendrer des �ux ordonnés d'informationspertinentes provenant de di�érentes sources et destinées à servir de base aux décisions[ANG02].

Pour Rolland [RFB88], le SI d'une organisation est dé�ni par un ensemble constitué :� de collections de données qui donnent des représentations partielles de la réalité

d'une organisation sur lesquelles on souhaite être renseigné ;� de collections de règles qui �xent le fonctionnement de l'organisation ;� d'un ensemble de procédés qui assurent le stockage, la recherche, la communication

et la restitution des informations ;� d'un ensemble de ressources humaines et de moyens techniques.Reix [Rei98] dé�nit le SI comme � un ensemble organisé de ressources : matériel ,

personnel, données, procédures permettant d'acquérir, de traiter, de stocker, de commu-niquer des informations dans les organisations �. Ces dé�nitions positionnent le SI commeun instrument de communication entre les acteurs d'une organisation. Dans [CRS01], lesauteurs assimilent le SI à un outil de gestion et donc à un moyen de formaliser l'actionorganisée : � Si l'on considère, de manière très large, un outil de gestion comme � toutdispositif formalisé permettant l'action organisée �, alors nous pouvons dire que SI etoutils de gestion se recouvrent en grande partie �.

L'usage des systèmes d'information dans l'entreprise est devenu une réalité quoti-dienne. La gestion des SI et leur conception représentent donc aujourd'hui un problèmemajeur des organisations [RF90]. Le domaine des systèmes d'information a certes uneforte composante technologique et informatique. Mais c'est seulement un aspect de cedomaine qui est en fait beaucoup plus vaste. Il s'agit de concevoir la façon dont circule etest stockée l'information de manière e�cace et cohérente pour toutes les activités d'uneentreprise ou d'un réseau d'entreprises.

La conception du SI

Les SI s'imposent actuellement comme un élément stratégique pour les entreprises.L'évolution actuelle vers une intégration totale de l'ensemble des processus exige, demanière symétrique, la conception de SI intégrés, visant à reproduire le plus �dèlementpossible cette évolution. Cela implique la maîtrise d'une information très détaillée, dense

21


et hautement intégrée, nécessitant une conception adaptée et de grandes ressources d'in-formatique de gestion. Selon Rolland et al. � dans le processus de développement du SI,objet complexe, la conception est la tâche la plus créative mais aussi la plus di�cile �[RFB88] [Thi76] [Thi85a].

Au cours de cette conception, un grand nombre de décisions est à prendre. Elles sontrelatives aux choix :

� des fonctions que le SI doit assurer ;� des technologies et instruments de traitement, de communication et de di�usion

de l'information ;� des règles de mémorisation, de traitement, de communication et de di�usion des

informations produites et des documents ;� des structures de travail et des comportements attendus des agents ;� etc.Aujourd'hui, l'évolution des techniques et la variété de choix qu'elles créent per-

mettent de se libérer de cette emprise technologique, de reconnaître l'importance del'examen des besoins, de l'analyse conceptuelle et l'intérêt de susciter une interactionpositive entre les professionnels de la technologie et les utilisateurs, et en �nal une par-ticipation plus active de ces derniers à l'expression des besoins et au choix des solutions[Rol96].

Les méthodes de conceptionLes premières méthodes de conception des SI, appelées aussi méthodes d'analyse,

datent du début des années soixante. Des méthodes, comme CORIG (COnception etRéalisation en Informatique de Gestion [Mal71], cherchaient à standardiser le métier dedéveloppeur d'application et initialisaient une approche industrielle d'informatisation[Fro97].

Les méthodes cartésiennes, qui ont connues du succès dès les années soixante-dixcomme SADT ([Lis90], [Tec89]) ou SD/SA [GS79], ont introduit la notion de traitementpermettant une décomposition hiérarchique fonctionnelle d'un SI. Elles mettaient enévidence la nécessité d'une démarche par étape fondée sur une programmation structuréeet modulaire. Elles préconisent d'analyser et de concevoir le SI en se centrant sur sesfonctions. Cette appellation est due au fait qu'elles associent au paradigme cartésien uneapproche fonctionnelle de conception [RF90].

Les méthodes systémiques des années quatre-vingt comme MERISE ([BR00] ainsique [TRC+89]), IDA ([BP89]) ou REMORA ([RFB88]) ont provoqué une rupture parrapport aux deux précédents types de méthodes. Elles mettent en avant les notionsde données, d'actions, d'événements et de relations entre les éléments qui privilégientune approche conceptuelle globale d'un SI. Elles ont leurs racines dans la théorie dessystèmes. Dans leurs approches, le SI est perçu comme un artéfact qui fournit une re-présentation des faits présents et passés de la vie de l'organisation. Le SI est un modèleabstrait de la réalité organisationnelle qui apporte aux acteurs et décideurs la connais-sance dont ils ont besoin pour agir et décider ([RF90], [Fro97] , [LM77], [Bou56], [Che76],[Cod70], [BBG78]). Une analyse de ces méthodes systémiques est détaillée dans [Thi85b].

Au milieu des années quatre-vingt, Thiery [Thi85b] a proposé un modèle et un lan-gage fondés sur les Types Abstraits Algébriques (TAA) faisant le pont entre les mé-thodes systémiques et les méthodes objets. Cette proposition a précédé la méthode DI

22


(dite Démarche Intégratrice) qui a fait l'intégration des concepts des di�érents courantsde méthodes systémiques citées ci-dessus (MERISE, REMORA et IDA). Cette intégra-tion permet la spéci�cation du schéma conceptuel à partir des catégories � Objet �, �Opération � et � Evénement � (cette spéci�cation a donné lieu à la création du modèleOOE) [FT97] et [FTS96].

Les méthodes objets des années quatre-vingt-dix sont une synthèse des méthodessystémiques et des méthodes cartésiennes. Elles permettent des spéci�cations détailléesdes éléments d'un SI en introduisant la notion d'objet regroupant structures de donnéeset traitements et proposent des spéci�cations globales d'un SI par l'intermédiaire despéci�cations statiques et dynamiques.

Elles adoptent deux approches principales :� Une approche orientée logiciel, adoptée par les méthodes dites techniques comme

HOOD [Lai91], MECANO [Gir91], etc. ;� Une approche plus orientée SI adoptée par des méthodes globales comme OOA3

[PY91], OMT4 [RBP+91], OOSA5 [EKW92], etc.Les méthodes objets étant de plus en plus nombreuses, des tentatives d'uni�cation

ont été e�ectuées. En particulier, la modélisation UML, dé�nie par l'Object ManagementGroup (OMG) et issue des travaux de James Rumbaugh, Grady Booch et Ivar Jacob-son. Elle uni�e les concepts présents dans les trois méthodes (OOD/OOA, OMT et Ob-jectoring) (cf. [CPFJF+97], [BR95], [BJR96], [Mul97], [RBP+91], [Boo91], [JCJO92]).L'OMG di�use depuis novembre 2005 la version UML 2. Celle-ci propose 13 types dediagrammes (9 en UML 1.3). Les 13 diagrammes UML sont dépendants hiérarchique-ment et se complètent, de façon à permettre la modélisation d'un projet tout au long deson cycle de vie.

Systems Modeling Language - SysML en abrégé - est un langage de modélisation spé-ci�que au domaine de l'ingénierie système. Il permet la spéci�cation, l'analyse, la concep-tion, la véri�cation et la validation de nombreux systèmes et systèmes-de-systèmes. Al'origine, SysML a été développé dans le cadre d'un projet de spéci�cation open source,et inclut une licence open source pour sa distribution et son utilisation. SysML se dé�-nit comme une extension d'un sous-ensemble d'UML (Uni�ed Modeling Language) vial'utilisation du mécanisme de pro�l dé�ni par UML.

SysML o�re aux ingénieurs systèmes plusieurs améliorations notables par rapportà UML, qui a tendance à être centré sur le logiciel. SysML réutilise sept des treizediagrammes d'UML 2 ; il ajoute deux diagrammes spéci�ques (Diagrammes de Requi-rements et diagrammes Paramétriques), et les tableaux d'allocations, qui peuvent êtredynamiquement dérivés des diagrammes SysML. Une analyse e�ectuant une comparai-son des diagrammes SysML et UML 2 est disponible dans [FAQ].

Vers un SI Produit

Dans un environnement concurrentiel qui exerce une forte pression sur les coûts,peu de secteurs, peu d'entreprises échappent à la concurrence internationale ou à la

3Object Oriented Analysis (Méthode d'analyse orientée objet)4Object Modeling Technique (Modélisation orientée objet)5Object Oriented Systems Analysis (Méthode d'analyse de système orientée objet)

23


nécessité de travailler pour une clientèle mondiale. Dès lors qu'il a été décidé de pouvoirrépondre à des clients dispersés géographiquement et culturellement, il faut alors faireface à plusieurs dé�s :

� L'accélération des cycles de vie, pour l'industrie manufacturière, les temps de dé-veloppement des produits ont été de plus en plus réduits.

� De nouvelles exigences sur les produits et les modes de travail. Plusieurs boulever-sements touchent les manières de travailler :� la nécessité d'intégrer une part croissante d'innovation externe (co-innovation) ;� le développement des plateaux multi-sites, multi-entreprises, physiques ou vir-

tuels, permettant d'appliquer des techniques de Concurrent engineering6 ;� la conception de produits modulaires, clés de la réutilisation et de la di�érentia-

tion retardée ;� l'utilisation de nouvelles technologies comme la maquette numérique, le confe-

rencing autour d'une maquette virtuelle ou l'usine numérique.� L'entreprise étendue :

Deux facteurs clés ont rendu la collaboration en entreprise étendue incontournable,et en font une tendance en croissance :� la non-maîtrise de la totalité des disciplines entrant dans la conception d'un

produit ;� la recherche du moindre coût.

Le développement des outils informatiques et des techniques d'optimisation sur lessystèmes de production se sont largement di�usés sur les autre fonctions de l'entrepriseindustrielle. L'émergence des outils/systèmes métiers (GPAO7, CAO8, FAO9, . . .) a gé-néré une prolifération constante des volumes de données. De fait, ces évolutions ont misle SI au c÷ur de la gestion de l'entreprise, avec, en grande partie, des di�cultés focaliséessur le système informatique.

L'entreprise intégrée a généré un réel besoin d'intégration des données. Ce besoind'intégration a permis l'émergence des Product Data Management (PDM) ou Systèmesde Gestion des Données Techniques (SGDT). Rapidement, les PDM ont évolué vers unegestion complète des données de conception, avec ensuite l'ambition de supporter l'en-semble des processus et des données du produit à toutes les étapes du cycle de vie. Lanécessité de gérer les assemblages physiques en toute cohérence avec les nomenclatures,de piloter les cartouches des plans CAO à partir des informations stockées dans le PDM,d'alimenter plusieurs applicatifs métier en information à partir du même référentiel pro-duit a conduit les entreprises du manufacturing à faire dialoguer les outils informatiquesqui supportent les aspects � métier � (CAO/XAO) et � gestion � (PDM) de leurprocessus de conception. On remarquera également que dans le contexte industriel quia permis cette approche, le support informatique des aspects � métier � a précédé lesupport des aspects � gestion � [Cha03]. Les besoins d'un travail collectif ont concurruau partage d'information entre les di�érentes entreprises partenaires. Ainsi, l'intégrationdes données initiée par les PDM s'est complétée d'une intégration des processus et desorganisations. En e�et, le développement des PDM a contribué fortement à l'apparition

6Ingénierie concourante - approche systématique pour concevoir un produit qui prend en considéra-tion tous les éléments de son cycle de vie

7Gestion de la production Aassistée par Ordinateur8Conception Assistée par Ordinateur9Fabrication Aassistée par Ordinateur

24


d'un domaine connexe au SI qui s'intéresse aux problèmes spéci�ques pour le dévelop-pement des produits : Les systèmes Product Lifecycle Management (PLM) ou Systèmesd'Information du cycle de vie du Produit10 (SIP).

1.2.2 Autour du SI Produit

Le Système d'Information du cycle de vie du Produit occupe une position de plus enplus importante dans les entreprises puisqu'il a l'ambition de gérer l'information et lesprocessus qui caractérisent le développement des produits industriels. Cauvet [CRE+01]propose quatre éléments signi�catifs qui donnent une spéci�cité au SIP :

� Les informations relatives aux produits constituent le socle de structuration etpermettent leur utilisation au sein des processus de la conception au service aprèsvente.

� Les documents techniques caractérisent les sources d'information adaptées auxmétiers des di�érents acteurs (plans, instructions, etc.).

� Les �chiers d'échanges avec les autres outils informatiques (simulation, CAO, etc.).� Les work�ow caractérisant la manière dont chacun participe à la gestion (création,

consultation, validation, etc.) des données techniques.Plus formellement, Gzara [Gza00] propose une dé�nition du SIP : � Un dispositif or-

ganisationnel permettant de réguler la création, la circulation, l'utilisation et l'évolutiondu patrimoine informationnel du produit, c'est-à-dire l'ensemble des informations qui dé-�nissent comment le produit est conçu, fabriqué et utilisé �. Cette dé�nition théorique,à laquelle nous adhérons, ainsi que la plupart des travaux dans le domaine ([Ter05],[Mes08], [PMLJ07], [Deb04], [MS02]) nous permet de mettre en évidence trois notionsessentielles dans les SIP :

� Les informations Produit qui vont permettre de structurer et stocker le capitalinformationnel technique,

� Les Processus industriels qui vont caractériser les di�érentes étapes du développe-ment du produit.

� L'Organisation des acteurs mettant en ÷uvre les processus industriels.

Par ailleurs, il convient de rappeler que le contexte théorique du système d'informations'appuie sur des systèmes informatiques industriels. Même si son périmètre n'est pastoujours facile à délimiter, tous les SIP se sont développés autour de deux catégoriesd'outils : les outils de production de données (outils métiers) et les outils de stockage dedonnées (base de données).

Product Data Management - PDM

Les PDM11 ou SGDT sont issus du monde de la CAO. A l'origine, ils étaient utiliséspour la gestion des données d'ingénierie (EDM). Depuis quelques années, ces systèmesont pris une toute autre dimension pour devenir un référentiel de données Produit etProcessus partagées par les acteurs de l'entreprise. Ainsi donc, la gestion de donnéestechniques (GDT), apparue au départ pour répondre aux premiers besoins d'automati-

10en abrégé Système d'Information Produit11Product Data Management

25


sation des fonctions d'entreprise (comme la gestion documentaire), se positionne parmiles applications transversales de l'entreprise.

Maurino [Mau93] dé�nit le PDM comme étant : � Un ensemble organisationnel quipermet de contrôler la création, la di�usion, l'utilisation et l'évolution du patrimoineformel de dé�nition du produit �. Finalement, les Systèmes de Gestion de données tech-niques sont les progiciels permettant d'assurer la gestion des données techniques d'unproduit. Ils permettent également d'automatiser le traitement des données par la miseen place de mécanismes de work�ow [Deb04].

Quelques soient les outils utilisés, ils se caractérisent par des capacités fonctionnellesrelativement standards, présentées ci-dessous.

La gestion des données ou la notion d'armoire électronique sécurisée La ges-tion des données assure le stockage, l'accès sécurisé et le partage d'information techniquepour l'ensemble des acteurs de l'entreprise. Dans une première étape, le système doitgarantir la pérennité et l'intégrité de l'ensemble des données référencées à toutes lesétapes de développement des produits. On di�érencie le contenu (la donnée elle-même)du contenant (la référence, attributs, liens), ce dernier étant l'élément de base dans laconstitution de la méta-data. Quelles que soient les technologies de stockage utilisées(base de données, �chiers, bases distribuées, ... ) la maîtrise des données de référenceimplique une encapsulation de l'information générée par par les di�érents composantslogiciels et son intégration dans les processus de circulation et de consultation. La resti-tution de l'information s'inscrit logiquement dans la seconde étape. En plus de l'aspectcapitalisation, le PDM doit fournir aux utilisateurs les moyens d'accéder aux informa-tions au travers d'une consultation sécurisée, par un accès exploratif et intuitif maisaussi grâce à des mécanismes évolués de recherche d'information [BEA96].

La gestion de la structure et de la con�guration produit L'objectif de la structu-ration et de la con�guration de produits est de structurer l'ensemble de ses composanteset de permettre son exploitation au travers de vues adaptées aux multiples intervenants.Il s'agit aussi de maîtriser, d'une part les évolutions de la structure produit dans le temps,d'autre part les di�érentes con�gurations applicables et leurs écarts respectifs. Ces dif-férences dans l'approche du produit (production, conception, ...) mettent en évidencedi�érents niveaux d'abstraction qui impliquent aussi, di�érents niveaux de con�guration.

La gestion des processus et des �ux de travail La gestion des �ux d'informationnécessite la prise en compte des processus qui vont transformer cette information. Lagestion des processus industriels reste une fonction di�cile à mettre en ÷uvre dans lesSGDT compte tenu de la complexité de ces types de processus. Les SGDT actuels selimitent en général aux processus de modi�cations et d'évolution des produits. Ces pro-cessus sont généralement considérés comme des processus de work�ow [Per02]. Le work-�ow est une démarche qui consiste à concevoir, contrôler, router, automatiser et suivreles circuits du �ux de documents, et plus généralement d'informations, de l'entreprise.Les outils de work�ow intégrés au SGDT garantissent le suivi des di�érents dossiers decon�guration, et plus généralement de tous les processus de travail [Per02]. En tant quedomaine des collecticiels (ou groupeware), les principaux concepts du work�ows seront

26


décrits au chapitre 4 (cf sec. 4.3.2).

Les outils xAO

xAO est un sigle désignant l'ensemble des processus de conception et de fabricationindustrielles assistées par ordinateur (d'où le sigle AO) ; en anglais on parle de "ComputerAided - CA". Les technologies xAO se sont développées avec l'informatique, remplaçantles dessins sur feuilles, la fabrication de maquettes, la simulation physique des piècesindustrielles.

Le dessin assisté par ordinateur - DAO Le dessin assisté par ordinateur (DAO)est une discipline permettant de produire des dessins techniques avec un logiciel informa-tique. On le distingue de la synthèse d'image dans la mesure où il ne s'agit pas du calculde rendu d'un modèle numérique mais de l'exécution de commandes graphiques (traits,formes diverses, etc.). L'intérêt de la DAO est essentiellement un apport de praticabilitédans la gestion des documents, facilitant l'édition de modi�cations, l'archivage, la repro-duction, le transfert de données, etc. On confond souvent DAO et CAO : la CAO n'apas pour fonction première l'édition du dessin [DB00]. De plus, avec le développementde la 3D, la DAO avec ses dessins et vues 2D est obtenue par projection ou extractiondes modèles 3D, elle est donc intégrée à la CAO.

La conception assistée par ordinateur - CAO La CAO permet de concevoir dessystèmes dont la complexité dépasse la capacité de l'être humain comme par exemple enmicro-électronique. La conception virtuelle permet l'appréciation globale du comporte-ment de l'objet créé avant même que celui-ci n'existe. En CAO, on ne dessine pas, onconstruit virtuellement un objet capable de réagir dans son espace non réel selon des loisrégies par le logiciel. Le résultat, appelé maquette numérique constitue alors un véritableprototype évolutif ; et chaque corps de métier peut disposer d'un outil CAO [GAR87].

La gestion de la production assistée par ordinateur - GPAO Un logiciel deGPAO est un programme modulaire de gestion de production permettant de gérer l'en-semble des activités, liées à la production, d'une entreprise industrielle : Gestion desstocks et des achats ; Gestion de commandes ; Gestion des produits engendrés par cescommandes ; Gestion des articles entrant dans la fabrication de ces produits et de leursnomenclatures-gammes ; Expédition des produits ; Facturation. La GPAO est notam-ment caractérisée par un système de réapprovisionnement en produits et composantsappelé calcul des besoins nets ou CBN.

La fabrication assistée par ordinateur - FAO Le but de la fabrication assistéepar ordinateur ou FAO est d'écrire le �chier contenant le programme de pilotage d'unemachine-outil à commande numérique. Ce �chier va décrire précisément les mouvementsque doit exécuter la machine-outil pour réaliser la pièce demandée. On appelle égalementce type de �chiers : programme ISO ou blocs ISO. Elle est caractérisée par trois étapes :

1. La modélisation : La conception de la pièce à fabriquer est réalisée à partir du�chier CAO importé via un format d'échange standard. Certains outils de FAO sont

27


capables de relire directement les �chiers des grands fournisseurs de CAO. Dansd'autres cas, la CAO et la FAO sont complètement intégrées et ne nécessitent pasde transfert. Pour ces progiciels, on parle de CFAO.

2. Élaboration des parcours-outils : A partir de la modélisation 3D importée, ilest possible de passer à la programmation des parcours outils. Le programmeurcrée les parcours en respectant les choix d'outil, les vitesses de coupe et d'avance,et les stratégies d'usinage à mettre en ÷uvre. Le progiciel de FAO "plaque" lestrajectoires des outils choisis sur la modélisation 3D et enregistre celles-ci sousforme d'équations.

3. La Machine à commande numérique : La dernière étape consiste, depuis leprogramme de FAO ainsi élaboré et véri�é, à générer les blocs ISO pour la machineoutil. Ce programme est appelé un Post-Processeur. Le �chier ISO obtenu esttransmis à la MOCN (Machine Outil à Commande Numérique), puis exécuté parcette machine, après la phase de réglage indispensable.

On parle également de l'ingénierie numérique ou Ingénierie Assistée par Or-dinateur (IAO) regroupe l'ensemble des moyens numériques et logiciels habituellementutilisés par les ingénieurs et techniciens des Bureaux d'Études pour concevoir, simuleret valider de nouveaux produits et processus industriels. L'aboutissement de la phased'ingénierie numérique d'un produit est sa maquette numérique [BBF05].

Font classiquement partie de la catégorie des outils d'ingénierie numérique : les lo-giciels de CAO, les logiciels de simulation des comportements (statiques, cinématiques,dynamiques, rhéologiques, ...), les logiciels de FAO, les PDM, les SBC (Système de Basesde Connaissance), les systèmes de KLM (Knowledge Lifecycle Management), les envi-ronnements immersifs.

D'autres plate-formes autour du produit, nous citons ci-dessous l'APS et le MES,liés plus aux processus de production.

L'APS (Advanced Planning and Scheduling System) Les APS sont liés auxprocessus de gestion de production et plus particulièrement à l'allocation des composantset à l'a�ectation des capacités de production de manière à optimiser la satisfaction dela demande. Ce sont des applications qui ont pour objet l'optimisation de la chaînelogistique depuis la prévision de la demande jusqu'au transport �nal en passant par laplani�cation de la production et des approvisionnements. Le champ d'action des APSinclue, la demande, les approvisionnements, la production, le stockage et la distribution[SK08].

Le MES (Manufacturing Execution System Le système MES couvre les princi-paux domaines du contrôle de la production. Il permet à tous les acteurs ayant un lienavec la production, de traiter leurs domaines dans un système unique et homogène. Lesystème MES est destiné à obtenir une vision globale et immédiate de la production surl'ensemble des ressources. Il est le médiateur indispensable entre les systèmes de gestion(non en temps réels) de la production (ERP, GPAO,CRM, SCM, APS) et les systèmesou besoins liés aux impératifs temps réel de la production (Atelier, lignes de fabrication,Contrôle commande, etc.) [BB02a].

28

1.3. La gestion du cycle de vie produit - PLM

1.3 La gestion du cycle de vie produit - PLM

Les Systèmes d'Information Produit (SIP) sont, en première analyse, relatifs auxactivités de conception et de développement de nouveaux produits, et plus généralementaux activités du processus de conception de l'o�re produit (en anglais � design chain�). En première analyse seulement, car un certain nombre d'informations provenant duprocessus de production de l'o�re produit sont susceptibles d'être concernées et � remon-tées � au sein des SIP. Ces informations sont essentiellement celles liées au � feed-back� de production dans un but de maintenance et/ou de capitalisation des connaissances.Au �nal, les SIP sont les systèmes d'information qui supportent la gestion du cycle devie des produits (en anglais � Product Life cycle Management �), terme ombrelle pourdésigner simultanément la gestion des work�ows des processus sous-jacents, des struc-tures produits, des données techniques et documents associés, . . . bref de l'ensemble desinformations issues de ces processus et consommées par ces processus [Cha03].

Cette section dé�nit les concepts du PLM et présente un état des lieux en la matière.

1.3.1 Le PLM : concepts, état des lieux, périmètre

Ces dernières années, un bon nombre de dé�nitions du cycle de vie du produit ontvu le jour [RF05] [SRF+05]. Néanmoins, l'ensemble de ces dé�nitions se rejoignent sur lefait que chaque étape du cycle de vie du produit intègre des activités, des acteurs, et desdomaines d'expertises di�érents mais dépendants les uns des autres. La �gure suivante(�g. 1.1) présente un schéma mettant en parallèle les étapes du produit et les activitésimpliquées [Cha05]. Ce schéma s'inspire des travaux de Subrahmanian [SRF+05]. Les�èches symbolisent à la fois les �ux d'informations et de données échangées entre lesacteurs et l'évolution du produit dans son cycle de vie.

Une première recherche sur Internet sur le terme � Product Lifecycle Management �donne plus de 50.100.000 liens et informations diverses. Cette surabondance de � bruit� incite en premier lieu à préciser de quoi l'on parle.

A�n de bien cerner le sens du concept PLM, cinq dé�nitions de ce dernier peuventêtre retenues :

� � le cycle de vie comprend le concept initial, à partir des exigences clients, sondéveloppement, intégrant le développement de ses moyens de production (indus-trialisation produit/processus), sa vie opérationnelle et sa �n de vie � [Deb04].

� � activité qui consiste à gérer les produits d'une entreprise sur l'ensemble de leurcycle de vie, de la manière la plus e�cace ; PLM aide l'entreprise à mettre sesproduits sur le marché plus rapidement et à mieux gérer leur �n de vie �. [Sta04]

� � stratégie d'a�aires qui aide l'entreprise dans le partage d'information sur leproduit, dans l'application de processus communs, et dans l'exploitation de laconnaissance organisationnelle lors du développement de produits, de la conceptionau retrait, et ce au travers de l'entreprise étendue �, selon Dassault Systèmes12.

� � une approche stratégique d'entreprise, qui applique un ensemble de solutionspour soutenir dans un mode collaboratif la création, la gestion, la disséminationet l'utilisation de l'information de dé�nition des produits, en entreprise étendue,

12http ://www.3ds.com/fr/plm-glossary/

29


du concept à la �n de vie en intégrant les acteurs, les processus, les systèmes etl'information �, selon CIMData13.

� � est considéré comme une approche stratégique de gestion d'informations concer-nant le produit, dans tout son cycle de vie : de la dé�nition jusqu'à la mise horsservice tout en passant par la fabrication et l'entretien � [Saa04].

Retrait de service

- Démantelement- Revalorisation- Recyclage

Avant projet

- Analyse du marché- Identification du besoin- Etude de faisabilité- Recherche de concept

Organisation

- Gestion du projet- Gestion des équipes- Récupération des informations et données nécessaires

Recherche de solutions

- Innovation- Réutilisation de projets similaires

Définition

- Conception détaillée du produit

Evaluation

- Simulation- Prototypage

Utilisation

- Service après vente- Maintenance

Production

- Définition du process de fabrication- Planning- Création de la « Suplly Chain »

Fig. 1.1 � Cycle de vie du produit et activités associées [Cha05]

Selon ces dé�nitions, le PLM représente avant tout une discipline industrielle entière ;il tire ses origines des transports aériens et de la défense, se prolongeant en grandepartie dans les secteurs de l'automobile, l'électronique, la pharmacie, l'agro-alimentaireet touche aujourd'hui certains secteurs tertiaires tels que la banque et les assurances.

Les di�érentes phases du cycle de vie du produit

Généralement, le terme � cycle de vie � indique l'ensemble des phases pouvant êtrereconnues comme étant des � étapes � indépendantes que le produit pourra suivre, dela (i) conceptualisation, (ii) conception, (iii) plani�cation de fabrication, (iv) produc-tion, (v) distribution, (vi) utilisation, (vii) dissémination et recyclage [VR99]. Dans lalittérature, l'identi�cation de ces étapes du cycle de vie révèle au moins deux principaux

13http ://www.cimdata.com/plm/de�nition.html

30


domaines d'analyse : (i) les étapes du cycle de vie du produit sur les marchés, et (ii) lesétapes du cycle de vie du produit qui tiennent compte de sa vie physique. Dans la suitedu déroulement, nous considérons l'aspect physique du cycle de vie du produit.

Aspects � métier � et � gestion � du cycle de vie des produits

Pour autant, les SIP ne traitent que l'aspect � gestion � du cycle de vie des produits,prenant en compte les problématiques d'identi�cation, de gestion des versions et de clas-si�cation des articles, de dé�nition des nomenclatures produit, d'association article -document, de validation des étapes du cycle de vie produit, . . . L'aspect � métier � ducycle de vie des produits est essentiellement géré - dans l'industrie du manufacturingtout au moins - par les CAO-XAO ; qui prennent en charge les problématiques de re-présentation tridimensionnelle des pièces et des assemblages, de calcul de structure, desimulations numériques diverses. Dans les industries des métiers de la formulation, lesaspects � métier � du cycle de vie produit peuvent être par exemple : l'optimisation deplans d'expérience, la simulation des propriétés et/ou du comportement d'un mélange, lasimulation de l'e�et d'un traitement (mécanique, thermique), la microbiologie prédictive[Cha03].

Le périmètre du PLM

Dans la littérature sur le PLM, la plupart des auteurs [Bro03] [GTBM05] le dé�-nissent plus comme une approche transversale de création, de gestion et de dissémina-tion de l'information auprès des di�érents services de l'entreprise, ou de ses partenaires,concernés par le produit : bureaux d'études, service marketing, achats, logistique, pro-duction et après-vente. La démarche PLM implique une imbrication très forte avec l'ERP(Entreprise Ressource Planning) de l'entreprise (pour la gestion des stocks, de la pro-duction, etc.), ses outils CRM (Customer Relationship Management) (pour les retoursutilisateurs sur les anomalies, CRM analytique, etc.) et le SRM (Supplier RelationshipManagement) de son service marketing, etc. Il peut de ce fait apparaître comme une dis-cipline pouvant ou voulant tout gérer, analyser et contrôler dans l'entreprise, une sorted'ERP universel aux contours �nalement très �ous [Ger08].

Il s'agit donc là d'un vaste domaine de recherche qui englobe plusieurs axes issusdes dimensions managériales, technologiques et scienti�ques. D'ailleurs, tel que dé�nici-avant, le concept PLM prend en considération la gestion e�cace de la �n de vie desproduits, proposant ainsi de fermer la boucle du cycle des matières et laissant entre-voir une préoccupation à caractère environnemental. Il en va de même pour le principed'optimisation du cycle de vie du produit (cf. Section "Cycle de vie du produit"), quipousse la notion d'e�cacité à ses limites et qui, au passage, permet l'élimination degaspillages sous di�érentes formes [BB03]. L'étude sur les besoins environnementaux etle PLM sortent du contexte de ce travail, néanmoins, nous redirigeons le lecteur vers lestravaux de Burton [BB03] sur ce type de besoins .

Le PLM se limite bien aux informations liées au produit, certes en interconnexionavec d'autres dispositifs de management des données, mais se focalisant sur le manage-ment de ces informations tout au long de la vie du produit (Cf. Figure suivante).

31


Fig. 1.2 � Cycle de vie du produit et d'information produit

Dans certains contextes, le PLM est considéré comme une nouvelle génération duPDM ; alors que dans la réalité industrielle, le PDM s'occupe d'une partie des informa-tions du cycle de vie du produit [BOK02].

1.3.2 Les modèles Produit, Processus, Organisation

L'objet de cette partie est de présenter les trois modèles supports au PLM : Pro-duit, Processus, Organisation. Les modèles de processus seront étudiés dans le chapitresuivant.

Modélisation du Produit

Le produit est un véritable concept aux formes multiples dont la représentationdépend du point de vue de celui qui l'utilise, et de l'étape du cycle de vie dans lequel il sesitue. Le produit en tant qu'élément sortant de l'entreprise se dé�nit simplement par : � lacombinaison des biens et des services à fournir � [NKD94]. Cette dé�nition correspondà une vue du produit orienté vers le client. Le produit c'est aussi un regroupementd'informations et de données qui organise et structure la connaissance qui va permettrede le concevoir et de le produire. La façon dont il est structuré est donc en grandepartie liée au métier ou à l'activité de celui qui va l'exploiter. Le produit en phasede production n'est pas représenté de la même manière qu'en phase d'établissementdu cahier des charges. Toutes les descriptions sont pertinentes car elles contribuent à lacapitalisation du patrimoine technique et donc du savoir faire de l'entreprise. La di�cultéest de permettre une gestion globale du produit dans la diversité de ses représentationstout en maintenant la cohérence globale des modèles. Pour ce faire, il convient de dé�nirles di�érents niveaux de structuration qui dé�nissent le produit, et qui vont permettrede construire une représentation multi-niveaux [Per02].

De plus, toutes les formalisations récentes des produits font clairement apparaître uneapproche multi-dimentionnelle. La structuration des produits est à la base du modèleproduit. Elle dé�nit sous trois niveaux (l'abstraction, la composition et l'évolutivité)comment l'information va être stockée dans le système. Elle doit permettre le cas échéant

32


de réaliser les di�érentes activités nécessaires à la fabrication des produits [PC95]. Ladémarche la plus naturelle pour structurer le produit est de caractériser ses élémentsconstitutifs ainsi que les relations entre ces éléments. Ceux-ci sont relativement biendécrits dans la littérature et dé�nis par di�érentes normes [AFN85], il s'agit des : articles,fonctions, nomenclatures, documents [Per02].

Tous les éléments que nous venons de présenter constituent les briques utilisées par lemodèle de produit. Ce modèle est un mécanisme capitalisant l'ensemble des informationssur le produit à tous les niveaux de description a�n de permettre sa réalisation au seindes activités de l'entreprise [PC95]. De la conception à la destruction du produit, le rôledu modèle de Produit est :

� De permettre le maintien de la cohérence entre tous éléments constitutifs.� De garantir la pérennité et le stockage de l'information sur les produits.� D'être exploitable (accessible et di�usable) au sein du SIP.Dans le domaine de la conception, le modèle produit a pour but de faciliter le travail

du concepteur en proposant les éléments adaptés à une démarche de conception. Denombreux modèles existent :

� Le modèle de produit FSB (Fonction-Behavior-State [UTTO90] est basé sur unedescription fonctionnelle à base d'entités qui décrivent les intentions de conception(Function) et les séquences de changement d'état (Behavior). Les relations entreentités expriment des liens de causalité, de décomposition, de contraintes et decompléments d'information.

� Le modèle CPM (Core Product Model) développé par le NIST14 a pour but defournir un noyau de représentation générique d'information produit capable dereprésenter les connaissances communes entre les activités de développement duproduit [FFB06].

� La modélisation basée sur les caractéristiques (Feature based Modelling) expliciteles formes géométriques et les connaissances pour les obtenir [Ber00], [GAM98].

� Le modèle fonctionnel [Dup91], [KKKL93] utilise une base de composants (lesfonctions) susceptibles de répondre à un cahier des charges fonctionnel.

� Le modèle multi-vues [Tic96] assure le stockage des éléments par métiers ainsi queleur restitution en fonction des besoins. Il est basé sur l'intégration des connais-sances métier.

� Le modèle hybride [EGC97] lie la description fonctionnelle et la description géo-métrique du produit. Citons aussi les approches multi-modèles qui décrivent leproduit et le processus de conception [Har97], [Gza00], [PC01].

Le modèle de produit constitue le support structurant les données techniques à travers lesobjets ou les documents [AG97], [Tol97]. Soutenus par des grands groupes industriels, desprojets de normalisation des modèles produit sont à l'étude au sein de l'ISO, produisantdes normes comme STEP, SysML, PLCS, etc..

Modélisation des processus

La modélisation des processus s'inscrit dans la démarche naturelle de l'automaticienqui modélise des systèmes physiques a�n de les contrôler. Ainsi, modéliser les processus

14National Institute of Standards and Technology

33


de l'entreprise, c'est obtenir une abstraction d'un système hautement complexe a�nd'en assurer un meilleur contrôle. Les processus étant caractéristiques du comportementglobal de l'entreprise, leur modélisation va permettre de faciliter la communication entreles acteurs, et surtout de rationaliser (voire automatiser) tout ce qui peut l'être.

Les concepts liés à la notion de processus industriels sont détaillés dans le chapitre 4(Cf. section 4). Nous y expliciterons quelques principaux domaines au sein du processusde développement produit que sont la R&D, la conception et la fabrication, puis nousprésenterons di�érentes méthodes de modélisation des processus.

Modélisation de l'organisation

L'organisation dans un contexte de développement du produit peut être dé�niecomme étant la partie créant et gérant l'environnement de développement au sein du-quel se déroule le processus de développement du produit. Cette gestion est pilotée enfonction des particularités provenant de la discipline, du projet, des acteurs ou encorede l'entreprise considérée.

Le modèle d'organisation permet de corréler les di�érentes informations nécessairesà la mise en ÷uvre et au suivi du projet, sur le plan des ressources, des infrastructuresmais aussi du point de vue du pilotage. Le modèle d'organisation issu du modèle IPPOP[Gir04] est composé de di�érents éléments :

� Projet : dé�nit la �nalité de la conception ou le domaine qui est objet de laconception ainsi que l'organisation locale mise en ÷uvre pour la satisfaction desobjectifs de conception. Un projet se décompose en sous projets.

� Centre décisionnel : dé�nit un espace décisionnel c'est-à-dire le lieu où se prend unedécision. Les décisions considérées sont celles relatives à l'organisation du projetà savoir sa structuration, sa gestion et son suivi. Ce centre permet de dé�nir desdécisions de nature di�érentes comme : gérer la connaissance produit, gérer lesbesoins de conception, gérer les informations projet, gérer les ressources.

� Cadre de décision : établit les liens décisionnels qui existent entre les centres dedécisions. Un cadre de décision est composé d'objectifs, des variables de décision,des contraintes de décisions, des critères de décisions, d'indicateurs de performanceet d'informations complémentaires. Il permet ainsi de dé�nir le contexte pour laprise de décision dans le centre de décision qui le reçoit.

� Cadre de conception : dé�nit le contexte dans lequel devra se dérouler le travaildans le centre de conception. Ces éléments sont dé�nis par les centres de décisionsdont le centre de conception dépend.

� Niveau : permet de structurer les objets dé�nis dans le modèle organisation. Unniveau est dé�ni par le concept d'horizon-période. Il existe au moins trois niveaux :stratégique, tactique et opérationnel qui sont dé�nis par des horizons décroissants.

� Performance : permet d'assurer une évaluation ou une mesure des actions réaliséesa�n d'assurer le suivi pour corriger ou anticiper d'éventuels écarts. La performanceest à considérer par le triplet : objectifs, indicateurs de performance et leviersd'action.

D'autres modèles ayant trait aux modèles Produit-Processus ont été développés, oncite notamment : le Modèle intégré de dé�nition de système mécanique : MIDSYM ; le

34

1.4. Les architectures d'intégration au sein du Système Informatique

Modèle par Couche ; le Modèle Fonction � Comportement � Structure ; Modèle MOKA :Methods and tools oriented knowledge acquition ; Modèle produit CPM : Core ProductModel. Un état de l'art sur ces modèles a été développé dans la thèse de Geryville[Ger08].

L'étude des systèmes d'information supports à la gestion de produit et de processusnous conduit à aborder les questions d'intégration et par la suite les architectures d'in-tégration des applications intra/inter entreprise(s). La section suivante est consacrée àce sujet.

1.4 Les architectures d'intégration au sein du Système In-formatique

Même si l'on suppose que les di�érents partenaires se font su�samment con�ancepour collaborer e�cacement, l'extension des SI au-delà des frontières de l'entreprise posede réels problèmes [Rei04] :

� d'interopérabilité, capacité des matériels et des logiciels à fonctionner ensemble viades réseaux de communication ;

� d'inter-fonctionnement, accès réciproque aux données et aux ressources nécessaireslors des "passages de relais" entre multiples systèmes souvent hétérogènes.

Le recours aux plate-formes d'intégration apporte des améliorations certaines dans lagestion de ces problèmes.

1.4.1 Le besoin d'intégration

La question de l'intégration des applications intra ou inter entreprises est une néces-sité économique forte dans le cadre d'une démarche PLM. Elle est motivée par di�érentséléments : en externe, l'intégration des applicatifs est une conséquence de la globalisa-tion des marchés et du développement de partenariats avec di�érentes parties prenantes.Outre l'échange de données classique, il s'agit de dé�nir des protocoles de transactionrésultant d'un accord entre chacun des partenaires. Il existe par ailleurs une attente forteau niveau du SI, elle concerne indéniablement la capacité à fournir une vision globale etcohérente de l'entreprise.

Les SIP ont besoin de se connecter à d'autres applications, plus particulièrement :� ERP ou SCM pour le transfert de la nomenclature de production dans l'outil de

gestion de production, ou vers une base de composants ;� con�gurateur commercial, voire CRM lorsque l'on veut permettre par exemple au

client de choisir la con�guration du produit la plus adaptée à son besoin.

35


Fig. 1.3 � Intégration ERP/SGDT/SCM/CRM

ERP et PLM

ERP et PLM ont pour ambition de fédérer les �ux d'information de l'entreprise avecdes approches relativement di�érentes. Le PLM s'appuie sur une démarche de capita-lisation des connaissances sur les produits le long du cycle de vie physique alors quel'ERP s'intéresse plus à une �uidi�cation globale des �ux dans une démarche prédictiveou réactive.

L'intégration ERP/PLM doit répondre principalement au problème suivant : lesrecouvrements. En e�et, l'analyse des di�érents �ux échangés induit inévitablement dif-férentes formes de recouvrement ce qui rend encore plus di�cile la distinction des fron-tières fonctionnelles entre ERP et SGDT. Les origines de ces recouvrements sont liésaux produits et aux processus. Historiquement, le SGDT modélise le produit � virtuel� alors que l'ERP décrit le produit physique (les articles, nomenclatures, gammes). Endécouplant la gestion des nomenclatures, d'étude et de production dans deux systèmesdi�érents, on augmente les risques d'incohérence et surtout de désynchronisation. Il estdonc nécessaire de faire communiquer les deux systèmes dynamiquement par des mé-canismes de synchronisation et de noti�cation. ERP et SGDT doivent jouer des rôlescomplémentaires car chacun ne peut pas prétendre maîtriser seul l'ensemble des �uxinformationnels de l'entreprise.

CRM et PLM

L'intégration concerne également le PLM et le CRM de l'entreprise. Entre PLM etgestion de la relation client, et par extension entre produit et client, existent les relationsdans les deux sens [Deb04] :

� client vers produit :� les exigences, demandes formalisées, spéci�cations émises par le client dans l'at-

tente d'un produit qui y réponde. Le PLM répond à cette fonction par la gestion

36


des exigences, qu'il faut voir encore dans sa dimension applicative (progiciels degestion des exigences), mais aussi organisationnelle et humaine (quel lien entreexigence et fonction, qui doit l'établir, comment le faire vivre...),

� la veille technologique, marketing et concurrentielle : aux frontières du PLM,les organisations et systèmes qu'elle met en jeu permettent au stratège produit,au décideur, et au concepteur de Recherche et Développement de dé�nir desorientations valides, intéressantes pour développer de nouveaux produits,

� les retours clients : constituent avec la veille la source d'information pour dé�nirle "roadmap produit" (trajectoire des versions à venir). En termes d'outil PLM, ils'agit de bases documentaires pour la partie veille, mais aussi les bases de faitstechniques/demandes d'évolution qui peuvent �gurer dans le périmètre d'unPLM ;

� produit vers client :� con�gurateurs produit : ceux-ci mettent à disposition des clients, des forces avant

vente et des commerciaux, l'ensemble des possibilités de produit, modélisant lesoptions et variantes censées re�éter la diversité produit ;

� l'ensemble des informations produit est en�n utilisé en aval comme matériau debase pour les services liés à la vie opérationnelle du produit.

SCM et PLM

Le �ux d'information conception vers production est la raison d'être du PLM, etconstitue le �ux majeur, en création de produit (articles, documents, structure produit)mais également en évolutions/modi�cations. Les points de rencontre de ces deux pro-cessus ne forment pas un unique croisement mais plusieurs contacts comme le montre la�gure suivante.

Fig. 1.4 � Impacts réciproques PLM/supply chain [ASL03]

Le cycle de vie produit face à la demandeColler à la demande par l'augmentation du mix produit et la recherche de nouveaux

37


débouchés pour les produits en �n de vie sont deux tactiques pour accroître le chi�red'a�aires et les parts de marché.

Ceci nécessite de bien connaître le marché, analyser les tendances, prévoir les évolu-tions et en�n constater la clientèle réellement touchée, et donc de déterminer �nement lemix produit : pousser la chaîne logistique à assurer un délai de livraison court pour lesproduits les plus demandés, et côté conception/PLM, assurer l'unicité des données, lepartage de la même base de référence par tous les utilisateurs, la maîtrise des évolutionsdu produit.

Il faut aussi construire la "roadmap" du produit : prévoir à l'avance les futuresvariantes et versions du produit ainsi que la cadence de leur introduction sur le marché,en liaison avec le marketing, et jusqu'à l'obsolescence et plan de retrait des produits.

De même, pour répondre à la diminution des besoins en fonds de roulement (BFR) età la réduction des coûts, deux leviers sont utilisés conjointement : la standardisation pro-duit et le retard du point de personnalisation au client (Customer Commitment Point).Le PLM y contribue en favorisant la réduction du cycle de vie via la modularisation desproduits, l'identi�cation des articles critiques, la réutilisation de têtes d'arborescencesstandard... [Mit09].

L'usine numérique est porteuse de nouveaux enjeux : la modélisation des moyensde production, ressources et étapes du processus, qui permettent d'anticiper le travaildes méthodes, de le faire avec ergonomie et en manipulant directement la dé�nitionproduit à jour. Les opérations de production ainsi modélisées permettent de dé�nirdes processus génériques facilitant les transferts. Il s'agit d'un déplacement du travaild'industrialisation des outils de GP vers le PLM.

Les besoins d'intégration ainsi exprimés nécessitent de mettre en place une infra-structure technique autorisant une coopération automatisée, de qualité, sécurisée et per-formante entre di�érents systèmes. Nous présentons dans les développements suivantsquelques architectures d'intégration des systèmes d'information.

1.4.2 Les architectures d'intégration

Entreprise Application Integration - EAI

EAI signi�e � intégration des applications d'entreprise �. L'objectif de l'architectureEAI est d'o�rir une infrastructure de communication globale, cohérente et systématiqueentre les applications du système d'information [Cru03].

Les di�érents composantes d'une application sont les suivants [Deb04] :� le premier composant est un système centralisé sur lequel convergent tous les �ux

provenant d'un système vers un autre. Il gère donc l'aiguillage des �ux entre lesdi�érents systèmes d'information mais aussi les éventuelles transformations de don-nées nécessaires à e�ectuer a�n de rendre les données de l'application compréhen-sibles par une application destinataire ;

� le deuxième composant est le middleware permettant de transporter les messagesentre les applications ;

� le troisième composant correspond aux connecteurs propres à chaque applicationpermettant de relier l'application au middleware ;

38


� une couche de transport : il s'agit de la couche qui sert à acheminer les donnéesentre les applications. Cette couche peut être implémentée par échange de �chiers,par échange de message ou encore par appel de services.

Fig. 1.5 � EAI

L'EAI a eu l'avantage d'apporter une réponse au souci de réutilisabilité des entre-prises, en leur permettant de capitaliser sur les applications existantes. C'est une réponseau souci technique d'intégration mais cela ne su�t pas [Cru03] :

� Les fonctionnalités de gestion des processus métiers des outils d'EAI sont généra-lement complexes à utiliser et dissociées de l'o�re technique d'intégration ;

� Les processus sont dé�nis à un niveau technique, et les décideurs n'ont aucunevisibilité sur leur SI ;

� Il est impossible de réconcilier cette vision avec la vision work�ow : comment faireintervenir les utilisateurs dans les processus ?

On parle également d'eAI ; celui-ci étend les problématiques initiales de l'intégrationde logiciels vers l'intégration des SI via internet. Plus qu'un moteur d'intégration, l'eAIs'intéresse aux modèles d'échanges des processus.

L'architecture orientée services - SOA

Une nouvelle approche, a fait l'objet d'une attention particulière ces dernières années.Il s'agit de l'Architecture Orientée Service, connue sous le vocable SOA (Service OrientedArcitecture). La SOA renvoie à une nouvelle manière d'intégrer et de manipuler lesdi�érentes briques et composants applicatifs d'un système informatique (comptabilité,gestion de la relation client, production, etc.) et de gérer les liens qu'ils entretiennent[MRS05], [BHH07] [IBM07].

La SOA se dé�nit comme � Une approche architecturale permettant la création deservices métier interopérables et couplés de manière souple, qui peuvent être facilementpartagés au sein des entreprises et entre celles-ci � [BS06]. Comme son nom l'indique,cette approche repose sur la réorganisation des applications en ensembles fonctionnelsappelés services [Cha08], [AB07]. Ils ont pour objectif de mettre en ÷uvre des appli-cations distribuées utilisant les protocoles et les langages devenus des standards telsque :

� XML (eXtensible Markup Language) et ses diverses déclinaisons comme le WSDL(Web Service Description Language) ou l'UDDI (Universal Description Discovery

39


and Integration) ;� SOAP (Simple Objcet Access Protocol) comme protocole d'échanges de messages

entre les application.Dans une architecture SOA, le niveau de granularité n'est plus l'application mais

le service. Ces services délèguent les traitements aux applications, et fournissent uneinterface indépendante de ces applications [AR07].

La SOA peut se décrire de la façon suivante :� Les services transverses utilisés par les applications sont mutualisés : ainsi, la

noti�cation, la sécurité ou le login sont accessibles sous forme de services. Il n'estplus nécessaire, par exemple, de re-développer la gestion du login pour chaqueapplication.

� Les échanges entre les services sont gérés grâce à des fonctionnalités de ServiceManagement. Il est alors possible de diagnostiquer et de prévenir les problèmes demontée en charge, d'indisponibilité d'une application, etc. Le Service Managementpermet aussi de remonter des informations basées sur des indicateurs métiers, àdestination des décideurs.

� Les services sont utilisés dans les processus métiers de l'entreprise. On dépasselargement la notion de connecteur applicatif : les processus n'accèdent pas à desapplications via des connecteurs, ils accèdent aux services du SI.

Au sein de la SOA, on distingue les notions d'annuaire, de bus, de contrat et deservice, ce dernier étant le noyau et le point central d'une SOA.

� Le service : il s'agit d'un composant clef de l'Architecture Orientée Services. Ilconsiste en une fonction ou fonctionnalité bien dé�nie. C'est aussi un composantautonome qui ne dépend d'aucun contexte ou service externe.

� L'annuaire de services : il référence l'ensemble des services (et des contrats associés)disponible au sein du SI, il participe ainsi activement à la mise en ÷uvre d'unecartographie dynamique du SI. Dans un modèle de bus, l'annuaire peut être auto-alimenté par le service (enregistrement). Les annuaires UDDI forment aujourd'huile standard de référencement des services.

� Le bus de service : dans une architecture SOA, le bus a un rôle de médiateur(middleware) entre le consommateur et le producteur du service. Le bus peutaussi fournir une gamme de services : versioning de service, supervision et contrôledes services, etc.

Les concepts de base de SOA sont les suivants [CD05] :� Couplage faible : un service ne peut pas appeler directement un autre service. Il

délègue cette fonction à un traitement spécialisé dans l'enchaînement qui est lafonction d'orchestration.

� Contrat d'utilisation : un service expose un contrat d'utilisation décrit en deux par-ties : une partie abstraite qui déclare les messages d'entrée et de réponse du traite-ment o�ert et une partie concrète qui décrit les standards et protocoles techniquesutilisés pour l'activation du service (XML-RPC15, SOAP-HTTP, SOAP-JMS16,. . .).

� Pattern : le pattern d'architecture SOA consiste à créer une architecture applicativequi décompose les traitements sous la forme de services rattachés à des objets

15Remote procedure call16Java Message Service

40


métier.� Localisable, activable à distance et interopérable : un service expose une interface

d'utilisation qui est la même indépendamment de sa localisation sur les réseaux.L'appel au service fonctionne quel que soit le langage et le système d'exploitationdu consommateur.

Par son caractère standard, l'approche SOA contribue à améliorer la rapidité ainsique la productivité des développements. Un composant exposé sous forme de Web Ser-vices pouvant être réutilisé à loisir par d'autres applications. Une fois publiées par le biaisde Web Services, ses fonctions peuvent être aisément intégrées aux di�érentes briques duSI sans que le développement de connecteurs spéci�ques au cas par cas ne soit nécessaire(comme les EAI) [Haa02]. La SOA consiste essentiellement en une collection de servicesqui interagissent et communiquent entre eux. Cette communication peut consister en unsimple retour de données ou en une activité (coordination de plusieurs services). Au-jourd'hui, la plupart des serveurs d'intégration (EAI) et des plates-formes applicativessavent exécuter les interfaces en mode Web Services [W3C07]. Ce qui leur permet parconséquent de supporter un premier niveau d'architectures de type SOA, c'est-à-dire unensemble de Web Services distribués dialoguant entre eux. Certaines o�res vont plus loinen incluant l'orchestration de processus standardisés (via BPEL17) [Cru03].

Cependant, un premier obstacle à la mise en ÷uvre d'une SOA est technique [CD05].Certains anciens systèmes demeurent di�cilement compatibles avec les Web Services, etdonc ne peuvent s'inscrire dans une telle architecture. Ce qui s'explique généralement parleur caractère trop peu fragmenté. Un élément qui rend en e�et les composants di�ciles àpublier sous forme de services, ceux-ci étant par nature granulaires. Autre point : mêmesi les standards des services Web (SOAP/WSDL) et de l'orchestration orientée services(BPEL) [CD05] commencent à se généraliser, les solutions d'intégration doivent encoretrop souvent proposer des langages complémentaires pour la gestion des transactions oude la sécurité. Le modèle reste encore assez loin de la palette fonctionnelle que propose,par exemple, un bus CORBA18, sorte de SOA pour le monde des serveurs d'applicationsJ2EE... Le chantier de standardisation est loin d'être achevé.

L'architecture dirigée par les modèles - MDA

L'architecture dirigée par les modèles ou MDA (pour l'Anglais Model Driven Archi-tecture) est une démarche de réalisation de logiciel, proposée et soutenue par l'OMG19.C'est une variante particulière de l'ingénierie dirigée par les modèles (IDM, ou MDEpour l'Anglais Model Driven Engineering) [OMG01].

Le principe de base du MDA est l'élaboration de di�érents modèles, en partantd'un modèle métier indépendant de l'informatisation (Computation Independent Model,CIM), la transformation de celui-ci en modèle indépendant de la plate-forme (PlatformIndependent Model, PIM) et en�n la transformation de ce dernier en modèle spéci�queà la plate-forme cible (Platform Speci�c Model, PSM) pour l'implémentation concrètedu système. Les techniques employées sont donc principalement des techniques de mo-délisation et des techniques de transformation de modèles [BB02b].

17Business Process Execution Language18Acronyme de Common Object Request Broker Architecture19Object Management Group

41


� CIM (Computation Independent Model) : appelé aussi modèle de domaine oumodèle métier. Il modélise les exigences du système. Il montre le système dansl'environnement organisationnel dans lequel il va être exécuté. Son but est d'aiderà la compréhension du problème mais aussi de �xer un vocabulaire commun pourun domaine particulier. Un CIM peut consister en deux modèles UML correspon-dants aux deux points de vue RM-ODP, Entreprise et Information du système. Lesexigences exprimées dans le CIM doivent être traçables dans le PIM et le PSM.

� PIM (Platform Independent Model) : il décrit le système sans montrer les détailsde son utilisation sur une plate-forme particulière. Un PIM peut être construiten se basant sur les points de vue Entreprise, Information et Traitement du sys-tème. Un PIM doit être ra�né par les détails d'une ou plusieurs architecture(s)particulière(s) pour obtenir un PSM.

� PDM (Platform Description Model) : il décrit la plate-forme sur laquelle le systèmeva être exécuté (ex. modèles de composants à di�érents niveaux d'abstraction :CCM, C, EJB, EDOC,. . .). Actuellement, il est souvent sous forme de manuels delogiciels et de matériels. Dans une démarche MDA, on se base sur les PDMs pourgénérer les PSMs à partir des PIMs.

� PSM (Platform Speci�c Model) : c'est le modèle produit par la transformation duPIM. Il spéci�e comment le système va utiliser la plate-forme choisie. Le PSM peutprésenter plusieurs niveaux de détails. Il peut être une implémentation s'il fournittoutes les informations requises pour la construction et l'opérationnalisation dusystème.

Le MDA fournit un processus [Cha08] et met en ÷uvre des outils pour :� spéci�er un système indépendamment de la plate-forme qui le supporte, et donc

réaliser un PIM,� enrichir ce modèle par des étapes successives,� spéci�er les plates-formes,� choisir une plate-forme particulière pour le système,� transformer la spéci�cation du système (PIM) en une autre spéci�cation pour une

plate-forme particulière (PSM),� ra�ner le PSM jusqu'à obtenir une implémentation exécutable.Les trois objectifs préliminaires de MDA sont la portabilité, l'interopérabilité et la

réutilisabilité à travers une architecture de séparation des préoccupations.La �gure suivante représente le schéma de MDA et ses di�érentes couches de spéci-

�cation [MM03] :

42

1.5. Conclusion

Fig. 1.6 � Le Model Driven Architecture de l'OMG

� Au c÷ur, se trouvent les techniques de base (UML, MOF, CWM), puis quelques-unes des plates-formes supportées et en�n en surface les services systèmes.

� A l'extérieur, sont présentés les domaines pour lesquels des composants métiersdoivent être dé�nis (Domain Facilities).

1.5 Conclusion

Nous avons présenté, dans ce premier chapitre, une étude de l'état de l'art sur lessystèmes d'information et leurs évolutions dans le contexte de l'entreprise étendue ; oùle produit est au centre des préoccupations. Ces évolutions ont favorisé l'apparition d'unnouveau concept de SI, qu'est le système d'information pour la gestion du cycle devie produit, dits SIP. Cela nous amène dès lors à présenter les principaux concepts etspéci�cités caractérisant le PLM et les systèmes d'information supports.

Nous avons également abordé les méthodes de conception du SI en général, et dé-crit les modèles "Produit, Processus, Organisation" caractérisant les SIP. Le modèle deprocessus n'est pas détaillé dans ce chapitre, vu que nous consacrons le suivant auxprocessus collaboratifs. En e�et, la question de la collaboration est une nécessité éco-nomique indispensable pour la pérennité de l'entreprise industrielle, qui nécessite uneharmonisation et une intégration des processus métiers.

Dans notre investigation, nous avons recensé un certain nombre de systèmes et ou-tils intervenants dans les di�érentes phases du cycle de vie du produit. Cela nous aconduit à aborder les questions d'intégration et à présenter par la suite les architecturesd'intégration des applications intra/inter entreprises.

43


44

2

Construction des indicateurs depilotage et Instrumentation

Sommaire2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 452.2 Pilotage et Indicateurs de performance . . . . . . . . . . 46

2.2.1 Indicateurs de performance . . . . . . . . . . . . . . . . . . 462.2.2 Pilotage et maîtrise des dysfonctionnements . . . . . . . . 482.2.3 La performance dans l'entreprise . . . . . . . . . . . . . . 502.2.4 Mesure, évaluation et appréciation de la performance . . . 512.2.5 L'élaboration du système d'indicateurs . . . . . . . . . . . 54

2.3 L'évaluation qualitative des indicateurs . . . . . . . . . . 572.3.1 Formalismes de l'évaluation subjective/qualitative . . . . . 572.3.2 Imprécision et incertitude dans l'évaluation qualitative . . 60

2.4 L'observation pour le suivi des activités . . . . . . . . . 612.4.1 Observation par l'analyse des traces des activités . . . . . 622.4.2 Déroulement d'un processus d'observation . . . . . . . . . 632.4.3 Démarches d'ingénierie des traces . . . . . . . . . . . . . . 64

2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

2.1 Introduction

Les entreprises auraient tendance à mener des stratégies préservant leurs parts demarché à "court terme", au détriment d'actions vitales aux niveaux de l'innovation,l'investissement, la maintenance ou de la motivation des hommes. Une telle politiqueinduira à terme un "gap" dans la compétitivité.

A�n de garantir une compétitivité durable et une performance globale [Lor95b],[Tro95], [Cha96], il convient plutôt pour les entreprises de renforcer leurs actions entermes de satisfaction des clients sur la base d'une démarche continue, englobant desaspects internes technologiques, organisationnels, sociaux, d'évaluations stratégiques, departenariat, ...

45

Chapitre 2. Construction des indicateurs de pilotage et Instrumentation

Du fait de la complexité de l'appréhension de la performance industrielle, la miseen place d'indicateurs de performance est un moyen essentiel qui revêt plusieurs aspectset remplit plusieurs fonctions. Ainsi parle-t-on tantôt d'indicateurs de processus ou derésultat, tantôt d'indicateurs de maîtrise ou de progrès, ... On utilise des indicateurs àdes niveaux tantôt locaux, tantôt globaux, ... Les indicateurs de performance s'inscriventdans une démarche d'amélioration continue.

En e�et, plus la détection d'une quelconque dérive se fera tard, plus elle ne seraqu'un constat ; plus les actions correctives nécessiteront des e�orts (techniques, humainset économiques), moins l'entreprise sera réactive et donc performante. Une manière di-recte d'augmenter la réactivité est une évaluation physique de ces événements, pour uneprise de décision au niveau même où l'information prend sa source, ce qui permet demettre en adéquation pilotage "local" et pilotage "global" [Ber97]. La mise en place desindicateurs permet de "surveiller" l'état des événements les plus critiques, et d'aider àestimer l'impact de l'occurrence d'un aléa quelconque sur les objectifs globaux.

Nous détaillons dans ce chapitre la notion de pilotage et de performance dans l'en-treprise industrielle. Nous mettons en lumière les di�érentes catégories d'indicateurs,puis nous faisons une distinction entre mesure, appréciation et évaluation. Ensuite, nousaborderons les techniques d'évaluation qualitative des indicateurs. Ce chapitre fait éga-lement l'objet d'une présentation des modèles d'observation pour le suivi des activitésmenées au sein du SIP. En e�et, de tels systèmes sont dotés de grandes capacités detraçabilité, et mettent à notre disposition plusieurs sources d'observation pour e�ectuerun suivi des activités.

2.2 Pilotage et Indicateurs de performance

2.2.1 Indicateurs de performance

Dé�nition

Un indicateur de performance est une donnée quanti�ée qui mesure l'e�cacité et/oul'e�cience de tout ou partie d'un processus ou d'un système (réel ou simulé), par rap-port à une norme, un plan ou un objectif, déterminé et accepté dans le cadre d'unestratégie d'entreprise [AFG92]. Cette donnée est éventuellement exprimée de manière àêtre évaluée par rapport à la globalité des objectifs du système ; appréciée au regard ducontexte de déroulement de l'activité ou processus ou système considéré.

Outre les aspects d'objectif, de mesure et de stratégie, cette dé�nition met en exerguel'aspect global de la performance (et non des optimisations locales), à travers les notionsde processus et de système, ce qui laisse imaginer l'existence d'indicateurs à di�érentsniveaux [AFG92].

L'indicateur n'est pas seulement qu'une simple mesure, mais un objet "complexe",regroupant :

� un objectif négocié, cohérent avec la stratégie d'entreprise ;� des variables d'action déterminantes, qui sont "des facteurs sur lesquels agissent un

ou plusieurs acteurs du système, a�n de faire évoluer tout ou partie d'un processusou d'un système vers les objectifs assignés" ;

46

2.2. Pilotage et Indicateurs de performance

� des moyens d'action, qui sont les éléments actifs pour la maîtrise de la performancedu processus ou système ; ils concernent par exemple les ressources (capacité, ...)les produits (complexité, ...) ;

� une mesure d'e�cacité, à laquelle une unité d'÷uvre est associée.On di�érencie par ailleurs les indicateurs simples de ceux complexes :� un indicateur est simple si une seule variable d'action lui est associée, telle que

l'indicateur de la "capabilité" d'une machine, dont la variable d'action est la ma-chine,

� un indicateur est complexe si plusieurs variables lui sont associées, telles que parexemple le taux de rebut ; la complexité est due d'une part à la multiplicité desvariables d'action, d'autre part aux corrélations éventuelles faisant qu'une variablepuisse favoriser un indicateur au détriment d'un autre.

Catégories d'indicateurs

On distingue deux catégories d'indicateurs, les indicateurs de résultats et les indica-teurs de processus [Ber97].

� Les indicateurs de résultats (IR) ont une vocation rétrospective ; ils sont as-sociés aux variables essentielles du système. Ils concernent tous les niveaux de lahiérarchie, sur les di�érents horizons temporels (du stratégique à l'opérationnel).Les IR touchent aux objectifs et recouvrent l'aspect du système lié aux états (pro-ductivité, ...). Ils en appellent de ce fait à la notion de véri�cation/contrôle. UnIR arrive trop tard pour l'action, ne permettant que de constater le degré d'at-teinte des objectifs. En cas de non performance, de tels indicateurs n'indiquent nila source des problèmes, ni les solutions à y apporter.

� Les indicateurs de processus (IP), dits également indicateurs d'action, in-diquent comment le processus évolue. Ils ont une vocation prospective et sontassociés aux variables d'action. Un IP est "un clignotant, appelant un acte déci-sif lorsqu'il s'allume, autrement dit lorsqu'un écart est enregistré entre la réalitémesurée et l'objectif". Recouvrant un aspect du système lié aux activités, les in-dicateurs de processus évaluent les résultats et/ou e�orts des interventions sur lescomposantes (structure et organisation) d'un système ou sous-système au niveaudes ressources, de ses processus et de leur pilotage, ainsi qu'à celui de ses produits,de manière à ce que sa performance se rapproche de celle attendue.

On di�érencie également les indicateurs de reporting et les indicateurs de pilotage.� Les indicateurs de reporting ou d'information servent à informer le niveau

hiérarchique du degré d'atteinte des objectifs. De tels indicateurs ne servent pasdirectement au pilotage. Ce sont toujours des indicateurs de résultat.

� Les indicateurs de pilotage servent au pilotage des activités. A usage essentiel-lement local, ils ne sont pas systématiquement agrégés. De tels indicateurs peuventêtre de processus ou de résultat. Ils sont de plus distingués selon la �nalisation del'information fournie par rapport à l'objectif du décideur. Ils peuvent être dans cesens liés à des actions dont les variables sont internes, auquel cas une action sur cesvariables est contrôlée ; comme il peuvent être liés à des actions dont les variablessont externes, mais sur lesquelles un suivi veut être maintenu. Les indicateurs sontdits dans ce cas latéraux ou de suivi.

47


Typologie des variables d'actions

La notion de variable d'action trouve un synonyme et un prédécesseur dans la no-tion d'inducteur de performance. Aussi, la typologie établie pour cette variable estfortement inspirée de celle de l'inducteur.

A la base de la performance d'une activité sont toujours un ou plusieurs facteurs in-�uents (facteurs explicatifs). Ces facteurs doivent générer des actions pour l'améliorationde la performance ; l'indicateur étant dans ce cadre l'élément qui mesure l'améliorationréalisée. Ainsi, les "inducteurs de performance" (performance drivers) - quali�és égale-ment de générateurs ou vecteurs de performance - d'une activité sont tous les facteurs quiin�uent signi�cativement sur une performance donnée. Cette notion fondamentale pourle diagnostic, permet de plus de regrouper les activités ayant des inducteurs communs.Les inducteurs retenus peuvent être choisis de plusieurs façons : éléments déclencheursde l'activité ou du processus, facteur de consommation des ressources, ...

En outre, la pertinence d'une variable d'action est évaluée en fonction d'un certainnombre de facteurs, tels que [CPr97] :

� la localisation (où agir),� les e�orts nécessaires qu'elle suscite en termes de ressources,� la qualité de réponse au regard de l'action (e�et de levier),� le temps de réponse entre l'action et le résultat (inertie),� la capacité à ne pas limiter l'atteinte des objectifs des autres processus (e�et per-

vers).Un "plan d'action" est mis en place dès lors que l'objectif est �xé et les variables

d'action sont identi�ées. Le plan d'action regroupe l'ensemble des opérations à menersur les variables d'action du processus, système ou activité considérés.

Les mesures fournies par les indicateurs ont un usage di�érent selon le pilotage initié.Les indicateurs peuvent avoir pour vocation de "surveiller-contrôler" la conformité etde mesurer les écarts par rapport à des normes préétablies, ou d'aider à choisir une actionde pilotage. La surveillance/contrôle concerne des domaines cernés où les rôles sont biendé�nis. L'action se situe à court terme, à partir de mesures directement exploitables. Ellea des �ns de régulation (souvent automatique) en cas de constatation d'écarts. Lorsqueles indicateurs ont pour vocation de "piloter-agir", les actions se situent sur les moyenet long termes, elles sont enclenchées par des indicateurs synthétiques (par exemple, laqualité des produits, le rendement d'une ressource) [Ber97].

2.2.2 Pilotage et maîtrise des dysfonctionnements

Souvent la notion de pilotage identi�e l'ensemble des actions "correctives" à menerlors de l'occurrence d'un événement. Dans ce sens, les modes de pilotage peuvent êtredéclinés selon un horizon temporel [Cou04], [Lor03].

� Le pilotage opérationnel est souvent la régulation d'un procédé ou processus - gé-néralement répétitif ou du moins bien connu - par rapport à une norme préétablie.Ni les objectifs ni les façons de faire ne sont remis en cause. On parle à ce niveaude "commande" (dépannage ponctuel suite à l'occurrence d'une panne machinepar exemple).

48


� Le pilotage tactique consiste en l'adaptation des ressources (techniques, humaines,�nancières et de temps) existantes au vu de l'état constaté. Les objectifs (exprimésen termes de quantité, coût, qualité et délai) ne sont pas remis en cause. On parleà ce niveau de "conduite". Des exemples caractéristiques d'adaptation sont laprogrammation d'heures supplémentaires, ou la programmation d'une maintenancepréventive suite à des pannes machines répétées.

� Le pilotage stratégique a pour rôle de veiller à corriger les éventuelles dérives auregard des objectifs stratégiques. Il identi�e notamment la restructuration de lagestion (parfois la re-ingénierie) lorsque celle-ci s'avère ine�cace.

Outre ces classi�cations hiérarchiques classiques, la commission IP (Indicateurs dePerformance) de l'AFGI20 décline le pilotage selon sa nature. Plutôt que de pilotage, onparle de "management de la performance", qui consiste en le déploiement transversal dela stratégie à tous les niveaux de l'entreprise. Autrement dit : "Tout système physiqueest traversé par un �ux de matière d'une part, et est activé par un système de pilotaged'autre part. Ce dernier reçoit des "signaux" du système physique, les traite au moyende modèles pour en obtenir des "images" dont la comparaison à des "objectifs" permet,face aux écarts, de prendre des décisions de réaction [...]. Ce mécanisme est décrit par desverbes relatifs aux ressources, aux produits et à leur synchronisation, déclinés à chacundes niveaux, qui eux sont caractérisés par leur horizon et leur période" [AFG92].

On peut dès lors distinguer deux natures di�érentes de pilotage :� le pilotage technique, qui a pour rôle de veiller au bon fonctionnement ainsi qu'à

l'amélioration des processus ; il intervient avec l'objectif d'éviter les dysfonction-nements, sans remettre en cause toutefois les objectifs assignés aux processus.

� le pilotage économique, qui oriente les moyens disponibles en vue de l'améliorationde la performance technique ; les recon�gurations des processus sont possibles à ceniveau.

La bonne évaluation des processus est conditionnée par l'occurrence d'événementsou de sollicitations internes (état des ressources, ...) ou externes (arrivée d'une nouvellecommande, ...), requérant des réactions di�érentes. Aussi, le concept de pilotage des pro-cessus est fortement associé à celui de la maîtrise et de la prévention de tels événements.Dans ce sens, deux types de sollicitations sont distingués [Cli04] :

� les événements prévus, dont l'occurrence répertoriée n'entraîne pas de remise encause des objectifs assignés et pour lesquels la réponse est connue, grâce à une�exibilité au niveau des ressources, la multiplicité des solutions, ...

� les aléas ou dysfonctionnements, menaçant l'atteinte des objectifs, dont la priseen charge nécessite des stratégies nouvelles, que ce soit pour en prévenir les e�ets(anticipation), pour retrouver le précédant fonctionnement (restauration) ou pourréviser les objectifs (dégradation).

La mise en place des indicateurs dans ce contexte permet de "surveiller" l'état desentités les plus critiques, et d'aider à estimer l'impact de l'occurrence d'un aléa ouévénement quelconque sur les objectifs globaux.

20Association Française de Gestion Industrielle

49


2.2.3 La performance dans l'entreprise

La performance : dé�nition et objectifs

La notion de performance s'est complexi�ée, dans le contexte actuel du monde éco-nomique, l'appréhension de la performance ne peut se limiter à une seule minimisationdes coûts et une augmentation du volume de production à moyens constants.

Elle nécessite une approche globale et multicritère qui se traduit par un déploie-ment à tous les niveaux de l'entreprise ; une réactivité accrue ; une prise en compte dela performance des processus mis en ÷uvre ; une mise en place "d'actions a�n de pro-mouvoir l'e�cacité de l'entreprise à court et long termes" (telles que l'amélioration dufonctionnement des processus, l'organisation du lancement de nouveaux produits, etc.).La stratégie d'une entreprise compétitive doit reposer en ce sens sur "la �exibilité, larapidité de réaction et la capacité d'anticipation" [Cli04].

La performance industrielle s'articule autour de trois objectifs [ECO96] :� le savoir-faire, qui analyse respectivement la relation entre produits/services et

clients, fournisseurs, moyens humains et techniques,� le savoir-gérer qui analyse les aspects organisationnel, humain, technique et �nan-

cier de la structure,� le savoir-vendre, qui informe de l'évolution de l'entreprise, du secteur d'activité,

des marchés et clients, des produits/services, de la concurrence.

Les di�érents niveaux de la performance

Les auteurs dans [JMG96] voient en la performance "globale" un concept fédérateurqui souligne que "tout se tient (technologie, organisation, recherche, marché, formation,�nancement, etc.)". En outre selon l'horizon sur lequel elle porte, la performance prenddes sens di�érents et concerne des variables di�érentes. Au niveau opérationnel, parexemple, la performance identi�e l'e�cacité, au sens de la meilleure utilisation possibleou productivité des ressources. A un niveau tactique, cette performance est élargie àl'ensemble des services périphériques à la production. Elle est abordée dans ce sens àl'aide d'une approche par processus.

La performance est appréhendée à travers la satisfaction d'un système d'objectifsinduits par les stratégies adoptées. La problématique aujourd'hui est d'arriver à un"bon" compromis entre les di�érents objectifs, à l'aide d'une appréhension globale, quiéviterait de se focaliser sur un objectif au détriment d'autres (réduire les coûts et négligerla qualité ou le service par exemple) [Ber97].

Une dé�nition classique du système d'objectifs se rattache souvent à une déclinaisonselon les horizons stratégique, tactique et opérationnel [Gal90], [Gia88] :

� les objectifs stratégiques concernent l'évolution de l'entreprise, ses orientations,son positionnement dans son environnement,

� les objectifs tactiques concernent la préparation des activités industrielles en dé-ployant la performance par processus,

� les objectifs opérationnels sont liés à l'activation des ressources et des processusopérants.

50


2.2.4 Mesure, évaluation et appréciation de la performance

Un pilotage multicritère, ayant pour vocation l'anticipation des dysfonctionnements,repose sur un certain nombre de notions telles que [Lor03] :

� la �xation des objectifs ainsi que leur déclinaison en "sous-objectifs",� la détermination des variables qui permettent d'agir sur le système,� la mesure des écarts puis leur appréciation - en vue d'une réaction - en fonction :

des tendances d'évolution, des objectifs, du contexte, des actions éventuellementen cours.

La performance atteinte est ainsi renseignée par les mesures de réalisation des ob-jectifs.

Mode d'élaboration de la mesure

La mesure est élaborée en général à partir d'une des procédures suivantes.� La mesure est directe - dite physique ou technique - souvent issue de "capteurs"

au niveau du processus physique, telle que par exemple la mesure chronométréed'un temps de changement d'outil.

� La mesure est obtenue en utilisant des opérations mathématiques simples (mo-nocritère) sur des mesures physiques élémentaires, exprimées en unités d'÷uvrehomogènes. Ces opérations consistent en général en des comptages, des contrôlesdimensionnels, ..., ou en combinaison mutlicritère de mesures rattachées à desfacteurs hétérogènes.

� Un autre mode d'élaboration de la mesure consiste plus généralement en une "col-lecte de données", par exemple par rapport à une mesure de satisfaction des clients.Une telle mesure est renseignée à partir de questionnaires et d'enquêtes, puis syn-thétisée grâce à des outils statistiques (échantillonnage, modélisation, tests de nor-malité) [CG92].

La mesure obtenue peut être objective ou subjective, selon la nature des mesures quiinterviennent dans son élaboration d'une part et le mode de cette élaboration d'une autrepart. De plus, les mesures peuvent être "attributs" ou "variables". Les mesures attributssont déterminées à partir de questions à réponses fermées (oui/non, bon/mauvais, ...),alors que les mesures variables impliquent un relevé. Les mesures attributs sont souventutilisées pour des variables qui sont maîtrisées, ou sur lesquelles une fonctionnalité desuivi est exercée, tandis que les mesures variables sont celles réellement utilisées pour lepilotage [Ber97].

Au vu de la dé�nition et du rôle de l'indicateur, la mesure retournée par l'indicateurdoit re�éter l'état réel, comparé à un état espéré (objectif), c'est-à-dire que l'indicateurdoit retourner une mesure de performance.

Fréquence de la mesure de performance

Le choix de la fréquence dans les prises de mesure est lié aux processus considérés,aux objectifs assignés, aux possibilités d'amélioration suite à ces mesures [Ber97].

� La prise de mesure se fait dès l'apparition de l'événement (par exemple l'atteinted'un seuil d'alerte). Elle est renseignée par des capteurs physiques et correspond

51


généralement à la valeur d'une variable d'état du processus physique. Dans ce cas,l'objectif est en général lié aux consignes opératoires (par exemple, éviter toutralentissement ou blocage), ses variables d'action sont souvent des actionneursphysiques. C'est le cas des mesures événementielles. Les événements peuvent cor-respondre également à la �n de l'exécution des activités, et ce, pour estimer lesperformances atteintes.

� La prise de mesure se fait par échantillonnage, sur une durée correspondant auniveau décisionnel considéré. C'est le cas des mesures périodiques (dites égalementde �abilité).

� La prise de mesure est continue, le long du déroulement de l'activité analysée. C'estle cas notamment des processus continus dans lesquels l'exécution des activités estconditionnée par l'atteinte des objectifs.

Outre le mode d'élaboration et la fréquence caractérisant la mesure, il est un aspectnon moins important rattaché à la validité. En e�et, les mesures prises peuvent êtreentachées d'erreurs. Du moment que ces mesures représentent l'exécution de l'activitéou processus analysés, elles sont à l'origine des actions de pilotage menées. Aussi, de lavalidité de ces mesures dépend la validité de la mesure de performance et dépend, enpartie, l'adéquation du pilotage avec le contexte.

De la mesure à l'évaluation

Évaluer c'est assigner une valeur bonne ou mauvaise, meilleure ou pire, à une choseou à un événement. Ce n'est donc pas simplement mesurer la valeur en quelque sorteintrinsèque des objets. C'est établir un ordre de préférences [Jac90].

Prenons un exemple de la vie courante. Si un footballeur a pour objectif de mar-quer 10 buts lors d'une saison donnée, et qu'il n'en marque que 8, intuitivement, saperformance peut être dé�nie par le rapport 8/10, soit 80%. Selon le score des autresfootballeurs, il est en outre jugé (évalué) plus ou moins bon ou mauvais. Dans ce cas,8 est la mesure physique, 80% la mesure de la performance et, par exemple, bonnel'évaluation.

L'évaluation d'un ensemble d'indicateurs implique la mesure de leur écarts par rap-port à l'ensemble correspondant de valeurs de référence mais aussi un jugement ducaractère plus ou moins acceptable des écarts [Gia90]. Dans ce sens, à l'instar de M.Buitton [Bit90], de L. Najar [NBM94] et de O. Cérutti [CG92], une distinction fonda-mentale est à faire, lors de l'appréhension de la performance, entre la notion de mesureet la notion d'évaluation.

Fournissant simplement une information locale, la notion de mesure est trop réduc-trice. L'évaluation vient l'enrichir, pour en donner une interprétation par rapport à unevision globale ou cadre de référence. Le cadre de référence est obtenu à l'issue d'une ana-lyse stratégique de l'entreprise. Il �xe et pondère les di�érents critères qui constituentla performance globale. Exemple : Dans une stratégie de renforcement de la politiquede lancement de nouveaux produits, la tension des �ux n'aura pas la même importance,selon qu'il s'agisse des produits nouveaux ou des produits usuels.

La notion d'évaluation aborde des aspects de coordination et de cohérence entreindicateurs, ainsi que d'exploitation e�ective des indicateurs. Dans ce contexte, "la per-

52


tinence d'une évaluation" tient bien plus à la qualité de l'interprétation qu'à l'exactitudeet à la précision des calculs [LLS96].

Quelles sont les étapes implicites à cette évaluation de la performance ? L'évaluationprise dans un sens large [Ber97], peut sous-entendre :

� Une étape d'expression homogène des mesures de performance à évaluer : à unniveau opérationnel (local), de simples mesures techniques sont su�santes à uneanalyse des performances, telles qu'un temps de réponse, ... A un niveau tac-tique par exemple, on doit comparer, à partir des tableaux de bord, des qualitésphysiques entre elles. Pour pouvoir les comparer, ces données doivent être natu-rellement exprimées de manière homogène.

� Une étape d'interprétation (ou de comparaison) de ces expressions les unes parrapport aux autres, conformément aux critères donnés par le cadre de référence.

� une étape d'agrégation éventuelle des di�érentes données.Que ce soit dans un souci d'agrégation ou d'interprétation, les performances ne sont

pas toutes de la même nature. Il serait impossible d'ajouter par exemple des fréquences àdes heures. C'est pourquoi la notion d'évaluation appelle implicitement à la mise sur unréférentiel commun de l'ensemble des performances re�étant la réalisation des objectifs.

En outre, une fois les performances retournées par les indicateurs, une analyse préa-lable de ces performances est opportune pour l'aide à la prise de décisions. Dans cecontexte, le passage du modèle de contrôle au modèle de pilotage appelle à un bascule-ment corollaire : de la mesure à l'appréciation (ou interprétation) [Lor95a].

... et de la mesure à l'appréciation

Reconsidérons à nouveau l'exemple du footballeur. Une performance de 80% peutêtre évaluée comme étant bonne au regard du score des autres footballeurs. Elle peut êtrenéanmoins appréciée en fonction de critères autres que l'objectif, tels que par exemplela condition physique des sportifs, les conditions météorologiques, le type de terrainréservé...

Inscrit dans une boucle de réaction, l'indicateur doit fournir des éléments d'informa-tion alimentant cette réaction, c'est-à-dire une appréciation ou un diagnostic préalablesaux prises de décision. Or, seule, la mesure ne peut su�re à l'élaboration d'un diag-nostic pertinent. Elle doit être complétée par une appréciation qui prend en compte lecontexte, du moment que "le pilotage ne peut espérer agir sur l'action qu'indirectement,en agissant sur l'interprétation [...]. Piloter c'est agir sur des interprétations ; in�uencerdes interprétations" [Lor95a].

En outre, le pilotage, sous sa facette "choix des actions à entreprendre pour optimiserla combinaison d'éléments techniques, économiques et humains" est fortement lié à laqualité et à la pertinence des décisions prises par les acteurs. Dans ce sens, P. Lorinoparle de contrôle "�ou", au vu des incertitudes rattachées désormais à ce contrôle, desinterprétations qu'il nécessite, reposant sur l'expérience des acteurs, leur savoir-faire,leur position ainsi que d'autres grandeurs plus subjectives.

Considérons un exemple d'illustration en industrie : un retard dans une production,dû à des événements exceptionnels (de type inondation, grève du personnel ou autre im-

53


pondérable). Dès lors, il n'est pas fondé de se baser sur la mesure sans considérer cet aléa.Dans ce cas, les actions à mener ne doivent pas porter sur le processus de fabrication,mais sur une adaptation des ressources en vue de rattraper cette non performance. Ajou-ter à ceci que le diagnostic peut varier d'un observateur à un autre : un premier prônerala programmation d'heures supplémentaires, un autre jugera la commande su�samment�exible pour remplacer les produits manquants par d'autres en stock, ... [Ber97]. Si l'onconsidère le cas d'une panne machine juste à temps, sa maîtrise peut relever de stratégiesdi�érentes : tel acteur privilégiera une action à court terme, qui consistera à pallier auplus vite à la panne, sans se préoccuper outre mesure des normes de qualité, ... Uneautre attitude consistera en l'arrêt de l'installation, en vue de s'interroger sur la �abilitédes équipements (voire même une organisation en �ux tendus), pour une éradication àlong terme d'un tel type de panne.

Le contrôle "�ou" nous amène à aborder l'évaluation qualitative des indicateurs. Lasection suivante sera dédiée à ce sujet.

2.2.5 L'élaboration du système d'indicateurs

La construction d'un système d'indicateurs se base sur la dé�nition d'une stratégiedéployée sous forme d'objectifs à atteindre. Cette étape donne lieu à l'identi�cation desprocessus et des activités-clé que l'on doit améliorer dans le cadre des objectifs recherchés.A partir de là, on recherche les inducteurs de performance, c'est-à-dire les éléments ayantune in�uence sur la performance de l'activité que l'on a choisie de traiter. Tous cesinducteurs ne vont pas forcément permettre le développement d'actions. Il faudrait doncdé�nir des variables d'action pour mettre au point les plans d'action retenus. Le choixdes indicateurs aura lieu à ce moment-là. Ils serviront à valider la démarche et assurerà la fois la mesure des résultats du plan d'action et la dynamique de progrès.

Il est à noter que les inducteurs que l'on vient d'évoquer ne vont pas tous pouvoirse transformer en variables d'action. Par ailleurs, en ne retenant que les éléments surlesquels on peut agir, on va e�ectuer des choix au niveau du plan d'action.

Par ailleurs, le lien de l'indicateur avec l'objectif se fait donc à travers un doubleprocessus d'interprétation par les acteurs, résumé par les deux questions suivantes :

� pour atteindre cet objectif, quelle(s) action(s) faut-il engager (interprétation causes-e�et) ?

� Pour évaluer le déroulement ou le résultat de cette action, quelle information faut-ilutiliser (interprétation mesure) ?

Le premier type d'interprétation s'appuie sur un modèle cause-e�ets, que certainsacteurs appellent � théorie de l'action �, du type � Si nous faisons cela, nous obtenonscela, nous obtenons tel type de résultat ; pour obtenir tel type de résultat, nous devonsfaire cela �.

L'indicateur est donc étroitement lié à une connaissance collective de l'action : il fautune certaine connaissance de l'action et de ses e�ets pour le construire, mais, une foisen place, il doit contribuer à faire évoluer cette connaissance. Il constitue une base d'ap-prentissage sur les enchaînements causes-e�et de l'action. Les modalités selon lesquellesl'indicateur va alimenter la dynamique d'apprentissage collectif sur les actions et leurs ef-fets sont multiples, mais c'est là sa principale fonction : fournir une base d'apprentissage

54


sur les enchaînements causes-e�et de l'action [BC01].

Fig. 2.1 � Processus de construction du système d'indicateurs. Source [BC01]

Fig. 2.2 � L'indicateur de pilotage et la dynamique d'apprentissage. Source [BC01]

Le système d'indicateurs devrait logiquement être l'image d'un modèle causes-e�etportant sur l'action.

Causes-e�et IndicateursA partir des objectifs poursuivis, Indicateurs de résultats globaux/�-

nauxon tentera de répondre plusieurs fois de la suiteà la question pourquoi ?,

Indicateurs de résultats intermé-diaires

jusqu'à identi�er les leviers sur lesquels on sou-haite agir,

Indicateurs de résultats intermé-diaires

et dé�nir des plans d'action. Indicateurs de pilotage.

Tab. 2.1 � Principe d'un raisonnement causes-e�et et indicateurs correspondants

55


Fig. 2.3 � Une structure causes-e�ets

Fig. 2.4 � Systèmes d'indicateurs correspondant à la structure causes-e�ets

Le modèle causes-e�ets est arborescent et fonde une structure d'indicateurs elle-même arborescente : un e�et peut avoir plusieurs causes, bien identi�ables, selon desniveaux successifs de causalité qui nous éloignent de l'objectif visé (lien de plus en plusindirect) mais nous rapprochent des potentiels d'action pertinents (agir sur les causesen amont et non sur des symptômes intermédiaires).

Cependant, dans un grand nombre de cas, chaque fois que le problème posé parl'objectif étudié est complexe, mal structuré, interagissant fortement avec un environne-ment incertain, une telle structure arborescente des causes et des e�ets est impossibleà construire. Tout d'abord, la relation causes-e�ets devient mal déterminé, non linéaire,plus proche d'interactions en boucle, avec des niveaux variables de corrélation entre lesphénomènes [MDGL02]. Ensuite, parce que des facteurs génériques peuvent in�uencersigni�cativement sur plusieurs objectifs simultanément, et parfois de manière contradic-toire. Un même facteur peut in�uer de manière très directe sur un objectif (cause deniveau 1 ou 2) et de manière très indirecte et peu mesurable sur un autre (cause deniveau n, avec n>=1). Par exemple, accroître la productivité de l'accueil téléphoniquepeut conduire à en détériorer le contenu informationnel. Mais l'accroissement de com-pétence des agents chargés de l'accueil devrait agir positivement sur la productivité etsur le contenu informationnel.

D'autres structures d'analyse plus �oues et plus souples peuvent être appliquées ; detype � nuages de facteurs �, � zones d'in�uence �, ou encore � diagrammes d'a�nités�. Dans de telles structures, on identi�e des facteurs ayant une in�uence sur le jeud'objectifs (pris dans sa globalité), en les ordonnant selon l'in�uence plus ou moinsdirecte ou plus ou moins hypothétique qu'ils exercent sur les objectifs. On ne cherchepas à a�ecter directement et systématiquement causes et leviers d'action à tel ou telobjectif, mais on peut essayer de regrouper les leviers d'action et, donc, les indicateurs

56

2.3. L'évaluation qualitative des indicateurs

de pilotage selon des zones d'a�nités plus ou moins forte avec tel ou tel objectif (parexemple, regrouper les leviers d'action � in�uant plutôt sur la qualité du service au client� ou � in�uant plutôt sur le délai de développement des nouveaux produits �, etc.). Cesregroupements ne sont ni rigides, ni tranchés, la disposition en nuages avec des distancesmesurant des degrés d'a�nité permet de rendre compte de la complexité des liens.

2.3 L'évaluation qualitative des indicateurs

L'information est élaborée à partir de l'exécution de l'activité ou de l'évolution duprocessus. Cette élaboration induit deux étapes successives :

� une étape de prise de mesure e�ectuée, qui retourne ce que nous appelons la mesure(physique) brute ;

� une étape d'élaboration de l'information suite à des traitements éventuels de lamesure, de manière à obtenir une grandeur exprimée en cohérence avec l'universde discours de l'objectif.

Il est des cas où les informations recherchées ne correspondent pas à des grandeursphysiques dé�nies sur des univers numériques, mais à des grandeurs faisant appel àdes concept plus abstraits, tels que l'esthétique d'un produit par exemple. Le recours àdes "capteurs humains" (opérateurs), fréquent dans les procédures de contrôle qualité,s'avère alors utile [MBF96]. Généralement, un opérateur fournit, de manière plus �able,une caractérisation linguistique de sa perception plutôt qu'une caractérisation numérique[OUB+96]. Une caractérisation linguistique est plus qualitative, mais elle a le mérite dereprésenter la globalité du phénomène observé [MBMG95]. Notons qu'il est d'autres casoù le recours à des capteurs humains se justi�e également, dès lors que des estimationsapproximatives sont su�santes, ou pour suppléer un capteur physique défaillant parexemple. Les estimations "humaines" peuvent de ce fait être également numériques.

L'expression de l'objectif peut être plus ou moins �exible ou nuancée, dé�nie pardes concepts dont on cerne mal les limites. Elle peut être également linguistique. De cefait, une représentation numérique nette ne peut toujours su�re à décrire l'expressionde l'objectif. Un objectif doit pouvoir être exprimé par une valeur ou un ensemble devaleurs numériques, un mot ou un ensemble de mots. Il s'agit par conséquent d'utiliserun formalisme à même de prendre en compte, de manière homogène, l'expression ainsique la �exibilité ou nuance souhaitées pour l'objectif, quel que soit le type de l'universde discours. Une solution nous est o�erte par la logique �oue.

2.3.1 Formalismes de l'évaluation subjective/qualitative

La logique �oue est basée sur des formalismes mathématiques assez développés dé-passant le cadre de cette section. Nous nous limiterons ici à présenter le principe intuitifet les principaux formalismes de la logique �oue que nous pourrons utiliser dans notretravail. La logique �oue permet par ses propriétés d'intégrer les aspects subjectifs etincertains associés au jugement de l'expert humain, son raisonnement, ainsi qu'à sesappréciations de l'environnement qui l'entoure. Elle permet par ce fait, de modéliserl'incertitude et les imprécisions dans la connaissance.

La logique �oue s'appuie sur la théorie des sous-ensembles �ous. Cette théorie, in-

57


troduite par L.A Zadeh, est une extension de la théorie des ensembles classiques pourla prise en compte d'ensembles dé�nis de façon imprécise. La notion de sous-ensemble�ou illustre les idées d'appartenance partielle à une classe aux limites mal dé�nies,de passage graduel d'une classe à une autre.

La théorie des sous-ensembles �ous o�re ainsi une représentation mathématique del'imperfection des connaissances : imprécises, incomplètes, vagues, incertaines, ... expri-mées notamment en langage naturel (avec des mots). En ce qui concerne l'incertain, ila été abordé par la théorie des possibilités, basée sur un formalisme proche de celui dessous-ensembles �ous. Cependant, cette théorie ne permet pas de traiter des croyancessubjectives, ni de résoudre le problème posé par les connaissances imprécises ou vagues.

À l'inverse de la logique booléenne, la théorie des sous-ensembles �ous permet à unecondition d'être en un autre état que vrai ou faux. Il y a des degrés dans la véri�cationd'une condition. Il s'agit d'une approche essentiellement pragmatique, e�cace et géné-rique. Elle permet de transcrire les connaissances. Le fonctionnement doit être décrit pardes quali�catifs globaux traduisant l'état approximatif des variables.

La logique �oue est l'outil le plus utilisé dans les travaux s'attachant à un traitementqualitatif des données plutôt que quantitatif. Elle permet de manipuler des ensembles dedonnées que l'on souhaite dé�nir selon des classes ou des catégories. La notion manipuléeest graduelle (�oue). Elle permet également de prendre en compte plusieurs variables ete�ectuer de la � fusion pondérée � des grandeurs d'in�uence. En e�et, son principalobjectif est de pouvoir modéliser, imiter et simuler les fonctionnalités du raisonnementhumain dans des situations incertaines ou imprécises.

Concepts théoriques de la logique �oue

Dans la théorie classique des ensembles, dans un référentiel donné, un élément appar-tient ou n'appartient pas à un ensemble donné. Si on considère alors le degré d'apparte-nance d'un élément à un ensemble il sera égal à 1 si cet élément appartient à l'ensembleconsidéré et égal à 0 s'il n'y appartient pas. Dans la théorie des ensembles fous un élémentpeut appartenir complètement à un ensemble (degré d'appartenance de 1) mais il peutaussi 'presque' y appartenir : il possèdera par exemple un degré d'appartenance de 0,9.Cette approche conduit à construire une fonction d'appartenance et à partir de celle-ci dedé�nir un sous-ensemble �ou. Il est tout à fait possible de construire plusieurs fonctionsd'appartenance ; ainsi un élément donné peut appartenir à di�érents sous-ensembles �ousavec des degrés d'appartenance di�érents pour chaque sous-ensemble.

Notions de base

Fonction d'appartenance : Fonction µ(x) qui à toute valeur d'entrée x fait corres-pondre son degré d'appartenance à l'ensemble A. Cette valeur graduelle est compriseentre 0 et 1.

Degré d'appartenance : Un élément x appartient à un ensemble �ou A avec un degréd'appartenance compris entre 0 et 1, donné par la fonction d'appartenance µ(x).

Conclusion : Une conclusion de règle est une proposition associant une variable lin-guistique et un terme linguistique, écrite après le "alors" de la règle. Une conclusion

58

2.3. L'évaluation qualitative des indicateurs

peut être formée par la combinaison de plusieurs propositions. Les règles �oues sont re-présentées via des combinaisons logiques de notions �oues avec des opérateurs logiques�ous (ie. Faire des calculs sur des degrés de vérité).

Degré de vérité : Le degré de vérité, ou encore degré d'activation, d'une règle prendune valeur "Y" comprise entre 0 et 1 déduite des degrés d'appartenance des prédicatsde la règle. Il in�ue directement sur la valeur des conclusions de cette même règle. Ondit aussi que la règle est active à "Y".

Fuzzi�cation : Transformation d'une valeur numérique en degré d'appartenance �oupar évaluation d'une fonction d'appartenance.

Inférence : Cycle de calcul des degrés d'activation de toutes les règles de la base ainsique de tous les ensembles �ous des variables linguistiques se trouvant dans les conclusionsde ces règles.

Défuzzi�cation : Transformation, après inférence, d'un ensemble �ou d'une variablelinguistique de sortie en valeur numérique.

Prédicat : Appelé encore prémisse ou condition, un prédicat de règle est une pro-position, associant une variable linguistique et un terme linguistique, écrite entre le siet le alors de la règle. Un prédicat peut être formé par la combinaison de plusieurspropositions.

Terme linguistique : Terme associé à une fonction d'appartenance caractérisant unevariable linguistique.

Variable linguistique : Variable numérique appliquée en entrée, pour fuzzi�cation, ouen sortie, après défuzzi�cation, d'un module de logique �oue. On lui attribue l'adjectiflinguistique car elle est utilisée, dans les fonctions d'appartenance et les règles, par sonnom et non pas par une valeur numérique.

La base des règles �oues

L'outil le plus utilisé dans les applications de logique �oue est la base de règles�oues. Une base de règles �oues est composée de règles qui sont généralement utiliséesen parallèle, mais peuvent également être enchaînées dans certaines applications.

Une règle est composée d'un prédicat et d'une conclusion. Un prédicat (de mêmepour une conclusion) est une combinaison de propositions par des opérateurs.

Il existe de nombreuses variantes dans ces opérateurs. Les plus répandus sont ceuxdites "de Zadeh" : Intersection, Union, Complément, Ladder �ou. . . Les opérateurs �ous(ou fuzzy) peuvent être implémentés de diverses manières et une même application peutd'ailleurs faire appel à des implémentations di�érentes judicieusement choisies selon lecontexte.

La procédure de génération des règles �oues est la suivante :1. Variables et termes linguistiques

(a) Dé�nition des variables : entrées, sorties(b) Dé�nition des fonctions d'appartenance

2. Règles et résultats

59


(a) Écriture des règles �oues(b) Application de la Fuzzi�cation(c) Application de l'Inférence(d) Application de la Défuzzi�cation

Quand peut-on utiliser les bases de règles �oues ?

Le choix des bases de règles �oues pour résoudre un problème applicatif peut êtrefait quand les conditions suivantes sont réunies [BMM03] :

� possibilité d'agir sur le procédé (contrôlabilité),� existence d'une expertise ou d'un savoir-faire,� possibilité de mesurer ou d'observer des grandeurs importantes (entrées et sorties),� expertise qualitative (si elle est mathématique, l'automatique classique est à favo-

riser),� expertise graduelle (si elle est booléenne, les systèmes experts sont plus adaptés).

2.3.2 Imprécision et incertitude dans l'évaluation qualitative

Les connaissances dont nous disposons sur une situation quelconque sont générale-ment imparfaites, soit parce que nous avons un doute de leur validité, elles sont alorsincertaines, soit parce que nous éprouvons une di�culté à les exprimer clairement, ellessont alors imprécises.

La mesure (et l'information) dans les processus peut être entachée d'erreurs, enraison de sa source (caractéristiques des capteurs), de la nature de la variable considérée,du contexte de prise de mesure, ... Dans ce qui suit, nous présentons une descriptionsynthétique des approches probabilistes et possibilistes au sujet du traitement de ceserreurs.

Approches probabilistes et possibilistes

Une "erreur de mesure" représente l'écart entre la valeur mesurée et la valeur vraie.Pour prendre en compte ces erreurs, généralement soit une précision soit une incertitudeest associée aux mesures. La précision délimite l'intervalle autour de la valeur mesurée,à l'intérieur duquel on est assuré de trouver la valeur vraie. L'incertitude se rattacheà l'incapacité de dire si un énoncé est vrai ou faux (du fait d'un manque d'informa-tion). Elle peut être caractérisée par un degré de vérité de la valeur mesurée. Ces deuxparamètres sont estimés à partir de procédures conventionnelles ainsi que d'hypothèsesprévisionnelles.

L'incertitude est appréhendée d'un point de vue probabiliste, à l'aide de lois clas-siques (normale, binomiale, uniforme, Poisson, ...). Dans le cas où le phénomène observéest caractérisé par le regroupement de n observations précises (et indépendantes), leprincipe usuel consiste en l'établissement d'un histogramme, ainsi que le calcul de para-mètres tels que la moyenne, la variance, ... de manière à identi�er une loi de distributionde probabilités.

60

2.4. L'observation pour le suivi des activités

Le principe du calcul d'erreurs consiste à attacher un intervalle à la mesure. Dece fait, il prend en compte l'imprécision et non l'incertitude. Si l'intervalle choisi pourmodéliser l'erreur est étroit, il ne sera pas sûr. Si en revanche, il est pris large, la certitudes'acquiert au détriment de la précision. Quant aux probabilités, rappelons qu'un bonusage nécessite des conditions pas toujours remplies (observation de la variable sur unetaille d'échantillons signi�cative, mesures disjointes et précises, connaissances des lois,...). En un mot, dès lors qu'une information est à la fois imprécise et incertaine, le cadreproposé par ces approches est peu adapté. Une solution est fournie par une utilisationparticulière de la notion de sous-ensemble �ou : la théorie des possibilités.

La théorie des possibilités a été introduite a�n de permettre la prise en comptecombinée à la fois de l'imprécision et de l'incertitude dans des connaissances.

Plutôt que de caractériser l'incertitude relative à un événement A par un degré deprobabilité, la théorie des possibilités propose de caractériser cette incertitude par deuxdegrés : le degré de nécessité et le degré de possibilité de A [DP87].

Les approches probabilistes et possibilistes ne sont pas antagonistes. Ce sont deuxapproches complémentaires pour le traitement de l'incertitude. La première adaptée auxobservations précises et di�érenciées tandis que la seconde est adaptée aux observationsimprécises mais concordantes. Du reste, ces deux théories sont des cas particuliers d'unethéorie plus générale dite théorie de l'évidence [Sha76].

On �nira par préciser qu'une connaissance �oue n'est généralement pas une connais-sance "incertaine" et n'est donc pas reliée à une probabilité. Le �ou est lié à la formede la connaissance : son imprécision donc, et n'est donc pas de nature probabiliste. Parexemple, dire "l'âge de cette personne est autour de 30 ans" ne présume en rien dela probabilité de l'âge e�ectif de la personne. On peut mieux voir la distinction entreimprécision et probabilité en pondérant cette assertion : "je suis sûr que l'âge de cettepersonne est autour de 30 ans" où l'on peut retrouver ici à la fois une imprécision (surla valeur de l'âge) et une certitude (sur le fait que cet âge soit autour de 30 ans). Ouaussi : "l'âge de cette personne est autour de 30 ans, avec une probabilité de 0.2" oùl'on retrouve encore une connaissance �oue ("autour de 30 ans") qui est relativisée parune probabilité de véracité.

2.4 L'observation pour le suivi des activités

L'observation de l'activité tracée constitue une approche originale pour la quêted'information. L'observation des activités est une technique très utilisée dans le cadre desenvironnements informatiques pour l'apprentissage humain (EIAH). Les environnementsEIAH ont pour objectifs de favoriser ou susciter des apprentissages, de les accompagneret de les valider. La recherche dans ce domaine est née avec l'informatique mais sesont surtout développées dans le sillage de l'intelligence arti�cielle dans les années 70.Le terme EIAH est né dans les années 90, avec le souhait de souligner l'interactionentre les deux pôles source de la complexité du projet technologique et scienti�que :l'informatique (avec la modélisation computationnelle qu'elle exige et son inscriptionmatérielle) et l'apprentissage humain (pour lequel on ne dispose encore que de modèlestrès partiels). La recherche sur les EIAH est fondamentalement pluridisciplinaire, enappelant à la coopération de di�érents secteurs de l'informatique (génie logiciel, réseau,

61


la modélisation des connaissances et des interactions, etc.), et des sciences de l'hommeet de la société (psychologie, didactique, ergonomie, sciences du langage, sciences de lacommunication, etc.). L'ingénierie des traces a connu une évolution dans le cadre desrecherches dans le domaine des EIAH (Projet LISTEN [Cho07]). La trace se situe au-delàde la problématique de la personnalisation par le pro�l. Elle renvoie plutôt à l'émergenceet à la gestion personnelle des connaissances. Il ne s'agit pas de se contenter d'analyser lesjournaux produits par le système d'information (les logs), mais de partager réellementl'expérience d'utilisation du système. Tandis que les journaux systèmes s'adressent àl'expert, la trace d'utilisation provient de l'activité ; elle est directement accessible àl'utilisateur qui peut en faire de multiples usages. L'objectif est d'observer et analyserl'activité de l'utilisateur a�n de mieux comprendre son comportement.

Nous présentons dans cette section les travaux dans le domaine de l'ingénierie des tracesqui nous semblent transposables à notre problématique.

2.4.1 Observation par l'analyse des traces des activités

L'observation sert à établir un état des lieux des pratiques dans l'objectif d'une régu-lation de l'activité. Dans ce cas, l'observation joue ce rôle de prise d'informations utilespour le déroulement adapté de la suite de l'activité collaborative. L'observation produitune grande quantité d'informations utiles. La qualité des activités peut être évaluée se-lon une approche PDCA (Plan-Do-Check-Act). Cette approche comporte quatre étapes,chacune entraînant l'autre, et vise à établir un cercle vertueux [Bar94]. Sa mise en placedoit permettre d'améliorer sans cesse la qualité d'un produit, d'une ÷uvre, d'un service...

� Plan : Préparer, Plani�er (ce que l'on va réaliser)� Do : Développer, réaliser, mettre en ÷uvre (le plus souvent, on commence par une

phase de test)� Check : Contrôler, véri�er� Act (ou Adjust) : Agir, ajuster, réagir (si on a testé à l'étape "Do", on déploie lors

de la phase "Act")L'idée dans une démarche d'observation est notamment de modi�er et d'enrichir le

scénario dans lequel certaines activités sont, par exemple, systématiquement rajoutéesou supprimées par les utilisateurs.

Les approches pour mener à bien cette observation sont multiples : techniques qua-litatives d'interviews ou de questionnaires à l'issue de l'utilisation des plates-formes,des observations en présentiel ; techniques quantitatives basées notamment sur l'analysedu serveur (logs, bases de données, serveur d'application), du poste client (interactionshomme-machine), des enregistrements video ou audio, etc.

Concernant les techniques quantitatives, une analyse des di�érentes sources d'obser-vations a posteriori est nécessaire pour identi�er les di�érentes données participant àl'activité à gérer. Ainsi, chacune des sources nécessite une instrumentation particulièrea�n d'aider à l'interprétation de données collectées/recueillies.

Dans un environnement d'apprentissage autour d'une plate-forme collaborative no-tamment, une bonne compréhension du comportement de l'utilisateur peut apporterplusieurs avantages. Du coté concepteur de logiciel, cette approche permet d'améliorer

62


la conception (ou la re-conception) du logiciel par rapport aux besoins de l'utilisateur[CC04]. Du coté utilisateur, il est possible d'obtenir plus d'aide pour l'activité en courspar l'amélioration des approches d'assistance en ligne [Zai02]. En�n, du coté analystele retour obtenu par l'analyse peut conduire à la remise en cause et à l'adaptation d'unscénario observé [MHCF04].

2.4.2 Déroulement d'un processus d'observation

Les sources d'observation, les �chiers logs en l'occurrence, contiennent l'ensembledes actions e�ectuées sur le serveur de la plate-forme en question. Les éléments observésne sont pas directement exploitables. Plusieurs travaux de recherche sont actuellementorientés vers les phases de prétraitement des traces enregistrées dans les �chiers de log[CMS99], [MHCF04], [TT04]. La quantité des traces collectées est généralement énormeet les traces très détaillées (la représentation numérique contient des paramètres detrès bas niveau), ce qui rend le processus d'interprétation di�cile du côté de l'analyste.Plusieurs méthodes caractérisant le processus d'observation peuvent être utilisées pourréduire le grand volume des traces : le nettoyage, le �ltrage et la généralisation des traces[Log06].

1. Phase de collecte : A�n d'analyser le comportement de l'utilisateur nous avons be-soin de collecter des traces par rapport à l'activité en cours. Cette phase consiste àcollecter l'ensemble de toutes les traces enregistrables aussi appelées observables.On remarquera que ces traces peuvent provenir de sources di�érentes, qu'ellespeuvent être de di�érents types (formats de texte, images, . . .) et qu'elles ne sontpas forcément du même niveau de granularité. Lorsqu'elles ne sont pas transfor-mées, ces traces sont également quali�ées de "traces brutes".

2. Phase de fusion : Une vision globale de l'activité nécessite une fusion des di�érentestraces. A ce stade une solution pour gérer la fusion des traces est nécessaire. Laplupart du temps cette étape est automatisée.

3. Phase de nettoyage : Le nettoyage supprime les traces qui ne sont pas généréespar l'action explicite de l'utilisateur (par exemple les images requises par la pageweb) et qui ne seront pas analysées. Les méthodes classiques utilisent des listesdes su�xes ou même des noms des �chiers contenus dans la requête http [CMS99]pour décider si les traces sont adéquates ou non. Mais ces méthodes restent tropgénérales pour extraire un sous-ensemble des traces étroitement lié à l'objectifde l'analyse. Généralement le résultat constitue une entrée pour les méthodes de�ltrage.

4. Phase de �ltrage : Les phases de collecte/fusion produisent généralement une trèsgrande quantité de données. Comme la plupart du temps les expériences d'ob-servation sont conduites selon des objectifs précis, il est possible de réduire cettequantité de données a�n de pouvoir ra�ner l'analyse et de minimiser sa durée. Lebut des méthodes de �ltrage (sélection) est d'extraire un sous-ensemble des tracespertinentes par rapport à l'objectif de l'analyse. La solution la plus répandue estd'employer des conditions de �ltrage sur les attributs des traces [MHCF04]. Dansce cas une règle de �ltrage représente une expression logique qui implique des attri-buts, des opérateurs relationnels et des constantes. Le désavantage principal de cesméthodes est la complexité. Tout d'abord, il est di�cile de manipuler des attributs

63


de bas niveau (ip, date, requête http) pour exprimer des règles de �ltrage com-plexes. De plus, comme les traces sont générées par l'interaction entre l'utilisateuret les composants logiciels du système, on doit faire correspondre le composant etsa représentation dans la trace a�n de pouvoir employer ce composant dans unerègle de �ltrage.

5. Phase de structuration : La représentation des traces avec des paramètres de basniveau rend le processus d'interprétation di�cile. Pour la bonne compréhension destraces une bonne structuration est nécessaire. A ce stade, les traces collectées sontregroupées, réarrangées, annotées pour faciliter leur interprétation. Une solutionconsiste à générer des traces plus abstraites par l'identi�cation de "patterns" dansl'ensemble des traces brutes (changement du niveau de granularité des traces pourles rendre plus interprétables). Cela se fait via la généralisation des traces dupoint de vue sémantique ou syntaxique. La généralisation sémantique groupe lespages web avec le même contenu sémantique alors que la généralisation syntaxiquecombine les traces dont les requêtes http sont similaires [TT04]. Ces transforma-tions peuvent causer la perte d'informations. Leur utilisation est donc adéquatepour les analyses dont l'objectif est d'obtenir une vue générale du comportementdes utilisateurs.

6. Phase d'analyse : Cette phase guide l'interprétation des traces par l'analyste. Laplupart du temps, cette phase est peu automatisée à cause du haut niveau de com-plexité de la tâche. Mais des outils spéci�ques de visualisation et de représentationdu résultat peuvent être utilisés a�n de faciliter la tâche de l'analyste.

2.4.3 Démarches d'ingénierie des traces

L'ensemble des traces obtenues via le processus d'observation doit être préparé pourl'interprétation. Plusieurs solutions sont proposées permettant d'instrumenter l'environ-nement informatique en spéci�ant les observables à un autre niveau d'abstraction. Nouspassons en revue quelques unes des démarches d'ingénierie des traces.

Le modèle � Modify, Map, Mine �

Le modèle � Modify, Map, Mine � a été dé�ni dans le cadre du projet LISTEN[Mos04], [MB06]. Ce modèle, dédié aux environnements EIAH, représente un ensemblede recommandations méthodologiques pour l'utilisation, par un système d'analyse detraces, des données collectées par un système informatique quali�é de "tutoriel intelli-gent" [Cho07].

1. Modi�er l'instrumentation du système (� Modify �). Cet ensemble de recomman-dations porte sur la conception ou la réingénierie du système d'apprentissage demanière à le rendre capable de collecter le maximum d'informations signi�antes.� Enregistrer les événements, que ce soient les productions de l'utilisateur (dit ap-

prenant) : � inputs �, les productions du système : � outputs �, ou les motivationsayant amené le système (appelé "tuteur") à faire ses productions : � tutorial de-cisions �. Il est recommandé également d'envisager di�érents types d'analysepour caractériser ces événements, en donnant l'exemple d'un clic souris qui, s'il

64


est représenté par ses coordonnées spatiales, peut donner des indications sur lamotricité de l'apprenant, mais qui, s'il est représenté par référence à l'élémentde l'interface cliqué, donne des informations sur la nature de l'interaction.

� Dater systématiquement les événements de manière à pouvoir mener des analysessur les précédences, les récurrences, les fréquences, etc.

� Intégrer les opérations dans le système d'apprentissage de manière à les rendreanalysables. En particulier, il serait intéressant de mettre en place des solutionsIHM de manière à ce que toute l'activité � externe � de l'apprenant puisse êtreenregistrée.

� Rendre aléatoires certaines décisions pour faciliter l'analyse de la qualité desdécisions dans un contexte donné en multipliant les situations.

� Multiplier les tests des acquis de l'apprenant en considérant que ces tests serventà la fois à évaluer l'apprenant mais également à mesurer la pertinence des actionstutorielles.

� Acquérir (ante session) des informations sur l'apprenant (son âge, son Q.I., etc.)de manière à mieux contextualiser les performances de l'apprentissage.

� Équiper le système de moyen de compréhension du langage naturel. Il est consi-déré ici qu'il faut au moins se donner les moyens d'interpréter la sémantique desproductions de l'apprenant, en caractérisant ces dernières par le temps mis à lesproduire, par une comparaison avec un ensemble de productions attendues, etc.

� Inclure une étape de traitement manuel des données collectées pour préciser etcompléter ces données.

2. Ensuite, transformer les événements collectés en variables signi�antes (� Map �).Cet ensemble de recommandations identi�e les moyens de reconstruire des infor-mations signi�antes à partir du �ot d'événements collectés.� Segmenter un �ot d'événements en séquences temporelles, identi�ées par des

instants remarquables, comme par exemple le moment de la production de l'ap-prenant. Selon [MB06], lorsqu'elle est associée à une mesure du temps de laséquence, cette technique est particulièrement utile pour dé�nir et entraîner unmodèle comportemental.

� Identi�er dans le �ot d'événements les enchaînements relatifs à une compétenceparticulière de l'apprenant ou du tuteur intelligent.

� Reformuler le �ot d'événements en un ensemble de tâches, caractérisées chacunepar son contexte, sa décision tutorielle et son résultat, de manière à mesurer laqualité intrinsèque d'une décision tutorielle, mais aussi son impact relatif à uncontexte et un apprenant donnés.

3. Puis �nalement, explorer l'ensemble des données collectées (� Mine �). Cet en-semble de recommandations porte sur les techniques de dé�nition ou d'exploitationd'un modèle quali�ant l'apprenant ou le tuteur intelligent.� Inspecter des échantillons des interactions de manière à aider à la formulation

d'hypothèses de recherche.� Agréger et composer un ensemble de données pour véri�er une hypothèse, un

objectif de recherche spéci�que.� Adapter un modèle d'analyse à un ensemble de données en déterminant les

paramètres qui minimisent ses erreurs de prédiction.� Entraîner un modèle d'analyse sur un sous-ensemble de données avant de l'ex-

ploiter sur l'ensemble des données collectées.

65


L'approche MUSETTE : approche de modélisation et d'exploitation destraces

L'approche MUSETTE [CPM04] propose la création d'un modèle d'utilisation quidé�nira toutes les "observables". Des descriptions peuvent être ajoutées pour chaqueobservable en vue de faciliter leur interprétation.

MUSETTE considère la trace d'utilisation d'un environnement informatique commeune succession d'états, représentant une con�guration stable de l'environnement, et detransitions entre ces états, révélant une interaction entre l'utilisateur et le système ayantfait évoluer la con�guration. L'objectif de MUSETTE est d'extraire, à partir des donnéescollectées, des motifs, quali�és d'épisodes, dans la trace d'utilisation qui témoignent dela réalisation d'une tâche spéci�que par l'utilisateur.

La trace est ainsi structurée en plusieurs niveaux d'abstraction. MUSETTE en consi-dère trois :

1. La trace brute, soit l'ensemble des données collectées par un � Agent Observateur�, guidé par un � Modèle d'Observation �. Ce modèle d'observation décrit les règlesnécessaires à la détermination des données pertinentes issues de l'environnementet à la construction e�ective de la trace primitive.

2. La trace primitive (ou première) est le premier niveau de trace accessible (i.e.supposée compréhensible) par l'utilisateur. Elle est générée conformément à un �Modèle d'Utilisation � qui � décrit les entités, événements et relations à observerpour construire une trace primitive, à la manière d'une `ontologie de l'observa-tion' � [MCP06]. C'est à ce niveau que la trace peut être représentée comme unesuccession d'états et de transitions.

3. Les épisodes sont extraits de la trace primitive par un � Analyseur Génériquede Trace �. Cet analyseur s'appuie sur des signatures de tâches utilisateurs pourdétecter les épisodes dans la trace primitive.

Le formalisme de MUSETTE introduit la notion � d'objets d'intérêt � pour quali�erles éléments d'interaction constituants de la trace. Trace primitive, épisodes et signaturesde tâches sont exprimés à l'aide des ces objets d'intérêt. Ils sont de trois types :

� Les entités sont des objets � présents � pour l'utilisateur, c'est-à-dire perçus parcelui-ci. Si nous considérons l'exemple de l'utilisation d'un site Web, ces entitéspeuvent être des pages, des hyperliens, ou bien encore des images.

� Les événements sont des objets � qui se passent � durant l'interaction. Toujoursdans l'exemple du site Web, ces événements peuvent être un clic souris, la posed'un marque-page sur une page, ou la sauvegarde d'une page en local.

� Les relations sont des liens structuraux ou causaux entre les entités et/ou lesévénements, comme par exemple le lien entre un hyperlien et un clic souris, ouentre un clic souris et une page.

Les signatures de tâches sont alors exprimées par un graphe d'objets d'intérêt, pardes contraintes relatives aux positions des objets d'intérêt dans la trace, et par descontraintes sur la structure interne des objets d'intérêt. L'explication de la signature estexprimée par un nom, éventuellement complétée par une annotation en texte libre des-tinée à l'utilisateur, et/ou par une annotation formelle pour un traitement automatique[Cho07].

66


Fig. 2.5 � L'approche MUSETTE [Cho07]

L'approche MUSETTE est néanmoins limitative, car elle réduit l'ensemble des ob-servables à ceux dé�nis précédemment. Aussi, une description particulière de la tracen'est pas toujours adaptée à l'objectif visé par l'activité d'observation.

Les Systèmes à Base de Traces modélisées

Les Systèmes à Base de Traces (SBT) s'inspirent des travaux sur MUSETTE maisélargissent leur spectre d'utilisation en cherchant à dé�nir un cadre général pour l'exploi-tation des traces [Set06]. Dans un système à base de traces, les traces sont considéréescomme une séquence temporelle d'observés et sont toujours accompagnées de leurs mo-dèles de traces.

Un SBT se dé�nit comme étant � tout système informatique dont le fonctionnementimplique à des degrés divers la gestion, la transformation et la visualisation de tracesmodélisées explicitement en tant que telles � [Set06]. Une trace modélisée est, dans cecontexte, une collection d'observés, situés dans le temps, exprimée de manière conformeà un modèle formel. Dans une approche tenant de l'IDM - Ingénierie Dirigée par lesModèles (Cf. Chapitre 1, section 1.4.4), des traces nouvelles, exprimant un point de vueparticulier sur la trace première, peuvent être obtenues par transformations explicitesentre modèles de traces. Ces transformations peuvent être (1) une sélection à partir d'unetrace source en respectant un �ltre de sélection spéci�que pour, par exemple, isoler desobservés pertinents, (2) une réécriture de motifs permettant de remplacer un ou plusieursobservés par un autre, (3) une fusion temporelle de deux ou plusieurs traces permettantnotamment de regrouper des observés collectés par plusieurs sources.

La proposition SBT a�rme un ancrage dans une approche IDM plus fort que MU-SETTE, notamment dans sa volonté d'expliciter les transformations entre les traces.Comme souligné et démontré dans [SPMM07], ces transformations, mais aussi les mo-dèles de traces et les représentations des traces, peuvent être capitalisées et réutilisées

67


dans d'autres contextes. De plus, l'approche par modèles permet de manipuler et defusionner des traces aux formats hétérogènes, provenant de plusieurs sources. Ceci estun avantage certain dans un contexte où la perception de l'activité s'opère en combi-nant plusieurs sources de données comme, par exemple, les �chiers de � logs � d'uneplate-forme, les productions des acteurs, les échanges sur une messagerie, etc.

Cependant, il semble restrictif de n'envisager les transformations de traces commene relevant que de trois types : sélection, réécriture de motifs et fusion temporelle.L'établissement d'un indicateur est également une transformation à partir d'un ensembled'autres indicateurs et de traces et il semble important, dans un objectif de capitalisationet de partage, d'expliciter également ce type de transformations [Cho07].

En�n, on ne retrouve plus ici le concept de signature de tâches expliquées de l'ap-proche MUSETTE, qui est intéressant par son potentiel à impliquer l'analyste dans lamodélisation des observations et sa capacité, dans le contexte de la scénarisation (activitéobservable), à établir des liens sémantiques entre les scénarios et les traces [Cho07].

L'approche par les agents d'observation

L'approche par les agents proposée dans [LCM07] identi�e plusieurs types d'agentd'observation : agent collecteur, agent historique, agent de structuration, agent statis-tique, agent visualisation. Nous présentons dans ce qui suit une description des agentsproposés.

� Observer les actions d'un apprenant : agent collecteur des traces. Cet agent estchargé de collecter des traces numériques à partir des actions de l'apprenant/l'uti-lisateur durant l'activité. La séquence des traces collectées est systématiquementenregistrée dans des �chiers de log sur la station de travail. L'agent est égalementhabilité à choisir les traces collectées en fonction de ce qui lui est demandé.

� E�et mémoire ou � que fait cet utilisateur depuis le début de l'activité ? � : agenthistorique. Cet agent est chargé de chercher et d'identi�er de traces dans l'� his-torique des actions � (l'ensemble des �chiers de log) qui se trouve sur la stationde travail. Il permettra éventuellement de retrouver des informations lorsque l'onsouhaite a�ner ou préciser une observation.

� Raisonnement ou � quel but a cette suite de micro-actions ? � : agent structu-ration. Les traces collectées peuvent avoir di�érentes formes, peuvent être trèsdétaillées, redondantes ou incomplètes. Ainsi l'agent structuration est spécialisépour les regrouper, reformater ou annoter a�n de les rendre plus adaptées pourl'interprétation (les amener au bon niveau d'abstraction). Cet agent est alors dédiéà l'identi�cation de patterns (ou de motifs) dans l'ensemble des traces collectéeset à l'application de règles de réécriture pour changer le niveau d'abstraction destraces.

� Recueil d'informations factuelles, collectives : agent statistique. Cet agent est dotéde fonctionnalités de calcul. Cet agent est évidemment informé par les autres agents(généralement par l'agent structuration) de l'état de chaque micro-action.

� Représentation de l'activité : agent visualisation. Cet agent est spécialisé dansla visualisation/présentation des traces ainsi que dans l'a�chage de résultats oumessages (autres que la trace). Il permet ainsi de suivre plus aisément ce qui sepasse au cours de l'activité.

68

2.5. Conclusion

Les agents décrits dans la section précédente ont des compétences mais aussi desbesoins spéci�ques (des informations ou résultats qu'ils ne "savent" pas obtenir direc-tement). Ainsi, l'agent collecteur ou l'agent historique ont besoin de la description destraces à sélectionner parmi les traces collectées ou enregistrées dans les �chiers de log.L'agent structuration applique ses règles de réécriture de traces par l'identi�cation depatterns qui lui ont été fournis. En�n, le fonctionnement de l'agent statistique nécessitela liste des étapes des actions à surveiller.

Les notions de compétences et de besoins spéci�ques imposent aux agents de co-opérer pour résoudre un but général d'observation. Par exemple, les traces collectéeset sélectionnées par les agents collecteurs sont regroupées via un agent structuration,le résultat étant a�ché à l'analyste grâce à un agent visualisation. A�n de pouvoir co-opérer chaque agent doit déclarer ses compétences. En�n, les agents peuvent coopérermais également réagir de manière autonome. La réaction d'un agent est conditionnéepar l'apparition d'une situation initialement prévue et peut ensuite engager l'agent dansune nouvelle coopération.

2.5 Conclusion

Nous avons traité, dans ce chapitre, la notion de pilotage et de performance dansl'entreprise industrielle. Nous avons recensé les di�érentes catégories d'indicateurs, puisnous avons cherché comment distinguer les concepts de mesure, appréciation et évalua-tion. Ensuite, nous avons abordé les techniques d'évaluation qualitative des indicateurs.

Ce chapitre fait également l'objet d'une présentation des modèles d'observation pourle suivi des activités menées au sein d'un système d'information. Il s'agit particulièrementde modèles d'analyse des traces. Ce choix est motivé par la démarche d'analyse adoptéepour répondre à nos questions de recherche ; une "logique Bottom-Up" ayant un pointde départ situé au niveau micro et qui consiste en l'analyse des processus instanciés dansle SIP en composantes opératoires.

En e�et, de tels modèles permettent de favoriser la découverte de connaissances grâceaux traces d'interaction avec le système. Néanmoins, ces modèles doivent être élaborésconjointement avec un ensemble de procédures, conduites par l'objectif de l'activitéd'observation, et permettant de s'assurer de la validité (données atypiques, manquantesou inconsistantes) des données collectées.

69

Étatdeslieuxdelacollaboration...

Documents

Transcript of Étatdeslieuxdelacollaboration...