ANACT systèmes d’information et d’intranet Mode d'emploi

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

OCUMENTS

E

TUDES ET

D D

OCUMENTS

EDITIONS

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

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.

2

* 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 1 er décembre 2003 - co-éditions Anact/Liaisons sociales

EDITIONS

ES ÈR TI MA

T

ABLE DES

M

S

ATIÈRES

BL TA

Objectifs et contenu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 4

1

re

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

2

e

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

3

e

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

4

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 importantes 2 .

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

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 œuvre

3

• 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

6

EDITIONS

1

re

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

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

8

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.

EDITIONS

2

e

partie

Le déroulement type des projets de systèmes d’information

2.1. Quelle proposition de démarche ?

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 :

{

1 re 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

{

2 e 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

10

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 2 e 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

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’organisation

4

:

• 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

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.

12

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 2 e 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).

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

14

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é

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

16

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 ;

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

18

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.

EDITIONS

3

e

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

20

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éten-

tion 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 ?

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

Entreprise

« absorbée » adoptant le S.I. d’une autre entreprise

Entreprise modifiant son organisation et son S.I. à la suite d’un audit stratégique

Changement d’organisation dans une direction, un service

Volonté de faire

évoluer le S.I.

Volonté de développer l’usage d’un nouvel

équipement

Volonté de s’inscrire sur la vague technologique de l’intranet

Exemple

Intégration dans un ERP de la maison-mère

Mise en place d’un centre d’appels

Informatisation de la force de vente

Mise en place d’un nouveau canal de vente

Migration de progiciels hétérogènes sur une plate-forme unique

Installation d’une messagerie instantanée (IM)

Suppression du papier dans toute l’organisation

Dominante du projet

Projet d’intégration

Équilibre projet organisationnel / projet technique

Projet stratégique

Équilibre projet organisationnel / projet technique

Projet « métier »

Projet à dominante organisationnelle

Projet

« *Schéma Directeur »

Projet à dominante technique

Projet « *appropriatif »

Projet à dominante organisationnelle

Projet « *visionnaire »

Équilibre projet organisationnel / projet technique

Enjeux du projet

Conduite de projet

Changement global de culture, d’organisation, de S.I.

Adaptations et ajustements mutuels de l’organisation et de la technique

Adaptation du S.I.

au changement d’organisation conduite fortement structurée conduite structurée conduite structurée

Chef de projet

« Binôme »

Chef de projet utilisateur / Chef de projet informatique

« Binôme »

Chef de projet utilisateur / Chef de projet informatique

Chef de projet utilisateur

Accompagnement organisationnel du projet informatique

Développement d’usages

Projets portés par les utilisateurs

Maintien du lien entre objectifs globaux et mise en œuvre locale conduite structurée conduite faiblement structurée conduite fortement structurée

Chef de projet informatique

Chef de projet utilisateur

« 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

22

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’adresse à 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.

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

Projet intégré de type ERP

Sites Internet et Intranet

Bureautique communicante

Toute l’entreprise, mais la lourdeur de mise en œuvre recommande de bien cerner la faisabilité au départ.

Temporalité

Durée longue

(un an ou plus).

Ressources

Implication forte de la direction.

Ressources internes et externes souvent très importantes.

Possibilité de mise en place incrémentale, mais définir au

Durée variable, mais en général départ des règles et pouvoir assez courte si

évoluer vers la notion de portail.

l’infrastructure existe déjà.

Importance des ressources internes pour définir et alimenter les services.

La dimension organisationnelle La durée de mise Importance des est prédominante, car les outils en place dépend ressources existent déjà en général du service fourni et managériales et en de la « réceptivité » accompagnement des utilisateurs. 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

24

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) ?

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

• Définition des positions de travail, répartition paramétrage des autorisations

• Emplois, compétences

• Formation métier

• Apprentissage organisationnel

Mise en place du S.I.

• Implantation des postes de travail, des tâches, circuits de communication

• Conception de la documentation, des aides en ligne

• Formation informatique

• 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

26

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

EDITIONS

3.6.4. Les matrices de responsabilité

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.

Réalisation Validation / Recette

Date début Date fin réalisation réalisation

Chantier 1 : Gestion de stocks de vente

Expression des besoins DURAND / MARTIN 10

DUBOIS

Cahier des charges

Développement

Elaboration / Test

Support formation / information

Demultiplication de la formation

DUBOIS / SCHMIDT 15 DURAND / MARTIN / 1,5 1-févr-07 21-févr-07

DUBOIS

Société prestataire SSII

30

DUBOIS / SCHMIDT 10

Vendeurs (groupe 1)

Vendeurs (groupe 1)

10 1-mars-07

8

5-mars-07

15-mai-07 20-mai-07

DUBOIS / SCHMIDT 3

Tous les vendeurs

21-janv-07 21-janv-07

50 25-mai-07 25-juin-07

Chantier 2 : gestion des délais logistique

Expression des besoins

Cahier des charges

DUBOIS / SCHMIDT 15 31-janv-07

DUBOIS / SCHMIDT 15 DURAND / MARTIN / 1,5 17-févr-07 5-mars-07

DUBOIS

Développement

Elaboration

Support formation / information

Société prestataire SSII

40

DUBOIS / SCHMIDT 10

3 logisticiens

1 logisticien

6 10-mars-07 20-mars-07

3 25-mai-07 17-juin-07

Auto formation

à partir des supports

15 logisticiens

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

28

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 ! ».

EDITIONS

29

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