Télécharger le document

Télécharger le document
P
rojets de systèmes
d’information et d’intranet
Expérimentations et repères
pour la conduite du changement
Sous la direction d’Odile ROCHER
Responsable du département Innovations
Technologiques et Travail
DOCUMENTS
ET
DOCUMENTS
ET
réseau
EDITIONS
ETUDES
ETUDES
réseau
EDITIONS
P
rojets de systèmes
d’information et d’intranet
Expérimentations et repères
pour la conduite du changement
Sous la direction d’Odile ROCHER
Responsable du département Innovations
Technologiques et Travail
Rédaction :
Dominique HÉRAUD et Jean-Baptiste STUCHLIK,
consultants du Cabinet GESTE
avec la participation de :
Pierre-Jean BENGHOZI, Directeur de recherche
au CNRS Centre de Recherche en Gestion
de l’École Polytechnique - CRG
Septembre 2003
réseau
EDITIONS
Préambule
Dans le cadre d’un appel d’offres proposé par son département Innovations Technologiques et Travail,
l’ANACT a lancé une étude pluridisciplinaire pour une approche intégrée des dimensions sociales, techniques et économiques dès le lancement des projets de systèmes d’information.
L’étude a pour objet d’éclairer les pratiques de conduite de ces projets afin de guider les différents acteurs,
les entreprises utilisatrices et les consultants qui les accompagnent. Élaboré autour d’une hypothèse fondamentale sur les représentations mentales qui se construisent autour des technologies de l’information et
de la communication (T.I.C.), le cahier des charges de l’étude oriente la recherche-action autour de deux
hypothèses :
• l’une, explicative des difficultés d’appropriation des T.I.C. dans les entreprises ; les technologies de l’information étant bien souvent pensées exclusivement comme des outils ayant capacité à résoudre les problèmes organisationnels et les projets d’investissements en technologies de l’information considérés
comme des projets d’investissements informatiques plutôt que des projets organisationnels.
• l’autre, prescriptive de démarches alternatives de conduites de projets T.I.C. pour guider les actions d’accompagnement du changement d’organisation. Les démarches standards d’implantation d’outils ne produisent pas toujours les effets attendus en termes de performance tant économique que sociale.
Comment développer l’appropriation individuelle et collective de ces nouveaux outils ?
Comment faire du projet d’implantation une occasion d’apprendre ? *
Sur la base de son expérience dans la conduite de projets de systèmes d’information et de deux accompagnements de projets en appui-observation au maître d’œuvre, l’étude réalisée par le Cabinet Geste, en collaboration avec le professeur Pierre-Jean BENGHOZI du centre de recherches en gestion de l’Ecole
Polytechnique, met en lumière les spécificités et difficultés rencontrées dans le processus d’implantation
ou de refonte de systèmes d’information ; en outre, elle propose des éléments de démarche et des repères
pour faciliter l’appropriation technique et organisationnelle.
* Odile Rocher - L’apprentissage au cœur de l’e-transformation - l’Expansion Management Review - mars 2003
R. Chevallet - O. Rocher - Agir sur la conduite des e-projets à paraître le 1er décembre 2003 co-éditions Anact/Liaisons sociales
2
TABLE DES
MATIÈRES
TA B L E
DES
M AT I È R E S
réseau
EDITIONS
Objectifs et contenu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 4
1re partie : Réflexion organisationnelle
et conduite de projet de systèmes d’information
. . . . . . p. 6
1.1. Mener en amont une réflexion sur l’organisation . . . . . . . . . . . . . . . . . p. 6
1.2. Une approche par processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 6
1.3. Faire coïncider « cible organisationnelle » et « cible technique » . . . . . p. 7
2e partie : Le déroulement type des projets
de systèmes d’information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 9
2.1. Quelle proposition de démarche ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 9
Phase de négociation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 10
Phase de mise en œuvre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 14
3e partie : Points de repère . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19
3.1. Les objectifs du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19
3.2. L’envergure du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 22
3.3. La prise en charge du projet : maîtrise d’ouvrage et maîtrise
d’œuvre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 23
3.4. La prise en compte des utilisateurs (dans l’entreprise,
les clients, etc.) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 24
3.5. L’évolution des métiers, des compétences, des conditions de travail . p. 24
3.6. La « boîte à outils » (infrastructure, modélisation, pilotage,
plan qualité). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 25
Le diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 25
Les bases documentaires. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 25
Le plan qualité projet (PQP) : « un qui fait quoi » pour le projet . . . . . . . . . p. 26
Les matrices de responsabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 27
Les listes de diffusion : projet_tic@entreprise.com. . . . . . . . . . . . . . . . . . . . p. 27
En conclusion... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 28
3
réseau
EDITIONS
Objectifs et contenu
La conduite du changement organisationnel en lien avec les technologies de l’information et de la communication est une question récurrente et dont les problématiques sont sans cesse renouvelées par l’évolution technologique, organisationnelle et sociale.
Sous le vocable de NTIC ou T.I.C., il est aujourd’hui difficile de distinguer les frontières entre les
différentes technologies (Internet et extranet, systèmes de gestion et workflow, SGBD et data warehouse, place de marché et sites marchand, groupware, messagerie et bureautique communicante, système
d’aide à la décision, infocentre, etc...) qui exploitent massivement, mais avec une combinaison très large,
les ressources des réseaux et des progiciels.
La difficulté de caractériser un projet NTIC par une technique ou un produit informatique relève du fait
que ces technologies s’organisent et s’entrelacent en « système »1. Le fonctionnement en système des
divers composants qui couvrent un grand nombre de fonctions de l’entreprise mettent en jeu aujourd’hui
un nombre illimité de relations : il ne s’agit plus de considérer uniquement la relation entre l’opérateur
salarié et le système d’informatique (l’interface homme machine -IHM) mais de prendre en compte l’ensemble utilisateurs (l’ensemble des salariés, les clients, les fournisseurs,...). La conduite du changement
organisationnel, si elle ne peut-être dissociée du projet technique, ne se pose pas dans les mêmes termes
suivant les projets :
• Beaucoup de projets informatiques actuels se situent plus dans une logique de cycle continu que de développement lourd et ponctuel avec un début et une fin
• les fortes disparités de volume et de durée des projets excluent de vouloir appliquer systématiquement
les mêmes méthodes
• on constate encore de fortes disparités dans les cultures d’entreprise, les pratiques de négociation sociale qui conditionnent largement les modes de conduite du changement, même si l’on retrouve presque
partout une plus forte maturité des utilisateurs vis à vis de ces technologies et des leurs implications
managériales.
Nous nous attacherons à voir quelles questions posent aujourd’hui la conduite du changement organisationnel dans les projets informatiques et quelles recommandations peut-on faire pour que les choix d’organisations soient bien posés en amont du projet lorsque les marges de manœuvre sont importantes2.
Ce guide est destiné aux différents acteurs qui seront concrètement aux prises avec le projet :
• les chefs de projet et les membres de l’équipe projet
• les futurs utilisateurs des outils systèmes d’information
• les représentants du personnel
• les responsables de DRH
1 - Pierre-Jean Benghozi « Technologie et organisation : hasard ou nécessité » - ICUST juin 2001
2 - Christophe Midler « L’auto qui n’existait pas », InterEditions, 1993
4
réseau
EDITIONS
Le guide est divisé en trois parties :
• dans la première partie, nous présentons les enjeux d’une réflexion organisationnelle en amont du projet, ou tout au moins à son lancement
• dans la deuxième partie, nous étudions sous forme d’une proposition de démarche quelles questions
pose la conduite des projets dans une vision « dynamique » où il n’est pas facile d’assurer une cohérence du projet dans son ensemble notamment du fait que les outils T.I.C. forment aujourd’hui des
« grappes » liant un système technique + organisation + procédures + processus de mise en œuvre3
• dans la troisième partie :
- le projet est vu selon plusieurs « points de repère » (sans considérer qu’il y a nécessairement un parcours
avec des points de passage obligés).
- A chaque « point de repère » est proposée une grille de questionnement adaptée au type de projet et
au type d’acteur ; sont également exposées des illustrations de réponses fournies dans des cas d’étude.
Les analyses et recommandations exprimées dans ce guide s’appuieront sur deux configurations de projet
que l’on rencontre fréquemment aujourd’hui dans les entreprises qui montrent que les conditions de mise
en œuvre sont nettement différentes :
1. Un premier type de projet qui porte sur une refonte du système d’information (S.I.) de production et de gestion avec l’objectif d’avoir une meilleure intégration entre les services et une ouverture du S.I. vers de nouveaux utilisateurs notamment les partenaires externes (les clients, les fournisseurs, différents prestataires). Ce projet résulte souvent d’une étude stratégique préalable qui débouche
sur un projet de changement de l’entreprise, portant à la fois sur l’organisation, les métiers et la procédures. La refonte du S.I. apparaît non seulement comme une nécessité (les programmes doivent être
adaptés) mais aussi comme une mise en mouvement de tous (symboliquement la nouvelle organisation
suppose un changement complet de l’outil informatique). L’entreprise observée est une structure associative dans le domaine du tourisme. Le projet est mené sur 2 années.
2. Le deuxième type de projet porte sur le développement de services intranet prenant place à côté
d’un système informatique existant. La dynamique de ces projets, fortement portée par des services
utilisateurs, vise à apporter des fonctionnalités que l’informatique en place ne peut facilement assurer,
soit pour des questions de contenu d’information (il s’agit de données plus ou moins structurées à visée
essentiellement informationnelle), soit que les modes de développement (coût, délai, méthodes) ne
paraissent pas adaptés. La dimension de l’organisation (quelle est la population concernée, fonctionnet-elle dans une logique de management ascendante/descendante ou s’agit-il de communications transversales ?) revêt-elle une dimension d’entreprise - de portail ou communautaire ? L’entreprise observée
est un établissement de crédit de taille moyenne et chaque développement intranet est réalisé en 6 mois
au maximum.
3 - P.J. Benghozi, « Technologie et organisation : hasard ou nécessité » - ICUST juin 2001
5
réseau
EDITIONS
1re partie
Réflexion organisationnelle
et conduite de projet de systèmes
d’information
1.1. Mener en amont une réflexion sur l’organisation
Dans la grande majorité des cas, il est nécessaire de mener une réflexion sur l’organisation en amont d’un
projet système d’information. Les entreprises ou organisations sont souvent tentées de déclarer : « l’organisation sera inchangée par le projet T.I.C. », mais cette intention est généralement illusoire. Les projets
informatiques ont toujours des impacts organisationnels, et il vaut donc mieux les anticiper.
De fait, les objectifs de ces projets touchent au travail, donc à son organisation :
• Un outil informatique destiné à automatiser des tâches existantes va entraîner un redéploiement des activités des salariés auparavant affectés à ces tâches : quelles nouvelles tâches va-t-on leur confier ? Faut-il
les reconvertir ?
• Un outil informatique permettant de nouveaux services à des clients ou à des usagers suppose d’affecter
des salariés dans cette nouvelle fonction : doit-on embaucher ? Comment les salariés de la nouvelle fonction vont-ils collaborer et se coordonner avec le reste de l’organisation ?
• La mise en place d’un outil de suivi de processus (outil de workflow) va modifier les manières de travailler : quels salariés sont concernés ? Comment évoluent leurs tâches ?
Dans la grande majorité des situations, il est donc utile de réfléchir à « l’organisation cible » avant de
mettre en route un projet T.I.C. Cependant, on trouve aussi des configurations où la réflexion organisationnelle en amont apporte peu, et peut être repoussée un peu plus tard dans le projet :
• Quand les possibilités techniques de l’outil sont mal connues : il est alors difficile de tracer les contours
de la future organisation, quand on ignore ce qu’apporteront vraiment les T.I.C. Dans ce cas, il vaut
mieux explorer les potentialités des outils, les expérimenter par des « pilotes », en tirer les conclusions
organisationnelles.
• Quand le projet T.I.C. repose plus sur des enjeux d’appropriation par les utilisateurs que sur des enjeux
techniques : il vaut parfois mieux mettre en place le projet sur un périmètre limité, mesurer le degré d’appropriation par les utilisateurs, avant de planifier un déploiement et la structure organisationnelle correspondante.
Si le travail de réflexion organisationnelle n’a pas été mené en amont, il est toujours possible de rattraper
le projet. Ce rattrapage doit s’effectuer au plus tôt, car des décisions techniques prises entre-temps risquent
de contraindre fortement la future organisation du travail.
1.2. Une approche par processus
Il est préconisé de réfléchir sur l’organisation selon une « approche par processus ». Cette démarche consiste à identifier tous les enchaînements d’activités qui aboutissent à des résultats tangibles pour un « client »
interne ou externe. Un processus peut faire intervenir plusieurs acteurs en plusieurs étapes.
Par exemple, on définit dans la relation de service des processus tels que :
• processus de création de dossier (de client)
• processus de prise de commande
• processus d’envoi / de livraison des commandes
• processus de gestion des réclamations
6
réseau
EDITIONS
Une bonne analyse de processus sépare les activités dans des processus relativement autonomes, et permet
de connaître les étapes problématiques dans la fourniture d’un bien ou d’un service, de repérer les ruptures
de charge, etc.
L’approche par processus
La norme ISO définit ainsi les processus : « Toute activité utilisant les ressources et gérée de manière à
permettre la transformation d’éléments d’entrée en éléments de sortie, peut être considérée comme un processus ». L’approche processus désigne l’application d’un système de processus au sein d’un organisme,
ainsi que l’identification, les interactions et le management de ces processus. Cette approche souligne
l’importance :
• De considérer et de satisfaire les exigences ;
• De considérer les processus en termes de valeur ajoutée ;
• De mesurer la performance et l’efficacité des processus ;
• D’améliorer en permanence des processus sur la base de mesures objectives.
Pour un projet T.I.C., il s’agit de réfléchir sur les processus concernés par le nouvel outil informatique, et
de construire les nouveaux processus. On aboutit ainsi à l’ensemble des « processus cibles », qui vont structurer « l’organisation cible. »
Articuler organisation et informatique dans un projet T.I.C.
1.3. Faire coïncider « cible organisationnelle » et « cible technique »
Les enjeux organisationnels d’un projet T.I.C. peuvent s’illustrer par la métaphore suivante :
Les deux cibles d’un projet T.I.C.
Une entreprise se trouve dans une situation de départ organisationnelle et technique ; par le projet
T.I.C., l’entreprise a pour objectif d’évoluer vers une situation « cible », qui va se décliner entre une
« cible organisationnelle » et une « cible technique.
À la fin du projet T.I.C., il faut que la cible organisationnelle et la cible technique coïncident.
Du fait des aléas survenant dans tout projet, les cibles technique et organisationnelle sont ajustées au fur
et à mesure du projet, et il est nécessaire de faire des points d’avancement « organisation / T.I.C. »
Ces points permettent de s’assurer qu’aucun décalage n’apparaît entre la cible organisationnelle et la cible
technique.
Le décalage « cible organisationnelle / cible technique »
Le décalage « cible organisationnelle / cible technique » est un dysfonctionnement classique des projets
T.I.C. En général, le projet cible a été défini au départ à partir d’une étude des besoins, d’un cahier des
charges, d’un schéma d’organisation cible. Un découpage « technique » par domaine de responsabilité a
été établi. La coordination d’ensemble est assurée par un pilotage des ressources et un planning de mise
en œuvre.
Les projets organisationnels et informatiques fonctionnent ensuite en parallèle avec leurs logiques et des
impératifs propres (principalement de réalisation, de délai et de coût pour le volet informatique, d’ajustement organisationnel, de négociation sociale, de formation pour l’autre partie). Au fil du temps, des
aléas interviennent et conduisent à des ajustements qui sont difficilement répercutés sur les autres projets.
7
réseau
EDITIONS
Le risque de dissociation entre projet technique et projet organisationnel
Le décalage survient généralement quand :
• La cible identifiée au départ n’a pas été suffisamment bien cernée. Dans le temps, cette cible a évolué
compte tenu de divers aléas.
• Le projet technique et le projet organisationnel sont menés de manière trop distincte, les ajustements sur
l’un des projets ne sont pas pris en compte par l’autre projet.
Une gestion de projet séparant technique et organisation peut fonctionner dans des contextes particuliers,
par exemple si les délais de mise en œuvre sont courts, et si la cible organisationnelle et technique est bien
maîtrisée. Cependant, dans les cas de fusion d’entreprise où les organisations et le S.I. sont imposés, le
risque d’un rejet par les utilisateurs subsiste.
8
2e partie
Le déroulement type des projets
de systèmes d’information
2.1. Quelle proposition de démarche ?
Implication prépondérante
de la maîtrise d’ouvrage
Par rapport à quelques-uns des écueils rappelés brièvement, il nous paraît important de distinguer les deux
étapes essentielles dans la conduite de projet que sont les phases de négociation et de réalisation. La proposition de démarche s’articulerait en 2 grandes phases et 6 étapes :
Implication prépondérante
de la maîtrise d’œuvre
réseau
EDITIONS
{
{
1re phase : négociation
1. Situer le projet dans son contexte (socio-économique
et organisationnel) et ses objectifs (étude d’opportunité)
2. Réaliser puis partager le diagnostic de faisabilité
3. Dimensionner le projet (partenariats internes autour
du projet) et définir l’organisation cible
2e phase : mise en œuvre
4. Mettre en place des partenariats avec les prestataires
externes
5. Intégrer les outils dans l’organisation
6. Déployer l’organisation
Il est généralement bénéfique de structurer formellement le projet en ces deux phases distinctes. Cela oblige en effet à :
• en interne, définir de manière précise les fonctions du futur outil (cahier des charges fonctionnel) ;
• en interne, prendre la mesure de l’investissement dans le projet ;
• en interne, prévoir l’organisation interne et externe du projet ;
• pour un prestataire externe, s’assurer que la mise en œuvre ne soit pas beaucoup plus coûteuse en ressources que ce qui avait été estimé avant la phase de conception.
En effet, si le projet est conçu d’un seul bloc, deux effets pervers peuvent survenir :
• qu’en interne un flou subsiste sur l’organisation du projet ;
• qu’en interne le cahier des charges soit imprécis au point que l’outil livré ne satisfasse pas aux attentes
initiales ;
• que si la conception et la réalisation doivent être confiées au même prestataire externe, celui-ci ait pour
intérêt d’influencer la conception de manière à ce que la mise en œuvre soit favorable.
9
réseau
EDITIONS
On observe que les entreprises ont tendance à faire intervenir des prestataires techniques trop tôt dans la
démarche de projet. La présence prématurée de tels prestataires peut fausser la réflexion interne à l’entreprise sur le projet, et aboutir à un résultat éloigné du but initialement prévu. Néanmoins, pour évaluer la
faisabilité du projet, l’entreprise peut avoir intérêt à se faire aider par un partenaire externe qui apportera
son expérience tirée de projets antérieurs.
Le fait que les technologies de l’information et de la communication apparaissent de plus en plus comme
des grappes conjuguant des systèmes techniques, de l’organisation, des procédures et des processus de mise
en œuvre introduit une difficulté supplémentaire de représentation de la cible lors de cette phase amont.
Si des réalisations expérimentales ont déjà été menées, la négociation peut tirer partie des résultats produits à condition qu’elles soient transposables dans le contexte considéré. La notion d’expérimentation est
difficilement envisageable lorsqu’il s’agit d’un projet de refonte globale du S.I. La phase de négociation
portera alors sur des données essentiellement prospectives, en s’appuyant sur des expériences dans d’autres
services de l’entreprise, voire dans d’autres entreprises.
Les phases de négociation et de réalisation peuvent être répétées dans un projet de grande ampleur en prévoyant des livraisons par étapes et lots qui sont testés et expérimentés afin de valider les réalisations informatiques mais aussi les choix d’organisation et de procédures. Cette option est malheureusement souvent
écartée pour des problèmes de délais alors que le cycle de réalisation des maquettes successives est par
ailleurs retenu. Il paraît possible de s’approcher du système cible si l’on prévoit dans la conduite de projet
de tester l’organisation et les procédures en même temps que le produit informatique. Ce concept est fréquemment retenu dans des structures de services (banques, assurances) qui veulent tester un nouveau
concept de service aux clients en créant un nombre limité d’agences pilotes qui vont mettre en œuvre une
organisation cible et au besoin de nouveaux outils informatiques.
A tout moment du projet, on peut réaliser des points « organisation », soit pour s’assurer de la bonne coordination entre cible technique et cible organisationnelle, soit pour « rattraper » le retard pris en réflexion
organisationnelle.
Exemple Financal
Les projets Intranet menés chez la société Financal ont montré qu’il était profitable de séparer contractuellement phase de négociation et phase de mise en œuvre.
Pour deux projets, la même société, PLUME, avait réalisé la conception, l’étude de faisabilité (phase de
négociation), et le développement (phase de mise en œuvre).
Dans le premier projet (Intranet juridique), un contrat avait été passé au forfait pour l’ensemble de la
mission. Les difficultés rencontrées ultérieurement dans le projet auraient sans doute pu être évitées si un
point plus formel sur l’organisation interne avait été fait entre Financal et PLUME entre les phases de
négociation et de de mise en œuvre.
Dans le 2e projet (Intranet comptable), il a été décidé de signer deux contrats séparés, l’un portant sur
la conception, l’autre sur la réalisation. Cela contribue à l’élimination des flous sur le projet, préjudiciables à son achèvement.
2.1.1. Phase de négociation
La phase de négociation porte sur le fait de partager un constat de départ qui amène à poser un certain
nombre d’objectifs. C’est de la responsabilité du maître d’ouvrage de formuler l’objectif du projet, la
« visée » de l’opération qu’il souhaite mettre en œuvre. Lorsque cette phase de négociation intervient en
amont du projet, elle favorise le partage et l’enrichissement de ce projet auprès de différents acteurs de l’entreprise :
• les utilisateurs / les salariés
• l’encadrement / les chefs de service / d’unité
• la Direction des Systèmes d’Information (DSI)
• la Direction des Ressources Humaines (DRH)
• la Direction
10
réseau
EDITIONS
Étape 1 : Contexte/objectifs et opportunités
Quel que soit le fait générateur de la décision (choix délibéré ou imposé par un tiers), déterminer en quoi
le projet peut être une opportunité, et confronter le plus en amont possible les objectifs du projet avec les
réalités de l’existant. Pour ce faire, décliner les objectifs d’amélioration, attendus du projet (issus d’une
étude d’opportunité) sur tous les champs :
• organisation
• métiers, compétences
• conditions de travail
• économique
Il est essentiel de mener une analyse stratégique du projet, au sens où l’entendent les sociologues de l’organisation4 :
• quels individus vont être touchés par le projet ?
• la position de ceux-ci va-t-elle s’en trouver menacée ?
• dans l’organisation, quels acteurs se trouveront renforcés par le projet ? Quels sont ceux qui en ressortiront affaiblis ?
Cette réflexion est indispensable, car on voit souvent des projets de systèmes d’information servir d’alibi
à des restructurations organisationnelles. Cette situation s’apparente alors à un double pari : même si le
projet aboutit techniquement, malgré l’opposition d’une partie des salariés, le systèmes d’information peut
parfaitement rester inutilisé par la suite, les salariés refusant de se l’approprier.
Exemple : Service Voyages du CCE du Crédit Siennois
Le service Voyages du Comité Central du Crédit Siennois, à la demande des élus, a réalisé un audit sur
le positionnement des centres de vacances qu’il gère et sur l’organisation de son service central de réservation de séjours et voyages adultes et enfants (une trentaine de personnes). Dans le souci d’améliorer les
prestations à personnel constant, plusieurs orientations organisationnelles ont été prises (rationalisation
des services de production, création d’un service marketing et qualité, fusion des secteurs adultes et
enfants). A la suite de cet audit stratégique, un audit informatique a montré que le S.I. actuel n’était
pas adapté à ces orientations et qu’il ne pourrait pas évoluer pour s’adapter à la nouvelle organisation,
ni offrir des services en ligne. Le projet informatique est venu en aval du plan stratégique.
Attendus en fin de cette étape :
• au lancement du projet, une vision claire des objectifs du projet, généralement formalisée par une note
stratégique
Cette note stratégique peut être rédigée soit par le porteur du projet à l’intention de la Direction Générale
pour justifier l’investissement, soit par la Direction Générale à destination du porteur de projet et des
futurs utilisateurs pour leur donner les orientations et la marche à suivre.
4 - Nous faisons notamment référence aux travaux de Michel Crozier.
11
réseau
EDITIONS
Étape 2 : Lancer le projet et commencer à mobiliser les acteurs par le diagnostic
de faisabilité
Les objectifs de cette étape sont :
• S’assurer de la faisabilité du projet et confirmer ou non le bien-fondé et les objectifs du projet.
• Organiser le diagnostic de faisabilité (choix, échantillon...)
• Réaliser le diagnostic de faisabilité :
- organisationnelle : process, activité, RH, compétences, usages des technologies de l’information et de
la communication
- sociale : RP, climat social, perception des projets passés et en cours, charge et conditions de travail
- économique : ressources humaines internes et externes à mobiliser), investissement matériel dépenses
d’investissement / dépenses de fonctionnement)
- technique : applications informatiques existantes, capacité et limites.
• Vérifier en quoi les solutions existantes sur le marché permettent de répondre au besoin et aux attentes.
Le diagnostic de faisabilité doit faire apparaître plusieurs scénarios précisant les objectifs et appréciant leur
degré de faisabilité. La phase de définition et de dimensionnement du projet intervient lors du choix du
scénario de mise en œuvre.
Selon la taille du projet T.I.C., cette phase est menée soit en interne, soit avec l’aide d’un ou plusieurs
consultants externes. A ce stade, il est nécessaire de disposer de compétences RH et d’une certaine expertise T.I.C. Il n’y a généralement pas besoin de faire intervenir des spécialistes techniques ou des développeurs, car seules les grandes options sur le projet sont étudiées.
Exemple de Financal
La société Financal avait décidé d’informatiser la documentation des procédures comptables. Une exploration des différentes solutions est réalisée, et aboutit à l’alternative suivante :
• acheter un progiciel du marché, qui consiste en un système d’information à implanter dans toute l’entreprise, d’un coût de l’ordre du demi million d’euros,
• sur la base d’un prototype, faire développer un outil spécifique au service comptable de Financal, plus
léger, sous forme d’Intranet, d’un coût de moins d’une centaine de milliers d’euros.
Sur les plans humain et financier, la première option représentait un investissement lourd.
Sur le plan technique, l’analyse montrait que la première option nécessitait des investissements en serveurs et postes de travail, entraînant une surcharge de travail et des délais plus longs. Un prototype réalisé rapidement montra la faisabilité dans un temps raisonnable de la 2e option.
Exemple : Service Voyages du comité central d’entreprise (CCE) du Crédit Siennois
Le S.I était basé sur deux logiciels différents, l’un dédié aux séjours des familles et adultes, l’autre aux
séjours enfants. La fusion de ces deux services nécessitait de revoir entièrement ces logiciels existants dont
la maintenance était par ailleurs coûteuse et difficile.
La société ARETE qui avait réalisé l’audit informatique a proposé une nouvelle solution basée sur un
progiciel de gestion des œuvres sociales des comités d’entreprise déjà implanté dans de nombreux autres
CE. À partir de ce noyau, elle proposait de développer des modules spécifiques pour le secteur de réservation des voyages, toute la partie du fichier client et la facturation existant déjà.
D’autres sociétés ont adressé des offres concurrentes à celle de ARETE, mais celle-ci a été retenue pour la
qualité de son offre et sa bonne connaissance des besoins du CCE du Crédit Siennois (à travers l’audit
préalable).
12
réseau
EDITIONS
Le fait de réaliser en quelque sorte « une étude de faisabilité » en demandant des offres à plusieurs fournisseurs est une pratique relativement courante. Si elle permet de comparer plusieurs solutions entre elles,
elle présente néanmoins plusieurs écueils :
• Le maître d’ouvrage a-t-il bien la maîtrise du cahier des charges ou bien a-t-il aussi sous-traité cette
partie ? Si c’est le cas, y-a-t-il indépendance entre ce prestataire et le futur maître d’œuvre.
• Différentes options technico-organisationnelles ont-elles été étudiées avant de transmettre le cahier des
charges à des fournisseurs ?
• Quelle est la qualité du cahier des charges ? Est-il suffisamment précis pour comparer les offres ?
Étape 3 - Dimensionner le projet et définir l’organisation cible
Cette étape est cruciale, car les fondements de la conception de l’outils y sont fixés. Certains choix décidés durant cette phase peuvent s’avérer irréversibles, et leur invalidation ultérieure peut mettre en péril le
projet. Cette étape doit comporter tous les éléments suivants :
• constitution de la structure du projet, à savoir comité de pilotage, équipe projet, groupes de travail, suivi
paritaire
• établissement du calendrier cadre
• plan des actions de communications associées au projet
• délimitation du périmètre fonctionnel du projet
• recueil et formalisation des besoins liés à l’évolution de l’organisation, à savoir guide d’expression des
besoins liés aux objectifs attendus du projet
• cahier des charges fonctionnel des outils cibles du projet
Un écueil fréquemment rencontré dans les projets de systèmes d’information est de constituer des
« groupes de travail alibi », c’est à dire de confier le travail de description et de spécification du futur système à des groupes de salariés sans vraie marge de manœuvre sur la cible. Il arrive aussi que les utilisateurs
désignés pour ces groupes de travail ne soient pas représentatifs de l’ensemble des utilisateurs. Par exemple,
on se débarrasse des salariés les moins efficaces (les « bras cassés) en les envoyant dans les groupes de travail (sic !) : le résultat est souvent désastreux. Sélectionner les salariés les plus performants pour spécifier
l’outil T.I.C. cible n’est pas non plus une stratégie payante : en effet, le système d’information final n’est
alors pas utilisable par tous.
Un travail de mise en cohérence et de consolidation est nécessaire entre des modèles d’analyse des besoins
qui sont souvent différents et les fonctions informatiques / ingénierie et organisation / RH.
Formalisation des besoins liés à la mise en place des outils (CDC fonctionnel)
Exemple : Une structure de projet adaptée au Service Voyages du CCE du Crédit Siennois
Même s’il s’agit d’une structure de taille limitée (30 personnes), l’organisation du projet est basée sur nette
dissociation entre une maîtrise d’ouvrage représentant le niveau politique (l’adjoint au secrétaire général du CCE chargé des voyages) et la maîtrise d’œuvre avec un chef de projet (le directeur de la structure voyages).
Le groupe de projet composé de ce directeur et des chefs de services.
L’ensemble des salariés est associé lors de la séance de présentation du lancement du projet.
Des petits groupes d’utilisateurs se réunissent pour approfondir les choix fonctionnels et valider les développements réalisés.
13
réseau
EDITIONS
Exemple : Une conduite de projet Internet et Intranet qui tourne dans le vide
Un EPIC souhaitait rendre visible son offre en ligne via Internet et apporter de nouveaux services aux
salariés du siège et du réseau à travers un Intranet d’entreprise.
La structure de projet formelle a été mise en place avec un comité de pilotage, des comités par projet et
une participation importante des services utilisateurs. Ces instances se réunissent au moins une fois par
mois depuis plusieurs mois sans déboucher sur des résultats tangibles pour plusieurs raisons :
• Les projets ne sont pas articulés assez étroitement avec le système d’information existant (un ERP), la
démarche de schéma directeur du S.I. n’ayant pas encore débouché lors du lancement du projet. La
direction informatique qui est traditionnellement faible dans cette structure n’a pas apporté une aide
suffisante à la définition du cahier des charges.
• D’autre part, un projet stratégique (création d’une filiale) est portée par la direction, ce qui modifie le
contour de ces projets et à tendance à marginaliser le comité de pilotage.
• A l’inverse, la dimension organisationnelle est largement présente même si la cible paraît encore lointaine. Les Instances Représentatives du Personnel (IRP) ont obtenu qu’une expertise soit menée sur les
projets dès la phase actuelle de l’expérimentation (il existe un site vitrine sur l’offre en ligne).
2.1.2. Phase de mise en œuvre
La réalisation est une période sensible du projet, où se jouent beaucoup d’éléments influant sur la réussite de l’outil. Il est illusoire de croire qu’une fois un prestataire choisi avec un cahier des charges précis, le
projet se déroulera tout seul sans encombre. La réalisation comporte toujours des imprévus, exige des précisions, des arbitrages sur telle fonction ou telle autre, qui doivent être tranchés avec le commanditaire.
La conduite de projet, basée sur des projets successifs, permet de mieux cerner les changements et l’accompagnement nécessaire sur le volet organisationnel renforce les chances de succès des projets. C’est la
stratégie suivie par FINANCAL pour son intranet documentaire.
Dans le cas du projet du secteur voyages du CCE du Crédit Siennois, le processus d’itération a consisté à
réaliser une maquette préfigurant un certain nombre de services. Ces outils de maquettage rapide ont ainsi
permis l’approfondissement des choix de procédures plus « parlants » pour les futurs utilisateurs.
Ces démarches se différencient des méthodes classiques dites de « cycle en V », dans lesquelles les utilisateurs n’étaient sollicités qu’au début du projet, pour l’expression des besoins, et tout à la fin, pour les tests
d’exploitation. Entre-temps, le prestataire pouvait avoir réalisé un produit en fort décalage avec les besoins
des utilisateurs à cause de choix « techniques » ayant un fort impact fonctionnel.
« Le cycle en V » : un modèle inadapté
14
réseau
EDITIONS
L’expérience a montré qu’il est plus sûr d’adopter une démarche itérative, avec de fréquents allers-retours
entre utilisateurs, concepteurs et développeurs, selon le modèle schématisé ci-dessous :
« Le modèle itératif » : un modèle pragmatique
Exemple de Financal
La société Financal avait lancé un projet de documentation sous Intranet des procédures comptables ; il
fut décidé dans la structure de projet que le chef du service comptable serait l’interlocuteur direct de
PLUME.
À chaque fois qu’une décision technique significative devait être prise par PLUME, le chef du service
comptable était sollicité pour valider l’amélioration ou l’absence d’impact négatif pour l’utilisateur. Si ces
changements touchaient l’interface, la demande était illustrée par des maquettes d’écran.
Par cette démarche itérative, les « mauvaises surprises » sur le produit livré furent évitées. L’Intranet de
documentation comptable, lorsqu’il entra en service, correspondait complètement aux attentes des comptables, puisqu’ils avaient pu suivre et agir sur toutes les modifications logicielles.
Étape 4 - Mettre en place des partenariats avec les prestataires extérieurs
Avant de choisir un outil, l’entreprise doit réaliser un cahier des charges, auquel répondront différents
prestataires. Elle peut à cette occasion se faire assister d’un consultant dans le cadre d’une mission
d’Assistance à Maîtrise d’Ouvrage (AMOA).
Ce cahier des charges doit éviter plusieurs écueils :
• il doit mentionner le moins d’éléments techniques possibles, il doit rester fonctionnel pour rendre compte des besoins des utilisateurs sans réduire le champ des solutions techniques envisageables ;
• il ne doit pas être trop précis, tout en constituant un cadre garantissant que les besoins des utilisateurs
seront couverts. Cela permettra d’obtenir une diversité des offres des prestataires permettant de bien
balayer toutes les solutions envisageables ;
• il doit mentionner les délais de réalisation souhaités, en fonction des contraintes des utilisateurs ;
• il doit porter les critères d’évaluation des solutions en termes de satisfaction utilisateur.
Le projet entrera alors dans une phase de sélection des offres :
• premier examen de toutes les offres ;
• sélection d’une short list d’offres, examinées en détail ;
• comparaison des caractéristiques des offres en « short list » selon les tous les critères élaborés dans le cahier
des charges (financiers et utilisateurs).
À la fin de cette étape, l’entreprise a sélectionné un prestataire soit pour développer un logiciel spécifique,
soit pour intégrer / paramétrer un logiciel du marché.
15
réseau
EDITIONS
Pour cela, l’entreprise doit, dans toute la mesure du possible, garder en interne le pilotage de la maîtrise
d’œuvre et pas seulement d’ouvrage. Cela suppose que les responsabilités de chacun soient clairement définies, tant en interne que chez les prestataires externes, et cela pour chaque phase du planning. Cette répartition des rôles est typiquement décrite dans le « Plan Qualité Projet » (PQP).
Le PQP est un document rassemblant le « qui fait quoi » du projet pour chacune de ses étapes, avec le
planning correspondant. Généralement, le PQP distingue « qui réalise », « qui participe », « qui valide »
chacun des livrables du projet, et cela pour toute entité impliquée (service interne, encadrement, équipe
de développement, etc.).
Il s’agit de donner au « contrat » tout son sens, en précisant notamment en interne :
• Préparation et animation des comités de pilotage
• Identification et mobilisation des acteurs du projet (utilisateurs, experts métiers, experts système, etc.)
• Mise en place de l’infrastructure pour l’équipe de projet (bureaux, postes de travail, etc.)
• Mise en place de normes et standards de documentation (gestion des noms, des versions, localisation,
accès), des rapports d’avancement du projet (périmètre, budget, risques, problèmes), du journal des
actions/décisions du projet.
• Suivi du budget et du planning
• États d’avancement et de suivi des actions et de décision du projet
• Communication sur le projet
Un plan indicatif de PQP est fourni dans la partie « Points de repères ». Une présentation classique consiste à faire la liste des tâches du projet, et de détailler pour chacune, qui réalise, qui contribue, qui valide,
et à quelles dates.
Exemple de Financal
La société Financal avait lancé un projet de documentation informatisée du service juridique. Il fut
décidé en interne que le projet serait structuré de la manière suivante : la personne en contact avec
PLUME, le prestataire externe chargé de la réalisation de l’Intranet juridique, serait non pas le chef du
service juridique, mais le responsable de la communication interne.
Par conséquent, toutes les expressions des besoins du service juridique étaient transmises ou interprétées
par cet intermédiaire de la communication interne. De la même façon, quand PLUME avait besoin
d’une précision sur les caractéristiques d’une fonction particulière, la demande passait par la communication interne, était transmise au service juridique, la réponse revenait à la communication interne, puis
était fournie à PLUME.
Un tel circuit était lourd, relativement lent. Dans certains cas, la communication interne répondait
directement à PLUME en supputant les besoins du service juridique. Ce mode de fonctionnement finit
par créer certains malentendus qui aboutirent à un dysfonctionnement technique. Sur les indications de
l’intermédiaire de la communication interne, les développeurs de PLUME mirent en place une base
documentaire qui s’avéra trop lente pour les réels besoins des juristes, du fait d’une volumétrie du thesaurus mal estimée.
Pour le projet suivant de documentation des procédures comptables, il fut décidé dans la structure de
projet que le chef du service comptable serait l’interlocuteur direct de PLUME. Avec ce nouveau mode
de fonctionnement, le projet se déroula comme prévu, et l’outil donna complète satisfaction.
Etape 5 - Intégration des outils dans l’organisation
Une fois le logiciel / l’intranet développé, il reste à le paramétrer selon les besoins des utilisateurs et le tester.
Les tests finaux sont regroupés dans la phase de « recette », qu’il importe de bien préparer. Cette phase est
souvent négligée dans les projets T.I.C., ce qui a pour effet de masquer les insuffisances des outils jusqu’à
ce que les utilisateurs les découvrent « par hasard ». Il est alors généralement trop tard pour agir.
La préparation de la « recette » passe par la rédaction d’un « cahier de recette », qui va énumérer toutes les
manipulations, opérations, cas à tester par les utilisateurs. Plus précisément, la recette est l’ensemble des
opérations de contrôle permettant au Maître d’ouvrage de vérifier que les engagements du Maître d’œuvre,
établis dans le cadre du projet « Prométhée », sont respectés (conformité aux spécifications). En outre, elle
permet d’officialiser l’acceptation des différents composants du projet.
L’objectif de ce cahier de recette (appelé aussi protocole de recette) est de préciser les modalités (conditions) de la réception de chacun des composants à livrer. Pour ce faire, il :
• reprend le planning général des réceptions ;
• précise pour chaque composant les critères de réception (en entrée et en sortie de la Recette), et la
méthode de réception associée ;
16
réseau
EDITIONS
• liste la documentation applicable et de référence ;
• liste la documentation de test à produire ;
• précise les environnements de tests nécessaires à la réception du système (et aux réceptions intermédiaires
s’il y en a), et leur gestion ;
• précise les procédures applicables ;
• précise le vocabulaire.
Le cahier de recette doit être rédigé pendant la phase de conception. Il prend un caractère contractuel après
son approbation par le Maître d’ouvrage et le Maître d’œuvre.
Il est indispensable de bien tester les capacités des outils à répondre aux exigences fonctionnelles et techniques des utilisateurs. Il faut donc impliquer les salariés dans les réunions de prototypage et de « recettage ».
L’organisation du projet doit donc prévoir le rôle moteur d’une personne interface (« traducteur ») entre
les experts informatiques et les futurs utilisateurs. Cette personne sera au premier plan lors de la recette.
Exemple : Service Voyages du CCE du Crédit Siennois
L’intégration des nouveaux outils informatiques dans l’organisation représente pour le service Voyages un
processus complexe
• en termes de calendrier (mise en œuvre avec le démarrage d’une saison et impossibilité de décaler le
démarrage au dernier moment),
• en termes de ressources internes (continuer à assurer l’exploitation courante) ;
• et de validation des données et des circuits de traitement, ceux-ci devant être conformes aux règles fixées
par l’instance politique (les salariés doivent avoir accès aux services du CCE de manière équitable... ce
qui diffère des pratiques d’un voyagiste habituel).
La nouvelle organisation (réallocation physique des bureaux, services fusionnés) est mise en place 6 mois
avant le démarrage du nouveau système informatique. Dans les groupes de travail participant à la
conception et au paramétrage du logiciel, les personnes ont eu l’occasion d’échanger sur leurs pratiques
professionnelles.
Après le déménagement des bureaux, les salariés vont disposer d’un accès au nouveau SI pour valider les
données sur l’offre de séjour et se familiariser avec l’ergonomie du produit, même s’ils ne passent pas de
transactions réelles.
Étape 6 - Déploiement de la nouvelle organisation
Une fois la recette terminée, le nouvel outil et l’organisation associée doivent être mis en place avec une
attention toute particulière. Cela suppose d’avoir planifié :
• un déploiement des nouvelles consignes de travail (procédures, règles de gestion),
• des séances de formations associées à leurs usages,
• d’éventuels outils d’auto-formation,
• d’une assistance sur place ou par téléphone.
Un problème observé fréquemment concerne la coordination des décalages entre la formation aux outils
et leur mise en place réelle. Il n’est pas rare que des salariés soient formés à un outil plusieurs mois avant
que celui-ci leur soit installé, laps de temps pendant lequel le mode d’emploi est oublié... L’inverse arrive
aussi : les utilisateurs se voient imposer un outil pour lequel ils n’ont pas reçu de formation, et apprennent
péniblement par essai/erreur... tout en se faisant critiquer par les informaticiens pour leurs mauvaises
manipulations !
Pour ces raisons, il est indispensable de prévoir une assistance, trop souvent négligée. Celle-ci peut être
assurée par un utilisateur particulier, qu’on aura pris soin de décharger d’une partie de son travail habituel, pour qu’il puisse apprendre à ses collègues les différents modes opératoires. Ce salarié « médiateur »
et « accompagnateur » pourra aussi faire remonter les problèmes et bugs. Cette stratégie d’appropriation
est souvent très efficace, mais suppose de pouvoir libérer le salarié pour la durée correspondante.
La maintenance du système doit également être prévue : maintenance technique, bien sûr, mais aussi
maintenance éditoriale. Pour un site Intranet, comportant des nouvelles, des informations, il faut officiellement affecter la responsabilité du suivi éditorial à une personne.
Rappelons que la date de mise en place doit être fixée selon le planning des utilisateurs plutôt que sur les
considérations techniques seules. Trop souvent, les outils sont mis en place dès que leur développement
est achevé, alors qu’il vaudrait mieux s’interroger sur la période la plus adaptée pour les salariés.
Une bonne organisation et des supports associés permettront d’accompagner les salariés dans la phase opérationnelle (assistance utilisateurs) pendant le déploiement opérationnel (dit « bascule »). Mais il est éga-
17
réseau
EDITIONS
lement nécessaire de mettre en place des structures pérennes dans l’organisation s’appuyant sur des acteurs
relais et/ou des correspondants dans les services. Ces structures seront chargées de l’ajustement de l’organisation, des usages, des outils et processus d’apprentissage, des compétences.
Exemple : Service Voyages du CCE du Crédit Siennois
6 mois avant la fin du projet, la majorité du CCE change, et l’élu qui assurait la maîtrise d’ouvrage du
projet est écarté. D’autre part, la maîtrise d’œuvre était éclatée entre le responsable opérationnel du service « Voyage » et les deux sous-traitants. Le projet est donc « décapité. »
Les nouveaux élus du CCE ne connaissant pas le projet, un certain nombre de tâches prennent du
retard : implantation des micro-ordinateurs, réorganisation des locaux. Heureusement, le projet technique, qui s’appuie sur des bases solides (maquette, règles de gestion), peut continuer sur sa lancée. Les
prestataires (PLUME et ARETE) ont poursuivi et achevé les développements, et la phase de tests commence.
En tout état de cause, l’implantation des ordinateurs et la restructuration des locaux coïncidera avec la
fin des tests. La livraison du système d’information pourra malgré tout avoir lieu dans le laps de temps
envisagée (i.e. à la rentrée de septembre.) Entre-temps, la nouvelle organisation a été intériorisée et
acceptée par tous : pour les nouveaux élus, « c’est de l’acquis, il faut mener le projet jusqu’au bout. »
En analysant ces derniers événements, on voit que le projet T.I.C. a ainsi été fragilisé par des problèmes
et des jeux d’acteurs internes au Crédit Siennois. L’absence de chef de projet désigné aurait pu être fatale au projet. Ici, la bonne préparation dans la première phase, grâce aux maquettes et au prototype, a
permis de mener à son terme le projet. Si la préparation technique et organisationnelle avait été moins
rigoureuse, il est probable que cela aurait eu des conséquences graves sur le projet. Dans le meilleur des
cas, celui-ci aurait été retardé de plusieurs mois, voire d’un an.
Cet épilogue illustre bien le type d’aléas relativement imprévisibles qui peuvent affecter un projet T.I.C.
Il montre aussi l’importance d’une bonne préparation, avec la nomination d’un chef de projet. Il souligne enfin qu’avec une préparation rigoureuse, à partir d’une méthodologie utilisant maquette et prototype, l’aléa peut être surmonté et le projet T.I.C. malgré tout aboutir.
Exemple : Intranet comptable Financal
L’Intranet comptable Financal est livré à la date prévue, et les fonctionnalités correspondent à la demande initiale, avec les ajustements demandés en cours de projet. L’Intranet est utilisé par les salariés comme
prévu, et l’outil donne satisfaction.
Cependant, un aléa survient : la Direction des Systèmes d’Information a entre-temps lancé un grand
projet de centralisation des données de tous les Intranets de Financal. Or le projet d’Intranet comptable
avait été lancé avant cette décision de centralisation, et s’avère incompatible avec cette dernière.
Un conflit s’instaure entre la DSI et le service comptable, la DSI refusant d’assurer la maintenance évolutive de l’Intranet comptable, le service comptable ne voulant pas financer le redéveloppement de l’application pour la rendre compatible avec le système centralisé de la DSI. Le compromis suivant est trouvé : le service comptable garde son Intranet tel quel, et se chargera de le faire évoluer et de le maintenir
directement avec le prestataire PLUME. Le service comptable continuera donc d’utiliser son outil
Intranet qui le satisfait.
Le projet T.I.C. est donc ici complètement réussi, et valide donc la méthodologie de prototypage et de
contractualisation exposée plus haute. Cependant, l’épilogue montre aussi les jeux de pouvoir qui peuvent apparaître entre utilisateurs et Direction des Systèmes d’Information. La DSI veut imposer une stratégie, mais des problèmes de calendrier et un manque de coordination et de communication font surgir
des conflits difficiles à anticiper. Ici, une issue satisfaisante pour les deux parties est trouvée, mais dans
d’autres cas, la confrontation peut conduire à l’échec du projet.
18
réseau
EDITIONS
3e partie
Points de repère
Après la présentation de la « réflexion organisationnelle » et du « déroulement type » des projets T.I.C.,
cette partie expose les points sensibles, les nœuds de la démarche de projet qui sont incontournables. Ces
« nœuds » nécessitent un examen attentif, et montrent les écueils types auquel un chef de projet ou les utilisateurs peuvent être confrontés, et les tactiques à adopter. Pour ces raisons, cette partie a été appelée
« Points de repère ».
Les « points de repère » suivants ont été sélectionnés :
1. Les objectifs du projet (la genèse du projet, les objectifs stratégiques, l’articulation des différents projets...)
2. L’envergure du projet (périmètre, temporalité, ressources internes et externes)
3. La prise en charge du projet : la maîtrise d’ouvrage et la maîtrise d’œuvre
4. La prise en compte des utilisateurs (dans l’entreprise, les clients, etc.)
5. L’évolution des métiers, des compétences
6. La « boîte à outils » (infrastructure, modélisation, pilotage)
3.1. Les objectifs du projet
Les objectifs d’un projet T.I.C. doivent s’analyser en fonction des événements déclencheurs du projet.
En effet, ces événements sont très éclairants sur les objectifs réels du projet, par opposition aux objectifs
affichés.
Bien que l’expérience montre que les événements déclencheurs d’un projet peuvent être extrêmement
variés, on peut néanmoins distinguer plusieurs grandes catégories :
• Lorsqu’une entreprise est absorbée par une autre entité ou du moins contrôlée économiquement
par elle, la fusion ou l’interconnexion des S.I. devient nécessaire, ne serait-ce que pour consolider les
résultats financiers et établir des budgets. Les objectifs affichés s’attachent à bâtir une culture commune
entre les différentes entités, à favoriser les synergies (base de clients commune), à diminuer des coûts
(charge de développements informatiques et d’exploitation mutualisés).
Une fédération du crédit Mutuel (Crédit Mutuel de Centre Est Europe) avait pris le contrôle de la
banque CRÉDIT INTER INDUSTRIEL-Paris au milieu des années 90. Le CRÉDIT INTER
INDUSTRIEL a été conduit à adopter quelques années plus tard le système d’information de cette fédération, permettant ainsi à son réseau de distribuer plus facilement les produits bancaires conçus de
manière globale par la banque mutualiste. En regroupant leurs moyens, les deux entités pouvaient aussi
dégager des moyens financiers plus importants pour améliorer les performances du S.I. Le projet a été
appelé « CRÉDIT INTER INDUSTRIEL 2001 », ce qui signifiait « Construire une Informatique
Commune pour 2001 ».
• Lorsqu’une entreprise doit repenser sa stratégie pour diverses raisons (survie économique, commerciale, changement de direction, etc.), elle remet bien souvent en question son système d’information et son organisation. Cela suppose de réorienter certaines prestations offertes, et de restructurer des processus de travail. Il est à peu près inévitable que le S.I. doive lui-même évoluer, voire être
remplacé par un autre système. Les objectifs mis en avant dans ce type de projet de changement sont
d’abord des objectifs stratégiques pour l’entreprise (dépasser un cap difficile, se renforcer pour l’avenir...)
19
réseau
EDITIONS
avec les moyens qui en découlent (nouvelle organisation a priori plus cohérente avec les orientations stratégiques, adaptation des effectifs, moyens informatiques nouveaux).
Une mutuelle lance un projet T.I.C. de Gestion de la Relation Client, qui permettra à tous ses clients de
gérer leurs contrats et leurs sinistres par téléphone. Mais ce nouveau mode de communication entre en
concurrence avec le réseau traditionnel d’agences de la mutuelle. Les agents, se sentant court-circuités par
la Direction, coopèrent a minima avec la plate-forme téléphonique centralisée, et pratiquent une rétention d’informations. La qualité du service de gestion par téléphone en est amoindrie, et la Gestion de
Relation Client voulue par la Direction se révèle alors bien en dessous des attentes.
Une entreprise veut informatiser son réseau commercial, en fournissant à ses commerciaux un logiciel
où ils saisiront leurs rendez-vous et toutes les données client recueillies. Or la base client constitue le « trésor » de ses commerciaux, qui anticipent que dès que l’entreprise aura stocké toutes leurs informations
clients, elle pourra les licencier relativement facilement. Dans un contexte social tendu, l’outil finit par
être mis en place, mais restera majoritairement inutilisé.
• Lorsque le projet informatique résulte d’une évolution majeure du système d’information prévue
dans un schéma directeur informatique. Les raisons stratégiques évoquées précédemment sont souvent présentes, mais elles n’apparaissent pas nécessairement en premier dans ce type de projet. Ce qui est
souvent mis en avant, c’est le volet de la modernisation du S.I., pour offrir un meilleur service, pour
adopter une architecture plus récente, plus performante, moins coûteuse. Il peut s’agir simplement de
respecter une obligation commerciale, réglementaire. Les projets mettant en jeu l’ensemble du S.I. (nouvelle architecture, mise en place d’un progiciel de gestion intégré) présentent une complexité importante, souvent difficilement appréciée, et sont pilotés par la direction générale. Les objectifs affichés portent
à la fois sur un volet informatique et sur un volet organisationnel, mais la partie technologique est souvent plus facilement mise en avant pour dynamiser l’entreprise sur un objectif de changement (le nouveau S.I. est la partie la plus visible du changement).
L’exemple de SOCRATE, le système de réservation de la SNCF peut illustrer un cheminement à la fois
organisationnel et informatique. Il s’agissait d’adapter un système de réservation du monde aérien (le système d’American Airlines) qui permettait d’optimiser commercialement l’occupation des trains (le yield
management). La partie emblématique du projet a été le renouvellement du logiciel de vente en gare
(avec les difficultés d’implantation que l’on connaît). Si le volet organisationnel avait été partiellement
traité (les études métiers montraient que le travail du vendeur était très peu modifié), par contre le volet
de la relation client (sa capacité à comprendre la nouvelle stratégie commerciale de la SNCF) n’avait pas
du tout été pris en compte dans la conduite de projet (cf. Études & Documents de l’ANACT n°4, 1995).
• Lorsque le projet informatique ne correspond pas à un objectif clairement affiché, soit parce qu’il résulte d’une mise à disposition d’un outil, d’une fonctionnalité supplémentaire sur des équipements déjà en
place, soit parce qu’il relève d’une décision d’équipement sans objectif organisationnel précis.
On peut mettre dans cette catégorie de projet la diffusion de logiciels bureautiques supplémentaires, les
outils de messagerie et d’accès au Web, la diffusion de micro-ordinateurs portables et les accès à distance. La question qui se pose est la capacité de l’organisation à utiliser de tels équipements. Les décisions
se prennent plutôt au niveau de collectifs de travail de taille limitée (par exemple pour partager des agendas), puis peuvent s’étendre par effet de « capillarité ». Des projets informatiques peuvent être aussi portés par des directions opérationnelles qui veulent « outiller » une partie de leur activité par une application qui n’est pas ou mal assurée par le S.I. de l’entreprise. On retrouve ce type de projets dans le développement de sites intranet ou internet qui sont créés à l’initiative de services, le projet d’entreprise visant
à fournir une infrastructure et des règles de présentation (charte graphique, outils de développement).
On parle d’un « projet appropriatif » quand on met à disposition des salariés des outils sans connaître à
l’avance quels en seront les usages.
Dans ce type de projet, on ne sait pas clairement où l’on veut aller, parce qu’on connaît mal ce que va
produire la combinaison de choix organisationnels, techniques, de nouveaux modes de travail. La
réflexion porte sur des couples fonction / technologie, car ce ne sont pas les technologies qui sont les facteurs de différentiation, mais les domaines d’application et les usages. Les modes d’appropriation non
imposés, difficilement identifiables au départ et dont les conséquences sur les comportements, sur les procédures de travail, les modes de management et in fine l’organisation sont mal connus.
On rencontre typiquement ce type de situation dans les T.I.C. Cette logique « appropriative » pose la
question même du pilotage : peut-on conduire quelque chose ? Ne s’agit-il pas plus de mettre à disposition une infrastructure, de voir se construire des services, se développer des usages et d’observer ?
20
réseau
EDITIONS
En général, l’appropriation fonctionne plus ou moins bien, plus ou moins rapidement. Certains services,
certains utilisateurs peuvent ne pas s’impliquer dans de nouveaux modes de fonctionnement et être marginalisés. Il est difficile pour l’entreprise de construire une stratégie a priori. Il s’agit plus d’une évaluation a posteriori et de favoriser des échanges d’expérience.
En revanche, un écueil récurrent des « projets appropriatifs » est de sous-estimer la charge de travail liée
à l’utilisation des nouveaux outils. « Le syndrome du forum vide » fait partie des exemples connus : l’organisation met en place un forum pour susciter des débats ou des réactions sur un sujet, mais ne confie
pas de travail d’animation à un « modérateur. » Assez souvent, le forum s’éteint, faute de discussions, de
relances et d’animation.
• Lorsque le projet informatique est issu d’une vision venue d’en haut (sic !). Dans une approche « visionnaire », le projet TIC est lancé par la Direction, dont la vision lie intimement projet organisationnel et
projet informatique. Il peut s’agir d’une nouvelle orientation stratégique de l’entreprise, de nouveaux
produits et services, la création d’une nouvelle entité. Le projet TIC constitue dans les domaines organisationnel et technique un levier de changement. Le management du projet est porteur de cette cohérence en permanence.
De ce fait, la négociation entre les acteurs s’arbitre en fonction des objectifs stratégiques, et la cible doit
donc être clairement perçue par tous les acteurs. La communication sur le projet doit faire l’objet d’une
attention particulière.
Les risques et échecs des projets « visionnaires » peuvent tenir au fait que les réalisations ne soient pas à
la hauteur du « dessein. » La complexité de mise en œuvre du projet, des facteurs externes qui relèvent
de « l’intendance »... sont mal pris en compte, car ils n’interrogent pas le niveau stratégique. Il y a un
risque progressif d’écart entre le discours et ce qui est fait réellement. Les moyens ne sont pas à la hauteur des ambitions. La partie évaluative n’a pas un poids suffisant dans la boucle de décision. Peu à peu,
les acteurs se démobilisent et le projet n’atteint pas ses objectifs initiaux, tant sur le plan technique qu’organisationnel.
Prédominance de la dimension technique ou organisationnelle des projets selon les événements déclencheurs
Déclencheur
Exemple
Enjeux
du projet
Dominante du projet
Conduite
de projet
Chef de projet
Entreprise
Intégration dans
« absorbée » adoptant un ERP de
le S.I. d’une autre
la maison-mère
entreprise
Projet d’intégration
Équilibre projet
organisationnel / projet
technique
Changement global conduite
de culture,
fortement
d’organisation,
structurée
de S.I.
« Binôme »
Chef de projet
utilisateur / Chef de
projet informatique
Entreprise modifiant
son organisation et
son S.I. à la suite
d’un audit stratégique
Mise en place
d’un centre d’appels
Informatisation
de la force de vente
Projet stratégique
Équilibre projet
organisationnel / projet
technique
Adaptations et
conduite
ajustements mutuels structurée
de l’organisation et
de la technique
« Binôme »
Chef de projet
utilisateur / Chef de
projet informatique
Changement
d’organisation
dans une direction,
un service
Mise en place
Projet « métier »
d’un nouveau canal Projet à dominante
de vente
organisationnelle
Adaptation du S.I.
au changement
d’organisation
conduite
structurée
Chef de projet
utilisateur
Volonté de faire
évoluer le S.I.
Migration
de progiciels
hétérogènes sur une
plate-forme unique
Projet
« *Schéma Directeur »
Projet à dominante
technique
Accompagnement
conduite
organisationnel du structurée
projet informatique
Chef de projet
informatique
Volonté de
développer l’usage
d’un nouvel
équipement
Installation
d’une messagerie
instantanée (IM)
Projet « *appropriatif »
Projet à dominante
organisationnelle
Développement
d’usages
Projets portés par
les utilisateurs
conduite
Chef de projet
faiblement utilisateur
structurée
Volonté de s’inscrire
sur la vague
technologique
de l’intranet
Suppression
du papier dans
toute l’organisation
Projet « *visionnaire »
Équilibre projet
organisationnel / projet
technique
Maintien du lien
entre objectifs
globaux et mise
en œuvre locale
conduite
fortement
structurée
« Binôme »
Chef de projet
utilisateur / Chef de
projet informatique
Note : selon le type d’événement déclencheur du projet, il faut s’interroger sur la pertinence d’audits organisationnel et technique préalables :
• doit-on séparer audit « organisationnel » et audit « informatique » en amont du projet ?
• doit-on mener un audit global « organisation et informatique » en amont du projet ?
21
réseau
EDITIONS
3.2. L’envergure du projet
(périmètre, temporalité, ressources internes et externes)
L’étude de faisabilité est le moment clé pour définir l’ampleur que l’on va donner au projet. Aujourd’hui,
les entreprises partent toujours d’un existant informatique. Il ne s’agit pas de construire un nouvel édifice
en partant d’un terrain vierge, mais d’aménager, de moderniser un existant qui a ses faiblesses, mais aussi
ses potentialités. Jusqu’où le commanditaire choisit-il d’aller dans son programme de rénovation ?
Suivant les objectifs et les technologies envisagées, la question du périmètre du projet pourra être traitée
différemment.
Dans le cadre d’un projet intégré tel que celui de l’ERP (Entreprise Ressources Planning ou
Progiciel de Gestion Intégré), la question peut sembler triviale car le concept même du produit s’adres-
se à l’ensemble des ressources de l’entreprise dans le but d’intégrer les fonctions de gestion entre elles.
Le projet a nécessairement une envergure très large. Le rôle de l’étude de faisabilité n’est pourtant pas
inutile, car l’expérience des entreprises qui ont déjà conduit ce type de projet montre que mettre en place
un ERP est très coûteux en ressources financières et humaines. L’entreprise doit être consciente de l’effort
demandé et le projet doit recevoir un soutien fort de la direction. D’autre part, le projet ne s’adresse pas
nécessairement à la totalité des fonctions de l’entreprise (notamment pour les activités qui nécessitent des
applicatifs sectoriels).
La question de l’adaptation de l’organisation dans le cadre de la mise en place de l’ERP doit être posée
dans le contexte du projet, mais les dimensions de l’organisation ne sont pas « nécessairement » contraintes
par l’ERP : les possibilités de paramétrage laissent le choix aux acteurs de définir les modalités de configuration des traitements.
Lorsqu’il s’agit de construire des applications de type Internet ou Intranet, la stratégie incrémentale est
plus souvent retenue en choisissant de développer des applications pilotes qui s’étendent ensuite de proche
en proche aux différentes fonctions de l’entreprise. Dans ce type de projet, plusieurs points apparaissent
importants :
• Dans quelle mesure ces services Internet et Intranet doivent-ils être intégrés dans le S.I. de l’entreprise ?
• Quelle cohérence existe-t-il entre ces différents services Intranet ? La notion de « portail d’entreprise »
est-elle assurée ? Le choix d’une charte graphique commune est-elle prévue dès le départ afin d’éviter des
modifications ultérieures ?
Pour les applications de type bureautique communicante, la question du périmètre du « réseau » est
un élément déterminant, car elle influe directement sur la valeur ajoutée de l’outil. On admet que la
« fonction d’utilité » de ces outils augmente en proportion du carré du nombre d’utilisateurs. Les critères
de standardisation des outils sont également importants, car ils facilitent la montée en compétence et la
mobilité des salariés.
Cas du service Voyages du CCE du Crédit Siennois
La refonte du système de réservation et de facturation de voyages et de séjours présente, à l’échelle de la
structure, un projet de type ERP. Il concerne à la fois la production et la diffusion du catalogue de l’offre,
la transmission et la saisie des réservations, la facturation des séjours. Les logiciels de comptabilité et de
paie devraient être également remplacés. On voit donc que la totalité des fonctions de l’entreprise est
concernée par le projet. À un niveau plus fin, certains choix ont été faits qui limitent la dimension
d’« intégration » dans les fonctions de gestion :
• les salariés peuvent remplir leur demande de réservation, mais la confirmation de cette réservation n’est
pas immédiate (le CCE affecte les places en fonction de critères de priorité différents de l’ordre séquentiel des demandes) ;
• le paiement en ligne des prestations n’est pas envisagé pour l’instant ;
• une liaison directe avec le S.I. des voyagistes dont les produits figurent au catalogue est prévue à plus
long terme.
Ces options limitatives ont été retenues soit pour maintenir la possibilité pour le siège de réguler les flux
de réservations dans les périodes les plus chargées, soit pour ne pas complexifier les fonctionnalités du service en ligne et donc pour maîtriser les problèmes de sécurité.
Même si l’on met en avant la prééminence de l’organisation par rapport à des choix techniques, les
contraintes du S.I. sont souvent très fortes et conditionnent au moins temporellement les possibilités
d’évolution de l’organisation du travail. Les technologies informatiques et les choix de logiciels sont des
éléments fortement structurants dans la construction d’un projet. Face à la lourdeur d’évolution du S.I.,
il est d’ailleurs fréquent que des services utilisateurs lancent des projets dits « légers » apportant un service plus limité, mais qui s’affranchit du processus habituel d’évolution du S.I.
22
réseau
EDITIONS
La durée de vie des applications informatiques est beaucoup plus longue que ce que l’on pouvait imaginer lors de la mise en place des premiers systèmes (la question du passage à l’an 2000 l’a bien montré).
Dans l’analyse du périmètre du projet, la question de la pérennité des solutions choisies est un élément
important :
• Dans le choix d’une technologie, adopte-t-on un produit standard ou un produit spécifique ? Quelle
dépendance accepte-t-on vis-à-vis d’un fournisseur ?
• Des changements d’organisation seront-ils possibles avec le même système d’information ? Dans quelle
mesure choisit-on des solutions génériques et adaptables ?
On voit donc que plusieurs questions essentielles sous-tendent les rapports entre évolution de l’organisation et évolution du Système d’Information :
• A-t-on bien pensé le futur S.I. à partir de l’organisation cible et non l’inverse (situation classique dans
une logique d’offre informatique) ?
• Comment assure-t-on la transition entre les différentes générations de S.I. ? Va-t-on vers une simplification ou une complexité croissante du S.I. ?
• Le S.I. cible sera-t-il compatible avec une évolution ultérieure de l’organisation du travail et des processus ? ( Peut-on garder comme objectif de pouvoir faire évoluer l’organisation sans redévelopper les applicatifs) ?
3.2.1. Points de repère : suivant les types de projet, quel périmètre,
quelle temporalité donner au projet ? Quelles ressources ?
Exemples de projet
Périmètre
Temporalité
Ressources
Projet intégré
de type ERP
Toute l’entreprise, mais la
lourdeur de mise en œuvre
recommande de bien cerner
la faisabilité au départ.
Durée longue
(un an ou plus).
Implication forte
de la direction.
Ressources internes
et externes souvent
très importantes.
Sites Internet
et Intranet
Possibilité de mise en place
incrémentale, mais définir au
départ des règles et pouvoir
évoluer vers la notion de portail.
Durée variable,
mais en général
assez courte si
l’infrastructure
existe déjà.
Importance des
ressources internes
pour définir et
alimenter les services.
Bureautique
communicante
La dimension organisationnelle
est prédominante, car les outils
existent déjà en général
La durée de mise
en place dépend
du service fourni et
de la « réceptivité »
des utilisateurs.
Importance des
ressources
managériales et en
accompagnement
des utilisateurs.
3.3. La prise en charge du projet :
la maîtrise d’ouvrage et la maîtrise d’œuvre
La dissociation entre Maîtrise d’Ouvrage (celui qui commande) et Maîtrise d’Œuvre (celui qui réalise) est
suffisamment courante aujourd’hui pour ne pas nécessiter d’analyse plus approfondie. Elle est généralisée
dans la mesure où elle permet une maîtrise plus efficace entre projet organisationnel et projet technique.
La question des capacités internes pour assurer ces fonctions est un problème difficile. Dans la première
partie de démarche, nous avons mis l’accent sur la nécessité de bien assurer en interne la responsabilité de
maîtrise d’ouvrage, même s’il peut être utile de recourir à l’assistance d’un conseil en maîtrise d’ouvrage
(notamment sur l’étude de faisabilité). Suivant le type de projet, la maîtrise d’ouvrage pourra être assurée
par la direction générale, s’il s’agit d’un projet au niveau de l’ensemble de l’entreprise, soit par une direction opérationnelle s’il s’agit d’un projet concernant spécifiquement un secteur de l’entreprise, soit par une
direction de l’informatique et de l’organisation s’il s’agit d’un projet plus transversal avec de fortes incidences sur l’architecture du S.I.
Le chef de projet doit également être choisi en interne, même s’il peut être fortement assisté par un prestataire de service externe qui assurera une part importante dans la réalisation du projet. Le chef de projet
23
réseau
EDITIONS
est le référent interne qui suit l’avancement du projet au jour le jour et coordonne l’ensemble des travaux
assurés, aussi bien en interne qu’en externe. Le choix du profil du chef de projet présente plusieurs possibilités :
• un chef de projet métier ?
• un chef de projet informatique ?
• un pilotage conjoint avec un chef de projet métier et un chef de projet S.I. ?
• un pilotage tripartite avec la Direction Générale, la Direction Utilisateur et la DSI ?
Le choix sera effectué en fonction du type de projet. En reprenant la classification des projets établie précédemment, on adaptera le profil de ce chef de projet à la dominante de l’objectif poursuivi.
3.4. La prise en compte des utilisateurs
(dans l’entreprise, les clients, etc.)
L’ouverture du système d’information aux partenaires clients et fournisseurs de l’entreprise, aux administrés, usagers pour les services publics, amène à repenser la place des utilisateurs dans les projets informatiques. Ces utilisateurs sont, par définition, moins bien connus que les utilisateurs internes. Leur prise en
compte représente donc un défi nouveau en termes de service rendu (Comment le rendre accessible au
plus grand nombre ? Comment le rendre performant pour différentes catégories d’utilisateurs avec des
niveaux d’expertise différents ? Comment assurer la sécurité de fonctionnement ?).
Certaines de ces questions s’étaient déjà posées lors de la mise en place des systèmes transactionnels assurant des opérations en temps réel avec la clientèle (on parlait fréquemment de « relation à trois » entre le
client, l’opérateur et l’écran informatique). Même si le client n’était pas l’utilisateur direct du système,
comment les demandes qu’il formulait pouvaient-elles être traitées par l’opérateur ? Le système était-il
structurant dans le dialogue avec le client ?
Les démarches adoptées par des groupes d’utilisateurs et des groupes témoins pour évaluer les choix de
conception ont permis d’améliorer les interfaces avec les utilisateurs, de prendre en compte, en amont de
la conception, de nouvelles exigences en termes d’ergonomie du logiciel.
De nouvelles questions se posent aujourd’hui (et doivent être posées en amont du projet) vis-à-vis des utilisateurs :
• Les catégories d’utilisateurs sont de plus en plus multiples et difficiles à caractériser de manière homogène : par leurs compétences et niveaux d’appropriation du S.I., par les bénéfices ou conséquences négatives qui résulteront pour eux du projet, par leur niveau de responsabilité et d’autonomie...
• Ils peuvent être à la fois utilisateurs et producteurs d’information. Leur contribution et leur adhésion à
un service (par exemple pour l’agenda, le reporting) deviennent essentielles pour le fonctionnement
du S.I.
• Il peut exister des technologies, des applications alternatives qui peuvent fournir des services proches l’un
de l’autre. C’est notamment le cas avec les outils de communication.
• Les services offerts sous couvert de modernité et d’intégration accrue apportent-ils un avantage réel en
termes d’efficacité, de productivité pour l’utilisateur pris individuellement ? Ce denier ne risque-t-il pas
d’être rebuté par la complexité de mise en œuvre du nouvel outil, par un temps de formation pris sur
son temps personnel, par une saisie à la source d’informations qui étaient auparavant traitées par d’autres
et qui conduisent à une augmentation de la charge de travail ?
3.5. L’évolution des métiers, des compétences, des conditions de travail
3.5.1. Conditions de travail et mise en place du S.I.
La bonne intégration du S.I. au niveau des conditions de travail, des compétences constitue un enjeu
majeur du projet (les conditions de travail structurant l’ensemble de la démarche).
• Comment inclure le volet conditions de travail avant que les choix informatiques aient trop restreint les
marges de manœuvre ?
• Comment penser les conditions de travail de travail du salarié dans une perspective temporelle (phase
d’apprentissage, régime de croisière, évolutions applicatives) ?
24
réseau
EDITIONS
• Comment concevoir un dispositif technique et organisationnel d’accompagnement et d’assistance aux
utilisateurs (hotline, traitement des incidents, « parrainage / essaimage ») ?
• Comment intégrer les retours utilisateurs pour améliorer la conduite du projet et le Système
d’Information cible ?
Ces questions doivent se décliner selon les thèmes suivants :
Organisation du travail
Mise en place du S.I.
• Définition des positions de travail,
répartition paramétrage des autorisations
• Implantation des postes de travail,
des tâches, circuits de communication
• Emplois, compétences
• Conception de la documentation, des aides en ligne
• Formation métier
• Formation informatique
• Apprentissage organisationnel
• Assistance, Hot line, analyse des incidents
3.6. La « boîte à outils »
(infrastructure, modélisation, pilotage, plan qualité)
Plutôt qu’une liste impérative d’éléments nécessaires au bon déroulement du projet, voici certaines
« bonnes pratiques » qui méritent d’être retenues si le contexte ou la taille du projet s’y prêtent. Ces pratiques ont été sélectionnées, car elles sont relativement répandues, aisément compréhensibles et relativement faciles à mettre en place.
3.6.1. Le diagramme de Gantt
Il s’agit tout simplement de la représentation graphique du planning des différents chantiers ou tâches du
projet. Cette présentation permettra à chaque acteur d’avoir la vue d’ensemble du projet. On peut utiliser
un logiciel dédié (comme Microsoft Projet) ou utiliser un tableur standard.
3.6.2. Les bases documentaires
Il est approprié de faire travailler tous les acteurs internes du projet sur un répertoire partagé, où tous les
fichiers seront regroupés par une arborescence par chantiers ou étapes du projet. L’accès à l’information en
est facilité, le regroupement évite de disposer ou de travailler sur des versions obsolètes des documents.
Par ailleurs, la sécurité en est accrue si le serveur est sauvegardé régulièrement.
25
réseau
EDITIONS
3.6.3. Le Plan Qualité Projet (PQP) : « un qui fait quoi » pour le projet
Le Plan Qualité Projet (PQP) définit l’organisation du projet en explicitant les missions de chaque acteur
interne ou externe. Les responsabilités du chef de projet, des utilisateurs, des prestataires sont décrites pour
ce qui est de l’animation, de la validation des documents et des décisions, de la rédaction de compte-rendus, de la documentation, etc.
Le PQP fournit le planning de référence et les charges de travail estimées pour chacun. Si une tâche
requiert plus de temps ou de travail que prévu, le PQP doit être amendé.
C’est le PQP qui fait foi lorsqu’il y a contestation de la responsabilité avec les prestataires, par exemple.
En précisant par écrit les rôles de chacun, il évite que les prestataires ne se « renvoient la balle » quand survient un problème.
Sommaire type d’un PQP
1. Présentation générale du projet
1.1. Objectifs du projet
1.2. Périmètre du projet
1.3. Projets parallèles
2. Plan d’organisation du projet
2.1. Les intervenants, rôles et missions
2.2. Les comités et leurs missions
2.2.1. Le comité de pilotage :
missions / composition / fréquence des réunions /
rédaction des comptes-rendus
2.2.2. Le comité de suivi de projet :
missions / composition / fréquence des réunions /
rédaction des comptes-rendus
3. Plan de conduite du projet
3.1. Répartition en chantiers
3.2. Description des étapes des chantiers
3.2.1. Conduite du projet
3.2.2. Livrables par chantiers
• Expression des besoins
• Cahier des charges
• Étude technique détaillée (de la solution)
• Cahier de recette
• Documentation technique / support de formation
3.2.4. Matrices des tâches et responsabilités
3.3. Planning du projet
26
réseau
EDITIONS
3.6.4. Les matrices de responsabilité
Validation / Recette
Charge
Réalisation
Charge
Il s’agit d’un tableau résumant toutes les tâches et les rôles de chacun. Cela permet d’avoir une vue d’ensemble et de vérifier qu’on n’a pas surchargé à 200 % un membre du projet ! La matrice de responsabilité ci-dessous a été utilisée pour un projet de fiabilisation logistique pour la vente.
Date début
réalisation
Date fin
réalisation
Chantier 1 : Gestion de stocks de vente
Expression des besoins
DURAND / MARTIN
DUBOIS
10
21-janv-07 21-janv-07
Cahier des charges
DUBOIS / SCHMIDT
15
DURAND / MARTIN /
DUBOIS
1,5 1-févr-07
21-févr-07
Développement
Société prestataire SSII
30
Vendeurs (groupe 1)
10 1-mars-07
5-mars-07
Elaboration / Test
Support formation / information
DUBOIS / SCHMIDT
10
Vendeurs (groupe 1)
8
Demultiplication
de la formation
DUBOIS / SCHMIDT
3
Tous les vendeurs
15-mai-07 20-mai-07
50 25-mai-07 25-juin-07
Chantier 2 : gestion des délais logistique
Expression des besoins
DUBOIS / SCHMIDT
15
Cahier des charges
DUBOIS / SCHMIDT
15
DURAND / MARTIN /
DUBOIS
Développement
Société prestataire SSII
40
3 logisticiens
6 10-mars-07 20-mars-07
Elaboration
Support formation / information
DUBOIS / SCHMIDT
10
1 logisticien
3
Auto formation
à partir des supports
31-janv-07
15 logisticiens
1,5 17-févr-07
5-mars-07
25-mai-07 17-juin-07
7,5 15-juin-07 30-juin-07
3.6.5. Les listes de diffusion : projet_tic@entreprise.com
La messagerie électronique s’avère un outil précieux pour le fonctionnement des projets. La création d’une
liste de diffusion (d’une adresse unique pour le groupe projet ou les différents sous-groupes) permet d’assurer une large diffusion des documents.
27
réseau
EDITIONS
En conclusion...
Un constat simple doit conclure ce guide : bien gérer un projet T.I.C., c’est avant tout ... bien gérer un
projet tout court ! Autrement dit, réussir son projet T.I.C. suppose de mener avant tout une gestion de
projet classique de façon rigoureuse.
En effet, dans tout projet, il faut se fixer des objectifs préalables, mener une analyse d’opportunité, délimiter un périmètre d’intervention. Il est ensuite nécessaire de nommer un chef de projet aux compétences
requises, constituer une équipe projet, gérer ses ressources sous contrainte de temps et de budget. On doit
toujours prendre des marges de sécurité, identifier des étapes intermédiaires, faire des points réguliers,
savoir négocier avec les partenaires internes et externes.
Toutes ces tâches constituent le « bon sens » de la gestion de projet, le savoir-faire mobilisé quel que soit
le changement que l’organisation souhaite mettre en œuvre. Les projets T.I.C. n’y font pas exception.
Il conviendra donc de garder ce postulat à l’esprit, car les prestataires de service en informatique ont souvent tendance à faire croire à leurs clients qu’avec les T.I.C., une nouvelle économie était apparue où les
règles du jeu avaient radicalement changé : tout allait plus vite, les années étaient devenues des mois, les
organisations hiérarchiques avaient disparu au profit de start up fusionnelles... et comme par magie les projets T.I.C. allaient se mettre en place tous seuls...
Cette fièvre est maintenant retombée, et les T.I.C. sont revenues dans le rang : les nouvelles technologies
sont des outils au même titre que les autres, et leur efficacité, leur utilité réelle se mesure désormais non
plus au son des lendemains qui chantent, mais à l’épreuve des faits.
Le lecteur pourra relire les chapitres du présent ouvrage, en reconnaissant quels sont les conseils et les
exemples qui relèvent de la gestion de projet « classique ». Il sera sans doute étonné de voir que derrière
les aspects technologiques, nombre de recommandations sont transposables à d’autres types de projet.
Il verra ainsi qu’un projet T.I.C. est avant tout ... un projet « comme les autres ! ».
28
réseau
EDITIONS
29
réseau
EDITIONS
Agence Nationale pour l’Amélioration
des Conditions de Travail
4, quai des Etroits - 69321 LYON Cedex 05
Téléphone : 04 72 56 13 13 - Télécopie : 04 78 37 96 90
Internet : www.anact.fr
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising