View
4
Download
0
Category
Preview:
Citation preview
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.
Introduction générale
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
Introduction générale
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
Chapitre 1 Problématique
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
Chapitre 1 Problématique
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
Chapitre 1 Problématique
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
Chapitre 1 Problématique
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
Chapitre 1 Problématique
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
Chapitre 1 Problématique
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),
Chapitre 1 Problématique
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
Chapitre 1 Problématique
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
Chapitre 1 Problématique
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.
Chapitre 1 Problématique
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
Chapitre 1 Problématique
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
Chapitre 1 Problématique
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
Chapitre 1 Problématique
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
Chapitre 1 Problématique
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
Chapitre 1 Problématique
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
Chapitre 1 Problématique
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
Chapitre 1 Problématique
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.
Chapitre 1 Problématique
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é
Chapitre 1 Problématique
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’à
Chapitre 1 Problématique
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.
Chapitre 1 Problématique
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
Chapitre 1 Problématique
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
Chapitre 2 Déploiement d’une solution PLM
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
Chapitre 2 Déploiement d’une solution PLM
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
Chapitre 2 Déploiement d’une solution PLM
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
Chapitre 2 Déploiement d’une solution PLM
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,
Chapitre 2 Déploiement d’une solution PLM
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 »,
Chapitre 2 Déploiement d’une solution PLM
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)
Chapitre 2 Déploiement d’une solution PLM
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
Chapitre 2 Déploiement d’une solution PLM
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
Chapitre 2 Déploiement d’une solution PLM
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
Chapitre 2 Déploiement d’une solution PLM
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
Chapitre 2 Déploiement d’une solution PLM
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
Chapitre 2 Déploiement d’une solution PLM
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,
Chapitre 2 Déploiement d’une solution PLM
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].
Chapitre 2 Déploiement d’une solution PLM
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.
Chapitre 2 Déploiement d’une solution PLM
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é.
Chapitre 2 Déploiement d’une solution PLM
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.
Chapitre 2 Déploiement d’une solution PLM
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
Chapitre 2 Déploiement d’une solution PLM
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
Chapitre 2 Déploiement d’une solution PLM
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.
Chapitre 2 Déploiement d’une solution PLM
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
Chapitre 2 Déploiement d’une solution PLM
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
Chapitre 2 Déploiement d’une solution PLM
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
Chapitre 2 Déploiement d’une solution PLM
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
Chapitre 2 Déploiement d’une solution PLM
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.
Chapitre 3 Analyse et amélioration du déploiement des solutions
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.
Chapitre 3 Analyse et amélioration du déploiement des solutions
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.
Chapitre 3 Analyse et amélioration du déploiement 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
Chapitre 3 Analyse et amélioration du déploiement des solutions
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,
Chapitre 3 Analyse et amélioration du déploiement des solutions
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
Chapitre 3 Analyse et amélioration du déploiement des solutions
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.
Chapitre 3 Analyse et amélioration du déploiement des solutions
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
Chapitre 3 Analyse et amélioration du déploiement des solutions
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.
Chapitre 3 Analyse et amélioration du déploiement des solutions
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
Chapitre 3 Analyse et amélioration du déploiement des solutions
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.
Chapitre 3 Analyse et amélioration du déploiement des solutions
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
Chapitre 3 Analyse et amélioration du déploiement des solutions
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
Chapitre 3 Analyse et amélioration du déploiement des solutions
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
Chapitre 3 Analyse et amélioration du déploiement des solutions
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
Chapitre 3 Analyse et amélioration du déploiement des solutions
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).
Chapitre 3 Analyse et amélioration du déploiement des solutions
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
Chapitre 3 Analyse et amélioration du déploiement des solutions
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.
Chapitre 3 Analyse et amélioration du déploiement des solutions
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
Chapitre 3 Analyse et amélioration du déploiement des solutions
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
Chapitre 3 Analyse et amélioration du déploiement des solutions
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
Chapitre 3 Analyse et amélioration du déploiement des solutions
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
Chapitre 3 Analyse et amélioration du déploiement des solutions
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
Chapitre 3 Analyse et amélioration du déploiement des solutions
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
Chapitre 3 Analyse et amélioration du déploiement des solutions
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
Chapitre 4 Adapter l’approche et le dialogue « client »
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.
Chapitre 4 Adapter l’approche et le dialogue « client »
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,
Chapitre 4 Adapter l’approche et le dialogue « client »
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
Chapitre 4 Adapter l’approche et le dialogue « client »
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
Chapitre 4 Adapter l’approche et le dialogue « client »
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
Chapitre 4 Adapter l’approche et le dialogue « client »
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.
Chapitre 4 Adapter l’approche et le dialogue « client »
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
Chapitre 4 Adapter l’approche et le dialogue « client »
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
Chapitre 4 Adapter l’approche et le dialogue « client »
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.
Chapitre 4 Adapter l’approche et le dialogue « client »
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
Chapitre 4 Adapter l’approche et le dialogue « client »
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
Chapitre 4 Adapter l’approche et le dialogue « client »
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
Chapitre 4 Adapter l’approche et le dialogue « client »
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
Chapitre 4 Adapter l’approche et le dialogue « client »
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
Chapitre 4 Adapter l’approche et le dialogue « client »
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,
Chapitre 4 Adapter l’approche et le dialogue « client »
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
Chapitre 4 Adapter l’approche et le dialogue « client »
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.
Chapitre 4 Adapter l’approche et le dialogue « client »
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
Chapitre 4 Adapter l’approche et le dialogue « client »
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.
Chapitre 4 Adapter l’approche et le dialogue « client »
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
Chapitre 4 Adapter l’approche et le dialogue « client »
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.
Chapitre 4 Adapter l’approche et le dialogue « client »
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
Chapitre 4 Adapter l’approche et le dialogue « client »
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
Chapitre 4 Adapter l’approche et le dialogue « client »
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).
Chapitre 4 Adapter l’approche et le dialogue « client »
Page 122
Figure 16. Le contexte revu lors du projet
Chapitre 4 Adapter l’approche et le dialogue « client »
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
Chapitre 4 Adapter l’approche et le dialogue « client »
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.
Chapitre 4 Adapter l’approche et le dialogue « client »
Page 125
Figure 18. L’initialisation du suivi des interventions par l’avant vente
Chapitre 4 Adapter l’approche et le dialogue « client »
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).
Chapitre 4 Adapter l’approche et le dialogue « client »
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
Chapitre 4 Adapter l’approche et le dialogue « client »
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
Chapitre 4 Adapter l’approche et le dialogue « client »
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).
Chapitre 4 Adapter l’approche et le dialogue « client »
Page 130
Figure 23. La définition succincte de l’application vue par l’avant vente
Chapitre 4 Adapter l’approche et le dialogue « client »
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
Chapitre 4 Adapter l’approche et le dialogue « client »
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).
Chapitre 4 Adapter l’approche et le dialogue « client »
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.
Chapitre 4 Adapter l’approche et le dialogue « client »
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.
Chapitre 5 Analyse centrée sur les acteurs
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
Chapitre 5 Analyse centrée sur les acteurs
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.
Chapitre 5 Analyse centrée sur les acteurs
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
Chapitre 5 Analyse centrée sur les acteurs
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
Chapitre 5 Analyse centrée sur les acteurs
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,
Chapitre 5 Analyse centrée sur les acteurs
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
Chapitre 5 Analyse centrée sur les acteurs
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 :
Chapitre 5 Analyse centrée sur les acteurs
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.
Chapitre 5 Analyse centrée sur les acteurs
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).
Chapitre 5 Analyse centrée sur les acteurs
Page 145
Figure 28. Les questionnaires sources de la typologie des documents
Chapitre 5 Analyse centrée sur les acteurs
Page 146
Figure 29. L’utilisation vue par les utilisateurs
Chapitre 5 Analyse centrée sur les acteurs
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
Chapitre 5 Analyse centrée sur les acteurs
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
Chapitre 5 Analyse centrée sur les acteurs
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
Chapitre 5 Analyse centrée sur les acteurs
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
Chapitre 5 Analyse centrée sur les acteurs
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
Chapitre 5 Analyse centrée sur les acteurs
Page 152
Figure 34. Présenter le persona de l’utilisateur
Chapitre 5 Analyse centrée sur les acteurs
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.
Chapitre 5 Analyse centrée sur les acteurs
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),
Chapitre 5 Analyse centrée sur les acteurs
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
Chapitre 5 Analyse centrée sur les acteurs
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
Chapitre 5 Analyse centrée sur les acteurs
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
Chapitre 5 Analyse centrée sur les acteurs
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
Chapitre 5 Analyse centrée sur les acteurs
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).
Chapitre 5 Analyse centrée sur les acteurs
Page 160
Figure 37. Apport de persona au contexte de la carte heuristique
Chapitre 5 Analyse centrée sur les acteurs
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
Chapitre 6 Études de cas
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
Chapitre 6 Études de cas
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
Chapitre 6 Études de cas
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
Chapitre 6 Études de cas
Page 167
Figure 39. Extraits du Cahier Technique des Clauses Particulières (CCTP)
Chapitre 6 Études de cas
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)
Chapitre 6 Études de cas
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).
Chapitre 6 Études de cas
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.
Chapitre 6 Études de cas
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).
Chapitre 6 Études de cas
Page 172
Figure 43. Image de l’application envisagée par l’avant vente
Chapitre 6 Études de cas
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:
- la personne, de ses méthodes
- la complexité du projet et des
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
Chapitre 6 Études de cas
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 »
Chapitre 6 Études de cas
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
Chapitre 6 Études de cas
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
Chapitre 6 Études de cas
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.
Chapitre 6 Études de cas
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).
Chapitre 6 Études de cas
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.
Chapitre 6 Études de cas
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
Chapitre 6 Études de cas
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
Chapitre 6 Études de cas
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).
Chapitre 6 Études de cas
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
Analyser le contexte
---
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 +
solution plus performante
individuellement et plus
cohérente dans leur ensemble
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
Chapitre 6 Études de cas
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.
Chapitre 6 Études de cas
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:
- 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
+++
Ajout d'une description illustrée
des besoins clés par le biais
des personas mis à jour
Lister les solutions
+
dépend de:
- la personne, de ses méthodes
- la complexité du projet et des
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
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
- 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
++
solution plus performante
individuellement et plus
cohérente dans leur ensemble
Spécifications techniques
-
réalisé point par point et avec
peu de contexte +
solution plus performante
individuellement et plus
cohérente dans leur ensemble
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
Chapitre 6 Études de cas
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
Chapitre 6 Études de cas
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
Chapitre 6 Études de cas
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
Chapitre 6 Études de cas
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
Chapitre 6 Études de cas
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
Chapitre 6 Études de cas
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
Chapitre 6 Études de cas
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.
Chapitre 6 Études de cas
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.
Chapitre 6 Études de cas
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
Chapitre 6 Études de cas
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
Conclusion et Perspectives
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
Conclusion et Perspectives
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
Conclusion et Perspectives
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
Conclusion et Perspectives
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é.
Conclusion et Perspectives
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
Conclusion et Perspectives
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,
Conclusion et Perspectives
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.
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.
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.
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
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.
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
Recommended