Thèse - u-bordeaux.frori-oai.u-bordeaux1.fr/pdf/2012/BACZKOWSKI_MYLENE_2012.pdf · 2015. 1. 5. · Université Bordeaux 1 Les Sciences et les Technologies au service de l’Homme

Université Bordeaux 1

Les Sciences et les Technologies au service de l’Homme et de l’environnement

N° d'ordre : 4714

THÈSE

PRÉSENTÉE A

L’UNIVERSITÉ BORDEAUX 1

ÉCOLE DOCTORALE DES SCIENCES PHYSIQUES ET DE L’INGENIEUR

Par Mlle. Mylène BACZKOWSKI

POUR OBTENIR LE GRADE DE

DOCTEUR

SPÉCIALITÉ : PRODUCTIQUE

TITRE : Amélioration du processus de déploiement d’une solution PLM par l’utilisation de

cartes heuristiques et de persona : cas LASCOM

Directeur de recherche : Professeur Philippe GIRARD

Soutenue le : 12 décembre 2012

Devant la commission d’examen formée de :

MM. Aziz BOURAS Président du jury

Aziz BOURAS Rapporteur

Professeur des Universités - Université Lumière Lyon 2

Benoît EYNARD Rapporteur Enseignant Chercheur HDR – Université de Technologie de Compiègne

Philippe GIRARD Directeur de thèse Professeur des Universités – IUFM d’Aquitaine – Université Bordeaux 4

Vincent ROBIN Co-directeur

Maître de Conférences – IUFM d’Aquitaine – Université Bordeaux 4

Christophe MERLO Examinateur

Docteur (HDR) – ESTIA

Sabine NOISETTE Examinateur Directrice de recherche – LASCOM – Bièvres

Bertrand ROSE Examinateur Maître de conférence – Université de Strasbourg

Dominique PIOLLE Invité Technical Sales Director, BT EuroWest - Dassault Systèmes

A mes proches

Résumé ___________________________________________________________________________

Pour améliorer le pilotage et la gestion de l’ensemble des activités, les entreprises tentent de

mettre en œuvre des solutions informatiques aptes à répondre à leurs besoins théoriques.

Toutefois lors de la mise en pratique, de nombreuses itérations sont généralement nécessaires

pour s’approcher d’une solution adéquate à leurs besoins réels. Cet écart provient

essentiellement de trois causes majeures. D’une part un manque de maturité et la

connaissance des besoins réels au sein de l’entreprise. D’autre part la difficulté de transposer

ces besoins métiers dans une solution logicielle prédéfinie et enfin du manque de

communication sur le projet et d’investissement des utilisateurs finaux.

Notre contribution se place dans une dynamique de recherche d’amélioration des processus

d’implémentation et de déploiement des solutions logicielles de type PLM dans les

entreprises. Nous proposons une démarche complète de déploiement, centrée sur les acteurs

de l’entreprise et qui s’appuie sur l’utilisation de deux outils jusque là peu usités pour

répondre à ce type de problématique : les cartes heuristiques et les personas. Cette démarche a

été construite puis mise en œuvre dans le cadre d’une collaboration avec LASCOM, éditeur

de solutions PLM.

Mots-clés : persona ; carte heuristique ; PLM ; déploiement ; expression des besoins ;

centrage utilisateur

Remerciements ___________________________________________________________________________

Je tiens tout d’abord à exprimer ma profonde reconnaissance envers la société LASCOM qui

m’a permis de réaliser cette thèse CIFRE malgré un sujet qui s’est un peu éloigné des

préoccupations premières d’un éditeur. Je tiens plus particulièrement à remercier Monsieur

Dominique PIOLLE ancien Directeur Marketing & Avant Vente qui a initié ce projet et qui

m’a fait confiance. Ces années partagées ont contribué à faire évoluer le sujet en fonction de

nos échanges, de l’expérience et de l’analyse du terrain mais également de mes motivations.

Je remercie également Madame Sabine NOISETTE qui a su reprendre le flambeau à son

arrivée chez LASCOM après une période de trouble. L’un comme l’autre ont permis grâce à

leur expérience et leur souci de l’utilisateur final de prendre des orientations de recherche

pragmatiques faces aux problèmes rencontrés.

Je remercie bien évidemment mon directeur de thèse et mon encadrant de thèse, en

commençant par Monsieur Philippe GIRARD pour sa confiance tout au long du projet. Je

remercie également Monsieur Vincent ROBIN pour son soutien et pour les confrontations très

intéressantes entre les deux mondes que peuvent être la recherche et l’industrie.

Je remercie également les membres du jury, tout particulièrement Monsieur Aziz BOURAS

pour avoir présidé la séance, mais aussi pour avoir tenu le rôle de rapporteur avec Monsieur

Benoit EYNARD. Tous deux ont permis d’apporter des pistes de réflexions intéressantes.

Je n’oublie pas tout ceux qui ont eu un rôle moins officiel mais tout aussi important tout au

long de ma vie sans qui je n’aurais jamais pu arriver jusque là. Je remercie également

vivement toutes les personnes qui m’ont soutenu et encouragé durant ces quatre années de

thèse tant dans le cadre personnel (ma famille, mon ange gardien, mes amis) que dans le cadre

professionnel (la liste est un peu trop longue vous m’en excuserez j’en suis sure). Sans ce

soutien quotidien ou du moins fréquent, je n’aurais jamais réussi à parvenir au terme de cette

expérience enrichissante mais semée d’embûches et de doutes. Et pour finir l’initiateur de

cette aventure, qui rentre dans de nombreuses catégories précitées, monsieur Bertrand ROSE

sans qui cette aventure n’aurait jamais vu le jour et n’aurait jamais abouti.

Table des matières

Page 9

Table des matières ___________________________________________________________________________

INTRODUCTION GENERALE .............................................................................................................. 17

CHAPITRE 1 ......................................................................................................................................... 21

PROBLEMATIQUE ................................................................................................................... 21

1 Introduction ...................................................................................................................... 21

2 La « r »évolution de l’informatisation ............................................................................... 25

2.1 L’évolution de l’informatisation .................................................................................................... 25

2.2 Du Système d’Information support à la stratégie… ...................................................................... 27

2.3 … Au Système d’Information partie intégrante de la stratégie ..................................................... 29

3 Les verrous de l’implémentation d’un Système d’Information en entreprise ................... 32

3.1 L’organisation polymorphe des entreprises .................................................................................. 33

3.2 La vision transverse : hétérogénéité organisationnelle................................................................. 38

3.3 La collaboration : hétérogénéité sémantique ................................................................................ 39

3.4 Une implémentation intégrée pour une meilleure interopérabilité ............................................... 40

4 Synthèse .......................................................................................................................... 41

CHAPITRE 2 ......................................................................................................................................... 45

METHODOLOGIE DE DEPLOIEMENT D’UNE SOLUTION PLM ................................................... 45

1 Introduction ...................................................................................................................... 45

2 Les briques fonctionnelles ............................................................................................... 47

2.1.1 La gestion électronique documentaire : la mémoire de l’entreprise..................................................... 47

2.1.2 La gestion de configuration : la représentation réelle d’un produit/projet ........................................... 48

2.1.3 Les processus : le dynamisme de l’entreprise ...................................................................................... 50

2.1.4 Le reporting : le support à l’aide à la décision ..................................................................................... 53

3 Mise en place d’un PLM : un processus aux multiples facettes ...................................... 57

3.1 La mise en place théorique vue du coté « client » ......................................................................... 57

3.2 La mise en place théorique vue du coté « éditeur », exemple de LASCOM .................................. 58

4 Des besoins à la solution logicielle : de la réalité aux modèles ....................................... 63

4.1 Les approches de modélisation d’entreprises ............................................................................... 63

4.1.1 L’approche « descendante » : l’intégration itérative ............................................................................ 63

4.1.2 L’approche « ascendante » : la fédération ........................................................................................... 64

4.2 Les méthodes et outils de modélisation d’entreprise et de processus ............................................ 65

4.2.1 Méthodes et outils de modélisation d’entreprise .................................................................................. 65

4.2.2 Méthodes et outils de modélisation des processus/activités ................................................................. 66

4.2.3 Analyse et synthèse ............................................................................................................................. 68

5 Synthèse .......................................................................................................................... 68

CHAPITRE 3 ......................................................................................................................................... 71

ANALYSE ET AMELIORATION DU DEPLOIEMENT DES SOLUTIONS : LE CAS LASCOM ............ 71

Table des matières

Page 10

1 Introduction ...................................................................................................................... 71

2 La réponse de LASCOM aux problématiques industrielles ............................................. 72

2.1 D’une solution « globale » vers des plateformes adaptées et pré-paramétrées : la

« verticalisation » ................................................................................................................................... 74

2.1.1 LASCOM AEC (Architectural Engineering & Construction) ............................................................. 75

2.1.2 LASCOM ICS (Industry & Complex Systems) ................................................................................... 77

2.1.3 LASCOM CPG (Consumer Packaged Goods) .................................................................................... 79

2.1.4 Synthèse .............................................................................................................................................. 80

2.2 Vers une évolution de la démarche de déploiement de la solution ................................................ 82

2.2.1 Définir le cadre du projet : le périmètre, les acteurs, les interlocuteurs potentiels ............................... 83

2.2.2 Des phases clés : avant-projet et après projet ...................................................................................... 84

2.3 Communiquer, former et accompagner le client pour être efficace .............................................. 89

2.3.1 Des actions de communication/formation de plus en plus en amont ................................................... 89

2.3.2 Un accompagnement sur le long terme : une hotline au service du client ........................................... 91

3 Synthèse .......................................................................................................................... 94

CHAPITRE 4 ......................................................................................................................................... 97

ADAPTER L’APPROCHE ET LE DIALOGUE « CLIENT » : UN VECTEUR DE PERFORMANCE ......... 97

1 Introduction ...................................................................................................................... 97

2 Le choix de la méthodologie de modélisation : une étape clé ......................................... 99

2.1 Problématique générale du choix de la méthodologie .................................................................. 99

2.2 Le casse-tête de la représentation multi-niveaux et de l’implication des acteurs ....................... 101

2.3 Deux outils « non conventionnels » pour lever les verrous ......................................................... 102

3 Les cartes heuristiques : une base commune de modélisation et de discussion .......... 104

3.1 La carte heuristique ou une structuration rapide d’idées ........................................................... 105

3.2 La formalisation heuristique tout au long du projet : approche théorique ................................. 108

3.2.1 Le commercial et la map ................................................................................................................... 108

3.2.2 L’avant vente et la map ..................................................................................................................... 109

3.2.3 Le service projet et la map ................................................................................................................. 110

3.2.4 Le support client et la map ................................................................................................................ 113

3.2.5 Synthèse ............................................................................................................................................ 114

3.3 Une carte générique pour le déploiement des solutions LASCOM ............................................. 115

3.3.1 Le contexte de l’entreprise ................................................................................................................ 117

3.3.2 Suivi des interventions ...................................................................................................................... 123

3.3.3 Suivi des livraisons ............................................................................................................................ 128

3.3.4 Définition des applications ................................................................................................................ 128

4 Synthèse ........................................................................................................................ 133

CHAPITRE 5 ....................................................................................................................................... 135

UNE ANALYSE CENTREE SUR LES FUTURS UTILISATEURS ..................................................... 135

1 Introduction .................................................................................................................... 135

2 Persona : une approche au plus près des utilisateurs finaux ........................................ 136

Table des matières

Page 11

2.1 Contexte et approche théorique .................................................................................................. 136

2.2 De la map à persona : de l’entreprise à l’acteur ........................................................................ 138

2.2.1 Etape préliminaire : comment et quand établir les questionnaires ? .................................................. 138

2.2.2 Mise en place des questionnaires durant la phase d’analyse des besoins ........................................... 142

2.2.3 Mise en place des questionnaires durant la phase d’exploitation ....................................................... 153

3 Synthèse : Confrontation des deux approches pour consolider le modèle ................... 157

CHAPITRE 6 ....................................................................................................................................... 163

L’ENTREE DANS LE PROCESSUS ET LES PROBLEMATIQUES ASSOCIEES : ETUDES DE CAS CHEZ

LASCOM ........................................................................................................................... 163

1 Cas d’une réponse à un appel d’offres : la map pour initialiser et aider à la

communication ............................................................................................................................. 163

1.1 Réponse à un appel d’offres par l’avant vente ............................................................................ 164

1.1.1 Problématique liée à l’avant vente ..................................................................................................... 164

1.1.2 L’importance de la map en avant vente ............................................................................................. 166

1.2 L’analyse des besoins : le cœur du processus ............................................................................. 174

1.2.1 Problématique de l’analyse des besoins ............................................................................................. 174

1.2.2 L’importance de l’exploration et des persona pour définir les besoins réels ..................................... 176

1.3 Synthèse ....................................................................................................................................... 183

2 Cas d’une reprise d’exploitation : importance des supports .......................................... 186

2.1 Problématique de la constitution d’une vue globale de l’application ......................................... 186

2.2 Mise en évidence de l’intérêt de la map comme support d’intervention ..................................... 188

2.2.1 Situations sans notre proposition ....................................................................................................... 188

2.2.2 Situation avec notre proposition. ....................................................................................................... 192

2.3 Synthèse ....................................................................................................................................... 193

CONCLUSION ET PERSPECTIVES .................................................................................................. 197

BIBLIOGRAPHIE PERSONNELLE .................................................................................................... 205

BIBLIOGRAPHIE ................................................................................................................................ 207

ANNEXES ........................................................................................................................................... 215

Table des matières

Page 12

Liste des figures

Figure 1. La brique fonctionnelle « Gestion des Configurations » ......................................... 48

Figure 2. La brique fonctionnelle « Gestion Documentaire » ................................................. 50

Figure 3. La brique fonctionnelle « Gestion des Processus » ................................................. 53

Figure 4. La brique fonctionnelle « Reporting » ..................................................................... 56

Figure 5. Les tâches d'un projet logiciel par activités et par phases ....................................... 59

Figure 6. Les différentes phases d’un projet d’informatisation chez LASCOM ...................... 60

Figure 7. La déclinaison LASCOM PLM pour le marché de l’AEC ........................................ 77

Figure 8. La déclinaison LASCOM PLM pour le marché de l’ICS ......................................... 78

Figure 9. La déclinaison LASCOM PLM pour le marché du CPG ......................................... 80

Figure 10. Cyclicité du processus d’informatisation ............................................................... 87

Figure 11. L’illustration des sept questions d’Aristote [Créativité, 12] ................................ 107

Figure 12. Les acteurs du processus d’informatisation et points d’évolution de la map ...... 115

Figure 13. Structure d’une carte client générique (« méta-map ») ....................................... 117

Figure 14. Le contexte prédéfini par le commercial .............................................................. 119

Figure 15. Le contexte enrichi par l’avant vente ................................................................... 120

Figure 16. Le contexte revu lors du projet ............................................................................. 122

Figure 17. Contexte à prendre en compte pour le projet ....................................................... 123

Figure 18. L’initialisation du suivi des interventions par l’avant vente ................................ 125

Figure 19. Le suivi des interventions en cours de projet ....................................................... 126

Figure 20. Convention pour les interventions par le support ................................................ 127

Figure 21. Origine d’une correction par le support .............................................................. 127

Figure 22. Structure de la partie « Livrable » ....................................................................... 128

Figure 23. La définition succincte de l’application vue par l’avant vente ............................ 130

Figure 24. Élaboration partielle de la définition de l’application ........................................ 131

Figure 25. Structure de l’organisation de l’application ........................................................ 132

Figure 26. Persona ou la définition de l’organisation dans la map projet ........................... 141

Figure 27. Les documents manipulés vus par les utilisateurs ................................................ 144

Figure 28. Les questionnaires sources de la typologie des documents ................................. 145

Figure 29. L’utilisation vue par les utilisateurs ..................................................................... 146

Figure 30. Communiquer sur l’aboutissement du travail commun ....................................... 147

Figure 31. Communiquer sur les listes établies ..................................................................... 148

Table des matières

Page 13

Figure 32. La grille d’utilisation de l’application ................................................................. 149

Figure 33. Personnifier l’utilisation ...................................................................................... 151

Figure 34. Présenter le persona de l’utilisateur .................................................................... 152

Figure 35. Les difficultés des utilisateurs .............................................................................. 155

Figure 36. Les demandes d’améliorations des utilisateurs .................................................... 156

Figure 37. Apport de persona au contexte de la carte heuristique ........................................ 160

Figure 38. Réponse financière de LASCOM .......................................................................... 166

Figure 39. Extraits du Cahier Technique des Clauses Particulières (CCTP) ....................... 167

Figure 40. Extrait de la réponse technique LASCOM (1/2) .................................................. 168

Figure 41. Extraits de la réponse technique LASCOM (2/2) ................................................. 169

Figure 42. Carte issue de l’analyse de l’extrait du CCTP ..................................................... 171

Figure 43. Image de l’application envisagée par l’avant vente ............................................ 172

Figure 44. Impacts de la map « avant vente » au cours du processus ................................... 173

Figure 45. La définition du fonctionnement issue du cahier des charges .............................. 176

Figure 46. Exemple de chiffrage pour une nouvelle application ........................................... 177

Figure 47. Définition du fonctionnement suite à la consultation interne .............................. 178

Figure 48. Exemple de modification effectuée ....................................................................... 179

Figure 49. Exemple de désactivation ..................................................................................... 180

Figure 50. Support à l’initiation à la map contexte ............................................................... 181

Figure 51. Extrait du contexte issu de l’analyse .................................................................... 181

Figure 52. Impacts de l’utilisation de la map pour l’analyse des besoins ............................. 183

Figure 53. Améliorations du processus de déploiement ........................................................ 185

Figure 54. Améliorations des étapes après projet ................................................................. 194

Figure 55. Phase du cycle de vie d’un produit ...................................................................... 217

Figure 56. Cycle de vie d’un produit ..................................................................................... 218

Figure 57. Complémentarité de l’ERP et du PLM ................................................................. 220

Figure 58. Principe de la méthode MPPI .............................................................................. 223

Figure 59. Diagramme BPMN du processus d'avant-projet .................................................. 225

Figure 60. Diagramme BPMN du processus de déploiement ................................................ 228

Figure 61. Phase de gestion du changement [Debaecker, 04] .............................................. 229

Table des matières

Page 14

Liste des tableaux

Tableau 1. Etude comparative des outils/méthodes de modélisation de processus ................. 67

Table des matières

Page 15

Liste des annexes

Annexe 1. Des solutions logicielles au cœur de la « r »évolution : ERP et PLM .................. 215

Annexe 2. Processus de déploiement d’une solution PLM en PMI/PME [Bissay, 10] .......... 222

Annexe 3. Adapter l’outil aux entreprises .............................................................................. 233

Annexe 4. PERSONNA ........................................................................................................... 241

Introduction générale

Page 17

Introduction générale ___________________________________________________________________________

Notre contribution se place dans une dynamique de recherche d’amélioration des

processus d’implémentation et de déploiement de solutions logicielles de type PLM dans les

entreprises. Nous proposons une démarche complète de déploiement, centrée sur les acteurs

de l’entreprise et qui s’appuie sur l’utilisation de deux outils jusque là peu usités pour

répondre à ce type de problématique : les cartes heuristiques et les personas.

Le premier chapitre montre dans quel contexte les industriels cherchent des solutions

informatiques leurs permettant de les aider à piloter et à gérer l’ensemble des activités liées

aux produits/projets. Nous présentons ensuite deux types de logiciels de gestion proposés sur

le marché : les ERP (Enterprise Ressource Planning), pour la gestion des ressources et des

plannings, et le PLM (Product Life Management) pour la gestion des données techniques. Au

regard du contexte, nous mettons en exergue les difficultés rencontrées par les industriels et

les éditeurs logiciels et en particulier la nécessité pour les premiers d’être conscients de

l’impact structurant de ce type de projet et les seconds d’avoir une méthodologie de

déploiement efficace et fiable. L’enjeu de ce travail de recherche est alors replacé dans le

contexte plus spécifique de cette thèse CIFRE chez LASCOM puisque nous nous focalisons

sur notre problématique d’amélioration de la méthodologie de déploiement mise en œuvre par

cet éditeur de solutions de PLM.

Le second chapitre identifie les principaux verrous de l’implémentation d’une solution

logicielle. Pour LASCOM, le problème réside surtout dans le nombre d’itérations nécessaires

au recueil d’informations chez le client en vue d’obtenir un modèle exploitable de

l’entreprise. LASCOM souhaite réduire ces itérations en améliorant les phases amont de son

processus d’implémentation. En partant du postulat que les entreprises clientes et que les

intervenants nécessaires à la construction du modèle ne sont pas tous des experts dans les

techniques de modélisation utilisées, nous montrons que l’un des préalables essentiel au

déploiement d’une solution est le choix du « langage » de modélisation. Il doit être simple et

mettre en évidence de façon explicite l’ensemble des informations pour favoriser l’implication

et la compréhension de chacune des entités interrogées quelque soit le niveau de maturité du

projet.


Page 18

Le troisième chapitre concerne l’étude et l’analyse critique des formalismes

classiquement utilisés pour modéliser les entreprises et leurs processus. Le but de cette

analyse est de travailler à l’affinement de la démarche d’implémentation chez LASCOM et à

l’identification d’au moins un formalisme « accessible » et « utilisable » dans le monde

industriel pour répondre à notre problématique. Nous montrons aussi que la pérennité d’une

solution PLM dans une entreprise est garantie quasiment essentiellement par le fait que les

utilisateurs se l’approprie. Pour ce faire, nous proposons de revoir les phases critiques du

processus de déploiement pour faire que les utilisateurs soient parties prenantes très tôt du

projet, de son développement jusqu’à la fin de l’exploitation de la solution.

Le quatrième chapitre décrit les outils supports à la démarche qui contribueront au

respect des grands principes que nous définissons dans ce chapitre. Nous nous centrons

essentiellement sur les outils supports à la modélisation des processus et à l’émergence des

profils utilisateurs. Notre réflexion nous conduit dans un premier temps à utiliser les cartes

heuristiques pour lever certains verrous que nous avons identifiés. Dans notre proposition, la

carte heuristique (ou map) qui doit constituer le support du projet et plus globalement du

cycle de vie de l’application, joue le rôle de moteur de la réflexion et de la communication.

Dans le cadre d’un projet, l’utilisation de la map offre une nouvelle dimension à la définition

de l’application et à la communication avec le client : une structure et une organisation

dynamiques et « immédiates » qui reprennent sur un seul document très visuel l’ensemble des

informations ce qui est un atout vis-à-vis des différents prototypes présentés d’une réunion à

l’autre. L’autre intérêt de la map réside dans le fait qu’elle est conçue conjointement avec le

client ce qui a pour effet de lui faire percevoir et assimiler la philosophie du logiciel.

Le cinquième chapitre se centre sur l’accompagnement et l’implication du client lors

de la construction de carte heuristique pour finalement replacer le client - et en particulier les

futurs utilisateurs - au centre de nos préoccupations. Nous proposons donc une démarche

complémentaire à la carte heuristique pour faire émerger des spécifications directement par le

client. Notre objectif est ici de responsabiliser encore un peu plus le client dans l’analyse et de

faire en sorte que l’éditeur reste centré sur son savoir faire pour faire des économies (chiffrage

plus précis et projet plus court). Nous nous appuyons ici sur la définition de personas qui

illustrent les rôles tenus par les utilisateurs dans un environnement plus ou moins précis. La

carte heuristique permet d’obtenir un support unique pour suivre le cycle de vie du logiciel et

sa construction repose sur l’approche descendante, tandis que le persona, centré sur les


Page 19

utilisateurs et leur environnement, se base sur une approche ascendante. C’est l’association

des deux qui offre une dimension de complémentarité des approches, grâce à la double

exploration du système et à une confrontation facilitée sur un même support, améliorant la

pertinence et la qualité de l’analyse donc de l’application.

Le sixième chapitre présente des études de cas menées dans le cadre de projets

« réels » auprès de clients de LASCOM. Chaque projet est unique, en fonction du secteur, du

métier, des intervenants, des prédispositions, du contexte, des ambitions, des contraintes, des

intervenants mais il est généralement possible de classer les projets en fonction de leur état

d’avancement initial, des éléments mis à la disposition de l’éditeur et des attentes des clients.

Le problème pour LASCOM va être d’identifier à quelle étape de son processus

d’implémentation se fait le démarrage du projet. Classiquement trois entrées dans le processus

sont possibles : soit l’éditeur répond à un appel d’offres, soit il répond à une demande

d’amélioration/évolution, soit il est dans une phase de prospection. Nous décrivons dans ce

chapitre le cas d’une entrée dès l’avant projet, puis d’une intervention « classique » pour

LASCOM - c'est-à-dire suite à la constitution d’un cahier des charges, pour finir par un projet

de reprise qui fait suite à l’exploitation d’une solution déjà en place.

Le dernier chapitre de ce mémoire synthétise notre contribution, reprend la

chronologie de nos travaux et identifie leurs limites actuelles, ce qui nous permet de proposer

des perspectives industrielles et universitaires de cette recherche.

Chapitre 1 Problématique

Page 21

Chapitre 1

Problématique

___________________________________________________________________________

1 Introduction

Dans le contexte économique actuel, aux évolutions incertaines amplifiées par la

mondialisation des échanges commerciaux, la rationalisation est devenue le mot d’ordre des

entreprises tant d’un point de vue de leurs activités que de leur structure. Cette rationalisation

s’articule particulièrement autour de trois points essentiels : la recentralisation de leur activité

sur leur métier propre, la croissance de leurs performances et leur capacité d’innovation. Les

entreprises ont en effet compris que leur atout majeur, source de valeur ajoutée sur leurs

produits et donc de bénéfices, résidait dans leurs savoir-faire et non dans la multiplication

d’activités nécessitant de déployer d’énormes moyens pour des résultats dégageant peu de

retours sur investissement directs. Cette prise de conscience a engendré des bouleversements

majeurs et une réflexion profonde au niveau de leur organisation et de leurs méthodes de

consolidation de leurs savoir-faire afin d’accroître leur performance.

Ce bouleversement est le fruit de la lente évolution économique à laquelle nous avons assistée

ces soixante dernières années. Classiquement, trois phases se distinguent durant cette période

[Giard, 2003]. La première débute à la fin de la guerre en 1945, tout est à reconstruire, tant les

hommes que les infrastructures ou l’économie. Grâce au plan de relance mis en place (le plan

Marshall), les entreprises sont les fers de lance de cette période de reconstruction surnommée

les Trente Glorieuses. Elles permettent de répondre activement à la forte demande grâce aux

avancées technologiques issues de la guerre, tout en offrant le plein emploi. Stratégiquement

les entreprises cherchent à produire peu de produits différents mais à les générer en masse,

l’organisation n’est pas au centre de leurs préoccupations. Elles optent pour l’organisation la

plus naturelle : le produit est conçu en passant d’un département à l’autre, d’un intervenant à

l’autre de façon séquentielle, correspondant à une structure purement fonctionnelle [Boboc,

02]. La confiance renait au sein de la population, la consommation prend peu à peu le pas sur

la pénurie jusqu’à la survenue du premier choc pétrolier en 1973. Cet événement sonne le

début de la seconde phase et l’essor industriel important aboutit à cette époque à équilibrer

l’offre et la demande. Pour conserver leur monopole sur le marché les entreprises optent pour


Page 22

la diversification de leurs produits en élargissant leurs gammes, leurs activités et leurs cibles

en partant à la conquête du marché international. La concurrence grandissant, les entreprises

cherchent des moyens de diminuer leurs coûts. C’est l’ère de la négociation et de la sous-

traitance. La performance et l’organisation prennent place au cœur de la stratégie des

entreprises. La gestion d’un portefeuille de produit/projet de plus en plus volumineux et la

conduite d’une organisation élargie à l’externalisation font naitre des besoins nouveaux de

suivi centralisé, tant d’un point de vue économique que d’un point de vue planning pour

favoriser le développement de l’entreprise. Finalement les frontières s’effacent peu à peu et

c’est en 1989 que le monde - et en particulier l’Europe découvre le potentiel économique et

industriel du bloc de l’Est. La délocalisation ne se limite plus aux activités à fort coût de main

d’œuvre, mais à l’ensemble des productions pour profiter des avantages de la relance

financière des pays de l’Est et également de leur position géographique centrale. La

mondialisation permet d’accroître la compétitivité des entreprises, en diminuant les coûts de

production, mais a contrario cette ouverture du marché, les contraint aussi à faire face à un

nombre de plus en plus important de concurrents en pleine croissance. La performance

devient l’axe prépondérant dans la stratégie mises en œuvre par les industriels. La

coordination nécessaire des projets et la continuité dans la relation entre le projet et les

départements métier qui en découle deviennent prépondérantes dans la méthodologie.

L’organisation de la conception utilisée jusque là montre ses limites, elle est revue et passe

d’un modèle séquentiel à un modèle concourant à l’image des méthodes mise en œuvre dans

le système japonais requérant un pilotage et un suivi accrus. En effet, « on se rend compte que

la manière séquentielle de déroulement des phases dans le projet est source de coûts

supplémentaires, sans être la voie vers un bon compromis efficacité/qualité. De plus, on

prend conscience du fait qu’enchaîner des solutions considérées optimales au niveau local

n'amène pas vers un optimum global. » [...] Alors que [...] « parmi les aspects découverts

dans le système japonais concernant le management des projets / des produits nouveaux on

compte les équipes de projet auto-organisées, le recouvrement des étapes, qui détermine une

diminution de la durée totale du projet, l’apprentissage qui se situe au cœur du système de

management de projets, les procédés de contrôle, "fins et subtils", les apprentissages,

transférés systématiquement à l’organisation, etc. » [Boboc, 02]. La migration entre ces deux

types d’organisation s’opère dans le but d’accroître la performance et l’efficacité des

entreprises. Ce mouvement est complexifié par l’extension des distances géographiques entre

les différents intervenants contraignant les industriels à utiliser d’avantage les avancées


Page 23

technologiques des transports et de la communication pour parvenir à conserver un niveau de

gouvernance suffisant.

Pour comprendre les évolutions structurelles et fonctionnelles des entreprises il est nécessaire

de s’intéresser à l’étude des changements du contexte industriel. Ces changements sont

généralement décrits suivant trois périodes [Giard, 03]. La première période s’étend de 1945 à

1975 : les trente glorieuses. Le contexte industriel est caractérisé par une forte pénurie, la

croissance est forte, les marchés localisés et la demande est supérieure à l’offre. Le client a un

choix restreint car les entreprises ne cherchent pas forcément à innover et misent plutôt sur

une offre et une gamme très réduites de produits, produits en grand nombre et dont la durée de

vie est élevée [Le Masson et Weil, 05]. La seconde période court de 1975 à la fin des années

80 : l’offre équilibre la demande puis finit par la dépasser. Les marchés s’ouvrent et

deviennent de plus en plus concurrentiels. L’entreprise doit garantir la conformité du produit

fourni avec le produit attendu par le client et ce dans un délai de plus en plus court. L’une des

finalités principales est de répondre à des objectifs de conformité du produit et de satisfaction

du client mais aussi à des contraintes temporelles de plus en plus restrictives entre le moment

où le client exprime son besoin et le moment où celui-ci est effectivement satisfait. De plus,

les entreprises se doivent d’accroître la variété de leurs gammes pour ainsi être présentes et

positionnées sur divers marchés. Enfin, la troisième période va du début des années 90

jusqu’à aujourd’hui : l’offre est supérieure à la demande. Les entreprises doivent faire face à

un marché relativement saturé, ouvert et très concurrentiel. Adaptation du produit aux besoins

ciblés du client et réactivité sont donc les maîtres mots. Pour Kaplan [Kaplan et Norton, 98]

« la réactivité est devenue une arme concurrentielle majeure. Savoir répondre rapidement et

précisément à la demande d’un client est souvent essentiel pour conquérir et conserver sa

clientèle ». Cette réactivité s’applique à toutes les activités de l’entreprise : en conception

pour suivre (ou précéder) le marché, et développer et intégrer les innovations technologiques,

en production pour synchroniser les commandes et optimiser les délais de réalisation [Di

Mascolo 00], [Sadfi, 02]. Pour ce faire, les entreprises ont à répondre à un problème

relativement simple dans son énoncé mais complexe dans sa résolution : concevoir un produit

avec les fonctionnalités désirées, le plus rapidement possible, avec un coût et une qualité

acceptables pour le client, tout en assurant leur pérennité. Ceci n’est possible qu’en « pilotant

les dépendances entre les activités, analysant l’action du groupe en terme de recherche de la

performance des activités interdépendantes pour atteindre les objectifs en utilisant ou créant

des ressources et en analysant l’organisation à mettre en place pour faciliter la réutilisation

des processus efficients » [Crowston, 97]. Ceci se traduit par une organisation non plus basée


Page 24

sur des processus séquentiels mais basée sur un processus de conception intégré et une

ingénierie simultanée [Prudhomme, 99] pour embrasser toute la problématique du cycle de

vie du produit [Lonchampt, 04] et ce dans un contexte d’entreprise étendue [Browne, 95]. Les

différents aspects traités successivement dans les organisations séquentielles doivent

désormais être pris en compte simultanément et conjointement, les acteurs auront alors à

travailler en parallèle et à collaborer de plus en plus [Parsaei et Sullivan, 93]. La collaboration

entre les acteurs est d’autant plus nécessaire que la complexification croissante des processus

oblige à intégrer de plus en plus d’expertises souvent dispersées du fait de l’organisation des

entreprises [Midler, 97], [Poveda, 01], [Munoz, 02].

Un processus d’entreprise est donc une œuvre collective et son achèvement nécessite la

coopération de plusieurs acteurs, ainsi que la coordination du travail de ces acteurs

[Lonchampt, 04]. Une approche globale qui tiendrait compte aussi bien des acteurs, de

l’organisation mise en place pour coordonner leur travail et du contexte dans lequel le

processus se déroule est nécessaire pour maîtriser la performance de l’entreprise. Ceci nous

conduit à considérer non seulement les processus de l’entreprise mais également l’entreprise

elle-même et plus globalement le contexte dans lequel ils se déroulent. La définition la plus

couramment admise concernant le concept de processus est la suivante : « Le processus est un

ensemble d’activités inter-reliées utilisant des ressources afin de transformer des éléments

entrants en des éléments sortants » [ISO 9000/version 2000]. Cette transformation est le

résultat de l'écoulement d'un flux de nature informationnelle au travers d’une succession

d'activités qui le transforment et permettent de décrire le processus. Le Moigne

[Le Moigne, 90] caractérise les modifications du flux comme suit : « modification au cours

du temps (T) de la position du produit dans un référentiel "Espace-Forme" (E-F) et pouvant

être identifiée à une somme de processements d'un flux de produit dans l'espace (transport),

dans le temps (stockage) et dans la forme (transformation) ».

Diverses solutions organisationnelles et structurelles ont été mises en place pour répondre aux

objectifs stratégiques des entreprises dans le cadre de leur adaptation à ces différentes

contraintes et aux exigences du marché pour pérenniser leur place sur le marché. Pour

répondre à ces problématiques d’équipe virtuelle, de cycle de vie rapide, d’un besoin

d’innovation important, de réglementation de plus en plus stricte, les entreprises espèrent

trouver « la » solution qui leur permettraient non seulement d’accroître le retour sur

investissement, de diminuer la durée des phases de conception et de fabrication malgré les

contraintes liées à ces phases, mais aussi d’assurer d’avantage la qualité et la traçabilité des

produits et ce quasi immédiatement pour un coût modéré. La gestion informatisée des


Page 25

organisations, des processus et des différentes activités de l’entreprise et la dématérialisation

sont apparues comme autant de solutions aux problématiques des entreprises.

2 La « r »évolution de l’informatisation

2.1 L’évolution de l’informatisation

Dans le milieu des années 80, le rôle de l’ordinateur et celui de l’être humain sont bien

distincts. D’une part, l’ordinateur vient en « aide lors du traitement des dossiers individuels

dont il facilite aussi le tri et la recherche ; et il permet de produire des indicateurs » [Volle,

06]. D’autre part l’être humain libéré de ces actions fastidieuses et sans valeur ajoutée mais

pour autant nécessaires, se spécialise dans les tâches demandant une expertise métier : « il

analyse l’information pour faire le tour d’un problème, l’interprète pour comprendre, la

synthétise pour résumer et communiquer ce qu’il a compris ; enfin il décide ou même il

conçoit. » [Volle, 06]. C’est avec cet état d’esprit que les entreprises investissent dans des

automates et des mini-ordinateurs pour déporter les tâches répétitives de vérification, de

calcul et de transcription vers les machines plus performantes que l’être humain, en termes de

puissance et de mémoire. Cette informatisation des entreprises ne s’est pas faite sans mal et a

posé de nombreux problèmes. En effet, chaque éditeur, pour tenter de se différencier, a

développé de façon autonome ses propres outils, utilisant des interfaces et des bases de

données propres, et souvent même son propre langage dit « propriétaire ». Cette situation

conduit à ce que les « contours fonctionnels » de ces outils soient réduits. Ainsi, pour mener à

bien une activité, les usagers sont souvent contraints de se connecter à plusieurs

« applications » informatiques aux ergonomies différentes. Autre conséquence directe du

développement parallèle des applications : la mauvaise communication entre les outils et leur

non-interopérabilité [Paviot, 10]. Les utilisateurs devaient ressaisir des données dans chacune

des applications, à l’aide de codes divers et variés et dont la mémorisation demande un

apprentissage. Ceci ayant pour effet d’accroître les risques d’erreurs et de limiter le taux de

performance. Loin d’atteindre le niveau de performance qu’elles étaient en droit d’attendre

suite à la mise en place d’outils informatiques, les entreprises se contentaient d’une

performance « dégradée » directement liée à la capacité qu’avaient les utilisateurs de

s’adapter aux outils et aux machines malgré les défauts de cohérence et de « convivialité ».

Cette tolérance ne durera pas et deviendra de plus en plus insupportable au vue du besoin

croissant d’informatisation et des pertes engendrées par celle-ci. C’est le développement de la

mise en réseau des micro-ordinateurs, dans les années 90, qui a déclenché la réelle prise de


Page 26

conscience de la nécessaire cohérence dans l’utilisation des outils informatiques : « pour toute

donnée importante, seule doit exister sur le réseau une mesure définie et tenue à jour par le

propriétaire de la donnée » [Volle, 06]. L’informatique va alors évoluer avec pour objectif de

fournir à l’utilisateur « une interface qui, fédérant sous une ergonomie cohérente les accès

aux diverses applications, lui évite les connexions-déconnexions et les doubles saisies tout en

soulageant son effort de mémoire ; elle lui fournit aussi un média de communication » [Volle,

06]. Le concept de « système d’information » apparait à ce moment là avec pour ambition de

construire un référentiel unique sur lequel les diverses applications pourront s’appuyer. Cette

uniformisation induit non seulement la cohérence sémantique mais elle doit favoriser les

échanges de données et une mise à jour mutuelle, ce qui assure la cohérence de leur contenu

et supprime les ressaisies. Au-delà de l’uniformisation se pose le problème de la « gestion »

des échanges, de la nécessaire « orchestration » des actions à mener et de leur suivi/évaluation

par le fait que l’on assiste à un phénomène de dématérialisation du travail. Cette

dématérialisation fait que les utilisateurs sont en grande partie libérés des tâches répétitives et

fastidieuses (calculs, vérifications, transcription …) mais que les fonctions de logistique et de

supervision (vérification de la qualité du travail fait, évaluation de la productivité des

personnes, maîtrise des délais de production) sont devenues quasi impossibles. C’est pour

pallier à ces problématiques que le concept de workflows [David et al., 2001] [Benali et al.

2002] [WfMC, 99] à petit à petit vu le jour à la fin des années 90. Sous ce terme se cache des

sortes de tables d’adressage qui balisent les flux de données et offrent diverses fonctionnalités

comme la traçabilité (possibilité de retrouver, de consulter et d’identifier un dossier à tout

moment de son cycle de vie), des indicateurs de volume, de délai voire de qualité. La maîtrise

de ces aspects logistiques longtemps négligés par l’informatique devient alors nettement plus

performante comparativement à l’époque de la gestion « papier » en supprimant le risque du

« last in, first out », en assurant la traçabilité des dossiers et en produisant automatiquement

des indicateurs de volume et de délai qui facilitent la maîtrise de la qualité. Les entreprises ont

pris conscience de l’intérêt stratégique d’intégrer cette nouvelle « couche » d’informatisation

pour les processus internes clés, ces derniers devant si possible reproduire au plus près leurs

pratiques professionnelles en articulant les fonctionnalités de l’informatique de

communication à celles du traitement des données structurées.

Grâce à l’évolution de l’informatique de ces dernières années, le resserrement des relations

entre l’informatique dite communicante et le traitement des données structurées est devenu

possible entrainant l’essor de systèmes d’informations évolués. Cette avancé technologique


Page 27

amène à construire des solutions « sur-mesure » dont la définition, l’extension et l’évolution

au sens large adhèrent aux besoins des utilisateurs pour que les solutions soient de réels

supports à la prise de décision et parties intégrantes de la stratégie.

2.2 Du Système d’Information support à la stratégie…

Originellement, un Système d’Information (SI) est un ensemble de personnes, de

procédures et de ressources qui recueille de l’information, la transforme et la distribue au sein

d’une organisation [O’Brien et Marion, 97]. Par opposition au SI manuel (basé sur

l’utilisation de papier-crayon), les SI modernes s’informatisent, ce qui permet de mieux gérer

non seulement la quantité grandissante de données mais également la complexité croissante

de leurs contextes et de leurs interactions. Nous nous concentrerons ici sur les systèmes

d’informations informatisés, qui utilisent du matériel, des logiciels, des télécommunications et

d’autres techniques d’information pour transformer les ressources en données et en divers

produits informatifs, et plus spécifiquement en produits de gestion, qui orientent les dirigeants

dans leur prise de décision. Dans ce cadre, un système d’information peut se définir comme

un système utilisant plusieurs ressources – le matériel (machines et supports), le logiciel

(programmes et procédures), le personnel (informaticiens et utilisateurs) – afin d’accomplir

des activités d’entrée, de traitement, de sortie, de stockage et de contrôle qui convertissent les

données en produits informatifs [O’Brien et Marion, 97]. Ces activités suivent un cours

chronologique rythmant le cycle de vie des données. Dans un premier temps, les données sont

rassemblées (collecte) et converties en un format acceptable pour le traitement (entrée).

Ensuite, les données sont manipulées (mise à jour) et de nouveau converties mais cette fois en

information (traitement), pour être emmagasinées en vue d’une utilisation ultérieure

(stockage) ou pour les communiquer/diffuser à l’utilisateur final (extraction) selon des

procédures de traitement (contrôle). En pratique, un SI n’est pas un logiciel au sens propre du

terme, mais la jonction d’une interface homogène et d’un orchestrateur (base(s) de données et

des procédures) reliant plusieurs logiciels pour un domaine d’activité (production,

administration…). Pour qu’un logiciel soit intégré dans le SI, il doit répondre aux contraintes

techniques et stratégiques propre au logiciel mais également aux contraintes induites par les

caractéristiques du SI. Selon [Gervais, 06], le SI est généralement composé de trois parties :

- une interface graphique (pour interagir avec l’environnement, essentiellement saisir et

visualiser les informations),

- une base de données (pour stocker, consolider et mettre à disposition les informations

brutes ou résultantes),


Page 28

- un ensemble de transactions (modélisant les procédures et les savoir-faire de

l’entreprise pour modifier et rendre utilisable les informations).

Cet ensemble, nécessaire à l’accomplissement des activités de l’entreprise, est caractérisé

par :

- l’utilisation de nombreuses données,

- des relations complexes entre les structures de données,

- des utilisateurs hétérogènes qui peuvent agir en concurrence,

- des opérations impliquant plusieurs structures de données, utilisant un volume

important de données, tout en préservant l’intégrité des données modifiées,

- une communication adaptée des requêtes des utilisateurs et une gestion des messages

d’erreur en cas d’appel invalide des opérations.

L’efficacité d’un SI est alors basée sur la qualité de la représentation de l’organisation et de la

modélisation des activités, pour une intégration fonctionnelle, afin de constituer non

seulement la mémoire de l’entreprise, mais surtout de générer les informations nécessaires à

l’ensemble des acteurs de l’entreprise à tous les niveaux quelque soit leurs outils de travail

quotidiens pour une intégration informationnelle [Laleau, 02], [Millet et al., 2005]. Les

systèmes d’information jouent un rôle capital dans l’exploitation, la gestion et la réussite

stratégique des entreprises et des autres organisations. Ils constituent aujourd’hui une fonction

vitale au sein des entreprises garantissant l’efficience et l’efficacité de ces dernières, clé de

voûte de l’obtention ou du maintien de leurs avantages face à la concurrence [O’Brien et

Marion, 97]. Ainsi les SI constituent un enjeu stratégique pour les dirigeants des organisations

et prennent une position centrale dans l’entreprise tant d’un point de vue stratégique que

fonctionnel. Leurs rôles sont de permettre l’adaptation de l'entreprise à son environnement

quelque soit les outils métiers mis en place en son sein et d’assister l’ensemble des membres

de l’entreprise dans leurs activités quotidiennes en fournissant à chacun les informations

adéquates. L’opérationnel accèdera à l’ensemble des données nécessaires au traitement d’un

dossier. Le manager pourra suivre les indicateurs utiles au pilotage. Les études stratégiques et

l’analyse stratégique seront alimentées par les statistiques issues du système. L’intérêt majeur

des systèmes d’information est de fournir des stratégies d'échange, de partage et d'intégration

des processus techniques globaux de l’entreprise à partir des éléments issus du savoir faire,

contenus dans différents outils au contour fonctionnel précis, interconnectés ou non, mis en

place dans tout ou partie de l’entreprise. Chaque logiciel connecté au SI doit respecter, dans la

mesure du possible, cette structure et cette philosophie pour ne pas risquer une perte

d’informations qui peuvent être stratégiques. Aujourd’hui les SI ont donc un rôle crucial dans


Page 29

la modification, l’utilisation et la communication de l’information au cœur des entreprises.

Véritable moteur de la production et de la stratégie, les SI sont conçus pour se rapprocher et

s’adapter aux besoins et aux habitudes de l’entreprise voire de l’utilisateur. Cette adaptation

n’est possible que si l’entreprise a une forte volonté d’identifier et de définir l’ensemble de

ses procédures, de ses habitudes et des besoins de chacun des usagers au moment de la

conception du système d’information. Ce n’est que parce que la modélisation de l’entreprise

aura été bien menée que le SI sera bien implémenté et implanté, celui-ci n’étant que le reflet

des données, procédures, processus ou workflows que nous voulons bien mettre à l’intérieur.

2.3 … Au Système d’Information partie intégrante de la stratégie

La mise en place d’une solution logicielle représente une réponse spécifique à un

problème donné. Lorsque ce problème concerne la réalisation d’une tâche dans une activité

assez opérationnelle, la solution logicielle sera souvent « standard » (outil de bureautique,

modeleur 3D, etc.) et ne nécessitera que la formation des personnes ayant à manipuler l’outil

et qu’une légère remise à plat des procédures. Dans le cas de la mise en place de logiciels

d’aide au pilotage et à la gestion des données, la problématique est plus stratégique et

concerne généralement l’entreprise dans son ensemble. Elle est donc à aborder de façon plus

globale. Pour ce faire, il n’existe pas de solutions « standards » d’implémentation et

d’implantation qui permettraient de se dédouaner d’une analyse préalable de l’entreprise et de

ses besoins propres, et d’un paramétrage spécifique de l’outil en fonction de cette analyse. Ce

n’est qu’une fois adaptées au contexte d’utilisation donné, que ces solutions logicielles

deviennent un des éléments support à la stratégie de l’entreprise en s’intégrant dans son

système d’information qui hébergera les données et documents représentant une part de la

connaissance des acteurs de cette dernière [Millet, 08]. La maximisation de cette adaptation

correspond au minimum pour assurer l’utilisabilité de l’outil, définie par la norme ISO 9241-

210 [ISO 9241-210, 08], comme « le degré selon lequel un produit peut être utilisé, par des

utilisateurs identifiés, pour atteindre des buts définis avec efficacité, efficience et satisfaction,

dans un contexte d’utilisation spécifié ». Si le système mis en place ne suit pas au plus près

les processus réels qui ont cours dans l’entreprise, si la sémantique employée par les outils

logiciels ne correspond pas à celle des acteurs de l’entreprise, si les utilisateurs ne retrouvent

pas leurs habitudes de travail, l’outil ne sera pas ou peu utilisé et les données risquent d’être

pauvres, erronées et inexploitables. Le gain pour l’entreprise sera donc nul et les évolutions

du SI seront donc perçues comme négatives et néfastes. Les changements organisationnels

que les dirigeants auront à faire dans l’avenir seront alors plus difficiles à faire accepter aux


Page 30

utilisateurs. Pour éviter ces écueils un tel projet d’implantation d’un nouvel outil devra

s’accompagner d’une démarche spécifique qui permet de structurer méthodiquement et

progressivement une réalité à venir. […] Il sera défini et mis en œuvre pour répondre aux

besoins d'un client […] et impliquera un objectif et des besoins à entreprendre avec des

ressources données comme le définit l’AFNOR [AFNOR X50-105, 94]. Du point de vue de

l’entreprise « cliente », l’implantation d’un outil de gestion se fait, comme de nombreux

systèmes d’informations, en quatre étapes [Botta et al, 01], [Le Duigou, 10] :

- Une phase de définition du projet : le maître d’œuvre définit les besoins, établit le

cahier des charges et l’équipe projet.

- Une phase de sélection de la solution : les éditeurs sont mis à contribution pour

prouver que leur outil répond le mieux aux exigences du maître d’œuvre.

- Une phase d’implémentation : la solution est paramétrée et installée, le personnel est

formé, on applique une stratégie de diffusion (large fonctionnalité, peu d’utilisateurs

puis de plus en plus d’utilisateurs ou peu de fonctionnalités, beaucoup d’utilisateurs

puis de plus en plus de fonctionnalités).

- Une phase d’évolution : la solution est utilisée par tous les utilisateurs, l’entreprise

évolue, de nouveaux besoins sont identifiés.

L’entreprise aura donc nécessairement à définir un objectif, qui peut se décliner en termes de

qualité, de coûts et d’échéance ; des moyens, correspondant à des ressources (des hommes,

des techniques, de l’information,… de l’argent), à décrire l’organisation de ces ressources

dans le cadre du projet et à identifier des conditions et/ou des contraintes limitatives. La

qualité du projet et de son management seront conditionnés par la façon dont seront pris en

compte ces différents éléments et dont leurs interactions seront gérées.

Du point de vue de l’éditeur de la solution logicielle, la spécification et le déploiement d'un

outil de gestion au sein d'une entreprise nécessitent de :

- Analyser les besoins « métier » de l'entreprise,

- Établir un modèle de données et une cartographie des processus cibles,

- Implémenter ces modèles dans les systèmes d'information supports,

- Développer des fonctionnalités et méthodologies spécifiques au « métier » de

l'entreprise,

- Expliquer l'approche « PLM » aux collaborateurs,

- Déployer et reprendre les données

- Assurer la formation et le support.


Page 31

Pour que les solutions logicielles apportent un gain substantiel, leur implantation doit

s’accompagner d’une réflexion sur l’organisation et plus particulièrement sur les processus

internes de l’entreprise. La valeur ajoutée dépend en grande partie de l’alignement entre le

modèle organisationnel de l’entreprise et celui porté par le logiciel [Neubert, 09]. Autrement

dit, les projets de gestion intégré ne sont pas uniquement des projets informatiques, car le

pouvoir structurant de ces logiciels impose bien souvent une réorganisation importante de

l’entreprise ce qui en fait de véritables projets d’intégration [Neubert, 09]. Le rôle de l’éditeur

est donc d’accompagner l’entreprise dans cette réflexion et dans la formalisation, souvent

pour la première fois, d’un référentiel « métier » permettant à chacun de partager une même

vue des objets « métiers » manipulés et des processus parcourus. Cette phase constitue un pré-

requis indispensable à tout déploiement d'un système informatique car elle est censée limiter

les taux de non assimilation et de non utilisation des outils. Ce référentiel se construit par une

analyse fine de l’existant tant d’un point de vue « terrain » (besoins, méthodologie, support,

échéance…) que d’un point de vue informatique (sémantique, interopérabilité,

orchestration…) afin d’être en adéquation avec les besoins propres de l’entreprise. Cette

analyse fine oblige à la définition précise d’objectifs globaux et locaux puis à leur déclinaison

en objectifs spécifiques, mais aussi à la spécification des cadres d’utilisation, de flux à

dématérialiser et enfin d’éléments nécessaires au paramétrage. Au regard de la complexité de

la tâche, la mise en place d’un outil de gestion dans une entreprise doit être comprise comme

un projet stratégique à moyen et long terme qui obligera à un engagement fort de la part de

l’entreprise comme de tous les intervenants.

Les entreprises sont souvent en quête de solutions informatiques clés en main mais

aujourd’hui rares sont les logiciels pouvant répondre exactement et complètement à leurs

vastes besoins. Ainsi, plusieurs outils informatiques sont généralement nécessaires pour

répondre à l’ensemble de leurs exigences. Chacun d’eux répond à un contour fonctionnel

déterminé, basé sur une ou plusieurs fonctions plus ou moins étendues (GED, calcul,

simulation, archivage, processus…). Le projet d’informatisation se doit donc de prendre en

compte non seulement l’implémentation de chacune de ces briques mais surtout

l’orchestration de toutes ces solutions au sein d’un même système d’information global

capable d’assurer la cohérence des flux et des données induites par chacune des briques pour

parvenir à optimiser l’organisation de l’entreprise mais en aucun cas pour la restructurer ou de

la rigidifier. La spécification d’un tel réseau de SI implique d’évoluer du seul paradigme

d’intégration vers un paradigme d’interopération [Fisher, 06] où l’agrégation est le

mécanisme « de construction » des relations entre des SI distribués, et participant au pilotage


Page 32

du Système Entreprise. Ce mécanisme se différencie du mécanisme de composition qui est

assimilé à une vision monolithique d’un SI décomposé en SI structurel tel que préconisé par

MERISE6 [Tardieu et al., 83] [Tardieu et al., 85]. La difficulté majeure rencontrée dans

l’ingénierie de SI distribués, hétérogènes et autonomes, concerne la complexité de leur

assemblage pour former un SI d’entreprise cohérent au regard d’une performance globale à

atteindre [Mayer et Auzelle, 07], [Auzelle et al., 08]. En effet, ces SI étant pour la plupart

considérés comme des composants sur étagères (COTS), leur configuration doit prendre en

compte les propriétés et les fonctionnalités d’un assemblage plus global auquel ils vont

participer tout en conservant les conditions opérationnelles propres à chacun. Nous allons voir

dans la section suivante la problématique liée à la mise en place de solutions logicielles dans

les entreprises en étudiant les verrous contraignants leur implantation.

3 Les verrous de l’implémentation d’un Système d’Information en

entreprise

Toutes les entreprises ont besoin d’échanger des informations et des connaissances,

aussi bien en interne qu’en externe avec leurs partenaires, leurs clients et leurs fournisseurs.

Les systèmes PLM peuvent être une réponse à ce type de problématique. Les principaux

problèmes mis en évidence dans les travaux de Sansonnet [Sansonnet, 04] et par les enquêtes

de terrain [Bissay, 10] sont les suivants :

- L’hétérogénéité organisationnelle ou la difficulté de modélisation des processus et

des données d’entreprise : L'hétérogénéité organisationnelle nait donc du fait que les

éditeurs ont généralement développé leurs outils relativement à des entreprises qui ont

grandies et prospérées chacune séparément des autres et construit leurs propres

organisations indépendamment de celles des autres. Par conséquent, la même tâche

pourra être exécutée de manière différente dans deux entreprises distinctes mais les

outils devront malgré tout s’adapter [Blanc 05]. La modélisation des processus est une

source de problème pour les entreprises. Elles n’ont pas toutes formalisé leurs

processus actuels et ne savent pas forcément quels processus mettre en place. Le lien

entre stratégie, besoins et processus n’est pas présent de manière explicite. De manière

plus pragmatique la modélisation des données et du Système d’Informations (première

étape à la modélisation d’entreprise) est une compétence qui n’est pas présente au sein

de toutes les entreprises. Il est alors impératif d’implanter le modèle de données

adéquat lors de l’installation du logiciel par les consultants sous peine de garder un


Page 33

modèle non adapté. Le modèle de données est indispensable au bon déroulement des

processus souhaités.

- L’hétérogénéité sémantique et le problème d’adéquation des fonctionnalités avec

les besoins : L'hétérogénéité sémantique est liée au fait que les applications qui

interagissent sur la base d’agents ont souvent été définies et construites par des

personnes différentes, en des lieux différents, à des moments différents, dans des buts

différents, avec des vocabulaires différents [Hewitt, 85]. Il ressort de tout cela des

difficultés d’interopérabilité non plus au niveau du transport et des langages de

communication mais au niveau des contenus informationnels eux-mêmes : c’est ce

problème qui est qualifié d’hétérogénéité sémantique [Sansonnet, 04]. Les

fonctionnalités des PLM actuels découlent souvent des besoins de grands donneurs

d’ordres car ils ont été les premiers à travailler avec les éditeurs au développement de

ces outils. Ces problèmes de sémantique se retrouvent donc dans les outils puisqu’ils

sont structurés relativement à leurs organisations et leurs usages qui ne sont pas

forcément transposables à d’autres entreprises. Le travail de mise « en phase » des

besoins d’une entreprise et des fonctionnalités de l’outil est alors parfois complexe.

- Manque d’interopérabilité avec les autres systèmes d’informations : Longtemps,

les systèmes distribués ont été peu interopérables. Aujourd’hui de gros progrès ont été

faits et les architectures de systèmes multi-agents en particulier ont contribué à

diminuer fortement la question du transport de l’information, de manière indépendante

des conditions matérielles c’est-à-dire des machines et/ou des systèmes d’exploitation

sous-jacents [Sansonnet 04]. La principale interopérabilité exigée concerne les

échanges avec le système d’informations interne. Il s’agit principalement de lier le

PLM, la CAO et l’ERP. Dans le cadre d’activité d’entreprise étendue, une

interopérabilité avec les systèmes PLM du réseau d’entreprises partenaires est

également nécessaire [Paviot, 10].

Nous allons nous intéresser dans les sections suivantes à montrer en quoi ces trois types

d’hétérogénéité sont autant de verrous à l’implémentation d’une solution logicielle dans une

entreprise.

3.1 L’organisation polymorphe des entreprises

D’un point de vue organisationnel, les entreprises ont dû prendre des décisions

stratégiques pour rester concurrentielles. Les bouleversements ont suivi une évolution

progressive et souvent cumulative au fil du temps : l’automatisation, l’informatisation, la


Page 34

sous-traitance… La dernière tendance était d’opter pour la délocalisation de tout ou partie de

leur savoir-faire requérant généralement un niveau accru de dématérialisation des documents

et des flux. Ainsi, la réalisation d’une activité nécessite un ou plusieurs acteurs, appartenant à

une ou plusieurs sociétés, sur un ou plusieurs sites, avec un ou plusieurs outils, avec une ou

plusieurs sources d’information pour parvenir à un résultat. Tous les acteurs du cycle de vie

du produit sont donc amenés à travailler à distance avec une équipe « virtuelle » dispersée

nationalement ou internationalement, travaillant sur des créneaux horaires différents et avec

différents outils informatiques. Pourtant, pour garantir la qualité et la durée des processus, les

actions de chacun de ces acteurs sont rarement séquentielles et la formation des acteurs aux

outils (physiques comme méthodologiques) reste trop souvent négligée voire inexistante. Par

conséquent, ces derniers ne doivent pas seulement posséder des compétences dans leur

domaine, mais également en informatique, tant sur des outils bureautiques que sur des

produits métiers plus ou moins variés, et avoir des qualités de collaboration, de

communication et plus largement de management. Cette diversité de compétences imposée

par le système oblige les acteurs à endosser plusieurs rôles dans l’entreprise, en conservant

toutefois une qualité d’expert dans leur domaine de prédilection.

Cette pluridisciplinarité, pouvant être pesante voire stressante pour le personnel, est amplifiée

par un turn-over important du personnel souvent encouragé par les entreprises. Ces dernières

espérant, par ce biais, accroître leur capacité d’innovation, grâce à un œil neuf, mais aussi leur

performance, une nouvelle entité n’étant par définition pas encore ancrée dans une routine

donc moins rétissante aux changements. Par contre d’un point de vue stratégique, quelques

soient les changements, les acteurs et leurs conditions, le produit doit être mis sur le marché

dans des délais de plus en plus courts, à moindre coût et avec un niveau de qualité jugé

acceptable. Or la mobilité du personnel entraine nécessairement un niveau de compétence et

de connaissance fluctuant en fonction des profils. Les acteurs se retrouvent confrontés à la

rétention d’informations, de connaissances mais également de données métiers dans des

carnets personnels. Face à l’ampleur de ces phénomènes, le risque de perdre une compétence

particulière mais surtout une connaissance métier a été évalué comme majeur par les

entreprises ces dernières années. Pour minimiser ces risques, les entreprises ont lancé une

campagne de formalisation des process de fabrication. Ces « procédures » ont longtemps

évoluées au cours du temps sans un suivi rigoureux, ni de validation. Chacun ajoutant des

étapes mal explicitées ou pas détaillées, des compléments d’information, voire des correctifs.

Malgré tout, ces procédures décrivaient rarement unitairement les actions à réaliser, elles

correspondaient plus souvent à des check-lists et des mémos qu’à de véritable mode


Page 35

opératoire. Autrement dit, les nouveaux arrivants, internes ou externes, devaient

nécessairement passer par une formation pour parvenir à un niveau suffisant de transmission

de compétence et de connaissance complémentaires à ces « procédures ». Cette période, selon

les individus et la technicité du poste, pouvait s’étaler dans le temps tout en sachant que la

transmission ne pouvait pas être totale. Malgré cette perte de performance, les entreprises

étaient conscientes de la nécessité de cette période de transition pour parvenir à un niveau de

qualité similaire. Force est de constater que la formalisation, généralement mal cadrée, ne

parvenait pas à lever le verrou lié au postulat ethnique que la transmission de connaissances et

de compétences n’est pas naturelle dans le cadre professionnel en France. Les entreprises

tentent alors de freiner cette perte de connaissance et d’efficacité via des outils de

capitalisation et des formations continues internes.

Cette prise de conscience et les moyens mis en œuvre restent bien souvent insuffisants face à

cette mutation des rôles des acteurs et de la définition d’une activité. En effet, si les acteurs

deviennent multi-compétences et accumulent des connaissances, bien souvent, ils ont

tendance à se sentir incompétent dans tous les domaines. Ce sentiment à des conséquences

directes sur la qualité de leur travail et donc du produit. Tout ceci induit inévitablement un

manque de confiance en soi, des difficultés à anticiper et prendre les décisions dans les temps.

Or, les bases de connaissances capitalisées mises en places actuellement ne permettent pas de

remplacer l’expérience des années face aux situations critiques rencontrées sur le terrain. Seul

l’échange et la communication - où la transmission ne se concentre pas uniquement sur un

simple principe de « constat – solution » mais apporte également le contexte, la démarche

d’analyse qui a permis d’élaborer la solution et les moyens préventifs mis en place -

pourraient limiter ces problèmes. Mais les changements organisationnels (de rôles, de statuts,

de hiérarchies…) génèrent des tensions et des conflits d’intérêt souvent sous estimés par les

entreprises, ce qui défavorisent ces échanges pourtant essentiels. Autrement dit, les

compétences, les connaissances et la collaboration sont indissociables pour parvenir à limiter

les pertes tant de performance que d’efficacité d’un point de vue stratégique pour l’entreprise.

Pour pallier à ces problématiques une activité ne peut donc plus être perçue comme une action

individuelle mais comme une coopération (sous entendu collective). Ainsi la qualité du

produit est régie par le professionnalisme de l’équipe en charge et le processus mis en œuvre

mais surtout par la qualité de l’échange d’informations et la collaboration non seulement entre

les personnes (de l’équipe projet et en dehors) mais également entre les outils utilisés tout au

long du projet [Ostergaard et Summers, 03]. L’impact de cette nouvelle perception d’une

activité conditionne les méthodes de travail du personnel ainsi que les différentes phases du


Page 36

cycle de vie d’un produit/projet (l’étude, la conception, la production…). Or aujourd’hui, ces

différents processus doivent non seulement respecter les contraintes techniques classiques et

organisationnelles actuelles, mais également les nouvelles contraintes imposées aux

entreprises. Ainsi la mode des « entreprises éco-citoyennes » intégrant les contraintes

environnementales, a obligé les entreprises à se soumettre aux réglementations accrues

impliquant de maîtriser la qualité et d’assurer la sécurité des produits, et des Hommes. En

effet, aujourd’hui, il n’est pas concevable de mettre un produit sur le marché sans pouvoir

assurer sa qualité, sa traçabilité et la sécurité (des sites de production et de la signalétique du

produit). Ce nouvel aspect réglementaire dans les entreprises fut vecteur d’une période de

formalisation, de cartographie et de documentation de l’entreprise pour obtenir les

certifications qualités souvent perçues comme gage de leur réussite. Les dysfonctionnements

majeurs des méthodes utilisées de formalisation se situaient au niveau de l’abondance de la

documentation, du caractère fastidieux de sa mise à jour, de la rigidification des processus liés

à la production des documentations et donc inadéquates aux réalités changeantes du terrain et

finalement de l’utilisation et de la mise en œuvre de ces outils. Aujourd’hui, cette période est

révolue. Non pas que les entreprises n’aient plus besoin d’être certifiées, bien au contraire,

mais la méthodologie et les moyens mis en œuvre actuellement doivent permettre d’obtenir

cette certification mais surtout de la conserver à moindre effort. Cette évolution a pour

objectif non pas de sur-documenter comme dans le passé, mais plutôt d’identifier et de suivre

les différents points critiques tout au long du cycle de vie de façon rationnelle et

fonctionnelle. Les axes majeurs sont orientés vers l’utilisation et l’évolutivité de la

documentation et des processus en fonction des contraintes du terrain, vers l’étude des

impacts d’une modification ou d’un problème, mais également le suivi des points critiques.

Encore aujourd’hui, beaucoup d’entreprises, cherchant à maximiser leur ROI (Retour sur

Investissement) à moindre frais et dans des délais de plus en plus courts, n’ont pas pris en

considération l’importance de revoir leur système qualité et sécurité. Bien souvent, les

performances et l’efficacité de ces entreprises sont finalement pénalisées par ces contraintes

réglementaires. Leur plan d’assurance qualité représente un frein à leurs évolutions

potentielles, à l’innovation mais surtout au bon déroulement des processus.

Ces différentes contraintes cumulatives et croissantes sont essentiellement dues au marché

mondial et au niveau d’exigence croissant des clients. En effet, face à la concurrence de plus

en plus forte, la durée du cycle de vie d’un produit a fortement diminuée ainsi que la durée de

présence de ce dernier sur le marché. Le « time-to-market » doit être minimisé et la rentabilité

doit être assurée durant la période d’exploitation pour maximiser les profits. De plus, pour


Page 37

répondre à cette ère de la consommation à outrance, le taux de renouvellement des produits

doit être important, ce qui se traduit d’un point de vue industriel par une explosion du nombre

de projets et un nombre exponentiel des références produits. Or dans l’organisation et la

structuration des entreprises, les interactions et les implications croisées non seulement entre

les projets/produits mais également entre les hommes et entre les données sont inévitables et

complexifient les flux. Toutes les difficultés énoncées précédemment étant démultipliées

également par une priorisation des actions à mener souvent arbitraire et se faisant au fil de

l’eau par les acteurs dépourvus de tout ou partie de la vision globale et transverse des

produits/projets, voire de l’entreprise.

Cette situation est antinomique à la profitabilité d’une entreprise, car progressivement son

fonctionnement se sclérose, des sous-entités anarchiques se forment et compromettent sa

stratégie. Or ces différents mauvais fonctionnements voir dysfonctionnements dans certains

cas, n’étaient pas identifiés, volontairement ou non, voire identifiables par les managers et les

conséquences n’étaient pas mesurées ou mesurables. Compte tenu de la complexité et quantité

croissantes des projets, pour autant nécessaires pour assurer la pérennité de l’entreprise, le

pilotage est devenu un axe stratégique pour les entreprises.

Initialement, les entreprises se contentaient de se fixer une cible « textuelle » à moyen terme.

Poussées par les financeurs, ces cibles se sont transformées en objectifs chiffrés à moyen et

long terme. Progressivement, ces derniers ont été déclinés en objectifs chiffrés aux dirigeants

des services. L’évaluation portait généralement sur les critères traditionnels : le coût, la

qualité et les délais [Porter, 86], [Hazebroucq, 99]. En l’absence d’outils fonctionnels et par

manque de méthode, ce pré-pilotage n’était en fin de compte qu’un simple suivi a posteriori

basé sur différents récapitulatifs (ou reporting : rapport, tableau de bord, compte rendu…)

présents dans l’entreprise, réalisés périodiquement parfois associés, manuellement, à des

éléments prévisionnels. Aujourd’hui pour permettre leur développement et assoir leur position

sur le marché, les entreprises ont besoin d’entrer dans un mode de pilotage en temps réel,

vecteur d’anticipation, d’innovation et d’amélioration de la pertinence et de la qualité du

pilotage.

Après cette prise de conscience de l’impact préjudiciable des dysfonctionnements de leur

organisation et de leurs procédures, la mise en place d’indicateurs de performances devient

une nécessité. Rapidement, les entreprises se sont confrontées aux problématiques de

définition de ces indicateurs et des moyens de les mesurer et de les suivre. En effet, par

définition, un système de pilotage est l’agrégation d’indicateurs [Ducq, 99], [Ducq, 05] qui

permet de dégager l’information nécessaire à l’optimisation et à la prise de décision en amont


Page 38

de l’action. Suite à l’essor de l’implémentation d’outils informatiques au sein des différents

services, les entreprises qui manquaient précédemment de données pour permettre ce pilotage,

se heurtent à présent à l’abondance d’informations non ordonnées, ni consolidées, ni reliées

entre elles issues de la multiplication des applications dédiées à l’entreprise, au site, à

l’équipe, à une activité... Un traitement plus ou moins complexes doit être réalisé pour

parvenir à synthétiser et mettre en valeur les chiffres clés pour l’entreprise et les décliner

ensuite en indicateurs clés de performance (KPI) sur une échelle de temps plus faible (la

semaine, le mois, le trimestre…) au niveau des services, des équipes, des lignes de

production, d’un produit/projet… selon les structures, la criticité et les ambitions de

l’entreprise. Cette complexité, nécessitant une étude longue et coûteuse, décourage souvent

les entreprises qui ne mettent alors en place non pas un système décisionnel centralisé mais un

système de pilotage partiel de leurs activités.

3.2 La vision transverse : hétérogénéité organisationnelle

La réussite d’un projet informatique passe par la clarté de la vision globale du projet

au sein de l’entreprise et la qualité de transmission de ces données par les deux parties en

présence lors de la conception de l’application : le chef de projet côté entreprise et le chef de

projet côté éditeur. Pour parvenir à une solution logicielle adéquate pour l’entreprise, les

objectifs doivent être clairement définis tant d’un point de vue stratégique, champ

d’application, fonctionnel que technique. Ces éléments définis en partie en avant-projet, ne

sont pas forcément bien appréhendés par les chefs de projets découvrant le projet au moment

du lancement. La bonne compréhension de la portée du projet permet d’identifier les

différents enjeux et contraintes potentielles sous-jacentes. Une maturité suffisamment avancée

du projet non seulement au sein de l’entreprise mais surtout pour les différents acteurs du

processus est nécessaire. Cette phase est évidement basée sur l’échange et la communication

entre le personnel de l’entreprise, entre le personnel de l’éditeur et entre les chefs de projet.

Durant cette phase l’éditeur doit être attentif et à l’écoute de toutes les informations pouvant

lui permettre d’acquérir au plus vite une vision transverse du projet et estimer la criticité du

besoin afin de proposer un planning approprié prenant en compte la complexité du projet dans

son ensemble mais également les solutions adéquates lors de la conception pour une

exploitation optimum à long terme de l’application.


Page 39

3.3 La collaboration : hétérogénéité sémantique

Au travers les premiers échanges entre les deux chefs de projet, une sémantique

commune se met en place, plus ou moins naturellement. Cette brique élémentaire de la

communication est un élément essentiel. Initialement, l’entreprise en recherche d’outil pour

améliorer son organisation et la rendre plus performante, est souvent néophyte dans le

domaine informatique et inversement, l’éditeur l’est dans la compréhension du

fonctionnement de l’entreprise voire du métier de cette dernière. La mise en place d’une

sémantique commune est cruciale pour assurer le bon déroulement des différentes phases du

projet. Elle permet de limiter les mésententes et les désaccords basés souvent sur une

mécompréhension mutuelle sur des aspects fonctionnels et techniques mal maitrisés ou

méconnus par l’un des deux intervenants. Dans le cas contraire, les conséquences en terme

temporel et financier sont inéluctables et peuvent faire péricliter l’ensemble du projet. Pendant

toute la durée du projet, si les deux chefs de projet mettent en place un langage commun

formalisé, auquel ils peuvent se référer en cas de doute, les anicroches pourront être évitées et

la dynamique conservée. Ce lexique permet de faciliter la compréhension, les échanges, les

compromis pour parvenir à une solution informatique adaptée au besoin. Cette étape est

d’autant plus essentielle que le niveau de personnalisation est conséquent. En effet, le degré

de personnalisation est un élément à considérer dès le début de l’étude, car il influencera la

conception, les fonctionnalités, les développements, les tests et le déploiement. Initialement,

ce dernier nécessitera une compréhension mutuelle d’autant plus fine pour concilier les

aspects techniques et fonctionnels, entre l’entreprise et l’intégrateur/éditeur du logiciel afin de

déboucher sur la définition de ses spécificités. Cette étape vient en sus de la définition même

du système. Ce surplus de travail se répercutera dans chacune des étapes et démultipliera

d’autant la durée de chacune des étapes du processus. Ainsi cette étape, souvent galvaudée,

favorisera et améliorera d’autant la collaboration entre les différents acteurs.

La réussite de ce type de projet se base en grande partie sur la qualité de la collaboration entre

les deux chefs de projet. La conséquence est directe sur toutes les phases du projet, mais plus

particulièrement lors de la spécification et la modélisation. En effet si la collaboration est

performante, le nombre d’itérations pour parvenir à un compromis technique et fonctionnel

entre les deux parties sur un des points sensibles voire critiques du projet, qu’il soit standard

ou spécifique à l’entreprise, sera moindre. Il ne sera pas nécessaire de modéliser toutes les

décisions unitairement pour s’assurer de la bonne compréhension mutuelle. Le gain de temps

peut se révéler très important en fonction de l’envergure, de la complexité et de la spécificité


Page 40

du projet. La pertinence de ces deux étapes du projet est également conditionnée par le

premier facteur clé évoqué, la vision globale du projet. En effet, plus la définition globale du

projet est précise, plus les chefs de projets pourront anticiper les spécifications mais

également les besoins sous-entendus et/ou futurs dans la conception du système propre à

l’entreprise. Cette prise en compte au plus tôt des contraintes permet à long terme un gain de

temps et d’argent important tant pour l’entreprise que pour l’éditeur. La solution pourra être

jugée comme un outil stratégique, perspicace et adaptée au besoin. Pour parvenir à ce résultat,

les deux critères, qualité de la collaboration et vision globale, doivent nécessairement être

réunis.

3.4 Une implémentation intégrée pour une meilleure interopérabilité

Outre l’aspect technologique, l’interopérabilité est également un point clé de la

conception et doit être prise en compte également au plus tôt dans le projet afin d’uniformiser

la sémantique employée au sein du système d’information ce qui facilitera l’interaction a

priori ou a posteriori entre les différents logiciels [Paviot, 10] Ces éléments sont cruciaux

pour pérenniser l’implémentation, l’utilisation et l’intérêt tant au niveau individuel que

stratégique du logiciel. C’est pourquoi la vision transverse de la stratégie de l’entreprise doit

être identifiée au préalable pour anticiper au maximum les besoins futurs. En effet, quel que

soit le besoin initial, la dématérialisation de flux a un caractère stratégique à court terme pour

accroître la performance et l’efficacité des activités, mais également à long terme pour

enrichir le système d’information et permettre une meilleure visibilité sur l’ensemble des

activités et leur pilotage. Si ces aspects sont prédéfinis dans le projet initial, la portée et

l’intérêt du logiciel en seront d’autant plus reconnus et valorisés a posteriori. L’un des

problèmes sous-jacent de cette dématérialisation est que souvent l’entreprise n’a pas de vision

agrégée et consolidée des informations et certaines opérations ou des éléments dématérialisés

sont saisis dans l’outil lors d’opérations manuelles avec des risques d’erreur et des indicateurs

peuvent être non calculés car trop fastidieux ou s’appuyant sur des données manquantes ou

erronées. Pour lever cette contrainte, peu de solutions dite techniques sont envisageables : soit

le système d’information a été pensé dès sa création pour respecter ses contraintes, soit il faut

agrémenter le système d’information avec une solution centralisatrice des informations avec

toutes les problématiques liées à la redondance et la synchronisation des informations, soit

permettre la visualisation centralisée des rapports « équivalents » (sur la même échelle de

temps, sur les données liées…) dans une même fenêtre. La première solution n’est possible

que lors de la mise en place de l’ensemble d’un système d’information et répond donc qu’à


Page 41

une faible proportion des entreprises. La seconde est très coûteuse de part sa spécificité pour

chaque cas et se révèle souvent difficile à maintenir. Malgré tout cette solution peut se

positionner comme une solution intermédiaire intéressante de part les avancées

technologiques qui permettent aujourd’hui à des systèmes de « portail » de se connecter à

différents logiciels informatiques en standard. Les difficultés qui apparaissent alors sont liées

à la rigidité des outils (pas d’évolution facile, pas beaucoup adaptables) et à la nécessité, dans

des cas de plus en plus nombreux, de travailler sur des portails d’entreprise déjà existants chez

les clients.

4 Synthèse

L’évolution des besoins, des contraintes réglementaires et sociales ont poussé les

entreprises à réagir et à s’adapter à leur environnement pour continuer à exister sur le marché

et pérenniser durablement leur activité. Pour répondre à leurs nouveaux objectifs, les

industriels ont généralement optés pour des modifications d’ordre organisationnelles et

structurelles. Grâce aux avancées technologiques et à l’utilisabilité des outils dans un cadre

industriel, l’axe « matériel » a connu un essor important et a souvent été perçu comme « la »

solution « simple et rapide » à mettre en place pour accroître la performance de l’entreprise.

Face à la mondialisation et à la concurrence grandissante, la quête de l’optimisation absolue

reste le nerf de la guerre pour privilégier toujours d’avantage l’innovation à la production. A

force de considérer que l’optimisation locale engendre l’optimisation globale, les entreprises

ont mis en place bon nombre d’outils informatiques pour répondre à des besoins locaux, sans

prendre en considération la cohérence des informations stockées dans chacun d’eux. Or avec

l’émergence des normes qualités et les réglementations de plus en plus strictes, la traçabilité

et la responsabilisation sont devenues des critères primordiaux pour subsister sur le marché

mondial. Autrement dit, les entreprises ont dû rapidement mettre en place des solutions de

suivi et de stockage des informations liées aux produits/projets et à leur environnement. Au

vue de la croissance exponentielle du nombre de produit/projet à gérer, pour répondre aux

besoins accrus de nouveauté émis par la clientèle, les industriels se sont d’autant plus tournés

vers la dématérialisation et l’informatisation de ces données pour réduire les coûts engendrés

par ces nouvelles contraintes.

Le recueil mais surtout la qualité des informations deviennent des enjeux stratégiques. De

nombreuses informations liées au produit/projet sont déjà traitées dans les divers outils

informatiques mis en place localement. Mais par manque de cohérence, toutes ces données

doivent subir un traitement important pour les uniformiser et les fédérer avant l’archivage.


Page 42

Une stratégie d’uniformisation informatique est alors nécessaire : les Systèmes d’Information.

Ce concept implique que tous les outils doivent respecter la même philosophie et les mêmes

règles (de conception, d’implémentation…) pour favoriser l’échange, le partage et

l’intégration de processus entre les outils. Cette structuration commune garantira la qualité

des données en évitant les ressaisies et les pertes d’informations, ce qui permet également un

gain d’efficacité pour l’entreprise.

Pour maximiser leurs profits et tracer l’ensemble des actions réalisées à moindre coût, les

industriels cherchent des solutions informatiques leurs permettant de les aider à piloter et à

gérer l’ensemble des activités liées aux produits/projets. Pour cela deux types de logiciels de

gestion proposés sur le marché provoquent un vif intérêt de la part des responsables

informatiques : les ERP (Enterprise Ressource Planning), pour la gestion des ressources et des

plannings, et le PLM (Product Life Management) pour la gestion des données techniques.

L’un comme l’autre promettent de conserver la flexibilité et l’adaptabilité de l’entreprise

étendue tout en uniformisant, fédérant, dynamisant et optimisant leur processus de gestion

(une présentation générale et une comparaison des outils les outils ERP et PLM est fournie en

Annexe 1). Or les industriels sous-estiment bien souvent l’impact de l’implémentation de tels

outils au sein de leur société. En effet, pour garantir la qualité et la circulation des

informations entre les différents acteurs du projet, la modélisation du logiciel doit être alignée

sur le modèle de fonctionnement de l’entreprise et du projet en question. Une réflexion et une

remise en question de ces derniers doit donc être opéré avant la mise en place de la solution

informatique pour ne pas risquer d’omettre certaines possibilités, faire émerger les bonnes

pratiques capitalisées et adapter au plus près l’outil aux habitudes réelles de fonctionnement.

Dans le cas contraire, le risque majeur est de rigidifier la structure et rendre inutilisable la

solution. Une perte d’informations et de traçabilité serait alors inévitable. Le déploiement

d’un logiciel de gestion ne se résume pas uniquement à un projet informatique devant

s’intégrer dans le système d’information en place mais à un projet d’intégration d’envergure

organisationnelle et technique.

Au regard du contexte, des difficultés rencontrées par les industriels et des caractéristiques

des solutions présentes sur le marché, il apparait que pour que le gain escompté soit probant,

il est nécessaire d’une part que l’entreprise soit consciente de l’impact structurant de ce type

de projet et d’autre part que les éditeurs et/ou intégrateurs proposent une méthodologie les

aidant dans leurs démarches de réflexion et qu’ils permettent un fort degré de flexibilité dans

l’outil et dans son implémentation. L’enjeu de ce travail de recherche est d’améliorer la


Page 43

méthodologie de déploiement, voir les solutions proposées par LASCOM, éditeur de solutions

de PLM.

Chapitre 2 Déploiement d’une solution PLM

Page 45

Chapitre 2

Méthodologie de déploiement d’une solution PLM

1 Introduction

Longtemps réservées aux secteurs de pointe, essentiellement dans l’aéronautique, les

solutions logicielles PLM se démocratisent et font leur entrée dans tous les secteurs d’activité

industrielle. Cet essor alimente la réflexion tant des éditeurs d’un point de vue fonctionnel

(« ce que l’outil est capable de faire ») que des intégrateurs du point de vue de la

méthodologie de déploiement (« comment mettre en place l’outil chez le client ») pour

conserver leurs avantages concurrentiels sur le marché. La mise en place d’un logiciel au

cœur du système d’information est un projet stratégique tant pour l’entreprise, pour accroître

ses performances, que pour l’éditeur pour sa pérennité. Cette décision sous-entend pour les

industriels que l’investissement consentit doit rendre leur entreprise plus performante. De leur

point de vue, la notion de performance possède une double nature. D’une part la performance

sera évaluée sur leur capacité à mettre en place des supports informatiques pour répondre aux

contraintes (réglementaires, qualités, géographique, sous-traitance, partenariat…) sans qu’il y

ait de fortes perturbations dans le fonctionnement de l’entreprise. D’autre part, les attentes

relatives à l’outil informatique et plus généralement aux nouvelles technologies concernent

l’accélération des processus industriels afin de concevoir, produire, mettre sur le marché et

vendre de plus en plus rapidement. Plus généralement, l’intérêt d’un tel investissement est de

faire « mieux » que le système existant selon le triptyque coût/délais/qualité pour le produit

réalisé. L’objectif financier est réduit à améliorer le ratio coût, délais. Tandis que l’objectif

stratégique se concentre sur une meilleure maîtrise des éléments liés au produit/projet au sein

de son environnement et ce durant l’ensemble de son cycle de vie (éléments temporels,

« qualité » et volumes de données manipulés, etc.). Pour répondre à cet objectif stratégique de

maîtrise du cycle de vie du produit, l’éditeur et/ou intégrateur doit atteindre trois objectifs

techniques :

- informatiser les données/documents,

- conceptualiser les processus,

- apporter des éléments de pilotage de l’ensemble.

Ceci l’oblige à ce que l’implémentation de son outil soit efficace et que son déploiement

corresponde réellement et pleinement aux attentes fonctionnelles du client pour qu’il soit


Page 46

accepté par les utilisateurs et s’intègre parfaitement dans l’organisation et dans le système

informatique (en étant livré dans les délais et en respectant le budget prévu). La

problématique de l’éditeur/intégrateur peut donc se résumer ainsi : Comment offrir une

solution visiblement plus performante, intégrant l’ensemble des activités impactant le

produit et élargissant le champ fonctionnel pour satisfaire l’ensemble des utilisateurs, sans

qu’elle ait un coût et un délai de mise en place prohibitifs ? Pour ce faire, les aspects

fonctionnels et méthodologiques doivent être en phase l’un avec l’autre mais aussi et

surtout avec le marché et les attentes des clients. Afin d’apporter une réponse adéquate à

ces objectifs et à tous les niveaux hiérarchiques de l’entreprise, il est nécessaire de

modéliser toutes les activités impactant le produit constituant ainsi l’environnement le

plus complet possible de conception dans le logiciel support au PLM.

Nous verrons dans ce chapitre que le problème majeur réside souvent dans le fait que

l’entreprise « cliente » et l’éditeur de l’offre logicielle ont du mal à concilier leurs objectifs

communs. En effet, face aux avancées technologiques, les entreprises se sont fourvoyées

quant aux capacités réelles des outils. Elles percevaient les logiciels informatiques comme des

solutions miracles à leurs nouvelles problématiques à l’instar de l’automatisation des lignes de

production par exemple. Idéalement les entreprises souhaitent un logiciel clé en main

(standard), pour minimiser les coûts et les délais de déploiement, mais avec toutes les

caractéristiques propres à leurs métiers et spécifiques à l’organisation de l’entreprise. Ceci

pour limiter le temps de prise en main de l’outil par l’ensemble des acteurs et maximiser un

retour sur investissement rapide. Cette posture peut être issue non seulement de la

communication qui est faite sur le caractère flexible et paramétrable des outils informatiques

en général, mais également de la transposition individuelle de la facilité d’installation des

logiciels tel que ceux de bureautiques. Or l’éditeur ne peut satisfaire à cette attente de part

l’ampleur et l’impact du déploiement d’un outil de gestion des données et des flux, qui ne

sont pas comparables d’un point de vue analyse, conception et déploiement à ceux d’un

logiciel bureautique. La solution logicielle n’étant souvent que peu modulable, il est important

de bien cerner les éléments qui la structurent pour ainsi cerner en quoi cette structure peut être

un facteur contraignant pour le client et pour l’éditeur lors de la mise en place de la solution.

Nous allons dans un premier temps décrire les composants « classiques » (ou briques

fonctionnelles) d’une solution PLM pour identifier les besoins en méthodologie de

déploiement et en particulier en méthodologie de modélisation. Puis nous analyserons en quoi


Page 47

ces besoins peuvent être source de difficultés et nous proposerons des pistes de réflexion pour

lever ces difficultés, pistes qui seront étudiées dans les chapitres suivants.

2 Les briques fonctionnelles

Pour répondre aux besoins de gestion de la conception produit, en termes de

performance et de conception, le marché regorge de nombreuses solutions logicielles telles

que Windchill de PTC, Agile d’Oracle, TeamCenter de Siemens, ENOVIA de Dassault,

LASCOM PLM de LASCOM… Chacune de ces solutions possèdent ses particularités, ses

atouts et ses points faibles mais toutes sont structurées autour de 4 briques fonctionnelles

identiques.

2.1.1 La gestion électronique documentaire : la mémoire de l’entreprise

Dans l’organisation des entreprises, il apparait clairement deux grandes contraintes :

un turn-over rapide, favorisant certes l’innovation au sein de l’entreprise mais également la

perte de savoirs, et des normes de plus en plus strictes à respecter selon les domaines

d’activité, nécessitant le respect et la traçabilité de tous les documents utilisés. Ce contexte

propulse peu à peu la capitalisation des connaissances au cœur des entreprises pour éviter la

perte d’informations cruciales. Longtemps, le coût de ce type de projet représentait un frein

pour les entreprises au regard de l’investissement essentiellement temporel pour concevoir,

alimenter et mettre à jour ce type de base. Mais aujourd’hui, les entreprises doivent faire face

aux modifications significatives de leur organisation, à la concurrence mondiale toujours plus

importante quelque soit le marché et à la course effrénée à l’innovation. Il leur faut produire

des nouveautés, en plus grand nombre dans un temps de plus en plus restreint. Le choix de la

capitalisation de l’information sous format électronique apparait comme la clé de voute de la

prospérité des entreprises pour pérenniser leur place sur le marché en conservant et réutilisant

leurs savoirs sur l’ensemble de leurs produits/projets.

L’implémentation d’une gestion documentaire répond en grande partie à ce besoin. Elle a

pour objectif de créer un référentiel unique avec une structuration des documents et de leur

classement. Les intérêts de la mise en place d’une telle base sont multiples pour les

entreprises. En effet, cette dernière constitue la mémoire de l’entreprise et facilite de surcroit

la recherche de documentation, l’échange des savoirs-faires et des expériences, la traçabilité

et l’intégration de nouveaux arrivants. Ainsi le module de GED est un outil pertinent aux

regards de ces éléments en structurant les informations selon leur nature grâce à la définition

d’un modèle de données adapté. Il offre une réponse pour respecter les critères de plus en plus


Page 48

contraignants de la législation mais surtout pour constituer une véritable base de connaissance

facilitant la capitalisation mais également la traçabilité des données, des produits, des projets

grâce au suivi de version. L’application assure ainsi l’unicité des données – tous les

utilisateurs ont accès à la même « vraie » information –, la recherche – tous les utilisateurs ont

accès rapidement à l’information – et l’archivage des données – tous les utilisateurs peuvent

se référer aux informations capitalisées. Pour répondre au besoin d’accessibilité et de

traçabilité des informations, la majeure partie des outils sur le marché intègre cette première

brique de gestion documentaire connectée intrinsèquement au moteur de la solution comme

l’illustre la Figure 1.

Figure 1. La brique fonctionnelle « Gestion des Configurations »

2.1.2 La gestion de configuration : la représentation réelle d’un produit/projet

Les industriels proposent des gammes de produits de plus en plus diversifiées, afin de

répondre aux exigences des clients en proposant régulièrement de nouveaux produits avec un

« time to market » minimisé. La durée de vie globale des produits se trouvant réduite, le cycle

de conception a du être optimisé. Pour répondre à cette contrainte, les entreprises ont mis en

place des équipes virtuelles, autrement dit les différents intervenants ne font pas forcément

parties du même service, de la même filiale voire de la même entreprise. Il est alors essentiel

non seulement que tout le monde travaille sur la même version des documents, mais surtout

que chacun est la même vision du produit adaptée à son métier. De plus, la coexistence de

nombreuses variantes pour chacun des produits impose un suivi et une traçabilité fine pour

faciliter la maintenance et la réutilisation des connaissances acquises tout au long des projets.

Autrement dit, les entreprises ne cherchent pas seulement à gérer leurs documentations mais

l’ensemble de leurs gammes de produits tout au long de leur cycle de vie. Le besoin réside

donc dans la gestion des documents mais aussi des liens qui existent entre ces derniers. Ce


Page 49

sont tant ces liens que les documents qui constituent et restituent la complexité du produit

dans la base de connaissance à travers soit sa nomenclature, sa recette, son dossier

d’exécution…

Dans la littérature cette arborescence, ou configuration, est désignée, selon la norme ISO

[ISO 10007, 03], comme l’ensemble des caractéristiques fonctionnelles et physiques d’un

produit définies par des documents techniques et obtenues par le produit. On parle par

exemples, de configuration de référence, de configuration applicable, de configuration

documentaire, de configuration réalisée selon les étapes atteintes dans les projets, etc. La

gestion de configuration consiste à gérer les informations qui décrivent la structure du produit,

en particulier sa décomposition en sous-ensembles et pièces élémentaires. Elle permet de

superviser la totalité du cycle de vie d'un produit, elle comporte l'identification des

composants qui doivent être contrôlés (éléments de configuration), le contrôle des évolutions

apportées à ces éléments (y compris la documentation), ainsi que des fonctions et des

mécanismes permettant d'auditer et de contrôler toutes les actions effectuées. La gestion de la

configuration permet donc de formaliser et de présenter de manière claire et complète la

configuration du produit à un instant donné et l’état d’accomplissement des exigences

physiques et fonctionnelles.

Selon le domaine d’activité et selon les entreprises, la définition comme la constitution d’un

document, divergent. En effet, la structure des documents (le nombre de propriétés propres et

provenant d’autres items par exemple) et les propriétés des liens entre ces derniers atteignent

différents degrés de complexité. Ainsi la difficulté est issue : soit de la quantité

d’informations importante au sein du document, soit de la présence obligatoire de fichier

spécifique associé à un ou plusieurs documents, soit de la précision de la structure d’un

produit basé sur de nombreux documents (nomenclature, recette,…)… Ces diverses

perceptions d’un document engendrent de multiples niveaux de complexité lors de la création

d’une GED et du suivi des documents. Le plus ardu reste la gestion de cette arborescence

hiérarchisée de documents communs à différents dossiers (c’est le cas d’une nomenclature, ou

d’une liste d’ingrédients…). En effet, le suivi, l’impact des modifications sur les différents

documents, la mise à jour de ce type de structure sont souvent cruciales pour les entreprises.

Si les caractéristiques d’un élément sont modifiées, il est essentiel que l’utilisateur identifie

les impacts sur l’ensemble de la base de son action, et qu’il puisse choisir de modifier ou pas

tous les produits/projets utilisant cet élément.

Pour résoudre ces contraintes liées aux structures complexes, la gestion de configuration est

une composante essentielle. Cet outil entièrement intégré à la solution permet de créer,


Page 50

modifier et supprimer une configuration. Son utilisation est facilitée grâce à une interface

dédiée, accessible dans un onglet présent sur les documents concernés. Il offre la possibilité

de créer des configurations plus ou moins complexes, avec de nombreux niveaux,

représentant la décomposition réelle du produit. Cette décomposition est souvent complétée

par des liens d’attributs, de valeurs, de types. Ces informations supplémentaires contribuent à

accroître la lisibilité de l’arborescence de la configuration, en faisant apparaitre directement

ces informations, sans nécessairement naviguer vers le document en question. L’utilisateur

dispose ainsi d’une complémentarité de l’information qui est à la fois portée par les

documents mais aussi par les liens qui les relient – par exemple une date de validité, une

quantité... La fonctionnalité native d’analyse d’impact met en valeur très rapidement, à partir

d’un onglet spécifique, l’utilisation d’un même document par d’autres

dossiers/produits/projets dans l’ensemble de la base avant toute modification ou suppression.

Ainsi pour faciliter la modélisation de la structure plus ou moins complexe des

produits/projets et gérer non seulement l’évolution des documents de référence pour le

produit/projet mais aussi l’évolution dans son ensemble du produit/projet tout au long du

cycle de vie, une seconde brique de gestion de configuration connectée au moteur de la

solution est intégrée et utilise les données contenues dans la première brique de gestion

documentaire comme l’illustre la Figure 2.

Figure 2. La brique fonctionnelle « Gestion Documentaire »

2.1.3 Les processus : le dynamisme de l’entreprise

Dans l’ère de la dématérialisation, pour des raisons de coût, de respect de

l’environnement, de validité des informations pour l’ensemble de l’entreprise étendu, les

entreprises veulent non seulement accélérer la mise à disposition des informations « vraies »,


Page 51

de suivre l‘évolution de leurs produit/projet, mais ils souhaitent surtout minimiser le « time to

market ». Depuis longtemps, des procédures existent pour valider les différentes étapes

cruciales identifiées grâce à leurs expériences mais aussi obligatoires par la réglementation en

vigueur. La mise à jour de toutes ces procédures est généralement fastidieuse si l’on souhaite

conserver une cohérence entre les produits/projets, et favoriser la standardisation et la mise en

place des bonnes pratiques uniformément sur l’ensemble de la production. Comme à l’époque

de l’automatisation des chaines de production, les entreprises, de par le déploiement d’un

outil de gestion, informatisent ces procédures et en profitent pour automatiser certaines étapes

ne nécessitant pas une analyse humaine. Ce qui leur permet de conserver leur rigueur, leurs

connaissances des échanges, des démarches administratives ou métiers, nécessaire pour

assurer l’efficacité de leurs activités et d’accélérer et fiabiliser la circulation des informations.

La raison majeure reste que ces procédures formelles ou informelles constituent souvent le

cœur de l’entreprise et illustrent leurs savoirs-faires propres. Autrement dit, l’intérêt de la

mise en place d’une simple GED agrémentée d’une gestion de configuration, perd de son sens

en termes de performance, d’image et de mémoire de l’entreprise sans l’intégration de ces

procédures. Ces dernières peuvent être spécifiques à un cœur de métier ou à une entreprise, ou

tout à fait générale comme une validation ou une diffusion. Malgré la formalisation

informatique, il est important que cette automatisation ne soit pas trop rigide, à l’image des

procédures papiers, qui nécessitent souvent un degré important de flexibilité, pour adapter,

faire évoluer, voire même pour by-passer ponctuellement des étapes non cruciales mais

bloquantes afin de respecter les impératifs majeurs. Cette automatisation doit être source de

dynamisation des échanges en favorisant la circulation des informations tout en conservant et

en assurant la cohérence et la fiabilité de ces dernières.

La typologie de processus la plus communément reconnue distingue trois catégories [AFNOR

X50-176, 00], [Tudor, 06] :

– les processus de réalisation (ou processus opérationnel, processus métiers)

• Ce sont les processus qui couvrent le cycle de vie des produits ou des

services de l’entreprise à destination des clients, de la définition à la

livraison, voir la maintenance.

– les processus supports (ou processus de soutien, processus d’appuis)

• Ce sont les processus qui couvrent l’approvisionnement en ressources

nécessaires à la réalisation des processus métiers.

– les processus de management (ou processus de pilotage, processus de direction)


Page 52

• Ce sont les processus qui permettent de conduire l’organisation dans le

respect des objectifs stratégiques définis.

La norme ISO 9001 [ISO 9001, V.2000] ajoute une quatrième catégorie de processus :

– les processus de mesure

• Ce sont les processus qui permettent la maîtrise des autres processus et la

réalisation de l’amélioration continue en fournissant des indicateurs

répondants à des objectifs précis.

Cette cartographie n’est pas exhaustive mais permet une première qualification de tous les

processus d’une entreprise. Tout dépend du contexte, de l’activité de l’entreprise : le

processus de gestion des ressources humaines sera un processus support pour une entreprise

d’assemblage automobile et un processus métier pour une agence d’intérim. La performance

globale des entreprises est basée sur la pertinence et l’efficacité de ces quatre types de

processus, pas uniquement sur les processus purement métier.

Devant la complexité croissante des produits et des organisations et l’informatisation massive,

les entreprises sont amenées à formaliser leurs processus clés. Un grand nombre de ces

processus concernent la gestion du changement dans les différentes phases du cycle de vie du

produit et doivent naturellement être incorporés dans les systèmes de gestion de l’entreprise,

soit dans l’ERP soit dans le PLM. Ces derniers permettent ainsi de prédéfinir le cheminement,

les tâches, les personnes en charge de réaliser ces dernières, mais également les actions

automatiques à faire tout au long du processus. La plus part des outils sont dotés d’une

application de création de processus connectable au moteur de la solution. L’implémentation

de processus au cœur du système confère aux outils une capacité à organiser les flux

d’informations et d’en faciliter la circulation. La simplicité de création de nouveaux processus

élémentaires, la modularité et la flexibilité de l’outil permettent de s’approcher au plus juste

de l’organisation réelle de l’entreprise. Tous ces flux sont enregistrés dans la base de données

facilitant ainsi la traçabilité des actions, des commentaires et de tout élément intégré aux

processus. Cette partie du logiciel contribue également à créer des assistants de saisie, de suivi

de documents, d’opérations, de projets afin de faciliter l’acceptation et l’utilisation de

l’application par l’ensemble des utilisateurs.

C’est la brique de gestion de processus connectée au moteur de la solution qui dynamise les

flux de données, uniformise l’ensemble des méthodes et savoir- faire de l’entreprise et permet

de maitriser la circulation et les actions menées sur les données contenues dans la première


Page 53

brique de gestion documentaire et/ou sur un produit/projet gérer par la brique de gestion de

configuration comme l’illustre la Figure 3.

Figure 3. La brique fonctionnelle « Gestion des Processus »

2.1.4 Le reporting : le support à l’aide à la décision

Face à la concurrence grandissante et à la mondialisation, les entreprises doivent

perpétuellement optimiser le triptyque : qualité, coût, délais. Quelque soit leur secteur

d’activité, elles ont du mettre en œuvre de nombreuses modifications : organisationnelles, en

étendant l’entreprise, méthodologiques, en utilisant les avancées technologiques et

stratégiques, en se recentrant sur leur cœur d’activité mais aussi en prônant l’innovation

nécessaire pour subsister sur le marché. La seconde conséquence pour les entreprises fut de

gérer rapidement un nombre exponentiel de produit/projet pour répondre aux besoins de

nouveauté imposée par les clients. Or la performance de l’entreprise dépend du résultat, au

regard des ratios issus du triptyque qualité/coût/délais, de chacun des projets qui eux mêmes

sont conditionnés par les différents choix pris tout au long de son cycle de vie que ce soit au

niveau méthodologique, processus, organisation, technologie… Pour conserver leur place sur

le marché, la minimisation des risques liés à ces différents choix, que ce soit lors du

lancement d’un nouveau projet mais également durant son déroulement, est primordiale. C’est

pourquoi, les décideurs ont besoin de disposer d’informations fiables et pertinentes tout au

long du cycle pour prévoir, anticiper et agir sur la performance du projet, donc de leur

entreprise. Ce qui explique que la capacité à disposer de l’information juste - et juste à temps -

est devenue un facteur-clé de succès d’un point de vue stratégique. Ces informations doivent

permettre de suivre l’ensemble des flux critiques, transactionnels et informationnels, pour agir


Page 54

sur l’activité et sur son management. Autrement dit, les informations en question doivent

provenir des différentes sources d’informations présentes dans le SI afin de les mettre en

corrélation pour obtenir une vision transverse et complète du produit/projet dans le but de

déterminer les actions correctives au plus juste et adapter les actions futures du processus.

Pour obtenir l’ensemble de ces informations, un traitement fastidieux était nécessaire

entrainant soit un suivi partiel, basé que sur un type unique d’information, soit un suivi a

posteriori des actions, empêchant l’anticipation dans l’action. Eu égard aux investissements

réalisés dans les systèmes d’information depuis plusieurs années, les décideurs estiment

pouvoir disposer maintenant de l’ensemble de ces informations, nécessaires pour piloter leurs

activités, à moindre effort, ce qui suppose d’avoir une cohérence et une accessibilité complète

sur ces dernières.

Pour un produit/projet donné, le choix de l’organisation et de la méthodologie suivie pour

aboutir aux objectifs déterminés est réalisé a priori en fonction du savoir faire et des retours

d’expériences de l’entreprise mais aussi en fonction des moyens à disposition. Le pilotage

d’une activité présuppose la mise en place d’actions correctives et la re-définition des actions

prochaines, adaptées au contexte, en fonction des actions prédéfinies et des mesures de

contrôle effectuées. Le but de cette boucle rétroactive est de parvenir aux résultats escomptés

en optimisant le triptyque qualité/coût/délais de façon performante. Cette dernière

caractéristique repose d’après Gibert [Gibert, 80] sur l’optimisation de :

- l’efficience - le rapport entre la qualité du résultat et les moyens déployés -,

- l’efficacité - le rapport entre objectifs déterminés et le résultat obtenu -,

- la pertinence - le rapport entre les moyens déployés et les objectifs -.

Or pour un produit/projet donné, la performance globale de ce dernier dépend du déroulement

de l’ensemble des sous activités nécessaire pour parvenir au résultat, elles mêmes

conditionnées par les décisions prisent par les acteurs en fonction de l’environnement. La

performance est donc multi-acteur et multi-période, car elle doit être prise en compte sur

l’ensemble du cycle de vie du produit/projet [Tomala, 02]. La performance est une motivation

essentielle pour les entreprises pour pérenniser et survivre face à la concurrence. Il est donc

crucial de pouvoir l’évaluer à tout moment. Or l’entreprise regroupant différentes activités, il

est nécessaire de toutes les évaluer afin d’obtenir des performances locales (leur

« agrégation » ne fournissant pas au décideur une représentation de la performance globale). Il

est alors stratégique de pouvoir évaluer et suivre cette caractéristique à tous les niveaux de

l’activité jusqu’au niveau global. Des systèmes d’évaluation de la performance comme celui

de [Duffy et O’Donnell, 97], [Bonnefous, 01], [Robin, 05], [Sauser, 06] proposent un certain


Page 55

nombre d’étapes pour développer un système d‘évaluation de la performance et des tableaux

de bords. Ces différentes étapes sont :

- Définition des objectifs pour les différents niveaux (stratégique, tactique,

opérationnel)

- Définition des leviers d’action ou inducteurs de performance,

- Définition des indicateurs ainsi que des performances exigibles,

- Synthèse des données sous la forme généralement d‘un tableau de bord,

- Évaluation de la pertinence du système lui-même.

L’indicateur de performance permet d’exprimer la performance en fonction de l’atteinte d’un

objectif fixé, par sa comparaison à une mesure concrète résultant d’un calcul ou d’un constat.

Il doit être mesurable, observable ou contrôlable tout en étant simple, clairement défini et

facile à comprendre. Sa construction est basée sur les différents facteurs identifiés comme

ayant un impact direct sur la performance, les inducteurs. Pour rendre lisible et se positionner

comme un support à l’action, les indicateurs de performance sont regroupés et organisés sous

forme de listes et de représentations graphiques adaptées à un utilisateur selon son champ

d’action. Ce type de rapport est nommé tableau de bord, définit selon l’AFNOR comme étant

un « outil de pilotage et d’aide à la décision regroupant une sélection d’indicateurs »

[AFNOR X50-176, 00]. Son but est de mettre en évidence les actions qui s’imposent pour

atteindre les objectifs et améliorer les processus.

Les rapports et les tableaux de bord, que nous qualifierons de reporting pour la suite, sont

devenus des éléments clés pour les entreprises. Chaque nouvel outil implémenté dans le SI

doit fournir un niveau important d’accessibilité aux données soit pour une utilisation direct au

sein de ce dernier, soit par un outil tiers qui agrègera, selon certaines règles, les différentes

données issues de l’ensemble des logiciels mis en œuvre au cours de l’activité. C’est une

nouvelle façon de naviguer dans les données de l’entreprise et ouvre la possibilité de passer

d’un management de contrôle hiérarchique à un management anticipatif autonome. Étant

donné que la réalisation d’une activité émane d’une succession de choix issus du savoir faire

et des retours d’expérience du décisionnaire au regard de l’environnement du produit/projet

en question, s’il dispose du reporting adapté, il pourra analyser seul ou avec son équipe les

impacts de ses choix sur le déroulement de son activité, et optimiser ses actions au fur et à

mesure de l’avancé de cette dernière pour respecter les objectifs. Ceci se décline à tous les

niveaux hiérarchiques de l’entreprise : le patron pour réviser sa stratégie globale en fonction

du déroulement des projets, le chef de projet pour connaitre les leviers d’actions possible pour

améliorer le déroulement de son projet, le chef d’atelier pour identifier les points bloquants de


Page 56

son installation, l’opérateur pour connaitre l’impact de ses actions sur le projet et se

positionner au regard des objectifs qui lui ont été fixés. L’intégration d’un référentiel unique

pour les données et les processus, simplifie et accroit les capacités de créer, mesurer et croiser

des informations pour obtenir des indicateurs adaptés tout au long du cycle de vie géré par le

système. Le reporting est une brique fonctionnelle importante dans les solutions proposées par

LASCOM. Intégrant nativement un moteur de reporting connecté avec la base de données,

différents niveaux de suivi d’indicateurs de performance sont possible tant au niveau global

qu’au niveau local. En effet, il est possible de créer soit des rapports complexes agrégeant les

données du PLM et/ou d’applications tiers afin d’obtenir une vision transverse des activités,

soit des tableaux de bord axés sur une activité en particulier basées sur des rapports plus

simples, plus accessible et plus flexible en fonction de l’utilisateur et du produit/projet.

L’objectif des industries est de produire « mieux », autrement dit de produire d’avantage, à

moindre coût et dans un délai restreint. Pour évaluer leur performance et optimiser le pilotage

de leurs activités, les entreprises cherchent des outils de suivis et d’aide à la décision. C’est en

général un « moteur de reporting » qui aide au suivi, à l’adaptation et à l’optimisation du

pilotage des activités tout au long du cycle de vie du produit/projet. Il représente un vecteur

prépondérant de la performance global de l’entreprise, à partir des données contenues dans les

trois autres briques fonctionnelles et/ou dans des outils tiers (Figure 4).

Figure 4. La brique fonctionnelle « Reporting »

Ces briques sont d’autant plus importantes que se sont-elles qui vont être implémentées lors

de la mise en place d’une solution logicielle et c’est donc de leur définition et des périmètres


Page 57

qu’elles recouvrent que vont dépendre le ou les processus de mise en place de l’outil. La mise

en œuvre d'une infrastructure autour du PLM est un projet global du SI qui s'inscrit dans une

logique de long terme. Aussi, tout projet de déploiement d'un système PLM nécessite de

maîtriser les points suivants [Bissay, 10] :

- les processus métiers et les refontes éventuelles,

- les processus fonctionnels,

- les migrations de données,

- l'intégration globale avec les autres composantes du SI (comme l'ERP),

- la conduite de changement,

- les supports et la formation.

Dans les projets autour des PLM, deux grandes orientations existent. Il y a les projets qui

nécessitent de nombreux développements de par l'histoire de l'entreprise, sa complexité, ou

les contraintes de son business. Ces projets demandent un fort accompagnement. L'autre

tendance, la plus forte actuellement, vise à déployer rapidement son projet, tout en limitant le

coût. Pour cela, on cherche en permanence l'adéquation entre les besoins, les gains espérés et

les fonctionnalités standards des progiciels. Les restrictions de budgets poussent même à

segmenter les projets en petits lots peu onéreux, au risque de dégrader l'objectif global

[Debaecker, 04]. Il apparaît donc finalement au moins deux visions (parfois divergentes) du

processus de mise en place d’une solution logicielle dans une entreprise : la vision du

« client » - l’entreprise - et la vision du « fournisseur » - l’éditeur logiciel. Nous présenterons

ces deux visions dans la section suivante.

3 Mise en place d’un PLM : un processus aux multiples facettes

3.1 La mise en place théorique vue du coté « client »

Même s'il est difficile d'établir un ensemble d'étapes exhaustif représentatif de la

vision « client » du processus de mise en place d’un outil PLM dans une entreprise

[Bordegoni et al., 04], nous retiendrons les travaux de Bissay [Bissay, 10]. Les recherches

qu’elle a menées au sein de PME/PMI lui ont permis de modéliser la perception « client »

suivant trois grandes phases et sept sous-phases (une description plus complète des travaux

de Bissay est fournie en Annexe 2) :

- la phase d'avant-projet qui débute de l'idée de mettre en place un tel projet jusqu'au

choix de la solution et qui se compose de 3 sous-phases :

o La définition du projet,


Page 58

o La rédaction du cahier des charges,

o Choix d'une solution.

- la phase de mise en œuvre qui va correspondre à l'adaptation du système choisi à

l'organisation de l'entreprise,

o La définition du plan projet.

o La mise en œuvre.

- La phase d'accompagnement et d'adaptation du système qui est une phase transversale

généralement incluse dans les deux précédentes et qui permet de garantir l'adéquation

et l'adaptation du système aux évolutions du contexte industriel de l'entreprise.

o La gestion du changement.

o La reprise de l'existant.

L'approche globale pour le déploiement de système d'information de type PLM au sein des

PME/PMI proposée par Bissay est caractérisée par différents processus qui vont guider la

mise en œuvre en amont et en aval du projet. Cette proposition est représentative du fait que

les entreprises ont souvent une approche « processus » plutôt qu'une approche « projet » de la

mise en place d’une solution logicielle PLM ce qui a pour conséquence de compliquer la

tâche de l’éditeur. La section suivante, par la description de la vision « éditeur » de la mise en

place d’une solution, va mettre en exergue les problématiques liées aux perceptions

divergentes du client et de l’éditeur.

3.2 La mise en place théorique vue du coté « éditeur », exemple de

LASCOM

Dès 1981, des propositions de phasage d’un projet de mise en place d’une solution

logicielle dans les entreprises ont été diffusées (Figure 5) [Boehm, 81], [Morlay, 01].


Page 59

Figure 5. Les tâches d'un projet logiciel par activités et par phases

Cette proposition de phasage est très proche de celle que nous avons pu mettre en évidence

chez LASCOM, l’éditeur au sein duquel se déroulait le travail de recherche. En effet, les

retours d’expérience de l’entreprise permettent de mettre en évidence que le processus de

déploiement d’une solution logicielle est généralement décomposable en treize étapes

incontournables illustrées sur la Figure 6.


Page 60

Figure 6. Les différentes phases d’un projet d’informatisation chez LASCOM

Les tenants et les aboutissants de chacune de ces étapes peuvent être définis comme suit :

- Prospection : correspond à toutes les actions débouchant sur une mise en relation d’un

client potentiel et d’un éditeur.

- Expression du besoin : correspond à l’étape initialisant le processus, en effet ce type

de projet est généralement issu d’un constat d’un ou plusieurs disfonctionnement ou

vecteurs d’amélioration identifiés au sein de l’entreprise permettant de définir le

besoin.

- Étude de marché : à partir de la définition du besoin, l’étude de marché permet de

délimiter le contour fonctionnel de leur besoin au regard des solutions informatiques

présentes sur le marché.


Page 61

- Cahier des charges : en fonction de cette étude, le cahier des charges est réalisé. Ce

dernier permet de définir formellement le besoin et de délimiter la portée du projet

pour compléter l’appel d’offre émis aux éditeurs.

- Réponses : tous les éditeurs intéressés par le projet répondent au cahier des charges à

travers un chiffrage (la réponse financière), une description fonctionnelle de leur

solution (la réponse technique) et propose une démonstration de leur solution.

- Choix de la solution : suite aux réponses, des soutenances sont organisées entre

l’entreprise « cliente » et les éditeurs retenus. Ces entretiens doivent permettre aux

éditeurs de défendre leur proposition, de l’illustrer à travers une démonstration et de

négocier les termes du contrat, essentiellement le prix. Selon les projets, cette étape

peut être réitérée plusieurs fois afin de restreindre les candidatures tout en affinant le

besoin. A l’issue des entretiens, l’entreprise fait un choix entre les différentes

propositions techniques et financières revues.

- Spécifications : une fois le choix réalisé, le projet commun avec l’éditeur commence

par une formation dite au concept afin d’expliquer les termes techniques liés au

logiciel et améliorer la qualité de la communication entre les deux intervenants. La

spécification est une étape cruciale du processus, c’est un moment d’écoute et

d’échange pour parvenir à déterminer le cadre fonctionnel et technique le plus précis

possible de la future application, mais également de déterminer les solutions

techniques à mettre en œuvre pour parvenir à remplir, de la façon la plus satisfaisante,

le cahier des charges.

- Modélisation(s) : suite à cette analyse, une étape de modélisation et de prototypage

commence pour permettre d’illustrer le besoin, s’assurer de la faisabilité et de la bonne

compréhension mutuelle du fonctionnement. Elle comporte plusieurs sous étapes en

commençant par une schématisation puis une pré-modélisation, constituant les bases

de la modélisation pour aboutir au prototype.

- Développements : en parallèle un sous projet chez l’éditeur peut également être lancé

afin de réaliser les éléments spécifiques demandé par le client afin de les intégrer dans

un premier temps dans le prototype puis dans la solution finale du client.

- Tests : pour valider ce modèle, différents tests, généralement par module ou

fonctionnalité, sont réalisés par l’éditeur comme par le client (le chef de projet mais

également quelques utilisateurs), pour tester les développements spécifiques, les

spécificités fonctionnelles ou tout simplement le modèle de données.


Page 62

- Déploiement : une fois l’application validée, le déploiement est généralement réalisé

en deux phases. Dans un premier temps, le système est déployé sur une partie du site,

nommé site pilote, pour confirmer les différents tests dans une utilisation quotidienne,

initialiser la reprise des données et l’intégration au sein du système d’information. Si

cette étape est réussie, l’application est déployée sur l’ensemble du site, sinon des

modifications sont réalisées pour être testées à nouveau. Selon les projets cette étape

est intégrée dans l’étape de tests.

- Support : pour faciliter l’appropriation du logiciel, différentes étapes

d’accompagnement se succèdent durant les premiers temps : la formation des

utilisateurs, la formation des administrateurs qui vont constituer également les

premiers référents techniques dans l’entreprise, mais également la mise à disposition

d’un support technique.

- Exploitation : finalement, l’entreprise lance l’exploitation et impose l’utilisation

systématique du logiciel à l’ensemble des acteurs du cadre fonctionnel prédéfini.

L’éditeur n’interviendra que dans le cadre du suivi commercial et de la maintenance,

voire d’une enquête de satisfaction au près des interlocuteurs habituels.

Cette décomposition met en évidence le découpage généralement constaté dans les projets

réalisés par LASCOM, mais également la définition du terme « projet » pour chacun des

acteurs dans ce processus lié au moment de leur implication dans le cycle global. Pour mettre

en œuvre ce processus, LASCOM a jusque là adopté une approche qui consiste à définir un

processus issu d’une procédure « idéale » décrite par des experts et répondant à un besoin

spécifique, puis à construire le modèle de données associé. Puis au cours de la réalisation du

prototype ou lors du déploiement test, des corrections sont apportées au fur et à mesure des

réserves du client. Chacune de ces étapes nécessite des temps d’analyse, de formalisation et

de communication, leur durée, mais également le nombre d’itération, est donc relativement

variable en fonction du client, de la complexité du projet, des différentes contraintes à prendre

en compte.

Tout l’enjeu des étapes « amont » de ce processus est de définir un modèle le plus précis

possible de ce que souhaite le client sur le contour prédéfini. Pour se faire, différentes

réunions et échanges sont mis en place pour recueillir les informations auprès des personnes

identifiées par le client comme étant potentiellement détentrices possédant les connaissances,

puis ces éléments sont interprétés à travers des outils. Finalement la modélisation est effectuée


Page 63

a posteriori du système à considérer : l’entreprise, le service, un produit, un projet… Cette

démarche met en œuvre différentes méthodologies en fonction des intervenants, du type de

projet, du niveau de formalisation existant dans l’entreprise. En effet, en fonction de l’existant

et/ou des intervenants, il est souvent plus simple et surtout plus rapide soit de partir des

modèles existants et d’approfondir la partie à traiter, l’approche descendante, soit de partir de

la réalité du terrain et de définir le système permettant la réalisation du produit/projet,

l’approche ascendante. Ces deux approches représentent l’essence de toutes les méthodologies

utilisées pour modéliser les données, les activités et finalement l’organisation. La section

suivante présente les approches ainsi que les méthodes et outils classiquement employés pour

établir un modèle précis de ce que souhaite le client [Baczkowski et al., 12].

4 Des besoins à la solution logicielle : de la réalité aux modèles

Comme nous l’avons dit précédemment, il est souvent plus simple et surtout plus

rapide, en fonction de l’existant et/ou des intervenants, soit de partir des modèles existants et

d’approfondir la partie à traiter (approche descendante), soit de partir de la réalité du terrain et

de définir le système permettant la réalisation du produit/projet (approche ascendante). Ces

deux approches vont à la fois concerner l’entreprise dans son ensemble (visions

organisationnelle et fonctionnelle) mais aussi ses processus et activités (vision

opérationnelle). Les approches et méthodes de modélisation d’entreprise et de

processus/activités vont donc être nécessaires à la construction des modèles qui seront par la

suite implémentés dans la solution logicielle [Baczkowski et al., 08a].

4.1 Les approches de modélisation d’entreprises

Les modèles d'entreprises permettent de décrire les pratiques d'entreprises selon

plusieurs points de vues : fonctionnel, physique, processus, décisionnel et informationnel. Les

modèles d'entreprises sont des représentations de l'état existant d'un système et, à ce titre, sont

un pré-requis indispensable à toute étude de mise en place d’un SI dans une entreprise [Blanc,

06] [Chevallereau, 11].

4.1.1 L’approche « descendante » : l’intégration itérative

L’approche descendante repose sur le principe de l’approfondissement des systèmes. Il

s’agit, dans un premier temps, de définir le niveau le plus haut, représentant le système dans

sa globalité et d’en identifier ses finalités. A partir de cette définition fonctionnelle,

l’approche consiste à lister l’ensemble des processus mis en œuvre pour parvenir à passer


Page 64

d’un état d’entrée à l’état fini désiré. Ainsi la fonction du système s’affinera au cours des

décompositions successives en sous-fonctions jusqu’au niveau opérationnel. L’aboutissement

de cette étude itérative est l’obtention, par intégration de l’ensemble des données recueillies,

d’une définition du système cohérente du niveau global jusqu’au niveau local.

Ce type d’étude s’appuie sur des modèles préexistants et sur une forte connaissance de

l’entreprise, de son organisation, ses processus, ses activités…. La démarche doit conduire un

expert à analyser et formaliser progressivement le système pour faire émerger des modèles

globaux. Ce niveau d’expertise nécessite d’impliquer rapidement dans les projets les équipes

dirigeantes, ce qui peut constituer un attrait important due à la transversalité de la réflexion

dans le cadre de l’uniformisation du modèle.

4.1.2 L’approche « ascendante » : la fédération

Cette démarche est directement inspirée de la « Grounded Theory », [Taylor et al.,

84], dont le but était de découvrir des concepts, hypothèses ou propositions directement à

partir des données de terrain plutôt qu’en partant de suppositions ou cadres théoriques

existants. Autrement dit, cette démarche conceptuelle consiste à recenser d’abord toutes les

activités liées à la réalisation du produit/projet, puis à les regrouper selon le déroulement

logique du flux, depuis l’identification des exigences des clients jusqu’à la satisfaction des

exigences convenues. Cette première étape permet de répertorier les activités et de les

séquencer, aboutissant à la formalisation de l’ensemble des processus de réalisation du

produit/projet. Pour aboutir à une définition globale du système, il est nécessaire d’adjoindre à

ce modèle les processus de management, de support et de mesure dans une seconde étape.

L’agrégation et la standardisation de toutes ces informations a pour finalité de modéliser les

activités locales jusqu’à considérer l’ensemble en une seule activité globale.

Ce type de démarche a pour avantage sa rapidité et le réalisme du modèle, basée sur des

collectes d'informations sur le terrain auprès des personnes qui ont la connaissance sur

l'activité et non à une équipe projet n’ayant pas forcément l’expérience nécessaire pour

apporter le recul suffisant sur les situations exceptionnelles. Par contre, cette équipe et son

caractère transverse aux activités est mis à bonne escient lors de l’uniformisation des

différentes procédures.


Page 65

4.2 Les méthodes et outils de modélisation d’entreprise et de processus

4.2.1 Méthodes et outils de modélisation d’entreprise

Il existe divers outils et méthodes de modélisation d’entreprise mais nous ne les

détaillerons pas de façon exhaustive ici car notre objectif est ici de mettre en évidence leur

adéquation ou leur inadaptation aux problématiques rencontrées par les éditeurs logiciels.

L’une des premières méthodes, la méthode SADT (Structured Analysis and Design

Technique), est apparue à la fin des années 70 sous l’impulsion de Ross [Ross, 77] et devait

permettre une analyse structurée des systèmes. Cette méthode a ouvert la voie à la

modélisation par représentation graphique des activités et des chaînes d’activités. La méthode

SADT introduit le principe de décomposition fonctionnelle et formalise le concept d'activité.

Elle se présente comme un langage graphique et un ensemble limité de primitives, des

«boîtes» et des «flèches», pour la représentation des composants des systèmes et des

interfaces. SADT a donné lieu à la famille des méthodes IDEF [ICAM, 1981] (IDEF0, utilisée

pour décrire les aspects fonctionnels d’un système, IDEF3, spécialement conçue pour la

modélisation des séquences d'activités ou processus [Mayer et al, 1995], [Vernadat, 1999],

etc.). D'autres méthodes plus élaborées mais toujours issues du génie logiciel proposent des

supports d'analyse statique ou dynamique en se basant sur des approches fonctionnelles,

relationnelles ou objets. Nous pouvons citer MERISE [Tardieu et al., 83] et ses modèles de

traitement, la modélisation objet OMT [Rumbaugh, 91] (vues statiques, dynamiques et

fonctionnelles d'un système), OOD [Booch, 00] (vues logiques et physiques du système),

OOSE [Jacobson, 92] (couvre tout le cycle de développement), UML (Unified Modeling

Langage) est la fusion et synthèse des méthodes précédentes mais ce n'est pas vraiment une

méthode car il ne comporte pas de démarche, c'est un langage de modélisation objet [OMG,

03]. Enfin, il existe plusieurs travaux relatifs à la modélisation en entreprise dans son

ensemble. Parmi les plus connues, nous pouvons citer pour des architectures de référence et

méthodes telles que :

- CEN ENV 40003 [Shorter, 00], qui est une pré-norme du Comité Européen de

Normalisation (CEN) pour la modélisation d'entreprise. Son but est de préciser la

terminologie et d'énoncer les principes fondamentaux sous-jacents au domaine de la

modélisation en entreprise. L'architecture de référence retenue est basée sur le cadre

de modélisation de CIMOSA,

- CIMOSA (CIM Open System Architecture) [AMICE 93], qui est une architecture

pour construire des systèmes intégrés de production. Elle a été développée par le


Page 66

Consortium AMICE dans le cadre de projets ESPRIT. Cette architecture comprend un

cadre de modélisation (MFW « Modeling FrameWork ») ; une plateforme

d'intégration (IIS « Integrating InfraStructure ») et le cycle de vie d’un système CIM «

Computer-Integrated Manufacturing » (SLC « System Life Cycle »). CIMOSA offre

des langages de modélisation intégrés pour les aspects fonctionnels, informationnels,

ressources et organisationnels [Vernadat, 96].

- GERAM (Generalized Enterprise Reference Architecture and Methodology) [IFAC,

97], qui est une architecture de référence développée par un groupe de réflexion sur les

architectures pour l'intégration des entreprises. GERAM est en fait une généralisation

de CIMOSA, de GRAI-GIM, de PERA et de quelques autres architectures (ARIS,

ENV 40003 et IEM),

- La méthode GRAI (Graphe de Résultats et Activités Interreliés) qui a pour but la

conception ou la reconception des systèmes de production et qui se focalise sur la

partie décisionnelle (système de conduite) et s'applique dans une optique générale

d'amélioration des performances. La méthode GRAI est construite à partir d'un modèle

de référence et s'appuie sur des langages (grille, processus, réseaux,...) [Doumeingts,

84], [Roboam, 93], [Ducq, 05].

- PERA (Purdue Enterprise Reference Architecture) [Williams, 92], est une

méthodologie complète d'ingénierie des environnements industriels. La méthodologie

définit toutes les phases du cycle de vie d'une entité industrielle depuis sa

conceptualisation jusqu'à sa mise en opération en passant par les phases de conception.

L'originalité de PERA réside dans la prise en compte des aspects humains et

notamment de leur positionnement dans l’architecture ;

- ARIS (Architecture for integrated Information Systems) [Scheer 99] dont la structure

est similaire à celle de CIMOSA mais qui à la place de se focaliser sur les systèmes

CIM traite les entreprises avec des méthodes traditionnelles orientées métier (planning

de production, inventaires de contrôles, etc.). Elle se focalise surtout en ingénierie des

logiciels et des aspects organisationnels de la conception des systèmes intégrés dans

l’entreprise.

4.2.2 Méthodes et outils de modélisation des processus/activités

Il existe divers outils et méthodes de modélisation des processus métier [Abdmouleh

04] et comme pour les méthodes de modélisation d’entreprise nous ne les détaillerons pas ici

car notre objectif est d’estimer la pertinence de l’utilisation de ces outils pour les éditeurs


Page 67

logiciels. Nous avons étudié et comparé les principaux outils et méthodes de modélisation des

processus (IDFEØ, IDEF3, workflow de la « Workflow Management Coalition », réseaux de

Petri, grafcet, UML, workflow de Windchill, réseaux GRAI, gestionnaire de processus

d’Enovia-LCA). Le Tableau 1 présente la synthèse de notre analyse.

Tableau 1. Etude comparative des outils/méthodes de modélisation de processus


Page 68

4.2.3 Analyse et synthèse

Même si les modèles d'entreprise sont une représentation de l'état existant d'un

système et, à ce titre, sont un pré-requis indispensable à toute étude des entreprises, il est à

noter qu’ils sont peu utilisés par les éditeurs logiciels. Ceci peut s’expliquer par le fait que les

clients exigent un temps d’étude du besoin relativement court ce qui ne permet pas forcément

de déployer de tels outils ou méthodes. Les méthodes de modélisation de processus sont

finalement plus utilisées mais il n’existe pas forcément de consensus quant à la « meilleure »

méthode à employer. L’utilisation de telle ou telle méthode dépend en fait de l’expertise de la

personne mandatée par l’éditeur logiciel pour aller recueillir les informations chez le client

qui aura plus d’appétence avec une méthode plutôt qu’une autre. L’utilisation de ces

méthodes demande une organisation rigoureuse des informations et un nombre important de

schémas, souvent imposants selon la granularité, pour parvenir à modéliser de façon

cohérente l’ensemble du processus et ainsi obtenir une cartographie de l’organisation de

l’entreprise. Cette cartographie n’a de sens qu’à un instant précis et pour une utilisation

précise, dans notre cas pour aligner le logiciel sur l’organisation de l’entreprise. En effet, le

modèle résultant ne permet pas une mise à jour aisée du fait des impacts engendrés sur tout ou

partie des nombreux schémas. Autrement dit, cette modélisation constitue une vue statique du

système au lieu d’être un outil d’analyse et d’amélioration utilisable au quotidien pour le

client mais aussi pour l’intégrateur lors d’évolution du logiciel.

5 Synthèse

L’un des objectifs de toute entreprise, comme de toute organisation, est de développer

un produit/projet relativement à ses buts propres. Pour répondre stratégiquement à cet

objectif, leur structure a souvent été établie pour cette seule fin en plaçant le produit au centre

des préoccupations. Dans le monde industriel, pour un produit donné, un ensemble de

livrables, documents, données internes et externes est produit pour répondre aux exigences

réglementaires, qualité, commerciales… exigences qui peuvent influencer la structuration, la

nature et la définition des activités à mettre en œuvre et ainsi instaurer une organisation

particulière. Pour accélérer la modélisation (et finalement l’implémentation), base de

l’adéquation entre le logiciel et l’entreprise, c’est préférentiellement la première étude sur le

terrain qui doit être efficace pour mettre en évidence fidèlement mais globalement cette

logique d’organisation. C’est lors d’une seconde étape d’analyse plus fine que l’organisation

de l’entreprise et ses processus/activités sera réellement détaillée. Ces deux grandes étapes

primordiales donnent souvent lieu à des incompréhensions entre le client et l’éditeur et des


Page 69

incertitudes apparaissent. Incertitudes qui par la suite perturberont le déroulement du projet

car elles seront autant de sources d’itérations et de discussions chronophages entre les

partenaires. Ce sont ces itérations que LASCOM souhaite réduire en améliorant les phases

amonts de son processus d’implémentation et en particulier celles qui correspondent au

recueil d’informations chez le client. Ainsi, et en partant du postulat que les entreprises

clientes et que les intervenants nécessaires à la constitution du modèle ne sont pas tous des

experts dans les techniques de modélisation utilisées, il apparait donc essentiel que le

« langage » de modélisation utilisé soit simple et qu’il mette en évidence de façon explicite

l’ensemble des informations pour favoriser l’implication et la compréhension de chacune des

entités interrogées quelque soit le niveau de maturité du projet. L’objectif du chapitre suivant

est donc de travailler à l’affinement de la démarche d’implémentation chez LASCOM et à

l’identification d’au moins un formalisme plus « accessible » et « utilisable » dans le monde

industriel.

Chapitre 3 Analyse et amélioration du déploiement des solutions

Page 71

Chapitre 3

Analyse et amélioration du déploiement des solutions : le cas

LASCOM

1 Introduction

Aujourd’hui l’information est au cœur des préoccupations des entreprises, que ce soit

par peur d’une fuite de connaissance, soit pour des problématiques de suivi et de croissance

de la performance de la collaboration dans le cadre des entreprises étendues. Pour faciliter la

capitalisation et le transfert de ces dernières, la dématérialisation et plus généralement

l’informatisation, représente le nerf de la guerre économique pour les industriels. Aux vues

des impacts organisationnelles de la mise en place d’un logiciel de gestion et plus

particulièrement d’une démarche PLM, le processus d’informatisation devient un processus

stratégique pour les entreprises et a un rôle majeur dans la croissance de la performance de

ces dernières. L’apport méthodologique et l’optimisation de ce dernier peut constituer un

différentiateur fort entre plusieurs éditeurs en sus des performances de l’outil au regard des

besoins identifiés par l’entreprise elle-même. L’objectif est de subsister sur le marché, ce qui

induit de rentabiliser l’investissement au plus tôt pour les entreprises et, pour l’éditeur, de

rendre son produit central pour l’activité de son client. Ainsi l’éditeur peut espérer accroître la

satisfaction du client et assurer la longévité du produit chez celui-ci et surtout son utilisation

engendrant de la maintenance, des évolutions techniques et nombre d’utilisateurs croissant (et

donc de licences). Le but commun pour l’entreprise et pour l’éditeur est de maximiser le

retour sur investissement en implémentant une solution logicielle performante (très)

rapidement. Pour atteindre ces exigences, le logiciel doit non seulement répondre aux besoins

et aux critères financiers fixés au moment du déploiement, mais également à long terme,

autrement dit l’éditeur doit fournir une solution plus efficace que les dispositions actuelles,

adaptée aux besoins présents et futurs de l’ensemble des utilisateurs et surtout maximiser

l’utilisation de son produit par un panel élargie.

Nous allons nous intéresser dans ce chapitre à la définition des évolutions tant techniques que

méthodologiques que doivent subir les solutions PLM, notamment celle développée par

LASCOM, pour répondre aux besoins toujours croissants des entreprises et des utilisateurs.


Page 72

2 La réponse de LASCOM aux problématiques industrielles

La solution LASCOM PLM proposée par l’éditeur LASCOM répond au besoin de

gestion des données critiques les plus complexes et est un outil full web de gestion de cycle

de vie produit/projet (PLM - Product Life Management) et de processus (BPM – Business

Process Management). Elle assure la gestion de données complexes et de processus critiques

permettant à ses clients de gérer, d’assurer l’échange et le suivi de leurs données et dossiers à

travers un référentiel technique unique. Cet ensemble permet de constituer véritablement la

mémoire, voire l’image de l’entreprise, d’améliorer la conception et de réduire le temps de

mise sur le marché de produits. Cette application permet non seulement de constituer une

Gestion Électronique Documentaire (GED), mais également la gestion des liens existant entre

ces données (les configurations), sans oublier l’automatisation des procédures (les processus

ou workflows) et l’apport d’une vision transverse et dynamique support à la décision (les

rapports et tableaux de bord ou reporting).

L’intégration de cette solution au sein du Système d’Information d’une entreprise est

complexe et nécessite de prendre en considération les spécificités du client. Or l’expérience

montre que LASCOM, quelque soit le projet d’informatisation (une nouvelle intégration ou

une évolution) mais également quelque soit l’entreprise cliente, emploie toujours le même

processus de déploiement (Chapitre 2, section 3.2, Figure 6). Ce mode de fonctionnement est

propre à LASCOM et donc souvent non partagé par le client ce qui entraine différents

problèmes :

- Un problème de communication entrainant une mécompréhension, due en partie à une

formation aux concepts souvent inadaptée aux interlocuteurs (aux clients) et peu

orientée sur les concepts et l’intérêt du PLM, en effet :

o Soit le client ne connait absolument pas l’informatique et plus particulièrement

le fonctionnement d’une base de données, ce qui entraine des difficultés

énormes de communication et la formation proposée par LASCOM n’est pas

suffisante pour combler les lacunes.

o Soit le client est ou se croit être expert dans ces domaines et a déjà son idée

préconçue sur la solution à mettre en place et son paramétrage. Dans ce cas le

client n’a bien souvent qu’une vision « technique » et non conceptuelle de

problème ce qui limite sa perception et sa réflexion quant à l’intérêt du

déploiement d’une solution PLM.


Page 73

- Des itérations, essentiellement lors des spécifications du système (pendant l’étape de

spécification ou lors des tests), difficilement chiffrables en terme de temps et

incontrôlables par l’éditeur car elles sont en majorité :

o Fonction de la qualité de la communication entre les parties prenantes et de fait

de la compréhension qu’ont les interlocuteurs du problème tant au niveau des

besoins métiers que des solutions techniques employées.

o Fonction de la place du chef de projet coté client, sa vision du projet étant

généralement parcellaire.

o Fonction de la maturité et de la définition du besoin global du client mais

également des besoins plus « locaux » des utilisateurs finaux.

- Une définition des besoins locaux incomplète entrainant des mécontentements des

utilisateurs et un ROI plus faible et/ou plus long qu’espéré dû essentiellement :

o À l’utilisation d’une seule approche de définition des besoins et qui ne reflète

souvent qu’un point de vue idéalisé du fonctionnement global du système

« entreprise »,

o À l’utilisation de méthodologies non-outillées pour l’analyse des besoins et

dont le choix est laissé au chef de projet (client et éditeur) qui en fonction de

son expérience préfèrera telle ou telle méthode de modélisation. Ceci démontre

la nécessité pour LASCOM de mener totalement la réflexion avec le client

pour avoir une démarche commune forte.

o À une perte de temps sur des itérations au niveau global qui ne laisse ensuite

que trop peu de temps pour de mener correctement des réflexions au niveau

local.

Finalement, l’ensemble de ces problèmes fait que souvent la solution mise en place par

LASCOM ne permet pas d’atteindre le niveau d’utilisabilité de l’outil espéré ni même

d’apporter tous les éléments permettant le pilotage des processus et activités et donc d’élargir

le cercle des utilisateurs par manque de temps de modélisation. Trois axes de réflexions

susceptibles d’améliorer la démarche de LASCOM émergent des problèmes que nous avons

mis en évidence dans cet état des lieux : les outils, la méthodologie et la communication.

Nous allons dans un premier temps nous intéresser aux outils et à ce que les éditeurs logiciels

appellent la « verticalisation » des solutions.


Page 74

2.1 D’une solution « globale » vers des plateformes adaptées et pré-

paramétrées : la « verticalisation »

Les briques fonctionnelles classiques vues dans le chapitre précédent permettent de

constituer le socle technico-fonctionnel de l’offre de LASCOM et font en sorte que le PLM

puisse :

- aider au pilotage en guidant l'information critique au travers de processus métier et en

donnant une totale traçabilité et un système de « reporting » efficace,

- représenter l’organisation en place contribuer à sa coordination en gérant et en

assurant l'échange et le suivi de toutes les données d'un client, pour lui apporter une

vision dynamique et un véritable tableau de bord de l'ensemble de son information

technique,

- participer à l’uniformisation des procédures en optimisant et en standardisant au

maximum les échanges de données de manière transversale à l’entreprise avec les

autres applications (ERP, CRM, MES,…) pour unifier et valoriser l’ensemble du

système d’information plutôt que ses différentes briques.

Une fois mis en place, le PLM devient un outil du quotidien pour les entreprises étendues,

c'est-à-dire pour l’entreprise et l’ensemble de ses partenaires. Pour être efficace, et s’inscrire

dans l’environnement quotidien des utilisateurs, il se doit d’être accessible via internet pour

répondre aux nouveaux principes organisationnels et de productivité qui imposent un accès

distant, une disponibilité continue des données pour les équipes géographiquement dispersées,

sans aucune contrainte technique, ni installation de logiciel préalable. Mais pour être

performant, l’outil doit être adapté à l’entreprise, à son organisation, au produit et à son

environnement. Classiquement, les éditeurs définissent leurs offres en fonction : d’un métier,

d’un produit/service, d’un profil… Dans le cas de LASCOM, la stratégie fut pendant

longtemps d’adapter le socle fonctionnel composé par les quatre briques classiques à chaque

client, ce qui donnait lieu à la mise en place de solutions spécifiques à chaque client. Cette

démarche fut celle préconisée durant ces vingt dernières années. Elle confère à LASCOM une

grande expérience et un grand savoir faire en terme développement et de mise en place de

solutions dédiées à un client mais elle n’est plus forcément adaptée aux exigences du monde

d’aujourd’hui. En effet, cette démarche est chronophage alors que les clients exigent de plus

en plus une mise en place rapidement et efficace. C’est pour répondre à ces exigences que

LASCOM a donné une nouvelle dimension à son produit en ajoutant à son socle fonctionnel


Page 75

une « surcouche métier » d’un point de vue fonctionnel, ergonomique, conception…. La

gamme LASCOM est donc aujourd’hui constituée d’une déclinaison de solutions

« verticalisées », autrement dit de plateformes adaptées et pré-paramétrées, en fonction de

trois grands domaines d’activités :

- l’AEC (Architectural Engineering & Construction) : BTP, ingénierie, construction

et collectivités territoriales,

- l’ICS (Industry & Complex Systems) : aérospatial, défense, industrie

manufacturière,

- le CPG (Consumer Packaged Goods) : agroalimentaire, distribution, cosmétique et

pharmaceutique.

Chacun de ces secteurs se caractérisent par des besoins différents liés au type de produit géré,

à l’organisation en place pour le réaliser, aux réglementations et exigences applicables, aux

contraintes rencontrées, aux processus métiers…

2.1.1 LASCOM AEC (Architectural Engineering & Construction)

Historiquement présent sur le marché de la CAO en tant que revendeur Autodesk®,

LASCOM a acquis des connaissances sur les métiers et les problématiques du bâtiment. Que

ce soit pour la gestion d’une nouvelle construction ou la maintenance d’une infrastructure, les

outils LASCOM aident les entreprises à surmonter les difficultés techniques liées à la

disponibilité des dernières informations validées et induites par la multiplication du nombre

d’intervenants et l’évolution continuelle des aspects réglementaires de plus en plus

contraignant vis-à-vis de la traçabilité et de la sécurité. La gestion du cycle de vie des plans

puis celle du patrimoine technique complet sont devenues vitales pour les entreprises du

bâtiment mais également pour tous celles qui doivent gérer des infrastructures, que ce soit des

sites industriels, administratifs ou historiques. Pour faire face aux enjeux concurrentielles et

budgétaires les entreprises se doivent de :

- respecter des délais et des plannings projet,

- coordonner des équipes et des intervenants nombreux et dispersés,

- maîtriser et réduire les risques,

- augmenter la disponibilité des infrastructures.

Tout ceci peut alors se traduire en termes de besoins relativement à cinq axes :

- Unifier le savoir-faire et les données associées dans un référentiel commun,

- Disposer à tout moment d’une information valide et à jour,


Page 76

- Faciliter la collaboration avec l’ensemble des acteurs afin d’optimiser le respect

des délais et des normes,

- Conserver et capitaliser le savoir-faire de l’entreprise, dont la réutilisation permet

d’accélérer le lancement des nouveaux projets,

- Fournir des outils d’aide à la décision pertinents et évolutifs afin de faciliter la

gestion en temps réel de vos projets.

En réponse à ces problématiques, LASCOM propose un référentiel web multi-projets,

organisé et piloté par des processus métiers et par des outils de reporting avancés dédiés au

secteur de la construction, l'ingénierie industrielle et des collectivités locales. Développé pour

la conduite des projets de construction, d'exploitation et de maintenance depuis leur

lancement jusqu'à la gestion du patrimoine bâti, LASCOM AEC est aussi bien dédié aux PME

qu'aux grands comptes grâce à sa structure modulaire et paramétrable. Pour atteindre ces

objectifs et proposer une réponse précise et performante aux problématiques du secteur et du

client, l’offre LASCOM AEC se décompose autour de six concepts essentiels :

- Un référentiel unique et structuré pour toute les phases du projet, basé sur un

modèle de données adapté au métier, structurant et stockant les données et les

documents, doté de fonctionnalités.

- Une déclinaison du référentiel par projet permettant de créer une structure

décisionnelle associée à ce dernier.

- Une optimisation de la production documentaire en reliant les outils de

bureautique directement au référentiel évitant les ressaisies, le rangement manuel

des données tout en conservant la traçabilité et en automatisant la génération de

document à partir des données du référentiel et d’un modèle.

- Un portail d’échange commun facilitant et accélérant les interactions pour

l’ensemble des intervenants du projet

- Un catalogue de processus métier permettant d’optimiser l’échange des

informations au sein de l’entreprise et avec les acteurs externes en automatisant les

procédures et les activités critiques (ex : validation de documents, gestion des

modifications, gestion des faits techniques, …)

- Des outils de reporting support à l’aide à la décision grâce au suivi des activités

documentaires et de l’avancement global pour l’ensemble des projets.

LASCOM AEC apporte une « surcouche métier » par rapport aux quatre briques de base

constituant LASCOM PLM, pour répondre aux besoins spécifiques de ses clients du secteur

de la construction, l'ingénierie industrielle et des collectivités locales, essentiellement orientés


Page 77

sur la gestion du patrimoine technique et de la gestion de projet. Cette « surcouche métier »

contribue à développer plus particulièrement les capacités de la gestion documentaire, des

processus et du reporting (Figure 7).

Figure 7. La déclinaison LASCOM PLM pour le marché de l’AEC

2.1.2 LASCOM ICS (Industry & Complex Systems)

Le secteur de « l’Industrie et des systèmes Complexes » comporte deux grands pôles :

le manufacturier et les systèmes complexes (les industries de pointe mais pas seulement).

Nous retrouvons dans ce secteur les domaines de l'aéronautique, du spatial, du transport et de

la défense par exemple dont la gestion des programmes et des systèmes demande une

identification précise de l'ensemble des composantes et des processus qui leurs sont associés.

Gérer ces systèmes complexes tout au long de leur vie suppose une vision unifiée, partagée et

consolidée de l'ensemble de ses composants par l'ensemble des acteurs. La solution de

LASCOM – LASCOM ICS est axée sur la phase de conception qui la première génératrice

des données relatives aux composants et répond aux défis de l’Ingénierie de conception en

permettant de :

- Rationaliser les coûts de conception,

- Accroître la productivité grâce à l'automatisation des procédures,

- Maîtriser les échanges avec les co-traitants,

- Renforcer la confiance des clients par une connaissance exhaustive des produits.


Page 78

LASCOM ICS est une plateforme technologique développée pour concevoir, intégrer et

maintenir des systèmes complexes, collaborer sur les projets et les programmes et gérer les

modifications et maîtriser l'évolution des systèmes. Cette solution tend donc à favoriser la

collaboration, gérer la diversité des données techniques et globaliser l'information des

entreprises. Elle repose sur le développement des 4 briques fonctionnelles complémentaires et

interopérables (Figure 8) :

- La gestion des données techniques et des documents au sein d’un référentiel

commun afin de stocker l’ensemble de la documentation relative au produit,

- La gestion de configuration intégrée de manière native afin de réaliser les

nomenclatures adaptées et intégrés des informations sur la composition (date de

validité d’un lien par exemple)

- La gestion de processus avec la présence au catalogue d‘une bibliothèque de

processus métiers sur étagère (gestion des faits techniques, des retrofits, des

opérations de maintenance, des modifications, des anomalies...). En outre,

l’adaptation et la création de processus sur mesure reste possible.

- Le reporting apporte une vision synthétique des données et des actions sur le

référentiel pour réaliser des indicateurs, des tableaux de bord et des rapports au

service de la performance.

Figure 8. La déclinaison LASCOM PLM pour le marché de l’ICS


Page 79

2.1.3 LASCOM CPG (Consumer Packaged Goods)

Dans le secteur des industries agroalimentaires, plus que dans toute autre industrie,

l'innovation est le principal moteur de croissance et de profits. Être innovant dans ce secteur

signifie aujourd'hui être capable d'améliorer ou d'ajouter de nouveaux produits sur le marché,

de réduire les coûts en modifiant les ingrédients, les procédés de fabrication, les emballages

ou les fournisseurs, etc. Dans ce secteur, pour la plupart des industriels, l'innovation produit

consiste le plus souvent à opérer des changements sur un produit déjà commercialisé. Ces

changements qui peuvent concerner l'emballage, la recette, le process de fabrication, les

contrôles qualité sur le produit, les fournisseurs ou encore l'étiquetage. Ils sont conditionnés

par les tendances du marché, les exigences nouvelles des consommateurs et les contraintes

règlementaires toujours plus fortes et cela sa traduit par :

- Une gestion croissante du nombre de références,

- Une capacité de réaction à la montée en puissance des marques de distributeurs,

- Une amélioration de la productivité,

- Une maîtrise des processus critiques d'innovation et de mise sur le marché de

nouveaux produits.

La solution LASCOM CPG est centrée sur la phase de R&D d’un produit dans un premier

temps puis sur la production de ce dernier une fois sa conception validée. Ce logiciel de

gestion d'informations permet de structurer, gérer et auditer l'ensemble des données et des

documents associés au produit.

L’objectif de LASCOM CPG est d’aider les industriels et distributeurs du secteur de

l’agroalimentaire et des autres biens de consommation à réduire le temps de mise en marché,

à gagner en productivité et à capitaliser sur la connaissance acquise pour innover à moindre

coûts en leur permettant de (Figure 9):

- Centraliser l'information relative aux produits dans un référentiel unique,

- Optimiser la formulation des produits donc la R&D,

- Automatiser la production documentaire (fiches techniques et cahier des charges),

- Disposer d'une traçabilité complète.


Page 80

Figure 9. La déclinaison LASCOM PLM pour le marché du CPG

2.1.4 Synthèse

Les outils développés par LASCOM sont issus de la gestion des systèmes complexes

et du monde de la CAO. En 20 ans, les modes de conception et d’utilisation d’un PLM ont

changé, le cercle fonctionnel s’est élargi à d’autres activités et à d’autres types d’utilisateurs.

Mais surtout les clients recherchent des outils qui s’adaptent à leur besoin et à leur

méthodologie de travail et ils ne sont plus prêts à s’adapter à l’outil. Ainsi, pour rester

concurrentiel sur le marché du PLM, il est primordial d’adopter une stratégie de baisse du

coût de la solution et d’accélération de sa mise en fonctionnement effective chez le client.

L’un des premiers freins à cette stratégie provenait de la méthodologie employée qui

consistait à créer complètement une solution par client. Au regard des délais et de la

méthodologie d’approche, les solutions choisies étaient dédiées et développées relativement

au seul besoin exprimé par un client. La standardisation des développements n’était pas

primordiale et la réutilisation était donc souvent fastidieuse voire impossible de part sa

spécificité. La première étape de la « verticalisation » consista à développer des plateformes

pré-paramétrées en fonction du secteur d’activité avec un modèle de données, un certain


Page 81

nombre de fonctionnalités et de processus basés sur la récupération des développements

réalisés historiquement pour un client. L’idée était de permettre un déploiement « éclair ».

Cette « spécialisation globale » permet aux clients de percevoir la solution PLM de LASCOM

comme un ensemble prêt à installer, répondant à leur besoin et à leurs usages aux

paramétrages près, et ce sans surcout, ni délai supplémentaire. Les mécontentements

apparurent lorsque les clients souhaitèrent encore plus « personnaliser » l’application et que

cette démarche s’avéra très complexe de part le caractère malgré tout figé et générique du

cœur de la solution. LASCOM eut donc à répondre à des demandes de plus en plus fréquentes

de modifications gratuites, voire d’évolutions, qui mettaient les projets en périls. Les clients

étaient convaincus de leur bon droit dès lors que leur demande apparaissait à leurs yeux

comme du paramétrage. Or peu d’éléments étaient vraiment paramétrables, car le travail de

standardisation n’avait pas vraiment été réalisé et il était souvent complexe et coûteux de

réaliser ces modifications dans la base existante de l’outil. Face à cet échec il était essentiel de

prévoir un maximum d’éléments paramétrables pour réduire les temps d’adaptation de l’outil

mais aussi de prévoir plusieurs modèles ou types de besoin pour un même secteur afin de

répondre plus précisément aux spécificités du client. Les « nouvelles » applications

verticalisées se sont alors améliorées et enrichies avec pour objectif non pas d’obtenir des

solutions prêtes à l’emploi mais des solutions prêtes à être paramétrées. Mes premiers travaux

de recherche chez LASCOM concernaient le développement de telles solutions. Le principal

verrou à lever pour que ces solutions voient le jour concernait la prise en compte de la

multiplicité des profils utilisateur (et donc des paramétrages) et la simplification de

l’utilisation de l’application pour le plus grand nombre d’utilisateurs afin d’élargir son cadre

d’utilisation.

D’un point de vue « technique » ceci implique la simplification du modèle de données, de

l’interface homme machine (IHM) et la création d’un catalogue de fonctionnalités

interopérables et adaptées à l’ensemble des profils visées (Voir Annexe 3).

D’un point de vue plus « méthodologique », il va être essentielle de travailler à l’implication

des utilisateurs dans les phases très amont du projet, bien avant que la solution soit mise en

place. La section suivante présente nos préconisations quant aux évolutions nécessaires de la

démarche de déploiement de LASCOM pour favoriser une adaptation encore plus forte aux

contraintes clients.


Page 82

2.2 Vers une évolution de la démarche de déploiement de la solution

Choisir un progiciel de gestion intégré est un moment des plus importants pour le

développement d’une entreprise et pour sa survie face à la concurrence. Au regard du coût

d’un tel projet, l’entreprise doit tenir compte de ses besoins actuels et futurs mais également

de ses expériences antérieures. Quelque soit la méthodologie ou le logiciel mis en place et sa

performance supposée, son intérêt ne sera avéré que s’il est approprié aux besoins de

l’entreprise, à son organisation et à ses activités. Cette informatisation induit très souvent la

reconstruction d’une communauté autour de nouveaux modes de coopération et les échecs

constatés lors de l’implémentation d’un tel logiciel proviennent régulièrement d’un manque

de préparation des équipes projets quant à la gestion de cette problématique communautaire.

Autre facteur aggravant pour les équipes, leur manque de connaissances de ce type de projet

et des outils à mettre en place. Ces facteurs d’échec conduisent les équipes à négliger les

impacts tant techniques qu’organisationnels et humains de la mise en place de la solution. Les

effets « organisationnels » des logiciels de gestion sont nombreux :

- Ils modifient la structure de l’organisation par la création de nouveaux services et la

réorganisation des services informatiques,

- Ils font évoluer la nature, la circulation et les modes de création de l’information,

- Ils affectent le processus de décision, les processus de contrôle et la culture de

l’organisation.

Ces effets sont souvent perçus comme ne concernant que des petites parties de l’entreprise

alors que c’est l’entreprise dans son ensemble qui est impactée. Aujourd’hui, pour des raisons

financières et de délais, l’approche globale au niveau de l’entreprise est généralement

galvaudée au profit d’une analyse plus succincte (mais plus rapide) qui ne se concentre

uniquement que sur les besoins pré-définis dans le cahier des charges. Il n’existe ainsi pas de

réelle phase de lancement de projet qui permettrait à l’intégrateur de prendre la mesure de

l’entreprise dans son ensemble et de mieux comprendre et d’appréhender ses besoins, sa

culture organisationnelle et son mode de fonctionnement pour le produit/projet à considérer

dans le logiciel. Ceci semble incohérent de par l’impact du contexte de l’entreprise sur le

cycle de conception, mais cette phase n’est aujourd’hui jamais prise en compte dans le projet

car il semble trop couteux d’effectuer cette analyse complémentaire. Sous estimer cette phase

induira inévitablement des questions complémentaires par la suite, provoquant

indubitablement des dépassements lors des spécifications pour combler les lacunes, voire des

omissions essentiels au bon fonctionnement. Dans ce cas de nombreuses itérations


Page 83

client/éditeur apparaitront lors des tests pour arriver à faire que l’outil s’intègre dans

l’organisation de l’entreprise. Ces itérations conduisent à des modifications souvent plus

couteuses que si ces éléments avaient été pris en considération dès le départ du projet.

Pour éviter ce travers, il faudra dépasser deux obstacles. D’une part la pression commerciale

ou du client qui lors de la négociation va chercher à diminuer considérablement, voire

supprimer, cette phase de lancement de projet. Et d’autre part, les habitudes de travail prisent

chez l’éditeur qui sont elles aussi des freins à la réalisation d’une phase de lancement efficace

et profitable pour le client et l’éditeur. Une évolution de l’état d’esprit du client et de l’éditeur

passera selon nous par la mise en place d’une nouvelle démarche de déploiement au sein de

chez LASCOM. Nous nous proposons de décrire dans cette section les phases « amont » du

déploiement, les phases qui font suite au déploiement seront présentées dans la section

suivante.

2.2.1 Définir le cadre du projet : le périmètre, les acteurs, les interlocuteurs potentiels

Le projet d’implantation est souvent considéré de manière différente si l’on se place

du point de vue du client ou du point de vue de l’éditeur. Le client considère cette démarche

comme un pas vers l’amélioration de son processus et donc de sa productivité à travers

l’énoncé de ses besoins. Pour l’éditeur, le projet est généralement considéré comme un

« simple » déploiement de sa solution, adaptée pour un client. Les enjeux ne sont donc pas du

même ordre. Le chef de projet coté éditeur se cantonnera bien souvent aux besoins énoncés

par le client alors que le projet doit s’inscrire dans un contexte global et l’application devra

prendre place dans un ensemble pour faire un tout afin d’aboutir aux résultats escomptés par

le client. L’organisation de cette réflexion est généralement dictée par les informations

présentes dans le cahier des charges fourni à l’éditeur en amont du projet de déploiement. Ce

document recense les besoins et attentes mais le problème lié à sa rédaction vient du fait qu’il

est produit avant le choix du logiciel et donc avant de connaitre les possibilités du logiciel et

les éléments nécessaires à sa « personnalisation ». Ce document est donc souvent mal adapté

car il n’existe pas vraiment de cohérence entre les besoins et les possibilités de l’outil. Cette

incohérence est d’autant plus dommageable qu’elle peut perdurer relativement longtemps

dans le projet. De plus, le cahier des charges est généralement réalisé par plusieurs personnes,

avec des profils différents, sans forcément de concertation sur l’ensemble des détails et

souvent sans le chef de projet côté client qui sera effectivement en lien direct avec l’éditeur.

En effet, le cahier des charges peut être émis des mois voire des années avant la phase de

spécification de l’outil et il n’est pas rare que les chefs de projet changent. Des contradictions


Page 84

apparaissent donc souvent dans les cahiers des charges, d’autant plus si le projet est

d’envergure et que le chef de projet coté client a du mal à comprendre le besoin et le

fonctionnement réel de la solution. Dans quasiment tous les projets, le client va chercher à

remédier à ces contradictions par des actions en « internes » : le chef de projet en réfère aux

différents responsables, qui eux même si besoin est, verront avec les utilisateurs, puis il

revient vers l’éditeur pour lui faire part des résultats. Dans cette démarche, il n’est quasiment

jamais prévu que l’éditeur puisse participer à ces séances d’éclaircissement ou à des réunions

avec les différents utilisateurs. Ceci est d’autant plus dommageable que sa présence pourrait

éviter des « pertes » de temps et que l’identification au plus tôt des différents profils des

futurs utilisateurs est essentielle pour mieux appréhender leurs besoins mais également leur

façon de travailler. Prendre en considération les habitudes de travail des utilisateurs « clés »

de l’application permet de limiter la résistance naturelle aux changements car ils se retrouvent

au cœur du système.

Principe 1 : Pour que les deux parties trouvent un avantage à long terme au logiciel, il est

essentiel d’intégrer la nouvelle application dans son contexte mais également de faire

participer les futurs utilisateurs le plus tôt possible dans le processus de déploiement pour

créer un outil adapté à l’entreprise mais surtout aux futurs utilisateurs actifs.

Le point clé selon nous d’une analyse du contexte réussie va résider dans la capacité du chef

de projet « éditeur » à cerner l’entreprise dans toute sa complexité : de sa structure globale

aux utilisateurs finaux. Il doit pour se faire s’appuyer sur des interlocuteurs solides au sein de

l’entreprise. La démarche de LASCOM ayant montré ses limites dans ce domaine, c’est donc

toute cette démarche, notamment dans les premières phases du processus de déploiement

(Expression du besoin, Etude de marché, Cahier des Charges, Chapitre 2, section 3.2, Figure

6) qui doit être revue.

2.2.2 Des phases clés : avant-projet et après projet

Une des problématiques à la source des retards pris durant le projet était le manque de

connaissance sur le client, plus particulièrement sur le projet et son contexte. Une des

possibilités pour accroître le degré de connaissance du projet et de la solution logicielle serait,

pour l’éditeur, d’entrer dans l’entreprise en amont du lancement du projet. Cette présence peut

être faite soit par l’éditeur, soit par un tiers (un intégrateur, un partenaire ou une filiale de

consulting), l’objectif étant d’une part d’aider l’entreprise à mûrir leur projet et d’autre part de


Page 85

récolter un maximum d’information sur le projet avant le lancement officiel du projet pour

constituer l’environnement de ce dernier. Quelque soit l’intervenant en amont, l’ensemble des

connaissances sur le client et sur le projet doivent être formalisé et transmis aux différents

acteurs, côté éditeur/intégrateur, du processus en aval. L’adjonction de ces connaissances au

cahier des charges permettront d’acquérir une vision plus globale du projet et de son contexte

et ainsi d’accélérer les spécifications, ce qui permettra d’approfondir sereinement les aspects

liés aux utilisateurs. A l’origine d’un projet, deux cas peuvent se présenter, soit le projet

concerne un client existant et il en a parlé à un de ses interlocuteurs privilégiés (commercial,

chef de projet, support…), soit c’est un prospect qui a été contacté par un mode de

prospection ou un tiers qui a prévenue le commercial. Cette entrée en amont du lancement de

projet est plus ou moins complexe à réaliser en fonction de ces deux modes et du lien existant

entre l’éditeur et le demandeur.

Aujourd’hui, dans des projets de grande envergure, une relation étroite est souvent instaurée,

dû aux forts enjeux et à la durée du projet, entre le client et le chef de projet. Cette évolution

permet de mieux appréhender la complexité du déploiement de la solution coté client et offre

la possibilité d’échanger d’avantage sur le mode de fonctionnement de l’entreprise cliente, des

impacts que peut engendrer ce type de projet sur l’organisation. Finalement, ces discussions

permettent d’améliorer la qualité des spécifications en ne se contentant pas uniquement de

traiter les besoins initiaux du cahier des charges sans analyse complémentaire, mais en

affinant en fonction des besoins réels. La solution mise en place correspond alors

naturellement aux méthodes et habitudes de travail de l’entreprise, facilitant la montée en

charge et l’acceptation du logiciel par les différents utilisateurs. La qualité de cette relation de

confiance, établie entre les intervenants durant les phases antérieures à la mise en production,

favorise et facilité les prises de contacts en cours d’exploitation en cas de soucis ponctuel ou

d’émergence de nouveaux besoins. Des évolutions sont alors envisagées (technique,

fonctionnel, ergonomique…) naturellement, pour parvenir à ajuster au plus près le logiciel

aux besoins réels des utilisateurs finaux ainsi que l’ouverture du système à de nouveaux

profils, donc à de nouvelles fonctionnalités. Ce mode de fonctionnement est possible, car le

projet est constitué de plusieurs phase, autrement dit le client commande régulièrement des

améliorations, conclusion le chef de projet travaille quasiment continuellement sur le projet.

Dans le cas présent, d’un projet élaboré par phase, la problématique de captation des

informations en amont existe mais ne met pas en péril le projet, car d’une part le client est

conscient de la complexité du projet et apporte assez naturellement des explications sur le

cadre de ces besoins, et d’autre part ces retards sont souvent négligeables sur la durée. Par


Page 86

contre, ce mécanisme n’est pas généralisable à tous les projets, car nombreux sont ceux où les

délais d’obtention de la solution finale sont réduits et ne tolèrent aucun retard. Il est donc

nécessaire d’obtenir ces informations en dehors du cadre du projet et idéalement avant même

le lancement du projet pour établir des devis avisés.

Hormis les grands projets, cette prise d’information peut être réalisée malgré tout plus

facilement avec les clients existants lors de nouveaux projets (demande d’amélioration,

élargissement du cadre fonctionnel par exemple). Soit parce qu’ils ont opté pour

l’accompagnement fonctionnel (décrit dans le chapitre 3 section 2.3.2) durant la phase

d’exploitation et dans ce cas toutes les informations sont récoltées au fur et à mesure par

l’éditeur. Soit parce qu’il est possible de proposer des audits réguliers d’un panel

d’utilisateurs dans un souci d’optimisation et d’amélioration continue pouvant s’inscrire dans

une politique qualité du client. Les intérêts de ces actions sont non seulement d’accroître la

satisfaction client, d’identifier les améliorations à apporter au produit, de capitaliser

l’expérience mais également d’identifier dès leur émergence les futurs besoins sur la partie

fonctionnelle existante, pour être force de proposition ou de conseil en établissant un lien fort

de confiance, ouvert à la discussion.

Dans ce cas, l’ajout de cette étape dans le cycle de vie du projet permet d’apporter une

nouvelle brique au processus, créant une jonction entre l’exploitation et le lancement d’un

nouveau projet, basée sur la capitalisation des retours d’expérience propre au client dans le

but de proposer des axes d’amélioration de la solution ou du support et d’affiner les besoins

en évitant de réitérer les erreurs tant d’implémentation que de déploiement. Dans ce cas,

contrairement au schéma proposé précédemment, le projet n’est plus linéaire mais cyclique

s’inscrivant dans une boucle d’amélioration continue (Figure 10).


Page 87

Figure 10. Cyclicité du processus d’informatisation

Ce schéma peut également être proposé dans le cadre d’un nouveau client par le biais d’un

audit permettant d’affiner leur besoin. Cette incursion dans l’entreprise révèle différents

avantages, d’une part elle permet de mieux connaitre les clients ou prospects, ces derniers

découvrent l’éditeur ou les nouveaux produits qu’ils proposent tout en leurs permettant de

faire un état des lieux de leurs besoins. Il est important dans ce cas, d’arriver en avant projet,

lorsque la définition du besoin n’est pas encore totalement établie, car selon les types de

marché public ou privé, l’obtention d’une telle prestation est quasiment impossible. Dans ce

domaine, un certain nombre de service de consulting existe, mais généralement ils sont soient

expert dans le métier de l’entreprise, soient expert informatique. Dans les deux cas, le cahier

des charges émis via une prestation de consulting, cumule différents niveaux d’interprétation


Page 88

du besoin dans son contexte et intègre une sémantique souvent approximative tant du métier

que de l’informatique pouvant altérer la définition des besoins, faussant leur perception et leur

compréhension. C’est un besoin réel pour les entreprises en quêtes d’une solution

informatique tant pour affiner leur expression de besoin, que pour établir leur cahier des

charges, que pour définir le type de logiciel. Malheureusement, cette option est difficilement

réalisable directement tant que la prestation n’est pas reconnue sur le marché, voire dissocier

de l’éditeur. L’accent doit donc être mis sur les clients existants potentiellement source de

projet pour eux, mais il constitue aussi les meilleurs ambassadeurs de la solution qu’il utilise

vers l’extérieur. Cette nouvelle étape offre un suivi personnalisé non pas uniquement

commercial mais également technico-fonctionnel. L’intérêt est de pouvoir établir et conserver

un lien fort avec le client, assurer un suivi de la satisfaction utilisateurs et favoriser la

capitalisation des retours d’expériences clients. Ce service permet de rassurer le client et

établir un climat de confiance. Si les utilisateurs sont satisfaits et si l’entreprise constate une

valeur ajoutée à la prestation, le produit et les services associés, elle sera amenée à divulguer

plus facilement les futurs projets en amont des différentes étapes d’analyse et de recherche de

solution. Dans ce cas, si le besoin correspond au contour fonctionnel de l’éditeur, il sera

souvent plus simple pour l’entreprise de choisir une extension de la solution existante que

d’apporter un nouveau logiciel au sein du système d’information. Cette relation, du type

gagnant/gagnant basée sur la satisfaction client, sort du métier de l’éditeur, car il ne vend plus

uniquement un produit mais un package dans lequel le produit est tout aussi important que les

services. Mais finalement, l’éditeur n’est pas perdant, car indirectement, si la relation devient

une véritable collaboration, cela lui assure un taux de renouvellement important voire même

l’accroissement du nombre de licence vendu grâce aux extensions, mais également grâce à

l’ouverture vers d’autres clients potentiels grâce à la publicité réalisée directement par les

clients satisfaits.

Ainsi, cette structure cyclique basée sur l’accompagnement permet non seulement d’assurer la

présence de l’éditeur chez le client en amont du processus classique (linéaire), mais également

de favoriser et améliorer la collaboration grâce aux quatre préceptes suivant :

- Se positionner en tant qu’interlocuteur privilégié : être connu et reconnu tant par les

décideurs que les utilisateurs pour intervenir en amont des projets

- Limiter le nombre d’interlocuteur durant le projet : la mise en place d’une équipe

efficace prend du temps tant sur des aspects humains, organisationnels ou techniques

pour favoriser l’efficacité et la qualité du service.


Page 89

- Anticiper les besoins de l’entreprise et des acteurs : pour parvenir à une définition du

besoin plus précise, autrement dit un outil adapté à l’ensemble des utilisateurs.

- Se centrer sur le client : rendre le client participatif à l’évolution du produit et être sur

que les évolutions correspondent à des besoins réels des clients, du marché.

Pour optimiser le processus de déploiement et éviter des itérations lors des étapes décisives de

spécification et de modélisation, la solution proposée ici est d’ajouter une étape

d’accompagnement pouvant prendre différentes formes en fonction des besoins et reliant la

fin d’un projet au début d’un autre. Ce qui permet de passer d’un processus de déploiement à

un cycle de déploiement.

Principe 2 : L’acteur doit être au centre des préoccupations des éditeurs, non seulement dans

la philosophie de construction de la structure de base du logiciel, mais également lors de la

conception de la solution propre à une entreprise.

Un travail devra être mené au niveau de la solution de LASCOM pour que celle-ci puisse

fournir toutes les informations en temps utiles aux utilisateurs en fonction de leurs activités

mais aussi puisse faire que les données, les fonctionnalités et plus généralement l’ergonomie

soient personnalisables pour s’adapter aux besoins propres à chacun des utilisateurs.

Le fait de vouloir faire participer très tôt un nombre d’utilisateurs important va obliger

LASCOM à revoir sa politique de communication et d’accompagnement. D’une part, lors des

premières phases du processus pour créer puis entretenir une vraie dynamique autour du

projet. D’autre part, durant les phases de déploiement et de tests pour que les informations et

les échanges se fassent rapidement et efficacement. Enfin, lors de la phase d’utilisation de

l’outil pour accompagner au mieux les utilisateurs et montrer que LASCOM est un éditeur

avec une offre « globale » et un suivi sur le long terme.

2.3 Communiquer, former et accompagner le client pour être efficace

2.3.1 Des actions de communication/formation de plus en plus en amont

L’élargissement du contour fonctionnel et l’anticipation des besoins lors des phases

« amont » de la démarche vont obliger LASCOM à modifier ses actions de formation vers les

clients. En effet, la formation ne se cantonnait jusque là qu’à apporter aux futurs utilisateurs

les bases nécessaires en vue d’une exploitation quotidienne de l’application. La formation


Page 90

présentait les fonctionnalités les plus usitées mais ne mettait pas en avant les concepts de base

de la solution et plus globalement d’un PLM. Cette démarche contribuait à construire une

certaine capacité à utiliser l’application mais ne permet pas de limiter la réticence aux

changements car elle se faisait trop tardivement, lorsque l’outil était déjà en place.

Nous proposons d’avoir des actions de communication/formation bien avant la mise en place

de l’outil pour que l’éditeur puisse faire passer les concepts du PLM, valoriser l’utilisation de

l’application comme vecteur de performance et donc contribuer à limiter les résistances aux

changements. Mais un autre objectif fondamental de la démarche est de permettre la détection

des réticences et des difficultés éprouvées par les futurs utilisateurs très tôt pour tenter d’y

remédier. L'implication des utilisateurs durant le projet de déploiement de la solution est

primordiale d’une part pour vérifier les besoins, comprendre le mode de fonctionnement et

pour atténuer la réticence aux changements. Le degré d'implication des utilisateurs dans

l'implantation de nouvelles technologies d’information, constitue un facteur clé de succès

pour la conduite du changement. L’adhésion au projet se révèlera difficile si l’implantation du

PLM n’est pas ressentie comme une nécessité par les collaborateurs mais plutôt appréhendée

comme une source de difficultés par rapport à l’impact sur les métiers et la circulation de

l’information.

Les analyses de la situation existante en avant-projet doivent être minutieuses car elles vont

contribuer largement à déceler les points sur lesquels il faudra insister pendant la phase de

communication/formation. Étant donné que les utilisateurs sont rarement impliqués dans les

phases de conception de la solution PLM, la formation constitue souvent la première

interaction entre l’outil et les utilisateurs actifs et/ou passifs. Pour les premiers, l’objectif est

de comprendre l’intérêt de l’outil et se familiariser avec lui pour favoriser son utilisation

quotidienne et faire en sorte qu’ils soient force de propositions. Pour les seconds, le but est de

connaitre l’existence de l’outil et ses capacités pour être en mesure de trouver et d’utiliser les

informations mises à leur disposition et valoriser son utilisation. Dans les deux cas, il est à

prévoir qu’il y aura après la phase de formation, une phase d’apprentissage mais aussi une

phase d’assimilation : l’utilisateur a une vue globale du fonctionnement du PLM mais encore

faut-il qu’il saisisse les détails des actions qu’il sera capable de développer. Pour que les

phases d’apprentissage et d’assimilation se déroulent correctement, il est important de ne pas

laisser les utilisateurs seuls face à ce nouvel outil. En effet, selon le profil de l’usager et son

niveau de compétence en informatique au sens large, l’arrivé de ce nouvel outil peut

désarçonner un acteur, le bloquer dans son travail quotidien, voire être perçu comme une


Page 91

intrusion dans son travail de tous les jours avec une sensation d’être « surveillé » (avec le

traçage des activités, l’apposition de son nom automatiquement, la présence d’indicateurs…).

Principe 3 : Les actions de communication et de formation à destination des futurs usagers

doivent être fréquentes, suivies et construites relativement à une situation clairement définie.

De telles actions ne sauraient être « standardisées » et se doivent de montrer la volonté

farouche de l’éditeur d’intégrer aux plus tôt les utilisateurs finaux et de les accompagner tout

au long de la vie du projet et de la solution.

2.3.2 Un accompagnement sur le long terme : une hotline au service du client

Aujourd’hui dans le déroulement d’un projet type, au moment du déploiement à

grande échelle, le lien entre l’éditeur et le client est constitué du commercial et de la hotline,

normalement le chef de projet ne devrait pas être sollicité mais cela peut arriver. En effet,

l’entreprise opte généralement pour une formation initiale de tout ou partie des utilisateurs et

des administrateurs, puis elle réalise ses formations en interne. Elle ne prévoit pas dans ses

budgets la possibilité de réaliser une « formation complémentaire » suite au début de

l’utilisation de l’outil par le plus grand nombre, générateur de questions et de doutes.

Généralement, pour résoudre les difficultés des utilisateurs, un premier niveau de support est

réalisé en interne le temps du démarrage des utilisateurs. Quand ces derniers ne possèdent pas

la réponse, en fonction du type de question ils font appel soit à la hotline pour les problèmes

techniques, soit au commercial pour évoquer des nouveaux besoins, soit, selon sa

disponibilité, à l’ancien chef de projet pour des explications fonctionnelles. Malheureusement,

pour certains projets d’ampleur, le déploiement peut prendre beaucoup de temps, et au

moment où l’entreprise à besoin d’un support « spécifique », soit les intervenants du projet

sont toujours là mais ne se souviennent plus forcément de l’ensemble des spécificités du

projet, soit ils ne sont peut être plus dans les effectifs de l’entreprise, dans les deux cas, le

temps nécessaire pour répondre aux questions du client est relativement long et couteux. La

pérennité d’une solution ne se base pas uniquement sur la qualité de l’outil au regard des

besoins au moment de la livraison, ni sur sa capacité d’évoluer, mais bien sur son utilisation à

long terme par les utilisateurs. L’entreprise doit être consciente que la mise en place d’une

cellule support interne est primordiale pour que les personnes ne restent pas démunies non

seulement face au nouveau logiciel, mais également face aux nouvelles méthodes de travail

imposées, c’est un élément essentiel concourant à une politique d’accompagnement aux

changements. Ce service ne peut pas être sous traité facilement, car la connaissance des


Page 92

procédures interne, des habitudes de travail… est capital pour apporter le bon niveau de

réponse. Par contre au niveau logiciel, la qualité de service n’est pas homogène de part la

diversité des problématiques. On peut distinguer deux types, le niveau technique (les bugs) où

la réponse est de se référer au support technique de l’éditeur et le niveau fonctionnel où

normalement la formation, la documentation et l’expérience constituent les seuls sources de

réponse. Aujourd’hui, si la réponse n’est pas trouvée au sein de la cellule, dans le meilleur des

cas, la question sera posée au support technique, qui ne connaitra pas forcément pleinement

leur application et qui tentera de trouver une solution pour leur problème précis, mais n’aura

pas le temps de former véritable la personne, d’analyser le cadre du besoin… ou au chef de

projet s’il est toujours joignable. Dans le pire des cas, la réponse se restreindra à l’usage

courant de l’application, à leurs connaissances du logiciel et tout élément hors de ce cadre

sera jugé comme impossible. Ce cas peut être problématique, car il se base sur des

connaissances et des compétences humaines, et non pas sur les capacités du logiciel. L’éditeur

est normalement plus apte à répondre aux difficultés rencontrées, aux demandes particulières

et d’identifier les évolutions potentielles des incompréhensions. Autrement dit, pour améliorer

la qualité du support interne, l’éditeur pourrait avoir un rôle de conseil fonctionnel pour

utiliser au mieux son logiciel envers la cellule support du client en plus du support technique.

L’avantage pour le client est d’assurer un meilleur niveau de service, favorisant l’utilisation et

améliorant ainsi le taux de rentabilité du projet, mais également d’obtenir des devis plus

adapté à ses besoins. En effet, en étant plus près des réalités du terrain, des difficultés des

utilisateurs, il aura une vision plus claire des demandes formalisées. L’évaluation des

demandes d’évolution se basera donc non pas uniquement sur un simple cahier des charges,

mais sur les expériences du terrain contenant des habitudes d’utilisations et souvent des

besoins sous-jacents mineures qui ne sont pas budgétés. Cette solution d’association a

également des avantages pour l’éditeur, et ce quelque soit les capacités du client. D’un point

de vue produit, les retours peuvent faire émergence des évolutions ou des améliorations de sa

solution et ainsi enrichir son catalogue. D’un point de vue stratégique, il va également

accroître sa connaissance du marché en acquérant des connaissances plus précise sur le métier

et les besoins de son client et d’un point de vue méthodologie projet, en validant l’adéquation

entre la solution réalisée et les besoins réels des utilisateurs et faire émerger des

disfonctionnements ou des manques.

Finalement, il est essentiel de prendre soin ne de pas laisser le client totalement en autonomie

sur sa solution après son installation, pour que la solution conserve sa place clé au sein de


Page 93

l’entreprise en répondant continuellement aux besoins des utilisateurs. Si des difficultés

apparaissent et que le client est en autonomie soit :

- elles sont trop importantes et il abandonne la solution ce qui représente une perte

importante pour les deux parties,

- son niveau de compétence du client et de ses capacités techniques lui permettent de

développer lui-même les éléments nécessaire à répondre à ses besoins au lieu de

contacter l’éditeur, ce qui représente d’une part une perte pour l’éditeur, tant sur la

vente de service ou de module que sur l’évolution de sa solution globale en fonction

au marché.

Les retours d’expérience sont des éléments stratégiques pour l’évolution d’un logiciel afin de

continuer à coller aux besoins du marché. En l’absence de contact autre que commercial et

support technique, bons nombres de ces informations, qui pourraient être cruciales, sont donc

perdus dans les méandres des boites vocales, mails ou couloirs de bureaux, voire restent

uniquement chez le client. La création de ce type de service apparait importante et nécessite

de mettre des ressources dédiées à cette tâche uniquement. En effet, il semble difficile de

demander aux mêmes personnes que celles du support technique, car une personne au profil

trop technique aura du mal à prendre de la distance avec la technologie, que ce soit lors de la

compréhension du problème énoncé, de la réponse, que lors de la définition des besoins pour

l’évolution du produit (ergonomique et fonctionnel). La mise à disposition d’un support

fonctionnel est donc tout aussi essentiel qu’un support technique pour accompagner le client

tout au long du cycle de vie de l’application et pas uniquement jusqu’au déploiement.

L’intégration du concept de hotline fonctionnelle amène une nouvelle dimension au projet en

plaçant les retours d’expérience utilisateurs au cœur de la stratégie de l’éditeur pour continuer

à proposer un logiciel en adéquation aux besoins de ses clients. La généralisation de cette

proposition est un investissement important pour les éditeurs, sans garantir systématiquement,

pour chaque projet, le recueil d’information innovante. Mais un des différentiateurs important

entre les deux niveaux de support est leur évolutivité dans le temps, en effet pour un projet

donnée, les problèmes techniques existeront constamment, alors que les explications sur le

fonctionnel vont diminuer dans le temps pour devenir des nouvelles demandes et prendre un

caractère plutôt d’avant vente pour des nouvelles commandes. Autrement dit, la demande

n’est pas constante dans le temps et présente des pics important lors du début de

l’exploitation, puis lors du déploiement du logiciel auprès des groupes d’utilisateurs. Une des

propositions pourrait être alors de proposer ce service sous deux formes, dite « en régie »,

c'est-à-dire sur site, dans un premier temps, pour accompagner la cellule de support et


Page 94

apporter son expertise sur la politique aux changements, et à chaque fois que nécessaire, puis

passer sur un système de hotline classique à distance.

Principe 4 : Les actions d’accompagnement après la mise en place de la solution doivent

s’effectuer chez le client pour participer à la mise en place d’une cellule « interne » d’experts

puis, lorsque la cellule est opérationnelle, se faire à distance par le biais d’une hotline

« classique » et ce tout au long de la vie de la solution.

L’accompagnement doit aller au delà d’une simple formation et doit perdurer tout au long du

cycle de vie de la solution. Cette assistance doit pouvoir répondre à toutes les thématiques

autour du produit en particulier techniques et fonctionnels. Elle rassure le client et lui évite de

rester bloqué sur une problématique qui n’en est peut être pas une. Dès lors le logiciel ne

constitue plus juste une boite noire, sans vie, incompréhensible malgré la documentation ou

les formations, d’un point de vue client et surtout utilisateur, mais un outil du quotidien

utilisable par chacun à son rythme et à sa façon. En améliorant la durée et la qualité du

support fonctionnel, les utilisateurs ont la possibilité d’assimiler au fur et à mesure de leurs

besoins les différentes possibilités et fonctionnalités de l’application et faciliter ainsi

l’acceptation et d’adéquation des utilisateurs au logiciel, voire d’amélioration continue du

process et du logiciel.

3 Synthèse

La pérennité d’une solution PLM dans une entreprise est garantie quasiment

essentiellement par le fait que les utilisateurs se l’approprie. Pour ce faire, nous avons proposé

de revoir les phases critiques du processus de déploiement pour faire que les utilisateurs

soient parties prenantes très tôt du projet et de son développement et ce jusqu’à la fin de

l’exploitation de la solution. Les utilisateurs doivent être perçus comme le maillon essentiel

du développement et du déploiement d’une solution dans une entreprise et comme une source

d’amélioration continue de celle-ci de part leurs interactions quotidiennes avec elle.

Nous étudierions dans le chapitre suivant les outils support à la démarche qui contribueront au

respect des 4 principes énoncés ci-dessus. Nous ne nous focaliserons malgré tout pas sur les

aspects liés à la communication/formation et à la hotline car ils ne relevaient pas du domaine

de compétences qui était le notre au sein de l’entreprise LASCOM. Nous nous centrerons


Page 95

donc essentiellement sur les outils support à la modélisation des processus et à l’émergence

des profils utilisateurs.

Chapitre 4 Adapter l’approche et le dialogue « client »

Page 97

Chapitre 4

Adapter l’approche et le dialogue « Client » : un vecteur de

performance

1 Introduction

Un logiciel PLM, une fois défini et implémenté pour un client, constitue un produit

unique propre à l’entreprise qui structure son produit/projet. Ceci explique qu’il n’existe pas

d’application prête à l’emploi efficace sur le marché des logiciels car, contrairement aux

logiciels de bureautique, il ne suffit pas de demander ou d’imposer aux acteurs de s’adapter à

ce dernier. En effet, dans le cadre de logiciels PLM c’est toute la logique de travail qui est

impactée car l’enjeu se situe au cœur du savoir-faire de l’entreprise. Le niveau de satisfaction

client sera donc évalué non seulement sur le logiciel fourni au regard des besoins énoncés -

besoins stratégiques, mais aussi par son taux d’utilisation - besoins locaux, et la qualité des

services gravitant autour du produit (projet, support technique et fonctionnel, audit, etc.) -

besoins opérationnels.

Dans le cadre de ce type de logiciel, le fonctionnement est basé sur la hiérarchisation des

différents types de données et le mode de traitement de ces dernières au cours du cycle de vie

du produit/projet. Cette modélisation est conçue pour une entreprise et doit être représentative

de la réalité opérationnelle et non pas uniquement théorique. La qualité de ce travail constitue

l’enjeu majeur pour favoriser la cohérence et la performance de la solution PLM vis-à-vis de

l’entreprise. L’importance de l’étude réalisée durant les premières étapes du processus

d’informatisation, et plus spécifiquement durant les spécifications, apparait comme la clé de

voute de l’optimisation tant du ratio coût/qualité que du résultat informatique. L’amélioration

du cycle de déploiement repose donc essentiellement sur la définition et la qualité des

spécifications finales. Cette définition dépendra à la fois du niveau de granularité de la

modélisation pour aboutir à une solution la plus proche des besoins réels, mais aussi de

l’exhaustivité de la documentation associée. En effet, cette étape d’analyse constitue le cœur

du produit fini car elle explicite les besoins, elle imagine des solutions à créer dans le logiciel

et elle valide les solutions théoriques retenues sous forme textuelles. Les documents qui en

sont issues (les spécifications fonctionnelles) composeront la référence commune entre

l’éditeur et le client d’un point de vue fonctionnel et formeront la base documentaire pour le

support afin de répondre rapidement et spécifiquement aux demandes, mais aussi lors de


Page 98

commandes d’évolution pour vérifier les aspects fonctionnels et adapter le devis (que la

demande soit une adaptation d’une fonction existante ou une création). Pour obtenir une

solution cohérente aux besoins de l’entreprise et un niveau de service optimum il est

nécessaire d’aboutir à la fin des spécifications à une modélisation la plus détaillée et la plus

réaliste possible tant au niveau local, pour répondre aux besoins, qu’au niveau global, pour

intégrer la solution dans son environnement, c’est à dire pour prendre en compte tous les

besoins connexes et les enjeux.

Pour assurer l’efficacité de la modélisation, nous avons montré dans le chapitre précédent

qu’il est nécessaire d’avoir une démarche de déploiement très structurée et très proche du

client. Au-delà de la démarche, il faut aussi avoir des outils efficaces pour que la phase

« d’opérationnalisation » de la démarche se déroule correctement. Il est primordial d’adapter

le choix des outils supports à la méthode en fonction de l’entreprise (de sa culture), du projet

(de l’existant), de son envergure (de ses capacités), mais surtout du niveau à analyser et donc

des personnes à interroger. L’objectif est d’obtenir le niveau de précision (de granularité)

nécessaire et suffisant en fonction du/des focus et besoins à satisfaire et d’agréger les résultats

de chacun des modèles pour obtenir une vision complète du système à modéliser. La partition

du système en différents n’est pas simple et elle n’est pas appréciée de la même façon selon

les interlocuteurs et leur implication dans l’entreprise. Pour accroître la pertinence et la

complétude du modèle global, il va être important de construire avec le client une partition

(décomposition) partagée du système et de faire intervenir des acteurs de chaque niveau de

décomposition identifié. Cette démarche est un peu différente de ce qui a cours aujourd’hui

puisque se sont souvent les personnes en charge du projet qui travaillent à la décomposition

du système et à la construction des modèles.

Ainsi, même s’il s’avère que plus le niveau d’implication est fort, plus le niveau d’abstraction

est faible, la caractérisation des besoins pour et par l’ensemble des utilisateurs (ou un panel

représentatif) est un véritable enjeu pour l’éditeur et le client. Nous verrons dans ce chapitre

que pour répondre à cet enjeu et respecter les 4 principes que nous avons édicté il est

nécessaire de travailler sur deux axes : d’une part le choix puis la mise en place effective

d’une méthode/démarche de modélisation adaptée au niveau de l’entreprise et d’autre part les

moyens à mettre en œuvre pour placer l’acteur au cœur de la définition des modèles et donc

finalement au cœur du projet et de la solution.


Page 99

2 Le choix de la méthodologie de modélisation : une étape clé

2.1 Problématique générale du choix de la méthodologie

Pour favoriser l’implémentation et surtout l’acceptation de la solution, il est important

d’approcher au plus près la réalité du terrain. L’analyse du besoin et la modélisation

constituent les étapes essentielles tant d’un point de vue organisationnel - pour établir une

relation de confiance avec le client, que méthodologique - pour assurer la qualité des

fonctionnalités demandées. L’établissement d’un climat de confiance, favorisera la

communication et la collaboration avec le client, facilitant et améliorant ainsi la modélisation.

Si ce climat propice est présent tout au long du projet, il sera alors possible d’étudier plus

précisément la définition des processus et des indicateurs de performance ouvrant des

possibilités d’accroître le coté décisionnel des reporting proposés et donc la pertinence de

l’application. Le but est ici de construire un modèle au plus près du déroulement réel du cycle

de vie du produit/projet qui doit être géré dans le logiciel, et ce dans les temps et le budget

impartis pour cette étape. Pour concevoir ce logiciel « unique » et adapté à l’entreprise sur le

périmètre prédéfini, les seules qualités de communicant des interlocuteurs ne suffisent pas et

l’utilisation des méthodologies adaptées et efficaces est primordiale.

Nous avons montré dans le deuxième chapitre (Chapitre 2, §4.2) que bon nombre de

méthodologies (et les formalismes associés) permettaient de modéliser une entreprise, une

organisation, des processus, des activités et des flux. Certaines sont plus particulièrement

orientées sur des aspects stratégiques et généraux (niveau global), d’autres sur des aspects

plus tactiques et opérationnels (niveau local), d’autres enfin permettent l’approfondissement

et la coordination des niveaux les uns envers les autres.

Le choix de la méthodologie doit se faire en fonction des éléments existants (éléments

déjà modélisés précédemment par l’entreprise ou par l’éditeur lors d’un projet précédent), du

projet (complexité, envergure) et également des participants (connaissance du fonctionnement

de l’entreprise, aisance avec des méthodes de modélisation). Mais la méthode à adopter sera

aussi fonction de l’application logicielle implémentée puisque c’est elle qui déterminera les

besoins en termes de « degré de précision » et d’éléments à prendre en compte dans la

modélisation. Enfin, le choix dépendra aussi du contexte lié à l’entreprise et surtout de la

maitrise, de la connaissance et de l’aisance qu’ont les acteurs du projet dans l’utilisation de la

méthode. En effet, en fonction de l’existant et/ou des intervenants il est souvent plus simple,

et surtout plus rapide, soit de partir des modèles existants et d’approfondir la partie à traiter,


Page 100

l’approche descendante, soit de partir de la réalité du terrain et de définir le système

permettant la réalisation du produit/projet, l’approche ascendante.

L’expérience de LASCOM montre que rares sont les entreprises qui connaissent et

utilisent les méthodologies que nous avons précédemment décrites pour modéliser leur

organisation, leur fonctionnement et surtout leurs besoins, sauf dans le cadre d’une

certification portée et réalisée quasi exclusivement par le service qualité. Généralement, ce ne

sont qu’une ou deux méthodologies qui sont utilisées : IDEF0-SADT et IDEF3.

Malheureusement elles n’apportent que des représentations assez statiques et globales de

l’entreprise (par manque de temps de modélisation) qui sont relativement peu exploitables

dans le cadre de la conception et du déploiement d’un PLM. De plus, les retours des

ingénieurs commerciaux de LASCOM montrent aussi que les clients ont souvent du mal

comprendre les modèles censés représenter un objet qu’ils connaissent pourtant bien : leur

entreprise ! Il apparait clairement que les méthodologies « classiques » ne sont pas forcément

appropriées pour mettre en exergues tous les aspects nécessaires à la conception et au

paramétrage des applications. Aucune méthode et aucun formalisme classiquement utilisés ne

peuvent répondre à l’ensemble des critères nécessaires à un déploiement efficace d’une

solution PLM. Pour qu’une méthodologie et un formalisme de modélisation puisse convenir à

la conception d’une application, il faut qu’ils soient :

- Adaptés au paramétrage du logiciel, car le chef de projet doit pouvoir identifier tous

les éléments nécessaires à la conception de l’outil propre au client,

- Adaptés à tous les projets, quelque soit leur complexité et les nombre et le degré

d’expertise des participants,

- Simples, quasiment « intuitifs » et rapides à mettre en œuvre car aucun temps

d’appropriation des concepts et outils n’est prévu dans le cadre du projet,

- Compréhensibles par tout un chacun, car plus le support est simple, plus la

communication est facilitée et plus il est aisé d’impliquer un grand nombre de

personnes dans la mise en place de l’outil afin d’obtenir un produit répondant à toutes

les attentes.

Quand bien même, la méthodologie choisie est adaptée au projet et au logiciel,

compréhensible par tous et ni trop complexe ni trop chronophage, il est primordial de prendre

en compte un temps nécessaire pour informer et valider l’utilisabilité d’une méthodologie (ou

d’un formalisme) dans le cadre du projet. Information qui doit concerner tout ou partie des

intervenants tant au niveau global qu’au niveau local. Malheureusement cette phase n’est

généralement pas prévue lors du chiffrage de l’application et doit donc rentrer dans le cadre


Page 101

des spécifications, diminuant d’autant leur durée et détériorant ainsi leur qualité et donc la

qualité du produit final et la satisfaction client. En pratique dans de nombreux projets, le choix

est d’outre passer ces étapes de formalisation dans le but d’accélérer la mise en production, et

ce au détriment de la qualité des premiers résultats. Ce manque de formalisation entraine un

nombre d’itérations et de corrections plus conséquents ce qui va à l’encontre de l’effet

escompté en termes de délai et de qualité. C’est pour contrer les effets néfastes de la réduction

de cette phase pourtant si importante que nous avons proposé de revoir notamment la phase

d’avant projet (Chapitre 3, Figure 10). Mais revoir une démarche ne suffit pas si cela ne

s’accompagne pas de la mise en œuvre d’outils opérationnels supports à celle-ci, permettant

une représentation multi-niveaux et l’entreprise et étant des vecteurs de communication entre

les acteurs.

2.2 Le casse-tête de la représentation multi-niveaux et de l’implication

des acteurs

Pour obtenir une solution fidèle au système, il est nécessaire d’étudier le système avec

différents niveaux de représentations et de préférence avec différents acteurs pour confronter

leurs différentes visions, leurs expériences et ainsi approcher la modélisation au plus près du

système réel et non pas uniquement théorique. La multiplication des acteurs dans le projet

apporte un degré de précision important sur la définition des informations à chaque niveau

mais entraine aussi la nécessité de gérer un groupe important et de faire « du tri » dans les

données récoltées.

Au niveau de l’entreprise, au niveau global, il sera nécessaire de faire apparaitre son

« besoin », comment il s’intègre dans son environnement mais également d’avoir une vision

plus transverse pour ne pas s’arrêter au fonctionnel mais intégrer également les aspects

stratégiques. Au niveau des processus et des activités de l’entreprise (point de vue local), nous

devrons être capables de mettre en évidence la définition à plus proche du réel des activités

pour que la solution soit en phase avec l’organisation mais aussi les acteurs. L’expérience

montre qu’une étude « du réel » contribue à faire apparaitre qu’une ou plusieurs personnes

non référencées théoriquement interviennent dans certaines actions ou dans certains cas bien

spécifiques. Ces personnes sont souvent des ressources clés qui permettent de solutionner des

problèmes ou de débloquer des situations jusque là conflictuelles. L’aboutissement à une

image réel de l’entreprise est donc le résultat de la confrontation des différentes visions que

peuvent avoir les personnes sur le système. Il est essentiel de les intégrer lors des

spécifications mais toujours à un moment opportun. Dans l’idéal, il serait nécessaire de


Page 102

descendre jusqu’au niveau « local » pour valider l’ensemble des points prévus et adapter la

solution aux utilisateurs même du logiciel, car ce sont eux qui seront les moteurs de

l’utilisation de l’application. Aujourd’hui il est très difficile de faire participer activement tous

ces profils lors des spécifications pour des raisons notamment de coût et seules des validations

ponctuelles peuvent se faire et toujours par l’intermédiaire du responsable de projet.

Notre proposition d’accompagnement du client très en amont dans la démarche de

modélisation (4 principes édictés dans le chapitre 3) viendra donc se heurter à la difficulté du

choix de la méthodologie et du formalisme de modélisation (section précédente) mais aussi à

la difficulté de tenir compte de la structuration multi-niveaux et multi-acteurs de l’entreprise

client. Pour pallier à ces difficultés nous avons axé nos réflexions sur la recherche d’efficacité

en termes de modélisation de l’ensemble des besoins dans leurs contextes, mais aussi de

réalisation d’un support de réflexion et de l’analyse commun en vue d’une validation

concertée des solutions. Support qui idéalement contribuera aussi au suivi du projet des

phases des très amont de processus de déploiement jusqu’au déploiement de l’application à

proprement parler. La section suivante présente nos travaux quant à l’utilisation de deux outils

pour répondre à notre problématique : les cartes heuristiques et les personas.

2.3 Deux outils « non conventionnels » pour lever les verrous

Dans le cadre d’un projet d’implémentation, de durée relativement courte, non

seulement toutes les parties doivent, a priori, comprendre la méthode choisie afin de

contribuer activement à l’élaboration du modèle selon les étapes définies par cette dernière,

mais également connaitre le fonctionnement du formalisme associé. De la même manière, il

apparait que le choix du formalisme est tout aussi important que le choix de la méthode pour

améliorer la compréhension mutuelle et plus généralement la communication. Sa complexité

aura un impact déterminant sur le déroulement des spécifications. De plus, la formalisation

graphique constitue la base de la communication pendant les réunions avec le client, or durant

ces réunions les intervenants peuvent varier, il est même conseillé qu’ils changent pour

accroître la pertinence du modèle. Il n’est pas opportun d’utiliser un modèle trop complexe à

comprendre pour un nouvel arrivant ne connaissant rien aux méthodologies et aux différentes

cartographies. Tous les intervenants doivent être en mesure de l’interpréter, le critiquer et le

modifier tout au long du processus de réflexion. L’expérience de LASCOM montre que si

toutes les personnes participant aux réunions d’analyse comprennent le modèle présenté sans

explications préalables, leur participation et la communication en seront améliorées. De même


Page 103

leur visibilité sur le déroulement du projet et plus particulièrement de l’étape de spécification

et le contenu de la future application sera elle aussi plus grande. Pour que l’implication des

acteurs soit « naturelle » et « simplifiée », il semble donc que nous devons nous dédouaner

des problèmes de sémantiques intrinsèquement liés aux méthodologies et aux formalismes.

Nous devons choisir une méthodologie et un formalisme proches du « langage naturel » et

basé sur des concepts cognitiques eux-mêmes réduits à leur plus simple expression et proches

des démarches intellectuelles quotidiennes des acteurs. Sans oublier malgré tout que nos choix

devront permettre une représentation des plus précises de l’entreprise, de son organisation et

de son fonctionnement.

Pour obtenir un modèle d’entreprise suffisamment riche tout en conservant la

possibilité d’intégrer le plus grand nombre de personnes à la définition de l’application, nous

proposons d’utiliser deux formalismes complémentaires et relativement peu conventionnels

dans le cadre de la modélisation d’entreprises. D’une part les cartes heuristiques pour ce qui

est de modéliser l’entreprise et ses processus et d’autre part les personas pour l’étude et la

validation des spécifications au niveau des utilisateurs finaux de tous les niveaux (du global

au local). Ces formalismes ont le mérite d’être très simples et souples puisque aucune règle

formelle n’existe et ils sont facilement adaptables au besoin d’implémentation en fonction de

la solution et du projet. D’un point de vue client nous veillerons à ce que ces formalismes

l’aident à suivre l’évolution de son application et à définir son organisation et ses besoins, et

enfin facilitent la communication avec LASCOM. Pour LASCOM ces formalismes devront

améliorer la communication et la visibilité du déroulement des projets, voire de déporter une

partie de d’étude des besoins actuels et futurs chez le client, unifier la définition des

applications et faciliter la transmission d’informations entre les services.

Nous verrons dans les paragraphes suivants que les cartes heuristiques serviront de

base aux réunions de spécifications et permettront de définir le projet et son contexte. Et que

les personas seront à la base du questionnement des acteurs finaux et contribueront à affiner et

vérifier les besoins du terrain en fonction des éléments recueillis durant l’étude globale. Nous

montrerons aussi comment ces deux formalismes sont étroitement liés, se complètent et

pourquoi nous avons décidé de les mettre en œuvre dans le cadre du déploiement d’une

solution PLM au sein d’une entreprise.


Page 104

3 Les cartes heuristiques : une base commune de modélisation et

de discussion

Dans le cas d’un projet PLM, la compréhension du contexte d’utilisation de la solution

passe avant tout par la compréhension de l’entreprise (son activité, son organisation, le projet,

les besoins, le rôle…). En pratique une partie des éléments du contexte est fournie durant la

phase d’avant vente, phase au cours de laquelle sont impliqués au moins un commercial et le

service de « l’avant vente » de chez LASCOM. Ces éléments sont ensuite revus et/ou

complétés durant la réunion de lancement qui concerne les directeurs de projet et les chefs de

projet du client et de LASCOM. Enfin, ses éléments sont plus explicités et affinés au fil des

interrogations qui peuvent apparaitre durant le projet. L’environnement du projet étant un

facteur clé de succès de par son impact direct sur la qualité et la pertinence de la future

application, plus il sera clarifié dès le départ et plus ses évolutions seront tracées meilleur

seront les spécifications et la solution par la suite. Les phases préliminaires et de suivi de

l’évolution du projet ne doivent donc pas être sous-estimées et doivent aboutir à une

cartographie de l’entreprise, des(s) service(s) concerné(s), de(s) produit(s), des données des

plus précises mais malgré tout évolutive. La difficulté de la construction du modèle

d’entreprise vient du fait que les informations sont parfois de natures différentes et qu’il

n’existe pas un modèle de travail et d’échange unique et commun tout au long du projet. Les

informations fournies en avant projet sont souvent générales et reflètes les besoins

essentiellement stratégiques. Durant la phase d’avant vente on tend à passer d’une définition

stratégique à une définition technique et finalement durant le projet, on passe de cette

définition technique à une définition fonctionnelle. Il est souvent compliqué d’obtenir

l’ensemble des informations détenues par chacun des intervenants tout au long du projet car le

laps de temps entre l’avant vente et les phases de conception peut être relativement long, les

intervenants changent et que de nombreuses informations ont été donné informellement, à

travers un certain nombre de mails, plus ou moins explicitées dans différents documents... La

restitution unique est globale de l’ensemble des données est souvent impossible. De plus

l’évolution de la définition des besoins entraine souvent des discordances entre ce qui a été

prévue en avant vente, c'est-à-dire chiffrée et vendue, et ce que le client veut finalement et ce

qui est réalisé. La création d’un recueil unique de toutes ces informations tout au long du

processus, quelque soit le service, apparait indispensable pour éviter la fuite d’informations.

Ce recueil sera d’autant plus essentiel qu’il contribuera à la bonne compréhension du projet et

influera sur la conception de part les informations qu’il contiendra. La problématique est de


Page 105

construire un support unique pour modéliser l’entreprise cliente et suivre l’ensemble du cycle

de vie du projet. Ce support devra être initié par le commercial, complété par l’avant vente,

puis par le chef de projet et finalement par le support client LASCOM. Idéalement, ce

document sera partageable et partagé avec le client à des fins d’optimisation mais également

afin d’avoir le même niveau d’information sur le projet. La conception de ce document ne

doit pas entraver le bon déroulement du projet, il ne doit pas nécessiter un effort

supplémentaire au travail à chacun des participants et être un vrai vecteur de communication

entre les partenaires.

Pour répondre à tous ces critères et au regard du temps impartis à la construction de ce

type de document, il était nécessaire de trouver un format accessible, ne nécessitant pas un

haut niveau de formalisme, adaptable, rapide à construire, à parcourir et à mettre à jour. Notre

choix s’est donc porté sur les cartes heuristiques, plus communément appelées « mind map »

ou « map ». Nous allons voir quel est le principe de construction d’une map puis comment

elle peut s’inscrire dans le cycle de vie et surtout comment définir sa structure dans le cadre

du déploiement d’une application.

3.1 La carte heuristique ou une structuration rapide d’idées

Lors d’un lancement de projet d’implémentation, et plus particulièrement lors des

premières étapes d’interventions pour l’étude et les spécifications, le premier problème

rencontré par les intégrateurs est la compréhension et l’appropriation du fonctionnement de

l’entreprise. Cette problématique peut généralement se traduire par les questions suivantes :

Par où et comment commencer ? Notre proposition pour répondre à ces questions dans le

cadre de la modélisation d’une entreprise en vue du déploiement d’une solution logicielle est

d’utiliser une représentation heuristique (du grec ancien εὑρίσκω, eurisko, « je trouve »).

En vogue depuis quelles années dans le monde universitaire, la représentation

heuristique fait aujourd’hui son apparition dans le monde industriel pour organiser des idées,

des plannings, des projets, animer des réunions… Cette représentation nommée carte

heuristique, ou mind map en anglais, carte des idées, schéma de pensée, carte mentale, arbre à

idées ou encore topogramme, est un diagramme imaginé par le psychologue Tony Buzan en

1971 [Buzan, 93]. Il représente des liens sémantiques entre différentes idées ou des liens

hiérarchiques entre différents concepts. La création d’une carte heuristique se décompose en

deux grandes phases : la création d’un pêle-mêle d’idées puis la construction du schéma.

Concrètement, dans un premier temps, sur une grande feuille ou un tableau, il suffit d’inscrire


Page 106

un titre explicite au centre, illustrant le sujet de la réunion, puis à travers un brainstorming, il

suffit d’écrire toute les idées sous forme de mots clés autour de ce premier concept, de façon

aléatoire. Le principe est de réaliser une liste la plus exhaustive de tous les préceptes se

rapportant au sujet. Dès que tous les intervenants manquent d’inspiration, il suffit de choisir

un de ces mots clés et d’effectuer la même démarche en inscrivant tout autour une nouvelle

liste. Le support rempli de mots constitue la carte mentale divergente, autrement dit un mini-

schéma visuel où les mots sont inscrits dans l'ordre d’apparition dans l'esprit de la/des

personne(s) et où les idées sont directement reliées à l'idée principale. Il s'agit d’une première

version exploratoire (remue-méninges visuel). Pour aboutir à une carte heuristique

convergente, il est nécessaire de réaliser deux actions distinctes : l’organisation et le

figuralisme. La première a pour objectif de réorganiser la pensée en regroupant, triant,

classant et hiérarchisant les idées, tandis que la seconde donne vie, grâce à une image visuelle,

à la pensée en associant des éléments graphiques, des images, des couleurs, du volume… La

hiérarchisation des mots et des images attribue un rang qui reflète leur importance et leur

filiation jusqu'à plusieurs niveaux de parenté. Le caractère graphique doit marquer l’esprit et

faciliter la compréhension de ces liens. En effet, à l'inverse du schéma conceptuel ou de la

carte conceptuelle (concept map en anglais), la carte heuristique est le plus souvent une

représentation arborescente de données sans étiquetage formel des liens. Cette représentation

constitue un support très visuel, adaptée aux réunions de brainstorming ou de découverte d’un

concept en favorisant les échanges, l’interprétation, l’appropriation et la mémorisation. Pour

systématiser l’exploration d’un système ou d’un concept, sans pour autant complexifier les

échanges et la communication au sein de l’équipe projet, sa conception et/ou sa réorganisation

peut reposer sur les sept questions d’Aristote (Quoi, Qui, Quand, Où, Comment, Pourquoi,

Avec quoi) (Figure 11).

Finalement, une carte mentale (ou carte heuristique) est un diagramme qui permet de

représenter de manière globale et assez complète une situation (un problème, un concept ou

un projet). Le ou les objectifs peuvent être divers : soit la réalisation d’un compte rendu de

réunion en restituant rapidement les idées et les concepts clés, soit la résolution d’un problème

en explorant un maximum de solution rapidement, soit d’apprendre en assimilant de manière

connexes un ensemble d’informations, soit l’organisation d’un projet en constituant une

cheklist des éléments à ne pas oublier, soit la structuration d’un projet en clarifiant les rôles et

objectifs de chacun… L’utilisation de carte se répand de plus en plus car elle est d’une

manipulation très aisée, adaptable et personnalisable.


Page 107

Figure 11. L’illustration des sept questions d’Aristote [Créativité, 12]

Les avantages dans le monde industriel sont nombreux puisque les maps constituent des

supports évolutifs facilitant la participation, améliorant la communication et les échanges et

offrant la possibilité d’élargir le cercle des intervenants ponctuellement sans perdre le temps

de compréhension. De plus leur niveau d’accessibilité est très important car elles ne reposent

sur aucune méthode abstraite autre que la réflexion et l’association d’idée puis le

questionnement systématique pour chacun des éléments présent sur la carte : il n’est pas

nécessaire d’avoir une idée précise au départ du système à représenter. Leur formalisme

flexible est adapté au concept simple ou complexe en catégorisant les liens pour représenter et

visualiser la hiérarchie des concepts et il permet de formaliser les différentes perceptions d’un

système en fonction des regroupements fait par les uns ou les autres des intervenants.

En conclusion, nous pouvons retenir que « la démarche heuristique permet d’aborder

la complexité dans ce qu’elle contient de plus riche, parce qu’elle la rend intelligible sans la

réduire à quelque chose de simple. Il en est ainsi pour résoudre des problèmes. Dans ce cas,

la démarche heuristique nous permet d’identifier et clarifier le problème, procéder à un


Page 108

diagnostic pour ensuite imaginer une solution. Et pour ce faire, augmenter notre champ de

vision et celui des possibles. » [Deladriere et al., 07]. L’utilisation de carte heuristique n’est

pas une méthode conventionnelle de conception - quoique de plus en plus cités et utilisés dans

les articles scientifiquement, mais elle peut être adaptée pour répondre au besoin de création

d’une application associée de surcroit à un formalisme simple et accessible à tous. Elle

constituerait la dorsale d’un projet d’implémentation tant pour faciliter la compréhension des

besoins quelque soit le niveau d’abstraction, que pour créer, présenter et valider la solution

retenue.

3.2 La formalisation heuristique tout au long du projet : approche

théorique

Dans le cas du processus de déploiement d’un logiciel de gestion, la capitalisation des

connaissances sur le client et le projet représentent la clé de l’optimisation du résultat. Durant

l’implémentation d’une solution logiciel, les acteurs coté éditeur/intégrateur se succèdent au

rythme des phases du projet. Chacun d’eux acquièrent des connaissances de différents ordres

commercial, stratégique, technique, fonctionnel, etc. en fonction de leurs interlocuteurs. Nous

proposons de voir dans cette section comment la carte heuristique peut s’inscrire

concrètement dans la complétude du processus de déploiement (Chapitre 3, Figure 10).

3.2.1 Le commercial et la map

Comme nous l’avons vu, la première phase du processus est une phase essentiellement

commerciale. Sa durée est variable car le cheminement entre la prospection et l’émergence

d’un projet peut être relativement long en fonction de la maturité du projet, et l’acteur central

est le commercial. Durant cette étape, un certain nombre d’informations est collecté par le

commercial en amont via différentes sources, d’autres sont divulguées par le client lui-même

au « fil de l’eau ». Toutes ces informations sont généralement informelles et beaucoup

apparaissent mais sont mises de coté par le commercial qui peut les juger comme inutiles pour

le restant du processus. Malheureusement certaines de ces informations peuvent malgré tout

contribuer à déterminer le contexte stratégique du projet. Ces informations sont ensuite

transmises au service de l’avant vente qui lui va apporter une réponse technique et un

chiffrage au plus juste et des plus approprié tout en étant conscient du peu d’informations en

sa possession pour parvenir un résultat très proche du résultat final. Lorsque le client a reçu

l’offre et l’a acceptée, les informations passent ensuite de l’avant-vente au niveau de l’équipe

projet. A ce niveau, bon nombre d’informations sont généralement perdues ou resurgissent


Page 109

parfois au gré des certaines interrogations. Pour éviter la perte d’une partie de la dimension

stratégique, l’idée est d’initialiser une map dès la prospection par le commercial, sans même

savoir si effectivement un projet en ressortira. L’objectif est de collecter un maximum

d’informations pour faciliter et accélérer le travail d’avant vente, qui ne serait plus contraint

« d’aller à la pêche » aux informations et de se reconstruire sa vision « globale » du contexte

au fil des mails échangés et des discussions avec le client. Pour le commercial, l’instauration

de ce formalisme peut représenter un outil efficace dans ses démarches de prospection. Pour

ce faire, nous devons être en mesure de lui fournir une map générique qui orientera son

questionnement et qui sera la base de la construction d’une map spécifique au client,

représentative de l’ensemble des informations en sa possession tant pour valider certains

points que pour former et enrichir sa base de connaissances sur le client. L’approche de

modélisation adoptée est ici clairement une approche descendante. Nous verrons par la suite

qu’au cours du projet cette approche sera complétée par une approche ascendante pour

enrichir la carte.

3.2.2 L’avant vente et la map

Si l’on suit le processus, une fois un cahier des charges émis par le client via le

commercial, le dossier est pris en charge par l’avant vente. Leur objectif est de composer une

réponse technique et chiffrée d’une solution répondant à un maximum d’exigences décrites

dans le cahier des charges. Aujourd’hui cette double réponse est réalisée conjointement avec

le commercial, voire le service de développement pour certains aspects spécifiques, le but

étant généralement d’utiliser au maximum les « briques » et les fonctionnalités standards

proposées au catalogue pour chacun de verticaux. Pour élaborer sa réponse, la personne en

charge du projet se construit une « image » de la solution finale, généralement de manière

informelle en griffonnant sur un papier. Cette idée émerge de sa propre compréhension du

besoin, basée sur les différentes informations en sa possession (transmises ou acquises en

demandant au client des compléments sur certains points), de son expérience et de ses

connaissances. Basée sur cette vision personnelle de la solution, elle va d’une part concevoir

la réponse technique expliquant le fonctionnement global de la solution et les fonctionnalités

proposées pour répondre aux attentes particulières, et d’autre part chiffrer approximativement

cette proposition. Le chiffrage étant la partie la plus délicate du fait des incertitudes sur

l’expression du besoin, des possibilités techniques, des différents participants et de leurs

connaissances. Autrement dit, la vision de la solution finale n’est pas définie explicitement

dans la réponse. Dans notre proposition, la carte initiée à l’étape précédente par le commercial


Page 110

est fournie à l’avant vente en même temps que le cahier des charges. Le premier intérêt est

d’avoir la même vision partagée du contexte du projet que le commercial, ce qui permet

d’obtenir une vision d’ensemble plus rapidement et de faciliter d’autant plus le dialogue avec

ce dernier. Le second intérêt est d’illustrer la proposition technique rapidement et simplement,

grâce à une librairie pré-initialisée avec l’ensemble des composants nécessaires pour

formaliser la vision de l’application, du point de vue du modèle de données et des

fonctionnalités standard disponibles, sans forcément entrer dans les détails précis de la

conception. Cette modélisation rapide permet de fixer formellement une vision du besoin, du

contexte et de la solution qui pourra être ajoutée à la réponse pour servir de référence pour la

suite du projet. D’un point de vue méthodologique, la formalisation peut également faciliter la

rédaction de la réponse technique en formant la dorsale du document. Ainsi au moment de

l’envoi de la réponse au client par l’éditeur, la carte heuristique met en évidence les besoins

stratégiques, les besoins techniques et « l’image » de la modélisation sur laquelle repose la

proposition réalisée.

3.2.3 Le service projet et la map

Si la solution est retenue, le projet est lancé et le dossier est transmis au service projet.

Aujourd’hui, la passation repose sur le transfert d’un certain nombre de documents,

généralement le cahier des charges et la réponse de l’avant vente (technique et financière)

ainsi que des éléments temporels et financiers (date de début souhaitée, date de fin exigée,

pénalités, etc.). Une réunion rassemblant le commercial, l’avant vente, le directeur de projet et

le futur chef de projet est organisée dans le but d’appréhender le projet mais également la

réponse réalisée afin d’obtenir la vision globale du projet, établir le travail à faire et élaborer

un planning. Généralement, à la fin de cette réunion, le nouveau chef de projet a en sa

possession les documents cités précédemment, plus toute une collection de mails qui ont été

transférés pendant ou après la réunion en fonction des discussions, une collection de notes

prises par chacun, des feuilles griffonnées scannées, plus ses propres notes pour établir son

référentiel projet. Finalement, le constat est donc que chacun doit se recréer son

environnement et son support de travail, sur la base de documents aux origines et aux formats

hétérogènes, provoquant indubitablement des pertes de temps, des pertes d’informations mais

également des mauvaises compréhensions. Tout ceci est source de doutes, de questions

immédiatement après la réunion ou plus tard, lors de la confrontation avec les documents

reçus, voire chez le client. Dans la nouvelle vision que nous proposons, en début de projet, la

carte heuristique continue à suivre les phases du processus et est donc à disposition du chef de


Page 111

projet. Lors de la réunion interne, tous les participants possèdent ainsi le même support, avec

le même niveau d’information ce qui permet de présenter le projet de manière ordonné,

structuré et systématique, et d’aborder des points en particulier sans perdre de temps sur

d’autres points très basiques ou bien explicités. Ainsi si des oublis ou des imprécisions sont

décelés, la mise à jour de la carte est réalisée conjointement à ce moment là, créant ainsi un

référentiel commun sur le projet rassemblant les différents niveaux de connaissance acquise

par chacun des acteurs.

Lors du lancement de projet à proprement parlé, c'est-à-dire lors d’une réunion

LASCOM / Client, l’organisation du projet, les intervenants et leurs rôles, le planning prévu

pour un contour fonctionnel précisé sont présentés. Jusqu’à présent cette étape était délicate

de par les incertitudes existantes tant sur l’appréciation des informations d’un point de vue

client comme éditeur (le contour fonctionnel, les solutions envisagées, etc.), que sur la

différence entre le besoin perçu et le besoin réel. La présence de la carte heuristique

n’apportera pas une aide substantielle pour cette étape mais présente deux intérêts majeurs.

D’une part, ayant été construite en liaison étroite avec le client dès les phases amont, elle ne

devrait théoriquement contenir que peu d’éléments sujets à des incertitudes. D’autre part, à

travers cette amélioration de la fiabilité des informations fournies, c’est toute la

communication au cours de cette étape qui devrait être facilitée par l’utilisation qu’il peut être

faite de la map comme support pour exposer clairement la solution chiffrée, expliciter le lien

existant entre le planning et la délimitation du projet, etc.

Le projet d’informatisation est alors lancé et débute par la définition des spécifications

au cours d’une phase d’analyse du besoin plus ou moins poussé et plus ou moins dissociée de

la phase de détermination des caractéristiques de la solution. Aujourd’hui il n’existe pas de

méthode ou de formalisme propre à cette étape. Le constat général est que cette étape est

souvent très longue du fait d’itérations régulières, issues de problèmes de compréhension, de

communication, de niveau de connaissance des intervenants, de la validation interne

asynchrone et point par point. La conséquence est que la phase d’analyse est souvent réduite

au minimum afin de tenir les délais au risque d’aboutir à un logiciel strictement fonctionnel

basé sur le cahier des charges corrigé, et non sur les besoins réels et les retours d’expériences

des acteurs principaux et sans prendre en compte les aspects de pilotage. L’utilisation d’une

carte heuristique a pour objectif de limiter tous ces problèmes. Dans un premier temps, il sera

nécessaire de compléter la carte existante pour l’enrichir. Pour ce faire nous proposons de


Page 112

construire une nouvelle carte qui viendra compléter la précédente et qui sera dédiée aux

intervenants coté client identifiés comme des utilisateurs de la future solution. Jusque là ces

interlocuteurs n’ont pas été impliqués et une nouvelle carte permettra de ne pas les influencer

et d’aboutir rapidement à une définition des besoins concrets utilisant la sémantique propre à

l’entreprise. L’élargissement des cercles des intervenants et la rotation des participants sont

facilités grâce à la simplicité du formalisme ce qui aboutit à une définition plus précise, plus

rapidement et plus près la réalité et ce sans pour autant faire perdurer l’étape. De plus, grâce à

l’accessibilité et la flexibilité, l’élaboration peut donc être réalisée avec ou sans

l’éditeur/intégrateur permettant de diminuer les coûts. La seule contrainte est de vérifier

régulièrement la présence de tous les éléments décrits dans la première carte pour assurer la

compatibilité et la cohérence entre les deux cartes. Autrement dit, le concepteur de la carte des

besoins doit vérifier ou s’inspirer des éléments collectés dans la carte utilisée jusqu’à présent

pour orienter la réflexion et la description des participants, afin d’éviter des manquements.

L’objectif est évidemment de n’avoir qu’une seule carte globale construite sur la base des

cartes secondaires. Les informations fonctionnelles ainsi obtenues venant compléter les

aspects stratégiques et techniques et mettre en exergue si besoin les différences avec le

prévisionnel réalisé en avant vente. Les premiers intérêts de l’utilisation d’une map sont

d’accélérer l’analyse du besoin, rendant possible la systématisation de cette phase sans

augmenter les coûts, tout en améliorant sa qualité, en élargissant les profils interrogés. A la fin

de cette phase, si le décalage est trop important avec le cadre fonctionnel prévu, la map est un

élément commun de discussion pour mettre en évidence de manière tangible les écarts, voire

pour demander un arbitrage du client. Les constitutions de maps secondaires a pour but ici

d’adopter une approche de modélisation ascendante venant compléter l’approche descendante

initiale. L’idée de profiter des avantages de ces deux approches pour faire émerger une image

plus précise du « réel » de l’entreprise.

Une fois le besoin définit, la conception débute. L’idée est de mettre en vis-à-vis les

besoins et la modélisation de la solution sur une même carte. Pour ce faire, soit l’utilisation du

modèle créé en avant vente est possible, si les écarts entre les définitions ne sont pas trop

importants, soit il est préférable de recréer un modèle en se basant sur une librairie standard.

Dans les deux cas le but est de créer l’image la plus précise possible du logiciel en répondant

aux attentes point par point. Les avantages de la map unique dans la spécification sont

d’explorer les besoins exprimés par les utilisateurs de manière systématique, d’expliciter

facilement le pendant entre chacune des demandes et leur réponse par un effet miroir,


Page 113

d’améliorer la qualité et la finesse de spécification de l’application et finalement d’assurer un

haut niveau d’adéquation entre l’expression de besoin, la réalité du terrain et l’application

finale.

Une fois la définition validée, l’application est déployée et nécessite la création de

documentations et l’instauration de séances de formation. Aujourd’hui, selon les projets, les

services en charge de la documentation et des formations font soit des propositions sur la base

d’éléments génériques soit des propositions spécifiques. Une transmission de connaissances,

essentiellement d’un point de vue fonctionnel et sémantique, pour chacun des cas est

nécessaire. Autrement dit les personnes en charge de ces activités au sein de LASCOM

doivent se réapproprier en partie le projet ou du moins la solution réalisée pour apporter une

qualité de service minimum. En effet, que ce soit pour la documentation ou pour la formation,

il est essentiel d’utiliser la sémantique « métier », voire celle du client, pour que l’information

soit comprise et assimilée et que les utilisateurs s’approprient facilement l’application sans

être bloqués au cours de son utilisation. La map ne résoudra pas tous les problèmes mais aura

au moins le gros avantage de structurer la transmission de connaissances et offrira un support

dans lequel il sera la possible de naviguer aisément entre la vision métier (les besoins) et la

vision logicielle (la modélisation). L’intérêt étant d’accroître la performance tout en

améliorant la qualité du service.

3.2.4 Le support client et la map

La dernière étape du processus jusqu’à présent était le support client. Le rôle du

support client est de répondre aux différentes problématiques rencontrées par les clients dans

l’utilisation de leurs applications. Une première distinction est réalisée en fonction de la

nature de la question, technique ou fonctionnelle, et de la gravité, mineure, normale ou

bloquante. Pour les aspects techniques spécifiques, un second niveau d’analyse est nécessaire

pour déterminer si c’est effectivement un « bug » de la solution ou un choix volontaire validé

par le client à un moment donné (la personne déclarante n’étant peut être pas du tout au

courant du choix validé en amont). Pour les aspects techniques standards, c'est-à-dire non

développé pour un client en particulier, ou les bugs spécifiques, la compréhension du

problème est généralement assez aisée. La difficulté réside essentiellement en sa reproduction

sur des plateformes internes sachant que généralement en informatique si le problème est

reproduit, cela signifie intrinsèquement que le problème est identifiable donc potentiellement

corrigeable. Finalement les impacts de la correction et la non-déstabilisation de l’application

sont vérifiés. Pour les aspects fonctionnels, la distinction est toujours basée sur standard et


Page 114

spécifique mais nécessite précédemment de traduire la nature de la demande exposée

généralement avec la sémantique du client. Répondre à des questions sur le fonctionnement

standard est plus simple pour le support car la réponse est souvent générique ou fonction de la

version. Par contre pour le spécifique, au vue du temps impartis pour répondre, les ressources

à leur disposition résident essentiellement sur leurs expériences et sur les chefs de projet.

Autrement dit, lorsque le chef de projet n’est plus là, les seules ressources disponibles sont les

différentes documentations réalisées au fil des évolutions (en espérant qu’elles soient à jour),

augmentant le temps nécessaire pour trouver la réponse, donc diminuant la satisfaction client.

Une fois encore, la map peut être une aide intéressante pour le support client en apportant une

vision synthétique de la solution déployée au regard du besoin, des différentes évolutions

réalisées, des fonctionnalités mises en œuvre, des spécificités développés… Elle permet

également d’obtenir la traduction dans la sémantique du client, si cette dernière est bien

maintenue à jour, c'est-à-dire que le support client complète la map en y annotant ses

interventions.

3.2.5 Synthèse

L’utilisation du map générique implémentée tout au long du cycle de vie du logiciel

facilite le travail de chacun des intervenants, internes et externes. La Figure 12 met en

évidence le phasage de l’évolution de la map générique et l’implication des différents services

au regard du cycle de déploiement de la solution logicielle. Cela nécessite néanmoins une

certaine rigueur mais somme toute négligeable au regard de la facilité de mise à jour et des

apports pour chacun des acteurs. La constitution d’un référentiel commun accessible

contribue ainsi à améliorer la qualité du logiciel, en raison de l’analyse systématique des

besoins mais également des services connexes au logiciel.

Nous allons montrer dans la section suivante comment il est possible de construire et

d’opérationnaliser une map générique puis de l’implémenter tout au long du projet.


Page 115

Figure 12. Les acteurs du processus d’informatisation et points d’évolution de la map

3.3 Une carte générique pour le déploiement des solutions LASCOM

L’un des freins au déroulement d’un projet d’implémentation réside dans la difficulté à

obtenir une vision globale du projet et de la solution mise en place par les différents acteurs

tant du coté client que du coté éditeur. Notre proposition est de construire tout au long du

cycle de vie une carte heuristique qui sera la « carte d’identité » et le « carnet de santé » du

projet. Cette carte sera bâtie de façon collaborative entre l’éditeur et le client suivant une

démarche précise que nous définirons dans ce chapitre. Notre objectif est d’améliorer le

processus de déploiement et plus globalement le cycle de vie du logiciel en créant un

document de travail unique et commun aux deux parties. Les bénéfices de la démarche ne

seront possibles que si et seulement si la map est connue, reconnue, comprise, utilisable par


Page 116

tous les intervenants et surtout si elle est maintenue à jour. La mise en place d’un tel outil

impose de sensibiliser l’éditeur et le client sur l’intérêt de l’utilisation d’une map pour ensuite

systématiser sa conception et sa construction. Systématiser signifie que nous devons définir la

structure d’une map minimale générique et implémentable par les acteurs de projet

simplement et un temps réduit.

Pour initier la démarche chez LASCOM puis chez les clients nous proposons une

« méta-map » de base qui sera le point de départ de la construction d’une vision globale du

projet et aidera à systématiser la spécification des démarches. Pour que ce modèle soit un

cadre générique minimaliste, simplifié et exploitable par LASCOM nous l’avons bâti sur la

base de capitalisations d'expériences antérieures de projets LASCOM. Ce modèle évoluera en

fonction de l’apparition de nouvelles bonnes pratiques ou habitudes de travail, des mœurs, des

besoins spécifiques ou des améliorations de l’outil et de la démarche. Pour être pertinente, la

carte doit apportée une vision de l’ensemble du projet des phases initiales de la démarche de

déploiement jusqu’aux phases terminales. Nous devons ainsi retrouver sur la carte la

définition des besoins, la situation du projet et la solution déployée et ce à tout moment du

cycle de vie. Pour répondre à cette contrainte, notre proposition est de décomposer la map en

quatre branches (Figure 13) :

- La partie « Contexte » regroupera les informations relatives à la définition de la

structure organisationnelle et du fonctionnement initial de l’entreprise (avant que la

solution logicielle soit installée). Cette partie se complétera en collaboration avec le

client au fur et à mesure de l’évolution des modélisations successives de l’entreprise,

- La partie « Interventions » sera une zone de travail commune avec le client. Elle

contiendra les éléments relatifs au déroulement des interventions et des corrections,

- La partie « Livrables » concernera le suivi des livraisons liées à l’implémentation et à

l’installation de l’application,

- La partie « Applications » reflète le paramétrage et la définition du logiciel en cours

d’utilisation et donne un premier niveau d’explication du mode de fonctionnement.


Page 117

Figure 13. Structure d’une carte client générique (« méta-map »)

Le commercial initiera ces quatre éléments puis au cours du projet chaque

modification, chaque correction ou évolution apportée par un acteur fera évoluer le modèle ce

qui apparaitra visiblement sur la carte heuristique. Les informations « de travail » seront tout

d’abord décrites dans la partie « Interventions » dans un espace de travail commun dédié.

Puis, une fois validés, les différents éléments seront mis à jour tant dans la définition du

besoin dans le « Contexte ». Les informations décrites dans le contexte ne s’y trouveront que

si elles sont validées, le « Contexte » étant le modèle stabilisé, « contractuel ». Au fur et à

mesure de la construction de la solution, c’est la définition des « Livrables » qui évoluera pour

enfin aboutir à la mise à jour de la partie « Applications ». Cette partie sera l’image fidèle de

la solution effectivement mise en place chez le client. Une telle décomposition permettra de

suivre l’évolution des éléments relatifs au déploiement d’une solution chez un client tout au

long de son cycle de vie.

3.3.1 Le contexte de l’entreprise

La branche « Contexte » regroupera les éléments de description de l’entreprise et plus

spécifiquement le contexte du projet. Cette partie de la map doit contribuer à mettre en

évidence l’ensemble des éléments relatifs à l’environnement du projet en termes de

structurations organisationnelle et fonctionnelle de l’entreprise avant l’installation du logiciel.

Les informations contenues doivent permettre de modéliser l’entreprise grâce à l’association

des informations collectées par tous les acteurs. La définition de l’entreprise s’affinera au fur

et à mesure en associant les informations d’ordre juridique, stratégique et fonctionnel et ce

d’un niveau assez global à un niveau très local. Cette branche est créée par le commercial


Page 118

LASCOM dès le début de la prospection et son contenu évoluera tout au long de l’avancée du

projet et de l’implication des différents acteurs. L’utilisation d’heuristiques apparait comme

étant un outil adapté pour cette étape tant pour l’exploration de l’entreprise, des possibilités de

projet dans une entreprise ou tout du moins des axes potentiels de développement, que pour

accompagner la maturation de cette réflexion pour parvenir à déclencher un projet. Autrement

dit, la formalisation de tous ces éléments fonctionnels et stratégiques fournis au fil des

réunions et de discussions doit permettre de donner une vision plus structurée au commercial

de l’organisation, des besoins et du potentiel de l’entreprise et doit l’aider à fournir des

exemples et des solutions probantes issues du référentiel commun (Figure 14). D’un point de

vue commercial, cet outil sera un support au démarchage et à la « découverte » de l’entreprise

mais aussi à l’affinement de la prospection, la rendant ainsi plus efficace, mais également plus

pertinente grâce à la mise en place d’un format unique facilitant la comparaison entre les

différentes solutions mises en place chez les clients.


Page 119

Figure 14. Le contexte prédéfini par le commercial

La partie « Contexte » et plus spécialement la sous partie « organisation » sera ensuite

affinée en avant vente grâce à la description fournie par le cahier des charges et les

informations obtenues en cours d’analyse (Figure 15). Au niveau commercial, seul les grands


Page 120

axes du besoin ont été recensés (tous ne font peut être pas partie de la demande à traiter) et

c’est l’étape d’avant vente qui fera apparaitre plus nettement bon nombre d’exigences.

Figure 15. Le contexte enrichi par l’avant vente

Pour l’avant vente, cet outil apparait comme un support à la lecture des cahiers des

charges pour structurer les exigences, identifier les actions voire les acteurs ou du moins leur


Page 121

profil, les interactions, les zones d’ombres. Le but est d’obtenir une vision globale plus fine

des demandes et des éléments à modéliser. Cette partie sera réétudiée durant les premières

phases du projet d’implémentation, pour parfaire la définition des besoins en complétant cette

vue de l’entreprise par l’appréciation des acteurs interrogés durant la phase d’analyse des

besoins. La pertinence de cette phase est accrue de par l’accessibilité et la flexibilité du

formalisme, permettant d’élargir le cadre des intervenants et donc des futurs utilisateurs

potentiels. L’objectif est d’obtenir une modélisation de l’entreprise nécessaire à

l’implémentation de la solution du niveau « global » jusqu’au niveau « local » si possible et ce

pour les acteurs actifs et passifs (Figure 16). La mise à jour de cette partie de la carte sera

effective dès lors que cette modélisation sera validée par le client dans la partie «

Interventions ».

Pour la partie projet, la carte initie le lancement effectif du projet en apportant une

vision compréhensible par tous et partagée de la solution envisagée par l’avant vente. La map

devient surtout l’outil central de la définition des exigences et des besoins pour tous les

niveaux. Cette exploration systématique des besoins peut faire naitre des différences

importantes avec le cahier des charges initial mais aussi de nouveaux besoins. L’avantage

d’utiliser un même formalisme et une map unique entre l’avant vente et le projet réside dans

l’identification rapide des parties non chiffrées mises en valeur par l’intermédiaire de petits

drapeaux :

- Drapeau vert si la fonction est native dans l’application c'est-à-dire nécessitant peu,

voire pas de travail,

- Drapeau orange si cela nécessite un peu de travail pour intégrer la demande,

- Drapeau rouge si le travail est conséquent,

- Drapeau noir s’il n’y a pas de solution.

Grâce à cette mise en exergue des différences, l’arbitrage commercial est facilité afin

d’aboutir conjointement avec le client à la définition du nouveau cadre fonctionnel à prendre

en compte, voire des évolutions à prévoir (Figure 17).


Page 122

Figure 16. Le contexte revu lors du projet


Page 123

Figure 17. Contexte à prendre en compte pour le projet

3.3.2 Suivi des interventions

La branche « Interventions » correspond au suivi de toutes les actions réalisées durant

le cycle de vie du projet, c'est-à-dire des différents sous-projets mais également des actions


Page 124

réalisées par le service support. Dans le cadre d’un projet, cette partie tient place de définition

de la structure du projet en apportant une vision des différentes étapes. C’est un outil de suivi

de projet par la mise en évidence de l’évolution de ses différentes étapes dans le temps mais

également un espace de travail partagé entre le client et l’éditeur. C’est aussi le support à la

validation de la modélisation avant son application dans les autres parties de la carte.

Cette partie est pré-initialisée par l’avant vente notamment au cours de la phase de

chiffrage de la proposition. Pour mener cette phase à bien, c’est à ce moment là que la partie

organisation du projet est réellement affinée et évaluée par l’avant vente en fonction des

demandes spécifiques présentes dans le cahier des charges (certaines phases ou certains

livrables) ou simplement en fonction de la complexité du projet. L’initialisation consiste ainsi

à déterminer les grandes étapes du projet et les livrables associés, que ces étapes soient

réalisées avec le client ou uniquement chez l’éditeur. Nous retrouvons sur cette branche

l’ensemble des étapes et sous-étapes du processus de déploiement de la solution LASCOM.

L’initialisation est très importante car elle permet de compléter la réponse de l’éditeur

en illustrant non seulement les aspects fonctionnels et financiers mais également l’aspect

organisationnel du projet (Figure 18). La définition de l’organisation du projet sera reprise

durant le lancement de projet pour l’affiner et établir les dates prévisionnelles issues de la

planification. Durant le projet, cette partie planning pourra bien évidemment évoluer et un

indicateur est placé pour estimer le travail restant sur chacune des étapes. Cet indicateur est

matérialisé par les carrés plus ou moins colorés présent au départ de plusieurs sous-

branches (Figure 18) : plus le carré est coloré plus l’étape est avancée (1/4 du carré coloré

25% de l’étape réalisée, la moitié du carré, 50% réalisé ; ¾ du carré, 75% réalisée, etc.).

La sous-branche « support de réunion » sera construite au fil du projet, selon les

besoins. Par exemple la définition du contexte via l’analyse du besoin sera construire dans

cette partie avant d’être intégrée dans la partie contexte, ce qui permet de débuter l’étude à

partir d’une carte vierge pour ne pas influencer les participants, de pouvoir la modifier, la

réorganiser sans pour autant perdre de vue la proposition établie précédemment (Figure 19).

Aucune contrainte n’est définie pour cette partie, elle doit être adaptée en fonction des

intervenants et du contexte mais doit illustrer chacune des validations à effectuer par

l’entreprise.


Page 125

Figure 18. L’initialisation du suivi des interventions par l’avant vente


Page 126

Figure 19. Le suivi des interventions en cours de projet

Dans ce contexte l’utilisation d’une carte heuristique a l’avantage de constituer un

support unique pour le suivi du projet d’un point de vue macroscopique qui suffit bien

souvent pour les clients, pour les réunions mais également pour la rédaction des documents à

livrer à chacune des étapes grâce à sa structuration lors des réunions. Il pourra aussi générer

automatiquement le plan du document suivant le logiciel utilisé.

Cette zone sera également utilisée lors de l’intervention du support pour tracer les

demandes réalisées mais surtout les modifications et les résolutions de problèmes. Elle aide à

l’identification rapide de la source du problème : n’avait-il pas été traité ou détecté ? La

modification est-elle demande d’évolution ou un retour en arrière à transmettre au

commercial. Pour faciliter cette recherche l’information d’entrée est idéalement la

fonctionnalité en cause (Figure 20).


Page 127

Figure 20. Convention pour les interventions par le support

Une fois le correctif validé, il serait idéalement nécessaire de mettre à jour la partie

« Contexte » et « Applications » pour ne pas perdre cette information et surtout conserver la

carte à jour. Pour ne pas alourdir la charge du support, nous proposons d’utiliser un système

de flèche pour identifier la source et l’impact de leur modification (Figure 21).

Figure 21. Origine d’une correction par le support

Dans le cadre du support, l’utilisation de la carte apporte le niveau de connaissance

suffisant pour comprendre les demandes techniques ou fonctionnelles du client, dans un

langage métier ou informatique et d’identifier l’organisation et la définition de l’application

facilitant la reproduction du problème et les tests de validation.

La partie « Interventions » a pour objectif d’améliorer le déroulement de projet tant sur

la communication, le niveau d’information fourni au client, que sur la qualité des prestations,

le niveau d’analyse, que sur la dynamique du projet (un seul document à mettre à jour, pas de

support à recréer à chaque réunion, des réunions plus rapides). Plus généralement cette partie


Page 128

retrace donc toutes les évolutions réalisées au cours du cycle de vie du logiciel. L’utilisation

de la map permet quelque soit l’intervenant d’obtenir rapidement une vision globale de la

solution, de cibler plus facilement le contexte de son intervention et son impact fonctionnel.

3.3.3 Suivi des livraisons

La branche « Livrables » tient sa nature à la difficulté rencontrée de gérer facilement et

efficacement les différents livrables au regard de la facturation. En effet, en règle générale, la

facturation est possible si et seulement si un certain nombre de livrables ont été fournis. Sa

structure est très simpliste car l’objectif est uniquement d’obtenir une vue synthétique des

éléments à livrer pour pouvoir facturer (Figure 22).

Figure 22. Structure de la partie « Livrable »

Cette partie est complémentaire à la partie « Interventions » et apporte un autre point

de vue sur l’évolution du projet. L’avantage de la carte est la centralisation des données pour

apporter un vue d’ensemble sur le projet.

3.3.4 Définition des applications

La branche « Applications » a pour objectif d’apporter une vision simplifiée des choix

techniques retenus pour répondre aux exigences fonctionnelles. En d’autres termes, cette zone

va permettre de définir les différentes composantes mises en œuvre pour parvenir à recréer

l’environnement des utilisateurs dans le logiciel. Cette définition comprend les modèles de

données, les processus choisis, les reporting mis en place, les modèles de saisies, le

paramétrage… L’objectif n’est pas d’aboutir à une définition trop technique mais d’apporter

un niveau minimum de compréhension du fonctionnement de la solution et de l’impact des

modifications demandées.

Cette branche est initiée par l’avant vente lors de la conception de la réponse au cahier

des charges pour les sous parties « version » et « définition des composants ». En effet, leur

étude doit aboutir à la construction virtuelle d’une application « type » répondant à l’ensemble

des besoins identifiés dans la partie « Contexte » et utilisant au maximum les fonctionnalités

standards du logiciel. Cette pré-définition sera la base essentielle du chiffrage calculé en


Page 129

fonction du nombre d’éléments standard réutilisables (drapeau vert), du nombre de

paramétrages à réaliser (drapeau jaune), du taux de réutilisation possible ou des estimations

réalisées par les experts sur les aspects spécifiques (drapeau orange) et sur la complexité du

projet. Cette première modélisation, importante lors du lancement de projet, sera réalisée dans

la partie « Applications » (Figure 23). La définition issue de l’avant vente est logiquement très

approximative mais doit permettre une évaluation « grossière » de l’ampleur du projet et du

niveau de spécificité.

A ce niveau du processus, c'est-à-dire en amont du projet, l’intérêt de la mise en place

d’une carte heuristique repose sur son mode même de construction, nécessitant une

exploration systématique évitant théoriquement les omissions. Pour parfaire la réponse

technique et financière, il est important que le document d’étude résultant fasse partie de la

réponse afin de clarifier le cadre fonctionnel pris en compte dans la réponse, la solution

envisagée et le niveau de spécificité de leur future application (le coût de la maintenance étant

généralement proportionnelle à la spécificité de l’application). Sa diffusion a pour objectif de

partager une référence commune entre l’éditeur et le client de la solution proposée et de

constituer la base de la réunion de lancement de projet.

Lors du projet, après avoir validé l’ensemble du « Contexte », l’étude des solutions

techniques et pratiques est réalisée pour mettre à jour la partie « Applications ». Avant

d’organiser l’application future du client, il est nécessaire de définir chacune de ces

composantes. Parmi les solutions techniques, une partie sera à établir avec le client (le modèle

de données, les mises en page, les modèles de saisies, etc.), l’autre avec les développeurs

(processus, paramétrages) avant la validation globale par le client. La forme de la définition

est fonction des possibilités du logiciel employé pour concevoir la carte, mais également en

fonction du logiciel à déployer. Dans le cadre de l’application LASCOM AEC et de

l’utilisation de MindManager, nous proposons par exemple d’utiliser des tableaux pour définir

les propriétés de chaque type d’objet, d’associer les fichiers de paramétrages, etc. (Figure 24).


Page 130

Figure 23. La définition succincte de l’application vue par l’avant vente


Page 131

Figure 24. Élaboration partielle de la définition de l’application

L’utilisation de la map ne doit pas être perçue comme un inconvénient pour les chefs

de projet mais comme une aide réelle. Dans le schéma proposé nous utilisons les tableaux ce

qui permet aux acteurs de continuer à utiliser un tableur familier (Excel par exemple). Il est

nécessaire d’opter pour des solutions simples ne nécessitant pas de compliquer le travail et ne

supprimant pas les outils usuels efficaces. Dans cette partie de la map, les fonctionnalités, les


Page 132

processus, les rapports sont également à traiter. Pour ces points relativement standards, la

carte sert surtout de check-list des actions à mener pour garantir un bon fonctionnement. Ce

listing permet de sensibiliser le client sur les impacts de ses demandes mais également

d’apporter une aide supplémentaire pour les futurs administrateurs de l’application.

Figure 25. Structure de l’organisation de l’application

Une fois chacun des composants définis, il est possible de construire l’application, de

définir l’ergonomie et le comportement de l’application dans les différents cas. Autrement dit,

les fonctionnalités par type d’objet, les contenus des listes, la visibilité des documents, les

droits. Dans tous les cas, l’entrée de la définition est le document car cela correspond à une

logique plus naturelle pour les entreprises. Ceci permet d’aboutir plus efficacement à la

définition des comportements souhaités, des différents droits et profils. Ce travail sera réalisé

dans la sous section « organisation » en respectant le plus possible la philosophie du logiciel.

Dans le cas du logiciel LASCOM AEC nous retrouverons par exemple comme structure les

différents onglets et avec les différentes données présentées en dessous (Figure 25).


Page 133

4 Synthèse

Dans notre proposition, la carte heuristique qui doit constituer le support du projet joue

le rôle de moteur de la réflexion et de la communication. Sa simplicité permet d’agencer de

nombreuses informations sur un même support ce qui donne finalement une vision

synthétique de la vie de l’application, compréhensible par tous et modifiable par tous. La

navigation dans la map permet de comprendre les différentes étapes de la conception et les

liens existants entre elles. Elle aide aussi à comprendre les tenants et les aboutissants du

paramétrage de la solution décidée avec le client et à se repérer dans l’application par rapport

au descriptif réalisé lors d’une demande d’intervention. Au niveau de la communication elle

tend à homogénéiser la sémantique du fait qu’il est simple d’employer le même vocabulaire

que le client. Dans le cadre de la gestion de projet, cette carte heuristique présente de

nombreux avantages pour chacun des acteurs du processus mais également pour le client.

Pour les acteurs internes, l’utilisation d’un unique formalisme permet un gain de temps

considérable tout en augmentant leur efficacité. D’un point de vue client, le suivi de projet est

facilité, sa participation est accrue et de surcroît mise en valeur et la solution résultante répond

pleinement à ses attentes sans pour autant augmenter la durée du projet. Au fil du temps et

grâce à l’accessibilité et la facilité d’emploi, il est semble envisageable lors d’évolution de

déporter en partie l’analyse au client, ce qui permet à l’éditeur de rester centré sur son savoir

faire et au client de faire des économies (chiffrage plus précis et projet plus court). Pour

parvenir à une méthode efficace, il est important de définir une structure de carte centrée sur

le client représentant les grandes étapes répétitives du cycle de vie de son logiciel, afin de

s’inscrire dans la boucle d’amélioration continue de l’entreprise et de conserver une

dynamique de résultat.

Dans le cadre d’un projet, l’utilisation de la map offre une nouvelle dimension à la

définition de l’application et à la communication avec le client : une structure et une

organisation dynamiques et « immédiates » qui reprennent sur un seul document très visuel

l’ensemble des informations ce qui est un atout vis-à-vis des différents prototypes présentés

jusque là d’une réunion à l’autre. L’autre intérêt de la map réside dans le fait qu’elle est

conçue conjointement avec le client ce qui a pour effet de lui faire percevoir et assimiler la

philosophie du logiciel. Il lui semblera plus naturel et plus facile de justifier certains choix,

car il aura participé pro-activement à sa réalisation et s’appropriera d’autant plus la solution.


Page 134

Le dernier intérêt réside dans la dynamique de la réflexion. Les modifications sont visibles

immédiatement et dans la méthode heuristique, les oublies sont normalement maitrisés.

Pour accompagner et impliquer encore un peu plus le client lors de la construction de

la map et pour finalement replacer le client et en particulier les futurs utilisateurs au centre de

nos préoccupations nous proposons dans le chapitre suivant une démarche complémentaire de

la map pour faire émerger des spécifications directement par le client. Notre objectif est ici de

responsabiliser encore un peu plus de client dans l’analyse et de faire en sorte que l’éditeur

reste centré sur son savoir faire pour offrir une meilleure qualité de service.

Chapitre 5 Analyse centrée sur les acteurs

Page 135

Chapitre 5

Une analyse centrée sur les futurs utilisateurs

1 Introduction

L’étape de spécification constitue l’étape décisive du processus de déploiement et son

déroulement conditionnera non seulement le processus mais également la place de

l’application au sein de l’entreprise. Tout l’enjeu de cette étape est de définir un modèle le

plus précis possible de ce que souhaite le client sur le contour prédéfini. Pour se faire,

différentes réunions et échanges sont généralement mis en place pour recueillir les

informations auprès des acteurs censés posséder les connaissances, les analyser et constituer

la base de travail commune pour créer l’application. Ces éléments sont ensuite interprétés à

travers des outils méthodologiques pour finalement transparaitre dans l’application finale.

Cette étape doit permettre : d’appréhender le projet dans sa globalité, de définir le champ

d’action, les fonctionnalités, les aspects techniques, les spécificités, les processus, d’anticiper

les besoins… et ce avec une granularité allant jusqu’à l’utilisateur final. Comme une solution

logicielle performante et pertinente est inutile si les acteurs ne l’utilisent pas faute de

satisfaction il est primordial que les utilisateurs finaux restent, suite à l’informatisation, les

acteurs principaux du processus, ce seront eux les « moteurs » de l’application.

Pour être au plus près des besoins réels des futurs utilisateurs et être cohérent avec la

réalité du terrain, il est important de compléter l’étude du niveau globale (de l’entreprise) avec

une étude au niveau local (des acteurs). Comme pour la modélisation de la structure et de

l’organisation de l’entreprise, notre proposition consiste à utiliser une méthodologie et des

formalismes privilégiant la communication et aidant à une compréhension rapide des

problématiques. L’expérience acquise par LASCOM montre que les interviews menées chez

le client apportent des informations très importantes tant pour LASCOM pour définir une

solution aux plus près des besoins que pour l’entreprise cliente pour capter les besoins et

identifier les difficultés. Elles constituent une photographie de l’entreprise assez réelle en

fonction du nombre de participants. La problématique réside dans le temps nécessaire pour les

mettre en œuvre dans de bonnes conditions et obtenir des résultants probants. La section

présente la méthode pour obtenir des personas que nous avons identifiée comme étant un

levier nous permettant de lever les verrous que nous avons mis en évidence.


Page 136

2 Persona : une approche au plus près des utilisateurs finaux

2.1 Contexte et approche théorique

Dans le processus de conception de l’application, le problème se pose, de nouveau, en

termes de coût et de délais. Aujourd’hui, il n’est jamais ou presque jamais prévu d’impliquer

les utilisateurs dans le cadre de la définition du logiciel pour des raisons économiques (ces

personnes sont souvent jugées comme plus utiles à leurs postes qu’en réunion). En général les

utilisateurs sont interrogés en amont pour définir ou valider certains points du cahier des

charges mais ils le sont rarement lors des spécifications, à part ponctuellement pour

approfondir un point à travers leur supérieur hiérarchique ou le responsable du projet. Mais

ces interventions ponctuelles sont souvent compliquées car menée rapidement et sans un réel

support visuel de l’avancement de la définition et ce qui a pour effet de tronquer certains

éléments du contexte d’utilisation. L’utilisateur ne sait donc pas quelle est la démarche suivie

mais surtout les éléments déjà pris en compte ou pas. Le but étant souvent d’avantage de

valider la vision que l’éditeur et/ou le responsable de projet a plutôt que de comprendre le

mode de fonctionnement réel et les besoins associés, pourtant primordiaux pour l’utilisateur.

De plus, ces aspects sont gérés en interne, entrainant la multiplication des interprétations :

l’utilisateur comprend d’une certaine manière la question avec ou sans contexte, et formalise

sa réponse, qui est réinterprété par la personne qui lui a posé la question, pour refournir

l’information à l’éditeur/intégrateur au niveau méthodologique, puis au niveau de l’outil. Le

nombre croissant d’interprétations et d’interlocuteurs génère généralement un nombre

d’itérations important (pour revalider en interne, pour des problèmes d’incompréhension…)

engendrant une perte de la finesse et de la justesse dans la définition tant fonctionnelle que

technique par manque de temps. Finalement, ce mode de fonctionnement initialement censé

accroître l’efficacité de la définition des besoins en limitant le nombre d’interlocuteurs pour

l’éditeur/intégrateur, joue souvent en défaveur de sa qualité engendrant l’inadéquation

partielle de l’application finale avec les besoins réels des futurs utilisateurs et la non

acceptation du logiciel. Autrement dit, plus la définition des besoins est réalisée loin des

utilisateurs, plus la compréhension du système est partielle et plus l’application s’éloignera

des besoins des utilisateurs et plus la résistance au changement sera forte. Il nous faut donc

identifier une méthodologie ou un formalise proposant une meilleure projection dans

l’application pour l’ensemble des intervenants tout en sachant que nous aurons déjà à notre

disposition une représentation heuristique du système. Nous connaitrons donc à minima les


Page 137

acteurs et leurs besoins, la méthode devant être un support à la mise en évidence de

l’utilisation qu’ils feront de l’application.

Depuis quelques temps en ergonomie web, pour concevoir des interfaces plus

adaptées, des nouveaux supports issus du monde du théâtre sont apparus : les PERSONAS

(Annexe 4). Un « persona » est un archétype des futurs utilisateurs listant leurs besoins et

leurs habitudes supposés. Ce profil utilisateur créé de toutes pièces en fonction de données

prospectives, représentatif de la cible ergonomique d'un site web, a pour but de

« théâtraliser » l’utilisation. C'est donc une personne « virtuelle » qui va servir de référent à

toute l'équipe de conception pour considérer les exigences utilisateur à travers la description

d’un utilisateur et de l’utilisation qu’il fera de l’application. C’est ainsi un site adapté à ses

besoins qui sera conçu facilitant l’accès aux fonctionnalités les plus usitées par exemple. Ce

support permet une meilleure projection des besoins et des contraintes des futurs utilisateurs

dans la conception de l’application pour l’ensemble des intervenants en développant leur

imaginaire. La méthode de conception des personas présuppose de connaitre a minima la

cible, en se basant sur des données tangibles issues de sondages ethnographiques,

sociologiques et psychologiques [Brangier, 10], et/ou d’imaginer ses besoins et l’utilisation

qui sera faite du site ou de l’application. Elle est rapide à concevoir, à mettre en œuvre et son

support de diffusion est relativement accessible.

Notre proposition est donc d’adapter et construire une démarche d’utilisation de cette

méthode dans le cadre du déploiement des solutions LASCOM. Pour ce faire nous allons

créer des questionnaires à destination des acteurs pour isoler des personas « réels » définissant

les besoins fonctionnels et techniques. Le but est de créer des personas en fonction des

besoins et des retours d’expériences des acteurs et non pas d’imaginer le comportement des

futurs utilisateurs. Ceci pour déterminer les besoins réels des utilisateurs pour valider les

exigences retenues (issues du cahier des charges et de l’analyse des besoins) et s’assurer de la

prise en compte de l’ensemble des besoins « pratiques » afin de maximiser la pertinence du

logiciel tout en intégrant les utilisateurs au projet d’informatisation. L’objectif n’étant pas de

prendre en compte toutes les requêtes mais d’identifier les situations non traitées, les oublies

et les manques, les évolutions potentielles.


Page 138

2.2 De la map à persona : de l’entreprise à l’acteur

2.2.1 Etape préliminaire : comment et quand établir les questionnaires ?

Jusqu’à présent, les éditeurs arrivaient à se différencier sur le marché grâce au rapport

coût / nombre de fonctionnalités, longtemps considéré comme un indicateur d’innovation. Le

centrage acteur était alors perçu comme une contrainte souvent secondaire par les éditeurs lors

de la conception de leur application au regard des contraintes techniques et technologiques

pour fournir toujours plus de fonctionnalités. Mais aujourd’hui avec l’essor du nombre

d’applications, aux critères de choix précédents s’ajoutent l’ergonomie. La prise en compte de

ce nouveau facteur impose aux éditeurs de ne plus considérer les utilisateurs uniquement

comme des simples profils informatiques (classiquement pour un utilisateur : qu’a-t-il le droit

de voir ? qu’a-t-il le droit de faire ? sous quelles conditions ?), mais comme un ensemble de

scénarii d’utilisation à faciliter.

Classiquement LASCOM procédait par interviews successives des intervenants directs

pour faire émerger des grands profils informatiques d’utilisateurs parfois assez éloignés de la

réalité du terrain. Ces intervenants directs du projet n’étaient en général pas les utilisateurs

finaux et LASCOM ne faisait pas d’interviews des utilisateurs mais bien uniquement des

personnes présentes aux réunions et missionnées par le client. Un profil pour LASCOM était

donc vu au sens « administration d’un logiciel » : que peut voir la personne, quelles actions a-

t-elle le droit de faire sur ces éléments et sous quelles conditions ? Dans notre proposition

nous allons chercher à conserver un peu cette façon de travailler qui a fait ses preuves mais en

allant beaucoup plus dans la définition des profils réels et en évitant le biais des interviews

(questions orientées par l’éditeur hors du contexte) pour être plus en phase avec les

utilisateurs. Les questionnaires que nous devons établir contribueront à la définition des

actions menées par chacun, c'est-à-dire que pour chaque action les acteurs auront à répondre

aux questions qui, quoi, comment et quand. Pour ne pas entrer dans les travers des interviews

tout en conservant leur pertinence, nous avons décidé d’opter pour des questionnaires

informatisés (ici Excel pour faciliter les traitements), limités en taille pour ne pas immobiliser

le personnel trop longtemps, et diffusés à des moments clés assez fréquents pour affiner le

questionnement et accroître la communication. Les questionnaires seront composés de deux

parties : une partie questionnement (QX) basée sur les informations recensées dans le cahier

des charges directement ou indirectement à travers la map, et une partie résultat (QX-1)

présentant les informations validées traitées dans le questionnaire précédent. A ce stade de la

définition il apparait important de dissocier deux phases dans le questionnement


Page 139

correspondant aux deux grandes phases du cycle de vie du logiciel durant lesquelles les

utilisateurs représentent les meilleures sources de retours d’expérience : durant l’analyse des

besoins et durant l’exploitation, car le questionnement n’aura pas les mêmes objectifs.

Durant la phase d’analyse des besoins, le rythme d’envoi ainsi que le contenu du

questionnaire doivent idéalement être en phase avec les différentes réunions d’analyse et de

spécifications que ce soit pour la conception du cahier des charges ou la conception de

l’application. L’intérêt étant d’avoir les résultats de chacun des « sondages » au moment de la

réunion afin qu’ils puissent être une source d’exploration ou de validation au même titre que

les participants présents. Ainsi, il sera plus aisé pour chacun des intervenants de comprendre

et d’assimiler les besoins réels, et de trouver la formulation du besoin et/ou la solution

adéquate. En effet, lorsque l’exigence est formulée sous forme « tous les vendredis, Léo doit

imprimer et envoyer la liste des plans posant problèmes pour la réunion de suivis

hebdomadaire » la réflexion et l’exploration des solutions ne seront pas les mêmes que

lorsqu’elle est sous forme « Exporter la liste des plans » qui correspond au besoin générique

émis initialement dans le cahier des charges. Pourtant l’exigence est bien la même « Exporter

la liste des plans » mais, grâce à la scénarisation, des détails contextuels sont apparues sur la

fréquence de réalisation, sur la condition de recherche et sur le but. Dans le cas de l’exigence

générique, la réflexion ne sera pas poussée et la réponse sera d’utiliser la fonction standard

d’export, mais dans ce cas Léo risque d’avoir des difficultés toutes les semaines pour fournir

cette liste. Alors que dans le second cas, la question se posera de savoir comment identifie-t-

on les « plans posant problèmes » (faut il ajouter une propriété ? Est-ce l’état du document qui

nous donne l’information ou est-ce le nombre de versions ?) et à qui doit-t-on envoyer cette

liste (peut-on créer un groupe fixe ?) pour pouvoir utiliser la fonction standard d’abonnement

qui permet d’envoyer une liste respectant certaines conditions à une fréquence donné.

Autrement dit, sans exemple concret, sans aller au bout du raisonnement, seule l’exigence

générique aurait certainement été traitée et la question de l’identification d’une condition

particulière pour repérer des difficultés n’aurait pas été abordée, de même que

l’automatisation de cette tache jugée « particulière » pour les personnes ayant rédigés le

cahier des charges et qui pourtant peut être générique également. La création de ces personas

a un double intérêt : replacer l’utilisateur au centre des spécifications en tant qu’animateur de

besoins puis en tant que « valideur » de profil au sens informatique, mais également de

faciliter la communication tant au sein de l’équipe de création (de la réflexion en passant par

le développement voire même la documentation), qu’au sein de l’entreprise. En effet, il est

souvent plus facile de communiquer et de se comprendre sur des exemples concrets, que sur


Page 140

des exemples abstraits emprunts aux malentendus. Plus la phase de conception avancera, plus

le questionnaire s’orientera sur la définition des profils des utilisateurs interrogés pour aboutir

à circonscrire leur espace d’action et d’interaction définissant ainsi les profils relatifs à la

branche organisation de la carte heuristique du projet dans la section contexte (Figure 26). Ces

personas constitueront la base de référence pour définir les différents types d’utilisateur de

l’application, utile pour lister les besoins concrets, imager la réalisation ou la modification de

l’administration du logiciel, mais également pour faciliter l’expression de nouveau besoin, et

finalement concevoir une application au plus près des besoins des utilisateurs. Pour favoriser

la participation, il est important que les utilisateurs soient également informés des résultats

afin de prouver la prise en compte de leur réponse et qu’ils s’approprient petit à petit les

éléments qui seront contenus dans leur application. Finalement, l’utilisation du sondage des

utilisateurs durant la phase de conception, apporte au fur et à mesure de la définition la

confrontation de la vision globale (« qu’est ce qui est fait par qui » utilisé durant les réunions)

à la vision local (« qui fait quoi »), dessine et affine la définition des personas par

regroupement d’information, et participe aussi à l’intégration des utilisateurs à la conception.

L’utilisation des questionnaires pourrait s’arrêter à la fin de la conception puisque

l’application et les personas types sont définis, mais le risque demeure que les utilisateurs

impliqués dans cette dynamique de questionnement se retrouvent frustrés de ne plus avoir de

moyen de s’exprimer au moment même où enfin ils voient et utilisent le « résultat » des

différents sondages : le logiciel et où ils se retrouvent au cœur du système. Le déploiement est

un moment tout aussi stratégique, il serait aberrant de couper la communication à cet instant

précis et même par la suite. Ainsi, durant la phase d’exploitation, les questionnaires devront

toujours être présents. Ils seront moins fréquents et essentiellement axés sur les difficultés

rencontrées lors de l’utilisation de l’application et les améliorations que les utilisateurs

souhaiteraient voir apparaitre. Un rythme assez soutenu sera malgré tout conservé au début de

chaque phase de déploiement pour détecter les difficultés voire les blocages potentiels des

utilisateurs. Ce tempo aura ensuite tendance à ralentir. Idéalement, il serait pertinent que les

utilisateurs puissent eux même demander un questionnaire de satisfaction à tout moment afin

de s’exprimer sur le logiciel quand ils le souhaitent (dès qu’ils rencontrent une difficulté par

exemple). S’ils doivent attendre un jalon bien précis pour réagir sur l’application, ils auront

certainement oubliés les soucis rencontrés ou n’auront peut être pas le temps de remplir le

questionnaire correctement si ce jalon « tombe mal ». L’objectif de cette base de retours

d’expériences est de voir comment pallier aux difficultés (demander une correction de bug,


Page 141

réaliser une formation complémentaire, diffuser des supports adaptés aux problèmes relevés,

etc.) mais également d’identifier et de prioriser les évolutions à prévoir.

Figure 26. Persona ou la définition de l’organisation dans la map projet


Page 142

L’utilisation des questionnaires pourrait s’arrêter à la fin de la conception puisque

l’application et les personas types sont définis, mais le risque demeure que les utilisateurs

impliqués dans cette dynamique de questionnement se retrouvent frustrés de ne plus avoir de

moyen de s’exprimer au moment même où enfin ils voient et utilisent le « résultat » des

différents sondages : le logiciel et où ils se retrouvent au cœur du système. Le déploiement est

un moment tout aussi stratégique, il serait aberrant de couper la communication à cet instant

précis et même par la suite. Ainsi, durant la phase d’exploitation, les questionnaires devront

toujours être présents. Ils seront moins fréquents et essentiellement axés sur les difficultés

rencontrées lors de l’utilisation de l’application et les améliorations que les utilisateurs

souhaiteraient voir apparaitre. Un rythme assez soutenu sera malgré tout conservé au début de

chaque phase de déploiement pour détecter les difficultés voire les blocages potentiels des

utilisateurs. Ce tempo aura ensuite tendance à ralentir. Idéalement, il serait pertinent que les

utilisateurs puissent eux même demander un questionnaire de satisfaction à tout moment afin

de s’exprimer sur le logiciel quand ils le souhaitent (dès qu’ils rencontrent une difficulté par

exemple). S’ils doivent attendre un jalon bien précis pour réagir sur l’application, ils auront

certainement oubliés les soucis rencontrés ou n’auront peut être pas le temps de remplir le

questionnaire correctement si ce jalon « tombe mal ». L’objectif de cette base de retours

d’expériences est de voir comment pallier aux difficultés (demander une correction de bug,

réaliser une formation complémentaire, diffuser des supports adaptés aux problèmes relevés,

etc.) mais également d’identifier et de prioriser les évolutions à prévoir.

La diffusion de notre questionnaire suit donc le cycle de vie du logiciel (Chapitre 3,

Figure 10), allant d’une démarche de modélisation à une enquête de satisfaction, l’importance

étant de rester concentrer sur les acteurs, moteur de la performance. Les avantages sont d’un

point de vue logiciel d’apporter une vision plus proche de la réalité au moment de la

définition de l’application pour l’adapter aux utilisateurs et d’un point de vue humain, de

diminuer la réticence aux changements en rendant les utilisateurs actifs et participatifs au plus

tôt dans le processus sans les immobiliser trop longuement.

2.2.2 Mise en place des questionnaires durant la phase d’analyse des besoins

Durant la phase d’analyse des besoins, l’objectif des questionnaires est de déterminer

les besoins et les difficultés actuels des utilisateurs, sur le contour prédéfini d’impact du

logiciel, pour isoler les personas réels, bases de la conception de l’application. Pour parvenir à

ce résultat, nous avons établie trois étapes minimum étaient nécessaires :


Page 143

- Lister les éléments manipulés,

- Lister les manipulations effectuées et définir ces manipulations,

- Présentation du résultat, c'est-à-dire les personas résultant.

Pour mener à bien ces étapes, nous avons établis quatre modèles de questionnaires. Le

premier questionnaire sera envoyé à l’issue du lancement de projet afin d’obtenir des éléments

qui aideront à débuter l’analyse plus précise du besoin. L’initialisation du questionnaire sera

donc réalisée sur la seule base disponible à ce moment du processus, c'est-à-dire la première

définition des besoins vue par l’avant vente et décrite dans la map. Les éléments présents dans

la map sont primordiaux car ils structureront certaines parties du questionnaire. L’utilisateur

sera seul devant le fichier Excel « questionnaire » et si aucun élément de réponse issu de la

map n’est proposé (sous forme de liste par exemple) il existe un risque non négligeable de

n’obtenir aucun résultat car sans guide et sans dynamique l’utilisateur ne sera pas enclin à

explorer ses expériences et ses connaissances pour compléter le questionnaire. Même si

comme nous l’avons vu cette définition est souvent « grossière », elle fait tout de même

apparaitre un certain nombre de documents et de fonctionnalités exploitables dans le

questionnaire. La première version du questionnaire aura pour but d’expliquer le projet et plus

particulièrement le cadre de cette démarche de questionnement et d’identifier tous les types de

documents manipulés par les utilisateurs. L’expérience de LASCOM montre que cette entrée

est souvent plus naturelle pour les utilisateurs dans la cadre d’une modélisation

« ascendante ». Dans le questionnaire Q1, les utilisateurs pourront choisir les documents

qu’ils manipulent dans la liste pré-initialisée et/ou en ajouter dans la colonne prévue à cet

effet. De plus, afin de débuter la caractérisation de ces documents, ils devront également

choisir leur provenance et leur fréquence d’utilisation (Figure 27). Ce « sondage » peut être

envoyé à un grand nombre de personnes car il a le mérite d’expliquer dans l’introduction la

mise en place du projet. D’un point de vue pratique un grand nombre de retours ne posera pas

de problème puisque le traitement des réponses sera automatique.


Page 144

Figure 27. Les documents manipulés vus par les utilisateurs

La largesse de ce premier sondage ne permet pas de s’assurer que les documents listés

constituent réellement une liste finie de documents. Elle correspond plutôt à une liste usuelle

pour l’utilisateur dont la dénomination correspond à la sémantique du client. Cette liste sera

confrontée aux résultats obtenus lors des réunions d’analyse afin de valider ou compléter la

carte heuristique (Figure 28) et aboutir à la constitution d’une liste finie de documents

catégorisés, à traiter, à cet instant du processus, dans le cadre du logiciel.

Une fois cette liste déterminée, l’objectif du second questionnaire sera de cadrer

l’utilisation (quelle manipulation est réalisée et sur quel document) réalisée par les utilisateurs

de ces éléments, et ce par profil. Pour cela, le questionnaire Q2 sera envoyé à certains

utilisateurs prédéterminés par le client, utilisateurs représentatifs d’un panel pour chaque

profil prédéterminé. La constitution du panel pourra évoluer en fonction de l’avancée de

l’analyse et des retours. Ce questionnaire sera cette fois nominatif et présentera une partie du

choix finie (la liste complète des documents) et une partie libre (les actions réalisées). C'est-à-

dire que la pré-initialisation sera basée sur les résultats des premières réunions d’analyse du

besoin et non pas sur les résultats du premier questionnaire pour que les utilisateurs explorent

de nouvelles possibilités. Le travail demandé sera simplement de sélectionner le niveau de

difficulté rencontré aujourd’hui pour réaliser les actions que les utilisateurs mènent

relativement aux documents (Figure 29).


Page 145

Figure 28. Les questionnaires sources de la typologie des documents


Page 146

Figure 29. L’utilisation vue par les utilisateurs


Page 147

Selon la taille de la liste de documents, il est tout à fait possible de scinder ce

questionnement en plusieurs étapes, l’objectif étant que le temps nécessaire pour répondre

n’excède pas 10 min. Par contre il est essentiel que dès le premier envoi d’un questionnaire

Q2, la liste finie de document avec sa description soit présentée dans l’onglet de résultat afin

de valoriser le travail commun et débuter l’appropriation du contenu de la future application

(Figure 30). Pour faciliter la compréhension des utilisateurs et les sensibiliser aux choix

effectués, il est important de décrire le contenu de chacune des catégories génériques retenues

avec les différents termes usités par les utilisateurs dans le premier questionnaire.

Figure 30. Communiquer sur l’aboutissement du travail commun


Page 148

Les résultats de Q2 seront utilisés dans un premier temps et comme précédemment en

réunion d’analyse pour valider ou agrémenter la liste des actions possibles par type de

document pour correspondre au plus juste aux besoins et à la sémantique client. La fréquence

et le niveau de difficulté donneront un éclairage supplémentaire sur l’importance de

l’informatisation de la fonctionnalité et de l’intégration de certains types de documents pour

faciliter accessibilité par exemple. Les premiers objectifs étant d’établir une liste finie des

actions compréhensibles par les utilisateurs qui sera présentée dans le questionnaire suivant

(Figure 31) et de valider la liste des différents types de documents à intégrer dans la future

application.

Figure 31. Communiquer sur les listes établies


Page 149

Une fois la liste des actions finie, le traitement des réponses doit être reconsidéré mais

cette fois en fonction des profils présupposés en vue de la construction des personas. Grâce à

son caractère nominatif, le questionnaire Q2 permettra de réaliser l’analyse des résultats pour

valider la cohérence des profils tant sur leur constitution (les personnes) que sur leur

construction (les documents manipulés et les manipulations). Une grille d’utilisation de

l’application par profil, correspondant au profil informatique, sera alors établie et présentée

dans le prochain questionnaire, le Q3 (Figure 32).

Figure 32. La grille d’utilisation de l’application


Page 150

A partir des résultats par profil, revus en fonction des analyses, un nouveau

questionnaire Q3 sera constitué pour affiner les personas, avec cette fois comme éléments

finis la liste des documents et celle des actions. Les utilisateurs auront à renseigner une

description d’utilisation pour situer et contextualiser leurs interactions, caractériser leur besoin

et valider la compréhension de la liste des actions uniformisée (Figure 33). Le but est de

personnifier les profils en illustrant des cas d’utilisation et de revalider la constitution des

profils, des fonctionnalités et des documents associés à celui ci. Pour ce faire, les

fonctionnalités seront organisées en deux groupes, celles détectées comme faisant partie du

profil et celles n’en faisant pas partie. Il en sera de même pour les documents. Pour faciliter la

saisie, les cellules qui ne sont logiquement pas à renseigner, sont hachurées mais l’utilisateur

peut malgré tout les remplir si effectivement cela correspond à son besoin. Le but n’est pas de

restreindre les fonctionnalités et les documents possibles mais bien de valider

« définitivement » son cadre d’utilisation d’où la nécessité de pouvoir compléter encore le

document pour ne rien omettre.

Les résultats permettront dans un premier temps de valider définitivement les profils

informatiquement parlant, grâce au remplissage des espaces hachurés ou pas mais également

les libellés des catégorisations des documents et des actions grâce à la phrase descriptive et à

la sémantique employée. Dans un second temps, les réponses permettront de créer des

personas « réels » pour personnifier et scénariser les besoins dans le but de mieux les

appréhender, et ce pour toutes les personnes travaillant sur le projet. En fonction des

descriptions apportées pour les cas d’utilisation non prévus ou peu fréquents, soit le profil sera

révisé, soit une étude plus précise pourra être réalisée individuellement pour comprendre

comment et pourquoi ces personnes interviennent dans le processus. A partir de ce niveau

d’avancement du processus, c'est-à-dire à la fin de la définition du contexte, les utilisateurs ne

seront plus questionnés aussi régulièrement et de manière aussi pointue car pour la suite -

c'est-à-dire la définition de l’application-, les retours d’expériences terrain n’apporteront plus

autant de valeur ajoutée. Pour réaliser ce basculement et étant donné qu’il est important de

montrer la contribution de Q3 sur l’évolution de la définition des profils, il est tout à fait

envisageable de lancer un dernier sondage (Q4) pour présenter le persona répondant à

l’utilisateur et dont l’objectif est de lui définir un nom par exemple. L’objectif de présenter

son persona, relatif à l’application, à l’utilisateur est qu’il puisse s’identifier à lui, d’une part

grâce à la description textuelle d’un exemple d’action réalisable dans l’application, le

scénario, d’autre part d’assimiler le vocabulaire de l’application en mettant en perspective la


Page 151

description avec les libellés de l’application (les lignes et les colonnes) (Figure 34). Cet

archétype définit le cadre fonctionnel d’utilisation et l’illustre.

Figure 33. Personnifier l’utilisation


Page 152

Figure 34. Présenter le persona de l’utilisateur


Page 153

Durant la suite du processus de définition de l’application il est tout à fait possible de

continuer à réaliser des petits sondages permettant de définir des petits points ergonomiques

(sur le visuel, des couleurs, des icones, etc.) ou sur des aspects plus fonctionnels (le choix des

messages, les successions d’actions, les critères de recherche, etc.). Le but est d’entretenir un

bon niveau de communication sur l’avancée du projet par le fait de conserver une forte

participation d’un grand nombre d’utilisateurs à la conception de leur future application.

La succession des questionnaires offre une connaissance précise et réaliste des besoins

des utilisateurs et du fonctionnement de l’entreprise à un niveau très opérationnel. Le

questionnement direct permet d’approcher un peu plus les besoins des utilisateurs lors de la

phase de conception de l’application, tout en limitant la réticence au changement et en rendant

chacun des utilisateurs acteur de la définition du contexte. En effet, chacune des contributions

apporte des éléments d’exploration pour compléter la carte heuristique du contexte, contribue

à définir la sémantique à employer, définie des personas pour personnifier les besoins. Les

questionnaires quant à eux contribuent à la communication sur le projet et fournissent des

explications sur les termes employés dans la future application en mettant en perspective le

contexte de l’application avec un exemple d’utilisation exprimé avec la sémantique usuelle.

Aucun des questionnaires présentés n’étant lié directement au choix de l’application à

mettre en place, toutes les étapes relatives à la saisie des informations peuvent être réalisées

en amont par le client soit pour établir le cahier des charges, soit pour préparer le projet

d’informatisation. L’un des intérêts de réaliser les questionnaires très en amont réside dans le

fait que cette enquête aiderait le client à clarifier et délimiter ses besoins à moindre coût, sans

avoir recourt à un consultant et sans immobiliser durablement les acteurs. Cette démarche

rendrait aussi la conception du cahier des charges « client » plus simple et plus précise, ce qui

aurait pour effet de limiter les « mauvaises surprises » tout au long du projet et en particulier

lors des chiffrages.

2.2.3 Mise en place des questionnaires durant la phase d’exploitation

La valeur ajoutée du questionnement des utilisateurs réapparait lors du déploiement de

l’application c'est-à-dire du démarrage de l’utilisation du logiciel par les différents acteurs. En

effet, ce sont les utilisateurs qui sont les « moteurs » de l’application or s’ils rencontrent des

difficultés ou des impossibilités à réaliser leur travail correctement à cause de l’application, le

risque est de voir une recrudescence des mécontentements voire le boycott de l’application.


Page 154

La communication est donc le point clé de cette phase : il ne faut pas laisser les utilisateurs

seuls face à leurs difficultés. Les questionnaires en exploitation peuvent répondre à ce besoin

de détection et d’identification au plus tôt des difficultés rencontrées, des points bloquants,

des manques, etc. LASCOM ainsi que le support interne seront alors en mesure d’apporter les

réponses adaptées (formation, support, accompagnement…), de solutionner les problèmes

mais également d’identifier les besoins futurs car ils constituent des problèmes potentiels s’ils

ne sont pas pris en compte.

Le premier questionnaire doit rapidement faire suite au déploiement afin d’instituer ce

mode de fonctionnement et prévenir les utilisateurs qu’ils ne sont pas seuls, qu’il existe des

moyens de faire remonter leurs problèmes (soit le questionnaire, soit le support interne). Pour

pondérer leurs réponses, nous proposons de réaliser deux parties dans les questionnaires de

retours d’expériences : les difficultés rencontrées et les demandes d’amélioration. En effet,

autant il est difficile de demander à un utilisateur lambda de mesurer objectivement la criticité

de ces problèmes surtout au début, autant il semble envisageable de lui faire dissocier les

problèmes rencontrées concrètement dans l’application (c'est-à-dire qu’il arrive à définir le

contexte de son besoin avec les termes de l’application) et ce qu’il souhaiterait faire (dont le

contexte n’est pas explicitable facilement avec les éléments présents dans l’application). Dans

un premier temps, la pertinence de cette décomposition ne sera pas forcément visible mais elle

apparaitra lorsque la base évoluera et s’enrichira dans le temps, proportionnellement à

l’appropriation du logiciel par les utilisateurs. Le premier objectif n’est pas la qualité des

retours mais de continuer la démarche centrée sur l’acteur tout en conservant la dynamique et

la communication autour du projet. Ceci ne sera possible que si les questionnaires reflètent la

démarche de LASCOM et le fait que nous sommes aux cotés des utilisateurs pour surpasser

leurs difficultés et pour les aider à utiliser notre solution logicielle. Démarche qui va au-delà

de l’accompagnement puisque les avis sont pris en compte pour améliorer la solution de telle

sorte que les utilisateurs doivent toujours se sentir acteurs de la conception et de

l’amélioration de « leur » logiciel. Cette démarche d’accompagnement/amélioration continue

se traduit dans le modèle de questionnaire R1 par :

- la présence d’un certains nombres de listes pré-paramétrées en cascade qui cernent le

contexte du problème et d’une partie libre pour que l’utilisateur exprime ses difficultés

(Figure 35),


Page 155

- la présence uniquement de la liste des documents pour cibler le contexte de la

demande et d’une zone libre (Figure 36) pour saisir les améliorations qu’il pense

envisageables et souhaitables.

Figure 35. Les difficultés des utilisateurs


Page 156

Figure 36. Les demandes d’améliorations des utilisateurs

Finalement les deux parties du questionnaire R1 ont le même objectif : limiter la

réticence aux changements en donnant la parole à ceux qui doivent nécessairement utiliser le

logiciel. Au moment du déploiement, les difficultés liées à la découverte d’un nouveau

logiciel et à la pertinence de la formation seront nombreuses. Les réponses se traduiront


Page 157

souvent par des compléments de formations, de l’accompagnement personnalisé, ou création

de supports plus simples. Au niveau des demandes d’amélioration l’expérience montre que

dans un premier temps elles correspondent généralement à la modification des profils et des

droits. Au fil du temps, les retours d’expériences seront de plus en plus pertinents et

l’identification des problèmes plus précise. Ce type de questionnement doit perdurer tout au

long de la vie de la solution même si la fréquence des échanges diminuera au fil du temps, les

difficultés et les demandes d’amélioration étant de moins en moins nombreuses.

Grâce au questionnement des utilisateurs durant l’exploitation du logiciel, le niveau

d’utilisation de l’application sera maximisé et l’évolution de l’application répondra aux

attentes réelles de l’entreprise. La solution offrira alors un niveau important d’adéquation

entre les besoins des utilisateurs et les réponses du logiciel. Les retours d’expériences des

utilisateurs permettent non seulement d’inscrire le logiciel dans la boucle d’amélioration

continue de l’entreprise mais également les utilisateurs en tant qu’acteur de la qualité.

3 Synthèse : Confrontation des deux approches pour consolider le

modèle

De nombreuses méthodes pour définir et représenter un système existent mais leur

mise en œuvre est souvent longue et coûteuse. Elles permettent d’obtenir une cartographie

complexe pour apporter à la fois tous les éléments nécessaires à la définition du niveau global

jusqu’au niveau local mais également au paramétrage de la future application PLM. Le

principal inconvénient réside dans le fait que chaque méthode possède son formalisme propre

et qu’il y a souvent une « surcharge d’informations » à représenter et/ou une multiplication

des modèles. Ainsi même achevés, les modèles ne constituent pas un bon support de

communication transverse pour l’entreprise ils apportent rarement une représentation des

éléments globaux et locaux sur un même support. Autrement dit un utilisateur lambda

éprouvera des difficultés à repérer ses actions et ne peut donc pas facilement et rapidement

vérifier les points qui le concernent s’il ne connait pas le formalisme ou s’il n’a pas suivi son

élaboration. Il existe de nombreuses méthodes permettant de définir les aspects fonctionnels

du produit souhaité, mais la définition d’un outil PLM demande également la spécification,

toute aussi importante, des aspects techniques et organisationnels qui eux sont moins encadrés

car dépendants du logiciel. Pour se rapprocher au plus près des utilisateurs certaines méthodes

préconisent de réaliser des interviews pour élaborer par regroupement les visions globales et

locales mais aussi les aspects fonctionnels et techniques. Ces approches sont souvent mal

perçues par les entreprises et les intégrateurs. Pour les premières, elles jugent souvent trop


Page 158

long le temps d’immobilisation de leurs personnels (temps de l’interview, de la restitution,

d’échange entre les personnes). Elles ont aussi la certitude que cela n’influencera pas de façon

majeure le fonctionnel de l’application au regard du coût de la mise en place des interviews.

Du point de vue des intégrateurs, ils ont du mal à vendre ces prestations, généralement

attribuées à des sociétés de conseil, car elles sont longues (temps de conception en fonction du

besoin, interviews, consolidation, restitution) tout en sachant que le résultat sera exploitable

qu’en partie de par la pertinence des réponses et les capacités de l’outil. Ces éléments mettent

en perspective uniquement la durée et le coût face au résultat technique et tangible alors qu’il

ne faut pas sous estimer l’apport de la communication et de la participation vecteurs important

dans la valorisation des personnes et la diminution de la réticence aux changements.

Finalement les méthodes proposées dans la littérature sont souvent fastidieuses, onéreuses et

présentent quatre inconvénients majeurs :

- le mise en évidence des besoins de l’entreprise mais aussi sur des besoins de l’éditeur

quant à la définition et au paramétrage du logiciel est souvent complexe,

- la construction d’une cartographie décrivant l’entreprise est peu évidente et souvent

celle-ci est inappropriée de par la complexité de la formalisation pour qu’elle soit

lisible et compréhensible par tout un chacun. La mise à jour de la cartographie dès que

l’entreprise évolue pose aussi problème car elle oblige souvent à sa recréation

complète,

- la mise en œuvre puis la confrontation d’une approche de modélisation ascendante et

descendante n’était pas possible pour des questions de coût et de délais, ce qui pouvait

limiter la qualité du modèle.

- l’implication active des futurs utilisateurs dans le projet dans les temps impartis est

quasiment impossible. Cette absence de vision « terrain » conduit souvent à de

nombreuses itérations coûteuses entre les étapes de spécifications, de modélisation et

les tests en vue de l’obtention d’un consensus entre le résultat au regard des attentes

réelles.

Dans notre proposition, l’utilisation de la carte heuristique « générique » présentée

précédemment permet de pallier en partie aux problèmes de profondeur de l’analyse en

descendant un peu plus vers le niveau local et de communication grâce à l’élargissement

potentiellement du champ des utilisateurs participant à l’analyse des besoins, voire à la

conception de l’outil. Cependant cette solution ne répond pas pleinement aux difficultés

rencontrées en termes d’intégration systématique et de participation active des utilisateurs


Page 159

finaux car elle ne lève pas le verrou de la durée de l’immobilisation d’un grand nombre de

salariés. Pour pallier à cet inconvénient nous avons proposé d’utiliser une méthode

complémentaire telle que persona pour interroger et impliquer les utilisateurs de façon directe

et autonome. Ils seront ainsi partie prenant du projet tout au long du processus de déploiement

voire au cycle de vie complet du logiciel.

Mise en commun, ces deux outils permettent de lever les verrous liés aux délais et à la

communication, en se basant sur une démarche et des supports simples à réaliser et à

comprendre. Le but est ici d’obtenir non pas une modélisation précise de l’entreprise mais une

modélisation suffisante à l’implémentation d’un logiciel informatique c'est-à-dire pour

appréhender plus efficacement le contexte et les besoins. Ces supports sont complémentaires

et nécessitent de peu temps d’adaptation offrant la capacité d’élargir le nombre de participants

pour chacune des étapes du processus. Or plus le nombre de participants est important, plus

nous diminuons le risque d’omettre des aspects du fonctionnement de l’entreprise et plus le

logiciel correspondra pleinement à l’entreprise. La mise en place de retour d’expérience

permet de surcroit de pérenniser ce fonctionnement à long terme. Nous aboutissons donc à

deux supports simples à comprendre et à mettre à jour : un support pour suivre le cycle de vie

du logiciel, la carte heuristique, et un support pour évaluer l’utilisation et les améliorations,

les personas. Cette association améliore le processus, le logiciel, et surtout apporte une

meilleur visibilité et une meilleure communication.

Au-delà des avantages liés à la mise en parallèle de ces deux outils, il est intéressant

de noter que ces outils présentent aussi de nombreux avantages individuellement tant pour

faciliter le déroulement du processus de déploiement, que pour améliorer la qualité du logiciel

et de la communication. Ils peuvent aisément être utilisés indépendamment l’un de l’autre

pour améliorer la perception d’une situation précise en fonction du contexte et du besoin. La

carte heuristique permet d’obtenir un support unique pour suivre le cycle de vie du logiciel et

sa construction repose sur l’approche descendante, tandis que le persona illustre le rôle tenu

par les utilisateurs dans un environnement plus ou moins précis en se basant sur une approche

ascendante. Cependant c’est l’association des deux supports qui nous intéresse ici car elle

offre une dimension de complémentarité des approches grâce à la double exploration du

système et à une confrontation facilitée sur un même support (Figure 37). La valeur ajoutée de

l’interaction entre les deux se situe essentiellement sur l’analyse des besoins et sur l’analyse

du résultat (le logiciel).


Page 160

Figure 37. Apport de persona au contexte de la carte heuristique


Page 161

Ces deux supports doivent vivre avec le logiciel, pour être en phase avec l’entreprise,

identifier les évolutions et les modifications dès leur émergence et donc éviter que le système

ne soit bloqué. Ceci nécessite de laisser la possibilité aux utilisateurs d’utiliser un modèle

qu’il puisse émettre quand il le souhaite pour être réactif, ne pas perdre de l’information et ne

pas laisser les utilisateurs face à une difficulté. Pour être pertinent, les retours d’expérience

doivent être nominatifs, afin de voir l’évolution des difficultés pour chacun, de comparer les

demandes aux personas, mais également pour cibler les groupes d’utilisateurs pour réaliser

des formations complémentaires par exemple. L’idée première pourrait être d’utiliser une

sorte de forum mais le risque est que les utilisateurs n’osent pas avouer leurs difficultés aux

yeux et à la vue de tous. Il semble donc nécessaire d’avoir une sorte de médiateur, qui apporte

une réponse précise à l’utilisateur directement, et qui généralise la question et les réponses

pour enrichir une base de connaissance libre d’accès. Idéalement, cette FAQ doit être

consultable à travers l’application même.

Finalement ce couplage de méthodes permet de faciliter le centrage sur l’acteur en

apportant un support à la communication tout au long du cycle de vie. Les utilisateurs se

trouvent au cœur de la définition et de l’amélioration du leur logiciel, car ce sont eux qui

possède l’expérience tant avant la mise en place du logiciel qu’après. L’informatisation peut

résoudre des problèmes que si ces derniers sont énoncés clairement, et ne pas en créer de

nouveau si la situation est définie dans son contexte. Le sondage ne résout pas toutes les

difficultés mais offre l’intérêt de favoriser la communication avec le plus grand nombre

limitant ainsi la réticence au changement, et d’augmenter la performance de l’outil en

améliorant la définition du niveau local.

Chapitre 6 Études de cas

Page 163

Chapitre 6

L’entrée dans le processus et les problématiques associées :

études de cas chez LASCOM

Chaque projet est unique, en fonction du secteur d’activités, du métier, des

intervenants, des « prédispositions » des acteurs et de l’entreprise, du contexte, des ambitions,

des contraintes, des intervenants… L’éditeur n’est pas non plus maître du moment de son

entrée dans le processus, des éléments construits lors d’étapes réalisées sans lui. Il est encore

moins maître des délais imposés par le client : il doit s’adapter. Malgré tout, pour « cerner »

les difficultés qui l’attendent, l’éditeur classe généralement les projets en fonction de leur état

d’avancement initial, des éléments mis à la disposition de l’éditeur et des attentes des clients.

En d’autres termes : « Au niveau de quelle étape du processus d’implémentation et sur la base

de quelles informations se fait le démarrage du projet pour l’éditeur » ? Comme le contexte et

la maturité du projet ont une influence importante sur le travail à faire par l’éditeur afin de

livrer une application adaptée, les réponses apportées à cette question sont centrales. Au

regard du processus initial vu par l’éditeur, trois entrées dans ce processus sont possibles avec

des « degrés d’information » différents : soit il répond à un appel d’offres, soit il répond à une

demande d’amélioration/évolution, soit il est dans période de prospection.

Nous allons décrire dans ce chapitre différents cas d’études représentatifs de la

diversité des projets de LASCOM et nous montrerons l’intérêt de nos propositions pour

aborder ces projets. Nous verrons le cas d’une entrée dès l’avant projet (réponse à un appel

d’offres), puis des interventions « classiques » pour LASCOM - c'est-à-dire suite à la

constitution d’un cahier des charges, pour finir par un projet de reprise qui fait suite à

l’exploitation d’une solution déjà en place.

1 Cas d’une réponse à un appel d’offres : la map pour initialiser et

aider à la communication

Le cas le plus fréquent d’entrée de l’éditeur dans le processus de déploiement d’une

solution logicielle correspond à la réponse à un appel d’offres. C'est-à-dire que le client a

défini ses besoins, réalisé une étude de marché et émis un cahier des charges indépendamment

de l’éditeur. Ce travail peut être fait en interne directement par l’entreprise ou par le biais d’un

consultant. Les premiers interlocuteurs « LASCOM » pour l’entreprise seront alors le


Page 164

commercial et l’avant vente. Ils vont constituer une réponse technique (illustration des

fonctionnalités liées au logiciel) et financière (le chiffrage de la solution envisagée), voire une

démonstration d’une solution type. Puis ils négocieront le contrat sur la base essentiellement

du chiffrage. Enfin, ce n’est que si l’éditeur est retenu que le projet démarre en suivant les

étapes décrites au chapitre 3 (Figure 10) pour parvenir à réaliser une application dédiée aux

besoins du client. Nous proposons dans cette section de nous focaliser sur le cas d’un client

qui arriverait avec un cahier des charges établi. Ceci correspond à une entrée de LASCOM

dans le processus au niveau de l’étape « Réponses » de la Figure 10. Il est important de

s’intéresser à cette phase et aux suivantes car se sont-elles qui conditionneront en grande

partie le déroulement du projet et la qualité de la solution et de la relation avec le client.

1.1 Réponse à un appel d’offres par l’avant vente

1.1.1 Problématique liée à l’avant vente

Pour l’éditeur, à l’entrée du processus se trouve le cahier des charges. Nous pouvons

distinguer deux types de cahier des charges : soit il définit très clairement les besoins du client

– essentiels et secondaires, voire la solution escomptée, soit il est très flou. La qualité du

cahier des charges reflète généralement la maturité du besoin et du projet. Dans le premier cas

grâce à la description précise, l’éditeur, et plus précisément l’avant vente, possède une

meilleure vision de la solution escomptée, des verrous qui devront être levés ou qui pourront

être induits par l’utilisation de son logiciel et de leurs importances dans la solution. Malgré

tout l’expérience de LASCOM montre qu’un « bon » cahier des charges n’est pas une

condition suffisante pour garantir une marge de risque minimale et un chiffrage optimum. En

effet, lors du déroulement du projet, comme dans les cas d’un cahier des charges floues, des

modifications et/ou la découverte de nouveaux besoins non explicités sont quasiment

systématiques. Les sources d’apparition sont nombreuses : la maturité du projet, la qualité et

la profondeur de l’analyse des besoins, les capacités liées au logiciel, etc. Dans certains cas la

divergence peut être considérable. Toutefois pour « vendre » un projet, il est nécessaire de

s’engager et d’éditer un devis, incluant une part de risque plus ou moins importante en

fonction du niveau d’informations obtenu. Pour illustrer certains aspects de ce devis un

certain nombre de brochures commerciales est également fourni. Aujourd’hui, le chiffrage (le

devis) représente une solution envisagée mais non définie clairement à cette étape, une

réponse technique (la brochure) relatant essentiellement les fonctionnalités à mettre en œuvre

et non la définition de l’application, et une proposition de déroulement type du projet (non


Page 165

explicitée et justifiée). De surcroit, le chiffrage émis par l’avant vente est ensuite négocié

entre le commercial et les achats, des coupes « franches » sont généralement réalisées dues à

des considérations essentiellement financières et non méthodologiques ou fonctionnelles.

Généralement les temps impartis aux aspects « méthodologie projet » (essentiellement

l’analyse) sont revus à la baisse, voire supprimés au regard de leur durée et de leur prix. Ces

durées et ces coûts sont le fruit d’un manque de méthode rapide et efficace chez les éditeurs

pour réaliser certaines étapes et notamment les étapes d’analyse. Finalement, le chiffrage

représentant la première et unique base tangible d’échange entre le client et l’éditeur, il

constitue souvent l’élément clé en vue de l’obtention d’un projet mais il n’est pas représentatif

de l’organisation du projet, de son déroulement et de la définition de la solution. Conclusion

le chiffrage n’est pas exploitable durant le déroulement du projet et la seule base de référence

sera et restera le cahier des charges émis initialement. Sur la base de cette seule « référence

exploitable » et lors de réunions avec le client, le chef de projet devra alors, dans les temps

impartis, définir le plus précisément possible les besoins contextualisés du client afin de

réaliser les supports nécessaires à la suite du projet et à la définition de l’application. Lors de

cette phase, les capacités du logiciel, la maturité du projet, de nouveaux éléments et/ou de

nouvelles contraintes vont s’affiner ou apparaitre comme nécessaires et dus. Et, pour ne pas

provoquer de dérive trop importante au regard des éléments vendus, le chef de projet devra

tenter d’expliquer la non prise en compte de certains points, constituant généralement une

première source de conflit tant entre les parties, qu’au sein de l’éditeur (mauvais chiffrage,

mauvaise vente, etc.). Cet état de fait est obtenu car sans éléments tangibles et sans écrits

clairs des éléments vendus suite à la négociation lors de l’étape précédente, il est souvent

impossible de refuser l’ensemble des demandes. L’éditeur se trouve tenu de réaliser la

prestation telle que demandée par le client et non telle que vendue. L’application doit souvent

répondre à plus d’exigences et ce pour le même coût et idéalement dans les mêmes délais. Ce

dernier point étant quasiment intenable au vue des itérations nécessaires pour appréhender les

nouveaux besoins mais également pour les réaliser, il génère généralement une seconde cause

de conflit.

Ainsi, aujourd’hui par manque de temps et d’outils, aucun élément pratique ne permet

de définir les termes du contrat tant au niveau de la solution logicielle définie au regard du

prix accordé, qu’au niveau de l’organisation et du déroulement du projet. Le principal verrou

réside ainsi non pas uniquement sur la qualité et la finesse du chiffrage mais surtout sur le

manque d’éléments factuels et à jour suite à la négociation, éléments qui viendraient expliquer

et illustrer chacun des points que ce soit technique, fonctionnel ou organisationnel, auquel


Page 166

raccrocher le chiffrage. L’objectif de notre proposition est d’instaurer un support unique (la

carte heuristique), détaillé et qui suit le cycle de vie du projet, et même du logiciel,

accompagné de méthodes simples d’analyse (exploration de la carte et persona). Le support

unique permettrait d’une part que le client soit conscient de l’impact de ses décisions sur la

solution lors de la négociation et d’autre part qu’il constitue une référence de comparaison

lors du déroulement du projet en cas de conflit. Tandis que les méthodes aideraient à

l’obtention de résultats suffisamment précis pour réaliser l’application client sans pour autant

être chronophages.

1.1.2 L’importance de la map en avant vente

1.1.2.1 Situation sans notre proposition

Pour illustrer cette problématique, prenons l’exemple d’une exigence relevée dans un

appel d’offres d’un marché public pour un département d’état et plus précisément dans le

Cahier Techniques des Clauses Particulières (CCTP représentant le cahier des charges) dans

le but de trouver un logiciel pour la gestion de ses plans et de leur cycle de vie. Le besoin

résidait dans l’utilisation d’outil métier, en particulier CAO, en lien direct avec le logiciel de

gestion recherché. Les obligations liées à cette contrainte pour l’éditeur étaient énoncées sous

deux aspects. D’une part en termes de gestion des documents, en imposant que le cartouche

des plans soit renseigné en fonction des métadonnées saisies dans l’application et que les

références existantes entre fichiers soient conservées. D’autre part en termes d’accessibilité

des plans au travers de l’outil CAO (Figure 39).

LASCOM propose différents outils tiers ou connecteurs, essentiellement CAO et

bureautique, pour utiliser son application LASCOM PLM au travers d’outils métiers pour

faciliter le travail quotidien des utilisateurs. Longtemps partenaire privilégié d’Autodesk,

LASCOM vend en particulier un connecteur adapté aux fonctionnalités du logiciel AutoCAD,

et plus ponctuellement des connecteurs pour d’autres plateformes CAO dont MicroStation de

Bentley. La réponse à ces exigences fut naturellement de proposer l’acquisition de ces deux

connecteurs, en sachant que son connecteur MicroStation serait disponible « prochainement »,

après mise à jour, afin qu’il fonctionne avec la version de l’application (Figure 38).

Figure 38. Réponse financière de LASCOM


Page 167

Figure 39. Extraits du Cahier Technique des Clauses Particulières (CCTP)


Page 168

La réponse technique explicitait rapidement les fonctionnalités principales disponibles

présentent dans ce type d’outil mais sans donner une liste exhaustive des fonctionnalités

prises en charge (Figure 40 et Figure 41). En effet, la réponse technique a pour objectif

d’illustrer les principales fonctions proposées au client pour répondre à ses besoins. Elle n’a

pas pour but de définir une à une chacune d’elle ni d’un point de vue fonctionnel, ni d’un

point de vue paramétrage. Elle doit répondre à des exigences commerciales et non techniques.

Figure 40. Extrait de la réponse technique LASCOM (1/2)


Page 169

Figure 41. Extraits de la réponse technique LASCOM (2/2)

Lors de la soutenance de l’offre et la négociation, la seule préoccupation était de savoir si

LASCOM possédait une solution pour intégrer son produit à l’outil métier le plus répandu

dans l’entreprise MicroStation et le débat se situait plutôt au niveau du prix eu égard à la

quantité de connecteurs nécessaires (un outil par poste de dessinateur).


Page 170

Une fois le projet obtenu et lancé, LASCOM a mis à jour son connecteur MicroStation pour

être en cohérence avec celui dédié à AutoCAD et à la version applicative mise en place chez

le client. D’un point de vue de l’éditeur, ce sont bien leurs deux connecteurs, adaptés au

contexte technique du client, qui étaient vendus. Autrement dit, aucun travail, d’un point de

vue fonctionnel, fut réalisé, ni même prévu, car rien ne laissait soupçonner de nouveaux

besoins. Or lors des tests de ce connecteur, le client a jugé le produit non conforme

fonctionnellement car toutes les fonctionnalités de l’outil de CAO n’étaient pas prises en

compte à travers cet outil tiers. Effectivement au regard des éléments présents dans la

réponse, le client était en droit de supposer et d’attendre que toutes les fonctionnalités natives

des outils CAO soient prises en compte. Finalement, de nombreuses itérations et compromis

ont du être réalisés pour aboutir à une liste exhaustive des fonctionnalités à prendre en compte

et pour déterminer leur mode d’utilisation. Finalement des mois ont été nécessaires pour

satisfaire les besoins principaux des utilisateurs et surmontés les nombreuses difficultés

techniques liées à l’outil mais également liées au mode d’utilisation propre au client. La

divergence entre le travail vendu et le travail finalement fourni fut importante, augmentant

considérablement les risques sur le projet. Encore aujourd’hui, les problématiques liées à cet

outil restent un point épineux à traiter, voire une source de conflit, dû au manque de cadrage

du fonctionnel pris en charge au départ.

1.1.2.2 Situation avec notre proposition

Reprenons notre proposition dans ce cas précis. Lors de l’analyse du cahier des

charges (ici dans le CCTP) par l’avant vente, nous préconisons d’utiliser la carte heuristique,

initialisée ou pas par le commercial, comme support de lecture du cahier des charges. Si nous

appliquons cette méthode uniquement pour la partie présentée à la Figure 39, nous obtenons

une description organisée et structurée des besoins énoncés (Figure 42). Ce format offre la

possibilité à l’avant vente de réaliser des regroupements, des liens et des annotations, des

modifications, des restructurations facilement et rapidement tout au long de l’analyse. Une

sorte de check-list des points à éclaircir peut être constituée et pourra ensuite être étudiée soit

au près du client, soit en interne. Ce support pour servir de base à un questionnement et mais

aussi à contextualiser et argumenter les propos de l’avant vente.


Page 171

Figure 42. Carte issue de l’analyse de l’extrait du CCTP

La construction et la réorganisation des besoins faciliteront ainsi le travail d’analyse de

l’avant vente, mais apporteront également une aide substantielle à la conception de sa vision

de l’application type nécessaire. En effet, il va pouvoir dans la zone de définition de

l’application ajouter les différentes briques standards explicitées au fur et à mesure de son

analyse et copier/coller les éléments spécifiques au projet, pour construire « grossièrement »

l’application type qu’il envisage pour la chiffrer (Figure 43).


Page 172

Figure 43. Image de l’application envisagée par l’avant vente


Page 173

Ces deux esquisses, du contexte et de l’application, seront ajoutées en complément du

chiffrage pour expliciter le travail prévu et les besoins pris en compte. Finalement, grâce à ce

complément d’informations, le client ne pourra pas juger le produit non conforme à cause

d’un manque de fonctionnalité non prise en charge, car le cadre fonctionnel est spécifié dans

le support accompagnant le chiffrage. La seule solution pour lui sera de demander une

demande d’évolution nécessitant un nouveau cahier des charges et un nouveau chiffrage.

Dans ce cas une part plus ou moins importante sera à sa charge contrairement à un correctif.

1.1.2.3 Comparaison

Les verrous identifiés dans ce cas sont :

- une réponse type non illustrée qui ne fixe pas exactement le travail à faire et les points

pris en compte dans le chiffrage au regard du cahier des charges,

- un manque de méthodes pour analyser le contexte rapidement et efficacement (étape

souvent diminuée voire supprimée au moment de la négociation).

L’instauration de la carte heuristique dès la phase d’avant vente semble lever ces difficultés et

améliorer le processus de déploiement. Nous avons comparé sur la Figure 44 le niveau de

difficultés rencontrés durant certaines actions clés du processus de déploiement sans et avec la

carte heuristique et ce sur les différentes phases du processus global.

Figure 44. Impacts de la map « avant vente » au cours du processus

Phase Les points clés Niv. Raisons Niv. Raisons

Analyser les documents reçus

+

dépend de:

- la personne, de ses méthodes

- la complexité du projet et des

documents

++

un support unique pour retracer et

organiser le contenu de l'ensemble des

documents

Lister les besoins

--

risque important d'oublier ou de ne pas

voir certaines difficultés ++

un support unique pour retracer et

organiser le contenu de l'ensemble des

documents

Lister les solutions

+

dépend de:



documents

++

utilisation d'un support standard permet de :

- identifier les difficultés, les verrous

- corrélations plus simplement avec

d'autres projets

Chiffrer+

chiffrage approximatif avec une marge

de risque globale++

les spécifiques sont mieux chiffrés, grâce à

l'apport du contexte

Rédiger le document

--

construction du document à chaque

projet, mais réutilisation des briques

de description

-

ossature du document réaliser

automatiquement à partir de la carte

Définition des éléments vendus - très flou + définie le package prévu clairement

Compréhension des

conséquences des négociations-

raisonnement uniquement sur le

chiffrage très général+

possibilité de montrer les conséquences

plus facilement

Marge de risque

-

- lié au chiffrage de chaque spécifique

indépendamment

- demandes d'évolution non

maitrisable

+

- chiffrage plus précis

- demande d'évolution potentiellement un

peu plus maitrisable

Facilité de l'arbitrage---

aucune description exacte de ce qui

était prévu+

document factuel précisant le cadre de la

prestation vendue

Analyser le contexte

---

peu de visibilité et pas de temps pour

faire une analyse poussée +

vision globale du besoin et de la solution

proposée avant même de commencer le

projet

Spécifications

Sans les supports Avec les supports

Réponse

Choix de la solution


Page 174

Des résultats similaires peuvent être présentés sur l’utilisation de la carte heuristique à

chacune des étapes d’intervention de l’éditeur comme expliqué dans les chapitres précédents.

Le point commun intéressant est que l’instauration de ce support facilite et améliore non

seulement l’étape en cours mais influe également de manière positive sur toutes les étapes qui

lui succèdent. Le second avantage est que la complexité du projet comme la personne

réalisant l’étude ne représentent plus des contraintes prépondérantes.

1.2 L’analyse des besoins : le cœur du processus

1.2.1 Problématique de l’analyse des besoins

La seconde étape critique du processus est l’étape d’analyse. Par manque de temps ou

par manque de méthode, cette partie est trop souvent omise ou réduite à sa plus simple

expression : un point rapide par le client de son besoin avec une bribe de contexte. Ainsi,

aujourd’hui lors d’un début de projet, après un exposé sommaire par le client de son besoin,

charge à l’éditeur d’animer la conversation/réflexion à partir du cahier des charges afin

d’affiner son analyse amont et de déterminer des solutions techniques appropriées. L’objectif

est d’aboutir à des spécifications fonctionnelles adaptées à son application, que l’on pourrait

qualifier plutôt de technico-fonctionnelle, définissant finalement l’application future ainsi que

son contenu. Selon le chef de projet (ses compétences, ses habitudes, etc.) et l’envergure du

projet, les spécifications technico-fonctionnelles sont accompagnées par une modélisation de

l’application plus ou moins complète illustrant les points clés fonctionnels (définition des

objets, des processus, etc.) et non techniques pour ne pas compliquer la description.

Finalement l’éditeur cherche généralement à modéliser son application sans même (ou alors

partiellement) modéliser le fonctionnement du système (l’entreprise, le service, etc.) à prendre

en charge. Malgré tout l’application résultante répond globalement aux attentes des clients,

mais génère également des « retouches » ponctuelles, plus ou moins importantes et fréquentes

durant le démarrage de l’exploitation pour répondre aux problématiques des utilisateurs. Ces

itérations sont difficilement gérables, consommatrices de temps et d’énergie (non « vendus »),

et allongent la durée du projet ce qui amplifie le mécontentement du client et bloque

potentiellement la facturation (augmentant la pression chez l’éditeur). Même si les itérations

ne sont pas dues à l’éditeur mais bien souvent au client qui change « d’avis », elles mettent en

évidence toujours le même problème : l’absence d’analyse contextualisée du besoin réel par

l’éditeur au regard de son produit. Cette analyse doit compléter l’analyse théorique, souvent

globalisée et généralisée, contenue dans le cahier des charges. Les causes du « délaissement »


Page 175

de cette étape peuvent provenir soit de l’éditeur, soit du client. Le premier ne se sent pas armé

pour réaliser une analyse à proprement parlé – ce n’est pas son cœur de métier – tandis que le

second n’en voit pas l’intérêt, ne cherche pas à évaluer son fonctionnement actuel et souhaite

« juste » concevoir son fonctionnement futur. Cette situation est accentuée dans deux

contextes en particulier : soit l’intervention d’un consultant en amont, qui a déjà réalisé une

étude poussée, soit un client qui souhaite une « petite application clé en main » pour un « petit

projet tout simple ». Dans les deux cas, il est impossible d’inclure l’analyse des besoins dans

le coût de la solution. Le premier rétorquera qu’il a déjà payé cette prestation au près d’un

consultant, le second qu’il a déjà fait l’analyse et qu’il a besoin du logiciel paramétré pour «

demain ». En l’absence de méthodologie adaptée, cette étape est généralement perçue, et

souvent à juste titre, comme trop coûteuse au regard du résultat, son influence sur la qualité

du logiciel n’est pas toujours facile à mettre en valeur et l’ensemble des résultats n’est pas

forcément exploitable. Dans les deux cas, les clients prétendent que toutes les informations

nécessaires sont présentes dans leur cahier des charges. Sauf que ces documents répondent à

une description soit totalement générique, et donc très floue, soit très figée et peut être pas

adaptée au logiciel choisi en définitif ou pas complètement appropriée. Si ces problèmes ne

sont pas mis en exergue lors de l’avant vente, le problème devient rapidement insoluble

particulièrement lors de la phase des spécifications, moment où l’on doit décrire la solution

technique choisie pour chacun des points fonctionnels à prendre en compte. Si la description

était floue, le client souhaitera en général ajouter des éléments ou les modifier en jouant sur

des prétendus sous-entendus « métiers », alors que le chef de projet tentera de ne pas trop

s’éloigner du chiffrage réalisé. De même si la description était figée, le client reste arcbouté

sur une solution « fantasmée », imaginée sur la base de ses connaissances ou sous l’influence

d’un consultant, même si le chef de projet, de par son expérience, entrevoit une solution plus

pertinente ou des impossibilités techniques ou fonctionnelles d’utilisabilité. Dans ce cas

l’éditeur a du mal de jouer son rôle de conseil surtout sans avoir le contexte réel du besoin.

Finalement aujourd’hui, l’analyse n’est presque jamais vendue comme une prestation en tant

que telle. Elle se résume bien souvent à des petites explications durant les spécifications au

cas par cas lorsque des difficultés à comprendre le cahier des charges ou à déterminer une

solution technique apparaissent.

En conclusion il est essentiel d’illustrer le chiffrage avec la définition d’une pré-

solution applicative afin de rendre compréhensible la proposition faite par l’éditeur mais aussi

de faire une analyse ou du moins une « contre expertise » pour valider l’ensemble des besoins


Page 176

à prendre en compte avant même de débuter les spécifications pour valider le cadre

fonctionnel et vérifier la réalisabilité. Pour éviter ces écueils tout en optimisant le temps

nécessaire, le principe est d’utiliser systématiquement une méthode simple, rapide et

modulable pour s’adapter au projet comme au client, dont la finalité constituera une base de

référence de ce qui est pris en compte et à déterminer pour mener à bien le projet, mais

également une base de communication commune.

1.2.2 L’importance de l’exploration et des persona pour définir les besoins réels

1.2.2.1 Situation sans notre proposition

Pour illustrer le phénomène décrit dans la section précédente nous prendrons

l’exemple d’un grand groupe de construction qui souhaite une nouvelle application pour

suivre et vérifier la conformité de certains travaux au regard des contraintes réglementaires,

de sécurité et liées aux projets. Sa première expression de besoin se concentrait

essentiellement sur l’issue du processus de gestion informatique des conformités, la partie

données de sortie (Figure 45), c'est-à-dire la conception des deux types de documents

factuelles à délivrer pour prouver le respect des contraintes imposés soit sur l’ensemble du

projet, soit pour une contrainte donnée et le reporting de suivi.

Figure 45. La définition du fonctionnement issue du cahier des charges


Page 177

Grâce au travail concluant réalisé depuis plusieurs années avec ce client, LASCOM a donc été

contacté directement par celui-ci, afin d’évaluer sa capacité à répondre à ce nouveau besoin.

Au regard des éléments en sa possession, l’avant vente proposa un module standard

paramétrable semblant répondre au besoin avec la possibilité de l’intégrer dans des

applications existantes. La démonstration convainquit le client et la vente du module avec

l’ajout de quelques spécificités fut conclue (Figure 46).

Figure 46. Exemple de chiffrage pour une nouvelle application

Pour paramétrer ce module, il était convenu de réaliser très peu de réunions de spécifications

car le niveau de spécificité à apporter n’était pas important et cela permettait de diminuer le

coût. Le but de ces réunions était de valider le vocabulaire, définir les droits, définir les

visuels, etc. Entre la signature du contrat et le démarrage du projet, le client a demandé que

l’étude soit menée pour accélérer les spécifications et tenter de débuter cette partie du projet

avec un maximum d’informations concernant le paramétrage nécessaire. Ainsi dès la première

réunion, ce dernier présenta ses résultats sur le fonctionnement (Figure 47) et la définition des

éléments nécessaires, avec pour objectif d’obtenir la validation de LASCOM plutôt que de

revalider le fonctionnement avec les autres personnes présentes.


Page 178

Figure 47. Définition du fonctionnement suite à la consultation interne

Le client, grâce à sa bonne connaissance du produit LASCOM, a présenté une spécification

initiale qui contenait en très grande partie les éléments, ou les emplacements, nécessaires au

paramétrage de l’application et ce dans les termes « lascomien ». Mais au regard des

différentes conversations avec les personnes présentes lors des réunions, il s’avéra que le

fonctionnement établi ne correspondait pas pleinement aux attentes et que d’autres part il ne

pouvait pas convenir du point de vue fonctionnel pour l’éditeur. Le nombre de réunions

nécessaires avant d’aboutir à la validation des spécifications fonctionnelles fut finalement

plus important qu’escompté et des compromis pour améliorer le fonctionnement furent

obligatoires car la remise en question n’était pas possible dans les temps impartis (Figure 48).


Page 179

Figure 48. Exemple de modification effectuée

Finalement de nombreuses anomalies bloquantes sont ressorties sur le fonctionnement même

de la gestion des contraintes lors des tests de validation de l’application. Autrement dit,

l’application ne peut pas être déployée en l’état, des corrections sont nécessaires, puis une

nouvelle campagne de test doit être opérée pour valider ce point mais également vérifier les

non-régressions. Pendant ce temps, la facturation de tout ou partie du projet n’est pas possible

puisque l’ensemble du processus n’ayant pas été préalablement clairement établi. Ainsi des

« sous entendus » métiers ou des habitudes d’utilisation de l’application en place n’avaient

pas été implémentés. De plus, ces troubles ont ouvert la porte aux remises en question

d’éléments validés durant les spécifications et aux demandes de modifications itératives. Le

projet prenant de plus en plus de retard et la nécessité absolue d’utiliser rapidement cette

partie de l’application étant devenue de plus en plus forte, d’importants retours en arrière ont

du être réalisé, en désactivant certaines parties, afin d’éviter de bloquer l’avancement de la

gestion des conformités (Figure 49). Ces parties devront être réactivées par la suite.


Page 180

Figure 49. Exemple de désactivation

En conclusion, tellement obnubiler par la conception des documents sortants, le client, chargé

de la tâche d’analyse, en a oublié de définir clairement le déroulement du processus. Le projet

a alors pris du retard imputable aux nombreuses itérations induites par des manques, puis des

doutes liés au fonctionnement même du processus de gestions des contraintes dans son

ensemble. Ces points particuliers auraient dû être éclaircis dès l’analyse. Finalement le client

est mécontent d’avoir eu à attendre aussi longtemps ce module, d’être obligé de limiter ces

fonctionnalités pour un temps, et il reporte la faute majoritairement sur l’éditeur. Cet exemple

illustre le rôle crucial de l’analyse des besoins et des difficultés/iniquités de laisser le client

réaliser cette étape seul impactant l’ensemble de la gestion de projet.

1.2.2.2 Situation avec notre proposition

Reprenons cet exemple en utilisant notre proposition. L’utilisation de la carte

heuristique pour cette étape offre potentiellement la capacité de proposer une prestation

abordable grâce à une réduction de sa durée et de son coût. Deux solutions s’offrent à nous,

soit il est impossible de conserver l’étape d’analyse des besoins, soit l’éditeur doit réaliser

cette étape. Dans un premier temps, nous allons considérer la seconde hypothèse.

Idéalement, l’étape d’avant vente a permis de récolter de nombreuses informations formelles

et informelles constituant ainsi un premier niveau de l’analyse mise en forme sous le format

de la carte heuristique présentée précédemment. Ce support est alors transmis au chef de

projet dès le lancement de projet, il représente la vision commune et partagée entre les

différents intervenants de l’éditeur. A partir de cette carte, le chef de projet déterminera les


Page 181

grands axes d’exploration à ne pas oublier, les hiérarchisera, etc., pour élaborer ainsi la base

de l’animation de sa réunion. Selon le nombre de participants lors de la première réunion, soit

le brainstorming est lancé sans expliquer l’objectif et c’est le chef de projet qui orientera

l’exploration – possible uniquement s’il y a peu de personnes à canaliser-, soit une carte

explicative de l’objectif (Figure 50) sera présentée expliquant le mode de fonctionnement, les

préconisations d’exploration, etc. avant le lancement de l’exploration. Selon les éléments

vendus mais également au regard de la complexité de l’organisation, suite à l’initiation, le

client pourra effectuer l’étude sans l’aide de l’éditeur, qui interviendra qu’à la restitution de

l’étude complète par le client afin de partager le même niveau de connaissance du système à

prendre définitivement en compte durant l’informatisation.

Figure 50. Support à l’initiation à la map contexte

A l’issue de des réunions, une exploration complète du processus est établie, mettant en

exergue les points délicats à confirmer par les fonctionnels afin d’obtenir le contexte définitif

comme présenté dans la Figure 17. Cette étude aurait permis de comprendre les différents

besoins, les mécanismes à prendre en compte dans l’application, les différents critères à

respecter évitant ainsi les « mauvaises » surprises pendant les tests. Par exemple, au vue des

actions à réaliser pour l’activité « recensement des documents sources », il serait apparu que

la solution d’utiliser l’objet « Document » existant était inappropriée, de même pour la

déclinaison des contraintes, le lien ne pouvait pas être réalisé entre « contraintes », mais bien

entre une « réponse » et une ou plusieurs « contraintes » (Figure 51).

Figure 51. Extrait du contexte issu de l’analyse


Page 182

Pour accélérer cette étude, nous aurions pu également proposer d’utiliser, en complément, les

personas soit en amont soit en parallèle, afin de pré-initialiser et/ou valider la conception de la

carte comme décrit dans le chapitre 5.

Finalement, la capacité de l’éditeur à proposer une méthode simple d’analyse des besoins en

se basant sur l’exploration de l’organisation existante permet d’améliorer la compréhension

mutuelle des éléments à prendre en compte dans l’informatisation, d’uniformiser la

sémantique et de mieux appréhender la conception de l’application. Grâce à cette expertise,

les chances d’obtenir un logiciel approprié aux fonctionnements de l’entreprise s’en trouvent

augmentées tout en améliorant le niveau et la qualité de la communication avec le client.

Toutefois si le client n’adhère pas à l’offre proposée par l’éditeur, il est tout à fait possible de

le laisser opérer à sa manière. Pour éviter les mésaventures il est primordial que le chef de

projet débute les réunions de spécifications par la création de cette partie de la carte non pas

en questionnant les interlocuteurs mais à partir de l’étude réalisée par le client. La carte

résultante doit permettre d’aboutir à un équivalent de la carte issue du brainstorming, en

ordonnant et classifiant les besoins et les différents éléments à prendre en compte. La

validation par le client est malgré tout nécessaire pour établir un point de repère commun

simplifié au même titre que le cahier des charges.

1.2.2.3 Comparaison

De par sa situation temporelle dans le processus, l’analyse des besoins permet de faire

le lien entre l’étape d’avant vente et le début des spécifications. Elle doit déboucher sur

l’énoncé clair de l’ensemble du problème afin d’organiser la suite du processus et limiter les

risques de divergence. Pour que l’éditeur puisse concrétiser cette étape d’analyse des besoins,

l’utilisation d’un support simple accompagné d’une méthode efficace est primordiale. Ce

support apportera une meilleure visibilité du travail à faire mais sera également un vecteur de

communication important. Ce support sera une base commune de connaissances du projet

pour les personnes participantes à l’implémentation d’un nouveau logiciel, mais il offrira

aussi la possibilité d’élargir le cercle des participants à des utilisateurs avertis par exemple.

De plus, cette étude est une phase critique dont la qualité se répercutera sur la suite du

processus et impactera directement la qualité de l’ensemble des étapes suivantes (Figure 52).


Page 183

Figure 52. Impacts de l’utilisation de la map pour l’analyse des besoins

1.3 Synthèse

Chaque projet est unique de par son contenu mais également sur sa forme et son

organisation, et plus particulièrement sur le niveau d’informations disponibles pour son

déroulement. L’uniformisation doit être opérée par l’éditeur car il ne maitrise ni la quantité et

ni la qualité des données entrantes nécessaires au processus. Il est important d’analyser

l’ensemble des informations fournies pour pouvoir identifier les manques qui risquent de

pénaliser l’ensemble du projet. D’un point de vue de l’éditeur, les deux premières étapes du

processus, la réponse et l’analyse des besoins, sont donc critiques et à « ne pas manquer », car

elles sont porteuses et propices à la collecte d’un grand nombre d’informations cruciales pour

Phase Les points clés Niv. Raisons Niv. Raisons


---

peu de visibilité et pas de temps

pour faire une analyse poussée

++

- compréhension du projet dans

son contexte

- déterminer le contour

fonctionnel

- constituer une base de

référence commune

Spécifications fonctionnelles

--

- longue pour appréhender point

par point les besoins

génériques énoncés dans le

cahier des charges

- fort risque d'évolution au vue

des capacités de l'application

++

- meilleure compréhension des

besoins individuellement mais

également dans son ensemble

- constitution d'une sémantique

commune déjà réalisée

Choix des solutions techniques

-

réalisé point par point, car

difficultés d'obtenir une vision

globale à ce moment là du

processus

++

solution plus performante

individuellement et plus

cohérente dans leur ensemble

Spécifications techniques

-

réalisé point par point et avec

peu de contexte +




Compréhension du besoin

fonctionnel -

explication fonctionnel

sommaire, avec très peu de

contexte

++

support commun résumant le

contexte et la situation du

développement à faire

Cohérence avec l'ensemble de

l'application cliente-

vision globale difficile à

appréhender++

vision globale du besoin et de la

future application

Compréhension des scénarios--

Pas de scénario, mais une

succession de tests unitaires++

Capacité de créer des

scénarios de tests par profils

Organisation des tests

-

Difficile à prioriser

+

Capacité de hiérarchiser

l'importance des fonctionnalités

globalement et par profil

Compréhension des questions

+

difficulté de comprendre les

questions du client en l'absence

de connaissance de

l'application et surtout de la

sémantique client

++

- support global présentant les

aspects fonctionnels pris en

charge

- une vision sommaire de

l'application

Tests

Support

Développements

Spécifications

Modélisations(s)

Sans les supports Avec la carte heuristique


Page 184

la suite du projet, sans risque de le pénaliser. La mise en place d’une méthode et d’un support

commun pour ces deux étapes maitresses du processus sont essentielles car elles

conditionnent le bon déroulement de la suite du déploiement. Nous venons de démontrer

l’intérêt de l’utilisation d’une carte heuristique pour aider à traiter toutes les informations

exploitables sous un format unique, rapide à mettre en œuvre et facilitant les échanges avec le

client. De la même façon, la suite du processus présente également ses manques et ses

faiblesses qui peuvent être minimisés par l’utilisation du même de support et ce pour

l’ensemble du projet (Figure 53).

Finalement l’instauration d’une même méthode et des outils associés tout au long du

processus, quelque soit l’intervenant, facilite globalement le déroulement du projet et la

qualité du résultat. Le niveau de communication est également augmenté grâce à la

transparence tant sur le déroulement du projet, que sur les choix pour l’application, améliorant

la confiance du client en l’éditeur. De plus, l’utilisation généralisée et l’intérêt observé pour

chacune des étapes et chacun des intervenants pour obtenir le niveau d’information suffisant

peuvent contribuer activement à la pérennité de cette solution.


Page 185

Figure 53. Améliorations du processus de déploiement

Phase Les points clés Niv. Raisons Niv. Raisons Niv. Raisons

Vérifier la concordance

entre le projet et ses

Comparer des projets

Analyser les documents

reçus

+

dépend de:



documents

++

un support unique pour retracer

et organiser le contenu de

l'ensemble des documents

Lister les besoins

--

risque important d'oublier ou de

ne pas voir certaines difficultés ++

un support unique pour retracer

et organiser le contenu de

l'ensemble des documents

+++

Ajout d'une description illustrée

des besoins clés par le biais

des personas mis à jour

Lister les solutions

+

dépend de:



documents++

utilisation d'un support standard

permet de :

- identifier les difficultés, les

verrous

- corrélations plus simplement

avec d'autres projets

+++

verrifier la cohérence entre la

solution et l'usage

Chiffrer

+

chiffrage approximatif avec une

marge de risque globale ++

les spécifiques sont mieux

chiffrés, grâce à l'apport du

contexte

+++

cohérence accrue

Rédiger le document

--

construction du document à

chaque projet, mais réutilisation

des briques de description-

ossature du document réaliser

automatiquement à partir de la

carte

Définition des éléments

vendus-

très flou+

définie le package prévu

clairement

Compréhension des

conséquences des

négociations

-

raisonnement uniquement sur

le chiffrage très général +

possibilité de montrer les

conséquences plus facilement

Marge de risque

-

- lié au chiffrage de chaque

spécifique indépendamment

- demandes d'évolution non

maitrisables

+

- chiffrage plus précis

- demandes d'évolutions

potentiellement un peu plus

maitrisables

Facilité de l'arbitrage---

aucune description exacte de

ce qui était prévu+

document factuel précisant le

cadre de la prestation vendue


---

peu de visibilité et pas de temps

pour faire une analyse poussée

++

- vision globale du besoin et de

la solution proposée avant

même de commencer le projet

- compréhension du projet dans

son contexte

- déterminer le contour

fonctionnel

- constituer une base de

référence commune

+++

- apporter soit une base

d'exploration, soit une validation

de l'exploration

- apporter la vision locale et la

sémantique usuelle

Spécifications

fonctionnelles

--

- longue pour appréhender point

par point les besoins

génériques énoncés dans le

cahier des charges

- fort risque d'évolution au vue

des capacités de l'application

++

- meilleure compréhension des

besoins individuellement mais

également dans son ensemble

- constitution d'une sémantique

commune déjà réalisée

+++

vision des besoins réels dans

leur contexte, permet d'entrevoir

des solutions plus adaptées

Choix des solutions

techniques-

réalisé point par point, car

difficultés d'obtenir une vision

globale à ce moment là du

processus

++




Spécifications techniques

-

réalisé point par point et avec

peu de contexte +




Compréhension du besoin

fonctionnel -

explication fonctionnel

sommaire, avec très peu de

contexte

++

support commun résumant le

contexte et la situation du

développement à faire

+++

vision théâtraliser de la situation

à prendre en compte favorisant

l'empathie

Cohérence avec

l'ensemble de l'application -

vision globale difficile à

appréhender++

vision globale du besoin et de la

future application

Compréhension des

scénarios--

Pas de scénario, mais une

succession de tests unitaires++

Capacité de créer des

scénarios de tests par profils+++

Utilisation des personas

comme scénarii

Organisation des tests

-

Difficile à prioriser

+

Capacité de hiérarchiser

l'importance des fonctionnalités

globalement et par profil

Expression du besoin

Sans les supports Avec la carte heuristique Avec la carte heuristique + persona

Prospection

Etude de marché

Cahier des charges

Réponses

Choix de la solution

Spécifications

Modélisations(s)

Développements

Tests


Page 186

2 Cas d’une reprise d’exploitation : importance des supports

Rétrospectivement, le cycle de vie d’une application chez un client peut être très long.

Durant ce laps de temps, des problèmes liés à l’utilisation sont rencontrés, les besoins

changent ou évoluent, et la version du logiciel peut ne plus être supportée par l’éditeur. Tous

ces événements entrainent des interventions plus ou moins fréquentes sur l’application du

client. Elles peuvent être catégorisées en trois types : correctives, « amélioratives » ou

préventives. Aujourd’hui selon le type d’intervention et sa teneur, le processus mis en œuvre

diffère tant sur le mode opératoire (les étapes réalisées, les intervenants) que sur le suivi. Ces

interventions constituent réellement une nouvelle entrée et rarement une suite du processus

car le laps de temps écoulé entre deux interventions peut être long, les types d’interventions

peuvent être différents et les intervenants peuvent eux aussi être différents. Cependant dans

les trois cas, que la teneur des modifications à apporter soit mineure ou majeure, chacune

d’elles nécessite de connaitre l’environnement dans lequel elle s’inscrit afin de ne pas

déstabiliser l’application et s’assurer de répondre correctement au besoin. Autrement dit, cette

seconde entrée se différencie de la première par la nécessite supplémentaire d’appréhender

l’application existante en place chez le client pour adapter l’intervention et déterminer une

solution compatible. La qualité de la prestation repose donc sur la capacité à reconstituer la

vue globale de l’application actuelle à partir de son historique.

2.1 Problématique de la constitution d’une vue globale de l’application

Aujourd’hui, selon le type d’intervention, le processus de prise en compte et les règles

de gestions diffèrent de ceux mis en œuvre pour un projet dont l’origine tient essentiellement

au coût de ces prestations. En effet, les actions correctives sont traitées par le support et sont

réalisées dans le cadre de la maintenance de l’application, c'est-à-dire que quelque soit le

nombre de demandes et leur difficulté, le coût annuel est fixe. La rentabilité repose alors sur

la rapidité des corrections. Tandis que les améliorations et les actions préventives reposent

généralement sur des commandes spécifiques ou complémentaires à la maintenance, c'est-à-

dire avec un budget donné et elles seront gérées par un chef de projet. Par contre à la

différence d’un nouveau projet, dans ces deux derniers cas, toutes les étapes du processus ne

sont pas réalisées que ce soit coté client ou éditeur. Pour le client toutes les étapes de choix de

solutions n’ont pas lieu d’être, la réponse de l’éditeur doit donc consister à fournir une

réponse financière. Cette différence est accentuée par le niveau d’information fourni. En effet,

dans ces cas, le cahier des charges est généralement réduit à une expression de besoin, c'est-à-

dire une description moins fonctionnelle et plus « technique » orientée en fonction du logiciel


Page 187

(par exemple : besoin d’ajouter une étape Y dans le processus untel après l’étape X).

Autrement dit, le chiffrage demandé est une évaluation technique - il y a rarement une étude

avant vente réalisée -, ce qui implique généralement l’absence ou la minimisation du coût de

la gestion de projet lié à la réticence des clients qui considèrent cette intervention comme une

« simple » modification dont le travail d’analyse est déjà réalisé par leur soin. Finalement

dans les trois cas, aucun temps d’étude n’est prévu (vendu) ou alors il est réduit à son

minimum, alors que cette étude est plus complexe car nécessitant la prise en compte

fonctionnelle et technique du besoin dans un cadre existant.

Une autre problématique repose sur le suivi de ces interventions car la récupération des

informations issues de ces interventions, de la demande à la résolution, est complexe. Le

support utilise un outil dédié permettant de communiquer formellement avec le client (les

déclarations de problèmes, les demandes d’informations complémentaires, les solutions, etc.),

problème par problème et ce tout au long du cycle de traitement jusqu’à sa clôture. L’objectif

du support est de comprendre la nature du problème pour pouvoir le résoudre. Or en fonction

des clients, la description ne correspond pas forcément réellement au problème technique

rencontré. Pour accélérer le processus de compréhension et donc de résolution, des échanges

informelles sont également opérés soit directement entre le support et le client, soit entre

l’ancien chef de projet et le client, soit en interne. Finalement, l’utilisation d’un outil dédié

permet de centraliser toutes les actions effectuées par la hotline mais ne donne pas une vision

globale des interventions sur une application. Ceci est dû fait que d’une part toutes les

informations ne sont pas forcément tracées, et que d’autre part elles sont stockées et

identifiées en fonction du client (or un client peut avoir plusieurs applications), de l’énoncé

initial du problème (ne correspondant pas forcément au problème réel) et individuellement

(plusieurs énoncés pouvant correspondre à un seul est même problème). Tandis que dans le

cadre d’une commande, le chef de projet sera en lien direct avec le client, accentuant les

échanges informels et dans un mode « sans » projet, c'est-à-dire que toutes les étapes du

processus ne sont pas forcément suivies (analyse du besoin, spécifications, etc.). Autrement

dit, les modifications apportées ne donneront pas forcément lieu au même niveau de

formalisation qu’en mode projet et reposeront d’avantage sur l’élaboration de fiches

d’interventions listant les actions réalisées sur le serveur. Ce mode de fonctionnement

entraine généralement des dérives plus ou moins importantes liées à la proximité entre les

deux parties pour concevoir et mettre en place les évolutions et/ou les améliorations. Comme

le client s’est retrouvé seul face à son application pendant quelques temps, dès lors qu’il

retrouve un interlocuteur, il aura tendance à en profiter pour exposer d’autres difficultés sans


Page 188

lien avec le but de l’intervention. Le chef de projet se trouve dans une situation délicate et doit

gérer les deux aspects l’intervention, pour laquelle il n’est pas forcément à l’aise, et la reprise

de contact. Selon les rapports entre le client et le chef de projet, et la disponibilité du chef de

projet, le client cherchera à faire perdurer ce phénomène plus ou moins longtemps par mail ou

par téléphone. Le chef de projet s’y pliera pour éviter les litiges et accroître la satisfaction du

client. Ces « petits » dépannages, qu’ils soient réalisés durant une prestation ou pas, sont

rarement retranscrits formellement ou alors dans les fiches d’interventions mélangeant ainsi

les actions propres à l’intervention et les demandes additionnelles. Ces types d’interventions

ne suivent donc pas un processus figé. Le seul jalon est l’opérationnalité de l’application

finale, les différentes étapes ayant menées à ce résultat n’étant pas forcément formalisées.

Finalement lors d’une reprise de l’existant, le type et le niveau de documentation de

suivi ne sont pas homogènes entre les différents types d’interventions et dépendent du

contenu de la prestation, du client, du temps accordé, du chef de projet, etc. Ceci oblige,

lorsque nous reprenons un existant, qu’il faut non seulement comprendre les modifications à

faire mais également le contexte dans lequel elles vont s’intégrer que ce soit techniquement

ou fonctionnellement. Au regard du mode de fonctionnement actuel, du cloisonnement entre

les types d’intervention et de l’hétérogénéité des supports, il est très compliqué pour un

intervenant ponctuel de reconstituer l’historique d’une application. L’objectif de se construire

une vision globale de l’application actuelle pour déterminer des solutions cohérentes et

évaluer les impacts de ses actions essentiellement d’un point de vue fonctionnel est donc

difficilement tenable pour les intervenants LASCOM.

2.2 Mise en évidence de l’intérêt de la map comme support

d’intervention

2.2.1 Situations sans notre proposition

2.2.1.1 Exemple d’actions sur une application déjà implantée

A l’origine, l’application a été conçue pour répondre à un cahier des charges dont les

exigences ont été revues ou adaptées en fonction de l’outil, des précisions apportées lors de la

conception, etc. Puis au fil de son utilisation certains ajustements ont été réalisés soit dans le

cadre d’évolutions à proprement parlé (ajout de fonctionnalités, d’outils tiers, etc.),

d’améliorations, mais également des corrections (soit pour résoudre des bugs, soit pour

répondre à l’environnement du client). Toutes ces étapes ont été menées par des intervenants


Page 189

différents dont le travail fut décrit plus ou moins précisément soit à travers un cahier des

charges dans le cas d’un élargissement fonctionnel (sans base préexistante dans l’application),

soit à travers des expressions de besoins (mini cahier des charges décrivant le besoin en terme

fonctionnel et/ou technique), soit des déclarations de bugs. Les deux derniers cas sont les plus

fréquents durant le cycle de vie d’une application. Ils sont perçus comme des « petites »

adaptations et suivent des circuits internes à l’éditeur différents. Le support agira à travers une

application dans laquelle seront tracés les échanges avec le client, les échanges internes et la

solution. Dans le cas d’un élargissement, il y aura une intervention qui donnera suite,

normalement, à une fiche d’intervention relatant, plus ou moins finement, les actions

réalisées. A cela s’ajoute les questions ponctuelles du client pour effectuer soit lui-même, soit

lors d’une intervention prévue, des paramétrages ou des corrections jugées mineures.

Finalement lors des dernières phases du cycle de vie d’une application, nous assistons à une

succession d’interventions plus ou moins formelles pour lesquelles l’enchainement de toutes

les étapes du cycle de déploiement est rarement respecté. Ce non respect du processus

s’explique par un manque de temps et surtout car ces étapes n’ont pas été vendues, le client ne

voyant pas l’intérêt de payer ce genre de prestation dans le cadre d’interventions dite

mineures.

2.2.1.2 Exemple une demande de modification des caractéristiques

Un autre cas fréquent d’interventions sur une application existante concerne la

demande de modification des caractéristiques d’une propriété du modèle de données pour des

fins fonctionnelles (réaliser un lien dynamique entre deux types de documents). Nous

étudierons le cas défavorable (mais fréquent) du chef de projet qui prend en charge le dossier

sans connaitre l’application dans son ensemble et qui en fonction de la modification vendue

n’aura pas eu l’opportunité d’effectuer une étude. Dans ce cas, le chef de projet va alors

réaliser une modification rapidement sous la pression du client a priori sans problème, une

fiche d’intervention est alors éditée et stockée. Finalement, quelques temps plus tard le client

déclare au support une anomalie : un outil tiers spécifique, qu’il utilise ponctuellement, ne

fonctionne plus. Le client n’ayant pas identifié la source du problème, le support a vérifié

dans un premier temps les demandes d’intervention effectuées récemment. Rien ne laissant

présager une modification de l’outil en lui même, il a dû déterminer quel était cet outil propre

au client (est-ce un outil « classique » dont le nom a été modifié pour le client ? Que fait cet

outil ? Comment fonctionne-t-il ?) et trouver un environnement de test pour reproduire le

problème et analyser le dysfonctionnement. Une fois un problème reproduit, il est souvent


Page 190

plus facile d’en déterminer la cause. Grâce à son expertise, le support a réussi à établir le lien

entre une fiche d’intervention et l’outil en question, et ainsi trouver la source de l’anomalie.

Le client utilisait une donnée dont les caractéristiques avaient changées, rendant l’outil tiers

incompatible. Il est a noté que si la modification n’avait pas été tracé, mais réalisée « pour

rendre service » dans le cadre d’une autre prestation, le lien entre les deux interventions et

donc l’identification de la cause de l’anomalie aurait pris plus de temps et suscitée des

itérations supplémentaires pour justifier et valider la modification du modèle de données.

Finalement, une modification jugée anodine au départ a impliqué deux interventions par deux

équipes différentes. Au cours de la première intervention, le chef de projet n’ayant pas menée

d’étude et ne possédant pas une vision globale de l’application, il n’a pas détecté les impacts

potentiels de sa modification. Tandis que la seconde intervention a conduit le support à

réétudier l’outil en question et rechercher l’historique des modifications pour déterminer la

cause du problème et rééditer un nouvel outil adapté compatible avec les modifications. En

conclusion, que la modification soit « anodine » ou pas, fonctionnelle ou technique, si

l’intervenant n’a pas une vision globale de la solution propre au client, les risques de

déstabilisation sont importants.

2.2.1.3 Exemple d’une migration d’application

Le dernier exemple va concerner la migration d’une application déjà en place.

L’objectif d’une migration d’une application est de fournir au client une application

équivalente à celle qu’il possède mais avec une version supérieure du logiciel. Cette nouvelle

version intègre de nouvelles fonctionnalités, des améliorations, des évolutions devenues des

standards, etc. L’enjeu majeur ne réside pas dans l’installation d’une nouvelle version du

logiciel mais dans la récupération des éléments spécifiques au client. Ce point englobe les

développements réalisés pour lui et qu’il est nécessaire de modifier pour les intégrer à la

nouvelle version, mais également l’ensemble du paramétrage propre à l’application (modèle

de données, paramétrages de l’application) et connexe à celle-ci (paramétrages structurels)

essentiel pour le bon fonctionnement de l’application dans l’environnement informatique du

client. Le jour du lancement de la migration, le nouveau chef de projet doit idéalement

appréhender l’application dans son intégralité ainsi que les besoins fonctionnels auxquels doit

répondre le futur logiciel pour évaluer le travail à réaliser au regard des fonctionnalités

disponibles dans la nouvelle version. Nous utilisons volontairement le terme « nouveau chef

de projet » car c’est rarement la même personne qui suit l’application tout au long de son

cycle de vie (turnover des ressources humaines, ancien chef occupé à la gestion d’un autre


Page 191

projet, etc.). L’objectif est de déterminer pour chacun des points si la source du

développement est l’application cliente ou la nouvelle version pour aboutir à une solution

fonctionnellement équivalente mais à jour techniquement. Une fois encore cette étape

décisive de reconstitution de l’historique de l’application est critique et essentielle pour

aboutir à la « recréation » de l’application améliorée. En effet, le niveau d’information

nécessaire sur les modifications apportées ne se résume ni à un aspect uniquement technique

(les développements sont stockés en interne et facile à identifier), ni à un aspect paramétrage

(plus compliqué à obtenir), ni enfin à un aspect fonctionnel (certains éléments développés à

l’origine ne sont peut être plus usités et risquent de retarder le projet pour rien). Aujourd’hui,

ces deux derniers points sont relativement complexes à cause d’une part des différents types

d’interventions et de leurs différents degrés de suivis (sans oublier les actions informelles

demandées par le client lors d’une intervention et les modifications effectuées par le client lui-

même) et de l’absence de suivi du contexte de l’application d’autre part. Il est alors quasiment

impossible de s’assurer d’avoir véritablement récupérer l’ensemble des informations. Cet état

de fait engendre soit :

- des migrations « trop souvent » systématiques pour limiter les risques immédiats

(basées uniquement sur l’application du client et rendues compatibles avec la nouvelle

version)

- des itérations importantes lors des tests réalisés pour parvenir au même niveau

fonctionnel que l’application existante.

Finalement le client ne bénéficiera pas de toutes les nouvelles capacités du logiciel et la

maintenance sera plus compliquée, baissant potentiellement sa rentabilité. La problématique

se situe essentiellement sur la reconstitution non seulement de l’historique des modifications

apportées par les différents intervenants chez l’éditeur mais également par le client mais aussi

et surtout sur la définition du contexte à prendre en compte.

En conclusion, pour l’éditeur, gérer le cycle de vie d’une application veut dire suivre

l’évolution de l’organisation et de ses besoins mais également les besoins technologiques. Ce

suivi est ponctué de différentes interventions plus ou moins importantes portant tant sur des

points fonctionnels que techniques. Pour réaliser une prestation sur une application existante,

un travail préliminaire plus important et complexe que lors d’un nouveau projet est nécessaire

pour reconstituer une vision de l’application dans son contexte actuel (son état au jour

d’aujourd’hui) avant d’évaluer et de valider les actions prévues. Aujourd’hui il existe ni


Page 192

méthode, ni support commun d’interventions ce qui a pour effet de générer un niveau

croissant de difficulté, proportionnel au nombre d’interventions.

2.2.2 Situation avec notre proposition.

Comme nous l’avons décrit précédemment, la mise en place d’une carte heuristique

dès les prémisses d’un projet et la mise à jour à chaque intervention permet de réduire les

problèmes de reconstruction d’une image de l’application dans son contexte. En effet en

consultant la map, soit au moment de la définition de l’intervention soit lors de la préparation

de l’intervention, la personne obtient une vision globale et commune de l’application sur

laquelle il doit interagir. La prise de connaissance du contexte doit lui permettre de situer le

contour de l’intervention et les impacts techniques et fonctionnels potentiels. Ainsi, les

problèmes énoncés dans les trois cas d’études précédents devraient être détectés en amont de

l’intervention soit par le client directement, soit par l’intervenant.

Pour le premier exemple, le lien entre les données et l’outil tiers aurait été visible

directement sur la map. Si malgré tout la modification avait eu lieu sans prendre en compte

des impacts collatéraux, le client aurait pu détecter rapidement la source du problème sur

l’outil tiers en cherchant la définition de ce dernier dans la map. De même, l’intervention du

support aurait été grandement facilitée puisqu’il n’aurait pas eut à rechercher la définition de

cet outil propre au client dans les différents documents ou dans les sources de développement

et la cause du problème aurait été identifiée rapidement.

Pour le second exemple, la migration aurait été plus efficace grâce à l’historisation et

la description des besoins contenues dans la map. Le travail de migration se serait concentré

sur les besoins toujours présents, les autres étant annotés comme obsolètes et les choix

techniques plus aisés grâce à la compréhension des besoins fonctionnels au regard des

solutions techniques préexistantes dans la nouvelle version du logiciel. De plus les données de

paramétrages propres au client auraient également été accessibles et à jour. Finalement, les

itérations pour aboutir au même niveau fonctionnel auraient été limitées, voire inexistantes, et

l’application résultante aurait bénéficiée de tous les avantages de la nouvelle version. L’autre

avantage de la map commune avec le client est de lui offrir un support pour le suivi de ses

modifications. En effet, certains clients sont semi-autonomes (faisant encore appel à l’éditeur

pour du support ou des évolutions), voire autonomes, sur leur application, c'est-à-dire qu’ils

interviennent directement sur le paramétrage, voire le développement de leur application.


Page 193

Aujourd’hui dans le premier cas, le plus critique pour l’éditeur, le client n’a pas de solution

simple pour stocker l’information et la partager avec l’éditeur. Conclusion, seul le client est

conscient des modifications qu’il a effectué, avec une maitrise plus ou moins importante de

leurs impacts sur le fonctionnement de certaines parties de l’application. Cette situation

engendre des difficultés supplémentaires pour corriger des anomalies liées à cette

modification mais détectées bien plus tard.

Finalement, cet outil de suivi commun avec le client retrace et conserve l’historique

des modifications effectuées tant par l’éditeur que par le client. La map constitue alors

l’unique référence pour les deux parties définissant le contexte, les prestations (le projet initial

et toutes les interventions) et la solution actuelle mise en place. Cette philosophie permet de

replacer l’application au centre du lien entre le client et l’éditeur car ce fil conducteur

contribue au suivi non pas des interventions comme actuellement mais de l’impact de celles-

ci, c'est-à-dire qu’il contribue au suivi du cycle de vie de l’application, cœur du lien entre les

deux parties.

2.3 Synthèse

Aujourd’hui, suite à la mise en place d’une application, les interventions de l’éditeur

se limitent souvent à trois types d’interventions :

- Les actions correctives : réalisées par le support en réponse à une déclaration

d’anomalie,

- Les actions d’améliorations/évolutions : réalisées par un chef de projet en réponse à

une commande ou dans le cadre d’une prestation,

- Les actions préventives : réalisées par un chef de projet pour conserver la

maintenabilité de l’outil.

Ces interventions suivent des règles de traitement et de suivi différentes engendrant des

difficultés dans le suivi de l’évolution de l’application et même des pertes d’informations. Ces

phénomènes sont accentués par les interventions directes du client sur son application qui ne

sont jamais connues de l’éditeur à part en cas de problème. Autrement dit, chaque

intervention entraine un niveau de risque croissant proportionnel au nombre de modifications

effectuées et l’appropriation du « nouveau » contexte de l’intervention est quasiment

impossible dans les temps impartis.


Page 194

Notre proposition de concentrer les informations sur un même support et de conserver un

historique des modifications de l’application et de son contexte sur ce même support améliore

la performance et la qualité des prestations (Figure 54). La définition du cadre de la prestation

et l’étude d’impact deviennent possibles en amont de l’intervention, limitant ainsi les risques

de déstabilisation de l’application. Tandis que dans le cadre d’une action corrective,

l’anomalie est resituée dans l’ensemble de son contexte à jour, facilitant l’identification de sa

source. Cette centralisation permet aussi de recentrer le suivi des interactions en termes de

suivi des modifications de l’application et de son environnement en sensibilisant de par sa

structure l’ensemble des acteurs du cycle de vie de l’application, éditeur comme client. Cette

sensibilisation doit porter sur l’intérêt de systématiser la mise à jour de la partie applicative

mais également du contexte (comment un problème est apparu ? Y-a-t-il un nouveau

besoin ou une modification d’un besoin ?). La map devient ainsi un support à

l’accompagnement du client et un support dynamique reflet du cycle de vie de l’application.

Figure 54. Améliorations des étapes après projet

Phase Les points clés Niv. Raisons Niv. Raisons Niv. Raisons

Compréhension des questions

+

difficulté de comprendre les

questions du client en

l'absence de connaissance de

l'application et surtout de la

sémantique client

++

- support global présentant les

aspects fonctionnels pris en

charge

- une vision sommaire de

l'application

+++

Sensibilisation du client à

l'intérêt de décrire précisément

les actions posant problème

Compréhension de l'application

-

pas de vision globale de

l'application à jour, nécessité

de rechercher l'historique ++

présentation sur un support de

tout le cycle de vie d'une

application (les choix, les

validations, les

modifications…)

Suivi de l'évolution de

l'application

--

- perte de contrôle du client

par rapport à son application

(ce qu'il a ou pas, les

modifications réalisées /

proposées…) et du contour

fonctionnel pris en charge

- voire de l'éditeur également

au regard du nombre

d'intervenants indépendants

tout au long du cycle de vie

++

support global et commun

entre l'éditeur et le client,

récapitulant toutes les

interventions et leurs impacts.

Vision toujours à jour de

l'application

Evaluation des demandes

d'évolution

+

difficultés pour l'éditeur d'être

force de proposition car pas

d'accompagnement

++

- vision globale de l'application

cliente à jour

- accompagment des

utilisateurs permettant d'être

force de proposition

- support facilitant la

connaissance de l'application

cliente / aux difficultés et ou

nouveaux besoins

+++

amélioration de la

compréhension des scénarii

d'utilisation et des difficultés

résultantes

Intégration

d'évolution/amélioration

-

difficultés pour l'éditeur :

- d'obtenir une vision claire des

besoins à prendre en compte

- d'estimer l'adéquation et la

cohérence des solutions

techniques

+

contexte d'utilisation

présentées au ragard de la

solution déployées et à jour

Suivi de l'utilisabilité de

l'application -

pas ou peu réalisé à part lors

de demandes d'interventions

ou la déclaration de bug

+

évolution du contexte montrant

les manques de l'application

sur un support unique

Support

Exploitation

Retours d'expérience

Sans les supports Avec la carte heuristique Avec la carte heuristique + persona


Page 195

Conclusion et Perspectives

Page 197

Conclusion et perspectives ___________________________________________________________________________

Une application « optimale » pour un client est une application qui se fond avec son

environnement tout en améliorant le fonctionnement du système. Pour intégrer une solution

PLM dans l’environnement d’une entreprise tout en apportant les services escomptés,

l’intégrateur et plus particulièrement si ce dernier est également l’éditeur, doit apporter non

seulement une solution technique répondant aux contraintes du client à long terme, mais

également un accompagnement de tous les instants du client pour que son application

fusionne avec l’organisation existante. La tâche de l’éditeur s’inscrit dans ces termes : il doit

être présent pour répondre aux besoins et aux difficultés rencontrées par les acteurs à travers

la mise en place de son logiciel tout au long de son cycle de vie mais également pour que la

solution s’intègre dans l’organisation. La compréhension mutuelle des attentes et des

contraintes des deux parties est alors primordiale. Chacun des intervenants comprend et

maitrise sa partie et l’échange de connaissances et le partage sont les vecteurs d’un résultat

réussi. Toutefois, l’objectif sera atteint uniquement si les acteurs utilisent le logiciel et se

l’approprient. Nous proposons d’améliorer le processus de déploiement et les supports

l’accompagnant pour accroître l’adéquation de l’application et la qualité des prestations tout

au long du cycle de vie de celle-ci.

Conclusions générales sur la thèse

Dans le premier chapitre, nous avons vu que pour résister sur le marché international,

les entreprises recherchent des solutions pour améliorer leur productivité, réduire leurs coûts

et accroître leur potentiel d’innovation. Aujourd’hui aux nouveaux besoins fonctionnels de

l’entreprise s’ajoutent les problématiques réglementaires imposant des solutions plus globales

pour gérer les entreprises de manière homogène et gérer les développements du couple

produits/projets mais aussi plus précises pour optimiser la dynamique du pilotage si possible

jusqu’au niveau local. Un des axes d’amélioration réside dans l’adoption de l’informatisation

des flux connexes, que ce soit l’ERP pour les aspects productions/ressources ou le PLM pour

les aspects conceptions/techniques. Mais aujourd’hui les entreprises n’ont pas toujours

conscience que pour aboutir aux capacités escomptées de chacun d’eux, le déploiement

impactera l’organisation même de l’entreprise de part le fait que ces outils sont très

structurants et nécessitent la mise en place d’une organisation structurée. Cette prise de


Page 198

conscience passe par une démarche de sensibilisation par les éditeurs et/ou intégrateurs qui

doivent aussi aider les entreprises durant le processus de déploiement de leur solution. La

méthodologie accompagnant la mise en place de ce type de logiciel doit donc être efficace et

fiable pour parvenir au résultat escompté tant au niveau technique qu’au niveau

organisationnel pour l’entreprise.

Dans le second chapitre nous avons défini le processus de déploiement utilisé par

LASCOM, éditeur et intégrateur de sa solution partie prenante des travaux de recherche. Nous

avons mis en évidence les principaux verrous induits par ce processus. Aujourd’hui, un

nombre important d’itérations est nécessaire pour spécifier définitivement la solution

logicielle en fonction des besoins, d’avantages théoriques que pratiques, de l’entreprise.

L’origine de ces itérations provient en particulier de la différence de perception du processus

de déploiement entre le client et l’éditeur. La problématique pour l’éditeur, centre de notre

étude dans le cadre de cette thèse CIFRE, repose essentiellement sur un double manque. La

manque de méthodologie rapide et efficace pour parvenir à modéliser le système à prendre en

compte dans son environnement et surtout le manque d’un support accessible par le plus

grand nombre d’intervenants et ce à tout moment du processus.

Le troisième chapitre, nous a permis d’analyser les problèmes rencontrés généralement

par LASCOM durant le déploiement. Pour améliorer la prestation de l’éditeur, trois axes de

réflexion émergent de cette étude : les outils, les méthodologies et la communication. D’un

point de vue outil, les éditeurs ont déjà pris conscience du problème en proposant des offres

plus adaptées au marché et plus rapide à déployer. Le nouvel enjeu se situe sur l’adaptabilité

du logiciel aux différentes contraintes imposées par le client mais aussi et surtout à

l’utilisateur. D’un point de vue méthodologique, l’enjeu réside essentiellement sur

l’accompagnement du client dans ce projet d’implémentation tant sur les concepts que sur la

prise en compte de l’utilisateur tout au long du cycle de vie de l’application. Du point de vue

de la communication, le problème subsiste entre l’éditeur et le client tant sur le suivi du

déroulement du projet, les impacts des choix opérés, etc., que chez le client sur la

communication autour du projet en général, son avancement, ses conséquences, etc. De ces

trois points ressort un élément majeur : la prise en compte active de l’utilisateur tout au long

du cycle de vie de l’application. En effet, la force de l’application (et donc la rentabilité du

projet) passe par sa pertinence et son utilisabilité. Pour ce faire il faut se centrer sur

l’utilisateur qui constitue le premier engrenage de la chaîne par l’emploi de l’application et le


Page 199

dernier par la validation ultime de la pertinence de la solution déployée. Il doit être le centre

des préoccupations du client et de l’éditeur et ce dès le début du projet et jusqu’à la fin de

l’utilisation de l’outil.

La première partie des résultats de notre analyse est présentée dans le quatrième

chapitre à travers la proposition d’un premier support au déploiement d’un logiciel de type

PLM. Elle repose sur l’utilisation des cartes heuristiques durant l’ensemble du cycle de vie de

l’application. L’idée est de constituer un document unique pour le suivi du projet et plus

généralement des différentes activités liées à l’application. Grâce à une structure préétablie et

aux concepts même des map, le document unique joue le rôle de moteur de la réflexion et de

la communication. Cet outil support de la modélisation et de collaboration entre l’éditeur et le

client permet de construire, comprendre et suivre les étapes de conception et les impacts des

décisions. En effet, les cartes offrent la capacité de concentrer un grand nombre

d’informations hiérarchisées dynamiques et « immédiates », offrant une vision globale,

commune et synthétique de l’ensemble des paramètres à prendre en compte pour fonder

l’application et plus généralement réaliser une intervention. L’intégration de toutes ces

informations favorise la communication et une meilleure compréhension des problématiques

fonctionnelles et techniques des deux parties aboutissant au choix de solutions plus adaptées

et consolidées en un optimum global. La simplicité du support rend accessible la modélisation

et la compréhension du cheminement à un plus grand nombre de profils d’intervenants

potentiels au cours du processus. Ainsi tous les acteurs partagent le même niveau

d’information et la même vision du projet facilitant la communication et la participation

proactive, vecteurs d’amélioration et d’appropriation de l’application.

Le cinquième chapitre se focalise sur un outil permettant à la fois d’améliorer le

niveau de communication sur le projet envers les futurs utilisateurs tout en accroissant la

connaissance des besoins réels de ces derniers. En effet, malgré la simplicité des cartes, il

n’est pas possible de faire participer tous les utilisateurs, seuls détenteurs du fonctionnement

réel du système grâce à leur perception locale de celui-ci et dont les a priori jouent un rôle

crucial sur le devenir de la solution. Notre proposition repose sur un second formalisme, le

persona qui peut être utilisé soit pour apporter des éléments concrets lors de la création de la

carte, soit pour affiner ou valider les résultats contenus dans la carte heuristique. L’objectif est

de créer des archétypes personnifiés des profils utilisateurs définissant leurs besoins et leurs

difficultés à partir d’un questionnement direct des intéressés. L’intérêt est d’instaurer un mode


Page 200

de communication autour du projet (l’avancement, les choix, etc.), d’accroître la contribution

d’un maximum d’acteurs afin d’améliorer le choix des solutions et de minimiser la résistance

aux changements. Une meilleure compréhension des besoins et des utilisations, que ce soit en

amont du projet ou durant l’exploitation doit permettre d’assurer une meilleure adéquation des

solutions techniques locales comme globales, gage d’un optimum global tout au long du cycle

de vie de l’application. De plus, cette technique sensibilise les clients, et plus particulièrement

les décideurs, sur l’importance de la prise en compte des utilisateurs pour sortir de la

généricité définissant les besoins globaux. Que ce soit lors de la modélisation amont ou lors

de l’évaluation des évolutions, la bonne définition des besoins locaux maximise le taux de

réussite du projet et plus particulièrement le taux d’adéquation de l’application aux besoins et

usages réels.

Le sixième chapitre illustre comment nos propositions pourraient potentiellement

améliorer le déroulement des phases du processus de déploiement de LASCOM au travers

d’études de cas « classiques » réelles de chez LASCOM. Quelque soit l’entrée dans le

processus et quelque soit le projet (la maturité, l’envergure, la méthode de gestion de projet,

etc.), notre proposition offre la possibilité de partager un support riche, flexible, simple et

accessible entre le client et l’éditeur et centré sur l’application. L’objectif de notre proposition

n’est pas de trouver une méthode pour prémunir les éditeurs des problèmes liés au contrat ou

pour choisir une méthode de gestion de projet mais de faciliter le déroulement de l’ensemble

des étapes du déploiement d’une solution. L’important est que celles-ci soient toutes réalisées

à moindre frais (sans prendre trop de temps) tout en partageant un même niveau d’information

avec le client sur ce qui lie sur le long terme un éditeur et un client c'est-à-dire le cycle de vie

de son application.

Perspectives industrielles pour LASCOM : projets sur les phases amont du

processus

Aujourd’hui grâce aux outils de prospection et de marketing toujours plus performants,

il arrive plus régulièrement à LASCOM d’entrer en contact avec un client avant même qu’un

projet d’implémentation d’un PLM soit en cours d’étude. Cette prise de contact très en amont

du projet implique généralement que le client entrevoit un potentiel à l’informatisation mais

sans avoir obligatoirement bien déterminé un besoin, soit parce qu’il n’entrevoit pas un projet

immédiatement mais il a déjà des idées, soit parce qu’il ne sait pas par ou commencer


Page 201

l’analyse de ses besoins. La prospection constitue pour lui une approche intéressante car il n’a

pas à chercher quel type de logiciel existe sur le marché, c’est l’éditeur qui vient à lui ! Le but

de l’éditeur étant de se différencier en amont pour orienter le choix final. Autrement dit, dans

les deux cas, le rôle du commercial est d’apporter un maximum d’arguments ciblés pour

pousser l’implémentation de sa solution au sein de l’entreprise. Aujourd’hui les outils à sa

disposition pour assoir son argumentaire sont de deux ordres :

- une intervention gratuite de l’avant vente pour illustrer ses propos et les besoins émis

par le client,

- la vente d’un service pour l’accompagner dans la détection de ses besoins.

Il est entendu que la première prestation correspond en une présentation orientée d’une

solution type sous forme d’une démonstration, tandis que la seconda correspond à la

réalisation d’un audit spécifique couteux car cette compétence ne fait pas partie du métier

d’un éditeur, mais plutôt d’un consultant. Dans les deux cas, LASCOM n’a ni une méthode ni

un support adapté à fournir au client potentiel. Chacun de ces éléments n’a pas les mêmes

fins. La méthode doit aider à faire émerger le projet en créant le cadre du besoin et le support

doit asseoir la vision du client par rapport à la solution, voire ajouter des besoins. Le choix de

l’un ou l’autre sera fonction de différents éléments : la maturité du projet mais aussi et surtout

évidemment les capacités financières. Ce point est crucial essentiellement pour les cas

d’émergence d’un projet au regard des coûts d’un audit spécifique. Malgré tout la taille ou

plutôt les capacités internes de l’entreprise peuvent également entrer en compte. Si un service

DSI (Direction des services informatiques) est présent une partie de l’expertise peut alors être

réalisée en interne. Le problème se pose donc plus particulièrement pour les petites et

moyennes entreprises voire les associations qui elles n’ont pas de gros moyens pour réaliser

ce type d’étude ni en interne, ni en externe que ce soit par un consultant indépendant ou un

éditeur/intégrateur. Cependant sans accompagnement pour réaliser cette étude, aucun projet

ne sortira, l’entreprise restera dans l’immobilisme et l’éditeur perdra un projet potentiel, si son

logiciel correspond bien au besoin. Ainsi le calcul du coût de l’audit est un vrai problème.

D’un coté il ne faut pas qu’il soit trop couteux sinon l’entreprise ne pourra pas acheter la

prestation ou alors son coût sera retiré du budget du projet déjà calculé au plus juste. D’un

autre coté le potentiel détecté ne sera pas forcément transformable en projet. Malgré tout

d’autres critères entrent souvent en jeu dans ce calcul. Par exemple, les éditeurs font assez

régulièrement de petits « sacrifices » quand ils sont convaincus du potentiel du projet,

d’autant plus s’il peut apporter en notoriété sur un nouveau type de projet ou de marché.


Page 202

Finalement, aujourd’hui l’accompagnement pour définir les besoins et identifier les

projets correspond à une vraie demande, d’où l’essor du consulting sur ce marché. Les

propositions faites par ces derniers sont généralement couteuses car elles comportent la

rédaction du cahier des charges très détaillé, censé améliorer le déroulement du projet. Or

comme nous l’avons vu dans cette thèse, quelque soit la qualité du cahier des charges, une

analyse complémentaire par l’éditeur est obligatoire pour mettre en perspective les besoins

réels (non interprétés) par rapport au logiciel choisi et pour aider au choix de la solution la

plus adaptée. Autrement dit, logiquement cette prestation n’est pas déductible du temps et du

coût du projet. Cette solution ne répond donc pas au besoin de petites et moyennes

entreprises. Dans leur cas, le besoin n’est pas de réaliser un cahier des charges poussé mais de

« dégrossir » le contour fonctionnel et déterminer les besoins majeurs pour évaluer et valider

l’intérêt de lancer un projet d’informatisation. Ceci n’est rendu possible que par une

présentation avant vente plus précisément adaptée aux besoins des PME et des arguments

commerciaux plus solides. Ce type de support ne faisant pas partie du cœur de métier des

éditeurs, ceux-ci sont généralement pas ou mal armés pour fournir cette aide facilement et à

bas prix. Nos propositions ouvrent de nouvelles perspectives aux commerciaux qui demain

posséderont ainsi deux outils supplémentaires à leur disposition pour répondre à ce type de

besoin. Le premier outil basé sur les cartes heuristiques pourrait être une proposition de

« mini forfait » comportant la présentation/formation à la démarche d’analyse basée sur les

heuristiques. Une telle démarche contribuerait à initier l’analyse du besoin basée sur

l’exploration du fonctionnement de l’entreprise par un certain nombre de personnes, puis

l’analyse des résultats au regard de son logiciel. Ceci nécessite que l’entreprise soit en

capacité de créer un groupe de réflexion avec au moins une personne fixe, pour conserver la

vision d’ensemble et animer l’exploration. Le second outil s’appuie sur les questionnaires

persona concernerait surtout une proposition de présentation/formation à la démarche centrée

sur l’acteur, permettant de lister les besoins réels en questionnant directement les personnes,

et faisant l’analyse des retours. Dans les deux cas, la présence de l’éditeur est nécessaire pour

expliquer la démarche et aider à analyser les résultats. Mais l’étape d’identification, étape qui

est la plus longue et la plus couteuse, nous pouvons imaginer que le client sera laissé en

autonomie partielle voire totale. En effet, au regard de la simplicité des formalismes et dans le

but de diminuer les coûts, l’entreprise peut avancer seule sur la description de son besoin.

Avec de telles propositions, le critère de choix ne sera plus d’ordre financier ou lié à la

taille de l’entreprise mais plutôt sur le choix de la méthode que souhaite l’entreprise : si elle


Page 203

veut et peut mettre en place un groupe de travail pour définir la vision globale de ses besoins

elle choisira de travailler avec les cartes heuristiques, si elle veut obtenir une vision locale des

besoins du terrain, elle optera pour persona. C’est deux méthodes sont complémentaires

uniquement dans le cas d’une analyse précise, autrement dit, il est tout à fait possible de

proposer les deux méthodes en les décalant dans le temps, l’une permettant de compléter et

valider les résultats de l’autre. Finalement grâce à l’une ou l’autre des méthodes, ou les deux,

le client peut prendre conscience des difficultés et des besoins émanant du cœur de son

entreprise, il a muri son besoin et évalué ses attentes. La proposition d’une intervention

d’avant vente prend alors toute sa pertinence car cette prise de conscience rend le client plus

réceptif et la démonstration sera orientée essentiellement sur le cadre fonctionnel déterminé.

Le but étant de prouver l’adéquation et les avantages de l’outil et provoquer le déclenchement

d’un projet avec l’éditeur. Que cette étude débouche sur un projet ou non, la mise en place de

l’une ou l’autre des méthodes apporte un double avantage pour l’éditeur. D’une part il accroît

sa notoriété et se place en tant qu’interlocuteur privilégié. D’autre part il réalise une étude de

marché gratuite, sur les évolutions et les améliorations à prendre en compte dans ses

applications pour coïncider avec sa cible, basée sur des retours d’expériences concrets tant sur

le mode de fonctionnement de ses clients potentiels, que sur les besoins inhérents.

Perspectives de recherche

Les perspectives de recherche de cette thèse s’articulent autour de trois axes. D’une

part, nos recherches doivent être approfondies au niveau des thématiques relatives à la

modélisation d’entreprise. Notre map générique et l’utilisation de persona ouvrent selon nous

de nouvelles perspectives au niveau de la modélisation d’entreprise et notamment dans

l’approche de modélisation ascendante. Dans leurs travaux, Girard et Robin [Girard, 06],

[Robin, 10] ont montré la nécessité de prendre en compte des vecteurs de performance

globaux (niveau entreprise) et locaux (niveau des acteurs). Les map et persona peuvent

contribuer à mettre en évidence ces vecteurs par une approche au plus près de l’acteur et par

un travail continu de fond sur un support accessible à tous.

D’autre part, le fait que nous soyons centrés sur les acteurs et que nous cherchions à

comprendre la place des utilisateurs dans l’entreprise nous conduit tout naturellement à

imaginer des perspectives autour de la mise en évidence, à travers nos propositions, de la

culture organisationnelle des entreprises. Les travaux menés dans laboratoire IMS par

Topliceanu sous la direction de messieurs Girard et Robin [Topliceanu, 08a], [Topliceanu,


Page 204

08b], [Topliceanu, 10] ont montré comment la culture organisationnelle agit sur l’acteur à

chaque niveau décisionnel et qu’il fallait avoir une vision plus détaillée sur les éléments de la

culture et ses formes de manifestation pour comprendre son influence sur la performance de

l’acteur. Il faut notamment être en mesure de suivre l’apparition et la formation des éléments

constitutifs de la culture organisationnelle. Les normes de comportement, les rites et les

cérémoniaux influencent les perceptions, ceux-ci conduisent à la formation des certaines

représentations de la réalité et celles-ci à leur tour influencent l’apparition des petites

histoires, des légendes et des mythes. La chaîne d’influence continue ainsi jusqu’à la

construction de valeurs communes qui soutiennent les croyances, les tabous, les traditions, les

symboles et conduisent à la formation et l’appropriation des rôles, des principes et du statut

des individus ce que détermine finalement leurs normes de comportements, leurs « rites » et

leur propre culture organisationnelle. Notre approche proche des acteurs et représentative de

leur vision de leur réalité de l’entreprise sur le long terme (le cycle de vie d’une application

pouvant être long) peut aider à la mise en évidence d’une partie des normes de comportement

et de leur évolution. Nous aurons donc à cœur à explorer ces pistes de recherche.

Enfin, au-delà de la culture organisationnelle, il semble que nos propositions peuvent

aussi être perçues sous l’angle de la thématique de la capitalisation de connaissances.

Aujourd’hui notre objectif ne concernait « que » l’identification, la définition et la

capitalisation des éléments « utiles » à LASCOM. Ainsi, si nous allons au-delà de cette vision

restrictive et que nous complétons et enrichissons nos modèles, nous devrions être en mesure

de capitaliser des éléments plus larges de la connaissance dans l’entreprise. L’un des premiers

éléments à développer dans nos map concernera les collaborations entre acteurs. Nous

sommes actuellement centrés sur des aspects très pratiques d’échanges de données et nous

pensons pouvoir compléter nos modèles pour arriver à capitaliser des éléments plus pertinents

notamment en vue du pilotage des activités collaboratives comme ceux décrits par Robin et

al. [Robin et al., 07] [Baczkowski et al., 08b]. Ces travaux seront à mettre en parallèle de

ceux que nous mènerons dans le cadre de la modélisation d’entreprise.

Bibliographie personnelle

Page 205

Bibliographie personnelle

[Baczkowski et al., 08] Baczkowski M., Rose B., « Capitalisation des connaissances et aide

décisionnelle en phase d’industrialisation : le cas de Sony Alsace »,

7ième conférence internationale de Modélisation et Simulation,

MOSIM’08, pp. 542-551, ISBN : 978-2-7430-1057-7, Paris (France),

31 mars – 2 avril 2008.

[Baczkowski et al., 08] Baczkowski M., Robin V., Girard P., « Applying a design system

modeling approach to deploy the ADVITIUM PLM solution in

enterprises », European Symposium on Innovative Management

Practices, ERIMA’08, Porto (Portugal), 6 – 7 November 2008.

[Baczkowski et al., 08] Baczkowski M., Rose B., Robin V., « Capitalisation des

connaissances et aide décisionnelle en phase d’industrialisation : le

cas de Sony Alsace », Logistique & Management vol. 16, n°1, pp. 87-

98, 2008.

[Baczkowski et al., 12] Baczkowski M., Robin V., Rose B., « Using of the concepts of roles

and context in a project management / plm solution: the real case

study of LASCOM », Engineering Systems Design and Analysis,

ESDA’2012, Nantes, 2-4 July 2012.

Bibliographie

Page 207

Bibliographie

A [Abdmouleh 04] Abdmouleh A., « Composants pour la Modélisation des Processus

Métier en Productique, basés sur CIMOSA », Thèse de doctorat Ecole

Nationale d'Ingénieurs de Metz (ENIM), Metz, 15 Septembre2004.

[AFNOR X50-105, 94] Norme : Management de Projet, 1994.

[AFNOR X50-176, 00] Norme : Outils de management - Management des processus, édition

juin 2000.

[AMICE, 93] ESPRIT Consortium AMICE, “CIMOSA - Open System Architecture

for CIM”, Springer-Verlag, Berlin, ISBN 3-540-56256-7, ISBN 0-

387-56256-7, 1993.

[Auzelle et al., 08] Auzelle, J.P., Morel G., Panetto H., Mayer F., “Using Systems of

Systems Engineering to Improve the Integrationof Enterprise-Control

Systems”, Special issue on Systems Engineering: Best of France. 11/3.

Insight journal of INCOSE, juillet 2008.

B [Baczkowski et al., 08a] Baczkowski M., Robin V., Girard P., « Applying a design system

modeling approach to deploy the ADVITIUM PLM solution in

enterprises », European Symposium on Innovative Management

Practices, ERIMA’08, Porto (Portugal), 6 – 7 November 2008.

[Baczkowski et al., 08b] Baczkowski M., Rose B., Robin V., « Capitalisation des

connaissances et aide décisionnelle en phase d’industrialisation : le

cas de Sony Alsace », Logistique & Management vol. 16, n°1, pp. 87-

98, 2008.

[Baczkowski et al., 12] Baczkowski M., Robin V., Rose B., « Using of the concepts of roles

and context in a project management / plm solution: the real case

study of LASCOM », Engineering Systems Design and Analysis,

ESDA’2012, Nantes, 2-4 July 2012.

[Benali et al., 2002] Benali, K., Bourguin, G., David, B., Derycke, A., Ferraris C.,

« Collaboration/Coopération », actes des secondes assises nationales

du GdR I3, Nancy ; Rédacteur J. Lemaitre, Cépaduès-Editions

Décembre 2002.

[Bidan, 2004] Bidan M., « Fédération et intégration des applications du Système

d’information de gestion », Système d’Information et Management,

Vol. 9-2, pp.5–24, 2004.

[Bissay et al., 08a] Bissay A., Lefebvre A., Pernelle P. and Bouras A., « Approche de

capitalisation des connaissances au sein des systèmes plm ». In 1er

colloque international sur les Systèmes Industriels et Logistiques

(SIL'08), Marrakech, Maroc, Décembre 2008.

[Bissay et al., 08b] Bissay A., Lefebvre A., Pernelle P. and Bouras A., “ Deployment

methodology of is”. SIG-PLM Workshop (IFIP WG 5.7), Lausanne,

Suisse, Juillet 2008.

Bibliographie

Page 208

[Bissay et al., 08c] Bissay A., Lefebvre A., Pernelle P. and Bouras A., “ Integration of

business processes and performance indicators in a plm”. In

International Conference on Advances in Production Management

Systems (APMS'08), Espoo, Finlande, Septembre 2008.

[Bissay, 10] Bissay A., « Du déploiement d’un système PLM vers une intégration

des connaissances », Thèse de doctorat en Informatique, Université

Lumière Lyon 2, soutenue le 12 janvier 2010.

[Blanc, 05] Blanc S., “Interoperability problems: Management of evolution of

collaborative enterprises”, Interop ESA, Doctorial Symposium,

Genève, 21-22 février 2005. http://interop-esa05.unige.ch/.

[Blanc, 06] Blanc S., “Contribution à la caractérisation et à l'évaluation de

l'interopérabilité pour les entreprises collaboratives”, Thèse de

Doctorat de l’Université Bordeaux 1, soutenue le 20 décembre 2006.

[Boboc, 02] Boboc A., « Formes de socialisation dans la conception automobile –

le cas Renault », Thèse de doctorat de l’Ecole Nationale des Ponts et

Chaussées, février 2002.

[Boehm, 81] Boehm, B. W., “Software Engineering Economics”, Prentice Hall,

1981.

[Bonnefous, 01] Bonnefous C., Courtois A., « Indicateurs de performances »,

Editions Hermès, 2001.

[Booch 00] Booch G., Rumbaugh J., « Le guide de l'utilisateur UML », Eyrolles,

Paris, 2000.

[Bordegoni et al., 04] Bordegoni, M., Benassi, M., Cugini, U., Cascini, G., ”Roadmap for

the selection and the evaluation of PLM tools in product development

processes”, in Tools and Methods of Competitive Engineering, Edited

by Imre Horwvath, Paul Xirouchakis, Millpress Rotterdam

Netherlands, ISBN 90-5966-018-8, Vol.1, pp. 319-330, 2004.

[Botta et al, 01] Botta V., Millet P.A., Neubert G., “The role of Enterprise Modeling in

ERP, Implementation”, International Conference on Industrial

Engineering and Production Management (IEPM'2001), ISBN 2-

930294-07-8, Quebec, Canada, August 2001, Book I,pp 220-231

[Brangier, 10] Ppt Personnas HEC Montreal 2010

[Browne et al., 95] Browne J., Sackett P.J. et Wortmann J.C., “Future manufacturing

systems- Towards the extended enterprise”, Computers in Industry,

Vol. 25, n°3, pp. 235-254, 1995.

[Buzan, 93] Buzan T., Buzan B., “The Mind Map Book”, Pearson Education, 277

pages, ISBN 0-563-36373-8, 2006.

C [Chevallereau, 11] Chevallereau B., « Contribution des nouvelles approches de

modélisation à la durabilité des apllications », Thèse de Doctorat de

l’Ecole Centrale de Nantes, soutenue le 11 février 2011.

[CIMdata, 2009] CIMdata, “PLM Market Growth in 2008”, Mid-Year, 2009.

[Creativité, 12] Site internet http://www.creativite.net, site « consacré à l'émergence

de la pensée créative des individus et au développement du potentiel

créatif des équipes pour innover en entreprise », site consulté en

janvier 2012.

http://interop-esa05.unige.ch/

http://www.creativite.net/

Bibliographie

Page 209

[Crowston, 97] Crowston K., “A coordination theory approach to organizational

process design”, Organization Science, Vol. 8, n°2, 157–175, 1997.

D

[David et al., 01] David, B., Vaisman, G., Saikali, K., « Evolution du Travail Coopératif

Assisté par Ordinateur : Vers la TCAO « capillaire » », CITE’2001,

Coopération, Innovation et Technologie, Université Technologique de

Troyes, 29-30 Novembre 2001.

[Debaecker, 04] Debaecker D., « PLM, la gestion collaborative du cycle de vie des

produits », Product Life-Cycle Management, Hermès - Lavoisier,

ISBN : 2-7462-0884-9, 2004.

[Deladriere et al., 07] Deladrière J-L., Le Bihan F., Mongin P., Rebaud D., « Organisez vos

idées avec le Mind Mapping », 2ième

édition, éditions Dunod, 400 p.,

2007.

[Di Mascolo et al., 00] Di Mascolo M., Duri C., Frein Y., « Comparison between three Pull

Control Policies : Kanban, Base Stock and Generalized Kanban »,

Annals of Operations Research, Vol. 93, pp. 41-69, 2000.

[Doumeingts, 84] Doumeingts G., « Méthode GRAI: méthode de conception des

systèmes en productique », Thèse d'état : Automatique, Université

Bordeaux I, 1984.

[Ducq, 99] Ducq Y., « Contribution à une méthodologie d'analyse de la

cohérence des systèmes de production dans le cadre du modèle

GRAI », Thèse de doctorat, Université Bordeaux 1, Bordeaux, 1999.

[Ducq, 05] Ducq Y., Vallespir B., “Definition and aggregation of performance

measurement system in three aeronautical workshops using the

ECOGRAI method”, Production Planning & Control, Vol.16, N°2, p.

163 - 177, 2005.

[Duffy et O’Donnell, 97] Duffy A. H. B., O’Donnell F., “A model of product development

performance. Designers—The key to successful Product

Development”, Darmstad Symposium, 3–5 décembre 1997.

[Dutta, 05] Dutta D., Wolowicz J.P., “An Introduction to Product Lifecycle

Management”, in Proceedings of the 12th ISPE International

Conference on Concurrent Engineering: Research and Applications,

Fort Worth, Dallas, USA, 2005.

F [Fisher, 06] Fisher D.A., “An Emergent Perspective on Interoperation in Systems

of Systems”, rapport technique, Carnegie Mellon University, Software

Enginnering Institute, mars 2006.

G [Gervais, 06] Gervais F., « Combinaison de spécifications formelles pour la

modélisation des systèmes d’information », Thèse de Doctorat,

Université de Sherbrooke, décembre 2006

[Giard, 03] Giard V., « Gestion de Production », Collection Gestion, Economica,

2003.

Bibliographie

Page 210

[Gibert, 80] Gibert, P., « Le contrôle de gestion dans les organisations

publiques », Paris, Editions d'Organisation, 1980.

[Girard, 06] Girard P., Robin V., “Analysis of collaboration for project design

management”, Computers in Industry, vol. 57, pp 817-826, 2006.

H [Hazebroucq, 99] Hazebroucq J.M., « La nouvelle conception de la performance: être

efficace oui, mais aussi efficient », Revue Gestion,1999.

[Hewitt 85] Hewitt C., The Challenge of OpenSystems, Avril 1985.

I [ICAM, 81] ICAM Architecture Part II-Volume IV - Function Modeling Manual

(IDEF0), AFWAL-TR-81-4023, Materials Laboratory, Air Force

Wright Aeronautical Laboratories, Air Force Systems Command,

Wright-Patterson Air Force Base, Ohio 45433, juin 1981.

[IFAC – IFIP, 97] IFAC – IFIP Task Force, “GERAM : Generalised Enterprise

Reference Architecture and Methodology”, Version 1.4, ISO

TC184/SC5/WG1, N398, août 1997.

[ISO 9000, V. 2000] ISO 9000 00, « Qualité et systèmes de management ISO 9000 »,

Editions AFNOR, 581p., 2001.

[ISO 9001, V. 2000] Norme européenne NF EN ISO 9001 version 2000, « Système de

management de la qualité – Exigences », AFNOR, 2000.

[ISO 9241-210, 08] Norme ISO 9241-210, « Ergonomie des interactions homme-

Machine », conception centrée sur l’humain des systèmes interfacés,

2008.

[ISO 10007, 03] Norme ISO 10007, « Systèmes de management de la qualité — Lignes

directrices pour la gestion de la configuration », 2003.

J [Jacobson 92] Jacobson I., Christerson M., Jonson P., Övergaard G., “Object-

Oriented Software Engineering: A Use Case Driven Approach”,

Addison-Wesley, Reading, March 1992.

K [Kaplan et Norton, 98] Kaplan R.S., Norton D.P., « Le tableau de bord prospectif. Pilotage

Stratégique : les 4 axes du succès », Editions d’Organisation, 1998.

L [Laleau, 02] Laleau R., « Conception et développement formels d’applications

bases de données. », Habilitation à diriger des recherches, Université

d’Evry Val d’Essonne, 2002.

Bibliographie

Page 211

[Le Duigou, 10] Le Duigou J., « Cadre de modélisation pour les systèmes PLM en

entreprise étendue – Application aux PME mécaniciennes », Thèse de

doctorat, Ecole Centrale de Nantes, 2010.

[Le Masson et Weil, 05] Le Masson P ., Weil B., « De la conception réglée à la conception

innovante : raisonnements et organisation pour domestiquer

l’innovation », Journées GPS, « Vers une conception et une conduite

de projet intégrées », 30 juin et 1ier

juillet 2005, Toulouse.

[Le Moigne, 90] Le Moigne J. L., « La modélisation des systèmes complexes », Bordas,

1990.

[Lonchampt, 04] Lonchampt P., « Co-évolution et processus de conception intégrée de

produits : Modèle et support de l'activité de conception », Thèse de

l’INPG de Grenoble, juin 2004.

M [Mayer et al., 95] Mayer R.J., Crump J.W. Fernandes R., Keen A., Painter M.K.,

“Information Integration for Concurrent Engineering (IICE)

comprendium of methods report”, Interim Technical Paper for Period

February 1991 to March 1995, 1995.

[Mayer et Auzelle, 07] Mayer, F. and Auzelle, J-P., “Is system of systems a candidate

rationale artifact for entreprise information-intensive system modeling

?”, in 9th International Conference on The Modern Information

Technology in the Innovation Processes of the Industrial Enterprise,

MITIP 2007, Florence, Italie, 2007.

[Midler, 97] Midler C., « Evolution des modèles d’organisation et régulations

économiques de la conception », Annales des mines, 1997.

[Millet et al, 05] Millet P-A, Neubert G., Botta-Genoulaz V., « Une approche outillée

de l'intégration », 6e Congrès international de génie industriel,

Besançon, 7-10 juin 2005.

[Millet, 08] Millet P-A, « Une étude de l’intégration organisationnelle et

informationnelle – Application aux systèmes d’informations de type

ERP », Thèse de l’INSA de Lyon, octobre 2008.

[Morlay, 01] Morlay C., « Gestion d’un projet système d’information – Principes

techniques mise en œuvre et outils », Dunod, Paris, 2001.

[Munoz, 02] Munoz Zarate S., « Coordination, intégration et innovation dans le

système de conception international de l’industrie des équipementiers

automobiles », Thèse de doctorat de l’INPG, 2002.

N [Neubert, 09] Neubert G., « Intégration et collaboration dans les entreprise en

réseau », Habilitation à diriger des recherches à Université Lumière

Lyon II, décembre 2009.

O [O’Brien et Marion, 97] O’Brien J., Marion G., « Les systèmes d’information de gestion »,

1997

Bibliographie

Page 212

[OMG, 03] Object Management Group, “OMG Unified Modeling Language

Specification”,http://www.omg.org/docs/formal/03-03-01.pdf,

Version 1.5 formal/03-03-012003, Mars 2003.

[Ostergaard et Summers, 03] Ostergaard K., Summers J.D., “A taxonomic classification of

collaborative design process”, Proceedings ICED 03, Stockholm, août

2003.

P [Parsaei et Sullivan, 93] Parsaei H.R., Sullivan W.G., “Principles of concurrent engineering”,

in “Concurrent engineering contemporary issues and modern design

tools”, Chapman & Hall, 1993.

[Paviot, 10] Paviot T., « Méthodologie de résolution des problèmes

d’interopérabilité dans le domaine du Product Lifecycle

Management », Thèse de Doctorat de l’Ecole Centrale de Paris,

soutenue le 1ier

juillet 2010.

[Porter, 86] Porter M.E., « Choix Stratégique et Concurrence », Economica, 1986.

[Poveda, 01] Poveda O. “Pilotage technique des projets d’ingénierie simultanée,

modélisation des processus, analyse et instrumentation”, Thèse

Institut National Polytechnique de Grenoble, 2001.

[Prudhomme, 99] Prudhomme G., « Le processus de conception de systèmes mécaniques

et son enseignement – La transposition didactique comme outil d’une

analyse épistémologique », Thèse de doctorat de l’Université Joseph

Fourier, 1999.

R [Robin et al., 05] Robin V., Sperandio S., Blanc S., Girard Ph., “Interactions modelling

between factors influencing performance of the design process”,

Proceedings ICED2005, Melbourne, Australie, 2005.

[Robin et al., 07] Robin V., Rose B., Girard P., “Modelling collaborative knowledge to

support engineering design project manager”, Computers in Industry,

vol. 58, pp 188-198, 2007.

[Robin, 10] Robin V., Girard P., “An integrated product-process-organization

model to manage design system”, International Journal of Product

Development, vol. 10, pp. 318-337, 2010.

[Roboam 93] Roboam M., « La méthode GRAI, principes, outils, démarche et

pratique », Teknéa, Toulouse, 1993.

[Ross, 77] Ross D.T., “Structured Analysis (SA): A Language for communicating

ideas”, IEEETransactions on Software Engineering, Vol. SE-3, 1977.

[Rumbaugh 91] Rumbaugh J., Blaha M., Premerlani W, Eddy F., “Object Oriented

Modeling and Design”, 1991.

S [Sadfi, 02] Sadfi C., « Problèmes d’ordonnancement avec minimisation des

encours », Thèse Institut National Polytechnique de Grenoble, 2002.

Bibliographie

Page 213

[Sansonnet 04] Sansonnet J-P., « Approches de l'Hétérogénéité Sémantique entre

Agents Informationnels », cours en ligne, dernier accès janvier 2012,

www.limsi.fr/Individu/jps/enseignement/tutoriels/sma/doc/4.hs.pdf,

cours mis en ligne en janvier 2004.

[Sauser, 06] Sauser, B., Boardman J., “From Prescience to Emergence: Taking

Hold of System of Systems Management” 27th American Society for

Engineering Management National Conference, October 26-28,

Huntsville, USA, 2006.

[Scheer 99] Scheer A.W., “ARIS-Business Process Modeling”, Springer-Verlag,

Berlin, 1999.

[Shorter 00] Shorter D., “Enterprise Integration framework for Enterprise

Modeling”, Revision of ENV 40003, Second Internal Draft, 2000.

[Sudarsan et al., 05] Sudarsan R., Fenves S. J., Sriram R.D., Wang F., “A product

information modeling framework for product life cycle management”,

Computer-Aided Design, Vol. 37, n°13, pp. 1399-1411, 2005.

[Sudarsan et al., XX] Sudarsan R., Fenves S. J., Sriram R.D., Wang F., “A product

information modeling framework for product life cycle management”,

Computer-Aided Design, Vol. 37, n°13, pp. 1399-1411, 2005.

T [Tardieu et al., 83] Tardieu H., Rochfeld A. et Colletti R., « La méthode Merise :

Principes et outils », tome 1, Paris, Éditions d'organisation, 328 p.,

ISBN 2-7081-1106-X et 2708124730, 1983.

[Tardieu et al., 85] Tardieu H., Rochfeld A., Colletti R., Panet G. et Vahéee G., « La

méthode Merise : Démarches et pratiques », tome 2, Paris, Éditions

d'organisation, 460 p., ISBN 2-7081-0703-8, 1985.

[Tomala, 02] Tomala F., « Proposition de modèles et méthodes pour l'aide à

l'évaluation des performances d'une innovation dès sa conception »,

Thèse de Doctorat, Université de Valenciennes et du Hainaut

Cambrésis, 2002.

[Topliceanu et.al, 08a] Topliceanu G. D., Robin V., Girard Ph., Ispas C., “Ensuring design

system efficiency by managing its performance inductors”, Academic

journal of manufacturing engineering, Timisoara, vol.6, n°1, 008

[Topliceanu et.al, 08b] Topliceanu G. D., Robin V., Merlo C., Girard Ph., “A preliminary

approach to consider organizational culture in the strategic design

project management”, Proceedings of ERIMA08, 6-7th November,

Porto, Portugal, 2008.

[Topliceanu, 10] Topliceanu G., « Prise en compte de l’influence de la culture

organisationnelle pour la conduite des activités de conception

collaboratives », thèse de Doctorat de l’Université Bordeaux 1,

soutenue le 6 janvier 2010.

[Tudor, 06] Tudor CRP H., « Modélisation des processus métiers : Etat de l'art et

conseils pratiques », Rapport de veille et recommandations , CITI,

2006.

http://www.limsi.fr/Individu/jps/enseignement/tutoriels/sma/doc/4.hs.pdf

Bibliographie

Page 214

V

[Vernadat 96] Vernadat F., “Enterprise Modeling and Integration: Principles and

Applications”, Chapman&Hall, Londres, 1996.

[Vernadat 99] Vernadat F.B., « Techniques de modélisation en entreprise :

applications aux processus opérationnels », Economica, Paris, 1999.

[Volle,06] Volle M., « De l’Informatique : Savoir vivre avec l’automate »,

Economica, 2006

W [WfMC 99] WfMC, Workflow Management Coalition, Interface 1: Process

Definition Interchange Process Model Document WfMW-TC-1016-P,

http://www.wfmc.org/standards/docs/TC-1016-

P_v11_IF1_Process_definition_Interchange.pdf, 1999.

[Williams, 92] Williams T.J., “The Purdue Enterprise Reference Architecture”,

Instrument Society of America, Research triangle Park, NC, 1992.

http://www.wfmc.org/standards/docs/TC-1016-P_v11_IF1_Process_definition_Interchange.pdf

http://www.wfmc.org/standards/docs/TC-1016-P_v11_IF1_Process_definition_Interchange.pdf

Annexes

Page 215

Annexes

Annexe 1. Des solutions logicielles au cœur de la « r »évolution : ERP et PLM

Longtemps la notion de Système d’Information comme nous l’avons décrite

précédemment est demeurée assez floue pour les entreprise et lorsqu’une société se lançait

dans une politique « d’informatisation » cela se traduisait souvent par la mise en place d’un

nouvel outil pour et dans un seul service, pour un cadre fonctionnel réduit indépendamment

des autres services. C’est ainsi qu’aujourd’hui les entreprises se retrouvent avec bon nombre

de logiciels informatiques relativement dédiés qui permettent d’assurer la gestion des relations

clients (CRM), la gestion et les opérations de l’entreprise (ERP), le suivi du cycle de vie des

produits/projets (PLM), etc. [Sudarsan et al., 05]. Leur principal but est d’aider au

déploiement d’une stratégie d’entreprise en apportant, à l’ensemble des utilisateurs, une

automatisation d’une démarche ou d’une méthode et une base de connaissance issue de la

capitalisation de l’expérience. Nous assistons actuellement à une redéfinition des contours de

ces outils avec pour visée l’atteinte d’une cohérence globale pour maximiser la mutualisation

des applications et répondre à un niveau d’interopérabilité important. Ce souci d’inscrire

efficacement les outils dans Système d’Information (SI) efficace et efficient traduit le souhait

des entreprises de voir en leur SI un élément primordial d’aide au pilotage et à la conduite de

leurs activités. Tout ceci semble devenir possible grâce à cette informatisation massive et

transverse aux services de l’entreprise qui contribue à faciliter et à centraliser les informations

dans des outils appropriés sous un format exploitable voire exportable. Dans le cadre de nos

travaux de recherche, nous allons essentiellement nous intéresser à deux types d’outils : les

ERP pour ce qui concerne la gestion intégrée des activités de l’entreprise et les PLM qui

participent au suivi du cycle de vie des produits.

1.1. Enterprise Ressource Planning (ERP) - Progiciel de gestion intégré

Pendant longtemps les industriels se sont concentrés sur l’optimisation de leur ligne de

production en utilisant les moyens mis à leur disposition telle que l’automatisation, la

robotisation ou la délocalisation afin de diminuer le ratio coût/temps. Or la multiplicité et la

complexité des produits à fabriquer ont rendu ces solutions insuffisantes pour accroître

durablement la performance de l’unité de production, tout en conservant une politique de

réduction des coûts et sans risquer de provoquer l’arrêt de la production pour des raisons

matérielles. C’est dans ce contexte que la première orientation stratégique d’informatisation

Annexes

Page 216

massive au cœur des entreprises fut centrée sur le système de production (ordonnancement,

achat, fabrication, assemblage) et ce grâce à l’émergence de logiciels intégrés : les ERP

(Enterprise Ressource Planning). Ces derniers calculent et surtout planifient les besoins en

composants par période et ce, à partir des nomenclatures et stocks intermédiaires de niveau en

niveau. Dès la saisie et le traitement de l’information stockée dans la base de données, ce

progiciel informatique de gestion impacte en temps réel l’ensemble de la chaine de

production, représentée par différents modules [Bidan, 04]. L’objectif principal d’un ERP est

de simplifier les flux et processus d’une entreprise et de diffuser l'information en interne de

manière optimale. Cette facilité de circulation de l'information permet d'élaborer des outils

puissants de gestion et d'analyse, et donc d'aide à la décision. Il doit ainsi permettre à

l’entreprise d’être plus opérationnelle et plus réactive. S'il est difficile de quantifier avec

précision le retour sur investissement et les bénéfices nets comptables, l'ERP reste

indispensable et sa contribution à la performance de l'entreprise n'a jamais été démentie.

L'automatisation des processus de gestion qu'il couvre assure des gains de productivité

essentiels, voire impératifs : meilleure qualité des données, réduction des stocks, diminution

des coûts administratifs et de production. Cependant, après une période où les investissements

étaient perçus comme d'éventuels leviers de croissance (création de valeur), les Directions des

Systèmes d'Information sont désormais systématiquement tenues de justifier leurs dépenses et

de limiter les coûts. Or, un ERP représente un poste de dépenses lourd, tant lors de la mise en

œuvre du projet que durant la période de fonctionnement.

C’est pourquoi au delà de l’optimisation du système de production en termes de gestion, la

capacité et la qualité de la collaboration de l’ensemble des acteurs de la chaine deviennent des

critères prépondérants dans le choix et la mise en place de ce type de progiciel. Autrement dit,

il est crucial, en termes de flux, que la propagation et la réutilisation des informations au sein

de ce logiciel, pour les différents services interconnectés, mais surtout au sein de l’ensemble

des applications métiers de l’entreprise, fasse partie intégrante de la solution pour accélérer la

production durablement. L’objectif complémentaire de ce type d’investissement est de

répondre facilement et rapidement au besoin de gestion mais également aux nouveaux besoins

des différents services à travers l’ERP ou via le système d’information dans lequel il s’intègre.

1.2. Product Life Management (PLM) - Gestion du cycle de vie du produit

La demande client croissante, en termes de nouveautés et de qualité, et la concurrence

omniprésente se durcissant, l’innovation devient le maitre mot pour toutes les entreprises en

Annexes

Page 217

respectant les contraintes temporelles, le « time to market » se réduisant de jour en jour, mais

également les contraintes réglementaires tout au long du cycle de vie du produit (de sa

conception à son recyclage). Après s’être concentré sur ce qui semblait être les éléments clés

de l’entreprise (la ligne de production, puis le système de production), petit à petit les

industriels ont perçu le besoin d’optimiser l’ensemble de la fabrication, c'est-à-dire en amont

comme en aval de la production. En effet, la connaissance et la maitrise du produit se situent

non seulement lorsque le produit est matérialisé, mais bel et bien tout au long de son cycle de

vie, que les activités et les ressources soient internes ou externes à l’entreprise.

Dans la littérature on distingue deux définitions du cycle de vie : le virtuel et le réel [Le

Duigou, 10], ce dernier correspondant aux composantes où le produit a une réalité physique.

Ce cycle est décomposable en huit étapes chronologiques : l’émergence d’un besoin et son

identification, la recherche des concepts permettant de répondre à ce besoin, la spécification

des solutions envisagées, le prototypage des solutions sélectionnées, l’industrialisation de la

solution retenue, la fabrication et la mise sur le marché du produit fini, finalement

extérieurement à l’entreprise, l’utilisation par le consommateur du produit et sa fin de vie.

Inclure ces deux dernières étapes permet de prendre en considération les retours client, tant

d’un point de vue utilisation et (in)satisfaction que les besoins connexes initiés par cette

nouveauté, dans le cycle de vie du produit. Ce sont les vecteurs principaux d’identification

des nouveaux besoins et les indispensables sources d’innovation en termes de produit, de

marketing, de conception, de recyclage… Dans le cadre du cycle de vie réel, cette fois le

bouclage est possible essentiellement en considérant l’utilisation de matières recyclées.

Geram [IFAC, 97] propose un découpage chronologique des phases (Figure 55) :

Figure 55. Phase du cycle de vie d’un produit

Annexes

Page 218

D’un point de vue organisationnel, cette schématisation séquentielle correspond en réalité à

une vue très simplifié de la figure 3 illustrant les interactions et de l’ordonnancement des

étapes, tout au long du cycle de vie du produit [Sudarsan et al., 05] (Figure 56).

Figure 56. Cycle de vie d’un produit

Cette nouvelle considération du produit par les industriels signe un tournant stratégique

important et sonne l’arrivé du PLM (Product Life Management) au cœur des entreprises.

CimData [CimData, 09] définit le PLM comme : une approche stratégique qui met en œuvre

un ensemble cohérent de pratiques permettant de supporter la création collaborative ainsi

que l’organisation, la diffusion et l’utilisation des informations relatives à la définition du

produit au travers de l’entreprise étendue, de la conception à la fin de vie, et d’intégrer les

hommes, les processus, les systèmes d’organisation et d’information. Ainsi le PLM est avant

tout une stratégie qui englobe la définition du produit mais également la définition des

moyens de production, des services liés au produit, (services durant son utilisation mais

également services de maintenance, de traitement en fin de vie…), des technologies mises en

œuvre, des organisations le concernant… mais également les différentes ressources et toute

l’orchestration nécessaire aux différentes activités mises en œuvre pour donner « vie » au

produit [Le Duigou, 10]. Or au vu de la croissance exponentielle de variétés et de variantes

des produits, amplifiée par les résultats concluant de l’ERP sur la fabrication,

Annexes

Page 219

l’informatisation de cette démarche est devenue inévitable pour généraliser et capitaliser les

connaissances détenues par chacun des acteurs de la naissance de l’idée à la fabrication du

produit et ce, pour chaque produit/projet. En cherchant à formaliser et standardiser une

méthodologie, les entreprises ont pris conscience que leur savoir faire, selon ce point de vue,

répondait d’avantage aux contraintes d’un produit/projet qu’à une structure organisationnel

hiérarchique comme précédemment. Cette fois le support logiciel doit être, pour répondre

efficacement aux besoins, axé sur les différents produits/projets et leur environnement propre

et doit favoriser la collaboration de l’ensemble des acteurs agissant sur le produit.

Fonctionnellement le logiciel support à cette systématisation méthodologique, quelque soit

l’équipe en charge (interne ou externe à l’entreprise), doit :

- Gérer une quantité importante d’informations complexes pour chacun des

produits/projets,

- Gérer les différentes vues métiers, de ces informations, nécessaires aux différents

intervenants,

- Gérer l’intégrité des données et la traçabilité des actions/modifications opérées sur le

produit au cours du temps.

Autrement dit, cette informatisation engendre la nécessité de structurer les données et de

modéliser l’organisation, pour mettre à disposition tout ou partie des informations nécessaires

aux activités des utilisateurs et faciliter les recherches ponctuelles. L’unicité des informations

ainsi que la connexion de ces dernières entre elles, offrent la possibilité d’étudier d’impact de

toutes modifications apportées et garantissent la traçabilité de ces dernières. De plus,

l’utilisation d’un cadre formel identique doit également faciliter l’analyse et la comparaison

des produits/projets et par la même la mise en exergue des bonnes pratiques applicables à

nouveau dans le futur en fonction d’un certain nombre de caractéristiques.

Au regard de la diversité des intervenants durant le cycle de vie du produit, il est essentiel

d’éviter les ressaisies d’informations entre le PLM et les outils métiers. Cette infrastructure

modélisée en fonction du besoin actuel, doit être modulaire et interopérable voir interactif

avec les différents logiciels utilisés et le système d’information de l’entreprise pour garantir

l’utilisation et l’utilité du PLM [Dutta, 05].

Finalement, le PLM représente qu’un élément du système d’information des entreprises

industrielles et peut être considéré comme l’ERP de la conception des produits. Il a pour rôle

de centraliser et d’organiser toutes les formes d’informations concernant le produit, dont il

assure la sécurité, la cohérence et l’accessibilité. Les limites du PLM ne correspondent pas

Annexes

Page 220

aux frontières de l’entreprise, mais à l’ensemble de l’environnement du produit. La gestion

dynamique de ces informations contribue à la structuration des activités concourant aux

différentes phases du cycle de vie et, par le suivi d’exécution des projets, instaure une

collaboration effective des équipes.

1.3. Comparaison de ces deux outils phares pour les industriels

Finalement, l’ERP et le PLM sont les deux outils de gestion intégrée les plus prisés par

le monde industriel. Leurs implémentations et leurs utilisations croissantes par les entreprises,

quelques soient leur domaine d’activités et la taille de leur structure, reflètent un besoin de

structuration, d’uniformisation et de transparence des flux informationnel et transactionnel

pour répondre aux contraintes de traçabilité réglementaire mais également pour faciliter la

gestion globale de l’entreprise. En effet, le premier, l’ERP, privilégie l’aspect organisationnel

de la structure en adoptant une approche transactionnelle tandis que le second un aspect

informationnel selon une approche collaborative. Selon la stratégie de l’entreprise et les

moyens mis en place, cette dernière a tendance à mettre en exergue un des deux modes de

fonctionnement en présence l’un permettant de gérer le cycle de vie des ressources et des

ordres, tandis que l’autre le cycle de vie des produits/projets en se basant sur les données

techniques et les flux (Figure 57).

Figure 57. Complémentarité de l’ERP et du PLM

Ces deux méthodes ne sont pas antinomiques, bien au contraire, ils sont

complémentaires en se concentrant soit sur la production soit sur l’innovation & la

conception. Ce centrage implique une utilisation différente des données recueillies. D’un côté,

les aspects transactionnels de l’ERP engendrent l’exploitation des données immédiates pour

Annexes

Page 221

gérer la production tandis que les aspects informationnels du PLM créent une base de

connaissance itérative nécessaire à la réutilisation et l’amélioration. Ces différences font que

l’objectif de l’ERP est de maintenir un état stable pour maximiser les profits alors que le PLM

est de gérer les changements et les environnements dynamiques pour optimiser la conception.

Pour répondre aux besoins de pilotage et de traçabilité, les industriels se tournent

majoritairement vers l’informatisation. Au regard de la description de ces deux outils, ils

permettent non seulement de conserver la flexibilité et l’adaptabilité des entreprises à leur

environnement mais surtout de maximiser leurs profits. C’est pourquoi ces deux outils

présentent, individuellement et/ou associativement, un fort attrait pour les industriels en quête

d’uniformisation, fédération et optimisation de leur processus de gestion incitant l’acquisition

et l’implémentation d’un logiciel de gestion.

Annexes

Page 222

Annexe 2. Processus de déploiement d’une solution PLM en PMI/PME [Bissay, 10]

La mise en œuvre d'une infrastructure autour du PLM est un projet global du SI qui

s'inscrit dans une logique de long terme. Aussi, tout projet de déploiement d'un système PLM

nécessite de maîtriser les points suivants :

- les processus métiers et les refontes éventuelles ;

- les processus fonctionnels ;

- les migrations de données ;

- l'intégration globale avec les autres composantes du SI (comme l'ERP) ;

- la conduite de changement ;

- les supports et la formation.

Dans les projets autour des PLM, deux grandes orientations existent. Il y a les projets qui

nécessitent de nombreux développements de par l'histoire de l'entreprise, sa complexité, ou les

contraintes de son business. Ces projets demandent un fort accompagnement. L'autre

tendance, la plus forte actuellement, vise à déployer rapidement son projet, tout en limitant le

coût. Pour cela, on cherche en permanence l'adéquation entre les besoins, les gains espérés et

les fonctionnalités standards des progiciels. Les restrictions de budgets poussent même à

segmenter les projets en petits lots peu onéreux, au risque de dégrader l'objectif global

[Debaecker, 04]. Il apparaît important de se situer, et de savoir ce que l'on veut et comment le

projet s'intègre dans un projet d'entreprise.

2.1. Les étapes d'un projet PLM

Même s'il est difficile d'établir un ensemble d'étapes exhaustif, un projet de type PLM

se décompose en trois grandes phases :

- la phase d'avant-projet qui débute de l'idée de mettre en place un tel projet jusqu'au

choix de la solution,

- la phase de mise en œuvre qui va correspondre à l'adaptation du système choisi à

l'organisation de l'entreprise,

- La phase d'accompagnement et d'adaptation du système qui est une phase transversale

généralement incluse dans les deux précédentes et qui permet de garantir l'adéquation

et l'adaptation du système aux évolutions du contexte industriel de l'entreprise.

Dans cette section, nous définissons les principales caractéristiques de la mise en œuvre d'un

système d'information centré sur le cycle de vie des produits.

Annexes

Page 223

2.2. Méthodologie MPPI

2.2.1. Approche globale

Le déploiement d'un projet PLM est l'occasion pour une entreprise, même pour une

PME/PMI, de remettre à plat certaines méthodes de travail. A défaut, il implique une

formalisation de ce qui est actuellement en application dans l'entreprise. Face à ce constat,

nous avons bâti notre approche en faisant l'hypothèse que ce travail d'analyse est une source

information qui va permettre de faciliter la capitalisation du savoir-faire. Ainsi, la démarche

proposée est une approche combinée qui prend en compte la capitalisation du savoir-faire

pendant les réflexions menées lors de la mise en œuvre d'un projet PLM. Elle intègre deux

aspects complémentaires :

- Une approche globale centrée sur un processus de mise œuvre d'un système PLM en

PME/PMI. Ce processus métier reprend en partie les trois grandes phases définies à la

section précédente,

- Une étape d'analyse combinée avec une approche de la capitalisation des savoir-faire.

Figure 58. Principe de la méthode MPPI

La figure précédente (Figure 58) schématise l'approche proposée dans MPPI [Bissay et al.,

08a] [Bissay et al., 08b] [Bissay et al., 08c]. Ainsi, MPPI est structurée autour de deux

processus : le processus d'avant-projet et le processus de déploiement. Il est à noter que le

processus d'accompagnement et d'adaptation doit être considéré comme un sous-processus

transversal, inclus dans les deux premiers.

Annexes

Page 224

L'approche globale MPPI met en avant une modélisation globale du processus de mise

en œuvre d'un système d'information centré sur le produit. Comme le montre les figures

suivantes (Figure 59 et Figure 60), la définition d'un processus sous un formalisme BPMN

permet de prendre en compte l'ensemble des étapes et des caractéristiques d'un projet défini

dans la section précédente. L'intérêt du formalisme BPMN est double. Il permet de proposer

une modélisation avec des granularités différentes couplée avec une notation accessible dans

un contexte de PME/PMI. Par ailleurs, le cas échéant, cette modélisation peut être

transformée dans un environnement d'exécution (BPEL) grâce des mécanismes de

transformation.

Les sections suivantes présentent en détail les deux processus de MPPI, la partie concernant

plus spécifiquement la capitalisation étant définie au chapitre 5.

2.2.2. Processus d'avant-projet

Le processus d'avant-projet que nous proposons est défini dans le diagramme BPMN

de la Figure 59.

La définition du projet. Cette étape détermine l'intérêt du projet, décrit le but recherché, les

moyens pour y parvenir. Elle quantifie l'effort et les gains visés et donne un cadre global au

projet. Pour cela, il est nécessaire de faire un état des lieux du système d'information en place,

de l'organisation, des processus en lien avec le développement des produits. Ainsi, il s'agit de

répondre aux interrogations suivantes :

1. Les raisons du projet : en quoi le contexte externe et interne de l'entreprise incite à

utiliser une solution PLM ? Quelles sont les limites de mon système actuel ?

2. Les objectifs du projet : quelles sont les objectifs de ce projet (mise en place de

nouvelles méthodes de travail, amélioration d'un système existant) ? Quelles

informations sont gérées dans l'outil PLM ?

3. Le périmètre géographique du projet : quels sont les sites de production concernés par

le projet ? Quels services sont concernés dans le projet ?

4. Le périmètre budgétaire du projet

L'objectif de cette étape est de caractériser le contexte du projet, en accord avec les

orientations stratégiques de l'entreprise.

Annexes

Page 225

Figure 59. Diagramme BPMN du processus d'avant-projet

Annexes

Page 226

La rédaction du cahier des charges. La rédaction du cahier des charges synthétise les

besoins et l'état actuel du système d'information. Il permet donc d'étudier la situation afin de

proposer et de choisir la meilleure solution possible pour atteindre les objectifs globaux. Un

cahier des charges se structure généralement en plusieurs parties :

- positionnement et objectifs du projet,

- analyse et état des lieux du système d'informations actuel,

- définition des fonctionnalités : Il s'agit dans cette partie de préciser les attentes que l'on

a vis-à-vis du système cible. Il est nécessaire de dresser la liste des fonctions du

logiciel pour satisfaire le niveau de besoin attendu.

Choix d'une solution. Le processus de sélection d'un PLM nécessite plusieurs étapes :

- établissement d'une première sélection à partir des solutions du marché auprès

desquels un appel d'offre est lancé ;

- sélection sur les propositions faites et établissement d'une seconde liste restreinte ;

- proposition d'une maquette et des démonstrations des solutions en short list ;

- sélection finale, si possible à l'aide d'une grille de critères équilibrés selon les enjeux

recherchés.

Cette étape peut connaitre quelques modifications selon la taille de l'entreprise, et ce

notamment sur la durée et le détail des maquettes. Le choix d'une solution est une étape

cruciale du projet. Les critères techniques et de coûts sont ceux à qui l'on accorde le plus

d'importance. Cependant, il ne faut pas se cantonner uniquement à cette vision. Des critères

de pérennité, de proximité, de stratégie de l'éditeur sont à prendre en considération. Nous

proposons une grille (voir annexes) de comparaison détaillée et basée sur quatre critères

(fonctionnels, techniques, stratégiques, financiers).

2.2.3. Processus de déploiement

La définition du plan projet. La phase de définition du plan projet sert à déterminer

plusieurs éléments : l'équipe projet, le lotissement du projet ainsi que le planning. L'équipe

projet est constituée de personne interne à l'entreprise sur laquelle l'intégrateur pourra

s'appuyer pour identifier les besoins fonctionnels. On peut identifier dans cette équipe trois

rôles essentiels :

- le chef de projet : le chef de projet est responsable du projet dans le respect des

objectifs fixés ainsi que de l'application de la stratégie de conduite du changement

définie. Cette personne doit suffisamment bien connaitre le fonctionnement et

Annexes

Page 227

l'organisation de la société afin de choisir les actions de communication, de formation

et d'accompagnement les plus appropriées.

- le responsable organisationnel : Le responsable organisationnel doit être une personne

qui connaît bien l'organisation de l'entreprise. Il est nécessaire que ce dernier dispose

d'une crédibilité interne lui permettant d'imposer les choix de mise en œuvre qu'il

conseillera.

- le responsable technique : le responsable technique doit s'assurer du bon

fonctionnement du matériel et du logiciel ainsi que de la mise en place des mises à

niveau futures.

Dans le contexte d'une PME/PMI, le lotissement a pour objectif de définir comment le projet

peut être découpé et dans quel ordre peuvent être organisés ces différents lots suivant

différentes stratégies de lotissement :

- globale : un nouveau système pour tous et pour tous les projets. Cette stratégie est

particulièrement appropriée aux petites et moyennes entreprises mais reste difficile à

mettre en œuvre dans un grand groupe.

- par projet : L'ensemble des fonctionnalités sont développées, testées, puis validées sur

un projet avant d'être étendue au reste des projets.

- par fonctionnalités : Le projet débute sur un système avec des fonctionnalités réduites.

Après leur validation, d'autres fonctionnalités sont ajoutées.

- par services ou par site : Le système est mis en place pour un service ou un site de

production puis déployer au reste de la société, une fois validée.

La mise en œuvre. La mise en œuvre est une étape relativement longue qui comprend les

taches de spécification, de développement spécifique et de test. Concernant les spécifications,

elles doivent traduire le fonctionnement de l'entreprise ainsi que les besoins des utilisateurs.

Ces spécifications sont rédigées, à la suite d'ateliers réalisés avec l'équipe projet mis en place

au sein de la société. Elles sont donc intimement liées aux fonctionnalités du système et à ses

outils de description, notamment pour le modèle de données, les droits d'accès, la

personnalisation de l'interface utilisateur, les processus.

Annexes

Page 228

Figure 60. Diagramme BPMN du processus de déploiement

Annexes

Page 229

Comme indiqué sur le diagramme BPMN (Figure 60), la définition du modèle de données et

l'intégration dans le système PLM des connaissances en lien avec le développement du

produit est détaillée au sein du module MPPI-KI et présenté au chapitre 5

2.2.4. L'accompagnement et l'adaptation

Dans le découpage proposé, les activités liées à l'accompagnement et à l'adaptation,

sont des tâches cycliques et transversales. Dans cette section nous présenterons les aspects liés

à la gestion du changement et à la reprise de l'existant.

La gestion du changement. De nombreux projets PLM n'atteignent pas leurs objectifs,

principalement pour des raisons non techniques. Les problématiques de résistance au

changement ne vont pas en décroissant au fur et à mesure que les technologies s'améliorent.

Les employés d'une organisation partagent des valeurs communes, une culture d'entreprise et

des acquis sociaux pouvant être remis en question par la modification de l'organisation de

l'entreprise ou l'introduction d'un nouvel outil informatique. La conduite du changement doit

prendre en compte ces valeurs et mettre en place un dispositif d'écoute permettant d'identifier

les craintes collectives afin, le cas échéant, de communiquer sur la stabilité des valeurs et

acquis actuels (Figure 61fig. 4.4).

Figure 61. Phase de gestion du changement [Debaecker, 04]

Annexes

Page 230

Le déploiement d'une solution PLM dans une entreprise, engendre un changement. Ce

changement des modes de travail ne peut se faire sans l'implication et l'adhésion de l'ensemble

des acteurs de l'entreprise. Dans la conduite du changement plusieurs aspects sont à prendre

en compte :

- la communication. La communication a pour objectif de faire circuler les informations

afin de promouvoir le projet, mais aussi d'écouter et de prendre en considération les

remarques qui pourront être faites. Les utilisateurs doivent comprendre les enjeux du

projet et le rôle de chacun.

- la formation. La formation va servir à expliquer et rendre opérationnel les employés

sur le nouvel outil.

- la documentation. La documentation utilisateur est très importante dans ce type de

projet. Elle va consister à décrire de manière détaillée les actions pour utiliser l'outil

nécessaire à l'obtention d'un résultat.

- l'accompagnement sur le terrain. Il est important après la phase de mise en production,

que les utilisateurs se sentent accompagnés : les assister lors des problèmes qu'ils

peuvent rencontrer, répondre à leurs interrogations et faire remonter les éventuels

dysfonctionnements en production.

La reprise de l'existant. La reprise de l'existant est une question importante dans un projet de

déploiement d'un système PLM. En effet, pour faciliter l'appropriation d'un nouvel outil, il est

important de mettre à disposition des utilisateurs, du contenu. Mais comment procéder : en

une seule fois ou par itérations ? Cette question doit être traitée au cas par cas, en prenant en

compte les spécificités de chaque organisation et le volume des données à migrer. Dans cette

phase de reprise des données, le recensement des données à migrer est dans la plupart des cas

un compromis entre la nécessité de mettre du contenu à disposition et la tâche de migration.

En effet, le temps nécessaire aux tâches de migration est souvent sous-estimé car il arrive que

les données soit éparpillées ou que des informations soient manquantes. Il est par ailleurs

important de planifier cette reprise car elle nécessite des ressources parfois non négligeables

selon l'étendue de la reprise.

Intégration globale au SI. Dans le cadre du déploiement d'un système PLM, les questions

d'intégration globale au SI doivent être abordées au plus tôt. En effet, quel que soit la taille de

l'entreprise ou son domaine d'activité, le besoin de garantir une continuité du flux

Annexes

Page 231

informationnel implique une analyse de l'intégration fonctionnelle et technologique du PLM

avec les autres composantes du SI. Le cas le plus classique reste l'intégration avec l'ERP.

Annexes

Page 233

Annexe 3. Adapter l’outil aux entreprises

5.1. Simplifier le modèle de données et l’IHM

Selon les applications, le modèle de données permet de personnaliser la sémantique

utilisée dans l’application, les différents contenus, le comportement pour chacun de ces

contenus. Dans le cas de LASCOM, les efforts ont portés tant sur la simplification des termes

employés dans le socle de l’application, afin que tout un chacun comprenne les actions

réalisées et non plus uniquement des experts en la matière, que sur l’uniformisation et la

généricité de la sémantique utilisée dans les différentes fonctionnalités métiers ajoutées, pour

que l’utilisateur connaisse le résultat attendu même sans formation, que dans le contenu, pour

limiter le niveau de personnalisation nécessaire à son utilisation. Dans le même esprit, les

efforts ont également portés sur la définition des différents contenus et processus pré-

paramétrés en utilisant des termes métiers et au maximum génériques. Les aspects visuels ont

également été revus pour permettre une aisance de navigation calqués sur les produits

courants actuels de type explorateur internet. Tous ces changements ont permis de mettre en

exergue que les différentes branches de métiers visés par LASCOM n’était peut être pas si

différentes, et que la maintenance des trois bases différentes étaient coûteuse et apportaient

une baisse de dynamisme. En effet, comme nous l’avons vu l’offre repose sur un même socle

composé de quatre briques élémentaires, l’apport pour chacune des branches consistaient à

accroître tout ou partie de ces briques afin d’offrir une couverture fonctionnelle adéquate aux

besoins du métier. Ces extensions entrainaient des besoins de maintenance sur le socle

commun, puis sur chacune des briques enrichies par vertical, autrement dit il existait toujours

un décalage important entre les différentes versions des applications et il était souvent difficile

de faire profiter tous les verticaux des évolutions d’un autre vertical. Après étude des

différentes solutions proposés par verticaux et entre verticaux, et grâce à la simplification de

la sémantique et aux améliorations technologiques, LASCOM a cherché aujourd’hui dans sa

nouvelle version 2012 à élargir et de renforcer le socle commun, en implémentant au

maximum l’ensemble des évolutions nécessaire pour chacun des métiers mais également de

simplifier la navigation d’un point de vue utilisateur. Ainsi pour composer une nouvelle

application verticalisée, le socle serait toujours identique par contre le modèle de données sera

celui du métier auquel s’ajouterait un certain nombre de plug-in métiers et/ou standards.

L’objectif restant d’accélérer la mise en place, tant en simplifiant l’implémentation grâce à

son mode de conception que d’utilisation par la simplification de l’IHM, mais en offrant un

niveau de paramétrage accru et un catalogue de fonctionnalités enrichies grâce aux trois

Annexes

Page 234

verticaux, le tout en limitant les coûts de maintenance. Avec cette nouvelle offre plus

générique, certains aspects longtemps délaissés vont pouvoir reprendre leur place et s’inscrire

dans une offre plus performante et plus proche des besoins clients.

5.2. Systématiser l’intérêt du reporting

En effet jusque là, les différentes fonctionnalités ou processus demandés

spécifiquement par les clients devaient être créé de toutes pièces. Les spécifications étaient

principalement orientées sur les aspects fonctionnels et techniques. Le pilotage de l’activité

était donc délaissé au profit de l’émergence d’une solution technique adaptée au besoin

spécifique. Aujourd’hui avec la verticalisation « nouvelle » génération, il est essentiel de ne

pas avoir à recréer de toutes pièces des fonctionnalités, mais de se consacrer plus

spécifiquement à ses éléments de pilotage propre en fonction des indicateurs clés utilisés dans

l’entreprise. L’objectif des nouveaux verticaux est de proposer une première base de rapport,

qui doit permettre le suivi minimum des éléments contenus dans l’application, mais surtout de

servir de base à la création d’outil de pilotage. En effet, les outils de pilotage ne peuvent pas

être considérer comme un élément générique ou paramétrable, car la base même de leur

élaboration repose sur l’organisation de l’entreprise et de ses activités. Autrement dit, pour

permettre la création d’outil de pilotage en lien ou intégrant pleinement l’application, il est

nécessaire d’appréhender le projet non seulement au regard des besoins technico-fonctionnel,

mais dans son ensemble en intégrant l’organisation de l’entreprise et des activités. Or jusqu’à

présent, le temps dédié à la spécification n’était pas suffisant pour définir l’application

proprement dit et les éléments de pilotage sans accroître considérablement le coût de

l’investissement. Aujourd’hui en utilisant un vertical pré-paramétré, il est possible de

proposer décemment d’utiliser le vertical sans trop de modification et de consacrer du temps à

la création d’élément d’aide à la décision adaptée à l’entreprise.

Beaucoup de fonctionnalité et de module ont été créé au fur et à mesure des demandes des

utilisateurs, et au regard des problématiques de délais et de cout énoncé précédemment, ces

fonctionnalités ont rarement été couplés avec du reporting permettant le suivi et le pilotage

des actions associés. Dans le cadre de la nouvelle génération de verticalisation, chacune des

fonctionnalités ainsi que le modèle de données proposé a été repensé pour pouvoir apporter un

premier niveau de pilotage. Aujourd’hui LASCOM répond à ces manques en ajoutant des

rapports et des tableaux de bord adaptés. L’application PLM ne doit pas être une simple

armoire à plan mais un réel outil de travail nécessitant par ce fait l’adjonction d’élément de

pilotage.

Annexes

Page 235

5.3. Élargir le cadre fonctionnel

Ajouter Sharepoint pour le coté informel et transverse : pour apporter des données sur

l’entreprise, des compétences utilisateurs pour l’élaboration d’un doc.

Opter pour une application de type PLM est un enjeu fort pour de nombreuses entreprises, en

effet pour apporter une amélioration des process, elle apporte avec elle un niveau de

formalisme et un cadrage plus important des opérations. En effet dans la démarche PLM le

suivi de la conception est l’enjeu principal nécessitant une certaine rigueur dans la

formalisation des diverses activités réalisées pour obtenir le produit. Or toute les activités, en

particulier les premières étapes de la création, ne suivent généralement pas un unique schéma

de conception. Or pour le paramétrage du logiciel, la géométrie variable est une structure très

difficile à prévoir. De plus, pour favoriser la création, la liberté est souvent un élément

essentiel, il faut parfois sortir des schémas classiques pour parvenir à l’innovation, moteur de

toutes les entreprises pour persister sur le marché mondial. En effet, lors des premières étapes

de conceptions diverses idées, difficilement formalisable, émergent, matures, sont

abandonnées, ressuscitent, stagnent, donnent naissances à d’autres idées… Toute cette

démarche est essentielle pour parvenir à trouver l’Idée. Mais son déroulement est fluctuante,

les besoins varient en fonction du projet initial, des personnes entrant dans le processus. Mais

toutes ces idées peuvent aussi être réutilisées ensuite pour trouver d’autres innovations, en

fonction des avancées certaines idées impossibles peuvent devenir possibles. De même la

démarche qui a permis de concevoir le nouveau produit peut également être source

d’inspiration pour un prochain projet (les personnes qui sont intervenues, les indicateurs

utilisés, les études de marchés réalisés…). Il est donc nécessaire de conserver tant les

différentes idées émises que le déroulement qui a permis d’aboutir au résultat.

Le problème des éditeurs se traduit donc par : comment laisser libre cours aux concepteurs

produit tout en utilisant un cadrage prédéfinis tel qu’un PLM ? Cette problématique semble

insoluble sauf si on opte pour la création d’une zone de « non-droit » ou tout un chacun peut

créer, modifier et supprimer à sa guise ses activités, leurs organisations, leurs déroulements...

La création d’une telle zone avec un tel niveau de flexibilité laissé à la porté des utilisateurs

semble difficilement envisageable dans une solution PLM et ne correspond pas forcément aux

attentes d’un PLM dans lequel les flux intégrés contribuent activement à la création d’un

produit. Pourtant le but parait assez clair et s’inscrit dans le mode opératoire de la conception,

son historisation, son suivi et sa réutilisation constitue une part importante de la mémoire de

l’entreprise et surtout un vecteur d’innovation future important. Une autre vision de cette

problématique est de considérer ces étapes comme de l’avant projet pouvant déboucher sur un

Annexes

Page 236

véritable projet ou pas. Dans ce cas, la solution peut être de compléter le PLM avec un autre

logiciel, qui gérerait les étapes d’avant projets et en lien avec le PLM pour déverser toutes les

informations nécessaire au lancement de projet effectif le cas échéant. L’association de ces

deux logiciels apporterait d’une part la flexibilité et la liberté nécessaire à l’innovation, et

d’autre part un cadre pour les projets, le tout en conservant l’historique dans chacun des cas.

L’utilisation de deux logiciels totalement indépendants est aussi possible, mais entraine une

perte d’information et de temps, due à la ressaisie et à l’import des données clés, important.

En effet les avantages de lier les deux logiciels sont nombreux selon le degré d’intégration

entre les deux logiciels. Idéalement l’imbrication doit permettre au minimum de naviguer de

l’un vers l’autre de manière transparente et de récupérer les données contenues dans l’un ou

l’autre des logiciels rapidement sans développement spécifique. Sur le marché actuel, de

nombreux outils répondent aux critères nécessaire à la gestion des avant projets et favoriser

l’innovation. Le choix pour les éditeurs de PLM est d’autant plus complexe. Les critères sont

généralement orientés sur la pérennité du logiciel tiers et sur la complexité et la maintenabilité

de cet interfaçage. Dans le cas de LASCOM, la stratégie fut d’opter pour le logiciel

Sharepoint pour sa pérennité, sa déclinaison de solutions (gratuite et payante), mais également

pour sa notoriété chez ses clients actuels. D’un point de vue fonctionnel, ce choix est

également important, car il offre la possibilité d’entrer dans les portails entreprise, offrant

ainsi une plus forte visibilité et une marge importante d’élargissement fonctionnel tout en

restant dans son cœur de métier mais en utilisant les fonctionnalités et les informations

contenues dans le portail.

Finalement, l’association de ces deux logiciels permet d’une part de répondre aux besoins de

la conception et ce durant toutes ces phases, élargissant ainsi le cadre fonctionnel direct du

PLM en apportant une solution dédiée aux différents stades de la conception de manière

transparente pour l’utilisateur. D’autre part, la complémentarité des deux solutions offre une

source importante de solutions simples pour répondre aux plus près des besoins actuels ou

futurs que la nature soit formelle ou informelle, nécessitant un lien ou pas avec d’autres outils.

Finalement, cette solution apporte une nouvelle dimension aux PLM grâce à l’ouverture sur le

monde des données informelles, mais également sur l’ensemble de l’entreprise à travers son

portail.

5.4. Apporter plus aux acteur : KPI et tableaux de bord

Le suivi et l’organisation globale ne sont pas les seuls gages de la réussite d’une

entreprise, mais ils permettent l’anticipation et la planification. Pour cela, les objectifs de

Annexes

Page 237

l’entreprise doivent être décomposés en éléments plus concrets et détaillés, de sorte que des

plans tactiques puissent être conçus (budgets), des responsabilités affectées et des mesures

effectuées au cours du temps. Par conséquent les objectifs stratégiques sont analysés pour

déterminer les facteurs qui affectent leur réalisation. Des indicateurs mesurables sont alors

déclinés pour l’entreprise, l’activité, le produit, la personne. Si l’ensemble des

acteurs/personnes parviennent à respecter leurs objectifs à courtes échéances, l’entreprise elle-

même augmente ces chances de parvenir à son but à longue terme. Dans tous les cas, les

indicateurs doivent apporter une aide à la planification, l’identification, la décision et l’action

suffisamment en amont temporellement pour ne pas mettre en péril la stratégie de l’entreprise.

Cette déclinaison doit être prise en compte également lors de l’implémentation d’un

gestionnaire de flux. Dans le cadre du PLM, il est important de dissocier les utilisateurs actifs

ou utilisateurs passifs. Le premier type d’utilisateurs correspondent aux personnes intégrant

de l’information et réalisant des actions, à l’opposé des passifs, qui consultent et pilotent les

activités de l’entreprise. Dans le cahier des charges, les besoins énoncés par les clients sont

généralement orientés sous un angle fonctionnel, c'est-à-dire pour les actifs, il décrit

précisément les éléments nécessaire d’un point de vue produit et non pas organisationnel,

autrement dit, par exemple les aspects pilotages ne sont jamais évoqués. Or dans un logiciel

de gestion de flux, le produit et les informations le concernant sont aussi important que le

respect des procédures et des délais. Chaque profil doit trouver les informations nécessaires à

la réalisation de leur activité. Le pilotage ne doit pas être sous estimé et doit être pris en

compte au plus tôt dans la conception ou le paramétrage de l’application. En effet, ce besoin

doit être considéré en parallèle, car il impacte d’un point de vue conception autant du modèle

de donnée que les besoins fonctionnels, que d’un point de vue process pour son bon

déroulement. Pour obtenir des indicateurs utilisables, il est nécessaire d’avoir toutes les

informations nécessaires au sein du logiciel tant sur les documents que l’on souhaite suivre

que sur les processus utilisés et leur déroulement.

Jusqu’à présent, le coût de conception des applications étaient trop important pour prendre en

compte ces aspects. Des fonctionnalités d’extractions étaient à la disposition des clients pour

qu’ils puissent concevoir eux même des rapports, voire des tableaux de bord a posteriori du

déploiement de l’application. Cette élaboration était souvent laborieuse ou permettait

d’aboutir qu’à des résultats simplistes. En effet, les données nécessaires à l’obtention

d’indicateur de performance n’étaient pas présents physiquement dans les exports par

exemple, ou simplement n’avaient pas été prévu lors de la conception de l’application.

Aujourd’hui, LASCOM veut sensibiliser ses clients à cette problématique en amont, même si

Annexes

Page 238

l’élaboration n’est pas prévue dans le projet. La réflexion sur les différents indicateurs

nécessaires doit être réalisée avant ou pendant les spécifications au plus tard, pour vérifier la

cohérence et la concordance entre le besoin et les futures informations contenues dans

l’application dans le but de concevoir des indicateurs beaucoup plus performant, automatique

donc consultable à tout moment. En effet, plus les indicateurs sont simples à consulter plus le

niveau de pilotage sera important, par exemple, si l’utilisateur est obligé de faire plusieurs

extractions pour croiser les informations afin d’aboutir à son indicateur, il est fort probable

qu’il le consultera qu’occasionnellement, or si ce dernier est fourni automatiquement ou qu’il

nécessite qu’une seule extraction, le pourcentage de consultation et donc d’utilisation sera

d’autant plus important. Or si la fréquence du suivi est importante, la moindre dérive sera

constaté rapidement et corrigeable plus facilement.

En effet, la mise en place d’indicateurs de performance est cruciale et doit être intégrée au

logiciel PLM pour permettre non seulement d’informer l’acteur sur son positionnement par

rapport à ses objectifs personnelles, mais surtout de faciliter la prise de décision, tant d’un

point de vue organisationnel (les plannings, les affectations de ressources, les actions…) que

d’un point de vue technique (méthodologie, décision …), pour atteindre l’objectif en

respectant les délais et les coûts en se basant sur les données concrètes recensées dans

l’application. Grâce à une approche ascendante dans la réflexion et la mise au point de tableau

de bord, une cohérence de la structure organisationnelle doit apparaitre. Autrement dit, les

indicateurs du niveau N+1 doivent être basés sur les X résultats du niveau N associés aux

dépendances managériales. Cette approche doit permettre à la fois de rapprocher les décisions

au plus près du terrain, là où l’action est encore possible, de vérifier la cohérence de

l’organisation et/ou la bonne circulation des flux, en toute cohérence avec la stratégie globale

de l’entreprise.

Outre la difficulté de sensibiliser chacun des acteurs sur l’intérêt d’atteindre ses objectifs, la

mise en place d’un outil flexible et adapté à tous est un réel défi. Les outils métiers sont

rarement appropriés pour répondre aux besoins spécifiques de chaque acteur, qui sont souvent

propres à chacun d’eux et peuvent évoluer dans le temps. La limitation des budgets pour les

projets ne touchant pas directement la productivité et le manque de visibilité sur le ROI direct

de ce type d’investissement accentuent le degré de difficulté et freinent la mise en place de

tableaux de bord dédiés à chaque acteur. Or si les données nécessaires à leur réalisation sont

accessibles, la mise en place de ce dernier peut être réalisés selon le budget et les outils

Annexes

Page 239

utilisés par les utilisateurs, de différentes façon soit par export dans Excel par exemple, soit au

sein même de l’application, soit à travers une application tiers tel un portail.

Annexes

Page 241

Annexe 4. PERSONNA

4.1. Quelques définitions

Un PERSONA, c’est un utilisateur-type (le fameux archétype), une représentation fictive des

utilisateurs cibles, qu’on peut utiliser pour fixer des priorités et guider nos décisions de

conception d’interface. Cette personne fictive se voit assigner une série d'attributs qui

enrichissent son profil pour mieux exprimer les caractéristiques du groupe cible. La

description d'une persona inclut le nom, le prénom, le genre, l'âge, les profils de

consommation dans différents secteurs, un mode de vie et bien d'autres attributs en fonction

du domaine étudié. Cette description est le fruit de recherches ou d'entrevues de clients

existants. Grâce à ces caractéristiques, les équipes de conception créent des scénarios

d'utilisation d'un produit ou d'un service tandis que les équipes commerciales définissent une

stratégie de positionnement, de promotion ou de distribution de ce même produit ou service.

Cette méthode est une technique de conception centrée Utilisateurs, initiée par Alan Cooper

en 1999. Cette méthode permet d’offrir une vision commune et partagée des utilisateurs d’un

service ou d’un produit, en insistant sur leurs buts, leurs attentes et leurs freins potentiels, et

en proposant un format des plus engageants. Grâce à la persona, les équipes donnent un

visage humain au groupe cible, ce qui permet de répondre aux multiples questions que posent

la conception, la promotion et la distribution d'un produit ou d'un service. Cette méthode est, à

ce jour, surtout utilisée pour la conception et l'amélioration de l'ergonomie de sites Web. Elle

étend cependant son périmètre d'influence bien au-delà des sites web pour pénétrer

l'ergonomie des produits de haute technologie, la stratégie de promotion, la création ou la

sélection de circuits de distribution vers les consommateurs.

4.2. La démarche

Du collaboratif AVANT TOUT… avec quelques ateliers de travail, pas mal

d’entretiens, et l’épluchage de diverses sources, pour recueillir l’ensemble de faits nécessaires

à la construction des PERSONAS. Une démarche en 3 temps :

1. PREPARER

2. CONSTRUIRE

3. COMMUNIQUER ET UTILISER…

4.2.1. Préparer

Le démarrage dont tout va dépendre. C’est planifier l’intervention, évangéliser dans

l’organisation et monter l’équipe chargée de construire les PERSONAS. C’est aussi, identifier

Annexes

Page 242

les sources d’informations potentielles. C’est enfin s’accorder avec l’équipe sur quelques

grandes catégories d’utilisateurs (pourquoi pas fondées sur les segments marketing

préalablement établis), puis conduire les entretiens pour chacune de ces catégories tout en

collectant en parallèle les données issues des autres sources, internes ou externes.

4.4.2. Construire

La phase la plus délicate. C’est analyser les données recueillies et les entretiens pour

établir une liste de faits et traiter ceux-ci pour établir les premiers squelettes de PERSONAS

en les distinguant en premier lieu par des BUTS, puis par les rôles, comportements &

attitudes. Il faut très vite veiller à distinguer les PERSONAS primaires (1à 3) dont les intérêts

doivent être servis en priorité, des PERSONAS secondaires. La seconde partie de la

construction consistera à donner naissance aux véritables PERSONAS, avec au minimum les

éléments suivants : Prénom, Titre / Rôle, Scénario (la Partie Storytelling qui permet de bien

rentrer dans le personnage et dans sa vie), Photo, Devise, Buts, Déclencheurs, Freins et

Fonctions recherchées. Il est essentiel à ce moment-là de valider les PERSONAS,

qualitativement (au sein de l’équipe, par des revues d’expert, avec des utilisateurs réels…) et

quantitativement (questionnaire).

4.2.3. Communiquer et Utiliser

C’est là que se joue toute la valeur des personas : c’est utiliser les PERSONAS sur le

projet pour construire l’expérience Utilisateur du produit et guider les choix de conception

ergonomique : ils seront de ce point de vue le fil rouge du projet. Plus largement, c’est

informer l’organisation de la naissance des PERSONAS (via le radiateur d’informations ou

carrément sous forme de Buzz) et introduire les PERSONAS dans les équipes. Enfin, il faudra

veiller, dans cette dernière phase, à gérer les évolutions puisque évidemment produits et

PERSONAS évolueront de concert.

4.2. Un exemple d’utilisation pas B. MEUNIER

« Dans l’un des projets sur lequel je travaille actuellement, je me suis assuré d’utiliser les

personas afin de mieux comprendre les besoins fonctionnels. Eh oui, c’est le A du A-B-C

mais pour certains, il est difficile de comprendre l’utilité des personas. J’en profite donc pour

vous exposer rapidement les bénéfices des premières étapes de l’utilisation des personas pour

un redesign web. »

Annexes

Page 243

Première rencontre. J’ouvre Mindjet, je prends un café et je discute avec la directrice

marketing. À la fin de cette rencontre, cinq personas ressortent clairement. On copie-colle

rapidement des images en noir et blancs et on les nomme : Julie, Cécile, Jonathan, Steeve et

Bianca. J’envoie le tout à ceux qui travaillent régulièrement avec le public et j’attends. Dès le

lendemain, déjà plusieurs commentaires se sont ajoutés dans le projet que je mets à la

http://www.mindjet.com/us/

Annexes

Page 244

disposition de tous sur Basecamp. Une petite analyse, une simple mise à jour et hop, j’envoie

le tout à la directrice qui accepte rapidement.

La semaine suivante, j’ouvre une feuille de calcul sur Google Docs, je prends un autre café et

je mets à la place de Julie. Je me raconte une histoire sur ce que Julie fait sur le site web, ex. :

Elle ouvre son ordinateur, prends ses courriels, surf, trouve le site web, le consulte et le

sauvegarde dans ses favoris. Je sépare le tout en colonnes, j’ajoute une ligne et je me pose des

questions : Sait-elle combien de temps elle passera sur ce site ? Lit-elle tous ses courriels ?

Est-ce qu’elle trouve le contenu pertinent ? Est-elle une lectrice assidue de ce site web ? Quels

mots-clés a-t-elle utilisé pour trouver le site web ?

J’ajoute une troisième ligne, je prends la voix de Julie et j’énonce mes anxiétés, ex. : Ouvrir,

me connecter et lire mon courriel est déjà très long. Je reçois déjà beaucoup de spam et je

n’aime pas ça. Chaque fois que j’imprime une page, ça ne marche pas. Je n’aime pas donner

mes informations personnelles. Combien d’étapes dois-je remplir avant de soumettre ce

formulaire ?

Finalement, en bas de chaque colonne, j’énumère toutes les actions possibles et je les dépose

dans une cellule chacune. Les colonnes commencent à être de plus en plus imposantes. En

voici des exemples : Julie ouvre son courriel. Julie fait le ménage de ses courriels. Julie inscrit

l’adresse du site web. Julie recherche le site web sur un moteur de recherche. Julie envoie

l’article à une amie, etc.

http://www.basecamphq.com/

http://documents.google.com/

Annexes

Page 245

Annexes

Page 246

Je partage, tous commentent et à la fin de la semaine, nous avons tracé la carte des besoins et

des fonctions à mettre en place et ce, par ordre d’importance. Voilà donc un exemple simple,

efficace et très terre-à-terre qui prouve sans aucuns doutes, l’utilisation des personas.

Annexes

Page 247

Annexes

Page 248

Titre :

Amélioration du processus de déploiement d’une solution PLM par l’utilisation de cartes

heuristiques et de persona : cas LASCOM

Résumé : Cette thèse se place dans une dynamique de recherche d’amélioration des processus d’implémentation

et de déploiement de solutions logicielles de type PLM dans les entreprises. Nous proposons une

démarche complète de déploiement, centrée sur les acteurs de l’entreprise, qui s’appuie sur l’utilisation

de deux outils jusque là peu usités pour répondre à ce type de problématique : les cartes heuristiques et

les personas. Nous proposons d’utiliser la carte heuristique (ou map) comme support du projet et

moteur de la réflexion et de la communication dans le cadre d’un projet. La map offre une nouvelle

dimension à la définition de l’application et à la communication avec le client : une structure et une

organisation dynamiques et « immédiates ». Elle permet de mettre en évidence l’organisation et les

processus du client. Nous affinons notre proposition en travaillant aussi sur l’accompagnement et

l’implication du client en plaçant les futurs utilisateurs au centre de nos préoccupations. Nous

proposons une démarche complémentaire à la carte heuristique pour faire émerger des spécifications

directement par le client : les personas. La carte heuristique permet d’obtenir un support unique pour

suivre le cycle de vie du logiciel et sa construction repose sur l’approche descendante, tandis que

persona, centré sur les utilisateurs et leur environnement, se base sur une approche ascendante. Nous

obtenons ainsi une double exploration du système, ce qui offre une nouvelle dimension à la

modélisation d’entreprises en vue de l’implantation d’une solution logicielle. Cette proposition

améliore la pertinence et la qualité de l’analyse et de l’application.

Mots-clés : Solution PLM, cartes heuristiques, persona, modélisation de processus

Title: Improvement of the deployment process of a PLM solution by using mind map and

persona: the case of LASCOM

Abstract: This thesis concerns research on PLM tools. We especially focus here on improvement of the

deployment process of PLM tools in enterprises. We develop a methodology to help PLM software

developers to design and deploy a PLM solution among their customers. Our proposition, centered on

final users of PLM solution, is build around two unusual tools for enterprise modeling: mind map and

persona. Mind map is used as a communication element between developer and customer during the

entire project. Mind map is a common support to exchange data and encourage reflection. It offers a

new dynamic and a new dimension in the definition of the PLM solution for customer and developer

since it makes easier description of customer’s organization and process. We enrich our proposition

with persona. Persona completes mind map and permits an easier identification of users’ needs. Such a

tool allows us to be more efficient on accompaniment and implication of customer and users. Mind

map is a unique support for software developer and customer to follow life cycle of the software. It is

based on a top-down approach. Persona is centered on users in the company and on their environment.

It is a bottom-up approach. Association of these tools allows us obtaining a double exploration of the

system that provides a new dimension in enterprise modeling with a view to software deployment.

This proposition increase pertinence and quality of the users’ needs analysis and of customer

organization modeling. As a consequence it also improves design and deployment of the PLM solution

which is closed to the users’ needs and well adapted to the company’s organization and processes.

Keywords: PLM solutions, mind map, persona, process modelling

Laboratoire de l'Intégration du Matériau au Système – IMS, Université Bordeaux 1.

351, Cours de la Libération - 33405 Talence Cedex.

Tél. : +33 (0)5 56 37 15 00 Fax : +33 (0)5 56 37 15 45

http://www.ims-bordeaux.fr/IMS/pages/accueil.php

http://www.ims-bordeaux.fr/IMS/pages/accueil.php

Documents

Thèse - u-bordeaux.frori-oai.u-bordeaux1.fr/pdf/2012/BACZKOWSKI_MYLENE_2012.pdf · 2015. 1. 5. · Université Bordeaux 1 Les Sciences et les Technologies au service de l’Homme