Quel rôle pour le PMO dans la transformation digitale d'une banque d'investissement ?

Pourquoi un PMO dans une banque d'investissement ?

Parce qu'un programme de transformation digitale y touche plusieurs entités qui ont chacune leurs métiers, leurs systèmes et leurs contraintes. Une banque d'investissement réunit souvent une société de bourse pour l'intermédiation, une société de gestion d'actifs et une activité de dépositaire. Les projets de digitalisation, comme la bourse en ligne, les portails clients ou la dématérialisation des processus, traversent ces entités.

Dans ce type de programme, nous intervenons comme PMO transverse. Le rôle consiste à faire avancer ensemble des projets portés par des équipes différentes, avec une DSI commune et plusieurs éditeurs de solutions.

Comment organiser la gouvernance ?

Sur trois niveaux, chacun avec son rôle et sa fréquence.

Le comité opérationnel réunit chaque semaine les chefs de projet, les référents métier et les responsables IT. On y suit l'avancement détaillé, on y traite les points bloquants du quotidien et on y prépare les sujets à remonter.

Le comité de pilotage se tient chaque mois. Il réunit les responsables des entités et la DSI, valide les jalons, arbitre les priorités entre projets et décide des actions correctives lorsque le planning dérive.

Le comité de direction reçoit une synthèse du programme. Il tranche les sujets structurants : budget, changement de périmètre, choix de solution, décalage d'une mise en production visible des clients.

Le PMO prépare et anime ces instances. Il rédige les supports, tient le relevé des décisions et suit les actions décidées jusqu'à leur clôture.

Comment construire un planning qui tient ?

En partant des dépendances. Dans une banque d'investissement, les activités sont liées par les flux : un ordre transmis par la plateforme de la société de bourse se dénoue chez le dépositaire, et les positions alimentent la gestion d'actifs et le reporting aux clients. Un retard dans une entité peut bloquer une mise en production dans une autre.

Le planning consolidé fait donc apparaître trois types de dépendances : entre projets d'une même entité, entre entités, et vis-à-vis des éditeurs. Chaque dépendance a un responsable et une date. Lorsqu'une dépendance glisse, le PMO en mesure l'effet sur l'ensemble du programme avant le comité suivant, ce qui permet d'arbitrer en connaissance de cause.

La définition du planning se fait avec les équipes métier et IT. Les dates qu'elles ont elles-mêmes proposées sont celles qu'elles défendent ensuite en comité.

Quel reporting produire pour les comités ?

Un reporting court, régulier et fondé sur des critères écrits. Nous utilisons un reporting RAG, rouge, orange, vert, par projet et par dimension : délai, périmètre, budget, risques.

Le point faible de cette méthode est la subjectivité. Un chef de projet optimiste affiche du vert jusqu'à la veille d'un retard. Nous fixons donc des critères de passage explicites : un jalon décalé de plus d'un certain délai fait passer en orange, une dépendance bloquée sans solution fait passer en rouge. Les critères sont validés en comité de pilotage et appliqués à tous les projets.

Les tableaux de bord présentés en comité de direction tiennent sur peu de pages. Ils montrent l'état global, les décisions attendues et les risques majeurs. Le détail reste disponible pour le comité opérationnel.

Comment suivre le budget et les risques du programme ?

Avec la même régularité que le planning. Le budget est suivi par projet et par entité : engagé, consommé, reste à faire. Les écarts significatifs sont présentés en comité de pilotage avec leur cause, qu'il s'agisse d'un changement de périmètre, d'une charge sous-estimée ou d'une prestation supplémentaire demandée à un éditeur.

Les risques sont déclarés par les chefs de projet dans leur reporting, avec une criticité choisie dans une échelle simple, un responsable et une action de maîtrise. Le PMO les consolide et repère ceux qui concernent plusieurs projets à la fois, comme la disponibilité d'un même expert métier ou une fenêtre de mise en production partagée. Ces risques transverses sont ceux que les chefs de projet voient le moins, puisque chacun ne regarde que son propre périmètre.

Comment travailler avec les éditeurs ?

Comme avec une équipe projet à part entière, avec la même exigence. Les éditeurs livrent des versions, corrigent des anomalies, accompagnent les déploiements. Leur calendrier conditionne souvent celui du programme.

Le PMO assure l'interface opérationnelle : suivi des livrables promis et des dates engagées, coordination des déploiements avec les équipes IT de la banque, résolution des points bloquants. Un registre des engagements de chaque éditeur est tenu à jour et présenté en comité lorsque les retards menacent un jalon. L'escalade suit un circuit défini à l'avance, ce qui évite qu'un désaccord technique reste sans arbitrage pendant des semaines.

Quand commence la conduite du changement ?

Dès le cadrage. Les utilisateurs des différentes entités sont associés à l'expression des besoins et aux recettes. Ce sont eux qui valident que la solution répond à leurs usages.

Avant chaque mise en production, nous préparons la formation des utilisateurs, la communication auprès des équipes et des clients lorsque c'est nécessaire, et l'assistance des premières semaines. Dans des activités réglementées comme l'intermédiation boursière ou la conservation de titres, une mise en production mal préparée peut avoir des conséquences directes sur les clients et sur la conformité.

Le PMO veille enfin à ce que les procédures soient mises à jour en même temps que les outils. Un processus digitalisé sans procédure révisée laisse les équipes appliquer d'anciennes règles dans un nouvel outil.