Une dissémination problématique

Pour intéressant qu’ils puissent paraître, les résultats précédents manquent de plans d’actions concrets. Comme cela est mentionné au début de cet exposé, la description de la phase de communication dans la proposition initiale ne comprenait pas non plus d’indication précise validée. Le directeur de programme exprime néanmoins le souhait de lancer une diffusion plus large à son niveau.

Je conviens avec lui que les acteurs du programme devraient avoir en priorité connaissance des résultats de nos travaux, auxquels plusieurs avaient contribué au travers des entretiens. Cette communication, la première action de cette dernière phase, consistait en une présentation d’une trentaine de minutes au « comité de programme », instance réunissant les responsables directement

impliqués dans les divers services, y compris ceux de la direction informatique et ceux des services territoriaux en charge du programme. Le titre choisi pour cette intervention est :

« Quelques enseignements sur la transversalité et la conduite de projet avec l’expérience PG ».

Le directeur de programme, en accord avec le responsable des SI réseaux, me demande d’assurer cette présentation en fin de réunion du comité, en présence du DE réseaux. La communication a lieu en novembre 2003, le surlendemain de la restitution institutionnelle rapportée ci-dessus.

Le DE réseaux, les membres du groupe de retour d’expérience, s’ils ne présentent pas, se montrent solidaires de la présentation. Ils interviennent dans la réponse aux questions.

Le buffet servi aussitôt après la réunion du comité permet de mesurer immédiatement que l’effet de cette présentation est très contrasté :

Les acteurs de la direction de programme, rattachés hiérarchiquement au directeur de programme, se déclarent frustrés, et expriment clairement à celui- ci la demande d’une restitution plus complète, ainsi que la diffusion des documents écrits : récit, repères, monographies. Quant aux acteurs territoriaux, ils n’ont pas compris, le temps de présentation étant trop court pour des messages sans doute intéressants, mais auxquels ils n’avaient pas été préparés (ce sont leurs mots).

Les acteurs de la DSI, qui avaient élaboré de leur côté, selon les règles en vigueur dans leur organisation, un rapport technique sur les difficultés rencontrées au fil du programme, ne se sentent pas concernés par la restitution, très orientée en effet sur les modes de coopération, de décision, et de façon générale, sur les problèmes managériaux.

L’encadré ci-après permet de se pencher sur le contenu du retour d’expérience des informaticiens, considéré par eux comme « ayant fait le tour de la question ». On vérifiera que ce travail, très utile aux acteurs du SI, est cependant très centré sur leurs préoccupations. Il laisse de côté en particulier

les questions de stratégie du programme, de pilotage global, de transversalité, par exemple, qui sont en revanche au coeur du « retour d’expérience » PG.

Le « Bilan d’étape », retour d’expérience des acteurs de la DSI

Ce bilan renvoie à une procédure formelle, imposée par la DSI du groupe. Il est réalisé à l’issue d’étapes clés, fixées en début de programme. Bien qu’il donne lieu à des entretiens avec des acteurs métiers, qu’il soit donné en lecture pour validation au directeur de programme, les destinataires sont les responsables de la DSI. (Pour l’anecdote, le directeur de programme PG n’a pas validé le document qui lui avait été soumis, qui comprenait un certain nombre de points de désaccord ; le document a été néanmoins diffusé au sein de la DSI).

Le plan du document est le suivant :

1. Rappel du contexte (les enjeux, le SI)

2. Principales actions engagées et résultats obtenus (au niveau du produit, des fonctionnalités offertes, des tests, des migrations, de l’organisation interne et des ressources)

3. Principaux indicateurs (délais, finance, gestion, maîtrise des risques) 4. Synthèse des avis des acteurs hors SI réseaux (métier, exploitants)

5. Axes de capitalisation (pour chacun des domaines : maîtrise du produit ; maîtrise du projet, et pour un ensemble d’activités type, repérage de points forts, points faibles, et proposition d’actions)

Le dernier paragraphe constitue le cœur du document : il fournit des directives concrètes, mais centrées sur les seules équipes informaticiennes. Si le directeur de programme n’a pas voulu valider ce document, c’est que, d’une part, le paragraphe 2 ne fait état que des initiative DSI, en égratignant à l’occasion la maîtrise d’ouvrage :

« Par souci d’économie (contraintes maîtrise d’ouvrage), la stratégie d’utilisation des plateformes de test a sans cesse évolué.. »

« La maîtrise d’ouvrage a eu tendance à limiter ses décisions au seul domaine fonctionnel XXX »

D’autre part, une bonne partie des indicateurs du paragraphe 3 sont empruntés à la direction de programme, et sont en fait des indicateurs de la maîtrise d’ouvrage, sans valeur ajoutée sur la gestion interne de la DSI,

Les impressions précédentes, recueillies à chaud à l’issue de la présentation en comité de programme, sont restituées au directeur de programme cinq jours plus tard. Cette restitution convainc ce dernier qu’il avait fait une erreur dans le choix du contexte de cette présentation (un comité pluridisciplinaire réuni sur des sujets opérationnels d’actualité), et de la durée imposée à la présentation, encore réduite dans les faits (un quart d’heure). Il comprend l’opinion des responsables territoriaux :

« Ils n’ont compris qu’une partie du message : ils sont pris par le quotidien ». Mais il s’interroge sur la réaction des informaticiens, décidément beaucoup moins enclins à partager les problèmes de la maîtrise d’ouvrage que leur supérieur hiérarchique, le responsable des SI réseaux, malgré tout ce qui avait été dit et écrit sur la « transversalité » et les échanges interdisciplinaires :

« Ils ne tirent aucune fierté de cette coopération avec la maîtrise d’ouvrage ».

Pour ce qui concerne ses collaborateurs au sein de la direction de programme, il décide d’accéder à leur demande de diffusion des écrits du retour d’expérience. Mais il impose une présentation préalable de deux heures. Cette présentation aura lieu le en décembre 2003. Le but de cette séance est à la fois de redonner aux acteurs présents une version intégrale de la restitution officielle de novembre, mais aussi de préparer les esprits à la lecture des écrits, notamment du récit.

En effet, les premiers commentaires laissaient supposer que les responsables de la direction de programme seraient intéressés avant tout par la place qu’ils occuperaient eux-mêmes dans le récit. La présentation orale des résultats, préalable à la diffusion des écrits, visait donc en particulier à avertir les futurs lecteurs que leurs actions individuelles n’étaient que très partiellement rapportées, uniquement dans la mesure où elles éclairaient la dynamique collective. Nous n’avons pas d’éléments précis sur la façon dont cet avertissement a été compris. Mais la présentation des monographies a rencontré un réel intérêt des participants.

Une seconde opportunité de communication se présente pour le directeur de programme. Cette communication représente pour lui un enjeu sensiblement plus important. Elle nous est annoncée lors du « débriefing » précédent. Elle devait prendre place dans une réunion formelle rassemblant l’ensemble de la hiérarchie de la direction des réseaux.

La durée de l’exposé, imposée par les organisateurs, est limitée à une vingtaine de minutes. Le thème de la journée, également imposé, concerne le « management par les processus ». Ce sujet est perçu comme ambigu et controversé, mais interprété dans le contexte de la direction des réseaux comme permettant l’instruction d’une réorganisation à venir. Le DE réseau est décrit comme très attaché à cette réunion, que chacun prépare dans le plus grand secret, ce qui est une source d’anxiété pour le directeur de programme : « Il est probable que des changements majeurs se préparent. Le DE Réseau a quelque chose en tête ».

Dans ce contexte, la présentation est assurée par le directeur de programme lui-même. Mais il me demande de l’aider à la lui préparer. Le titre qu’il a voulu donner à cette intervention s’intitule : « PG : quels enseignements ? ».

Cette intervention ne suscite sur le moment aucune réaction notable. Le directeur de programme a choisi de cibler son exposé sur les questions de coopération pluridisciplinaire, illustrées tant dans le programme lui-même (la « transversalité projet ») que dans les « processus métiers ». Contrairement à ce qui s’est passé lors de la restitution formelle de novembre en présence du DSI, le DE réseaux ne fait pas de commentaire en séance. Quelques jours plus tard, ce dernier réaffirme la responsabilité des directions de métiers et confirme l’arrêt prochain du programme, après transfert des acquis.

La logique de confirmation de la responsabilité des directions de métier vis-à-vis des acquis du programme nous a semblé, sur le moment, incompréhensible et décevante. En première analyse, elle peut même sembler en opposition avec le nouveau paradigme qui préconise une synergie étroite entre maîtrise d’œuvre et maîtrise d’ouvrage, plutôt qu’une relation d’autorité. Nous pensons après réflexion que ce n’est pas la bonne analyse.

En effet, d’une part cette coopération étroite vise des projets innovants à forte incertitude : lorsque les outils sont maîtrisés, tant par l’informatique que par les utilisateurs, il n’y aucune raison de ne pas revenir aux méthodes de délégation classiques. D’autre part, les directions de métier comportent en leur sein des équipes dédiées à la relation avec la DSI : elles sont donc structurellement en mesure de garder un contact étroit avec la maîtrise d’œuvre jusqu’au moment où les principales interrogations ont été levées, sans qu’il soit nécessaire de faire des démonstration d’autorité.

Ce résultat tend à montrer à la fois que le retour d’expérience a vraisemblablement aidé le DE réseaux à forger son opinion et à affirmer ses positions, tant en interne que vis-à-vis de ses pairs, et en particulier du DSI. Mais il semble que le directeur de programme n’ait finalement pas tiré de l’opération le bénéfice qu’il en escomptait, du moins en ce qui concerne la reconnaissance institutionnelle de son rôle, et l’accès à une porte de sortie conforme à ses ambitions. Pour autant, de son propre avis, il tire un bénéfice personnel de ce travail, par une compréhension en profondeur de ce qui s’est passé. Il a le sentiment d’un accroissement significatif de sa propre compétence sur la gestion de projet.

Mais le caractère impromptu et opportuniste des demandes de communication démontre l’absence de véritable exigence de dissémination des résultats, contrairement à ce qui figurait dans l’offre initiale.

Malgré cela, et contre toute attente, les résultats précédents semblent satisfaire tout le monde, en tout cas le directeur des réseaux et les membres du groupe - sauf moi. Bien sûr, le mépris avec lequel ses équipes d’informaticiens ont accueilli la présentation orale a agacé le responsable des SI réseaux. Mais celui-ci met ce résultat sur le compte du temps de présentation (trop court), et sur une forme de compétition qui se serait manifestée entre notre « retour

d’expérience » et le travail de bilan technique réalisé par les équipes informatiques. Il ne cherche pas non plus, sur le moment, à poursuivre l’effort de communication.

Je ne voyais pas bien comment le travail réalisé, assez conséquent tout de même, allait servir à l’organisation. C’est l’éléphant qui accouchait d’une souris.

Devant cette situation, je suggère une diffusion du récit. Ceci est fait, mais je dois rapidement me rendre à l’évidence : le récit écrit, d’une cinquantaine de pages, finalement distribué aux principaux acteurs du projet qui ont été interrogés au début du « retour d’expérience », semble destiné à finir dans les armoires, comme si, une fois couché par écrit, la connaissance accumulée, décrite comme telle par les trois principaux acteurs du programme, perdait tout intérêt.