spécification d’un workflow pour la gestion des...

2011 - 2012

Président BELDJILALI Bouziane

Professeur Université d’Oran

Directeur de thèse

BOUAMRANE Karim Maitre de conférences -A- Université d’Oran

Examinateur HAFFAF Hafid

Professeur Université d’Oran

Examinateur BENMOHAMED

Mohamed

Professeur Université de Constantine

Examinateur BENYETTOU Mohamed

Professeur Université Med Boudiaf - Oran

Examinateur LEHIRECHE Ahmed

Maitre de conférences -A- Université de Sidi-Bel-Abbès

DEPARTEMENT D'INFORMATIQUE

THESE DE DOCTORAT

Spécialité Informatique

Option : Informatique et Automatique

Intitulé :

Septembre 2011

Spécification d’un Workflow pour la gestion des

interactions entre experts au sein d’un processus

de maintenance coopératif

Présentée par

M r L AR EDJ M . Adnane

So us la d ir ec t io n d e

M r BOUAMRANE Karim

A Mes Parents

Ma Famille Mes Amis

Remerciements

Je tiens à remercier mon encadreur Mr BOUAMRANE Karim sans qui ce présent

travail n‟aurait pas pu être mené à son terme. Sa collaboration, au point de vue

documentation et connaissances personnelles m‟a été d‟une grande aide dans le

cheminement de cette thèse. Je lui suis également reconnaissant pour sa proximité et

ses qualités humaines qui m‟ont permis de travailler dans les meilleures conditions.

Je ne peux oublier aussi l‟aide de Mr GUEDDA Ahmed, Ingénieur Process au sein du

complexe GP1Z, grâce à qui j‟ai pu effectuer mon étude de cas, et qui a

généreusement mis à ma disposition sa précieuse documentation.

Je suis sensible à l‟honneur que me font les membres du jury d‟avoir accepté

d‟évaluer ce travail :

J‟exprime ma reconnaissance à Mr BELDJILALI Bouziane , qui m‟a honoré en

acceptant de présider le jury de ma thèse

Ma reconnaissance va également vers le Pr BENYETTOU Mohamed, Pr HAFFAF

Hafid, Pr BENMOHAMED Mohamed ainsi que le Dr LEHIRECHE Ahmed, membres

du jury, qui ont porté un intérêt particulier à ce travail et qui ont accepté de le juger

Table des Matières

Introduction générale 1

Chapitre1 : Les concepts de la maintenance 4 1. Introduction 2. Définitions 3. Types de maintenance 4. Objectifs de la maintenance 5. Les critères de maintenabilité 6. Processus de maintenance 6.1. Les intervenants du processus de maintenance 7. Les niveaux de maintenance 8. Fonctions de maintenance 8.1. Fonction étude et méthodes 8.2. La fonction exécution - mise en oeuvre

8.3. La fonction documentation 9. Présentation d‟un système de gestion de la maintenance 9.1. La gestion des flux d‟information 9.2. Informatisation des procédures de maintenance 9.3. Evolution du domaine technique 10. Nouvelles formes de maintenance 10.1. La télémaintenance 10.1.1. Apport de la télémaintenance 10.1.2. Domaines d‟application 10.1.3. Télémaintenance et coopération 10.2. La e-maintenance 10.3. La s-maintenance 10.4. La maintenance distribuée 11. Conclusion Chapitre2 : Coopération et Collaboration 31

1. Introduction 2. Coopération et collaboration 2.1. Qu‟est ce que la coopération ? 2.1.1. Un cadre temporel

2.1.2. Un cadre spatial 2.1.3. Un cadre conceptuel 2.1.5.Comment distinguer « coopération » et « collaboration » ? 2.2. Les formes de coopération 2.2.1. Les modes de coopération 2.2.2. Les modes d‟organisation 2.2.3. Modes de coordination 2.3. Les comportements et connaissances des individus lors de la coopération

2.3.1. Comportement individuel 2.3.2. Comportement collectif 2.3.3. Organisation d‟un groupe de membres coopérants 2.3.3.a. Organisation statique

2.3.3.b. Organisation dynamique 2.4. Exclusion mutuelle

3. la décision collaborative 3.1.Le processus de décision collaborative 3.2.Travaux actuels en décision collaborative 3.3.Décision collaborative en maintenance 3.4. Formalisation de la décision collaborative 4. Conclusion Chapitre 3 : CSCW (Computer Supported Cooperative Work) 52

1. Introduction 2. CSCW (Computer-Supported Cooperative Work) 2.1. Les Groupwares 2.2. Modèle du trèfle 2.3. Les règles d'or du groupware 2.4. Implantation d'un groupware 2.5. Conséquences de la mise en place d‟un groupware 2.6. Taxonomies des Groupwares 2.6.1.Types d‟applications

2.6.2. Classification espace temps 2.6.3. Taxonomie du travail collaboratif 2.7. Synthèse 3. les workflows 3.1. Définition 3.2. Concepts de bases 3.2.1. Le routage des documents, des informations ou des tâches 3.2.2. La gestion des règles de coordination des activités 3.2.3. La gestion des personnes (rôles) 3.3. Typologie des applications de workflow 3.3.1. Les workflows de production 3.3.2. Les workflows intégrées 3.3.3. Les workflows administratifs 3.3.3. Les workflows collaboratifs 3.3.4. Les workflows ad-hoc 3.4. Composantes techniques des systèmes de workflow 3.4.1. L'outil de définition de processus (interface 1) 3.4.2. Le moteur de services workflow (serveur workflow) 3.4.3. L'application cliente workflow (interface 2) 3.4.4. L'application appelée par le workflow (interface 3) 3.4.5. Les autres moteurs de services workflow (interface 4)

3.4.6. L'outil d'administration et de pilotage du système workflow (interface 5)

3.5. Impacts du workflow 4. Conclusion

Chapitre 4 : Systèmes de gestion de la e-maintenance 79 1. Introduction 2. Les sous systèmes fonctionnels de la e-maintenance 2.1. SCADA (Supervisory Control And Data Acquisition) 2.2. Systèmes d‟aide au diagnostic 2.3. Système de GMAO 2.4. Système de documentation 2.5. Système ERP 3. Plateformes de E-maintenance

3.1. La plateforme PROTEUS 3.1.1. Problématique d‟interopérabilité 3.1.2. Objectif du projet PROTEUS 3.1.3. Architecture de la plateforme PROTEUS 3.1.3.1. Les outils du « Central Service Application » 3.1.3.2. L‟« Intelligent Core Adapter » 3.1.3.3. Le « Functional Core Adapter » 3.1.4. Exemple d‟application 3.1.5. Evaluation du projet PROTEUS 3.2. Projet TEMIC (TEleMaintenance Industrielle Cooperative) 3.2.1. Evaluation de la plateforme TEMIC 3.3. TELMA Plate-forme d‟intégration de télémaintenance pour l‟enseignement et la recherche

3.3.1. Objectifs de la plate-forme TELMA 3.3.2. L‟architecture technique de la plateforme TELMA 3.3.2.1. La partie opérative 3.3.2.2. La partie commande 3.3.3. Génération de défaillances

3.3.4. Conditions de mise en place 3.4. OSA-CBM (Open System Architecture for condition-Based Maintenance)

3.5. La méthode “Scoop” pour les systèmes coopératifs 4. L‟approche proposée 4.1. Amélioration de la méthodologie « SCOOP » 4.2. Implémentation de la plateforme CDW

5. Conclusion

Chapitre 5: Modélisation d’un Workflow pour la e-maintenance 111 1. Introduction 2. Modélisation d‟un processus de maintenance coopérative 2.1. Modélisation du processus 2.2. Processus de e-maintenance 3. Contribution 3.1. Choix de la méthode de modélisation 3.2 Description de la méthode OSSAD 3.2.1. Le modèle descriptif 3.2.2. Modélisation de l‟algorithme de gestion de la coopération d‟un

groupe d‟experts

3.2.3. Le niveau prescriptif 3.2.4. Démarche de spécification. 4. Conclusion

Chapitre 6 : Etude de cas : le complexe GP1Z 129

1. Introduction 2. L‟activité de diagnostic et de maintenance au sein du complexe GP1Z 2.1. La Demande de Travail (DT) 2.2. La Préparation 2.3. La programmation 2.4. Le Procurement

3. Critiques et améliorations 3.1. Un Workflow pour l‟e-maintenance 3.1.1. Phase de modélisation du processus 3.1.2. Phase génération du Workflow 3.1.3. Phase d‟exécution du workflow 3.2. Génération des Réseaux de pétri à partir des modèles OSSAD 3.3. Vérification des propriétés d‟un RDP 4. Conclusion Conclusion et perspectives 148 Annexes 151

Liste des figures

Figure 1.1: les différents types de maintenance Figure 1.2 : Choix du type de maintenance Figure 1.3 : Processus général de maintenance Figure 1.4 : les fonctions et les tâches associées à la maintenance Figure 1.5 : le système de gestion de la maintenance Figure 1.6. Coopération des différents systèmes informatiques Figure I.7 : Schéma d'interaction entre les différents composants d'un système de

télémaintenance Figure 1.8 : Architecture de télémaintenance Figure 1.9 : Schéma fonctionnel d‟un système de télémaintenance Figure 1.10 : Fonctionnement d'un système de maintenance utilisant les informations

d'une base de données

Figure 2.1 : Modèle du processus de décision collective

Figure 3.1 : Modèle du trèfle Figure 3.2 : Classification de J. Grudin Figure 3.3 : Modèle de travail coopératif Figure 3.4 : Matrice fonctionnelle de la typologie workflow Figure 3.5 : Modèle de référence du workflow

Figure 4.1: Exemple d‟un système SCADA du Complexe GP1Z Figure 4.2 : Composant de la plateforme PROTEUS Figure 4.3 : Architecture simplifiée de la plate-forme PROTEUS Figure 4.4 : Description d'un "Intelligent Core Adapter" Figure 4.5 : Identification d'un workflow partant d'un scénario Figure 4.6 : La télé--maintenance dans une imprimerie industrielle Figure 4.7 : L‟architecture OSA-CBM Figure 4.8 : Modélisation des interactions entre 3 experts en mode synchrone Figure 4.9 : Capture d‟écran du simulateur des systèmes coopératifs

Figure 5.1 : Méta-modèle du modèle de rôles Figure 5.2 : Méta-modèle du modèle de procédures Figure 5.3 : Méta-modèle du modèle d‟opérations Figure 5.4 : Modèle d‟opération du processus de création d‟un groupe d‟experts Figure 5.5 : Modèle d‟opération du processus d‟ajout d‟un nouveau membre par

invitation Figure 5.6 : Modèle d‟opération du processus d‟Ajout d‟un nouveau membre par

demande d‟adhésion Figure 5.7 : Modèle d‟opération du processus de Dissolution du groupe d‟experts - fin de

traitement Figure 5.8 : Modèle d‟opération du processus d‟Exclusion mutuelle Figure 5.9 : Méta-modèle du niveau prescriptif. Figure 5.10 : Modèle d‟opération du processus de Création d‟un groupe – attribution d‟un

expert - traitement d‟une panne supplémentaire Figure 5.11 : Modèle prescriptif des opérations de Création d‟un groupe - attribution d‟un

expert - traitement d‟une panne supplémentaire

Liste des Tableaux Tableau 1.1 : Le processus de la maintenance selon les quatre types de maintenance Tableau 1.2 : Les ressources nécessaires pour chaque niveau de maintenance

Tableau 2.1 : Classification des mécanismes de coopération Tableau 3.1 : Classification des principaux éléments de coordination Tableau 4.1 : Positionnement des contributions des plateformes de e-maintenance Tableau 4.2 : Positionnement de (CDW) au sein des plateformes de e-maintenance Tableau 5.1 : Les niveaux de modélisation d‟OSSAD Tableau 5.2 : Principaux concepts du modèle descriptif d‟OSSAD

Figure 6.1 : Vue du System SCADA sur un train de production Figure 6.2 : Système de supervision de la production Figure 6.3 : Etablissement d‟une demande de travail par une application de GMAO Figure 6.4 : Différentes taches durant la phase de préparation Figure 6.5 : Différentes taches durant la phase de Procurement Figure 6.6 : Causes des pertes de capacité de production et implication des services Figure 6.7 : Architecture du système CDW conforme au modèle de référence WfMC Figure 6.8 : Module d‟envoie de notifications CDW_Messenger Figure 6.9 : Saisie du modèle Workflow OSSAD par l‟application DUOProcss Figure 6.10 : Module de génération de Workflow : CDW_Builder Figure 6.11 : Bon de travail envoyé au client pour le lancement d‟une tâche Figure 6.12 : Boite de réception de tâches du CDW_ApplicationClient Figure 6.13 : Exemples de règles de passage du Modèle OSSAD vers les RDP Figure 6.14 : Vérification des propriétés du modele RDP avec PertiParc Figure 6.15 : RdP correspondant au modèle OSSAD d‟opération « Ajout d‟un

nouveau membre par invitation »

Introduction

Générale

1

Introduction générale

Le développement de nouvelles technologies, l‟extension d‟Internet, l‟intégration

des applications, l‟émergence de nouvelles politiques de maintenance, sont les

préludes à une nouvelle période pour l‟informatisation de la maintenance, celle que

certains appellent la « maintenance intelligente ».

Cette dernière occupe dorénavant une part importante, et exige de ce fait, une

modélisation rigoureuse permettant par la suite son automatisation. C‟est dans

cette optique, que de nombreux acteurs de l‟industrie collaborent pour atteindre un

but commun : réduire la probabilité de défaillance ou de dégradation d‟un objet.

Chacun, ayant ses connaissances personnelles, son savoir faire, et ses pratiques

propres. Ainsi, plusieurs personnes de pays et de professions différents, travaillant

pour des entreprises distinctes, peuvent être amenées à travailler ensemble pour la

maintenance d'un produit. Ceci n'est pas sans causer de nombreux problèmes. Il

faut alors réinventer l‟organisation du processus de maintenance et redéfinir les

relations que doivent entretenir entre les hommes de métier dans le cadre d‟un

travail coopératif, au sein duquel les rôles et les positions de chaque acteur doivent

être redéfinis.

Dans ce contexte coopératif, nous proposons la spécification d‟un modèle

workflow1 pour l‟aide à la maintenance coopérative, dont l‟objectif principal, sera de

coordonner les interactions entre les différents acteurs intervenant au sein du

processus de diagnostic et de maintenance, et qui aboutira à terme, à une

plateforme workflow d‟aide à la e-maintenance coopérative. Pour arriver à cette fin,

on s‟appuiera sur les résultats des précédents travaux de recherche et plateformes

existantes (GENIE, PROTEUS, TEMIC, CALIF…)2 tout en présentant une véritable

alternative à ces dernières, car plusieurs problèmes reliés à cette coopération à

distance entre experts demeurent posés à ce jour, particulièrement au niveau de la

modélisation du processus de coopération pour tenir compte, entre autres, de la

disponibilité des experts, du caractère hétérogène des moyens de communication,

de l‟accès aux données partagées, etc.

L‟approche proposée dans le cadre de cette thèse, est basée sur une architecture

workflow, qui permet via trois phases (Modélisation, génération, exécution), de

1 Voir chapitre 3

2 Voir chapitre 4

2

mettre sur pied un workflow opérationnel et autonome, dont l‟objectif principal sera

de coordonner les interactions entre les différents acteurs intervenants au sein du

processus de maintenance. Parmi les phases citées précédemment, on s‟attellera

dans le présent travail, à élaborer des modèles formels ou semi formels des

interactions entre les intervenant de la maintenance.

Nous nous inspirons pour cela, des travaux réalisés par Boussedjra et Saint-

Vorin [BOUS01][SVZ06], et qui ont donné lieu à des modèles basés sur les réseaux

de Petri et les systèmes multi agents.

Cependant, Saint Voirin a utilisé dans son approche Scoop3, plusieurs modèles

(RDP, UML, EDP stochastique, PLOOM-UNITY, SMA, XML…) à travers différentes

phases (spécification formelle, modélisation structurelle, modélisation des

interactions, modélisation des connaissances) afin de définir la coopération et la

coordination entre experts, impliqués dans un processus de diagnostic. En se

basant sur la nomenclature qu‟il a proposée. Nous simplifions cette approche, en

utilisant un modèle Workflow basé sur un langage de modélisation reconnu et dédié

à la modélisation et la coordination d‟organisation, impliqués dans des processus

coopératifs. De plus, le langage de modélisation utilisé, permettra de générer un

RDP, dispensant ainsi les experts du domaine (maintenance), la charge de créé des

réseaux de Petri, qui sont plutôt l‟apanage d‟expert chevronnés dans le domaine de

la modélisation informatique et mathématique. Permettant ainsi de pallier à une

insuffisance souvent reprochée aux modèles Workflow, à savoir, l‟absence de

possibilité de vérification et simulation.

Le présent travail traite donc de la modélisation de la coopération entre différents

experts distants, impliqués dans le diagnostique et la réparation de défaillances

dans un contexte de e-maintenance. Nous proposons pour cela de suivre la

démarche suivante : Dans le premier chapitre, nous abordons les différentes formes

de la maintenance, afin de mettre en exergue l‟importance de la coopération entre

experts lors du diagnostic des pannes. Dans ce mémoire, nous introduisons dans le

deuxième chapitre les notions de coopération et de collaboration. Nous décrivons

ensuite dans le troisième chapitre, les différents outils de TCAO (Travail

Collaboratif Assisté par Ordinateur), permettant l‟implémentation d‟une vision

coopérative et collaborative de la maintenance, on se focalisant sur les

« Groupwares » et plus particulièrement les « Workflow », pour leur capacité de

coordination, d‟automatisation et de suivi des tâches collaboratives. Nous dressons

3 Voir chapitre 4

3

dans le quatrième chapitre un état de l‟art des différents travaux, réalisés dans le

cadre de partenariats industriels, et qui se sont orientés vers la conception et la

réalisation de plateformes d‟instrumentation de solutions d‟e-maintenance. Ces

plateformes intègrent les différents éléments tels que les capteurs actionneurs

instrumentant les équipements à maintenir, les systèmes distribués de

surveillance, les supports de communication. Il existe plusieurs plateformes, telle

que celle issue du projet européen Proteus [BANG03] qui est une plateforme

générique pour la e-maintenance, développée à l‟aide des technologies d‟Internet et

permettant notamment la collaboration des acteurs, le couplage avec les outils

classiques de gestion d‟entreprise de type ERP (Enterprise Resource Planning),

l‟aide au diagnostic, l‟accessibilité à diverses ressources (bases de données). Celle

du projet TEMIC (Télé-Maintenance Industrielle Coopérative) plateforme d‟e-

maintenance privilégiant la collaboration d‟acteurs de maintenance via un réseau

de téléphones portables. TELMA (TéLé-Maintenance) développé par le CRAN (Centre

de Recherche en Automatique de Nancy) [Levrat 06] : plate-forme pour

l‟enseignement et la recherche supportant les enseignements de la maintenance et

illustrant les apports des TIC sur les processus et organisations de maintenance.

Nous montrons les différentes insuffisances, qu‟on traite dans le cinquième

chapitre, consacré au choix du langage de modélisation « Workflow » basé sur une

approche systémique « OSSAD ». Ce dernier sera formalisé dans le dernier chapitre

par les RdP, faisant l‟objet d‟une étude de cas au sein du complexe gazier GP1Z.

Cette démarche nous permet ainsi la validation de nos modèles « Workflow », grâce

entre autres, aux propriétés mathématiques des RdP (vivacité, détection de

conflit….).

La thèse est terminée par une conclusion avec perspectives et des annexes.

4

Chapitre 1

Les concepts de la

maintenance

Chapitre 1 : Les concepts de la maintenance

5

1. Introduction

Au fil du développement de la concurrence et de la course à la compétitivité,

qui entraîne recherche de la qualité totale et surtout réduction des coûts, et au fur

et à mesure de la complexification et de l‟automatisation des processus de

production, la maintenance est devenue une des fonctions stratégiques de

l‟entreprise. Loin d‟être aujourd‟hui stabilisée, elle évolue au gré de l‟introduction de

nouvelles méthodes de gestion, du développement technologique des outils de

production, en particulier dans les domaines de la mesure et du contrôle de

fonctionnement, de la systématisation progressive de l‟usage des normes et des

procédures. Nous nous attacherons dans ce chapitre à définir les concepts de base

de la maintenance, ainsi qu‟une présentation des différente formes de maintenance

qui ont vus le jour sous l‟influence de nombreux facteurs qui modifie non

seulement les modes d‟organisation de la fonction de maintenance mais aussi les

activités des techniciens et ouvriers qui opèrent dans ce champ.

2. Définitions

Selon les normes NF X 60-010 et 60 011 :

a. la maintenance est définie comme étant l‟ensemble des actions permettant

de maintenir ou de rétablir un bien dans un état spécifié ou en mesure

d‟assurer un service déterminé.

b. La fiabilité d‟un système s‟exprime par la probabilité que ce dispositif

accomplisse une fonction requise dans des conditions d‟utilisation et pour

une période de temps déterminée. C‟est donc une grandeur comprise entre 0

et 1.

c. la défaillance elle est définit comme une altération ou une cessation d‟un

bien à accomplir une fonction requise. L‟analyse de la défaillance est faite

non seulement dans le but de réparer ou dépanner un système défaillant,

mais également de chercher à éviter la réapparition du défaut.

3. Types de maintenance


6

Maintenance préventive : maintenance ayant pour objet de réduire la

probabilité de défaillance ou de dégradation d‟un bien ou d‟un service rendu. Les

activités correspondantes sont déclenchées selon un échéancier établi à partir

d‟un nombre prédéterminé d‟unités d‟usage (maintenance systématique),

et/ou des critères prédéterminés significatifs de l‟état de dégradation du bien ou

du service (maintenance conditionnelle).

Maintenance prévisionnelle : maintenance préventive subordonnée à l‟analyse

de l‟évolution surveillée de paramètres significatifs de la dégradation du bien,

permettant de retarder et de planifier les interventions.

Maintenance corrective : ensemble des activités réalisées après la défaillance

d‟un bien, ou la dégradation de sa fonction pour lui permettre d‟accomplir une

fonction requise, au moins provisoirement : ces activités comportent notamment

la localisation de la défaillance et son diagnostic, le remise en état avec ou sans

modification, le contrôle du bon fonctionnement.

Maintenance palliative : activités de maintenance corrective destinées à

permettre à un bien d‟accomplir provisoirement tout ou partie d‟une fonction

requise. Appelé couramment dépannage, cette maintenance palliative est

principalement constituée d‟actions à caractère provisoire qui devront être

suivies d‟actions curatives.

Maintenance curative : activités de maintenance corrective ayant pour objet de

rétablir un bien dans un état spécifié ou de lui permettre d‟accomplir une

fonction requise. Les résultats des activités réalisées doivent présenter un

caractère permanent. Ces activités peuvent être des réparations, des

modifications ou aménagements ayant pour objet de supprimer le ou les

défaillances.

Maintenance préventive conditionnelle et prévisionnelle : Le principe

commun à ces techniques réside dans le contrôle régulier de l'état mécanique,

du rendement, et d'autres indicateurs des conditions de fonctionnement des

machines et des processus, de façon à optimiser l'intervalle entre les

interventions et à minimiser le risque d'indisponibilité. Ces techniques


7

Maintenance

Maintenance

systématique

Maintenance

conditionnelle

Maintenance

améliorative

Maintenance

Corrective

Maintenance

palliative

Maintenance

préventive

Maintenance

curative

Maintenance

prédictive

constituent un excellent moyen d'améliorer la productivité, la qualité du produit,

la rentabilité et le rendement global des installations. Elles ne se limitent pas au

contrôle et au suivi des vibrations, à des images thermiques ou à des analyses

de lubrifiants qui sont les méthodes et outils les plus courants : c'est toute une

"philosophie", une attitude qui consiste à se concentrer sur les caractéristiques

de fonctionnement et sur les performances globales d'une installation avec

l'objectif d'augmenter sa sûreté de fonctionnement. Un programme de

maintenance préventive complet utilise une combinaison d'outils permettant de

récolter un maximum d'informations sur l'état de santé des systèmes.

La maintenance préventive conditionnelle ou prévisionnelle ne se substitue pas

à des méthodes de gestion plus traditionnelle, elle est en fait un enrichissement

des programmes de maintenance et elle ne pourra en aucun cas supprimer

totalement la maintenance corrective [KEFF01].

Dans un premier temps on peut constater que la maintenance corrective ayant pour

but l'amélioration de la disponibilité ou la remise en conformité des installations

sera plus importante, car la maintenance conditionnelle ou prévisionnelle permet de

signaler un fonctionnement incorrect dès sa mise en place.

Figure 1.1: les différents types de maintenance [KEFF01]


8

4. Objectifs de la maintenance

Nous citons dans ce qui suit quelques objectifs qui sont étroitement liés à la

mission de l‟entreprise :

la limitation du nombre d‟interruptions de service et la réduction des durées

de pannes accidentelles;

le maintien des équipements en bon état pour opérer en toute sécurité;

la maximisation de l‟efficacité de l‟équipement;

la minimisation des coûts d‟opération;

le maintien d‟un niveau de qualité élevé du travail effectué par le service de

maintenance pour, entre autres, améliorer la qualité des produits et allonger

la durée de vie des équipements.

La réduction de l‟inventaire de pièces de rechange, et accroître la capacité de

production, ainsi que le profit global de l‟entreprise


9

Figure 1.2 : Choix du type de maintenance

Début de la démarche

La panne

sur l'équipement a-t-elle

une incidence importante sur

la production ou sur la

sécurité ?

Le cout induit par la panne

est-il acceptable ?

Est-il possible d'utiliser

des techniques de

surveillance ?

L'utilisation et

l'exploitation de tech-

niques de surveillance est-elle

acceptable ?

Oui Non

Oui

Non

Maintenance

préventive

systèmatique

Maintenance préventive

conditionnelle ou

prévisionnelle

Maintenance

corrective

Oui

Oui

Non

Non


10

5. Les critères de maintenabilité

Les normes NF X 60-300 et X 60-301 spécifient cinq critères de maintenabilité :

Le premier critère est relatif à la surveillance de la maintenance préventive. Il

est important de connaître à ce niveau l‟accessibilité de la composante, sa

démontrabilité et son interchangeabilité.

Le deuxième est relatif à la maintenance corrective, plus particulièrement, le

temps de recherche de panne ou de défaillance et le temps de diagnostic.

Le troisième critère est relatif à l‟organisation de la maintenance, pris en

compte par la périodicité du préventif, le regroupement à des périodes

identiques, l‟homogénéité de la fiabilité des composants, la présence

d‟indicateurs et de compteurs et la complexité des interventions.

L‟avant-dernier critère est lié à la qualité de la documentation technique.

Celui-ci comporte la valeur du contenu, la disponibilité de la documentation,

le mode de transmission et les principes généraux de rédaction et de

présentation de la documentation technique.

Le dernier critère de maintenabilité est lié au suivi du bien par le fabricant. Il

sera question de l‟évolution du fabricant, de la qualité du service après-vente

et de l‟obtention des pièces de rechange.

6. Processus de maintenance

Un processus de maintenance est « un enchaînement d‟activités contrôlées ou

interactives » [SAPD04], selon la démarche suivante :

a. La demande représente la formulation du besoin du client envers le

prestataire des services de maintenance. Il s‟agit de la demande exprimée

comme la réalisation de la maintenance préventive ou corrective ainsi que

toute externalisation de la maintenance ou de la demande pointue exprimée

comme la maintenance améliorative, un devis sur un équipement, des

travaux lourds etc.


11

b. Le déclenchement représente une signalisation souvent automatique d‟un

problème (défaillance ou panne) ce qui se traduit par une requête appelée

demande d‟intervention. La requête peut être externe, déclenchée pour la

plupart du temps par le client comme c‟est le cas de la maintenance

corrective et interne, initiée par un opérateur de maintenance qui signale un

problème après son contrôle ou une autre intervention. Elle peut être

également déclenchée par le système de gestion des interventions préventives

dans la GMAO ou par les capteurs ou plus généralement par le système de

surveillance comme SCADA. Comme la maintenance améliorative ne se fait

pas régulièrement mais à titre exceptionnel, la phase déclenchement ne fait

pas partie de son processus.

c. La phase préparation apparaît dans la maintenance préventive, proactive et

dans la maintenance améliorative. Les deux premiers cas concernent une

première étude de l‟équipement, consistant en sa décomposition

hiérarchique, de l‟analyse fonctionnelle à l‟AMDEC (Analyse des Modes de

Défaillance, et de leurs Effets Critiques). Cette étude a pour but de

développer la stratégie de maintenance la mieux adaptée à l‟équipement et

éventuellement d‟installer les capteurs nécessaires pour assurer la

disponibilité et la fiabilité de l‟équipement. Dans le cas de la maintenance

améliorative, la phase préparatoire contient une étude spécifique de

l‟équipement en vue de proposition de devis ou de l‟amélioration du

fonctionnement ou encore de la disponibilité de l‟équipement.

d. L’opération de validation et de correction se fait après la réception de la

demande d‟intervention. Celle-ci est corrigée et validée par le prestataire de

services de maintenance et renvoyée au client qui exprime les disponibilités

ou son accord pour la date de l‟intervention.

e. La planification et le lancement consécutif de l‟intervention se font suivant

la disponibilité de l‟opérateur dont les compétences sont nécessaires pour

effectuer cette intervention (ses compétences sont identifiées dans le type

d‟intervention) et suivant le planning de la production et donc de la

disponibilité de l‟équipement. La demande d‟intervention complétée de la


12

date précise d‟exécution est communiquée à l‟opérateur en tant qu‟ordre de

travail.

f. L’ordonnancement et l’approvisionnement à cette phase est requise dans

le cas de la maintenance préventive, proactive et améliorative. Les outils et

les pièces de rechange nécessaires pour la réalisation de l‟intervention sont

identifiés dans l‟ordre de travail et peuvent être commandés si nécessaire par

les acheteurs auprès des fournisseurs. Suivant le délai d‟approvisionnement,

la date d‟intervention est re-planifiée ou non.

g. La prise en compte représente un moment important pour les calculs des

indicateurs élémentaires pour la gestion de maintenance et notamment pour

l‟exploitation du retour d‟expérience comme par exemple le temps de la

réparation.

h. Le diagnostic et l’expertise de panne sur l„équipement concernent la

localisation et l‟identification de la cause ainsi que les actions conduisant à

sa réparation. Actuellement il est réalisé par l‟opérateur de maintenance

intervenant sur l‟équipement, en se basant sur le premier diagnostic fait par

l‟opérateur de production pendant la création de la demande d‟intervention.

Cette phase est présente dans la maintenance corrective et proactive ce qui

est dû au fait que pour les autres types de maintenance, le problème et sa

solution, respectivement le diagnostic et l‟action de réparation, sont

identifiés dans la phase préparation et déclenchement.

i. l’approvisionnement Suite au manque d‟information sur la défaillance de

l‟équipement dans la maintenance corrective, l‟approvisionnement ne peut se

faire qu‟après avoir identifié la panne et sa cause ce qui nous amène à

identifier les besoins en outils et pièces de rechange nécessaires pour réaliser

la réparation. Dans le cas de la maintenance proactive, l‟approvisionnement

peut se faire suite au diagnostic et expertise fait précédemment.

j. L’intervention représente une action de réparation de l‟équipement en

panne dans la maintenance corrective, une action de l‟entretien de

l‟équipement dans la maintenance préventive et proactive ou encore

l‟intervention de la maintenance améliorative. Après avoir effectué


13

l‟intervention sur l‟équipement donné, l‟opérateur de maintenance remplit

obligatoirement le rapport d‟intervention qui sert à l‟exploitation du retour

d‟expérience et à la gestion de la maintenance.

k. Le contrôle et la restitution de l’équipement sont faits par l‟opérateur de

maintenance et le client (opérateur de production) qui vérifient le

fonctionnement de l‟équipement

Figure 1.3 : Processus général de maintenance [RASO04]

Tableau 1.1 : Le processus de la maintenance selon les quatre types de

maintenance [RASO06]


14

6.1. Les intervenants du processus de maintenance

[RASO06] a classé les acteurs de maintenance du point de vue d‟un

utilisateur de système informatique appliqué en maintenance. Et afin de simplifier

la terminologie des acteurs du processus de maintenance souvent très

caractéristique dans chaque entreprise, on distingue trois classes générales :

6.1.1. L’opérateur de maintenance (technicien)

Représente le spécialiste qui intervient directement dans la phase

d‟intervention sur un équipement. Dans le cas de la maintenance préventive, il

s‟agit de l‟entretien ou de changement préventif, dans le cas de la maintenance

corrective l‟opérateur réalise le diagnostic et la réparation sur un équipement.

L‟opérateur est donc responsable de la réalisation et de la performance de

l‟intervention et il est chargé de la réalisation des rapports d‟interventions

nécessaires pour le retour d‟expérience ultérieur. Il a besoin des informations

concernant l‟équipement comme la documentation technique, les rapports

d‟interventions précédentes, les données sur l‟état des équipements, des mesures

des systèmes de surveillance, etc.).

6.1.2. L’expert de maintenance

Fait partie de ce qu‟on appelle souvent l‟ingénierie de maintenance. Il

intervient aussi bien dans la phase d‟intervention (aide au diagnostic et à la

réparation) comme étant l‟expert dans un domaine spécifique que dans la phase

préparatoire. Dans ce cas, il est chargé de l‟analyse d‟équipement et décide du choix

de la stratégie de maintenance la mieux adaptée, il planifie les interventions

préventives, propose des devis afin d‟améliorer le fonctionnement ou la disponibilité

de l‟équipement et veille sur l‟accomplissement des règles et des normes concernant

la sécurité de l‟équipement, du personnel et de l‟environnement.

l‟expert de maintenance participe également à la réalisation du contrat de

maintenance. Il a besoin d‟informations plus complexes qu‟un opérateur de

maintenance dont les informations concernant des indicateurs de maintenance, le

contrat de la maintenance, la documentation concernant les lois, règles et normes à

respecter, etc. Certains experts sont spécialisés dans l‟approvisionnement et

négocient les contrats avec les fournisseurs des pièces de rechange ou des outils.


15

6.1.3. Le manager

N‟intervient pas dans les phases techniques du processus de la maintenance

mais il supervise la réalisation et fait le suivi du contrat de maintenance sur le site

de production (analyse régulièrement les indicateurs du contrat de maintenance).

Le manager est chargé de la préparation des offres de prestations des services de

maintenance et des projets à proposer, de la négociation du contrat et il est ensuite

responsable de ce contrat et du suivi des engagements envers le client. Il a besoin

des informations générales concernant le parc d‟équipements dans un site de

production, de la documentation concernant les lois, règles et normes à respecter,

des indicateurs du contrat et accès au contrat lui-même, etc. Cette classe peut

comprendre différents types de manageurs tels que le manageur du site, du projet

ou du contrat, le commercial.

7. Les niveaux de maintenance

La spécification des niveaux de maintenance dans l‟entreprise fait référence à

la complexité des tâches à effectuer et à ressources humaines et matérielles

nécessaires à la réalisation de chacune des tâches :

1er niveau : réglage simple prévu par le constructeur au moyen d‟organes

accessibles sans aucun montage d‟équipement ou échange d‟équipements

accessibles en toute sécurité.

2e niveau : dépannage par échange standard d‟éléments prévus à cet effet ou

d‟opérations mineures de maintenance préventive.

3e niveau : identification et diagnostic de pannes, réparation par échange de

composants fonctionnels, réparations mécaniques mineures.

4e niveau : travaux importants de maintenance corrective ou préventive.

5e niveau : travaux de rénovation, de reconstruction ou réparations

importantes confiées à un atelier central.

Les ressources nécessaires à chaque niveau, sont résumées dans le tableau

suivant :


16

Niveaux Personnel d’intervention Moyens

1 er Exploitant sur place Outillage léger défini dans les

instructions d‟utilisation.

2 e Technicien habilité sur

place.

Outillage léger défini dans les

instructions d‟utilisation, plus pièces de

rechange trouvées à proximité, sans

délai.

3 e Technicien spécialisé, sur

place ou en local de

maintenance.

Outillage prévu plus appareils de mesure,

banc d‟essai, contrôle, etc.

4 e Équipe encadrée par un

technicien spécialisé, en

atelier central

Outillage général plus spécialisé, matériel

d‟essai, de contrôle, etc.

5 e Équipe complète,

polyvalente en atelier central

Moyens proches de la fabrication par le

constructeur.

Tableau 1.2 : Les ressources nécessaires pour chaque niveau de maintenance.

[KEFF01]

8. Fonctions de maintenance

Dans paragraphe nous cherchons à situer la maintenance par rapport au

processus de production. Ainsi, nous présentons les fonctions et les tâches

associées à la maintenance. Nous identifions trois fonctions associées à la gestion

de la maintenance.

Figure 1.4 : Les fonctions et les tâches associées à la maintenance [KEFF01]

Maintenance

Fonction exécution –

mise en oeuvre

Fonction documentation

Fonction étude et méthodes

Etude technique

Préparation et ordonnancement

Etude économique et financière

Stratégie et politique de maintenance


17

8.1. Fonction étude et méthodes

Cette fonction consiste à optimiser toutes les tâches en fonction des critères retenus

dans le cadre de la formulation de la politique de maintenance. Cette partie

regroupe quatre tâches principales.

8.1.1. Etude technique :

rechercher des améliorations dans le système de production susceptibles

d‟apporter la valeur ajoutée recherchée;

participer à la conception des travaux neufs tout en tenant compte de

l‟aspect maintenance de l‟appareil de production;

participer à l‟analyse des accidents de travail pour essayer d‟y remédier en

apportant des consignes de sécurité dans un premier lieu, et des actions de

maintenance corrective et préventive dans un second lieu.

8.1.2. Préparation et ordonnancement :

établir les fiches d‟instructions nécessaires pour effectuer les interventions;

constituer la documentation pour tous les genres d‟intervention;

établir les plannings des interventions préventives et d‟approvisionnement (la

politique de gestion du stock étant dépendante de celle de l‟entreprise);

recevoir et classer les documents relatifs à l‟intervention.

8.1.3. Etude économique et financière :

gérer les approvisionnements pour optimiser la gestion des matières

premières nécessaires au processus de production;

analyser les coûts de maintenance, de défaillance et de fonctionnement, ce

qui aura un impact direct sur la politique de maintenance choisie par

l‟entreprise manufacturière et aussi sur le coût de production;

participer à la rédaction des cahiers de charges pour tenir compte de la

maintenabilité et de la fiabilité des systèmes à commander;

gérer le suivi et la réalisation des travaux pour ainsi mettre à jour la partie

historique du dossier technique des machines.

8.1.4. Economique et financière :

choisir des procédures de maintenance corrective, préventive conditionnelle

et préventive systématique;


18

déterminer des domaines d‟actions préventives prioritaires;

étudier les procédures de déclenchement des interventions;

élaborer et choisir les procédures de contrôle;

élaborer et choisir les procédures d‟essai et de réception des nouveaux

équipements pour assurer l‟existence des différents éléments nécessaires à la

maintenance;

assurer la sécurité dans l‟organisation pour faire régner un climat de

confiance.

8.2. La fonction exécution - mise en œuvre

Pour cette fonction, une expérience considérable sur le matériel des

entreprises modernes et une connaissance approfondie des différentes technologies

sont nécessaires.

Les principales tâches pour remplir cette fonction sont les suivantes :

installer les machines et le matériel (réception, contrôle, etc.);

informer le personnel sur la façon d‟utiliser les équipements et faire la mise à

niveau;

appliquer les consignes d‟hygiène, de sécurité et des conditions de travail ;

gérer l‟ordonnancement et l‟intervention de la maintenance et établir le

diagnostic de défaillance du matériel;

coordonner les interventions de la maintenance et remettre en marche le

matériel après intervention;

gérer les ressources matérielles (les pièces de rechange, l‟outillage…).

8.3. La fonction documentation

Le troisième type de fonction, à savoir la documentation, est complémentaire

aux deux autres. Ses principales tâches consistent à :

établir et mettre à jour l‟inventaire du matériel et des installations ;

constituer et compléter les dossiers techniques, historiques et économiques

ainsi que le dossier des fournisseurs;

constituer et compléter une documentation générale (technique, scientifique,

d‟hygiène et de sécurité).


19

Pour remplir la fonction étude et méthode avec toutes ses composantes telles que

citées ci-dessus, le personnel doit disposer des dossiers techniques résumant les

caractéristiques techniques des machines et des pièces d‟usure; des fiches

d‟historique résumant les opérations déjà effectuées, en d‟autres termes, le

comportement de la machine; de la documentation du fournisseur constamment

mise à jour et résumant l‟évolution des techniques et des banques de données

(éventuellement).

9. Présentation d’un système de gestion de la maintenance

Le cadre de référence du système de gestion de la maintenance comporte

quatre étapes aussi importantes les unes que les autres.

La première étape concerne la réception du matériel et la documentation.

La deuxième est relative au choix du type de maintenance à effectuer en

fonction des paramètres choisis.

À partir du type de maintenance choisi (préventive conditionnelle, systématique,

corrective ou améliorative), nous précisons les étapes du processus de

maintenance telles que la planification des interventions, les procédures de

détection des défaillances, l‟exécution et le suivi de l‟intervention (troisième

étape).

La dernière étape concerne la réalisation et le suivi de l‟opération de

maintenance.


20

Figure 1.5 : Le système de gestion de la maintenance [KEFF01]

9.1. La gestion des flux d’information

À travers cette dynamique de gestion des opérations dans la maintenance, un

volume important d‟information circule à travers les différents processus. Pour

étudier cet aspect de la fonction maintenance et en se référant aux travaux sur

l‟organisation des systèmes, le système de gestion de la maintenance peut être

subdivisé en trois sous-systèmes :

Recevoir le matériel

Préparer et installer le materièle

Constituer le dossier technique

Choisir le type de maintenance

Planifier

l’intervention

Exécuter l’intervention

Planifier

l’intervention

Mesurer les

paramètres

de contrôle

Planifier

l’intervention

Diagnostiquer

la défaillance

Détecter la

défaillance

Planifier

l’intervention

Faire le suivi de l’intervention

Préciser les

améliorations

Choix du type de

maintenance

Si maintenance

systématique

Si maintenance

conditionnelle

Si maintenance

améliorative

Si maintenance

corrective

Planification

Exécution et

suivi


21

Le sous-système de décision comprend de nombreuses fonctions :

régulation, décision et coordination. Il définit, entre autres, les objectifs

et les orientations à moyen et à long terme.

Le sous-système opérant comprend la réalisation des opérations qui

assurent l‟atteinte des objectifs de l‟entreprise. En général, il reçoit des

intrants, les transforme grâce à l‟utilisation de ressources en extrant

(produits ou services à valeur ajoutée). Il se charge de l‟exécution des

travaux et de la gestion des opérations de maintenance.

le système d’information via le quel, s‟effectuent les échanges entre les

sous-systèmes de pilotage et opérant. Sa structure doit permettre de

relier d‟une manière intelligente les différents intervenants, de leur

acheminer une information complète et de les renseigner sur l‟état du

système en tout temps et ce, d‟une manière sûre et sans équivoque. Un

sous-système d‟information peut être plus ou moins simple à concevoir,

cela dépend essentiellement de l‟effort requis pour investiguer au-delà des

limites de l‟action et pour forcer la révision fondamentale des façons de

faire.

9.2. Informatisation des procédures de maintenance

L‟informatisation et l‟automatisation de la gestion des entreprises a permis

d‟informatiser plusieurs procédures de maintenance. Des fichiers informatiques des

équipements, des interventions, des stocks, des plans et schémas etc. ont ainsi été

créés. L‟intégration de ces fichiers et l‟automatisation des activités de la

maintenance ont été possibles grâce aux progiciels de GMAO (Gestion de

Maintenance Assistée par Ordinateur)[RASO06]. Les événements quotidiens de la

maintenance ont été traités : la panne, l‟exécution du préventif, la gestion des

stocks.

De plus, les progiciels cités ci dessus ont dû s‟interfacer avec les autres

logiciels de l‟entreprise telles que les achats et la comptabilité, déjà informatisés

précédemment. Les grands progiciels de gestion intégrée (PGI) correspondant au

sigle ERP en anglais (Enterprise Resource Planning) représentent une étape


22

suivante dans la rationalisation des processus de l‟entreprise et dans l‟intégration

de la maintenance avec les autres fonctions de l‟entreprise.

9.3. Evolution du domaine technique

L‟informatique a aussi progressé dans le domaine technique de la

maintenance. Les techniques modernes d‟analyse de maintenance et de contrôle ont

vu le jour parallèlement à l‟informatique: analyse vibratoire, analyse d‟huile,

thermographie IR, ultrasons à chaud, etc.

Nous pouvons distinguer parmi ces systèmes deux grands groupes :

Les systèmes d’analyse, quelques fois couplés aux systèmes experts ont été

décrits sous le sigle TTAO (travaux techniques assistés par ordinateur) ou

TMAO (techniques de maintenance assistées par ordinateur). Les systèmes

d‟analyse sont également destinés à fournir de l‟aide à la décision en

diagnostic, pronostic et réparation des équipements aux opérateurs, etc.

Parmi les systèmes d‟acquisition et de contrôle, nous pouvons citer SCADA4

Système de contrôle et d’acquisition des données, contrôles-commandes

des équipements, systèmes de gestion des données techniques et de la

documentation, etc.

Figure 1.6. Coopération des différents systèmes informatiques [RASO06]

4 Voir chapitre 4


23

10. Nouvelles formes de maintenance

La maintenance, de par son appartenance au monde de l‟entreprise, a subi

les évolutions technologiques, organisationnelles et informationnelles de ces

dernières années [SEGU08] Ces évolutions sont liées et interdépendantes et elles

ont profondément modifié les méthodes de travail des acteurs de maintenance

10.1. La télémaintenance

Selon la définition d‟AFNOR la télémaintenance est « la maintenance d‟un

bien exécutée sans accès physique du personnel au bien ». C‟est une architecture

distribuée, basée sur la notion de distance qui permet de transférer les données par

une radio, une ligne téléphonique ou par l‟intermédiaire d‟un réseau local.

[RASO06]

Le centre de télémaintenance et les différents sites peuvent représenter des

entreprises différentes d‟où découle différentes décisions stratégiques de faire,

faire-faire ou faire ensemble :

Le premier choix est d‟exécuter le processus de maintenance à l‟interne.

Cette décision implique une disponibilité des ressources humaines et

matérielles et un système d‟information bien rodé.

Le deuxième consiste à confier partiellement ou totalement le processus à

une tierce entreprise. Cette relation peut prendre plusieurs formes soit la

sous-traitance ou l‟impartition. Cette décision implique la délégation d‟une

partie ou de la totalité du savoir-faire à une entreprise externe.

Le troisième choix, découlant du choix stratégique de faire ensemble,

consiste à s‟allier stratégiquement avec d‟autres partenaires pour réaliser

partiellement ou totalement la maintenance.

Centre de télémaintenance

Site 1 Site 2 Site 3

Figure I.7 : Schéma d'interaction entre les différents composants d'un

système de télémaintenance


24

10.1.1. Apport de la télémaintenance

Les opérations de télémaintenance sont réalisées au travers d‟un système de

télémaintenance incluant un centre expert de la télémaintenance et des sites à

maintenir, elle présente les avantages suivants :

Dans l‟industrie : la télémaintenance s'applique à des systèmes (machines,

automates…), reliés par réseau de télécommunications à des centres de

maintenance. En cas de panne ou de défaillance de ces systèmes, le centre

de maintenance est automatiquement averti et peut déclencher certaines

opérations à distance.

La télémaintenance évite les déplacements coûteux des techniciens

spécialisés du fournisseur pour quelques minutes d'intervention.

Elle permet une certaine rapidité et efficacité d'intervention pour répondre à

toute demande ponctuelle et assure la sécurité des intervenant dans le cas

d‟opérations dangereuses sur des lignes hautes tension, ou dans l'industrie

du nucléaire.

La télémaintenance est souvent associée à un système expert d'aide au

diagnostic des pannes.

La télémaintenance peut se montrer décisive en matière de coûts et de

qualité dans certaines configurations matérielles et dans certains domaines

d„applications.

10.1.2. Domaines d’application

Quelques champs d‟application de la télémaintenance ont été recensés par

[STVR02] :

Informatique : maintenance de matériel informatique à distance

(photocopieur, ordinateur, imprimante,…) où détection et réparation de

défaillances sont réalisées à distance, avec également la planification

d‟interventions préventives de remplacement de consommables ou de

réglages divers [IVAN03],


25

Médecine : télémaintenance de matériel, télédiagnostic, télésurveillance et

même téléchirurgie de patients permettant de réduire les coûts de

disponibilité de personnels qualifiés en plusieurs lieux ; les experts sont

réunis en un même lieu et travaillent à distance [HAZE03],

Aéronautique et militaire : télémaintenance d‟avions ou d‟engins militaires

à distance afin de maintenir un fonctionnement minimal durant leurs

missions [PERE04], [BRES05],

Situation de danger, de risque pour l’humain : télémaintenance

d‟équipements nucléaires, de matériels pouvant engager la sécurité des

agents de maintenance [IVAN03],

L’industrie : télémaintenance des équipements de production.

Figure 1.8 : Architecture de télémaintenance [RASO06]

10.1.3. Télémaintenance et coopération

L'interprétation des alarmes déclenchées lors de la phase de surveillance

peut être découpée en trois parties :

Le filtrage, dont le but est de limiter la charge d'informations des alarmes,

afin d„essayer de ne présenter que les alarmes "intéressantes",

La localisation qui a pour but de caractériser ou d'identifier la situation de

dysfonctionnement détectée,

Le diagnostic qui a pour but de proposer la cause la plus probable du

dysfonctionnement observé. On réserve souvent le terme de panne au

résultat du diagnostic. La phase de diagnostic a pour but de rechercher les

causes premières des phénomènes observés. Il s'agit donc d'une analyse


26

profonde du procédé. Le télédiagnostic nécessite de connaître le plus

d'informations possibles sur le système distant.

La coopération entre les différents acteurs de la télémaintenance paraît donc

être un point important pour effectuer le télédiagnostic dans les meilleures

conditions. Cependant, même si la coopération entre plusieurs experts permet

d'augmenter la rapidité et la fiabilité des opérations de télémaintenance, les

systèmes actuels permettent rarement de l'exploiter. Celle-ci pourrait pourtant se

montrer décisive dans les opérations de détection, de diagnostic et de prise de

décision, Figure(1.9).

Les systèmes de télémaintenance coopérative permettant de réduire les coûts et

d'augmenter la vitesse et l„efficacité de réparation sont des systèmes spécifiques,

pour des applications bien déterminées. Peu d„études scientifiques ont été établies

pour la réalisation de ces systèmes ou pour établir des approches méthodologiques.

La première étape de l„approche méthodologique et générale de l„activité de

coopération distante est la connaissance précise de ce qu„est la coopération.


27

10.2. La e-maintenance

Avec l‟extension d‟Internet, les systèmes de télémaintenance émergent vers le

concept d‟e-maintenance. Le système d‟e-maintenance sera implémenté sur une

plateforme distribuée coopérative intégrant différents systèmes et applications de

maintenance [RASO06]. Cette plateforme doit prendre appui sur le réseau mondial

d‟Internet (d‟où le terme e-maintenance) et la technologie web permet d‟échanger, de

Figure 1.9 : Schéma fonctionnel d’un système de télémaintenance [STVR02]

Signaux

Système

Cap

teurs

Act

ionneu

rs

Voir Comprendre Agir

Alarmes

Pannes

Propositions

d’actions

COOPERATION HUMAINE =

FACTEUR D’EFFICACITE

Génération

d’alarmes

Fil

trag

e

Loca

lisa

tion

Dia

gnost

ic

Aide à la décision Alarmes Pannes

identifiées

Interprétation

Signaux Décision


28

partager et de distribuer des données et des informations et de créer ensemble des

connaissances.

L‟architecture d‟e-maintenance se fait via un réseau web qui permet de coopérer,

d‟échanger, partager et de distribuer ces informations aux différents systèmes

partenaires de ce réseau. Le principe consiste à intégrer l‟ensemble des différents

systèmes de maintenance dans un seul système d‟information [MULL05]. Les

systèmes proposent différents formats d‟information qui ne sont pas toujours

compatibles pour le partage ce qui nécessite la coordination et la coopération entre

les systèmes pour les rendre interopérables. D‟après [SPAD04], l‟interopérabilité est

« la capacité qu‟ont deux systèmes de communication à communiquer de façon non

ambiguë, que ces systèmes soient similaires ou différents. On peut dire que rendre

interopérable, c‟est créer de la compatibilité. » L‟architecture d‟e-maintenance doit

alors assurer l‟interopérabilité avec chacun de ces différents systèmes.

10.3. La s-maintenance

Le «s» de la s-maintenance, signifie sémantique [RASO05] et est une

architecture encore plus performante au niveau de la communication et de

l‟échange des données entre les systèmes. Ce système prend appui sur le concept

d‟e-maintenance avec un échange d‟informations basé le web sémantique. La

sémantique de l‟information échangée nécessite la création d‟ontologie du domaine

commune aux différents systèmes. Elle permet d‟utiliser et créer des connaissances

et des compétences ce qui aboutit à l‟utilisation des techniques du management des

connaissances et permet de capitaliser des connaissances acquises. Les systèmes

collaborent, ce qui suppose un effort coordonné pour résoudre ensemble des

problèmes.

L‟architecture d‟une plateforme de s-maintenance prend appui sur

l‟architecture d‟e-maintenance où l‟interopérabilité des différents systèmes intégrés

dans la plate-forme est garantie par un échange de connaissances représentées par

une ontologie. Afin que le partage de l‟information dans le réseau coopératif

d‟e-maintenance soit sans difficulté, afin de formaliser cette information d‟une façon

à pouvoir l‟exploiter dans les différents systèmes faisant partie du réseau. En

approfondissant la coordination entre les partenaires du réseau et nous élaborons

une base ontologique du domaine de partage de l‟information.


29

10.4. La maintenance distribuée

La maintenance distribuée est définie comme une approche de mise en

oeuvre de la maintenance basée sur l‟analyse des activités et des ressources selon

une approche réseau. L‟architecture du système résultant comprend un ensemble

de processeurs (humains, matériels et informationnels), internes ou externes à

l‟entreprise, qualifiés pour réaliser un ensemble de processus. Les couples

processus-processeur sont sélectionnés selon une analyse des impacts techniques,

stratégiques et économiques.

Ainsi, lors d'une opération de télémaintenance, pour établir le diagnostic, les

experts humains ou logiciels peuvent se baser sur un ensemble d'informations

stockées en temps réel dans une base de données (qui représente l'état des

équipements à surveiller).

Figure 1.10 : Fonctionnement d'un système de maintenance utilisant les

informations d'une base de données [KEFF01]

Les systèmes de télémaintenance sont habituellement constitués des trois parties

qui sont la surveillance, le diagnostic et la maintenance proprement dite. Ces

tâches peuvent être réalisées par des opérateurs humains ou par des systèmes

technologiques (capteurs, réseaux de neurones…). Elles peuvent être effectuées sur

place ou à distance pour au moins une part d'entre elles.

Activité de

maintenance

Ressources

humaines,

Matérielles

Stratégies de

maintenance

Capteur et cameras

Système de surveillance Diagnostique

Pronostique

Equipement à surveiller

Base de données


30

11. Conclusion

Un programme de gestion de la maintenance ne peut atteindre les résultats

voulus sans la préparation du terrain et sans l‟implication du personnel. Ces deux

conditions sont importantes pour la réussite d‟un système de gestion de la

maintenance. De plus, il faudra assurer la communication et la coopération

entre les différents membres de l‟équipe, ces deux aspects de la maintenance feront

l‟objet du chapitre suivant.

Chapitre 2: Coopération et collaboration

31

Chapitre 2

Coopération et

Collaboration


32

1. Introduction

Dans le chapitre précédant, nous avons présenté les systèmes de

e-maintenance comme étant des systèmes coopératifs complet, permettant

d‟appliquer et de valider de nombreux concepts de coopération, au sein d‟une

organisation, dont la complexité résulte de la nécessité de mettre en relation dans le

temps et dans l'espace, différents acteurs, possèdant chacun un des métiers

nécessaires à la maintenance. Face à ce constat, la coopération se propose de

substituer au schéma linéaire en un schéma d'organisation pluridisciplinaire.

2. Coopération et collaboration

2.1. Qu’est ce que la coopération ?

Il n‟existe pas de consensus sur une définition ou sur une conceptualisation

précise de la coopération [SMIT95]. Face au nombre important de définitions de la

coopération et du fait de sa proximité avec d‟autres concepts, nous allons présenter

quelques définitions qui permettent de cerner les principales facettes de la

coopération. Etymologiquement, le terme « coopération » vient de l‟association de la

racine operare et du préfixe co, i.e. travailler ensemble, conjointement. Cette idée de

travail commun est retrouvée dans la définition du Petit Robert qui définit la

coopération comme « l‟action de participer à une œuvre commune. Coopérer

consiste à agir, travailler conjointement avec quelqu‟un au succès de quelque

chose, à l‟exécution d‟un projet commun ». De cette définition, il ressort deux idées

importantes : la coopération est une action ayant pour but la réalisation d‟un

travail commun. [DAME00] parle d‟action finalisée. D‟autre part la coopération se

définissait surtout comme une activité qui vise à répondre à un besoin, et non

comme une fin en soi.

Dans la littérature, la plupart des définitions mettent l'accent sur le processus par

lequel des individus, des groupes et des organisations travaillent ensembles,

interagissent et entrent en relation dans le but d'un gain ou d'un bénéfice mutuel

[SMITH95]. La coopération est une situation dans laquelle les objectifs des parties

prenantes sont positivement liés [TJOS]. L‟atteinte de l‟objectif du but de l‟un aide

les autres à atteindre leurs buts.


33

La notion d‟interaction est fondamentale, la coopération ne se limitant pas à

un simple échange d‟informations. [DAME00] insiste sur l‟idée de relations de

réciprocité. [SOUB94] ajoutent que le coût spécifique de la coordination est inférieur

au bénéfice de celle-ci dans la poursuite de l‟objectif. La coopération entre plusieurs

acteurs implique l‟existence d‟une volonté de coopérer de la part des acteurs, qui est

le résultat d‟un calcul individuel sur l‟intérêt de la coopération. Si on reprend les

travaux de [AXEL92], la coopération est fondée sur un calcul donnant-donnant.

Cette volonté est liée à la nature et au niveau d‟interdépendance entre les parties,

qu‟elle soit liée à la division du travail cité par [DAME00] ou à l‟appartenance à un

groupe. L‟accent a été mis sur les divergences d‟objectifs des individus et de ce fait

de la nécessité que les individus soient dépendants pour qu‟ils coopèrent. La

coopération peut se définir alors comme un accord, un engagement formel ou

informel (de durée variable) impliquant une interaction entre les membres de

différentes fonctions ou métiers de l‟organisation, qui vont combiner ou mettre en

commun leurs ressources (compétences, …) afin de réaliser l‟objet de l‟accord et

d‟atteindre des objectifs communs et individuels.

En résumé, la coopération est avant tout une action. Cette action a un

caractère particulier : elle est conjointe, ce qui implique qu'il y ait plusieurs

personnes en cause dans la coopération au sein d‟une équipe de maintenance. On

coopère pour améliorer les conditions de réalisation de sa tâche en espérant ainsi

réparer les défaillances actuelles et anticiper sur les dysfonctionnements ultérieurs.

2.1.1. Un cadre temporel

Il est très important de définir précisément un cadre temporel à la

coopération. La gestion de projets s'accommode mal de périodes informelles de

travail collectif. Pourtant c'est à cette condition que les acteurs coopèrent

effectivement. A des moments précis dans le déroulement du projet on doit identifié

des "zones de coopération" où les acteurs doivent produire conjointement une

solution.

2.1.2. Un cadre spatial

Le plus souvent on considère que la coopération implique la co-présence,

physique ou virtuelle (à travers un réseau avec des outils de travail collaboratif). On


34

peut se demander si l'espace partagé ne peut pas être suffisamment fédérateur pour

constituer un cadre spatial à la coopération. Quand on dit "espace partagé", on

entend un environnement informatique par exemple avec des outils et des modèles

partagés.

2.1.3. Un cadre conceptuel

La coopération implique un partage au niveau des connaissances. Le cadre

conceptuel est à minima un ensemble de connaissances communes permettant

d'arriver à un minimum de compréhension réciproque. Cela implique une période

d'apprentissage.

Ce cadre conceptuel repose sur :

des règles qui sont d'une part des règles de fonctionnement mais aussi des

règles liées au produit et au métier. Le plus souvent on voit apparaître des

règles inter métiers locales au collectif.

Des objets qui sont en l'occurrence des modèles CAO, mais les travaux les

plus nombreux référence aux croquis et schémas comme objets privilégiés.

Localement ces objets sont parfois la représentation de symboles et

acquièrent un statut de convention.

Ces conventions peuvent avoir une dimension locale (les entités de

coopération, "points de départ") mais aussi une dimension plus large (le

dessin industriel est un exemple de convention partagée dans le domaine de

la mécanique). Il est intéressant de souligner le caractère dynamique et

versatile du processus.

2.1.4. Comment distinguer « coopération » et « collaboration » ?

Il est souvent fait référence aux termes de coopération et de collaboration de

manière interchangeable. Si les dictionnaires renvoient chaque terme l‟un à l‟autre

comme parfaitement équivalents, des distinctions apparaissent par l‟usage de ces

mots insérés dans un énoncé scientifique. [CERIS99] attribue à ce souci de clôture

sémantique la distinction entre des situations d‟apprentissage différentes. Il choisit

la distinction opérée par les ergonomes qui s‟appuie sur la répartition des tâches.


35

La coopération désigne selon cette orientation, «une organisation collective

du travail dans laquelle la tâche à satisfaire est fragmentée en sous-tâches.

Chacune de ces sous-tâches est ensuite affectée à un acteur, soit selon une

distribution parfaitement horizontale dans laquelle tâches et acteurs sont

équivalents, soit selon une logique d‟attribution en fonction des compétences

particulières de chacun ».

La collaboration quant à elle se définit par « une situation de travail collectif

dans laquelle tâche et but sont communs. Tous les acteurs travaillent sur les

mêmes points. » La nature des opérations est du même ordre [BIGN99]. C‟est la

principale distinction avec la coopération. Cerisier évoque l‟idée que dans la

pratique, les activités collectives conduites relèvent souvent partiellement d‟une

logique de coopération et partiellement d‟une logique de collaboration. En effet, un

projet coopératif peut induire, par exemple, des confrontations collaboratives de

points de vue. De même, des stratégies de partage des tâches peuvent être

remarquées dans des travaux collaboratifs. Cependant, chaque projet fonctionne

selon une logique dominante, coopérative ou collaborative. Cerisier ajoute que ce

choix n‟est pas neutre sur la vie des projets et leur effet sur les apprentissages.

Si la littérature tend à confondre les concepts de coopération et de

collaboration que nous venons de distinguer sur la dimension tâche, la réalité des

pratiques de coopération tend à montrer qu‟un projet coopératif comprend des

étapes collaboratives. Il apparaît donc opportun de s‟orienter vers une définition

globale de la coopération admettant l‟existence de différents types de coopération au

cours du processus de coopération.

Pour cela, [CISS99] s‟est appuyé sur la hiérarchie pour définir le concept de

la coopération, qui est le terme générique recouvrant en fait des niveaux différents

de " rapport à l'autre ". Ils définissent de la manière suivante les mécanismes

généraux de coopération susceptible d'émerger d'un tel dispositif, classés selon le

triptyque coopération/collaboration/co-décision :

Niveaux

hiérarchiques

Définition


36

Coopération

La coopération apparaît quand des actions individuelles

contribuent aux actions des autres et vice-versa

Collaboration

La collaboration est le fait de travailler ensemble dans

l'exécution d'une certaine action, générant une compréhension

commune et une connaissance partagée. Le résultat est ainsi

imputable au groupe tout entier.

Codécision

La co-décision concerne les décisions de groupe ou inspirées

par le groupe, les acteurs étant soit indifférenciés, soit dotés

de statut particulier. La

crédibilité et la création de connaissances partagées et de

reconnaissance mutuelle sont aussi importants que pour la

collaboration.

Tableau 2.1 : Classification des mécanismes de coopération

Donc, La coopération tend à être confondue avec d‟autres formes d‟activités

collectives et plus particulièrement avec la collaboration. Face à ce flou, nous nous

interrogeons sur la mise en évidence d‟une typologie des situations de coopération.

2.2. Les formes de coopération

La forme des processus de coopération est sans doute le critère qui permet le

mieux de cerner le « pourquoi » de la coopération. [SCHM91] distingue trois formes

de base :

- La forme augmentative a pour but d‟augmenter les capacités cognitives des

acteurs d‟un projet, considérées comme équivalentes et limitées, en combinant

ces capacités pour répondre au problème de rationalité limités étudié par Simon

[SIMO57].

- La forme intégrative vise à répondre au problème de spécialisation croissante

des connaissances d‟une part, et d‟augmentation de la complexité des projets

d‟autre part (complexité au sens de l‟association de multiples techniques,

méthodes ou outils). Il s‟agit de faire intervenir des acteurs sur des sous-tâches

qui correspondent à leur savoir-faire, et d‟intégrer ces sous-tâches dans un

ensemble performant et cohérent,


37

- La forme confrontative vise à obtenir un consensus qui atténue ou supprime

les problèmes de contestabilité des décisions prises, alors que des acteurs aux

savoir-faire similaires mais aux objectifs variés portent un avis sur ces

décisions.

Une telle typologie peut permettre de définir, pour un certain nombre d‟activités

coopératives, les objectifs locaux de ces activités, les savoir-faire et les modes

d‟organisation de ces savoir-faire à mettre en œuvre pour atteindre ces objectifs,

comme par exemple pour les activités de diagnostic [JOUG99].

D‟autres typologies sont plus particulièrement basées sur la façon dont est mise en

œuvre la coopération (ou sur les modes de coopération), c‟est à dire sur les

caractéristiques des acteurs concernés, et sur les modalités d‟occurrence des

activités coopératives.

2.2.1. Les modes de coopération

Il existe différents modes de coopération essentiellement Homme-Homme,

mais également Homme-Machine.

Dans le cadre de la coopération Homme-Machine, [MILL95] définit la coopération

horizontale comme un moyen de réguler l‟activité humaine de supervision au moyen

d‟un partage des tâches entre l‟opérateur et un outil d‟aide à la décision ou à

l‟action. Cette structure de coopération comprend deux décideurs : l‟un humain et

l‟autre artificiel entre lesquels sont partagées les décisions à prendre. Ce partage est

réalisé par un allocateur de tâches selon des critères de performance de chaque

décideur mais également en tenant compte des capacités de chacun des acteurs.

Dans la coopération verticale, l‟outil ne fait que proposer des conseils à l‟opérateur

qui reste le décideur final.

[JOHA88] et [SCHM91] on proposé d‟avantage de critères pour qualifier les

modes de coopération : le lieu, le temps, et la nature des relations entre les acteurs.

Dans la coopération dite « à distance » les acteurs coopérants au même endroit sont

capables d‟interagir librement, alors que les acteurs coopérants à distance sont

contraints dans leurs interactions par la disponibilité et les capacités du moyen de

communication.


38

Les différentes tâches ou sous-tâches d‟un travail coopératif peuvent être effectuées

simultanément (coopération synchrone) ou reportées dans le temps (coopération

asynchrone). L‟intervalle de temps entre deux tâches coopératives varie d‟autant.

Les sous-tâches peuvent aussi être réalisées comme une suite d‟actions étroitement

couplées ou comme une série d‟actions interconnectées.

Dans le mode collectif du travail coopératif, les individus coopèrent ouvertement

et consciemment : ils constituent un groupe qui a une responsabilité commune.

Dans le mode distribué, au contraire, les individus sont semi-autonomes. Chacun

peut modifier son comportement selon les circonstances et avoir sa propre

stratégie : dans cette situation, chaque travailleur n‟est pas nécessairement

conscient des autres ni de leurs activités : ils coopèrent au travers de leur espace de

travail.

Enfin, dans le cadre de la coopération directe, les travailleurs interagissent en

échangeant une information symbolique : ils communiquent, alors que dans la

coopération indirecte, ils coopèrent via un appareillage technique, typiquement une

machine.

Reste à analyser la façon dont les acteurs se coordonnent dans la mise en œuvre de

ces processus coopératifs, et surtout la façon dont ils sont organisés.

2.2.2. Les modes d’organisation

Le travail en commun nécessite de planifier, de coordonner et de réguler les

actions des différents acteurs impliqués dans le système. La manière dont sont

mises en œuvre ces trois activités est étroitement liée aux modes d‟organisation des

acteurs.

Nous avons retenu les travaux de deux auteurs ayant plus particulièrement

travaillé sur la définition des modes d‟organisation: Rasmussen et Mintzberg.

[MINT93].

Rasmussen a définit un certain nombre de modes d‟organisation, allant de

l‟autocratie à l‟anarchie, en passant par les modes d‟organisation hiérarchique,

bureaucratique, démocratique et diplomatique :


39

- L’organisation autocratique, un seul décideur a la responsabilité de la

coordination des activités entre les différents acteurs. Ces acteurs coopèrent

d‟ailleurs essentiellement dans l‟action par échanges d‟informations, puisqu‟ils

n‟ont aucun pouvoir de décision.

- L’organisation hiérarchique est stratifiée. La coordination est distribuée de

telle manière qu‟un décideur d‟un niveau donné évalue et planifie les activités

du niveau inférieur.

- L’organisation bureaucratique donne lieu à une coordination hétérarchique,

où les décideurs peuvent intervenir dans les domaines de leurs supérieurs ou

subordonnés pour coopérer (la hiérarchie des décisions est différente de celle

des acteurs).

- L’organisation anarchique, chaque opérateur planifie sa propre activité, sans

interaction avec les autres décideurs. La communication existe seulement dans

le contenu du travail. La coordination relative à une organisation démocratique

entraîne une interaction et une négociation entre tous les acteurs de

l‟organisation.

- L’organisation diplomatique Chaque décideur négocie avec ses voisins

concernés et le flux d‟informations est localement planifié.

2.2.3. Modes de coordination

[MINT79] a défini quant à lui cinq modes de coordination : par ajustement

mutuel, par supervision directe, par standardisation des procédures, des résultats

et des qualifications.

- L'ajustement mutuel : Il réalise la coordination du travail par simple

communication informelle. Grâce à l'ajustement mutuel, le contrôle du travail reste

entre les mains des collaborateurs. A cause de sa simplicité, l'ajustement mutuel

est naturellement utilisé dans les organisations les plus simples. Paradoxalement, il

est aussi utilisé dans les organisations les plus complexes parce qu'il est le seul qui

marche dans des circonstances extrêmement difficiles.

- La supervision directe : A mesure qu'une organisation croît et quitte l'état de

simplicité primitive dans lequel elle se trouvait au départ, on voit apparaître un

second mécanisme de coordination. La supervision directe est le mécanisme de

coordination par lequel une personne se trouve investie de la responsabilité du

travail des autres.


40

- La standardisation des procédés : En cas de standardisation, la coordination

des diverses parties est incorporée dans le programme de travail dès la conception,

les besoins de communication s'en trouvent donc réduits. Les procédés de travail

sont standardisés lorsque le contenu du travail est spécifié ou programmé.

- La standardisation des résultats : Il est également possible de standardiser les

résultats du travail (par exemple en spécifiant à l'avance les dimensions du produit,

ou la performance à atteindre). Dans ce cas peu importe aux différents intervenants

comment l'autre fait son travail, l'important est que chacun puisse compter sur les

qualités définies des travaux ou produits intermédiaires.

- La standardisation des qualifications : Il arrive que ni le procédé ni les

résultats ne puissent être standardisés et qu'une certaine coordination soit

néanmoins nécessaire. Une solution est de standardiser la qualification et le savoir

des personnes qui effectuent le travail. La formation de ces personnes est donc

spécifiée. La standardisation des qualifications parvient indirectement au résultat

qui est obtenu de façon directe par standardisation des procédés ou des résultats.

Par exemple, lorsqu'un chirurgien et un anesthésiste se trouvent dans une salle

d'opération, ils ont à peine besoin de communiquer; grâce à la formation que

chacun d'entre eux a reçue, il sait exactement à quoi s'attendre de la part de

l'autre.

Dans certains modes d‟organisation, comme dans le cas de la

standardisation des procédures, l‟allocation des rôles et des tâches est rigide, et

l‟organisation ne permet pas de résoudre des problèmes posés par des situations

nouvelles. Dans d‟autres, comme dans le cas ou le moyen principal est l‟ajustement

mutuel, l‟organisation peut résoudre des problèmes pour lesquels elle ne dispose

pas de procédure toute faite. Dans ces cas, pour spécifier les fonctionnalités

coopératives d‟un système, il est important de décrire un modèle de résolution

collective de problème.

Mais peut-on dire qu‟il existe une véritable coopération entre les membres

d‟une organisation autocratique, puisque la décision est réservée à une seule

personne et tous les autres acteurs n‟ont qu‟à suivre ses ordres, il n‟y a donc pas de

coopération dans la décision. De même, est-il possible de mener une action

commune dans une organisation anarchique ou chacun fait ce qu‟il veut et

uniquement ce qu‟il veut, et il n‟y a donc de coopération ni dans les décisions, ni


41

dans l‟action ? Ces deux modes d‟organisation extrêmes nous semblent constituer

des critères déterminants de qualification des situations non coopératives.

La typologie de Mintzberg nous permet quant à elle de déterminer les

situations coopératives, mais incompatibles avec la génération d‟innovations, qui

est notre principale préoccupation.

Nous proposons de nous baser sur ce critère du mode d‟organisation, en plus des

définitions de Schmidt [SCHM91] sur la performance des activités coopératives,

pour définir un outil de détection des situations coopératives.

2.3. Les comportements et connaissances des individus lors de la coopération

Les comportements humains lors d‟une coopération représentent une part

importante de la coopération proprement dite ; en effet, il ne suffit plus de

rassembler plusieurs experts même très compétents pour obtenir un résultat

satisfaisant de coopération. Des phénomènes humains négatifs peuvent apparaître.

Les personnes peuvent par exemple produire simultanément les mêmes résultats ce

qui n‟est pas très profitable lors d‟une coopération. Il est donc important de

connaître les travaux déjà réalisés dans ce domaine.

2.3.1. Comportement individuel

Chaque personne intervenant dans la résolution d‟un problème possède une

façon propre de raisonner, des connaissances spécifiques ainsi qu‟un

comportement que nous allons essayer de préciser. Les différentes personnes

utiliseront leurs connaissances propres pour résoudre les problèmes qui leur seront

soumis. La modification des connaissances est un domaine de recherche à part

entière, on utilise par exemple dans certain cas des bases de données, ou des

graphes conceptuels.

2.3.2. Comportement collectif

Les comportements individuels engendrent des comportements collectifs

complexes ; certains chercheurs se sont intéressés à les classer le plus simplement

possible. La coopération dans son ensemble peut être vue comme un ensemble de

six types primitifs de coopération :


42

Equivalence : une coopération par équivalence est définie par un ensemble

d‟agents, un ensemble d‟informations partielles (produites par n‟importe quel

agent), et un critère, utilisé pour choisir l‟un des agents. Quand plusieurs

agents coopèrent par équivalence, cela signifie que chacun des participants

est équitablement susceptible de produire une grosse partie de la solution au

problème.

Mutation : une coopération par mutation est définie par deux agents et une

fonction reliant la sortie du premier à l‟entrée du second. Quand différents

agents coopèrent par mutation, cela signifie qu‟une grande partie de

l‟information produite par l‟un des agents est utilisée par les autres.

Spécialisation : une coopération par spécialisation est définie par un agent,

un ensemble d‟agent et un ensemble d‟informations dans lequel est

spécialisé l‟un des agents. Quand des agents coopèrent par spécialisation,

cela signifie qu‟une partie spécifique de l‟information est toujours produite

par le même agent.

Redondance : une coopération par redondance est définie par différents

agents, un ensemble de parties d‟information et trois fonctions. La première

fonction vérifie qu‟il y a des attributs communs dans les éléments produits

par les agents, la seconde informatise un nouvel élément en fonction des

attributs communs, enfin, la troisième fonction est utilisée comme un critère

de fusion. Quand on observe une coopération par redondance, cela signifie

que les agents produisent la même information.

Complémentarité : une coopération par complémentarité est définie de

manière similaire à la coopération par redondance, excepté qu‟il y a différents

attributs non communs entre les éléments produits par les deux processus.

L‟expertise commune de certains attributs peut être utilisée pour guider le

processus de fusion. Quand il y a coopération par complémentarité,

différents éléments sont produits par chaque agent et doivent être fusionnés.

Simultanéité : une coopération par simultanéité signifie que différents

agents produisent des éléments indépendants d‟information en même temps.

Ces éléments ne doivent pas être fusionnés.

A partir de ces types primitifs de coopération, on peut réaliser une coopération

composée dans le but de modéliser les séquences de coopération pendant


43

l‟intersection, chaque type de coopération peut être composé à partir des six types

de coopération vue précédemment.

2.3.3. Organisation d’un groupe de membres coopérants

Un groupe est souvent définie comme étant un ensemble d‟entités réparties

et distinctes qui sont reliées par but commun. Un groupe peut être actif ou passif

(selon qu‟il existe un échange de données entre les membre ou pas), dynamique ou

statique (selon que les membres peuvent changer leurs rôles pendant le coopération

ou non) . Ouvert ou fermer (selon qu‟il accepte ou non l‟interaction des membres

qui n‟appartiennent pas au groupe), déterministe, non déterministe ou anonyme

(les membres du groupe se connaissent tous, seulement quelques membres se

connaissent ou aucun ne se connaît), permanent, à la longue durée ou à courte

durée (selon la tache à réaliser).

La structuration des groupes et du travail peut être décrite à deux niveaux

différents : niveau statique ou niveau dynamique.

2.3.3.1. Organisation statique

Elle reflète généralement la structure relativement stable dans le temps d‟une

organisation. Elle comprend d‟une manière générale :

Des projets,

Des activités au sein de ces projets,

Des tâches à accomplir et à coordonner au sein de ces projets,

Des individus, lesquels sont membres d‟un projet et participent à une ou

plusieurs activités qui les caractérise au sein d‟un projet (chef, exécutant,

visiteur, …), d‟une activité (responsable, consultant, …) ou d‟une tâche,

Des documents, qui peuvent être publics ou appartenir à un projet

spécifique ou une activité particulière.

On peut donc identifier les aspects spécifiques de cette organisation statique :

La création et la destruction des projets, des activités et des tâches

L‟ajout ou suppression de membres (individus ou document) à un projet,

activité ou la tâche,


44

Le contrôle de la sécurité : en effet, l‟appartenance d‟un individu à un projet,

une activité ou une tâche, et le rôle qu‟il y joue, déterminent les droits qu‟il

possède sur les documents présents dans la coopération,

La persistance des données

2.3.3.2. Organisation dynamique

Elle reflète généralement la structure des utilisateurs effectivement connectés

et des données effectivement manipulées à un instant précis. Elle est en quelque

sorte une instance dynamique de la structure statique précédemment décrite. Le

terme de session est souvent employé dans la littérature pour nommer les éléments

de cette instance. La notion de groupe est prépondérante dans le travail coopératif.

Les utilisateurs de telles applications sont regroupés en fonction de différents

critères qui peuvent être : la distance, l‟affinité, les compétences, la partie du travail

qu‟ils réalisent…etc.

On peut identifier des aspects spécifiques de l‟organisation dynamique :

L‟identification, la connexion et la déconnexion,

La création d‟une session, l‟entrée d‟un utilisateur dans la session, la sortie

d‟un utilisateur d‟une session et la destruction d‟une session. De tels

mouvements peuvent être explicites (un utilisateur demande à rentrer ou à

sortir d‟une session de travail coopératif correspondant à une activité dont il

est membre) ou implicite ( un utilisateur ouvrant un document déjà édité par

un autre membre d‟une même activité se retrouve automatiquement dans la

même session que lui) ,

La cohérence des sessions.

Enfin en ce qui concerne l‟organisation dynamique d‟un groupe de membres

coopérants, on peut dégager les caractéristiques suivantes :

La charge de travail peut varier considérablement dans le temps : tous les

membres coopérants peuvent réagir à un événement simultanément, puis

rester inactif un long moment,


45

La charge de travail peut varier dans l‟espace ; deux membres peuvent

effectuer une opération conjointement pendant que les autres en attendent le

résultat pour réagir,

Le rôle et les droits des participations peuvent également changer : un

membre observateur (donc inactif) peut devenir un membre acteur,

La qualité de service demandée peut être modifiée : par exemple si l‟on

introduit une connexion vidéo entre deux sites.

2.4. Exclusion mutuelle

Plusieurs travaux traitent de l‟exclusion mutuelle dans les systèmes répartis.

Ces algorithmes peuvent être classés en deux catégories selon la stratégie d‟accès à

la section critique.

L’utilisation d’un jeton

La première catégorie des algorithmes repose sur l‟utilisation d‟un jeton qui

circule entre les sites communicants. L‟unicité de ce dernier garantie d‟une façon

triviale l‟utilisation de la section critique. Le problème majeur dans cette catégorie

d‟algorithmes est l‟ordre de passage du jeton entre les sites, plusieurs sont les

travaux présentés comme solution de ce problème, tel que l‟utilisation d‟un ordre de

priorité entre les sites ou l‟utilisation d‟une structuration des sites sous forme

d‟arborescence. Parmi les caractéristiques les plus importantes de ces algorithmes,

on trouve la mobilité de l‟arborescence pendant le passage du jeton entre les sites et

la réduction importante du nombre de messages qui peut être de l‟ordre de log(n),

ou de quatre (dans le cas d‟une arborescence étoile, avec le site de plus forte

probabilité de demande de la section critique au centre). [RAY89] a proposé un

algorithme qui repose sur l‟utilisation d‟un arbre statique pour la structuration des

sites, afin de diminuer le nombre de messages, mais sa structuration n’est pas

trop tolérante aux fautes.

Demande de permission

La deuxième catégorie est fondée sur le concept de permission, si un site Pi

veut entrer en section critique, il doit demander et obtenir la permission d‟un

certain nombre de sites. Selon a structuration des sites, avec ou sans ordre de

priorité, cette catégorie peut être subdivisée en deux sous classes, dans la première

sous classe, si un site Pi a obtenu la permission d‟un site Pj alors cette permission


46

ne concerne que le site Pj, et on parle dans ce cas de la permission Individuelle,

dans la deuxième sous classe la permission attribuée par le site Pj au site Pi engage

tous les sites qui doivent obtenir la permission (d‟entrée en section critique) de la

part de Pi et dans ce cas on parle d‟une permission d’Arbitre. Dans la deuxième

sous classe, quand le site Pj sort de la section critique il doit envoyer un message de

libération de la section critique au site Pj afin que ce dernier puisse satisfaire

d‟autres demandes.

3. La décision collaborative

Karacapilidis [KARA01] associe la décision collaborative à un processus

"argumentatif" où chaque participant doit tenir compte des autres collaborateurs

pour comprendre les contraintes et les solutions au problème posé, les intérêts et

les priorités de chacun.

En intelligence artificielle et système multi agents, Panzarasa [PANZ02] propose la

définition d‟une prise de décision collaborative comme étant associée à un groupe

d‟agents distribués qui coopèrent pour atteindre des objectifs supérieurs aux

capacités individuelles des agents. Une prise de décision collaborative est

généralement associée à un mode de raisonnement distribué selon lequel un groupe

d‟agents travaillent en collaboration via un espace commun de recherche [PANZ02].

En Sciences pour l‟Ingénieur, Laborie définit l‟activité de prise de décision collective

comme une "convergence d'interactions cognitives et visuelles, planifiées ou

opportunistes, où des personnes acceptent de se rassembler pour un objectif

commun, dans une période définie, soit au même endroit, soit dans des endroits

différents, dans le but de prendre des décisions" [LABO06].

Dans le même domaine, Jankovic [JANK06] définit la décision collaborative comme

une décision collective où chaque acteur a des objectifs différents et, souvent même,

conflictuels avec les autres acteurs intervenant dans le processus de prise de

décision.

Ces définitions mettent à nouveau en évidence avec la définition du travail

collaboratif) les différences de point de vue et de dénomination des auteurs

travaillant sur cette problématique. Néanmoins, ces définitions confirment la

possibilité, pour les acteurs collaborant, de poursuivre des objectifs distincts les

uns des autres et celle d‟une alternance de travaux collectifs et individuels au sein

d‟activités de décisions collaboratives.


47

3.1. Le processus de décision collaborative

Il traduit le déroulement d‟une activité assez complexe, pour laquelle il est

difficile de trouver une définition consensuelle. Les modèles de processus existants

concernent, pour la plupart, l‟activité de conception. Voici deux exemples suivis

d‟un autre modèle de décision collective plus générique.

Kvan et Vera [KVAN00 proposent un modèle de processus de conception

collaborative. Ils décomposent l‟activité de conception en une succession d‟étapes

individuelles ou collectives. Ces auteurs considèrent que les acteurs de la

collaboration peuvent travailler individuellement sur des portions du problème.

Laborie propose également un modèle du processus de décision collective, en

s‟inspirant notamment du processus de Kvan et Vera mais en lui conférant un

caractère plus générique.

3.2. Travaux actuels en décision collaborative

L‟actualité des travaux en décision collaborative peut être abordée de

manière similaire à celle des travaux en décision ou en travail collaboratif.

Les approches théoriques de la décision s‟intéressent également à la décision

collaborative :

Ryan [RYAN 02] s‟est attaché à formuler une fonction d‟utilité de la décision

collaborative, avec l‟objectif d‟optimiser cette activité.

Xiao [XIAO05] se base sur la théorie des jeux propre à la décision afin de

modéliser la décision collaborative dans le cadre de conception collaborative,

intégrant ainsi l‟aspect multidisciplinaire de la collaboration dans son

approche de modélisation formelle.

Limayem [LIMA01] propose d‟utiliser une méthode de tri appartenant aux

méthodes d‟aide à la décision afin d‟aborder la décision collaborative en

gestion de projet.

Laborie [LABO06] s‟intéresse à la décision collaborative appliquée au

processus de conception concourante dans le domaine aéronautique. Pour

cela, il propose la mise en place de salles dédiées aux activités de conception

avec un ensemble d‟outils collaboratifs à disposition des acteurs

intervenants.


48

Jankovic [JANK06] se positionne sur un domaine assez proche de celui

Laborie avec l‟automobile. Mais cet auteur propose une approche plus

conceptuelle, en définissant une méthodologie de modélisation des

mécanismes de décision collaborative.

Fu [FU04] se concentre également sur la décision collaborative en

conception. Cet auteur met en évidence les besoins en connaissances

auxquels la décision collaborative fait appel, tout particulièrement en

conception.

L‟évolution des modes de travail et l‟avènement des TIC ont fait apparaître, depuis

quelques années déjà, des travaux de recherche contribuant à la conception,

l‟intégration et l‟utilisation d‟outils informatiques, comme support au travail et à la

décision collaborative. Ces travaux concernent également la préparation de

l‟implantation de ces outils aidant à la décision d‟une équipe. Citons, par exemple :

les travaux de Kronsteiner [KRON05] où les auteurs se concentrent sur une

étude des besoins concernant les environnements mobiles supportant la

décision collaborative.

Dans ses travaux, Parsa [PARS07] présente l‟utilisation d‟un environnement

Internet permettant de partager des connaissances dans le cadre de

décisions collaboratives.

Dans [SOUB05], Soubie et Zaraté ont une approche conceptuelle de la

décision collaborative, en analysant les mécanismes en présence dans les

échanges collaboratifs. Ces auteurs intègrent la gestion des connaissances

aux systèmes collaboratifs d‟aide à la décision.

Les travaux de recherche en décision collaborative concernent plusieurs

domaines applicatifs (l‟automobile, l‟aéronautique,…). Nous pouvons compléter avec

les travaux de Chim [CHIM04] abordant la décision collaborative via Internet et

appliquée en construction, ceux de Wambsganss [WAMB01] sur la gestion du trafic

aérien ou encore de Lario [LARI03] sur la décision collaborative dans la chaîne

logistique.

Ces travaux nous apportent des éléments de modélisation de la décision

collaborative même s‟ils n‟approfondissent pas les mécanismes lui servant de

support.


49

Figure 2.1 : Modèle du processus de décision collective [LABO06]

3.3. Décision collaborative en maintenance

En maintenance, les travaux de recherche s‟intéressant aux problèmes

décisionnels ou collaboratifs dans le contexte applicatif de la maintenance sont peu

nombreux même si quelques travaux existent. Pellegrin [PELL97] a notamment

essayé d‟appliquer les concepts de la théorie de la décision aux enjeux de la

maintenance.

Malgré quelques exceptions, les travaux étudiant la décision collaborative en

maintenance sont généralement liés au développement de plateformes

d‟instrumentation d‟e-maintenance. Citons, par exemple, les travaux de Saint

Voirin [STVR06] où des éléments de modélisation des systèmes coopératifs en e-

maintenance sont proposés. Les travaux de Kolski [KOLS93] sont plus anciens mais

les auteurs se concentrent également sur l‟étude d‟un système de télémaintenance

pour lequel ils étudient les apports et les aides pouvant intéresser un mainteneur

aux différentes étapes d‟une intervention lors de la prise d‟une décision.


50

Certains travaux, comme ceux de Brown, Kaffel ou Anke, se concentrent sur

la décision en maintenance sans intégrer la dimension collaborative. Ces travaux

proposent des architectures servant de support à la prise de décision [ANKE05] ou

simplement une étude approfondie des mécanismes en présence en proposant des

éléments de modélisation ou d‟évaluation des situations étudiées [BROW99],

[KAFF01]. Ces travaux intègrent néanmoins le fait que pour les activités

décisionnelles en maintenance, les besoins en informations (sur le problème, sur la

manière de le résoudre,…) sont un pré requis nécessaire à toute décision.

3.3.1. Formalisation de la décision collaborative

Une décision collaborative peut être résumée de la manière suivante

[SUEG08] :

- chaque acteur appartenant au groupe n‟est pas forcément impliqué dans la prise

de décision, il peut simplement contribuer à une étape comme, par exemple, la

recherche d‟informations nécessaires à la décision,

- le niveau de responsabilité ou de compétence des acteurs joue un rôle important

dans la prise de décision (par exemple, si deux mainteneurs réalisent une

intervention, le plus souvent, l‟un deux, ayant plus de responsabilités que l‟autre,

prendra au final la décision même si le second l‟aide dans cette tâche en lui

fournissant les informations et connaissances en sa possession),

- une décision collaborative est associée à l‟ensemble du processus et de ses

intervenants conduisant à une prise de décision et non à la seule activité

décisionnelle prise par un collectif (correspondant à la codécision),

- les acteurs collaborant ne sont pas forcément humains, une collaboration homme-

machine est également possible et sera abordée dans nos travaux.

4. Conclusion

Le contenu de ce chapitre s‟est intéressé à fournir un cadre théorique, semi

formel du concept de coopération, qui reste pour le moins versatile et flou au point

de vue informatique. Cette démarche s‟est réalisée à travers diverses définitions qui

convergent toutes vers le même objectif, l‟application de la coopération à un

processus de conception innovante. Il convient donc de noter, que la coopération


51

n‟est pas une fin en soi, et qu‟elle n‟a de sens que si elle contribue à l‟amélioration

de performances industrielles ou à la minimisation des conflits. C‟est pourquoi,

notre travail aura pour but de concrétiser toutes les notions et concepts vus

précédemment, dans le cadre d‟un processus de maintenance corrective.


52

Chapitre 3

CSCW :

Computer Supported

Cooperative Work

Chapitre 3: CSCW (Computer Supported Cooperative Work)

53

1. Introduction

Dans l'environnement industriel actuel, les entreprises doivent considérer

leur savoir et savoir-faire comme leur plus grande force afin de pouvoir réagir et

s'adapter, au changement le plus rapidement possible. Ce savoir-faire se retrouve

dans l'ensemble des employés de l'entreprise, c‟est pourquoi, le travail en groupe

devient incontournable, et de manière prépondérante dans l‟activité de

maintenance. Cependant, le travail en groupe coûte cher, tant en terme financier

qu'en heures de soutien et de formation et d'efforts de la direction pour l'imposer.

Mal géré, il peut poser plus de problèmes qu'il n'apporte de solutions. C‟est

pourquoi nous consacré ce chapitre à définir les outils permettant de supporter le

travail coopératif. Après une définition du champ d‟application du CSCW (travail

coopératif assisté par ordinateur), nous consacrerons la plus grande partie de ce

chapitre à présenter les workflows, ces Groupware dédiés à la coordination du

travail coopératif et qui seront au cœur de notre démarche, pour la gestion des

interactions entre experts collaborant dans le cadre d‟un processus de maintenance

coopérative.

2. CSCW (Computer-Supported Cooperative Work)

Le terme anglo-saxon CSCW, "Computer-Supported Cooperative Work", est

employé dans la littérature pour définir l‟ensemble des systèmes informatiques qui

facilitent la coopération d‟individus autour d‟une tâche commune. L‟ordinateur y

est utilisé aussi bien pour réaliser des tâches qui nécessitent de l‟assemblage et de

la coordination (la rédaction d‟un document), que pour réaliser des tâches fondées

sur la communication comme, par exemple, une prise de décision par un groupe

(group decision support system).

L‟autre terme anglo-saxon souvent utilisé en substitution de CSCW est

« Groupware ». Ce terme, initialement employé dans le langage courant des

scientifiques américains, a vite connu une utilisation plus universelle dans la

littérature informatique. En 1978, Peter and Trudy Johnon-Lenz, pionniers dans le

travail coopératif, introduisirent le terme groupware pour définir une activité de

groupe intentionnelle augmentée d‟un support logiciel permettant sa réalisation.


54

2.1. Les Groupwares

Le domaine du Travail Coopératif Assisté par Ordinateur (TCAO) a pour

thème d‟étude les collecticiel (le terme employé dans la communauté française pour

désigner groupware). Dans ce cadre, de nombreuses définitions ont été proposées

pour caractériser un collecticiel dont nous citons la plus courante, celle de C. Ellis :

―Computer-based systems that support groups of people engaged in a common task

(or goal) and that provide an interface to a shared environment." [ELLI91] ―Les

collecticiels sont des systèmes informatiques qui assistent un groupe de personnes

engagées dans une tâche commune (ou but commun) et qui fournissent une interface

à un environnement partagé.” (traduction de A. Karsenty [KARS94]) .

2.2. Modèle du trèfle

Le modèle du trèfle [SALB95], inspiré du modèle conceptuel d‟un collecticiel

proposé par C. Ellis [ELLI94], fournit un cadre conceptuel utile pour déterminer les

requis fonctionnels et mener une analyse fonctionnelle. En effet, selon ce modèle

présenté dans la figure ci-dessous, un collecticiel couvre trois espaces fonctionnels :

Figure 3.1 : Modèle du trèfle [SALB95]

• L'espace de production concerne l‟ensemble des fonctionnalités de production

d‟objets partagés tels que des documents communs et la gestion des accès à ces

données partagées. Par exemple, les éditeurs partagés, définis dans le paragraphe

2.1, sont dédiés à la production.

Production

Communication

Coordination


55

• L'espace de communication correspond aux fonctionnalités permettant

l'échange d'information entre les acteurs du collecticiel. Cet échange est de la

communication homme-homme médiatisée (CHHM) [SALB95].

• L'espace de coordination correspond aux fonctionnalités dédiées à l‟assignation

de tâches et de rôles aux différents acteurs d‟une activité collaborative. Ces

fonctionnalités ont pour but de coordonner les acteurs afin de réaliser une oeuvre

commune. Cette coordination peut s‟exprimer en terme de planification de tâches.

Par exemple, les systèmes workflow.

2.3. Les règles d'or du groupware

Comme nous avons pu le remarquer dans la définition initiale du groupware,

le groupware touche tous les domaines constituant l'entreprise. C'est-à-dire les

hommes et leur management, l'organisation et les processus de travail et les outils

informatiques. Nous pouvons mentionner trois règles de base qui aideront à situer

un système groupware dans ce contexte, et qui rappelleront son importance et son

impact dans l'entreprise.

1- être conscient que le groupware n'est pas qu'un produit logiciel. Il va entraîner

des changements sur les pratiques de management, sur l'organisation et sur

l'informatique de l'entreprise.

- Changement sur le management, d'une part, parce qu'il faudra apprendre

aux employés à travailler en équipe et à accepter de partager leurs

connaissances et leurs informations avec d'autres.

- Changement sur l'organisation. L'entreprise peut être amenée à devoir

reconfigurer ses processus afin de les adapter au travail en groupe. C'est

aussi en principe le "département" organisation qui va définir le projet

groupware et fixer les objectifs de performance.

- Changement sur l'informatique. L'architecture du groupware doit s'appuyer

sur le système d'information de l'entreprise. Cependant, si les systèmes de

communication ne sont pas adaptés pour supporter un système groupware,

il faudra penser à changer l'architecture réseau de l'entreprise.


56

2- Un projet groupware est un véritable projet de management et du management.

Ceci de par son étendue homme, organisation et technologique. Comme tel, le projet

groupware doit respecter les règles de conduite de tout projet.

3 - Un projet groupware est un véritable processus de changement. Ce troisième

point est la conséquence de tout ce qui a été vu jusqu'ici. Cela demande de

travailler avec méthode, tout en restant flexible, et de respecter les trois temps

caractérisant les processus de changement qui sont:

- Réfléchir sur la cible et définir la vision de l'objectif qui seule provoque et

justifie le changement.

- Identifier les acquis, les points forts et ce qu'il y a à améliorer, afin

d'atteindre la cible définie.

- Préparer la transition.

2.4. Implantation d'un groupware

Il n'existe pas une méthode unique et parfaite pour implanter un système

groupware. D'ailleurs, chaque société de conseil en groupware a sa propre marche à

suivre. De plus, suivant l'importance du projet, du budget et du délai, toutes les

étapes ne sont pas nécessairement respectées, alors que d'autres voient leur poids

se réduire. Bien qu'il existe plusieurs manières d'approcher une implantation de

groupware, une ligne directrice se profile derrière toutes ces méthodes, à savoir:

Étude préalable, définir les conditions de mise en œuvre et actions

d'accompagnement.

Identifier les projets porteurs.

Adopter une démarche de conduite du changement.

Impliquer le personnel, formaliser les règles de fonctionnement avec lui,

communication des enjeux, formation et soutien.

Application compréhensible et conviviale pour l'utilisateur.

2.5. Conséquences de la mise en place d’un groupware

2.5.1. Apports théoriques


57

- L'information circulera mieux et plus vite, et sera traitée d'une manière plus

globale, prise dans son environnement, puisqu'il sera alors possible de la comparer

immédiatement à d'autres, ainsi que de la compléter par des informations venant

d'autres sources externes.

- Toute l'information importante est mémorisée et partagée, la capitalisation des

connaissances de l'entreprise s'en trouve ainsi améliorée. Elle est de ce fait

consultable en tout lieu de l'entreprise et en tout temps , par ceux qui en ont besoin

et en ont les droits d'accès.

- Fiabilité accrue dans les processus en garantissant un cheminement identique à

chaque fois et identifié.

- Réduction des coûts. Diminution des frais de déplacement et des frais

d'administration. Réduction également des frais de papier, de gestion,

d'organisation et d'entreposage de tous les documents de l'entreprise à conserver.

- Augmentation de la rentabilité des employés, certaines tâches étant supprimées.

Le nombre de réunions physiques est réduit au profit des forums électroniques, qui

permettent de s'y connecter à "temps perdu". Les temps de déplacement sont, par

conséquent, réduits.

- La communication, collaboration et coordination sont optimisées pour travailler

ensemble, tant en interne qu'avec l'extérieur, fournisseurs, clients, voire même avec

des concurrents pour la réalisation de plates-formes communes de commerce.

- Le groupware permet de par son fonctionnement d'avoir des outils de statistiques

sur le temps d'exécution des différentes tâches, sur le rendement des hommes et

des processus, sur les goulots d'étranglement dans un processus, sur les coûts,

…etc.

2.5.2. Difficultés

La première difficulté est celle découlant de tout projet quel qu'il soit, à savoir

le mener à bien en respectant délai, coûts et spécifications. Les difficultés


58

interviennent dans les trois domaines du groupware, à savoir dans le management,

l'organisation et la technique.

Management

- La volonté de protéger sa connaissance en ne la mettant pas à disposition des

autres va mettre une limite au bon fonctionnement du groupware.

- Un conflit entre reconnaissance par les autres de sa valeur (en diffusant beaucoup

d'informations) et pouvoir va naître chez certains individus.

- Certains peuvent être systématiquement contre tout changement et notamment

ceux provoqués par l'arrivée des nouvelles technologies de l'information.

- De part l'archivage de toute l'information de l' entreprise et des messages des

forums électroniques, certains intervenants peuvent craindre l'utilisation qui sera

faite de leurs interventions et de leurs communications et des jugements en

résultant, ce qui nuit à la spontanéité de leur comportement.

- Un des excès les plus connus est la mise en copie systématique des messages

électroniques qui conduit à occuper inutilement le réseau et à une surcharge

d'informations chez les managers qui perdront alors temps et énergie à les lire et à

en faire le tri.

- Un autre abus est de considérer comme acquis et accepté le contenu de tout

message diffusé par messagerie ou stocké dans la base partagée.

- De plus, les relations peuvent se détériorer en cas de tension entre personnes. Les

échanges électroniques, de part leur sécheresse, ne permettent pas de s'expliquer ni

de se comprendre. Il est d'ailleurs conseillé que les personnes participant à des

forums électroniques se rencontrent avant de commencer à collaborer, afin qu'elles

apprennent à se connaître et sachent quel est le vocabulaire employé et la manière

de penser des autres participants. Finalement que la glace se brise.

Organisation


59

- Le responsable de projet peut voir une résistance à l'introduction du groupware.

En effet, les utilisateurs sont soudain confrontés à une nouvelle application

informatique souvent inconnue, dont ils devront apprendre le maniement, et qui

leur demande de modifier leurs habitudes de travail. L'intérêt pour un outil qui leur

impose une façon de travailler n'est pas immédiate. Par exemple, le workflow donne

l'impression à l'utilisateur de lui imposer son travail à faire à un moment donné,

plus qu'une instruction au téléphone ou une note écrite.

Technique

- La compatibilité des réseaux, poste de travail et entre certaines messageries peut

poser des freins.

- La sécurité, non seulement liée à l'ouverture de l‟entreprise sur le net, mais aussi

à tout ce qui implique la diffusion d'informations sensibles à l'interne, comme par

exemple une "curiosité" déplacée d'employés indélicats, peut poser problème.

2.6. Taxonomies des Groupwares

Dans cette partie, nous présentons trois taxonomies aux caractéristiques

complémentaires afin de définir plus finement ce qu‟est un collecticiel et de cerner

l'étendue des possibilités. La multiplicité des possibilités peut se voir comme un

indicateur du dynamisme de ce domaine, avec, sa compagne immédiate, la

complexité de réalisation logicielle. Les deux premières taxonomies présentées, l'une

selon les types d'application et l'autre Espace-Temps, sont incontournables dans la

littérature du domaine. La dernière taxonomie choisie repose quant à elle sur un

modèle du travail coopératif. Les trois taxonomies exposées, notre première

contribution sera de choisir et de proposer un ensemble de termes issus de ces

taxonomies qui couvrent raisonnablement le domaine de réflexion.

2.6.1. Types d’applications

La première taxonomie consiste en une classification par domaines

d‟application. Aussi cette taxonomie doit souvent être révisée pour prendre en

compte les nouveaux types d‟application. Elle traduit donc une image du domaine à

un instant donné. Pour élaborer une liste des domaines d'application des

collecticiels, nous avons combiné plusieurs taxonomies existantes [ELLI91] [DIX93]


60

[KARS94]. La variété des domaines d'application souligne le dynamisme de cet axe

de recherche. Nous obtenons quatre catégories de collecticiels qui sont :

1- Les applications dédiées à la communication homme-homme médiatisée

(CHHM, ou CMC pour Computer-Mediated Communication) où nous

regroupons les messageries électroniques, les forums de discussion, les

systèmes de vidéoconférence et les mediaspace,

2- Les applications d'édition où nous classons les éditeurs de texte et les

tableaux blancs partagés,

3- Les applications pour la coordination où nous rassemblons les systèmes

workflow, les systèmes d‟aide à la décision et les calendriers partagés,

4- Les applications de jeux en réseau.

2.6.2. Classification espace temps

Figure 3.2 : Classification de J. Grudin [GRUD94]

La classification Espace-Temps repose sur deux caractéristiques, à savoir où

et quand une action est exécutée par un des utilisateurs par rapport aux autres

utilisateurs. Il s‟agit de la classification la plus largement adoptée dans le domaine

du TCAO, nommée Espace-Temps ou matrice Espace-Temps. La classification

Espac

e

Même lieux

Rencontres

informelles

Jeu sur consol

Vidéo

conférence

Edition

partagée

Workflow

Relai

enchainement

tour de parole

Newsgroup

Mél(accés

wwww) SMS

Mél

Post-it

Même

moment

Moment

différents

(prévisibles)

moment différents

(imprévisibles)

Temp

s

1

2

3

4

5

6

7

8

9 Lieux

différents

(imprévisibles

) Lieux

différents

(prévisibles)


61

présentée à la figure ci-dessus est celle de J. Grudin [GRUD94], une version

étendue de la matrice Espace-Temps de C. Ellis [ELLI91].

2.6.3. Taxonomie du travail collaboratif

La taxonomie des collecticiels selon A. Dix [DIX93] repose sur un modèle du

travail coopératif. Ce modèle identifie deux entités impliquées dans le travail

coopératif : les participants (P) et les artéfacts du travail (A), c‟est-à-dire les entités

manipulées permettant aux participants d‟interagir entre eux et avec le système.

Par exemple, ces artéfacts peuvent être les outils mis à disposition comme un outil

pinceau utilisé pour dessiner dans un tableau partagé.

Figure 3.3 : Modèle de travail coopératif [DIX93]

Ce modèle identifie les relations entre ces entités, c‟est-à-dire les participants et les

artéfacts du travail, qui caractérisent le travail coopératif. Il existe trois types de

relation :

la communication directe entre les participants au cours d‟une

activité (orale, écrite, gestuelle, etc),

l‟établissement d‟une compréhension mutuelle pour mener des actions

conjointes et,

la manipulation des artéfacts.

A partir de ce modèle, A. Dix a identifié trois catégories [DIX93] de collecticiels

relatives aux trois relations mises en évidence par ce modèle du travail coopératif :

• Les systèmes de communication Homme-Homme médiatisée (CHHM)

désignent les systèmes dédiés à la communication directe entre les participants.

Cette catégorie de collecticiels regroupe, entre autres, le courrier électronique, les

P P

A

Compréhensi

on mutuelle

Communicati

on directe

Manipulation

des

rétroactions

Artéfact du travail

P :

participant

A : artéfacte


62

forums de discussion, la vidéoconférence et les mediaspace. Nous retrouvons ici

notre catégorie de la première taxonomie.

• Les systèmes de réunions et d’aide à la décision sont des collecticiels dont le

but est de favoriser et d‟aider à la compréhension mutuelle pour faciliter le

déroulement de réunions ou la prise de décisions entre différents participants. Cette

catégorie regroupe donc les systèmes d‟aide à la décision (GDSS) et les systèmes de

réunion virtuelle (bureau partagé) et réelle (tableau blanc réel et partagé).

• Les systèmes d’espaces partagés (shared workspaces) recouvrent les collecticiels

mettant en oeuvre des espaces partagés dans lesquels les participants peuvent

manipuler des artéfacts. Il s‟agit par exemple des éditeurs partagés ou des

calendriers partagés.

2.7. Synthèse

La taxonomie présenté a mis la lumière sur un type particulier de

groupware, dédiés à la gestion de processus (industriels, commerciaux,

administratifs, etc.) et à la coordination des différents intervenants au cours de ce

même processus. Connue sous le nom de « Workflow », ce type de groupware a la

charge de veiller à la bonne circulation des documents et des informations entre les

différents intervenants aux moments clés d‟un processus coopératif tel que la

conception collaborative d‟un produit. C‟est pourquoi nous avons choisi de l‟utiliser

pour mettre en œuvre un système d‟arbitrage de points de vue au sein d‟une équipe

de conception.

3. Les workflows

Cette section sera consacrée à la définition du concept de workflow. Ceci

permettra de mettre en valeur le rôle à la fois stratégique et opérationnel du

workflow, ainsi que ses applications pratiques. Ceci dit, de nombreux experts, font

remarquer que les logiciels de workflow et de groupware sont "A priori,

antithétiques. Le workflow cherche à automatiser les règles formelles en vue de

restructurer les procédures métier de l'entreprise; le groupware essaie de faciliter

les interactions informelles entre les groupes en renforçant les aspects

communication, coordination et coopération du travail en équipe".


63

Il existe toutefois une certaine confusion lorsqu'il s'agit de positionner les concepts

de workflow et de groupware. Le premier est-il un outil réservé aux communications

formelles et procédurales de l'entreprise ? Inversement, le groupware doit-il être

dédié aux relations informelles ? Qu'est-ce que le workflow ? S'agit-il d'un terme

issu du jargon des organisateurs ou emprunté aux informaticiens ? Voilà quelques

questions auxquelles se paragraphe apportera des réponses.

Pour commencer et pour poser clairement les termes de bases, des

définitions seront présentés, notamment celles de la Workflow Management

Coalition (WfMC). Cette organisation internationale, créée en 1993, joue un rôle

fondamental dans la maturation du marché des produits workflow. Elle regroupe

des éditeurs, des utilisateurs et des experts dans le domaine du workflow. Sa

mission est de promouvoir l'utilisation du workflow grâce à la définition de

standards portant sur la terminologie workflow, l'interopérabilité et la connectivité

entre les produits workflow. Cette mission comprend trois axes principaux qui sont

:

- Augmenter la valeur des investissements consentis par les entreprises dans les

technologies workflow.

- Réduire les risques liés à l'utilisation de produits workflow dans les entreprises.

- Contribuer à la croissance du marché du workflow par une meilleure prise de

conscience du rôle du workflow dans les organisations. Un modèle de référence des

systèmes de gestion de workflow (Reference Model for Workflow Management

Systems) a été créé. Il définit les caractéristiques communes des systèmes workflow

et détermine le contexte de développement des standards d'interface en spécifiant

des domaines fonctionnels particuliers. Ce modèle sera présenté en détail dans la

section "Composantes techniques des systèmes de workflow".

3.1. Définition

Conceptuellement, le workflow relève de l'automatisation de processus,

donc de flux informationnels dans lesquels les documents et les tâches associées

sont acheminées d'un participant à un autre selon des règles plus ou moins

détaillées et prédéfinies. Les logiciels de workflow ont des origines multiples.

Certains produits ont été conçus dès le départ comme de purs logiciels de workflow,

d'autres sont des dérivés de logiciels de gestion de documents, de système de

gestion de bases de données ou même de système de messagerie. C'est pourquoi


64

l'approche de la Workflow Management Coalition est très importante, en effet cette

pluralité de produits décourageait les investissements, car les solutions

propriétaires incompatibles entre elles étaient une réelle menace pour la flexibilité

des systèmes d'informations. Regardons maintenant les définitions proposées par la

WfMC :

a) Workflow : Automatisation de tout ou partie d'un processus d'entreprise au

cours duquel l'information circule d'une activité à l'autre, c'est-à-dire d'un

participant (ou d'un groupe de participants) à l'autre, pour action en fonction d'un

ensemble de règles de gestion.

b) Système de gestion de workflow : Système qui définit, implémente et gère

l'exécution d'un ou de plusieurs workflow à l'aide d'un environnement logiciel

fonctionnant avec un ou plusieurs moteurs de workflow et capable d'interpréter la

définition d'un processus, de gérer la coordination des participants et d'appeler des

applications externes.

c) Processus d'entreprise : Ensemble de plusieurs activités reliées les unes aux

autres pour réaliser un objectif, dans un contexte généralement organisationnel qui

définit des rôles et des relations.

d) Sous-processus : Processus déclenché à partir d'un autre processus (ou sous-

processus) et qui fait partie intégrante du processus dans son ensemble. Un

workflow peut comprendre plusieurs niveaux de sous-processus.

e) Définition de processus : Représentation informatique d'un processus qui

définit à la fois les processus manuels et workflow. Cette définition peut être utilisée

pour la modélisation et la simulation d'un processus, comme elle peut être exécutée

par un système de gestion de workflow. Une définition de processus est un réseau

d'activités intégrant des critères de lancement et de terminaison ainsi que des

informations relatives aux activités (participants, applications appelées, données

spécifiques, etc.)


65

3.2. Concepts de bases

Suite à ces définitions, il est possible de dégager les concepts de base du

workflow. Les principaux sont au nombre de trois :

1. Le routage des documents, des informations ou des tâches

2. La gestion des règles de coordination des activités

3. La gestion des personnes (rôles) qui accomplissent les tâches et qui

communiquent entre elles.

La métaphore des "3 R" (Routes, Règles, Rôles) illustre parfaitement les fonctions

d'un système de gestion de workflow.

3.2.1. Le routage des documents, des informations ou des tâches

Ce premier R désigne les itinéraires d'un workflow, c'est-à-dire les chemins

que prennent les différents résultats d'une activité à l'autre, d'un rôle à l'autre et

donc, d'un participant à l'autre.

Une des principales fonctions d'une application de workflow est l'exécution d'un

ordonnancement d'activités totalement ou partiellement spécifiée à l'avance. Il

existe de multiples possibilités d'ordonnancement, dont chaque extrémité peut être

définie de la manière suivante :

- D'un côté, tous les itinéraires possibles sont prédéfinis et spécifiés dans le

workflow sans qu'il soit possible, au moment de l'exécution d'une instance de

processus, de déclencher un nouvel itinéraire.

- De l'autre, aucun itinéraire n'est prédéfini. L'ordonnancement des activités n'est

défini qu'au moment de l'action.

Entre ces deux extrêmes, l'optimisation d'un workflow veut que l'on définisse

l'ordonnancement des interdépendances fondamentales, tout en laissant la

possibilité de définir, au moment de l'action, certains routages intégrant les

données spécifiques à une instance de processus particulier.


66

Le routage dans un système de workflow n'est en définitif rien d'autre que les

relations d'interdépendance entre les activités et les rôles. Différents types de

routages peuvent être utilisés, il s'agit des routages séquentiels, parallèles,

conditionnels ou en boucles.

3.2.2. La gestion des règles de coordination des activités

Le workflow est une application de groupware dont le but principal est

d'assister les organisations dans les mécanismes de coordination inhérents aux

processus de travail. Les systèmes de workflow contribuent à l'automatisation de

certains de ces mécanismes grâce à la gestion des routes, comme nous l'avons vu

précédemment, ainsi qu'a la gestion des règles. La gestion des règles de

coordination des activités est complémentaire à la gestion des routes. En effet

l'itinéraire d'un processus dépend de règles qui définissent à la fois la nature des

informations et leurs modalités de transit d'une personne à l'autre. Ce qui distingue

une application de workflow d'une application transactionnelle, c'est que les

mécanismes de coordination s'exercent dans un contexte socio-organisationnel.

Ce contexte est caractérisé par des interactions entre les participants assurant des

rôles définis. Une application transactionnelle exécute un enchaînement de

programmes élémentaires aboutissant à la mise à jour de bases de données.

Les principaux éléments de coordination des activités ont été définis par Thomas

Malone et Kevin Crowston [MALO94], ils sont présentés dans le tableau suivant.

Composant de la coordination

Mécanismes de coordination associé

OBJECTIFS

Identification des objectifs ACTIVITES

Association des activités aux Objectifs

ACTEURS Affectation des activités aux Acteurs

INTERDEPENDANCES Gestion des interdépendances Activités/acteurs

Tableau 3.1 : Classification des principaux éléments de coordination


67

Les objectifs sont la raison d'être des activités. Les activités regroupent des

ensembles de tâches à accomplir. Les acteurs sont les individus, les groupes ou

même les outils, responsables de l'accomplissement des activités. Les

interdépendances sont les relations entre activités (et donc, acteurs) qui permettent

leur exécution ordonnancée pour atteindre les objectifs.

Nous avons vu lors de la définition du workflow qu'il s'agit de

l'automatisation de processus ou partie de processus. Le challenge du workflow est

donc de décrire, via une modélisation préalable du processus, la coordination

entre les activités et les rôles nécessaires à l'accomplissement du processus dans

l'organisation. La modélisation du processus commence donc par l'identification des

objectifs. Ceux-ci représentent l'output, le résultat à atteindre. Ensuite, les rôles

capables d'atteindre ce résultat seront déterminés, cela revient à définir des

responsabilités. Le rôle est en effet responsable d'un ou de plusieurs résultats

donnés, il peut être tenu par un individu, un groupe ou même un outil

informatique. Un acteur, c'est-à-dire un participant au workflow, peut ainsi tenir

plusieurs rôles.

Les activités nécessaires aux rôles pour atteindre le résultat souhaité sont ensuite

analysées.

Vient alors le moment de sélectionner les acteurs ou les groupes d'acteurs

qui tiendront ces rôles. La sélection des acteurs fait partie intégrante de choix des

ressources impliquée dans un processus candidat au workflow. En effet les objectifs

sont déterminés grâce au modèle abstrait par les fonctions. Les interdépendances

sont illustrées dans le modèle abstrait avec les paquets d'informations et dans le

modèle descriptif avec l'enchaînement des activités. La détermination des acteurs et

l'affectation des activités à ces derniers se fait dans le modèle descriptif.

L'analyse de Thomas Malone et Kevin Crowston [MALO94] concernant les

éléments de coordination fait ressortir à quel niveau (en terme de processus), une

coordination est nécessaire. Elle n'est toutefois pas très détaillée en ce qui concerne

la manière dont cette coordination est effectuée. Cela revient à se demander quels

sont les mécanismes de coordination utilisés au sein d'un processus ou d'une

organisation. Différents mécanismes de coordinations existent, [MINT93] en à fait la

synthèse (voir chapitre 1).


68

Dans la métaphore des "3 R", les règles implémentées dans un workflow

déterminent les types d'interdépendances entre les activités et les rôles qui les

accomplissent, celles-ci comme expliqué ci-dessus se réalisent à travers les

différents mécanismes de coordination. Les principales causes d'interdépendances

sont :

- Les ressources partagées (hommes, information, temps, outils, argent)

- Les contraintes a priori. Le déclenchement de certaines activités dépend de la

terminaison d'autres activités.

- Les contraintes simultanées. Le déclenchement de certaines activités doit être

simultané lorsqu'elles doivent être accomplies en parallèle.

Plus qu'un simple réseau d'activité, le workflow est un réseau d'acteurs et

d'activités déterminé par des objectifs. Ce type de réseau correspond à une

traduction plus réaliste de la complexité d'une organisation.

3.2.3. La gestion des personnes (rôles)

Les règles de coordination et les routes déterminent le cheminement d'un

workflow entre les différentes activités et les rôles. Il est ensuite nécessaire de gérer

les participants et leurs rôles respectifs dans l'accomplissement des tâches. En

effet une fois qu'un processus a été défini et mémorisé par un système de workflow,

celui-ci prend la responsabilité d'affecter à chaque tâche les ressources

nécessaires à sa réalisation. Les tâches ne sont pas systématiquement réalisées

par des personnes : router un courrier électronique, effectuer un calcul complexe

ou sélectionner à intervalles réguliers des documents pour les diffuser à une liste de

personnes données sont des exemples de tâches pouvant être automatisées par des

programmes. Ces programmes peuvent être paramétrés et activés automatiquement

pour accomplir des travaux routiniers. Les systèmes de workflow permettent de

créer des automates intervenant dans l'exécution de processus.

Quand l'accomplissement d'une tâche requiert une personne physique, le

système de workflow prend en charge l'indispensable association entre une tâche

ou un groupe de tâches (donc une activité) et une ou plusieurs personnes. Cette

relation est gérée de manière différente selon les systèmes de workflow. Certains

systèmes sont conçus pour affecter des tâches à des personnes désignées par leur

nom préalablement enregistré dans un annuaire. C'est le protocole le plus simple à


69

implémenter. D'autres systèmes disposent de protocoles sophistiqués qui

permettent d'optimiser la gestion de la relation entre tâches et participants.

Dans ce cas, le moteur de workflow propose une activité (bon de travail) à un

groupe de personnes, chacune étant susceptible d'accomplir l'activité dans son

ensemble. Dès qu'une personne accepte l'activité, celle-ci disparaît

automatiquement de la liste des tâches des participants auxquels le bon de travail

était proposé. Le rôle est un concept très puissant dans la conception d'un

workflow. Il permet d'introduire une grande souplesse organisationnelle. Lors de la

modélisation d'un processus, le concepteur peut établir une cartographie associant

activités et rôles sans être obliger de définir une liaison avec des personnes

données. Lors de l'exécution du processus, le moteur de workflow effectuera une

recherche dans la liste de participants désignés pour assurer tel ou tel rôle.

Certains moteurs de workflow vont encore plus loin. Ils permettent de

regrouper des participants et d'associer à un rôle, un nom de groupe plutôt qu'une

liste de participants. Ceci est particulièrement utile lorsqu'il s'agit de reporter très

rapidement des activités d'un groupe sur un autre en fonction des charges de

travail.

3.3. Typologie des applications de workflow

Différentes classifications ont été proposées. Il existe en effet des types de

workflow mettant en oeuvre des fonctionnalités et des architectures techniques

différentes. Ces applications tentent de répondre à des besoins organisationnels

variés et spécifiques. Différents critères doivent être pris en compte lorsqu'il s'agit

d'effectuer une classification.

Les caractéristiques des processus à automatiser sont en général un bon point de

départ. S'agit-il d'un processus spécifique d'un métier, d'une entreprise ou d'un

processus générique ? L'application a-t-elle vocation à être utilisée par des employés

peu qualifiés ou au contraire par des "Knowledge Workers" ? Le travail est-il

déterminé par des circuits prédéfinis et imposés ou au contraire prend-il forme à

travers un jeu spécifique d'interactions et de décisions entre les acteurs ?


70

La segmentation proposée par la Workflow Management Coalition (WfMC) est très

utile pour se représenter fonctionnellement les différentes applications de workflow.

Le critère principal de différenciation repose sur la mission fondamentale de

l'application de workflow :

- L'application s'attache à automatiser des procédures de production dont il est

possible de définir les règles à l'avance.

- L'application s'attache à automatiser des procédures d'exception dont il n'est pas

toujours possible de définir toutes les règles à l'avance.

Quatre types d'applications sont définis :

3.3.1. Les workflows de production

Le but principal des workflows de production est de gérer un grand nombre

de tâches similaires et d'optimiser la productivité. Cela est réalisable par

l'automatisation des activités. A l'extrême, les ressources humaines d'un processus

de production sont utilisées uniquement pour gérer les exceptions.

Les processus concernés sont opérationnels, répétitifs et critiques pour la

performance globale de l'entreprise. Ils sont généralement accomplis par des

acteurs opérationnels de base. Les procédures sont clairement définies et

formalisées. Des exemples courants de ce genre de processus sont :

- Traitements des réclamations déposées par les clients des compagnies

d'assurances

- Instructions de demandes de prêts bancaires

- Traitement des commandes et de la facturation de sociétés de vente par

correspondance Les workflows de production peuvent gérer des processus très

compliqués et sont souvent intégrés avec les systèmes d'information existants. En

effet, la tendance est actuellement d'intégrer le système de gestion de workflow dans

les applications, afin qu'il joue le rôle de moteur de règle. Cela nous permet de faire

une nouvelle segmentation à l'intérieur des workflows de production :


71

- Moteurs de workflow autonomes Ces systèmes sont utilisables directement sans

ajouts d'autres composants logiciels. Ils ont en général leurs propres interfaces et

accèdent aux données des autres applications. Les spécifications de ces interfaces

de transfert de données depuis les autres applications sont en général très

complexes, c'est pour cette raison que les workflows intégrés sont de plus en plus

utilisés.

3.3.2 Workflows intégrés

Ces systèmes sont fonctionnels uniquement lorsqu'ils sont accédés depuis le

logiciel principal, par exemple un ERP (Enterprise Resource Planning), le moteur de

workflow est utilisé pour contrôler la séquence des fonctions de l'application, pour

gérer les queues et pour assister le processus de gestion des exceptions.

A noter qu'il faut différencier les règles de gestion de processus intégrées dans les

ERP et activées par des triggers sur base de données, des règles du moteur de

workflow. En effet ces dernières permettent de spécifier des processus plus

complexes et surtout sont intégrables à plusieurs applications et non pas

seulement à l'ERP concerné.

3.3.3. Les workflows administratifs

Les systèmes de workflows administratifs traitent beaucoup moins

d'instances de processus que les workflows de production. De plus, des processus

sont définis de manière moins rigide que dans la production. C'est pourquoi une

des propriétés la plus importante de ce type de système est la facilité de définition

et de modification de processus.

3.3.4. Les workflows collaboratifs

Les workflows collaboratifs se concentrent sur le travail d'équipe en vue

d'atteindre des objectifs communs. La taille des groupes peut être très variable, elle

peut aller du petit comité avec une organisation orientée projet, au grand groupe

réparti à travers le monde et ayant des intérêts en commun. L'utilisation des

workflows collaboratifs dans le but de faciliter les communications inter-groupes est


72

actuellement reconnue comme un élément vital dans le succès d'une entreprise,

tout comme l'usage d'Internet et du World Wide Web.

Le workflow collaboratif est parfois aussi appelé Groupware. Une distinction

est toutefois nécessaire dans la mesure ou certains types d'outils de groupware ne

sont pas des systèmes de workflow, par exemple la vidéo conférence (voir chapitre

précédant). Par rapport aux workflows de production, les workflows collaboratifs

ainsi que les workflows ad-hoc font beaucoup plus souvent appel aux moyens de

communication qui permettent l'ajustement mutuel des individus impliqués. Ils

sont également caractérisés par un cadre procédural relativement ouvert et plus

complexe car moins déterministe dans sa mise en oeuvre. Un exemple de workflow

collaboratif serait la gestion des processus plus ou moins formalisés de définition

d'un nouveau produit.

3.3.5. Les workflows ad-hoc

Les systèmes de workflows ad-hoc permettent aux utilisateurs de créer et de

modifier les définitions de processus très rapidement et facilement, dans le but de

correspondre aux situations souvent uniques qui se présentent. Dans ce cas il est

possible d'avoir pratiquement autant de définitions de processus que d'instances de

ces processus. Les workflows ad-hoc maximisent donc la flexibilité dans des

domaines où la productivité et la sécurité sont moins indispensables qu'en

production par exemple.

Les systèmes de workflows ad-hoc automatisent en quelque sorte les procédures

d'exception, donc occasionnelles, voire uniques. Ces processus sont le plus souvent

liés à des routines administratives. Les exemples les plus courant sont la gestion de

correspondance institutionnelle exigeant parfois des révisions et des approbations

intermédiaires, mais aussi des processus recrutement d'une compétence

particulière.

La matrice suivante résume de manière graphique la typologie fonctionnelle des

applications de workflow


73

Figure 3.4 : Matrice fonctionnelle de la typologie workflow

3.4. Composantes techniques des systèmes de workflow

Les principales composantes d'un système de gestion de workflow ont été

définies par la Workflow Management Coalition à travers le modèle de référence du

workflow. Le but de ce modèle est d'obtenir l'interopérabilité entre plusieurs

produits de workflow. Une hypothèse à été établie : tous les systèmes de gestion de

workflow reposent sur les mêmes composantes génériques qui interagissent selon

diverses modalités.

De multiples scénarios d'interopérabilité peuvent être conçus à partir de standards.

Par exemple, un processus standard utilisable par des dizaines ou des centaines de

groupes d'utilisateurs est défini à partir d'un produit de workflow et diffusé auprès

de ces groupes qui peuvent utiliser des systèmes workflow très différents. De même,

un utilisateur donné peut utiliser un client workflow unique pour traiter des

activités générées par des systèmes workflow différents. Le modèle de référence de

Processus répétitif et

structuré par des

document

Processus spécifique et

structuré par les

intervenants

Workflow centré sur le

document Workflow centré sur le

groupe

Workflow de

PRODUCTI

ON

Ex :

Demande de

prêt bancaire

Workflow

COLLABORAT

IVE

Ex :

développement

de nouveau

produit Workflow

ADMINISTRATIF

Ex :

Remboursem

ent de notes

de frais

Workflow

AD HOC

Ex :

Rédaction/révis

ion d’un

document

Work

flow

appli

quer

au p

roce

ssus

pri

nci

pau

x

Work

flow

appli

quer

au p

roce

ssus

support

Processus « mode

projet »

Workflow de

production

Workflow

AD HOC

Processus « mode

routine »


74

la Coalition définit ainsi un cadre de référence pour la définition et l'implémentation

de ces standards.

Ce modèle est composé de cinq éléments faisant objet de standards et de cinq

interfaces :

Figure 3.5 : Modèle de référence du workflow [WfMC10]

3.4.1. L'outil de définition de processus (interface 1)

De nombreux outils peuvent servir à l'analyse, à la modélisation et à la

description de processus d'entreprise. Le modèle de référence n'est pas

particulièrement concerné par la nature particulière de tels outils qui sont

généralement conçus en fonction du produit de workflow avec lequel ils sont

couplés. L'interface proposée par la Coalition vise à garantir le maximum de

souplesse et d'ouverture dans ce domaine. Cette interface est désignée sous le

terme d'interface d'import/export de définition de processus qui devrait fournir un

format d'échange commun aux types d'informations suivantes :

- Conditions de déclenchement et de terminaison de processus

Outils de

definition de

processus

Outils

d’administration

et de pilotage

Autre dispositifs

de services

workflow

Application

cliente workflow

Application

appelée

API workflow et format d’échange

Dispositif de service

workflow

Moteur de workflow

Interface1

Interface3 Interface2 In

terf

ace

4

Inte

rfac

e 5


75

- Identification d'activités dans le processus incluant les applications externes

associées et les

données d'ordonnancement de processus

- Identification des types de données et des chemins d'accès

- Définition des conditions de transition et des règles de routage

- Informations relatives aux décisions d'allocation de ressources.

Cette interface à été récemment réécrite pour utiliser XML comme langage de

définition des processus.

Exemple : Dans le cadre de la modélisation de gestion d‟infrastructures, on peut

utiliser le logiciel de représentation des processus Qualigramm5. il devrait alors

générer un script interprétable par un moteur de workflow, de la même façon qu'un

logiciel de modélisation de données (ex: Power Designer, Win'Design) génère un

script SQL de la base de donnée définie.

3.4.2. Le moteur de services workflow (serveur workflow)

Le moteur de services workflow correspond à un environnement run-time

capable d'exécuter un ou plusieurs workflow. Cet environnement peut impliquer un

ou plusieurs moteur de workflow, c'est-à-dire des produits workflow différents. Le

moteur de services workflow est distinct des applications et des outils orientés

utilisateurs mis en oeuvre dans l'accomplissement des tâches et des activités du

processus.

3.4.3. L'application cliente workflow (interface 2)

L'application cliente workflow est le module logiciel qui présente les bons de

travail à l'utilisateur et peut appeler les applications et outils logiciels nécessaires à

l'accomplissement des tâches. L'utilisateur rend ensuite la main au moteur de

services workflow pour poursuivre le déroulement du processus. Le client workflow

peut faire partie intégrante d'un système de gestion de workflow comme il peut être

un produit tiers (messagerie par exemple), ou bien encore une application

spécifique. Il est donc très important de déterminer des modalités de

communication ouvertes entre un moteur de services workflow et un client.

5 www.qualigram.com


76

3.4.4. L'application appelée par le workflow (interface 3)

Les systèmes de gestion de workflow doivent communiquer avec toutes les

applications externes nécessaires à l'accomplissement des tâches : messagerie,

outils bureautique, applications de production, etc. C'est pourquoi la Coalition

attache beaucoup d'importance au développement de standards relatifs à l'appel de

telles applications, ceci est effectué grâce à l'interface 3.

3.4.5. Les autres moteurs de services workflow (interface 4)

Un des objectifs fondamentaux de la Coalition est de définir des standards

permettant à des systèmes de gestion de workflow, conçus et produits par différents

éditeurs, de travailler ensemble sur les mêmes bons de travail. Ces standards

d'interopérabilité peuvent agir à différents niveaux : du simple transit de tâches

d'un produit workflow à l'autre jusqu'à l'échange intégral de définitions de

processus avec des données d'ordonnancement.

3.4.6. L'outil d'administration et de pilotage du système workflow (interface 5)

Il s'agit de définir un standard d'interface permettant à un outil

d'administration et de pilotage de travailler avec n'importe quel moteur de services

workflow. Cela permet d'obtenir une vision complète de l'état d'un workflow

cheminant à travers une organisation, indépendamment des systèmes de workflow

mis en oeuvre.

3.5. Impacts du workflow

Les différents avantages et bénéfices rencontrés lors de l'introduction d'un

système de workflow peuvent être de deux natures. Soit ils sont mesurables donc

tangibles, soit ils sont moins "palpables", mais contribuent tout autant à

l'amélioration significative de la qualité du travail effectué.

Du coté des gains tangibles nous retrouvons les éléments suivants :


77

- Réduction des coûts opérationnels : Les organisations utilisant des systèmes de

workflow constatent une diminution des coûts de transaction. L'exemple d'une

banque ayant mis en place un système de workflow pour gérer ses demandes de

prêts bancaires, relève une diminution de ces coûts de plus de 33%.

- Amélioration de la productivité : Les opérations routinières et répétitives

peuvent être automatisées réduisant ainsi significativement le temps d'exécution du

processus. De plus, le travail peut être effectué 24h/24, ceci étant un facteur vital

pour les multinationales et les entreprises effectuant des transactions commerciales

par le biais d'Internet.

- Processus plus rapides : Deux facteurs expliquent le gain de temps des

processus gérés par des systèmes de workflow. Le premier, nous l'avons vu plus

haut est dû à l'automatisation des opérations routinières. Le deuxième concerne les

activités "manuelles" ou nécessitant une intervention humaine. Celles-ci, peuvent

souvent être effectuées parallèlement (en tous cas pour une partie d'entre elles). Le

workflow permet dans ce cas, grâce à une coordination efficace et une attribution

des activités à plusieurs acteurs, de faire progresser le processus nettement plus

rapidement. Les gains intangibles sont les suivants :

- Service amélioré : Grâce à la rapidité de gestion des demandes de la clientèle

ainsi qu'à une meilleure information sur le l'état d'avancement de celles-ci, le

service rendu aux clients s'en trouve amélioré.

- Amélioration des conditions de travail des employés : Les tâches répétitives et

peu gratifiantes peuvent être automatisées, libérant de cette façon le personnel

pour des activités plus intéressantes.

- Facilitation du changement : Les entreprises peuvent constamment, grâce aux

systèmes de workflow, redéfinir et automatiser leurs processus.

- Augmentation de la qualité : suite aux automatisations des tâches répétitives,

ainsi qu'à une meilleure coordination et compréhension du travail, les erreurs sont

plus rares.


78

- Communication facilitée : Grâce aux informations disponibles concernant les

tâches à effectuer et l'état d'avancement des processus, la communication et la

transparence du travail sont améliorées.

- Aide à la prise de décision : Etant informé du déroulement des processus et des

activités, il est plus facile de prendre les bonnes décisions.

- Amélioration du planning : Les informations disponibles concernant

l'organisation, son business et ses processus améliorent les facultés de planning.

- Communications inter-entreprise : La gestion de processus inter-entreprises

augmente considérablement la productivité et la transparence du marché.

4. Conclusion

D'une manière générale, toutes les solutions utilisées dans les entreprises

aujourd'hui ont pour vocation de supporter des processus métier. Une partie de ces

processus est automatisé. Une minorité de ceux-ci ne reposent que sur la

communication entre applications, l'autre partie (en fait la majorité) dépend d'un

facteur humain pour, initier le process, approuver des documents utilisés dans ce

dernier et/ou répondre à tout événement ou situation exceptionnelle. Il est bien sûr

possible de créer une série d'étapes spécifique qu'on nomme workflow qui va décrire

les activités des personnes et des solutions jouant un rôle dans le process. Une

application peut alors reposer sur ce workflow pour supporter le processus métier

lié. Le workflow couvre un large domaine d'applications. En fait, peut être plus

clair, chaque fois que plusieurs personnes ou acteurs métiers coopèrent dans un

but commun, en suivant une procédure établie, il s'agit de workflows. Créer et

exécuter des workflow pose de nombreuses difficultés qu'il faut surmonter. Certains

processus métier peuvent prendre plusieurs heures, jours, ou même semaines pour

être réalisés. Comment un développeur peut alors persister les informations sur

l'état du workflow durant ce temps ? Lorsqu'un workflow communique avec

d'autres systèmes dans un mode asynchrone, comment rendre plus sûr et plus

simple ce type de communications ? Comment facilement permettre à un utilisateur

d'une solution métier de créer facilement ses propres workflow sans avoir à

dépendre d'un système particulier ? Comment lui permettre aussi de modifier en

temps réel la structure du workflow ? Comment communiquer avec des systèmes

distants ?

Chapitre 4 : Systèmes de gestion de la e-maintenance

79

Chapitre 4

Systèmes de gestion

de la

e-maintenance


80

1. Introduction

De récentes études réalisées par [COMP05] , recensant les différents travaux

réalisés ces dernières années dans le domaine des technologie web et des system

multi agent appliqués à la maintenance, ont permit de démontrer que les avancées

actuelles dans ces domaines, sont encore à un stade rudimentaire. D‟autre part,

[JARD06] a relevé les difficultés d‟intégration des technologies de la e-maintenance

coopérative, dans le monde industriel, dû principalement, au manque de

communication entre les chercheurs « théoricien » de la discipline, et les experts sur

le terrain. Cependant, un nombre important d‟outils, de systèmes (SCADA, GMAO,

ERP…) ont été développé afin de tenter de pallier à ces carences. Plusieurs

plateformes d‟e-maintenance on vu le jour, fruit de travaux académiques ou de

développement industriel, nous en présentons quelque unes dans la première partie

de ce chapitre (Proteus, TEMIC, TELMA, SCOOP…). Une étude comparative entre

ces plateformes, nous a permis de relever dans la deuxième partie de ce chapitre un

manque (voir l‟absence) de données fiables ou de méthodes efficaces de validation

de ces approches. C‟est pourquoi nous proposons dans le dernière partie,

d‟apporter quelques améliorations aux précédents travaux (ex : SCOOP) en

intégrant, entre autres, les modèles Workflow.

2. Les sous systèmes fonctionnels de la e-maintenance

2.1. SCADA (Supervisory Control And Data Acquisition)

Les outils de supervision ou SCADA6 s‟adressent à tous les industriels ayant des

nécessités de pilotage et de visualisation de leurs équipements. Un SCADA est un

système d‟acquisition de données qui permet le suivi de la dynamique du système

physique, et qui éventuellement détectera les dérives et les alarmes qui

nécessiteront une intervention immédiate ou sa programmation à une date

ultérieure. Ce système est soit indépendant, soit intégré dans un système de

contrôle - commande, dans des automates programmables, etc. Un SCADA est

rarement construit sur un modèle de maintenance. Il modélise le processus

physique à des fins de commande et-ou de supervision. Les principaux objectifs des

systèmes de supervision sont :

Concentrer les données, déporter ou centraliser le pilotage du procédé

6 http://www.actors-solutions.com/Supervision-SCADA


81

Apporter une vision temps réel des états permettant aux opérateurs de

réagir et de décider rapidement

Apporter les premiers outils d‟analyses nécessaires aux contrôles des

équipements concernés (historiques, courbes, pareto, alarmes, login)...

Figure 4.1: Exemple d’un système SCADA du Complexe GPZ7

Les systèmes de supervision sont des concentrés de technologies réunissant des

savoir faire diverses pour répondre dans un environnement unique, aux seuls

besoins des industriels. La liste suivante, non exhaustive donne un aperçu des

principaux atouts d‟un système de supervision :

Les outils de graphisme apportent tout le nécessaire afin de représenter les

procédés concernés

7 Voir étude cas chapitre 6


82

Les « moteurs » d‟animation permettent de définir les différents choix de

dynamismes des objets graphiques

La gestion de la base de données temps réel (parfois propriétaire), permet de

définir des variables typées internes, ou en liaison avec le système de

contrôle commande en leur attribuant des propriétés.

Des traitements internes initiés par des déclencheurs multiples (temporels,

changement d‟état, équation combinatoire, ouverture d‟une fenêtre...)

permettent d‟appliquer des premiers niveaux de traitement informatique plus

ou moins évolués. -Une gestion de la sécurité pour un contrôle des accès

applicatifs est généralement proposée.

Certains superviseurs intègrent également les possibilités de s‟interfacer

avec une base de données relationnelle.

Les données pertinentes de maintenance collecter par le system, ne sont pas

forcément stockées, elles peuvent aussi être ni mesurées, ni calculées, et le besoin

se fait jour de développer des adaptations en vue d‟une intégration. Un cas

particulier est celui des instruments intelligents (capteurs ou actionneurs) qui

peuvent déjà intégrer quelques fonctionnalités relevant de la problématique de la

maintenance.

2.2. Systèmes d’aide au diagnostic

Un ou des systèmes d‟aide au diagnostic peuvent être utilisés soit en cas

d‟arrêt et d‟assistance à la recherche de la cause du dysfonctionnement [BANG06],

soit actifs en permanence pour prévenir des défaillances autant que faire se peut.

Ces systèmes sont construits sur des modèles très variés (modèles de Markov, de

Bayes, modèles neuro-mimétiques, modèles de raisonnement à base de cas…). Ils

doivent, en général, s‟appuyer sur des données issues d‟un SCADA et sur

l‟expérience acquise pour assister la décision des responsables de la maintenance.

2.3. Système de GMAO

Un système de gestion de maintenance assistée par ordinateur (GMAO)

optimise les activités de maintenance et impacte ainsi directement la productivité

du matériel maintenu. Il doit gérer les diverses stratégies de maintenance,

maintenance corrective, maintenance préventive, prédictive, etc.


83

Les objectifs d‟une GMAO peuvent ainsi être décomposés selon les trois axes

suivants :

• gestion proprement dite de l‟activité de maintenance,

• génération du retour d‟expérience,

• analyse des données tout au long des autres processus.

Grâce à la GMAO, il est alors possible :

• de mieux maîtriser les équipements grâce à une diminution des temps d‟arrêt et

du nombre de défaillances, une augmentation de la disponibilité des matériels

ainsi qu‟une optimisation de l‟efficacité du personnel,

• de mieux suivre le déroulement des travaux,

• d‟optimiser les stocks,

• de réduire les coûts en optimisant les interventions et les stratégies.

Le logiciel de GMAO a pour but d‟optimiser la gestion des équipements, des

achats et ventes de stocks en fournissant aisément un panel d‟informations le plus

large possible mais avec une interface la plus claire possible, nécessitant un temps

de prise en main assez court. De par ses buts premiers on pourra ainsi baisser les

coûts de maintenance et améliorer la fiabiliste des machines notamment.

On retrouve différents modules dans un programme de GMAO :

- Gestion des actifs

On obtiendra en général des renseignements divers sur les possessions de la

société, les pièces de rechange, etc. … on pourra tout organiser en forme d‟arbre

hiérarchique (forme la plus courante dans les logiciels de GMAO)

- Gestion de la maintenance

On y retrouvera un calendrier des taches planifiées, une résume des ressources en

personnel et équipement, ainsi que la gestion des pannes et des interventions sur

les machines (dans le but d‟en tirer des statistiques)

- Gestion des stocks

Dans ce module on trouvera un inventaire général des stocks de l‟entreprise, pour

chaque produit en stock un bon logiciel de GMAO fournira la possibilité d‟entrer les

coordonnées du fournisseur et de pourvoir ensuite faire des commandes manuelles


84

ou automatiques si le stock descend en dessous d‟un niveau fixé par l‟utilisateur,

on pourra ainsi disposer des pièces au bon moment et ne pas perdre de temps.

- Gestion des achats

C‟est ce module qui gèrera les commandes manuelles ou automatiques, mais

également des prix, des coûts engendres par ces commandes, ainsi qu‟une gestion

d‟un budget permettant de ne pas mettre l‟entreprise dans le rouge

- Un module de divers rapports et historiques

Ce module affichera les diverses données telles les pannes ou interventions sur les

machines, les achats, ventes selon l‟organisation souhaitée et nous permettra de

faire des comparatifs entre diverses informations disponibles.

- Un module permettant d‟analyser les données

Ce module va de pair avec le module de rapport, il permettra d‟obtenir une analyse

de ces informations, de voir par exemple si une machine donnée ne tombe pas trop

souvent en panne par la quantités d‟interventions effectuées sur celle ci, ou encore

si un produit acheté nécessite une part importante du budget de l‟entreprise,

décidant celle ci à trouver un fournisseur meilleur marché.

Un bon logiciel de GMAO selon [VASS10], devra regrouper au minimum ces

modules (réorganisés autrement ou pas), pour au moins avoir une gestion globale et

efficaces des divers actifs de l‟entreprise.

2.4. Système de documentation

Un système de gestion de la documentation des équipements est au

minimum la base documentaire associée à l‟installation à maintenir. Ce système

doit délivrer la bonne information, au bon moment, au bon endroit et à la bonne

personne et ce tout au long de la procédure. Les informations ont longtemps été

textuelles : procédures, relations d‟anciennes expériences, notices d‟utilisation ou

de montage - démontage. Elles sont maintenant multimédia, incluant films et

commentaires. Mais les systèmes de documentation contiennent maintenant plus

que cela ; ils contiennent tout ce qui est relatif à la qualité, à la sécurité, les

normes, les règlements intérieurs, et plus généralement toutes les informations

internes à l‟entreprise.


85

2.5. Système ERP

L'ERP8 vient de l‟anglais « Enterprise Ressource Planning ». On utilise parfois

dans le monde francophone la dénomination PGI (Progiciel de gestion intégré) mais

la terminologie anglo-saxonne prime. Un système ERP a pour vocation

l‟optimisation de la productivité de l‟entreprise. La méthode est basée sur une

gestion, sur une optimisation et surtout une synchronisation des flux de matières,

de produits, d‟information, de décision et évidemment des flux financiers. De tels

systèmes intègrent toutes les informations de l‟entreprise, ressources humaines,

gestion des achats et de la logistique, service commercial et gestion des ventes,

production et gestion des matières, qualité des produits et des services, gestion

comptable et financière, et évidemment la maintenance qui est en relation avec

chacune des fonctions précédentes. Un ERP répond aux caractéristiques

suivantes :

Il émane d‟un concepteur unique

En cas d‟impact d‟un module, l‟information est mise à jour en temps réel

dans l‟ensemble des autres modules associés

C‟est un système qui garantie la piste d’audit : il est facile de retrouver et

d‟analyser l‟origine de chaque information

Il peut couvrir l‟ensemble du Système d‟Information de l‟entreprise (sauf si

l‟entreprise ne choisit dans un premier temps d‟implémenter que certains

modules de l'ERP)

Il garantie l‟unicité des informations qu‟il contient puisqu‟il n‟a qu‟une seule

base de données au sens logique.

Quel périmètre de gestion couvre un ERP ?

La vocation d‟un ERP est d'homogénéiser le Système d'Information de l'entreprise

avec un outil unique qui est capable de couvrir un large périmètre de gestion, c'est-

à-dire :

La gestion des achats

La gestion des ventes

La gestion comptable : comptabilité client, fournisseur, immobilisations,

personnel

Le contrôle de gestion

8 http://www.entreprise-erp.com


86

La gestion de production (planification, ...)

La gestion des stocks (logistique)

Un ERP est sub-divisé en modules qui répondent chacun à un des domaines de

gestion listés ci-dessus. On dit aussi que l‟ERP est constitué de modules

fonctionnels, chacun couvrant un périmètre de gestion de l‟entreprise.

Concrètement, par exemple, la saisie d'une vente génère automatiquement une

écriture comptable en partie double dans le journal des ventes avec calcul

automatique de la TVA collectée. Le grand livre et le compte de résultat sont

automatiquement impactés.

Un ERP contient généralement trois environnements de travail :

Un « environnement de développement » qui permet d‟adapter le progiciel

standard à des besoins spécifiques de l‟entreprise.

Un « environnement de test » dit encore environnement de recette qui

permet de réaliser des simulations. Ces simulations permettent de tester de

nouveaux paramétrages et de vérifier le fonctionnement correct du progiciel

par rapport à un processus de gestion donné (une vente, un achat, une sortie

de stock, …)

Un « environnement de production » qui correspond au progiciel utilisé par

les gestionnaires de l‟entreprise au quotidien.

Le travail en environnement de test est préalable au passage à l‟environnement de

production.

Pourquoi mettre en place un ERP : quels sont les bénéfices pour l’entreprise ?

Avant de mettre en place un ERP, chaque service avait son propre système

d‟information. Pour faire le lien entre ces différents systèmes, les situations

suivantes se produisaient :

Double voire triple saisie des mêmes informations dans des systèmes

d‟information distincts

Au mieux, l‟entreprise faisait développer des interfaces informatiques entre

ses différents SI

Conséquences néfastes: En cas de double saisie, on constatait un nombre élevé

d‟erreurs et d‟incohérences entre les différents systèmes d‟Information. En cas

d‟interface entre différents SI, la mise à jour ne se faisait pas en temps réel. Des


87

déperditions de données survenaient parfois, du fait d‟un plantage informatique au

moment du transfert de données. Des erreurs humaines survenaient aussi

régulièrement (transfert du mauvais fichier, doublons dus à deux transferts

successifs malencontreux …) Dans certaines grandes entreprises, des contrôleurs

de gestion étaient spécifiquement embauchés pour l‟analyse et la correction des

incohérences entre ces systèmes d‟information. Par exemple, chez un grand

constructeur de matériel informatique, un analyste des stocks devait réconcilier les

écarts entre le système enregistrant les entrées et les sorties physiques de stock

d‟un côté et les écritures comptables correspondantes de l‟autre.

Des écarts de plusieurs dizaines de milliers d‟euros étaient régulièrement constatés

et devaient être expliqués puis corrigés. Ce mode de fonctionnement coûtait très

cher à l‟entreprise et est devenu inacceptable.

Pour mettre fin à cette situation, les entreprises ont décidé d‟implémenter un ERP.

Globalement, les bénéfices d‟un ERP pour l‟entreprise sont les suivants :

Eviter la redondance d‟informations entre différents SI de l‟entreprise.

Disposer d‟un outil multilingue et multidevises (très adapté aux

multinationales)

Eviter des restitutions d‟informations divergentes entre différents services et

donc apaiser les conflits qui en résultaient

Une meilleure coordination des services et du coup un meilleur suivi du

processus de commande qui inclut la prise de commande, l‟enregistrement

d‟une sortie de stock, l‟expédition de la commande et l‟émission d‟une facture

Une meilleure maîtrise des stocks

Une normalisation de la gestion des Ressources Humaines, en particulier

pour les entreprises qui gèrent de nombreuses entités, parfois

géographiquement dispersées.

3. Plateformes de E-maintenance

3.1. La plateforme PROTEUS

3.1.1. Problématique d’interopérabilité

Nous venons de voir que pour mener à bien la maintenance d‟un système

industriel, on utilise en général une multitude de sous-systèmes fonctionnels tel

que : un système d‟acquisition de données (SCADA, Supervisory Control And Data

Acquisition), des aides au diagnostic, un système de GMAO (Gestion de


88

Maintenance Assistée par Ordinateur), un ERP (Enterprise Resource Planning), un

système de documentation. Chacun de ces systèmes s‟appuie sur un certain modèle

de l‟entreprise, du système physique ou de l‟installation à maintenir. Ces modèles

sont évidemment différents puisque leurs objectifs le sont, mais ils sont aussi

parfois incohérents car définis indépendamment les uns des autres. Les logiciels

sont parfois redondants, mais dans tous les cas non interopérables, tant par leurs

représentations hétérogènes des informations que par leurs interfaces

incompatibles entre elles. Ceci est vrai sauf dans le cas où tout est intégré par

construction initiale comme dans [REBE03].

C‟est cette recherche d‟interopérabilité, et d‟intégration harmonieuse des diverses

fonctions qui a motivé le projet PROTEUS [BANG06].

3.1.2. Objectif du projet PROTEUS

Le projet PROTEUS dont l‟objectif est de faciliter l‟intégration de ces divers

systèmes (SACAD, GMAO, ERP….) en définissant une description unique et

cohérente de l‟installation à maintenir (une ontologie), une architecture générique

(basée sur le concept de Web Service) et en proposant des modèles et des solutions

technologiques d‟intégration [BANG06]. Le projet PROTEUS a conduit à définir une

plate-forme d‟intégration, avec tous les problèmes inhérents à ces technologies,

répartition des composants, découverte de services, définition des services,

distribution des « workflows », contrôles des accès, etc.

Figure 4.2 : Composant de la plateforme PROTEUS


89

3.1.3. Architecture de la plateforme PROTEUS

Le but de PROTEUS étant d‟assurer l‟interopérabilité des différents outils

présentés précédemment, nous définissons tout d‟abord l‟architecture de la plate-

forme d‟intégration (voir Fig. 4.2). Une description plus complète est disponible

dans [BANG03]. Cette intégration relève d‟une démarche plus générale dans

l‟industrie, comme dans MIMOSA9, qui est résumée par l‟expression “Enterprise

Integration Technologies”, intégration qui se veut le plus possible dynamique, et pas

seulement statique [BUSS03]

Figure 4.3 : Architecture simplifiée de la plate-forme PROTEUS [BANG03]

La plate-forme doit offrir un service global et intégré aux utilisateurs. Pour cela, elle

doit résoudre trois types de contrainte :

• la coopération entre des applications de différentes natures (temps réel,

transactionnelles, interactives),

• le besoin d‟échange d‟informations entre sites distants,

• la variété des formats de données.

Les différents outils supportant des fonctionnalités communes offrent

rarement la même interface. Pour chaque type de système (ex : SCADA), nous

définissons une interface générique standard (voir paragraphe 5). Elle présente

ainsi une vision « idéale » de l‟outil et permet d‟uniformiser l‟accès à ces

9 http://www.mimosa.org/


90

fonctionnalités depuis la plate-forme. L‟implémentation de cette interface pour un

outil existant est assurée par un type de composant appelé « Intelligent Core

Adapter ».

Afin d‟assurer l‟évolutivité de la plate-forme, il faut pouvoir intégrer de nouvelles

fonctionnalités non fournies par un outil préexistant. Ce type de fonctionnalité sera

implémenté au travers d‟un type de composants appeler « Functional Core Adapter».

Enfin, d‟autres outils sont nécessaires pour le bon fonctionnement de la

plate-forme. Par exemple, la plate-forme nécessite des serveurs d‟authentification

pour les utilisateurs et d‟annuaire des services disponibles. Ces différents outils

sont intégrés au sein d‟un composant appelé « Central Service Application ». Afin

d‟assurer l‟interopérabilité des échanges, les communications sont basées sur la

technologie des « Web Services » et le protocole SOAP10 (Simple Object Access

Protocol).

3.1.3.1. Les outils du « Central Service Application »

Le CSA regroupe les différents outils responsables du bon fonctionnement de

la plate-forme. • Annuaire. L‟ « Universal Description, Discovery and Integration »

permet l‟enregistrement ainsi que la découverte dynamique de Web Services11. Cette

fonctionnalité est cruciale dans le cas de Proteus. En effet, l‟ajout d‟un nouvel outil

(par exemple un SCADA) sur la plate-forme ne doit pas interrompre son

fonctionnement. Il faut donc que les outils existants puissent découvrir les

nouveaux services à tout instant.

• Gestion de sécurité. Sur la plate-forme, différents acteurs peuvent intervenir. Il

faut donc pouvoir gérer les droits des utilisateurs comme des applications

(définies par contrat entre la société de maintenance et le client). De plus,

cette base d‟authentification permet de limiter les accès non autorisés.

• Base de liens entre les instances. Chaque outil possédant sa propre ontologie, il

est indispensable de créer une base de liens permettant d‟associer un

équipement (par exemple un moteur décrit dans l‟ontologie du SCADA) à sa

documentation (décrit dans l‟ontologie du serveur de documentation). Cela

implique de nommer les objets de manière unique et de permettre une

navigation entre les différentes relations définies par les ontologies.

10

http://www.w3.org/ 11 http://www.uddi.org/


91

• Gestion des événements. Il s‟agit de centraliser les abonnements à des

évènements (alarmes, valeurs périodiques…). Un tel serveur n‟est pas

obligatoire. En effet, ces abonnements peuvent être directement souscrits

auprès de chaque producteur (par exemple, un SCADA). Le but du serveur

d‟abonnements est de diminuer le trafic sur la plate-forme.

Notons que pour des raisons de robustesse et de rapidité, ces serveurs peuvent être

distribués et/ou répliqués sur les différents sites. Nous ne traiterons pas de ces

aspects et de leurs conséquences ici.

3.1.3.2. L’« Intelligent Core Adapter »

La plate-forme est basée sur une standardisation des communications. Les

interactions doivent donc suivre des schémas de flot de données et de flot de

contrôle. Afin que les services offerts par chaque application correspondent à ces

schémas, nous introduisons le composant ICA, Figure (4.3).

Figure 4.4 : Description d'un "Intelligent Core Adapter"

Pour chaque type d‟application, nous définissons un ensemble de Web Services

standard. Le rôle de l‟ICA est donc d‟implémenter ces Web Services. Il est constitué

de trois parties: • Une API réalisant l‟interface avec l‟application existante (« Tool

Interface Wrapper »). • Un ensemble de « Business Logic Objects » : ces objets sont

chargés de transformer les données et d‟enchaîner les appels de services de

l‟application afin de réaliser le Web Service. Notons que ces objets peuvent

éventuellement faire appel à d‟autres Web Services de la plate-forme pour remplir

leur mission. Enfin, une API réalisant l‟interface entre les BLOs et la plate-forme («

Platform Interface Wrapper »). Cette API implémente l‟interface de l‟outil « idéal »

défini par l‟ensemble de Web Services standards correspondants.


92

3.1.3.3. Le « Functional Core Adapter »

Il est possible que des services ne correspondant à aucune application

préexistante soient ajoutés à la plate-forme. Pour cela, nous introduisons le FCA. Il

reprend la structure d‟un ICA à l‟exception de la partie API vers une application

existante (« Tool Interface Wrapper »).

3.1.4. Exemple d’application

Dans cette section, nous présentons un scénario simplifié de maintenance et

induisant le workflow et les différents Web Services composés correspondants

[BANG06].

Le scénario de départ est le suivant :

Une alarme est générée par le SCADA.

L‟utilisateur effectue une demande d‟intervention.

Il déclenche l‟outil de diagnostic.

Ce dernier récupère les données pertinentes auprès du SCADA.

Il propose un diagnostic.

L‟utilisateur donne son Ordre de Travail et réserve les pièces détachées

auprès de la GMAO.

Il réserve les ressources humaines nécessaires auprès de l‟ERP.

Finalement, il demande à la documentation les gammes correspondantes

(i.e. les procédures d‟intervention).

La Figure (4.4) présente le workflow issu du scénario précédent. Chaque étape a été

détaillée de façon à correspondre à un service élémentaire. Trois Web Services

composés et un enchaînement manuel ont été créés :

• Service Diagnostic. Il gère toute la partie récupération des données pertinentes du

SCADA. Comme ces données ne servent qu‟à l‟outil de diagnostic, ce service est

hébergé dans l‟ICA du système expert.

• Service Gestion Alarme. Il prend en paramètre une alarme du SCADA. Il gère le

workflow jusqu‟à la présentation du diagnostic à l‟utilisateur. Ce service n‟étant pas

rattaché à un outil existant, nous créons un FCA responsable de ce service.

• Validation du diagnostic. Cette étape étant cruciale, elle reste à la charge de

l‟utilisateur. Si il valide ce diagnostic, alors il invoque le Web Service suivant au

travers du portail Web.

• Service gestion. Il prend en paramètre la demande de l‟utilisateur et gère les

réservations jusqu‟au bout.


93

3.1.5. Evaluation du projet PROTEUS

Un système générique de maintenance devrait en toute rigueur pouvoir être

instancier pour servir n‟importe quel processus physique selon n‟importe quelle

stratégie de maintenance, avec n‟importe quel système de documentation, etc. Le

chemin est encore long avant de disposer d‟un tel système. Le projet PROTEUS

apporte quelques pierres à ce vaste problème. Ses principaux apports concernent

aujourd‟hui :

• la possibilité de rendre inter opérables des sous-systèmes hétérogènes,

• les définitions des ICA qui pour chacun des sous-systèmes conduiront à terme à

une certaine normalisation des services des divers constituants

• la description générique des équipements à maintenir en plusieurs niveaux

d‟abstraction,

• la description générique des données caractéristiques des équipements,


94

Figure 4.5 : Identification d'un workflow partant d'un scénario

• la transcription systématique des scénarios de maintenance en workflow, ce qui

permet une grande liberté aux utilisateurs en leur permettant de faire

abstraction des techniques.

Il reste plusieurs problèmes, de diverses natures, à résoudre de façon générique, on

peut citer :


95

Les problèmes des erreurs dans les workflows : elles sont aujourd‟hui prises

en charge par l‟utilisateur final, certaines d‟entre elles pourraient être traitées

automatiquement.

La gestion du parallélisme et des relations d’ordre (total ou partiel) : dans

les workflows on devrait pouvoir gérer des demandes de service parallèles, avec

les problèmes de cohérence et les techniques de consensus et d‟engagement,

L’introduction d’autres types de coopération entre les acteurs : on a

identifié le besoin de coopérations autres, comme des modèles de type client

multiserveur déjà introduits au-dessus des éléments de service application

comme MMS.

La gestion de la qualité de service : chaque composant devrait être qualifié, les

demandes devraient l‟être aussi et la recherche des services devrait tenir compte

de la qualité requise.

Les technologies actuelles comme UDDI, WSDL ou SOAP devraient être

enrichies pour permettre l‟automatisation de certaines opérations comme la

composition de Web services et la construction de workflows, les concepts du

Web sémantique pourrait apporter certaines facilités [FENS02].

3.2. Projet TEMIC (TEleMaintenance Industrielle Cooperative)

Cette plateforme propose une solution matérielle et logicielle de télé

maintenance coopérative, permettant au personnel de maintenance d‟effectuer son

travail à distance (télé maintenance) et en collaboration avec d‟autre expert (travail

coopératif) [CARC04]. L‟accent est mis sur les aspects réseaux (hétéroginité,

dynamicité) et mobilité des membres coopérant pour la réalisation de l‟action de

maintenance. L‟intégration de solutions innovantes en terme de réseaux permet de

proposer des solutions de maintenance basé sur la mise en relation simultané, à

proximité ou à distance, des données informatiques multimédia pertinentes et des

compétences humaines adaptées. Pour cela, la plate-forme TEMIC intègre diverses

technologies :

Réseaux : ils peuvent être cablés (LAN, WAN) ou la sans fille (GPRS, WiFi,

Bluetooth).

Terminal : PC, ordinateur portable, PDA, téléphone portable. Avec différentes

ressources, capacité d'affichage, protocole de transmission.


96

Applications multimédia : VOD, vidéoconférence, téléchargement de dossier.

Elles fonctionnent avec des protocoles spécifiques et formats audio visuels.

La figure (4.6) présente un exemple de télé--maintenance dans une imprimerie

industrielle. Ce système permet à des experts d'effectuer un diagnostic collaboratif,

la réparation et la maintenance préventive à distance. En bas du schéma nous

pouvons voir la partie client (sur le site de maintenance) et en haut l'entreprise

responsable de la maintenance, composée d'agents mobiles (a gauche) et agents

immobile (experts) apportant l'expertise d'e-maintenance. La gestion d'alarme pour

une intervention de télé-maintenance se déroulera en trois phases :

Première phase : Une alarme apparaît sur une interface, elle est en suite

analysée par un système de réseaux de neurones, pour déterminer son type (fausse

alerte, état de dégradation, panne brusque et persistante). Selon cette analyse, le

système rédigera un rapport, lancera une commande ou entamera une session de

maintenance collaborative.

Figure 4.6 : La télé--maintenance dans une imprimerie industrielle


97

Deuxième étape : Recherche des intervenants : si une maintenance collaborative

a été lancée, une première connexion sera établie par l'envoi de messages SMS vers

le personnel disponible et préenregistré. Le but sera d'alerter le personnel de la

maintenance (local ou à distance). Ces messages seront relayés par un serveur

permettant de cibler Le meilleur groupe d'intervention (selon leurs compétences,

leurs privilèges, les outils dont ils disposent, et leur localisation…).

Troisième étape : Processus de réparations : les réparations peuvent être faites à

distance avec une liaison mobile, basée sur un échange d‟information restreint

(comme SMS) ou par l'intermédiaire de GPRS (service WAP) ou par Internet, afin

d‟établir une connexion avec le groupe de maintenance qui a reçu l'alerte,

permettant ainsi la transmission et l‟échange de données au sein d‟une

architecture client serveur. Selon la qualité de la connexion, dépendra le medias

proposés.

3.2.1. Evaluation de la plateforme TEMIC

TEMIC propose une solution innovatrice de maintenance collaborative, qui

donnera aux acteurs de la maintenance un ensemble de médias et d'outils d'aide à

la décision. Le lien entre l'aspect matériel et logiciel est essentiel pour réaliser un

outil complet de télé--maintenance.

Pour les aspects de logiciel, l'intérêt de divers médias est de fournir un outil complet

pour l'aide à la décision même dans le cas de connections limités (bande passante).

L'utilisation de l‟intelligence artificielle (réseaux neurones) pour la prévision de

panne et le diagnostic apportent une réponse appropriée à la complexité de données

dans la télémaintenance, et une bonne réactivité pour les systèmes temps réel. De

plus la flexibilité est très importante, sur les réseaux (IP, GSM, GPRS,…), sur les

terminaux (PDA, borne WAP, ordinateur portable,…). Nous pouvons noter aussi que

la plate-forme s'adaptera facilement à divers domaines (pharmacies, industrie

automobiles).

3.3. TELMA Plate-forme d’intégration de télémaintenance pour l’enseignement

et la recherche

La plate-forme pédagogique et de recherche TELMA utilisable en local et à

distance, a été élaborée afin de supporter les enseignements de la maintenance et


98

d‟illustrer l‟apport des nouvelles technologies de l‟information dans le processus de

maintenance et les nouvelles architectures qui en découlent. La plate-forme est

pilotée par des composants communiquant par réseau de terrain (Ethernet

industriel), ouverts vers le niveau Entreprise (Ethernet et Intranet) et son

environnement (Ethernet) [LEVR05]. La plate-forme est capable de générer un

ensemble de défaillances qui viennent nuire au fonctionnement « normal ». Il s‟agit

également d‟une plate-forme d‟expérimentation support à des recherches

développées dans le cadre d‟un projet de recherche du CRAN. Situé à l'Université

Henri Poincaré de Nancy, TELMA a été défini pour répondre à un groupe

d'enseignants et de chercheurs qui ont à leur disposition une plate-forme de

formation dans les domaines de maintenance, télémaintenance, et e-maintenance

[IUNG03]. Basée sur un processus physique connecté à la fois à une architecture

d'automatisation et d'une architecture de maintenance [LEVR06]

3.3.1. Objectifs de la plate-forme TELMA

L‟objectif visé par ce projet est donc de mettre à disposition de l‟enseignement,

une plate-forme d‟expérimentation en relation avec les nouveaux besoins exprimés

par les entreprises, dans les domaines de la maintenance et de la sûreté de

fonctionnement, liés au développement des nouvelles technologies de l‟information

et de la communication (télésurveillance, télémaintenance et e-maintenance). Cette

plate-forme est conçue pour :

un usage local dans le cadre des activités de formation classique,

une utilisation à distance via Internet pour l'opération sur l'industrie des

services électroniques (c -à -d télésurveillance), et pour accéder aux données

de production, données sur le rendement;

une utilisation pour l'e-enseignement et e-apprentissage comme support

d'application de cours dans les domaines d‟e-maintenance.

La plate-forme est actuellement utilisée pour démontrer la faisabilité et les bénéfices

potentiels des approches d‟e-maintenance (projet DYNAMITE) [MULL07]. En

particulier, la prise en charge ainsi que le déploiement du processus de pronostic.

3.3.2. L’architecture technique de la plateforme TELMA


99

Les principes généraux de conception et réalisation de la plate-forme TELMA

ont profité de l‟expérience acquise dans les travaux précédents sur le

développement et la construction de la plate forme IMS du CRAN [LEGE01]

3.3.2.1. La partie opérative

La partie opérative de la plate forme simule un processus de production semi-

continu, répandu dans l‟industrie automobile (ligne de découpe de flancs

métalliques, ligne d‟emboutissage, …), dans l‟industrie papetière ou l‟imprimerie.

La plate-forme TELMA est articulée autour d‟un système mécanique simulant le

déroulement en bande continue d‟un produit sous forme de bobine, servant une

presse verticale.

4 postes de travail assurent la production. L‟alimentation de produit est simulée

en entrée par un système automatisé de Changement de bobine, constitué d‟un

barillet supportant deux bobines, entraîné par un vérin pneumatique.

Le produit est matérialisé par une bande continue, dont l‟avance est assurée par

deux systèmes mécaniques d‟entraînement.

1. Le premier (Accumulation) achemine le produit en entrée de la presse, en

assurant une tension constante de la bande, contrôlée par un capteur

(analogique ou TOR), afin d‟éliminer les risques de déchirement du produit.

2. Le second système en aval (Avance) tire sur le produit pour l‟amener sous la

presse et y subir une opération de Poinçonnage, en respectant des exigences

strictes de positionnement du produit.

3.3.2.2. La partie commande

La plate-forme TELMA est pilotée par des composants communiquant par

réseau Ethernet industriels ouverts vers le niveau entreprise (Ethernet et Intranet),

l‟installation est constituée de 2 automates, le premier assure le

contrôle/commande de la plate-forme alors que le second est chargé de générer des

défaillances et dégradations contrôlées. La parti control/commande de la plate

forme est constituée de :


100

Un module d’entrées/sorties permet le contrôle des énergies (pneumatique

et électrique), des balises lumineuses (qui reflètent l‟état de la plate-forme),

du pupitre et du module changement de bobine.

Un serveur OPC situé sur le PC local permet de mettre à disposition l‟état

des différents composants de la plate-forme (capteurs, actionneurs,

moteurs…).

Une caméra Web pilotable permet de visualiser à distance et à tout moment

le système en fonctionnement.

Un automate programmable inclus des filtres de comportement permettant

la détection par la partie commande de défaillances et dégradations (capteurs

et actionneurs) (distribution traitements de maintenance dans la partie

commande). L‟utilisateur (enseignant ou chercheur) peut choisir d‟activer ou

non ces filtres afin de laisser se propager la défaillance.

3.3.3. Génération de défaillances

La plate-forme TELMA est capable de générer un ensemble de défaillances

qui viennent nuire à son fonctionnement « normal ». Pour cela l‟architecture

technique de la plate forme a été complétée par l‟ajout des Modules de génération

de Défaillance placés sur certains capteurs et actionneurs. D‟autres composants

ont été ajoutés afin de simuler des dégradations (vérins presseurs, vérins rotatifs de

courroie, frein magnétique).

3.3.4. Conditions de mise en place

Cette plate-forme devait répondre à un certain nombre de contraintes pour une

utilisation dans un contexte pédagogique [LEVR05].

Elle devait être représentative d‟une réalité industrielle afin qu‟elle soit crédible

dans ses modes de défaillances et leurs conséquences, elle devait être simple

afin que son fonctionnement soit compréhensible des étudiants,

elle devait être fiable et disponible 24h/24h sans un personnel technique

présent, afin d‟être accessible à distance.

elle ne devait pas être dangereuse pour les utilisateurs ou les personnes

évoluant dans son environnement.


101

3.4. OSA-CBM (Open System Architecture for condition-Based Maintenance)

Un regroupement de scientifiques et d‟industriels américains ont proposé le

cadre OSA-CBM (Open Systems Architecture for Condition-Based Maintenance)

(LEBO01), avec la volonté de standardiser une architecture « type » en maintenance

conditionnelle,. Cette architecture est structurée en 6 couches, créant une

succession linéaire des sous-processus nécessaires pour mener à bien cette

maintenance. Le pronostic se situe après le processus « Health assessment »

permettant de définir l‟état du système. Bien que cela ne soit pas dit explicitement,

ce processus intègre la fonction de diagnostic permettant de connaître le ou les

modes de défaillance/dégradation courants. Le pronostic se situe en amont du

processus « Decision support » qui permet de choisir les opérations de maintenance

à programmer pour rétablir le système dans un état et des performances donnés.

L‟architecture précédente couvre le domaine de l‟acquisition de données jusqu‟à la

décision avec une identification des données majeures échangées entre sous

processus et modélisées à travers les travaux de l‟association MIMOSA12.

Dans le modèle OSA-CBM, on peut identifier 5 grandes classes de flux

informationnels « d‟entrées » relatives : aux connaissances sur le fonctionnement

passé, au système, aux conditions opérationnelles futures, à l‟état courant du

système, au contrôle. Ce modèle permet aussi de définir les classes de sortie de la

couche « Prognostics » :

– le résultat du pronostic : il s‟agit directement de ce qu‟OSA-CBM appelle PLData

(différentes informations sur le résultat du pronostic sous la forme de RUL, de

distribution de probabilité de RUL, les performances futures du système).

– les identifiants du résultat du pronostic : cette classe de sortie est composée de

deux sorties, PL Configuration et PL Control Vector. Ces sorties permettent

d‟identifier un résultat de pronostic en lui associant les données du contrôle (PL

Control Vector), l‟algorithme choisi et la définition de l‟intervalle de pronostic (PL

Configuration).

– l‟explication du résultat du pronostic : elle est donnée par PL Explanation.

– l‟actualisation de l‟historique du pronostic (PR History).

12 http://www.mimosa.org

http://www.mimosa.org/


102

Néanmoins la provenance de tous les flux n‟est pas précisée, il est donc

difficile de les attribuer à l‟une ou l‟autre des différentes autres couches du modèle

OSACBM. De plus, la modélisation du processus de pronostic reste très générale

vis-à-vis des flux entrants et sortants, ils n‟identifient pas les sous-processus

génériques conduisant au déploiement de ce processus.

Figure 4.7 : L’architecture OSA-CBM [COCH07]

3.5. La méthode “Scoop” pour les systèmes coopératifs

[STVZ06] a étudié la modélisation de systèmes coopératifs et son application à

l‟e-maintenance. Il propose une méthodologie ainsi que des outils, pour la

modélisation, la mise en œuvre et la simulation de systèmes coopérants : “Scoop”

(Simulation des Systèmes coopératifs). Cette méthodologie se décompose en cinq

phases :

1. La phase “besoins préalables” consiste en une définition et un découpage

des systèmes coopératifs.

2. La phase “besoins finaux” est un découpage plus fin des définitions

précédentes


103

3. La phase “conception architecturale” utilise les deux phases précédentes

pour définir un méta modèle de structure du système. C‟est dans cette phase

qu‟est définie la nomenclature complète des acteurs du système et de leurs

interactions.

4. La phase “conception détaillée” comporte plusieurs niveaux :

a. la modélisation des interactions entre les acteurs par des réseaux de

Petri colorés.

b. la modélisation et la définition des connaissances/croyances des

acteurs par des fichiers XML basés sur une DTD spécifique au

système. Ce formalisme a été utilisé par Saint-Voirin car “les membres

décrits ne possèdent pas une représentation complexe de

l‟environnement, de ce fait, nous n‟utilisons pas les langages

RDFS/OWL ou les ACL[...]”.

c. la modélisation des comportements en utilisant les langages

PLOOMUNITY qui sont des langages formels orientés agents.

5. La phase “implémentation”

Scoop propose deux façons de modéliser les systèmes coopératifs :

a. Les réseaux de Petri stochastiques permettent de modéliser les

interactions du système. La simulation de ces réseaux permet

d‟obtenir des résultats sur ces interactions.

b. La deuxième proposition est la simulation par un système multi-

agents. Le paradigme multi-agents étant conçu pour la modélisation,

la simulation du travail collaboratif.

Saint-Voirin [STVR06] a démontré en appliquant la méthode scoop sur le

démonstrateur PROTEUS13, que le taux d‟échec des diagnostics de panne est de

77%. Ces résultats sont en accord avec les simulations qu‟il a effectuées. En effet, il

précise que le système PROTEUS ne dispose que d‟un pool de 5 experts disponibles

et d‟un groupe de 3 experts. Or, ses simulations montrent que la taille idéale de ce

pool serait d‟environ une trentaine d‟experts.

13 Voir paragraphe 3


104

Figure 4.8 : Modélisation des interactions entre 3 experts en mode synchrone

[STVZ06]


105

Figure 4.9 : Capture d’écran du simulateur des systèmes coopératifs [STVZ06]


106

Le tableau (4.1) présente une synthèse sur les approches présentées ci-dessus sur la base d‟un ensemble de critères proposés par

[MULL07b].

Plateformes

Maintenance à distance

Maintenance Collaborative

Maintenance Prédictive

Capitalisation de la

connaissance

Inter-opérabilité

Intégration de la

Maintenance

Collaboration

formalisation des

Processus

Knowledge management

PROTEUS MA MA MI MI MA MA

TEMIC MA MA MA MA MA

TELMA MA MA MA MI MI MA MI

OSA-CBM MA MA MA MA MI

MA : contribution majeure, MI : contribution mineure

Tableau 4.1 : Positionnement des contributions des plateformes de e-maintenance [MULL07b]


107

4. L’approche proposée

Nous avons relevé suite à l‟évaluation des différents systèmes et sous

systèmes en e-maintenance (Tableau 4.1), plusieurs inconvénients, tel que

l‟absence de modèle claire dans la plateforme TEMIC, qui se rapproche plus d‟une

application de GMAO, puisque on y insiste surtout sur l‟aspect physique de la

coopération dans la maintenance, avec de simple envoie de DI (demandes

d‟interventions) à des PDA ou via SMS selon des règles et des chemins préétablis.

D‟autre part, PROTEUS et OSA-CBM, ont pour objectif de gérer l‟interopérabilité et

les interactions entre les sous-systèmes impliqués dans le cycle de vie de la

maintenance (SCADA, ERP, GMAO…), au détriment de la coopération entre acteurs

humains, de plus ces plateformes sont plus orientées vers une maintenance

préventive que celle corrective donnant lieu à un processus de diagnostic. Nous

avons résumé notre étude comparative dans le tableau (4.1), où nous avons évalué

les différentes plateformes de e-maintenance selon la nature de leurs contributions

(majeur/ mineur), et en fonction des critères proposés par Muller [MULL07b], et

qui ont permis de mettre la lumière sur plusieurs axes à améliorer, dont on a

retenu, la modélisation et l‟implémentation de nouveaux processus (e-contrôle, e-

diagnostique, e-logistique, etc.) accompagné du développement de nouveaux

systèmes de e-maintenance, intégrant de nouveaux protocoles pour la collaboration

et la négociation tel que les Workflow , Web services ….etc.

4.1. Amélioration de la méthodologie « SCOOP »

L‟approche SCOOP [STVZ06] se présente sous forme d‟une démarche

saccadée, hachée (Parfois redondante), modélisant des bribes (nomenclature) de

système coopératif plutôt que l‟ensemble des acteurs et des interactions présent au

sein d‟un processus de maintenance coopérative. Saint Voirin [STVZ06] a utilisé

dans la méthodologie Scoop plusieurs modèles (RDP, UML, EDP stochastique,

PLOOM-UNITY, SMA, XML…) à travers différentes phases (spécification formelle,

modélisation structurelle, modélisation des interactions, modélisation des

connaissances) afin de définir la coopération et la coordination entre experts

impliqués dans un processus de diagnostique. D‟autre part, une nomenclature

spécifique à cette approche a été créée. Cette dernière est donc de faite inconnu.


108

[STVZ06] avait fait le choix des systèmes multi-agent combinés à d‟autres

méthodes de modélisations, au détriment des Workflow. Bien qu‟il a lui même

reconnu lors des ses travaux, que l‟analyse d‟un système coopératif par workflow

permet un bon niveau de compréhension. Cependant il a conclu qu‟il n‟existe pas

de représentation bien défini dans le domaine de la représentation par wokflow, et

que les formalisations existantes ne permettaient pas la définition d‟un système

globale, une vérification ou une simulation.

C‟est pourquoi, nous voulons à travers notre contribution (CDW : Cooperative

Diagnosis Workflow) démontré qu‟en utilisant un système basé sur une

modélisation Workflow, qu‟on simplifiera la démarche SCOOP, en réduisant

considérablement les différents niveaux d‟abstraction, et ainsi, augmenter

l‟efficacité, la rapidité et la fiabilité des modèles. Ces derniers seront basés sur un

langage de modélisation formel ou semi formel (voir chapitre 5), reconnu dans le

domaine de la modélisation des processus collaboratif [LARD05]. Le langage de

spécification du Workflow, permettra de générer automatiquement un RDP (voir

chapitre 6), afin de valider le modèle source et par la même occasion, d‟effectuer

certaines vérifications et simulations sur ce dernier, comme le préconisait Saint-

Voirin [STVZ06].

4.2. Implémentation de la plateforme CDW

La modélisation workflow du processus de maintenance collaborative a donné

lieu à une application workflow (CDW) d‟aide au télédiagnostic coopératif, qui

s‟appuie sur les résultats des différentes plateformes existantes (GENIE, PROTEUS,

TEMIC, CALIF…) tout en représentant une véritable alternative à ces dernières. Le

tableau (4.2), intègre notre proposition (CDW) ce qui nous permet de positionner

notre démarche par rapport aux plateformes proposées tableau (4.1) en exploitant

les mêmes critères. Notre proposition est basée sur une architecture Workflow, et

permet de mettre sur pied un Workflow opérationnel et autonome, dont l‟objectif

principal est de coordonner les interactions entre les différents acteurs intervenants

au sein du processus de maintenance. La plateforme CDW est composé d‟un

module d‟automatisation du Workflow permettant d‟implémenter une

représentation informatique du modèle de processus de e-maintenance en utilisant

un outil informatique regroupant toutes les définitions de processus nécessaires

avec les informations les plus pertinentes (documents, délai, droit d‟accès…etc.).

L‟implémentation de ce workflow permettra ainsi de définir la logique déterminant

dynamiquement les itinéraires des processus.


109

MA : contribution majeure, MI : contribution mineure

Tablea 4.2 : Positionnement de (CDW) par rapport aux plateformes de e-maintenance

Plateformes

Maintenance à distance

Maintenance Collaborative

Maintenance Prédictive

Capitalisation de la

connaissance

Inter-opérabilité

Collaboration

formalisation des

Processus

Knowledge management

PROTEUS MA MA MI MI MA MA MA

TEMIC MA MA MA MA MA

TELMA MA MA MA MI MA MI

OSA-CBM MA MA MA MI

CDW MA MA MI MA MA MA MI


110

5. Conclusion

Nous avons présenté dans ce chapitre, quelques travaux ayant donné

naissance à différents outils et plateformes, visant à coordonner le travail coopératif

entre différents acteurs intervenants dans un processus de maintenance de

manière général, ou de diagnostic plus spécifiquement. Cependant, suite à leur

évaluation, nous avons relevé plusieurs carences, que nous proposons de corriger à

travers notre approche CDW (Cooperative Diagnosis Workflow) basée sur une

architecture Workflow. Cette dernière a donné lieu à une plateforme (voir chapitre

6) permettant d‟assister les différents acteurs impliqués dans un processus de

maintenance coopérative. Cependant, l‟efficacité d‟une telle plateforme est tributaire

de la qualité du modèle worflow introduit en amont. Cette qualité de modélisation

passe en premier par le choix d‟un langage de modélisation adapté au processus

coopérative, et satisfaisant des critères de vérification et de simulation. Cette

problématique de choix du langage de modélisation, fera l‟objet du prochain

chapitre.

Chapitre 5 : Modélisation d’un Workflow pour l’e-maintenance

111

Chapitre 5

Modélisation d’un

Workflow pour la

e-maintenance


112

1. Introduction

Après avoir présenter dans les précédents chapitres, les principales notions

se rattachant aux concepts de la maintenance et de la coopération, ainsi que les

principaux outils informatiques permettant de mettre en place une plateforme de

coopération entre les différents acteurs de la maintenance. Nous consacrons ce

chapitre à compléter notre démarche CDW (Cooperative Diagnosis Workflow), en

choisissant un langage de spécification workflow permettant de modéliser la

coopération d‟un groupe d‟experts impliqué dans un processus d‟e-maintenance.

Nous entamons ce chapitre par la problématique du choix du langage de

modélisation, une fois ce dernier défini, nous modélisons les différentes étapes du

processus de diagnostic d‟une panne, et ce, en se basant sur l‟algorithme de gestion

de la coopération proposé par [BOUS01].

2. Modélisation d’un processus de maintenance coopérative

2.1. Modélisation du processus

La modélisation des processus vise tout d‟abord à représenter sous forme

graphique, en utilisant un langage spécifique, le fonctionnement d‟un système

complexe (une organisation ou entreprise). Il est important d‟arriver à une

modélisation qui est suffisamment pertinente pour qu‟on puisse se baser sur elle

dans des buts d‟amélioration de processus. Néanmoins, il faut toujours essayer de

garder une représentation simple et compréhensible, sinon une analyse des

modèles devient impossible. Comme cité précédemment, il existe toujours différents

éléments de base d‟un processus devant être modélisés :

· L‟activité symbolisant une étape du processus

· Le rôle accomplissant une activité

· La route représentant la transition entre les activités

· L‟objet transitant par les activités et subissant des transformations

Une activité de modélisation commence donc toujours par la description de

l‟existant. Comment l‟équipe fonctionne ? Qui fait quoi ? Comment est-ce que les

choses sont faites ?


113

Une fois cette étape franchie, il faut analyser la situation, procéder à des

simulations afin de les utiliser comme base pour poser des questions d‟optimisation

des processus au niveau des coûts et des délais, donc d‟amélioration de la qualité

du processus.

La troisième étape cherche finalement à trouver et analyser les dysfonctionnements

et problèmes et à partir de ce point trouver des solutions plus optimales. La

modélisation des processus sert donc un double objectif au sein du projet

Workflow. Elle permet d‟abord l‟analyse critique des processus candidats au

Workflow, et ensuite de préparer la définition de processus.

2.2. Processus d’e-maintenance

Notre démarche de modélisation se base sur le processus d‟e-maintenance

proposé par Boussedjra [BOUS01] à travers un algorithme de gestion de la

coopération d‟un groupe d‟experts, pour établir le diagnostic et la maintenance des

pannes détectées. L‟algorithme gère l‟organisation du groupe, et la communication

entre experts, il s‟appuie pour cela sur les hypothèses suivantes :

Chaque ensemble regroupé pour le traitement d‟une panne déclarée par un

technicien constitue un groupe.

A tout instant, un seul membre du groupe diffuse ses données et tous les

autres membres doivent être en attente.

Les experts sont polyvalents ou généralistes (ils ne connaissent pas les

installations).

Le site coopérant ne peut être en état de diffusion que s‟il a eu une

autorisation du coordinateur.

A tout instant, une et une seule personne est autorisée à parler ou diffuser

des données

3. Contribution

La modélisation d‟un Workflow implique de décrire précisément les agents

impliqués dans la réalisation d‟une tâche coopérative, la structure des interactions

qui unissent ces agents, la nature des informations qu‟ils échangent et la

dynamique des traitements qui doivent être effectués. Cependant, chaque année,

des dizaines de workflow sont spécifiés dans les entreprises. Dans le meilleur des

cas, l'équipe de développement se base sur une méthode rigoureuse de spécification


114

issue du Génie Logiciel. Mais bien souvent, elle se base sur une méthode « maison »,

issue d‟une adaptation d‟une ancienne méthode. Il est alors fréquent de constater

que les systèmes interactifs développés posent de nombreux problèmes

d'utilisabilité, ne répondent pas toujours aux besoins des utilisateurs, et sont

souvent mal adaptés à l'organisation du travail. Cette nécessité d‟adapter les

méthodes provient du fait qu‟il n‟existe pas de méthode unique de modélisation et

de spécification de workflow. Les développeurs qui ressentent un manque lors de

l‟application de « leur » méthode à une nouvelle situation tentent alors de l‟améliorer

selon leurs propres critères. Il en résulte alors un foisonnement de méthodes

personnelles manquant souvent de cohérence sur certains aspects de spécification.

Chaque méthode utilise généralement ses propres formalismes adaptés au

problème auquel elle s'attaque, les formalismes sont en quelque sorte la clé de

voûte de ces méthodes. Sans formalismes adaptés aux problèmes (permettant de

représenter toute l‟étendue des problèmes) et aux utilisateurs des méthodes

(adoptant une représentation aisément compréhensible), elles risquent de ne pas

être appliquées.

Dans les problèmes qui nous intéressent (e-maintenance), la coopération et les

relations de responsabilité sont essentielles. Il importe donc de représenter et

d'analyser les communications, les coordinations d'actions et les collaborations

entre les acteurs des organisations étudiées par ces méthodes.

3.1. Choix de la méthode de modélisation

Pour mener à bien la modélisation et la spécification du processus de

maintenance, il nous faut d‟abord trouver la meilleure organisation du travail. de

manière à fournir à chaque acteur les moyens technologiques qui assistent ou

automatisent son travail individuel tout en lui permettant de communiquer avec les

autres afin de coordonner les différentes activités et atteindre ainsi l'objectif global.

Selon [NURC96], une méthode de modélisation complète, doit remplir les critères

suivants :

Etre suffisamment générale pour permettre de modéliser n'importe quel

processus métier (même s'il comporte des étapes qui ne peuvent pas à priori

être mis en œuvre par un workflow),


115

prendre en charge l'analyse depuis l'identification des processus jusqu'à la

modélisation des procédures dont on veut automatiser le déroulement,

raisonner sur les objectifs à atteindre et non sur les fonctions réalisées par

les différents services d'un organisme,

permettre d'aborder des organisations complexes dont les processus ne sont

pas clairement définis. Une approche systémique est dans ce cas requise

[KUR87].

L‟étude comparative des méthodes de modélisation issue du génie logiciel

(Merise, SADT, SART, OMT et OOM…etc.) [LARD05] nous a permis de conclure que

ces dernières sont toutes orientées vers la structuration des données et des

traitements automatisés, omettant ainsi les aspects organisationnels, qui y sont

abordés que d‟une façon partielle. Ceci nous a conduit à pousser nos investigations

vers d‟autres méthodes qui peuvent correspondre aux critères proposées par

[NURC96], trois méthodes se sont alors distinguées : UML, OSSAD, et BPMN. Après

une étude comparative entre ces dernières (voir Annexe B), nous avons opté pour la

méthode OSSAD [CHAP04].

3.2 Description de la méthode OSSAD

La méthode OSSAD (Office Support Systems Analysis and Design) a été

développée lors du programme ESPRIT (European Strategic Programme for

Research in Information Technology) conduit de 1985 à 1990 par une équipe

multinationale de consultants, d'universitaires et d'usagers des technologies de

l'information. Il s'agit d'une approche systémique qui aide à comprendre comment

les gens travaillent ensemble, en incluant les personnes dans le système à

concevoir. OSSAD s'intéresse donc avant tout au fonctionnement organisationnel.

C'est une méthode qui permet d'analyser comment différentes personnes

coordonnent leurs tâches en vue de fournir un résultat global. Elle vise à :

- Fournir aux différentes parties prenantes un cadre de référence conceptuel et une

organisation du travail pour leur permettre de conduire un projet.

- Permettre d‟adapter le cadre général à chaque situation particulière.

- Fournir les outils de modélisation du travail tertiaire ou administratif.

- Permettre de concevoir en interaction (et non séparément) les sous-systèmes

techniques et humains, destinés à modifier la situation actuelle.


116

- Proposer de nouvelles opportunités de dialogues entre les managers, les

techniciens, les utilisateurs des moyens technologiques.

OSSAD, est une méthode relativement simple. Elle est notamment pratiquée dans

les entreprises privées et les administrations publiques, en Allemagne, en Finlande,

en France, en Irlande, en Italie, et en Suisse. Six principes constituent une

synthèse de la philosophie Ossadienne.

1. Participation : Un projet Ossadien ne doit pas se contenter de consulter les

utilisateurs, il doit les associer continuellement à la démarche. Cette association

s'appuie sur la clarté des concepts utilisés et leur apprentissage rapide par les

participants. Elle est garante de leur motivation et de leur implication.

2. Pragmatisme : Un projet Ossadien veut déboucher sur une solution réaliste et

applicable à un problème bien identifié. Il ne s'agit pas de modéliser pour le plaisir.

3. Expérimentation : Un projet Ossadien doit intégrer l'essai, par prototypage

technique et organisationnel, des solutions envisagées sur le papier.

4. Itérativité : Un projet Ossadien n'est pas linéaire. Des remises en question sont

possibles et souhaitables dans les limites d'une gestion rigoureuse du projet,

notamment lors de la validation des modèles par les participants.

5. Agrégation : Un projet Ossadien vise à traiter des problèmes particuliers, à leur

niveau de pertinence, sans perdre de vue l'ensemble de la situation. C'est une

démarche de type systémique.

6. Contingence : Un projet Ossadien s'organise autour du problème examiné et ne

doit pas obligatoirement faire appel à tous les outils et techniques d'OSSAD qui, de

plus, peuvent être adaptés si nécessaire.

Cette méthode propose une démarche qui se fait en trois étapes. Trois

modèles différents sont donc établis, ils répondent à des besoins bien délimités :

Abstrait14, Descriptif et Prescriptif.

14 Voir Annexe A


117

NIVEAU ROLE BUTS

Abstrait modélisation des

objectifs

Qu'est ce qui doit être fait ou atteint ?

Descriptif modélisation des

moyens Comment réalise-t-on les

objectifs ? Avec quoi et qui ?

Prescriptif spécification du

workflow

Comment sont automatisés les moyens mis en œuvre ?

Tableau 5.1 : Les niveaux de modélisation d’OSSAD [CHAP04]

Le déroulement de la méthode OSSAD, ne doit pas suivre obligatoirement

une démarche séquentielle (en utilisant l‟ensemble des niveaux de modélisation),

Cette Méthode nous permet d‟utiliser une partie des modèles qui y sont inclus,

selon les besoins de la modélisation. Nous avons privilégié dans notre démarche

d‟outre passer le niveau abstrait, pour utiliser directement le niveau descriptif (à

travers ses modèles) puisque ce dernier répond plus à nos besoins en termes de

modélisation de la collaboration et la représentation de la coordination des

interactions, entre experts dans un processus d‟e-diagnostic.

3.2.1. Le modèle descriptif

Il représente la façon pratique dont le travail est fait aujourd'hui… ou

pourrait être fait à l'avenir. Il répond aux questions : qui fait quoi et comment ?

Les concepts principaux utilisés avec ce modèle sont résumés dans le tableau

suivant :


118

Tableau 5.2 : Principaux concepts du modèle descriptif d’OSSAD [CHAP04]

Il existe trois types de modèles descriptifs : le modèle descriptif de rôles, le

modèle descriptif de procédures, le modèle descriptif d'opérations. Les deux

premiers élaborent une représentation statique du fonctionnement de l'organisme :

aucun élément chronologique n'y figure. Le troisième type de modèle constitue le

niveau le plus détaillé de la description et explicite la dynamique de l'organisation.

• Le modèle descriptif de rôles : permet de représenter la structure

organisationnelle dont s'est doté l'organisme (ou celle qui lui est proposée) pour

accomplir ses activités. Il utilise les concepts de Rôle, d'Unité et de Ressource. .

Figure 5.1 : Méta-modèle du modèle de rôles

Elément

Définition

Unité Regroupement significatif de rôles pour des besoins de

coordination et de contrôle

Rôle Ensemble de tâches effectuées par un individu, et donc des

responsabilités qu'il prend en charge dans l'organisme étudié

Procédure La procédure est l'aspect descriptif d'une activité (du modèle

abstrait), une façon de la mener à bien.

Tâches Ensemble des opérations accomplies par un rôle dans la

réalisation d'une activité (du modèle abstrait)

Opération Concept représentant le plus petit élément pertinent d'une

tâche

Ressource

La ressource (en information) est un ensemble d'informations,

groupées sous une forme concrète de stockage et de

communication Elle sert d'intrant ou d'extrant à des opérations

Outil

Outil physique et/ou technologique pour accomplir une

opération ou une tâche

acteur

unité

rôle ressour

ce 0..*

0..*

1..*

0..*

1..*

1..* 1..*

1..*

0..* 1..*

produit>

reçoit>

exerce>

<appartient

à <tenu par


119

• Le modèle descriptif de procédures permet de représenter le fonctionnement de

l'organisme, c'est à dire l'organisation du travail actuelle ou souhaitée. Il fait appel

aux concepts de procédure et de ressource. Ce modèle donne une vue d'ensemble

des relations entre procédures.

Figure 5.2 : Méta-modèle du modèle de procédures

• Le modèle descriptif d'opérations : fournit le détail correspondant à une ligne

de la matrice Activité/Rôle (donc à une procédure). On y indique qui fait quoi et

dans quel ordre. On fait apparaître ainsi la répartition du travail entre les divers

rôles. On attribue une colonne différente à chacun des rôles concernés et on y place

les Opérations qu'ils effectuent.

Figure 5.3 : Méta-modèle du modèle d’opérations

Donc, les modèles de ce niveau concernent les moyens humains, techniques

et organisationnels utilisés pour accomplir les objectifs détaillés sous la forme

d’activités. A chaque activité correspond une ou plusieurs procédures (actuelle,

future, alternative, etc…). Une procédure est un ensemble cohérent d’opérations ;

elle est réalisée de manière collaborative par un ensemble d’acteurs auxquels sont

assignés des rôles. Un acteur exerce plusieurs rôles, un rôle est attribué à plusieurs

acteurs.

3.2.2. Modélisation de l’algorithme de gestion de la coopération d’un groupe

d’experts.

Transmet

>

Procédur

e

ressour

ce

Reçoit>

0..*

0..* 0..*

0..*

Procédure ressourc

e

<participe à

produit>

1..*

1..* 1..1

1..*

tâche opérati

on

outil

ressourc

e

1..* 1..1

1..*

1..*

0..*

1..*

0..*

0..*

0..*

1..* réaliser

par>

Se décompose de> Se décompose de>

reçoit>


120

L‟algorithme de gestion de la coopération au sein d‟un processus de maintenance

coopérative se décline comme suit :

1) La création d’un groupe est initiée par le technicien (figure 5.4)

2) L’attribution de numéro d’ordre est faite ensuite selon le temps d‟arrivée des

messages d‟acquittement (figure 5.4). Le groupe construit est composé de deux

sous-groupes :

Le premier contient les experts coopérants pour la résolution de la panne et

un coordinateur. Ce sous groupe est actif : échange de données entre les

membres avec un coordinateur.

Le deuxième sous groupe est constitué des membres du groupe actif et du

technicien (ce sous groupe est optionnel).


121

Figure 5.4 : Modèle d’opération du processus de création d’un groupe

d’experts [LARE11b]

3) Le choix du coordinateur du groupe est fait en fonction de la qualité du réseau

entre lui et le site de la panne. Le rôle du coordinateur est de jouer le rôle

d‟interface de communication entre les membres du groupe et le monde

extérieur (site défaillants ou autre groupes coopérants).

4) L’affectation pour un nouveau groupe d’expert peut se faire en fonction des

numéros d‟ordre des experts en affectant au nouveau groupe existant ou par

décision du coordinateur de chaque groupe.

5) L’ajout d’un membre se fait par un appel ou une invitation du groupe par

l‟intermédiaire de son coordinateur (figure 5.5) ou alors par une demande d‟un

site libre voulant rejoindre le groupe (figure5.6). Tant que les deux sites ne sont

pas d‟accord (réception d‟accusés de réception positifs), le membre ne rentre pas

dans le groupe.

Figure 5.5 : Modèle d’opération du processus d’ajout d’un nouveau membre

par invitation [LARE11b]


122

6) le traitement d’une nouvelle panne B si tous les experts sont occupés sur une

panne A, se fera comme suit :

Si le traitement d‟une panne A en cours est terminé, alors la nouvelle panne

B est traité immédiatement et le groupe et reconstruit.

Si le traitement n‟est pas encore fini, mais qu‟une affectation d‟un ou

plusieurs experts à la panne déclarée B est possible, alors deux nouveaux

groupes sont construits, l‟un pour le traitement de la panne B et l‟autre pour

le traitement de la panne A

Sinon, la panne déclarée B ne peut pas être traité, alors elle est enregistrée

dans une file d‟attente comme un prochain travail (figure 5.7).

7) La dissolution d’un groupes d„expert construit peut intervenir afin de

répondre à l‟ensemble des pannes déclarés. Un groupe d‟experts peut être

construit en affectant des experts libres à la panne déclarée (figure 5.7).

Figure 5.6 : Modèle d’opération du processus d’Ajout d’un nouveau membre par

demande d’adhésion [LARE11b]

Site

(Experts) Coordinateur

Vérifier la disponibilité des experts

OU

NovMem

Affecter un N° d’ordre

OU

Etudier la demande

Si la demande est

acceptée

Données Si supérieur

Refuser la demande

Envoyer les

données


123

Figure 5.7 : Modèle d’opération du processus de Dissolution du groupe d’experts - fin de traitement [LARE11b]

8) La gestion de l’exclusion mutuelle est prise en compte grâce aux demandes

d‟autorisations grées par les coordinateurs et les numéros d‟ordre des

coopérants. Les demandes classées par importance sont parfois insérées dans

des files d‟attente (Figure 5.8).

Site


OU

Comparer le nombre de

pannes et le nombre de sites

Si supérieur

Terminer le

traitement Dissoudre le

groupe

Diagnostiquer une panne

OU

Contrôler la liaison

Vérifier si la file est vide

OU

Si déconnection

Chercher une panne dans la

file d’attente

Si la file est vide


124

Figure 5.8 : Modèle d’opération du processus d’Exclusion mutuelle [LARE11b]

3.2.3. Le niveau prescriptif

Les modèles Présenté ci dessous ne constituent pas une spécification

autorisant la génération d‟applications de workflow. A cet effet [CHAP00] a introduit

le troisième modèle Ossadien cherchant à préciser les détails des systèmes

techniques et organisationnels, de façon à faciliter le dialogue avec les fournisseurs

de matériels et de logiciels de manière à ce que tout ce qui permet d'intégrer

efficacement technologie et organisation figure dans ce modèle (prescriptif). Il étend

le modèle d'opérations par la spécification de ce qui sera automatisé dans un

workflow. Ceci est résumé dans les concepts de :

Document,

État de document,

Structure de document,

contrainte d‟interdiction ou d‟obligation,

Délai de réalisation d‟une opération,

Sélection et,

Notification.


125

Un document est une ressource du modèle d'opérations qui est informatisée.

La structure d'un document est un ensemble de champs informationnels. Le modèle

de document est basé sur celui du système cible de l‟application de workflow

généré, à savoir : un document est une collection organisée en « sections »de

champs de type simple ou de type «texte enrichi » dont les valeurs peuvent contenir

des liens vers d‟autres documents ou fichiers attachés.

L'état d'un document sert à dénoter sa situation relativement au flux (quelle est

l'opération faite ou à faire ?). Aux états d‟un document peuvent être associés des

modes d‟accès aux champs du document (pas d‟accès, lecture ou édition).

Lorsqu‟un document est en entrée d‟une opération, les acteurs du rôle pouvant

réaliser cette opération, ont accès à ce document. Les droits d‟accès sur un

document évoluent donc au fur et à mesure du déroulement du flux.

Les flux sont décrits avec un langage graphique qui représente l‟implantation

informatique du modèle d‟opération de la figure. Des méthodes comme Merise,et

plus récemment la notation UML, ont utilisé ce type de représentation graphique

basée sur des colonnes. Les diagrammes d‟activité d‟UML sont proches de ce modèle

graphique de spécification des flux.

Figure 5.9 : Méta-modèle du niveau prescriptif.

Procédur

e

ressour

ce

<participe

à

transmet>

1..*

1..* 1..1

1..*

tâche opérati

on

outi

l

ressour

ce

1..1 1..*

1..*

0..* 0..*

0..*

0..* 1..*

1..*

1..* réaliser

par>

Se décompose

de> Se décompose

de> reçoit>

0..*

0..*

0..*

1..* 1..1

délai

état

acteur

notification

sélectio

n

champ

docume

nt

accés

1..1 0..*

1..1 1..1

1..* 0..1

0..*

1..*

1..*

0..1 <émet

<émet

dépassemen

t

base

interdicti

on


126

3.2.4. Démarche de spécification.

La transformation d‟un modèle descriptif en un modèle prescriptif se fait

selon la démarche suivante :

1. identifier les ressources qui seront informatisées. Ces ressources deviennent

des documents.

2. spécifier les changements d‟état de ces documents dans les flux opératoires

(y compris les changements calculés par le système de gestion de workflow),

3. spécifier les contraintes entre opérations, si nécessaire,

4. déterminer les états pour lesquels il est nécessaire de sélectionner l‟acteur ou

les acteurs devant réaliser l‟opération suivante. Cette sélection peut être

associée à une notification par un message électronique. Les notifications

sont recommandées soit, pour des utilisateurs occasionnels d‟une

application, soit pour des utilisateurs travaillant sur plusieurs applications

de workflow.

5. mentionner les délais de réalisation des opérations, si nécessaire,

6. spécifier la structure (champs et sections) des documents.

Des contraintes entre deux opérations peuvent être définies : elles obligent /

interdisent qu‟un même acteur réalise ces deux opérations sur un même document.

Par exemple deux acteurs exerçant le rôle de demandeur peuvent remplir des notes

de frais. S‟ils exercent également le rôle d'approbateur, ils peuvent approuver les

notes de frais pour qu'elles soient remboursées. En ajoutant une contrainte

d'interdiction sur les opérations remplir et approuver, on empêche le même acteur

de réaliser ces deux opérations sur le même document.

La notion de sélection permet à l‟acteur réalisant l‟opération courante, de choisir

un sous-ensemble des acteurs devant réaliser l‟opération suivante. Par exemple

lorsqu‟un acteur du rôle contrôleur vérifie la note de frais telle que son nouvel état

soit vérifiée, la sélection permet de choisir parmi les acteurs du rôle approbateur,

celui ou ceux qui vont devoir approuver cette note de frais en particulier (par

exemple ses chefs directs plutôt qu‟éloignés).

La notion de notification est un concept lié à l‟automatisation des procédures de

travail. Elle indique que les acteurs d‟un rôle doivent être avertis par un message


127

électronique lorsqu‟un document arrive dans un état particulier et que l‟opération

qui suit relève de leur responsabilité. C‟est une façon de réaliser un mode « push ».

Un délai peut être spécifié pour la réalisation d‟une opération. Il est calculé à partir

d‟un état d‟un document (pas nécessairement celui qui est en entrée de l‟opération

considérée).En cas de dépassement du délai imparti, le document peut être mis

dans un état indiquant ce dépassement, et à partir duquel un autre flux peut être

mis en œuvre.

En appliquant toutes ces règles de transformation, nous avons pu déduire un

modèle prescriptif (Figure 5.11), qui est prêt à être introduit dans un Worklow, et ce

à partir du modèle d‟opérations (niveau descriptif) incluant la création d‟un groupe,

l‟attribution d‟un expert et le traitement d‟une panne supplémentaire (voir

Figure 5.10).

Figure 5.10: Modèle d’opération du processus de Création d’un groupe –

attribution d’un expert - traitement d’une panne supplémentaire [LARE11b]


128

Figure 5.11 : Modèle prescriptif des opérations de Création d’un groupe -

attribution d’un expert - traitement d’une panne supplémentaire [LARE11b]

4. Conclusion

Dans ce chapitre, nous avons présenté notre contribution à travers la

modélisation par la méthode OSSAD, du processus d‟e-maintenance coopérative,

basée sur l‟algorithme de gestion de la coopération d‟un groupe d‟experts proposé

par Boussedjra. Ce langage de modélisation (OSSAD) nous a aussi permis de

définir un modèle de spécification Workflow, correspondant à un modèle prescriptif

et généré à partir du modèle d‟opération, en recensant dans les processus

préalablement définis, ce qui sera géré de manière informatique, tels que les

documents qui devront être gérés par le réseau, ainsi que les règles d‟organisation

portant sur la tâche des acteurs (obligations ou interdictions). Ce choix devra être

validé à travers l‟étude d‟un exemple pratique de modélisation Workflow d‟un

processus d‟e-maintenance coopérative, qui sera traité dans le prochain chapitre.

Chapitre 6 : Etude de cas Le complexe GP1Z

129

Chapitre 6

Etude de cas :Le

complexe GP1Z


130

1. Introduction

Au chapitre précédent chapitre, nous avons traité la problématique du choix

d‟un langage de modélisation Workflow. Il serait alors intéressant, de valider ce

choix dans le cadre d‟un système d‟aide à la coopération entre experts, à travers

une étude de cas qui permet de modéliser des processus physiques selon différentes

stratégies de maintenance. Cette étude d‟un cas pratique, se déroule au sein d‟un

complexe pétrochimique spécialisé dans le traitement du GPL. L‟objectif à travers

cette étude, étant de démontrer la pertinence de notre choix en termes de langage

de modélisation pour la maintenance coopérative, et l‟apport de celui-ci au monde

de l‟industrie. L‟étude présentée dans ce chapitre s‟étale sur deux parties, dans la

première partie, nous décrivons l‟activité de maintenance telle qu‟elle est pratiquée

actuellement dans le complexe GPZ1, ce qui nous a permis de relever certaines

carences, aux quelles nous proposons de remédier dans la deuxième partie de ce

chapitre à travers notre contribution.

2. L’activité de diagnostic et de maintenance au sein du complexe GP1Z

Afin de mener à bien nos travaux de modélisation d‟un Workflow, nous nous

somme immergé dans le complexe GP1Z15 de l‟entreprise SONATRACH (Jumbo GPL)

situé dans la zone industrielle d‟ARZEW, et considéré comme l‟un des plus

importants au monde. La fonction de maintenance au sein de ce complexe

industriel à pour principaux objectifs de :

• Planifier et exécuter les travaux avec un minimum d'interférence avec la

production.

• Maintenir le niveau d'entretien désiré au moindre coût.

• Améliorer la viabilité et la fiabilité des équipements par l'entretien préventif

et correctif.

• Assurer la qualité du travail exécuté.

• Informer le Département Production des modifications de conduite des

équipements.

• Exécuter les travaux demandés en conformité avec les programmes prévus.

15 Voir Annexe C


131

• Informer le Département Production des équipements critiques et

recommander le stockage des rechanges de sécurité pour ces équipements

ainsi que leurs pièces.

Ces objectifs ne peuvent être réalisé, que si l‟équipe de production coopérer avec les

équipes de maintenance, afin de satisfaire les besoins suivants :

- Surveiller constamment la condition et la performance des équipements et

anticiper les besoins de l‟entretient

- Décrire clairement les travaux demandes, autoriser les dépenses et éviter les

travaux non indispensables

- Utiliser les équipements de façon à éviter les avaries lorsqu‟elles pourraient

raisonnablement être évites

- Établir les priorités d‟une façon réaliste et informer la maintenance aussitôt

que possible.

- Prévoir les arrêts programmes avec une avance suffisante et fournir une

information complète sur les travaux demandés.

- Rendre disponible, conformément aux engagements pris, les équipements

pour l‟entretient préventif et pour les interventions.

Figure 6.1 : Vue du Systeme SCADA16 sur un train de production

16 Voir chapitre 4


132

Figure 6.2 : Système de supervision de la production


133

D‟autre part, la fonction de maintenance du complexe GP1Z est répartie en sept

sous systèmes, correspondant chacun à une phase du processus de traitement des

défaillances :

1. le sous-système Demande de Travail.

2. le sous-système Préparation.

3. le sous-système Procurement.

4. le sous-système Programmation.

5. le sous-système Lancement et contrôle.

6. le sous-système Exécution.

7. le sous-système Informations de Gestion.

2.1. La Demande de Travail (DT)

Une Demande de Travail concerne les travaux non prévus (maintenance

corrective) tel que :

Réparations Accidentelle

Remplacements

Modifications

Nouvelle Installation

Figure 6.3 : Etablissement d’une demande de travail par une application de

GMAO17

17 GATIOR : Système de Gestion de la Maintenance, des Approvisionnements et de l'Inspection / LTH-SONATRACH


134

Les travaux à traiter par D.T. sont identifiés par le demandeur qui détermine aussi

le degré d‟urgence (Priorité) pour chaque situation dangereuse qui se présente, pour

chaque équipement sur lequel une ou plusieurs Anomalies se Manifestent et pour

chaque travail de réparation, modification ou remplacement nécessaire :

1. Priorité 1 (P1) Indique le travail qui doit commencer le jour même de la

formulation de la demande ou en cas de danger immédiatement

2. Priorité 2 (P2) Indique le travail à programmer pour le jour ouvrable qui

suit celui de la notification de la demande de travail (DT)

3. Priorité 3 (P3)

- Cette priorité sera attribuée à tous les autres types de travaux à

l‟exception de ceux à exécuter lors de l‟arrêt programme

- Le demandeur signale la contrainte « date » en indiquant sur la (DT) :

Priorité „‟3A‟‟Date du début (ou de fin) désirée

- Le demandeur laisse le choix de la date du début de travail au

département maintenance en indiquant sur la (DT) Priorité „‟3B‟‟

4. Priorité 4 (P4) Cette priorité indique le travail a exécuter lors de l‟arrêt

programme de l‟unité entière ou en mettant a profit un arrêt accidentel

5. Priorité 5 (P5) cette priorité indique que le travail ne pourra être exécuté

comme souhaite par le demandeur par suite d‟un empêchement majeur

comme manque des matériaux, attente des spécialistes etc.….Le

département maintenance avisera le demandeur sur cet empêchement

Après avoir choisi la priorité de la demande de travail, il faudra par la suite désigner

le genre de l‟intervention demandé :

- Accidentel : tout Travail de Réparation ou de remplacement exécuté

à la suite de défaillance des Equipements

- Préventif : toute Intervention résultant d' un Programme d'Entretien

Préventif Des Inspections imposées par la Loi

- Modifications / Déplacements : toute Modification ou Déplacement

d'Installation ou d'Equipements

- Travaux Permanents : tous les Travaux couverts par les D.T.P.

2.2. La Préparation


135

Cette phase consiste à assister les services opérationnels en leur donnant

tous les éléments nécessaires à l'exécution des travaux sur les aspects tel que le

mode opératoire, la durée, les délais, ainsi que les moyens requis. Surtout les

travaux de longue durée et les travaux répétitifs en définissant:

- Les mesures de sécurité à prendre

- La gamme opératoire avec :

Les points clés de l'Intervention

Les phases du travail et leur enclenchement

- Les moyens nécessaires: matières, pièces, outillages

- Le nombre d‟intervenants

- La durée estimée du Travail

Figure 6.4 : Différentes taches durant la phase de préparation

2.3. La programmation


136

Cette phase consiste à repartir au mieux le travail à exécuter dans le

temps en tenant compte des moyens disponibles et en économisant les couts

d'Intervention

2.4. Le Procurement

Les principaux objectifs de cette étape sont :

• Détermination des actions à entreprendre.

• Consultation d'entreprises.

• Contrôle disponibilité Matériaux.

• Lancement de demandes d‟achat

• suivi et contrôle des livraisons.

Figure 6.5 : Différentes taches durant la phase de Procurement

3. Critiques et améliorations


137

La relation traditionnelle de la maintenance avec la production telle que celle

utilisée au sein du complexe GP1Z, est principalement basée sur une demande

d‟intervention (DI], concrétisée par un ordre de travail (OT). Mais les choses ont

beaucoup évolué : en effet, nombre d‟entreprises qui ont engagé des

investissements importants dans des machines automatisées, théoriquement

capables de rythmes de production soutenus, ont découvert que cela ne suffisait

pas pour atteindre les objectifs de production fixés. Pour un même investissement,

leurs concurrents obtenaient des rendements supérieurs sans que l‟on sache

toujours exactement ce qui était en cause : maintenance, exploitation ou

conception.

Les observations effectuées sur les unités de fabrication performantes

aboutissent souvent au constat suivant : l‟amélioration de la conception des

moyens et des procédés permet d‟amener des gains de productivité est ainsi, les

entreprises ont amélioré la fiabilité, la maintenabilité et le rendement intrinsèque

de leurs machines. Cependant des pertes de capacité de production subsistent à

cause de trois origines (voir figure ci-dessous) :

Arrête pour maintenance : arrêts pour assurer l‟entretien programmé

(préventif, rénovations, visites réglementaires, etc.) ;

Réglage, microdéfaillances : petits dysfonctionnements (déréglages,

desserrages, fausses manœuvres, manque d‟ergonomie...) qui ne nécessitent pas

nécessairement l‟appel à la maintenance.

rebuts, mauvaise qualité : ils sont provoqués par les causes précédentes mais

également les aléas de procédés, les défauts de réglage ou les erreurs humaines.

Pertes Capacité de

production

Capacité

théorique

Arrêt pour

maintenance

Réglage,

microdéfaillance Rebus,

mauvaise qualité

Production

Implication

Maintenance

Production

90%

10%

50%

50%

10%

90%


138

Figure 6.6 : Causes des pertes de capacité de production et implication des

services

3.1. Un Workflow pour l’e-maintenance

Dans notre étude, nous nous focalisons sur la maintenance corrective, qui

consiste à intervenir après la constatation d‟une défaillance, durant laquelle, les

équipes de maintenance du complexe GP1Z procèdent comme suit:

constatation de la défaillance.

mise en situation sécuritaire du composant défaillant comme l‟arrêt du moteur,

la coupure du courant, etc. Cette action doit se faire en se référant au dossier

machine du composant.

Le placement en situation sécuritaire doit être accompagné d‟une analyse du

système.

La détection et la localisation des éléments défaillants.

La conduite du diagnostic. Cette conduite se déroule en s‟appuyant sur les

données disponibles dans le dossier technique, le technicien émet une

hypothèse possible de la cause de la défaillance,

Si l‟hypothèse est vérifiée, le technicien la met en évidence et identifie ainsi

l‟origine de la défaillance. Sinon, le technicien fera appel à des experts locaux ou

distants (fournisseurs, consultants), qui coopéreront afin de diagnostiquer la

panne signalée par le technicien. C‟est cette dernière procédure qui sera au cœur de

notre approche Workflow (CDW). On se basera pour cela sur la démarche de

Boussedjra [BOUS01] présentée dans le chapitre précédant. La plateforme CDW

(Cooperative Diagnosis Workflow) d‟aide à la maintenance coopérative, est basée

sur une architecture Workflow (figure 6.7), qui permet via trois phases

indissociables, de mettre sur pied un modèle opérationnel et autonome, dont

l‟objectif principal est de coordonner les interactions entre les différents acteurs

(experts) intervenants au sein du processus de maintenace.


139

Figure 6.7 : Architecture du système CDW conforme au modèle de référence

WfMC [LARE11]

3.1.1. Phase de modélisation du processus

Cette phase consiste à élaborer des modèles simplifiés de la réalité pour

résoudre les problèmes d‟organisation liés au processus de maintenance

coopérative (figue 6.9]. C‟est sur ces représentations abstraites que va se fonder

toute l‟analyse puis la réalisation informatique des processus de travail. La création

de ces modèles est réalisée par le biais du module de modélisation : CDW_Designer.

3.1.2. Phase génération du Workflow

La génération du Workflow consiste en une génération directe du modèle de

niveau perspectif à partir du modèle d‟opération. Une fois le modèle de spécification

Workflow généré. Il s‟agit ensuite de dégager ce qui, dans les processus

préalablement définis, sera géré de manière informatique, tels que les documents

qui devront être gérés par le réseau. Ainsi que les règles d‟organisation portant sur

la tâche des acteurs (obligations ou interdictions). Cette phase exigera

l‟introduction d‟un module d‟automatisation du workflow : CDW_Builder (figure

6.10). Ce module permet d‟implémenter une représentation informatique du modèle

de Processus en utilisant toutes les définitions de processus nécessaires avec les

CDW_Designer

Module

d’administration :

CDW_GlobalViewer,

CDW_Statistics…

CDW_Messenger

CDW_Editor …

CDW_Builder

Moteur workflow

(CDW_ Server)

Interface1

Interface3 Interface2

Inte

rfac

e 5


140

informations les plus pertinentes (documents, délai, droit d‟accès…etc).

L‟implémentation du Workflow permet ainsi de définir la logique déterminant

dynamiquement les itinéraires des processus au sein du processus global de

conception préalablement modélisés. Les 3R définis dans le chapitre 3 doivent pour

cela être respectés :

Les rôles, devant être définis indépendamment des individus réellement

impliqués dans l‟entreprise. D‟où la notion d‟acteurs

Les règles décrivant les conditions d‟exécution des activités, en intégrant les

applications extérieures au Workflow (CDW_Editor)

Les routes assurant la liaison entre les activités et les acteurs via

l‟application cliente de messagerie (CDW_Messenger).(figure 6.8)

Figure 6.8 : Module d’envoie de notifications CDW_Messenger


141

[LARE11 ????

Figure 6.9 : Saisie du modèle Workflow OSSAD par l’application

DUOProcss


142

Figure 6.10 : Module de génération de Workflow : CDW_Builder

3.1.3. Phase d’exécution du Workflow

L‟exécution du processus est contrôlée de façon automatisée par le moteur de

Workflow. Ce dernier se charge de distribuer les tâches aux personnes chargées de

leur réalisation et d‟effectuer lui-même quelques actions automatiques selon les

modes «push». Ainsi, le Workflow pousse les documents à traiter vers les

utilisateurs en fonction des règles de gestion du flux et de leur charge de travail

(dans le mode «pull», les utilisateurs iront eux-mêmes chercher les documents sur

lesquels ils doivent travailler). Les tâches à réaliser seront envoyées dans la boîte à

tâches des utilisateurs (Figure 6.12), une tâche se présentera sous la forme d‟un

bon de travail (Figure 6.11) comprenant une description de l‟action à réaliser.

Figure 6.11 : Bon de travail envoyé au client pour le lancement d’une tâche


143

Figure 6.12 : Boite de réception de tâches du CDW_ApplicationClient

Le moteur de Workflow contrôle donc la réalisation du processus, alimenté par les

règles définies dans le modèle de processus, il calcule les tâches à réaliser en

fonction des tâches déjà effectuées et des données qui y ont été enregistrées. Il

informera en temps réel les différents acteurs en leur faisant parvenir le travail qui

leur est affecté, un peu comme un serveur de messagerie distribue le courrier

électronique entre les utilisateurs (Figure 6.7). Le moteur Workflow sera aussi

responsable de tenir à jour la base de données du suivi où vont s‟inscrire tous les

évènements relatifs au processus.

3.2. Génération des Réseaux de Petri à partir des modèles OSSAD

Il a été souvent reproché aux modèles Workflow l‟absence de possibilité de

vérification et de simulation dus principalement au manque de formalisme. Le

modèle perspectif (Workflow) d‟OSSAD n‟est pas à l‟abri de ces critiques, puisque

(de par la volonté de ses concepteurs) OSSAD est une méthode relativement simple,

et dont l'interprétation est peu formalisée pour qu'on puisse espérer la prendre en

compte, pour effectuer des analyses, des vérifications ou pour simuler un modèle.

Pour pallier à ces carences, Van Der Aalest a introduit dans [Aal96] [Aal97] la

notion de WF NET, des Workflows basés sur une modélisation par réseaux de Petri

(RdP). L‟argumentation de Van Der Aalest s‟est basé sur le fait que les RdP sont un

langage graphique intuitive et qui abouti à des modèles Workflow dont la définition

est claire et précise. De plus, ces dernières années, beaucoup de recherches ont été

menées sur les propriétés mathématiques des différentes variantes de RDP, ce qui a


144

engendré un foisonnement de méthodes et techniques d‟analyse de RDP qui ont été

d‟un grand apport à la modélisation Workflow. Puisque ces techniques, ont permit

de prouver les propriétés des modèle (vivacité, conflit, invariant…) ainsi que de

mesuré les performances à travers divers outils d‟analyse et de simulation.

Figure 6.13 : Exemples de règles de passage du Modèle OSSAD vers les RDP

[CHAP04]

Cependant, on ne peut permettre de laisser à l‟utilisateur final la charge de créé

des réseaux de Petri qui sont plutôt l‟apanage d‟expert chevronnés dans le domaine

de la modélisation informatique et mathématique. C‟est pourquoi, on utilisera les

fondements théoriques du formalisme « Ossadien » afin de générer


145

automatiquement des réseaux de Pétri où Les états (d‟un Rôle, d‟une Ressource ou

d‟un Outil) seront interprétées comme des « places » et Les Opérations (de ce

même modèle), représentées habituellement par des carrés seront interprétées

comme des « transitions ». Les réseaux de Petri ainsi obtenues, auront une

syntaxe bien définie et une interprétation logique. Ils permettront de représenter les

inter-dépendances entre opérations en termes de séquence, de disponibilité, de

parallélisme ou simultanéité (ET), de conflit ou exclusivité (OU) (figure 6.14).

Remarque : Dans certains cas, pour simplifier, les places (cercles) ne sont figurées

qu’en début et en fin, ainsi que pour les « OU ».

3.3. Vérification des propriétés d’un RDP

L‟évolution d‟un RdP se fait par franchissement de transitions. Lorsqu‟au

cours de leur évolution, certaines transitions ne sont jamais franchies, cela indique

que le sous système modélisé ne fonctionnera pas. Il y a donc un problème au

niveau de la conception du système. L‟idée est d‟être capable de détecter

systématiquement ce phénomène par l‟analyse des propriétés du modèle RdP du

système à l‟aide d‟outil de simulation, de vérification et de validation de modèle

RDP, tel que PetriParc18 (Figure 6.14).

Figure 6.14 : Vérification des propriétés du modèle RdP avec PertiParc [LARE11b]

18 www.univ-valenciennes.fr/GDR-MACS/outils.php?id=15


146

Figure 6.15 : RdP correspondant au modèle OSSAD d’opération « Ajout d’un nouveau membre par invitation » [LARE11b]

4. Conclusion

De nombreuses études de cas ont été réalisées dans le cadre de travaux de

recherche, souvent dans le cadre de partenariats industriels. Ils se sont orientés

vers la conception et la réalisation de plateformes d‟instrumentation de solutions

d‟e-maintenance. Ces plateformes intégraient différents éléments physiques, comme

les capteurs actionneurs instrumentant les équipements à maintenir, les systèmes

Site


Envoyer les

données

Vérifier la disponibilité des experts

OU ACK(S,N)

Affecter un N°

d’ordre

ET

ORD(S,N)

Donné

es

Inviter un expert

libre à joindre le

groupe


147

distribués de surveillance ainsi que les supports de communication. Notre

démarche se distingue des précédentes, par le fait qu‟on s‟est focalisé sur

l‟élaboration d‟un modèle de comportements coopératifs au sein du processus

d‟e-maintenance, la création de ces modèles nous a confrontées à une autre

problématique, celle de la vérification des propriétés et la simulation du processus

modélisé. Cette dernière, nous a conduite, à élaborer une solution basée sur la

génération d‟un modèle RdP à partir du modèle OSSAD.

Conclusions et Perspectives

148

Conclusions et

perspectives


149

La Maintenance de manière générale et le diagnostic en particulier, sont des

processus nécessitants une grande coordination et une collaboration intense

compte tenu que les acteurs (experts, techniciens …) sont répartis aussi bien

géographiquement que temporellement. Il nous a semblé alors légitime de choisir

d‟implémenter un système Workflow afin d‟assister le travail coopératif d‟une équipe

de maintenance. Il faut cependant prendre en compte que le Workflow,

contrairement aux autres modèles et applications informatiques traditionnelles, ne

contribuent pas à l'automatisation du travail des ordinateurs, mais à

l'automatisation du travail humain accompli au travers de multiples interactions de

coopération et de coordination. Au-delà des traitements transactionnels propres

aux ordinateurs, le Workflow s'attache à assister l'homme dans ses interactions

avec d'autres hommes via les ordinateurs. Ainsi, si l'informatique de gestion

s'attache à automatiser les processus dans une perspective centrée sur les données

et les informations associées, l‟informatique de communication quant à elle (dont

fait partie le Workflow), s'intéresse plutôt aux interactions humaines et aux

comportements de communication sous-jacents. Les processus bénéficiant le plus

de ces technologies sont donc ceux basés sur la communication et la collaboration

en vue de l'accomplissement de l'objectif de ce processus, dans notre cas, la

maintenance coopérative, cette nuance nous a conduit à choisir un double langage

de modélisation OSSAD /RdP pour la spécification du Workflow, nous permettant

ainsi d‟avoir à la fois une facilité d‟utilisation grâce au premier et une précision de

formulation et une opportunité d‟analyse et de simulation pour le second.

Notre approche, orientée vers la coopération au sein d‟un processus de e-

maintenance, peut être étendu à d‟autres fonctions industrielles, surtout que ces

dernières années une nouvelle approche de la maintenance à vu le jour, consistant

à intégrer des métiers dans la phase de conception, et permettant ainsi de détecter

les erreurs très tôt dans le processus de développement d‟un produit. La qualité de

ce dernier est ainsi améliorée, les coûts supplémentaires dus aux modifications

sont éliminés et les délais de mise sur le marché sont réduits. Par conséquent,

l‟entreprise parvient à tenir ses engagements de satisfaction du besoin client et de

diminution de ses coûts globaux. C‟est dans ce contexte que la "conception

coopérative et intégrée" vient actuellement illustrer ce besoin de prise en compte du

cycle de vie du produit. Le besoin de rompre avec le processus séquentiel et faire

intervenir l'ensemble des différents métiers, amène les entreprises à concevoir le

travail en parallèle et à faire "concourir" plutôt les résultats de leur travail, donnant

naissance à une nouvelle forme d‟ingénierie dite simultané ou concourante.


150

L‟ingénierie simultanée (ou concourante) est une approche systématique pour

concevoir un produit qui prend en considération tous les éléments de son cycle de

vie, depuis la conception jusqu‟à la mise à disposition, et qui, par conséquent,

intègre la définition du produit, les processus de fabrication, et tous les autres

processus requis dans le cycle de vie tels que le fonctionnement (dans des

environnements mécaniques, thermiques, acoustiques, électromagnétiques...) ou la

maintenance. Cette approche doit permettre aux équipes multidisciplinaires (calcul,

fabrication...) et/ou multi métiers (structures, thermique, électromagnétisme,

acoustique...) de travailler en parallèle, le plutôt possible, vers un même but.

Plusieurs ébauches de définitions pour concurrent engineering, plus au moins

complémentaires, ont été proposées, nous en retenons deux : Une première

définition synthétique établie sur la base des autres définitions : "Le concurrent

engineering est une approche organisationnelle systématique et globale de

l‟entreprise, basée sur la conduite simultanée et intégrée du cycle de vie du produit,

mettant en œuvre des équipes pluridisciplinaires travaillant en symbiose et visant

des objectifs de production communs de coût-délai-qualité". De cette définition, il

en résulte les objectifs suivants :

- exécution parallèle des activités de développement,

- intégration et prise en compte des activités aval pendant le déroulement des

activités amont,

- constitution d‟équipes pluridisciplinaires qui regroupent différents acteurs

impliqués dans le projet de développement de produit,

- optimisation des processus de développement existants, essentiellement les

méthodes de conception et de gestion de la production et de la distribution.

Pour atteindre ces objectifs, Le CSCW (Computer-Supported Cooperative Work) ou

en français, le TCAO (travail coopératif assisté par ordinateur), peut être employé

pour définir un système (Modèle, application) informatique, qui faciliterait la

coopération d‟individus autour d‟une tâche commune, à travers différents outils tels

que les Workflow ou plus récemment, le BPM (Business Process Management).

L‟ordinateur y sera utilisé pour assister des tâches qui nécessitent de l‟assemblage

et de la coordination (la rédaction d‟un document), ainsi que la communication et la

coordination pour une prise de décision par un groupe (group decision support

system).

Bibliographie

151

Bibliographie

Bibliographie

152

[AALS96] Van der Aalst. “ Three Good reasons for Using a Petri-net-based Workflow

Management System.” In S. Navathe and T. Wakayama, editors, Proceedings of the

International Working Conference of Information and Process Integration in

Enterprises (IPIC‟96), pages 179–201, Camebridge, Massachusetts, Nov 1996.

[AALS97] Van der Aalst. “Verification of Workflow Nets”. In P. Azema and G. Balbo,

editors, volume1248 of Lecture Notes in Computer Science, page 407–426. Springer-

Verlag, Berlin, 1997.

[ANKE05] Anke J., Främling K., "Distributed Decision Support in a PLM scenario",

14th Symposium on Product Data Technology, Amsterdam, Netherlands, 2005.

[AXEL92] Axelrod R., Donnant-donnant. « Théorie du comportement coopératif »,

Editions Odile Jacob.

[BRES05] Bressy P., Zerhouni N., Allemand C., Leger J.-B., "Application du concept

de emaintenance à un système naval de défense : NEMOSYS", 2e Colloque

international francophone sur la Performance et les Nouvelles TechnOlogies en

Maintenance (PENTOM'05), Marrakech, Maroc, 2005.

[BROW99] Brown J., McCarragher B. J., "Maintenance resources allocation using

decentralised cooperative control", Proceedings of Information, Decision and Control

(IDC 99), ISBN 0-7803-5256-4, 1999.

[BANG03] T. Bangemann, E. Garcia, C. Lang, X. Rebeuf, J. Szymanski, J-P.

Thomesse and M. Thron. ―PROTEUS – a European initiative for e-maintenance

platform development‖. In IEEE International Conference on Emerging Technologies

and Factory Automation, Lisbon, Portugal, September 2003.

[BANG06] Thomas Bangemann, Xavier Rebeuf, Denis Reboul, Andreas Schulze,

Jacek Szymanski, Jean-Pierre Thomesse, Mario Thron, Noureddine

Zerhouni« PROTEUS : Creating distributed maintenance systems through anintegration

platform ». Compuer in Industry journal (57) Elsevier, 2006.

[BOUS01] M « la gestion da l‟information pour la télémaintenance et le

téldiagnostique coopératif ». Mémoire de DEA. LIFC 2001.

[BUSS03] Bussler, D. Fensel, N. Sadeh. Semantic ―Web Services and their role in

Enterprise Application Integration and E-Commerce‖. 2003.

[CHAP00] Chappellet, Jean-Loup André Le Grand « Modélisation, simulation et

génération d'applications de workflow pour l'internet » / Working paper de l‟IDHEAP

1/2000.

[CHAP04] J.L. Chappelet, J.J. Snella : « Un langage pour l‟organisation, l‟approche

OSSAD » Third Edition PPUR 2004.

[CARC04] E. Garcia, H. Guyennet, J.C. Lapayre, N. Zerhouni ―A new industrial

cooperative tele-maintenance platform‖. Computers & Industrial Engineering 46

(2004) 851–864. Elsevier.

Bibliographie

153

[COCH07] P. Cocheteux, A. Voisin, E. Levrat et B. Iung « Formalisation du pronostic à

base d’une approche processus ». 3ème Colloque International Francophone

Performance et Nouvelles Technologies en Maintenance, PENTOM 2007, Mons :

Belgium (2007)".

[COMP05] J Campos, O Prakash : ― Information and communication technologies in

condition monitoring and maintenance—a review‖. IFAC symposium INCOM06. 17–19

May, Saint Etienne, France, 2005.

[CERIS99] Cerisier, Environnements d‟apprentissages collectifs en réseaux, Poitiers,

Paris 8, Groupe de recherche sur l‟apprentissage et les médias en éducation.

[CHIM04] Chim M. Y., Anumba C. J., Carrillo P. M., "Internet-based collaborative

decision-making system for construction", Advances in Engineering Software, 35 (6),

p. 357-371, 2004.

[CISS99] Cissé, A., Ndiaye, S., Lenk-Pezet, « Travail en réseau et intelligence

économique », Solaris, n°5,

[DAME00] Dameron, S, Génération de la coopération dans l'organisation - Le cas

d'équipes projet, Thèse, Université Paris IX Dauphine.

[DIX93] Dix, Alan, Finlay, Janet, Abowd, Gregory et Beale, Russel. Livre, Human-

Computer Interaction, 1993, 570 pages, Prentice-Hall.

[ELLI91] Ellis, Clarence, Gibbs, Simon et Rein, Gail. Groupware: Some Issues and

Experiences. Journal, Communications of the ACM (CACM), 1991, volume 34, numéro

1, pages 38-58, ACM Press.

[ELLI94] Ellis, Clarence et Wainer, Jacques. A Conceptual Model of Groupware.

Actes de la conférence ACM Computer Supported Cooperative Work (CSCW’94), 1994,

pages 79-88, ACM Press.

[FENS02] D. Fensel and C. Bussler. The Web Service Modeling Framework WSMF. in

Electronic Commerce Research and Applications, Vol 1, Issue 2, pp.113-137, 2002.

[FU04] Fu Q. Y., Ping C. Y., Helander M. G., "Knowledge-based Collaborative

Decision Making System for Product Design", IEEE Conference on Cybernetics and

Intelligent Systems, Singapore, 2004.

[GRUD94] Grudin, Jonathan. CSCW: History and Focus. Jounal, IEEE Computer,

1994, volume 27, numéro 5, pages 19-26, IEEE.

[HAZE03] Hazebroucq V., "Rapport sur l‟état des lieux, en 2003, de la télémédecine

française", Rapport établi pour le Ministère de la recherche et des nouvelles

technologies, 2003.

[IUNG03] Iung B. ―From remote maintenance to MAS-based E-maintenance of an

industrial process‖. J Intell Manuf 2003;14(1):59–82.

[IVAN03] Ivanov A., Vernier C., Zerhouni N., "Ordonnancement des activités de

maintenance dans un contexte distribué", 4e Conférence Francophone de

Bibliographie

154

MOdélisation et SIMulation (MOSIM’03), Toulouse, France, ISBN 2-7430-0731-1,

2003.

[JARD06] A Jardine, D Lin, D Banjevic : ― A review on machinery diagnostics and

prognostics implementing condition-based maintenance‖. Mech Syst Signal Process

2006.

[JANK06] Jankovic M., "Prise des décisions collaboratives dans le processus de

conception de nouveaux produits. Application à l'automobile", Thèse de doctorat,

École Centrale Paris, 2006.

[JOHA88] Johansen R., Groupware, Computer support for business teams, New York,

the free press (Macmillan Inc), 1988

[JOUG99] Jouglet D, Coopération homme-machine pour le diagnostic technique,

application aux dérangements téléphoniques, Thèse de Doctorat de l‟Université de

Valenciennes, Janvier 1999.

[KAFF01] Kaffel H., "La maintenance distribuée : concept, évaluation et mise en

oeuvre", Thèse de doctorat, Université de Laval, Québec, 2001.

[KRON05] Kronsteiner R., Ibrahim I. K., "Collaborative Decision Support in Mobile

Environments: A Requirement Analysis", 2nd International Conference on Embedded

Software and Systems (ICESS’05), 2005.

[KOLS93] Kolski C, Millot P., "Problems in telemaintenance and decision aid criteria

for telemaintenance system design", International Journal of Industrial Ergonomics,

11 (2), p. 99-106, 1993.

[KARA01] Karacapilidis N., Papadias D., "Computer supported argumentation and

collaborative decision making: the HERMES system", Information Systems, 26 (4), p.

259-277, 2001.

[KARS94] Karsenty, Alain. Le collecticiel : de l‟interaction homme-machine à la

communication homme-machine-homme. Journal, Technique et Science

Informatiques (TSI), 1994, volume 13, numéro 1, pages 105-127, Hermès.

[KVAN00] Kvan T., "Collaborative design: What is it?", Automation in construction, 9

(4), p. 409-415, 2000.

[LABR06] Laborie F., "Le concept de salle de décision collective et son application

aux processuscomplexes EADS", Thèse de doctorat, Université Paul Sabatier de

Toulouse, 2006.

[LARI03] Lario Esteban F., Ortiz Bas A., Poler Escoto R., Perez Perales D., "Supply

chain management modelling collaborative decision", IEEE Conference on Emerging

Technologies and Factory Automation (ETFA '03), 2, p. 137-141, 2003.

[LARD05] Laredj M. Adnane : « Arbitrage de points de vues au sein d‟un processus

de conception coopérative » Mémoire de Magister. Université d‟Oran - 2005

[LARE11] Laredj M.A Djelloudi S, Grain N,: « implémentation d’un outil de

modélisation workflow ». PFE Master ingénierie des systèmes d‟information. 2011.

Bibliographie

155

[LARE11b] Laredj M.A, Bouamrane K, “Workflow Specification for interaction

management between experts in a cooperative remote diagnosis process”. Computer

Science and Information Systems (ComSIS) journal,Vol. 8, No. 3, p 573, June 2011

[LEBO01] Lebold M., Thurston M., Open Standards for Condition-Based

Maintenance and prognostic systems, 5th Annual Maintenance and Reliability

Conference (MARCON 2001), Gatlinburg, USA.

[LEGE01]Léger J.-B., Morel G. ―Intégration of maintenance in the enterprise : towards

an enterprise modelling-based framework compliant with proactive maintenance

strategy‖. Production Planning & Control, Volume 12, n°2, pp 176-187, 2001.

[LEVR05] E. Levrat, B. Salzemann, F. Clanché « TELMA Plate-forme d’intégration de

télémaintenance pour l’enseignement et la recherche » CETSIS'2005, Nancy, 25-27

octobre 2005

[LEVR06] E. Levrat, B. Iung, « TELMA: full e-maintenance platform », Vandoeuvre,

France, 2006.

[LIMA01] Limayem F., "Modèles de pondération par les méthodes de tri croisé pour

l‟aide à la décision collaborative en projet", Thèse de doctorat, École Centrale Paris,

2001.

[LYON92]Lyonnais P., Maintenance mathématique et méthode, Troisième édition,

technique et édition Lavoisier, France, 1992.

[MALO94] Malone T. W., Crowston K. The interdisciplinary study of coordination.

ACM Computing Surveys, mars 1994.

[MILL95] Millot P. La coopération homme-machine dans la supervision, les enjeux,

les méthodologies, les problèmes, Séminaire supervision et coopération

Homme/Machine, Paris 1995.

[MINT79] Mintzberg H., The structuring of Organization, Prentice Hall, Inc., 1979,

(traduction française : Structure et dynamique des organisations, Ed d‟Organisation,

Paris 1982).

[MINT93] Henry Mintzberg, Structure et dynamique des organisations. Les éditions

d'organisation

[MOUC91]Monchy, F, La fonction maintenance : Formation à la gestion de la

maintenance industrielle, Collection technologies de l‟université à l‟industrie,

MASSON, 1991.

[MULL05] Muller A., Contribution à la maintenance prévisionnelle des systèmes de

production par la formalisation d‟un processus de pronostic. Thèse de doctorat,

Université Henri Poincaré, Nancy, juin, 2005.

[MULL07] Muller A, Suhner M-C, Iung B. Maintenance alternative integration to

prognosis process engineering. J Qual Maint Eng [special issue on „„Advanced

Bibliographie

156

Monitoring of Systems Degradations and Intelligent Maintenance Management‟‟]

2007.

[MULL07b] Muller A, et al : On the concept of e-maintenance: Review and current

research. Reliab Eng Syst Safety (2007).

[NURC96] Nurcan, Selmin « Analyse et conception de systèmes d'information

coopératifs - Université Paris 1 – Sorbonne – 1996.

[PANZ02] Panzarasa P., Jennings N. R., Norman T. J., "Formalising collaborative

decision-making and practical reasoning in multi-agent systems", Journal of Logic

and Computation, 12 (1), p. 55-117, 2002.

[PARS07] Parsa S., Parand F.-A., "Cooperative decision making in a knowledge grid

environment", Future Generation Computer Systems, 23 (8), p. 932-938, 2007.

[PELL97] Pellegrin C., Fondements de la décision en maintenance, Ed. Économica,

ISBN 2-7178-3489-3, 1997.

[PERE04] Pérès F., Noyes D., Reyterou C., "Methodology of integration of Information

and Communication Technologies in a maintenance process: application to the

aeronautic field", Intelligent Maintenance Systems, 2004.

[REBE03] X. Rebeuf, N. Blanc, F. Charpillet, D. Cheve, A. Dutech, C. Lang, L.

Pélissier, J.P. Thomesse : « Proteus, des web services pour les systèmes de

maintenance » . 2003.

[RYAN02] Ryan A. J., "Optimizing Group Utility in the Collaborative Decision

Making Process", Aircraft Technology, Integration and Operations (ATIO) Conference –

AIAA (American Institute of Aeronautics and Astronautics), Los Angeles, USA, 2002.

[RASO04]. Rasovska I., Chebel-Morello, B. et Zerhouni N., A conceptual model of

maintenance process in unified modelling language. Proc. of the 11th Symposium on

Information Control Problems in Manufacturing, INCOM‟2004, Salvador-Bahia,

Brésil, 2004.

[RASO05] Rasovska I., Chebel-Morello B. et Zerhouni N., Process of smaintenance:

decision support system for maintenance intervention. Proc. of 10th IEEE.

International Conference on Emerging Technologies and Factory Automation

ETFA‟05, Italie, 2005.

[RASO06] Ivana Rasovska « Contribution à une méthodologie de capitalisation des

connaissances basée sur le raisonnement à partir de cas : Application au diagnostic

dans une plateforme d‟e-maintenance » Thèse de doctorat, L‟UFR des Sciences et

Techniques de l‟Université de Franche-Comté, 2006.

[SALB95] Salber, Daniel. De l'interaction individuelle aux systèmes multi-

utilisateurs. L'exemple de la Communication Homme-Homme-Médiatisée. Thèse de

Bibliographie

157

doctorat Informatique, Université Joseph Fourier, Grenoble, France, Septembre 1995,

303 pages.

[SCHM91] Schmidt K., Cooperative work: a conceptual framework, Distributed

Decision Making, Cognitive models for cooperative work, Editeurs : J. Rasmussen, B.

Brehmer, J. Leplat, pp. 75-110, New York, Chichester: Wiley, 1991.

[SEGU08] Anne SEGUY : »Décision collaborative dans les systèmes industrieles :

application à la E-maintenance » . 2008.

[SMIT95]. Smith, Caroll, Ashford, (1995), Intra- and interorganizational cooperation :

toward a research agenda, Academy of Management Journal, Vol.38, N°1, pp. 7-23.

[SOUB05] Soubie J.-L., Zaraté P., "Distributed Decision Making: A Proposal of

Support Through Cooperative Systems", Group Decision and Negotiation, 14 (2), p.

147-158, 2005.

[SPAD04], Spadoni M., Système d‟information centré sur le modèle CIMOSA dans un

contexte d‟entreprise étendue, JESA, Volume 38, n° 5, pp. 497-525, 2004.

[STVR02] Saint Voirin D., "Modélisation des approches de coopération en

télémaintenance : étude et contribution", Mémoire de DEA, LAB-LIFC, Besançon,

2002.

[STVR06] Saint Voirin D., "Contribution à la modélisation et à l'analyse des

systèmes coopératifs : application à la e-maintenance", Thèse de doctorat, Université

de Franche-Comté, 2006.

[VASS10] Francis VASSE, « Le marché de la GMAO, Portail Réseau maintenance »,

Association française des ingénieurs et responsables de maintenance, 2010

[WANB01] Wambsganss M., "Collaborative Decision Making in Air Traffic

Management", publié dans l’ouvrage "New concepts and methods in air traffic

management‖, de L. Bianco, P. Dell‟Olmo, A. R. Odoni, Ed. Springer, ISBN 3-5404-

1637-4, 2001.

[WfMC10] Workflow Management Coalition. www.wfmc.org

[XIAO05] Xiao A., Zeng S., Allen J. K., Rosen D. W., Mistree F., "Collaborative

multidisciplinary decision making using game theory and design capability indices",

Research in Engineering Design, 16 (1-2), p. 57-72, 2005.

[ZACK93]. Zacklad M., Groupe COOP, Rousseaux F., Projet GEOCOOP, Conception

d’une méthode d’acquisition des connaissances contextuelles et de modèles de

coopération : Application au développement d’un système géographique d’aide à

l’estimation du risque et à la gestion de crises, Rapport de Recherche de l‟INRIA

N°2052, Octobre 1993.

http://www.wfmc.org/

Annexes

158

Annexe A Le niveau abstrait du

langage OSSAD

Annexes

159

1. Le modèle abstrait d’OSSAD

Il décrit les objectifs, buts ou missions d'une organisation, sans tenir compte

des moyens humains et techniques nécessaires à leur réalisation. Ces modèles

abstraits sont généralement invariants d'une reconception des moyens mis en

oeuvre ("business process redesign"), mais pas d'une refonte profonde des activités

de l'organisation ("business process reengineering"). Il répond aux questions : «

Quels objectifs satisfaire ? » et « Que faut-il faire pour celà ? », en faisant abstraction

de la solution pratique employée. Il fixe les caractéristiques stables et durables du

système étudié que tout choix d'organisation devra respecter. Il sert de cadre à la

construction des modèles descriptifs.Les éléments déterminés lors de l'élaboration

de ce modèle sont les suivants :

Elément Définition

Fonctions Une fonction est un sous-ensemble de l'organisme

fournissant un certain résultat, ou ensemble d'actions

ayant un même objectif, indépendamment des moyens

concrets utilisés pour les effectuer.

Sous-fonctions/

Activités

Correspondent aux niveaux successifs d'analyse de plus

en plus détaillée des fonctions

Paquets Représentent l'échange d'informations entre les fonctions,

sous-fonctions ou entre l'organisme et les entités externes.

Entités externes

Modélisent tous les acteurs ayant des relations avec

l'organisme a travers l'échange de paquets.

Tableau 1 : éléments constituants le modèle abstrait d’OSSAD

Les fonctions sont des sous-ensembles de l‟organisation poursuivant des objectifs

homogènes. Elles échangent des ensembles d‟informations, appelés paquets Les

fonctions peuvent être décomposées en sous-fonctions. Les fonctions non

décomposées sont appelées activités. Elles constituent par définition le plus fin

niveau de détail de la modélisation abstraite.

Figure 1 : méta-modèle du modèle abstrait

Paquet Fonction /

activitée

<émet

<reçoit

0..*

0..* 0..*

0..* 0..*

0..1

Annexes

160

Le modèle abstrait vise donc, à représenter conceptuellement les objectifs, les

contraintes, les différentes fonctions de l'organisme et les interrelations entre elles.

On cherche donc à représenter ce qui doit être fait et pour quoi. Ce modèle

résume donc les caractéristiques stables et durables du système étudié. Le modèle

abstrait peut être qualifié de normatif car il indique ce qui doit être fait pour

atteindre les objectifs de l'organisme. Il résume la raison d'être, l'essentiel de ce qui

se passe, quelle que soit ensuite la façon dont on y parviendra.

Figure 2 : Exemple de modèle abstrait

2. La matrice Activité/Rôle

Le passage entre le niveau abstrait et le niveau descriptif est assuré par la

matrice Activité/Rôle. Les lignes correspondent à des activités (concept abstrait) et

les colonnes à des rôles (concept descriptif). On indique pour chaque activité d'une

fonction tous les rôles qui y interviennent en réalisant une tâche (une croix dans la

matrice correspond à une tâche).

Client

X X X

XXXX

* Agentservice prêts

Chefservice prêts

Agentcomptescourants

Gestion d'une demande de prêt

Réalisation d'un prêt

Figure 3 : Exemple de matrice Activité / Rôle

Manageme

nt

comptabilit

é

marketing

Vente

Rapport de vente

Rapport de frais engagés

Compte rendus

paquet

Fonctio

n

documentation

Annexes

161

Annexe B Comparaison d’OSSAD

avec UML et BPMN

Annexes

162

1. Comparaison OSSAD - UML

Les modèles d‟OSSAD et d‟UML couvrent des champs d‟applications qui ne

sont pas toujours similaires. Ces deux techniques reposent toutefois sur l‟idée de

représenter la réalité avec des points de vue et des niveaux différents, intégrant

pour cela des modèles présentés en cascade et des possibilités de zoom. Afin de

pouvoir les comparer, [GLAS02] propose un découpage en trois niveaux de

modélisation qu‟il résume en trois interrogations :

- Quoi ? Quels sont les objectifs de l‟organisation ?

- Qui et avec quoi ? Quelle est la structure de l‟organisation et quelles sont les

ressources disponibles ?

- Comment ? Quel est le fonctionnement procédural de l‟organisation ?

La table suivante montre cette répartition, à savoir quels modèles répondent

à quelle question. Nous expliquerons cette répartition et nous étudierons chaque

niveau dans le détail aux points suivants.

OSSAD

UML

Quoi ?

Modèle abstrait Cas d‟utilisation

Qui et quoi

?

- Modèle d‟unités

organisationnelles

- Modèle de rôles

- Modèle de procédures

- Diagramme de

séquence

- Diagramme de

collaboration

Comment

?

Modèle d‟opérations

Diagramme

d‟activités

Tableau 1 : comparaison UML / OSSAD

Annexes

163

1.1. Fonctionnement de l’organisation

La description des flux de contrôle et des flux d‟information est selon nous

clairement identique dans OSSAD et UML. En effet, elle repose sur des concepts

communs, même si la notation est parfois différente :

- Des activités ou des opérations élémentaires qui doivent être effectuées et qui sont

ordonnées de manière chronologique

- Des swimlanes qui permettent de montrer quels acteurs ou quels rôles sont

responsables de ces activités ou opérations

- Des conditions et des opérations parallèles permettant de contrôler le déroulement

ou la séquence de ces activités ou opérations

- Des ressources en information et des outils qui sont liés aux activités ou

opérations. Ces techniques présentent toutefois quelques différences, relativement

minimes à notre avis.

- OSSAD ne traite que des rôles alors qu‟UML ne marque pas la différence entre rôle

et acteur.

- UML permet de modéliser n‟importe quel type de ressources grâce au concept de

stéréotype et de classes d‟objets. OSSAD de son côté propose trois notations

distinctes, les ressources en information, les outils et les documents. Cette

correspondance directe entre les modèles opérationnels proposés par les deux

techniques n‟a rien de surprenant, dans la mesure où la représentation d‟une

séquence d‟opérations ou d‟activités est d‟un faible niveau d‟abstraction et doit

coller à la réalité. Ces modèles sont directement inspirés des ordinogrammes et

autres flowcharts communs à beaucoup de méthodes.

1.2. Structure et ressources de l’organisation

C‟est à ce niveau de représentation qu‟ OSSAD et UML présentent les plus

grandes différences. Ces dernières proviennent de la conception initiale de ces

techniques et des champs d‟application pour lesquels elles ont été prévues :

- UML est une méthode de conception de systèmes informatiques et elle ne

s‟intéresse de ce fait pas à la hiérarchie ou à la structure d‟une organisation. Elle

n‟intègre donc pas directement de possibilités de modéliser de manière clairement

Annexes

164

différenciée les acteurs physiques et les rôles qu‟ils ont à tenir au sein d‟une

organisation.

- OSSAD sont des méthodes directement conçues pour la modélisation de

processus et elles permettent de modéliser la structure d‟une organisation. Nous

pensons toutefois qu‟il est possible de mettre en correspondance des modèles

provenant de ces deux techniques :

- OSSAD et UML présentent une certaine similitude entre leur modèle de rôles et de

collaboration. En effet, le premier montre la circulation de ressources d‟information

entre des rôles et le second les échanges de messages entre des acteurs. A noter

toutefois qu‟UML permet d‟ajouter facultativement une numérotation correspondant

à la chronologie des messages, alors que le modèle de rôles d‟OSSAD ne contient

pas d‟information temporelle.

- Au sujet de la correspondance le niveau abstrait et le niveau descriptif. Là encore,

OSSAD et UML ont des modèles qui présentent une certaine similitude. En effet, le

modèle de procédures d‟OSSAD est lié au modèle abstrait car chaque procédure

représente une activité du modèle abstrait, alors que dans UML un diagramme de

séquence repose sur le scénario défini pour le cas d‟utilisation correspondant. Il est

intéressant de constater que cette double symétrie existe également au niveau de la

conception des méthodes OSSAD et UML : les modèles de rôles et de procédures

OSSAD sont liés car ils sont tous deux. définis comme des modèles de circulation

de l‟information, alors que les modèles de collaboration et de séquence UML sont

symétriques et portent le nom général de diagrammes d‟interaction. Par ailleurs, la

différence soulevée au point précédent est valable ici également, le diagramme de

séquence UML contient une chronologie alors que le modèle de procédures n‟en a

pas.

1.3. Objectifs de l’organisation

Les modèles abstraits d‟OSSAD et les cas d‟utilisation ont un but commun,

celui de modéliser les objectifs d‟une organisation. Ils sont cependant conçus de

manière différente et ne présentent pas la même information :

Annexes

165

- OSSAD reprend l‟idée de processus, mais y ajoute le concept de paquet

d‟information et montre la circulation de paquets entre processus. Cette méthode

intègre de plus l‟idée de processus externe afin de représenter la circulation de

l‟information non seulement à l‟intérieur d‟une organisation, mais aussi entre cette

dernière et son environnement.

- Les cas d‟utilisation d‟UML peuvent être mis directement en correspondance avec

les processus d‟OSSAD. Le concept d‟acteurs dans UML est relativement similaire à

celui de processus ou d‟entité externe dans OSSAD. Jusque là, nous pouvons dire

qu‟OSSAD et UML sont proches, mais la grande différence se situe au niveau des

relations qui unissent ces processus ou cas d‟utilisation. Là où OSSAD s‟intéresse

en premier lieu à circulation de l‟information entre processus, UML spécifie de

simples associations entre acteurs et cas d‟utilisation et ne donne aucune précision

sur le type d‟informations qui circule entre eux.

1.4. Concepts de modélisation

Comme nous l‟avons mentionné au long de cette section, OSSAD et UML

intègrent un certain nombre de concepts communs, même s‟ils portent parfois des

noms différents. Pour faciliter la mise en correspondance de ces concepts, nous les

avons regroupé dans la table.

OSSAD

UML

Quoi ? Processus Cas d‟utilisation

Entité externe Acteur

Annotation Note

Processus zoomé Environnement

Qui et quoi ? Unité organisationnelle ---

Acteur Acteur

Rôle Acteur

ressource Objet

Comment ? opération Activité

Poste condition Ramification

Opération parallèle Points de divergence et

Annexes

166

de convergence

Rôle Swimlane

Ressource / outil Objet

Tableau 2: correspondances entre les concepts de modélisation d’OSSAD et

UML

Nous avons vu qu‟au niveau opérationnel, les concepts étaient très similaires

dans OSSAD et UML. Nous pouvons donc dire qu‟à ce niveau, les deux techniques

peuvent être utilisées indifféremment pour modéliser un processus et que le

passage d‟une technique à l‟autre peut se faire facilement. Au niveau abstrait, nous

relevons que le concept de processus est présent partout, mais qu‟une des

techniques l‟utilise en ajoutant des paquets d‟information (OSSAD) et que l‟autre y

intègre des acteurs (UML). Après notre comparaison, nous pensons le niveau

abstrait, nous pouvons dire qu‟OSSAD est la méthode la plus détaillée, car le

concept d‟entité externe permet de reprendre les acteurs définis dans UML et qu‟elle

est la seule à s‟intéresser à la circulation de l‟information.

En ce qui concerne la description structurelle d‟une organisation, nous avons

constaté une différence importante entre OSSAD, méthode de modélisation de

processus à proprement parler, et UML qui est plutôt destiné à modéliser des

systèmes d‟information. Ainsi le choix d‟une méthode dépendra du champ

d‟application du travail de modélisation de processus, afin de pouvoir utiliser au

mieux les fonctionnalités respectives de ces deux techniques de modélisation. Nous

jugeons toutefois qu‟OSSAD est la méthode qui assure le mieux la liaison entre les

modèles structurels et le niveau abstrait grâce à la matrice activités-rôles. Donc

sans déterminer quelle est la meilleure technique de modélisation ou quelle est la

moins bonne. Nous terminons par quelques lignes d‟appréciation sur chacune

d‟entre elles :

- OSSAD permet de couvrir tous les aspects de la modélisation de processus et ses

différents niveaux de modèles sont fort bien articulés entre eux. Des extensions,

implémentées dans le logiciel tel que Workey, permettent de générer

automatiquement des applications de workflow.

- UML est une technique plus générique, avec les avantages et les inconvénients

que cela implique : elle ne «force» pas l‟utilisation de certains concepts qui peuvent

Annexes

167

s‟avérer très importants dans la modélisation de processus, entraînant ainsi une

perte d‟information ou la création de modèles incomplets, mais elle est par contre

flexible et extensible, ce qui permet à ses utilisateurs de l‟adapter précisément à

leurs besoins. UML permet également la génération automatique de code applicatif.

OSSAD

UML

Présentation

Position de l‟analyse (façon dont les auteurs de la méthode "attaquent" le système)

Totale (analyse de l'ensemble du fonctionnement Système)

X

Partielle (analyse du système centrée sur les points critiques)

X

Principe d‟assemblage Type/ Occurrence ------------------------ Niveaux d‟abstraction

X

X X

Généralisation/ Spécification ------------------------ Stratégique/ Tactique

X X

Structure

Nature de l‟environnement

Structuré X X

Semi-structuré X X

Non-structuré

Stable X X

Instable X

Certain X X

Incertain

Typologie des données

Qualité X X

Quantité X

Pertinence X

Méthodologie

Cycle de développement

Cascade ------------------------ Spirale

X

V X

Etapes concernées Analyse X X

Modélisation X X

Spécification X X

Conception X

Approche Descendante ------------------------ Ascendante

X

Evolutive X

Degré d‟implication de l‟utilisateur

Pas

Peu

Beaucoup X

Essentiel X

Annexes

168

Moment d‟implication de l‟utilisateur

Début X X

Milieu X X

Fin X X

Technologie

Mode de traitement

Interactif X

Client-serveur X

Synchrone X

Asynchrone

Distribué X

Type d‟Interface Homme Machine

Classique X X

Adaptable X

Programmation Structurée X X

Base de données X

Objet Multi-agents

X X

Quoi ? (Quels

sont les objectifs de l‟organisation ?)

Modèle abstrait Cas d‟utilisation

Processus Cas d‟utilisation

Entité externe Acteur

Annotation Note

Processus zoomé

Environnement

Qui et quoi ?

(Quelle est la structure de l‟organisation et quelles sont les ressources disponibles ?)

- Modèle d‟unités organisationnelles - Modèle de rôles - Modèle de procédures

- Diagramme de séquence - Diagramme de Collaboration

Unité Organisationnelle

-

Acteur Acteur

Rôle Acteur

Ressource Objet

Comment ? (Quel est le fonctionnement procédural de l‟organisation ?)

Modèle d‟opérations

Diagramme d‟activités

Opération Activité

Post-condition Ramification

Opération parallèle

Points de divergence et de convergence

Rôle Swimlane (permettent de montrer quels acteurs ou quels rôles sont

Annexes

169

responsables des activités ou opérations)

Ressource /

Outil

Objet

Tableau 3. Tableau comparatif entre OSSAD et UML

2. Comparaison OSSAD ET BPMN

‟OSSAD et BPMN couvrent des champs d‟application qui ne sont pas toujours

similaires. Ces deux techniques reposent toutefois sur l‟idée de représenter la

réalité avec des points de vue et des niveaux différents, intégrant pour cela des

modèles présentés en cascade et des possibilités de zoom. Afin de pouvoir les

comparer, un découpage en trois niveaux de modélisation résumé en trois

interrogations peut être avancé:

Quoi ? Quels sont les objectifs de l‟organisation ?

Qui et avec quoi ? Quelle est la structure de l‟organisation et quelles sont

les ressources disponibles ?

Comment ? Quel est le fonctionnement procédural de l‟organisation ?

La table ci dessous montre la répartition retenue, à savoir les critères qui

différencient ces deux méthodes et quels modèles répondent à quelle question.

L‟explication de cette répartition et l‟étude de chaque niveau seront développés dans

le détail aux points suivants :

OSSAD BPMN

Logos

Acronyme Office Support System Analysis

and Design

Business Process Modeling

Notation

Naissance

des

projets

OSSAD issue du projet de

recherche ESPRIT élaborer de 1985 à 1989.

BPMN est conçu par

l'OMG/BPMI depuis leur fusion en 2005.

Définition OSSAD une méthode

normative, d'analyse, de

conception et de mise en œuvre des systèmes d'information.

BPMN est une norme de

notation pour la

modélisation de processus métier.

Objectif permettre une introduction fournir un cadre permettant

Annexes

170

principal plus efficace des nouvelles

technologies dans les activités

administrative et mise en

œuvre de nouveaux systèmes d‟organisation et de procédures

qui permettent de répondre aux

finalités de l‟entreprise

de décrire un processus

d'une manière commune à

tous les utilisateurs et ce,

indépendamment de l'outil utilisé. L'outil étant bien

sûr censé supporter la

norme.

Les

modèles

représenta

tifs

Modèle Abstrait (MA)

Modèle Descriptif (MD)

Modèle Prescriptif (MP)

Diagramme BPMN (BPD19)

Quoi ? Modèle abstrait Les Activités de BPD

Qui et

quoi ?

- Modèle d‟unités organisationnelles

- Modèle de rôles

- Modèle de procédures

- Swimlanes de BPD

- Artéfacts de BPD

Comment

?

Modèle d‟opérations Objets de relation de BPD

Tableau 4 : Comparaison entre OSSAD et BPMN

2.1. Fonctionnement de l’organisation

BPMN permet de différencier rôles et acteurs directement dans le modèle,

alors qu‟OSSAD ne traite que des rôles.

OSSAD offre trois notations distinctes de ressources : ressource en

informatique, les outils et les documents, par contre BPMN ne permet pas la

représentation des ressources.

2.2. Structure et ressources de l’organisation

BPMN et OSSAD sont deux méthodes directement conçues pour la modélisation

de processus et elles permettent de modéliser la structure d‟une organisation. Nous

pensons toute fois qu‟il est possible de mettre en correspondance des modèles

provenant de ces deux techniques :

19 Business Process Diagram

Annexes

171

- BPMN et OSSAD permettent d‟attribuer formellement des rôles à des acteurs

physiques.

- OSSAD et BPM N présentent une certaine similitude entre leur modèle de

rôles et le BPD (Swimlanes). En effet, le premier montre la circulation de

ressources d‟information entre des rôles et le second les échanges de

messages entre des acteurs.

- BPMN permet d‟ajouter facultativement la notion chronologique des

messages alors que le modèle de rôle d‟OSSAD ne contient pas d‟information

temporelle.

2.3. Objectifs de l’organisation

Le BPD de BPMN et les modèles abstraits d‟OSSAD ont un but commun,

celui de modéliser les objectifs d‟une organisation. Ils sont cependant conçus de

manière différente et ne présentent pas la même information :

Les Activités de BPD représenté par BPMN montrent uniquement des processus de

manière très générale et ne contiennent guère d‟informations.

OSSAD reprend l‟idée de processus, mais y ajoute le concept de paquet

d‟information et montre la circulation de paquets entre processus. Cette méthode

intègre de plus l‟idée de processus externe afin de représenter la circulation de

l‟information non seulement à l‟intérieur d‟une organisation, mais aussi entre cette

dernière et son environnement.

2.4. Concepts de modélisation

OSSAD et BPMN intègre un certain nombre de concepts communs, même

s‟ils portent parfois des noms différents. Pour faciliter la mise en correspondance

des ces concepts, nous les avons regroupé dans la table ci-dessous :

OSSAD BPMN

Quoi ?

Processus Activités

Entité externe - - - - - -

Annotation Annotation

Processus zoomé Sous processus (processus

zoomé)

Annexes

172

Qui et quoi ?

Unité

Organisationnelle

Groupement

Acteur Acteur

Rôle Swimlane

Ressource Objet

Comment ?

Post-condition Gateway

Opération parallèle Gateway parallèle

Rôle Swimlane

Ressource / Outil Objet

Opération Activité

Tableau 5 : Correspondance approximatif des principaux concepts

2.5. La dimension coopération

Elle est associée à quatre critères :

- La communication indique la prise en compte des moyens de

communication ou du type de communication (directe (envoi de message),

indirecte (tableau noir), synchrone (par téléphone par exemple), asynchrone

(par exemple : la messagerie)), la possibilité de représenter la négociation (qui

devient la forme de communication de plus en plus courante, les entreprises

se tournant de plus en plus vers un management par projets) et l'utilisation

d'un modèle permettant de formaliser les communications (celui-ci étant le

plus souvent basé sur des théories de la linguistique).

- La coordination indique la considération de la coordination des acteurs

(plus généralement, la capacité à représenter la synchronisation ente les

acteurs).

- Les relations indiquent la prise en compte du type de relation entre les

acteurs (de hiérarchie, de responsabilité).

- L’individualité indique si la méthode permet de représenter des

caractéristiques propres aux acteurs du groupe comme l'autonomie et les

problèmes de confiance que pose le travail coopératif, c'est à- dire si les

acteurs peuvent être définis plus précisément que par leur appartenance à

un groupe.

Annexes

173

OSSAD BPMN

Communication

De données X X

Modes de

communication

Modèle du langage

Négociation

Relations

Hiérarchie X X

Responsabilité

Coordination

Individualité

Confiance

Autonomie X X

Tableau 6 : Prise en compte de la coopération dans les méthodes

On remarque que les deux méthodes OSSAD et BPMN en les mêmes propriétés

dans la dimension de coopération.

2.6. Conclusion

Au niveau opérationnel, les concepts étaient très similaires dans BPMN et

OSSAD. Nous pouvons donc dire qu‟à ce niveau, les deux techniques peuvent être

utilisées indifféremment pour modéliser un processus et que le passage d‟une

technique à l‟autre peut se faire facilement. Au niveau abstrait, nous relevons que

le concept de processus est présent partout, mais qu‟une des techniques l‟utilise tel

quel (BPMN) et que l‟autre lui ajoute des paquets d‟information (OSSAD). Après

notre comparaison, nous pensons que le niveau abstrait de BPMN est trop général

pour être réellement utile, alors qu‟OSSAD est plus riche au niveau de la

représentation. Nous pouvons même dire qu‟OSSAD est la méthode la plus

détaillée. Nous estimons qu‟OSSAD est la méthode qui assure le mieux la liaison

entre les modèles structurels et le niveau abstrait grâce à la matrice activités-rôles.

Annexes

174

Annexe C Etude de cas :

Le complexe gazier

GP1Z-SONATRACH

Annexes

175

Introduction

Afin de mener à bien nos travaux de modélisation d‟un workflow, nous nous

somme immergé dans le complexe GP1Z de l‟entreprise SONATRACH(Jumbo GPL)

situé dans la zone industrielle d‟ARZEW, et considéré comme l‟un des plus

important au monde. Ce terminal gazier a pour principal objectif depuis sa

construction par société japonaise I.H.I, C.I.T.O.H en 1984, de traiter le mélange

brut GPL venant de plusieurs gisements du sud algérien, pour la production de

propane et butane commerciaux, avec une capacité de production de 10.8 millions

de tonnes, destinée à la fois au marché national et international.

L‟usine répartie sur 120 hectares, comprend les principales zones de

production suivantes :

Zone utilité : fourni les énergies nécessaires pour le fonctionnement de

l‟usine tel que l‟électricité, vapeur d‟eau, l‟air comprimé, l‟eau distillée, Azote,

Méthanol, Gaz Naturel, carburant diesel et 04 générateurs de secours pour la

production d‟électricité en cas de coupure électrique de SONELGAZ.

Figure 1 : Le complexe GP1Z-SONATRACH

Annexes

176

Zone process : Elle comprend neuf (09) trains de production, chaque train

comprend les sections suivantes : section de déshydratation, section de

séparation, section de réfrigération et la section de l‟huile chaude.

Figure 2 : Trains de production 1,2,3

Zone de stockage et expédition :

1. Moyen de stockage : 22 réservoirs sphériques d‟une capacité de

1100 m3 pour le stockage de la charge, 8 bacs de 70000 m3 de

capacité unitaire pour le stockage des produits finis à basse

température, 04 réservoirs sphériques de 500 m3 de capacité unitaire

pour le stockage des produits finis à température ambiante pour

propane et butane et 01 réservoir sphérique de 500 m3 de capacité

pour le stockage du pentane et une section de liquéfaction de gaz

BOG.

Annexes

177

Figure 3 : Bacs de stockage

2. Moyen d’expédition : 02 jetées pour le chargement des navires dont

les capacités sont respectivement 400 m3/heure et 10000 m3/heure,

une rampe pour le chargement des camions

Figure 4 : Zone d’expédition pour la consommation nationale

spécification d’un workflow pour la gestion des...

Documents