View
221
Download
0
Category
Preview:
Citation preview
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
Chapitre 1 : Les concepts de la 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
Chapitre 1 : Les concepts de la maintenance
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]
Chapitre 1 : Les concepts de la maintenance
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
Chapitre 1 : Les concepts de la maintenance
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
Chapitre 1 : Les concepts de la maintenance
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.
Chapitre 1 : Les concepts de la maintenance
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
Chapitre 1 : Les concepts de la maintenance
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é
Chapitre 1 : Les concepts de la maintenance
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]
Chapitre 1 : Les concepts de la maintenance
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.
Chapitre 1 : Les concepts de la maintenance
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 :
Chapitre 1 : Les concepts de la maintenance
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
Chapitre 1 : Les concepts de la 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;
Chapitre 1 : Les concepts de la maintenance
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é).
Chapitre 1 : Les concepts de la maintenance
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.
Chapitre 1 : Les concepts de la 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
Chapitre 1 : Les concepts de la maintenance
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
Chapitre 1 : Les concepts de la maintenance
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
Chapitre 1 : Les concepts de la maintenance
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
Chapitre 1 : Les concepts de la 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],
Chapitre 1 : Les concepts de la maintenance
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
Chapitre 1 : Les concepts de la maintenance
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.
Chapitre 1 : Les concepts de la maintenance
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
Chapitre 1 : Les concepts de la maintenance
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.
Chapitre 1 : Les concepts de la maintenance
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
Chapitre 1 : Les concepts de la maintenance
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
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.
Chapitre 2: Coopération et collaboration
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
Chapitre 2: Coopération et collaboration
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.
Chapitre 2: Coopération et collaboration
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
Chapitre 2: Coopération et collaboration
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,
Chapitre 2: Coopération et collaboration
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.
Chapitre 2: Coopération et collaboration
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 :
Chapitre 2: Coopération et collaboration
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.
Chapitre 2: Coopération et collaboration
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
Chapitre 2: Coopération et collaboration
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 :
Chapitre 2: Coopération et collaboration
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
Chapitre 2: Coopération et collaboration
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,
Chapitre 2: Coopération et collaboration
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,
Chapitre 2: Coopération et collaboration
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
Chapitre 2: Coopération et collaboration
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.
Chapitre 2: Coopération et collaboration
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.
Chapitre 2: Coopération et collaboration
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.
Chapitre 2: Coopération et collaboration
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.
Chapitre 2: Coopération et collaboration
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
Chapitre 2: Coopération et collaboration
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.
Chapitre 2: Coopération et collaboration
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.
Chapitre 3: CSCW (Computer Supported Cooperative Work)
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
Chapitre 3: CSCW (Computer Supported Cooperative Work)
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.
Chapitre 3: CSCW (Computer Supported Cooperative Work)
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
Chapitre 3: CSCW (Computer Supported Cooperative Work)
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
Chapitre 3: CSCW (Computer Supported Cooperative Work)
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
Chapitre 3: CSCW (Computer Supported Cooperative Work)
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]
Chapitre 3: CSCW (Computer Supported Cooperative Work)
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)
Chapitre 3: CSCW (Computer Supported Cooperative Work)
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
Chapitre 3: CSCW (Computer Supported Cooperative Work)
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".
Chapitre 3: CSCW (Computer Supported Cooperative Work)
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
Chapitre 3: CSCW (Computer Supported Cooperative Work)
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.)
Chapitre 3: CSCW (Computer Supported Cooperative Work)
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.
Chapitre 3: CSCW (Computer Supported Cooperative Work)
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
Chapitre 3: CSCW (Computer Supported Cooperative Work)
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).
Chapitre 3: CSCW (Computer Supported Cooperative Work)
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 à
Chapitre 3: CSCW (Computer Supported Cooperative Work)
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 ?
Chapitre 3: CSCW (Computer Supported Cooperative Work)
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 :
Chapitre 3: CSCW (Computer Supported Cooperative Work)
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
Chapitre 3: CSCW (Computer Supported Cooperative Work)
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
Chapitre 3: CSCW (Computer Supported Cooperative Work)
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 »
Chapitre 3: CSCW (Computer Supported Cooperative Work)
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
Chapitre 3: CSCW (Computer Supported Cooperative Work)
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
Chapitre 3: CSCW (Computer Supported Cooperative Work)
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 :
Chapitre 3: CSCW (Computer Supported Cooperative Work)
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.
Chapitre 3: CSCW (Computer Supported Cooperative Work)
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
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
Chapitre 4 : Systèmes de gestion de la e-maintenance
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
Chapitre 4 : Systèmes de gestion de la e-maintenance
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.
Chapitre 4 : Systèmes de gestion de la e-maintenance
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
Chapitre 4 : Systèmes de gestion de la e-maintenance
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.
Chapitre 4 : Systèmes de gestion de la e-maintenance
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
Chapitre 4 : Systèmes de gestion de la e-maintenance
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
Chapitre 4 : Systèmes de gestion de la e-maintenance
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
Chapitre 4 : Systèmes de gestion de la e-maintenance
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
Chapitre 4 : Systèmes de gestion de la e-maintenance
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/
Chapitre 4 : Systèmes de gestion de la e-maintenance
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/
Chapitre 4 : Systèmes de gestion de la e-maintenance
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.
Chapitre 4 : Systèmes de gestion de la e-maintenance
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.
Chapitre 4 : Systèmes de gestion de la e-maintenance
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,
Chapitre 4 : Systèmes de gestion de la e-maintenance
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 :
Chapitre 4 : Systèmes de gestion de la e-maintenance
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.
Chapitre 4 : Systèmes de gestion de la e-maintenance
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
Chapitre 4 : Systèmes de gestion de la e-maintenance
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
Chapitre 4 : Systèmes de gestion de la e-maintenance
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
Chapitre 4 : Systèmes de gestion de la e-maintenance
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 :
Chapitre 4 : Systèmes de gestion de la e-maintenance
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.
Chapitre 4 : Systèmes de gestion de la e-maintenance
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
Chapitre 4 : Systèmes de gestion de la e-maintenance
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
Chapitre 4 : Systèmes de gestion de la e-maintenance
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
Chapitre 4 : Systèmes de gestion de la e-maintenance
104
Figure 4.8 : Modélisation des interactions entre 3 experts en mode synchrone
[STVZ06]
Chapitre 4 : Systèmes de gestion de la e-maintenance
105
Figure 4.9 : Capture d’écran du simulateur des systèmes coopératifs [STVZ06]
Chapitre 4 : Systèmes de gestion de la e-maintenance
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]
Chapitre 4 : Systèmes de gestion de la e-maintenance
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.
Chapitre 4 : Systèmes de gestion de la e-maintenance
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.
Chapitre 4 : Systèmes de gestion de la e-maintenance
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
Chapitre 4 : Systèmes de gestion de la e-maintenance
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
Chapitre 5 : Modélisation d’un Workflow pour l’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 ?
Chapitre 5 : Modélisation d’un Workflow pour l’e-maintenance
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
Chapitre 5 : Modélisation d’un Workflow pour l’e-maintenance
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),
Chapitre 5 : Modélisation d’un Workflow pour l’e-maintenance
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.
Chapitre 5 : Modélisation d’un Workflow pour l’e-maintenance
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
Chapitre 5 : Modélisation d’un Workflow pour l’e-maintenance
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 :
Chapitre 5 : Modélisation d’un Workflow pour l’e-maintenance
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
Chapitre 5 : Modélisation d’un Workflow pour l’e-maintenance
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>
Chapitre 5 : Modélisation d’un Workflow pour l’e-maintenance
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).
Chapitre 5 : Modélisation d’un Workflow pour l’e-maintenance
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]
Chapitre 5 : Modélisation d’un Workflow pour l’e-maintenance
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
Chapitre 5 : Modélisation d’un Workflow pour l’e-maintenance
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
(Experts) Coordinateur
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
Chapitre 5 : Modélisation d’un Workflow pour l’e-maintenance
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.
Chapitre 5 : Modélisation d’un Workflow pour l’e-maintenance
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
Chapitre 5 : Modélisation d’un Workflow pour l’e-maintenance
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
Chapitre 5 : Modélisation d’un Workflow pour l’e-maintenance
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]
Chapitre 5 : Modélisation d’un Workflow pour l’e-maintenance
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
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
Chapitre 6 : Etude de cas Le complexe GP1Z
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
Chapitre 6 : Etude de cas Le complexe GP1Z
132
Figure 6.2 : Système de supervision de la production
Chapitre 6 : Etude de cas Le complexe GP1Z
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
Chapitre 6 : Etude de cas Le complexe GP1Z
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
Chapitre 6 : Etude de cas Le complexe GP1Z
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
Chapitre 6 : Etude de cas Le complexe GP1Z
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
Chapitre 6 : Etude de cas Le complexe GP1Z
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%
Chapitre 6 : Etude de cas Le complexe GP1Z
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.
Chapitre 6 : Etude de cas Le complexe GP1Z
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
Chapitre 6 : Etude de cas Le complexe GP1Z
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
Chapitre 6 : Etude de cas Le complexe GP1Z
141
[LARE11 ????
Figure 6.9 : Saisie du modèle Workflow OSSAD par l’application
DUOProcss
Chapitre 6 : Etude de cas Le complexe GP1Z
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
Chapitre 6 : Etude de cas Le complexe GP1Z
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
Chapitre 6 : Etude de cas Le complexe GP1Z
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
Chapitre 6 : Etude de cas Le complexe GP1Z
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
Chapitre 6 : Etude de cas Le complexe GP1Z
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
(Experts) Coordinateur
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
Chapitre 6 : Etude de cas Le complexe GP1Z
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
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.
Conclusions et Perspectives
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.
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
Recommended