Certains projets arrivent à la DSI avec une demande apparemment précise. Il faut implémenter une application ou la remplacer, automatiser un processus, déployer un nouvel outil ou connecter plusieurs systèmes. Le besoin a été exprimé, le budget estimé et une date de démarrage circule déjà.
Puis le projet avance et sa véritable nature apparaît. Il faut revoir des règles de gestion, nettoyer les données, harmoniser des pratiques que chaque entité avait organisées à sa manière. Il faut aussi convaincre les utilisateurs et décider comment l’activité fonctionnera demain. La technologie occupe une place importante, mais elle ne répond à aucune de ces questions à la place de l’entreprise.
Pourtant, le projet reste présenté comme informatique. La DSI en devient progressivement propriétaire parce qu’un logiciel figure dans la solution et que bien souvent, la gestion du projet lui revient. Elle organise les ateliers, relance les participants, cherche les arbitrages et finit parfois par proposer elle-même des décisions que les métiers n’ont pas prises.
Quelques mois plus tard, elle court après des validations qui n’arrivent pas. Les représentants métiers manquent les ateliers parce que l’activité opérationnelle passe avant le projet. Les règles de gestion restent ouvertes, mais la date de livraison ne bouge pas. Lorsque le planning commence à glisser, les regards se tournent vers l’informatique.
C’est à ce moment-là que la DSI doit parfois rendre le projet à son véritable propriétaire.
Le logiciel ne définit pas le projet
Un nouvel ERP touche aux achats, aux stocks, à la production, à la finance et parfois à la relation client. Un CRM oblige à préciser la manière de qualifier les prospects, de partager l’information commerciale et de suivre les engagements. Un SIRH soulève des questions de responsabilité managériale, de confidentialité et d’organisation du travail.
La DSI intervient sur l’architecture, les intégrations, la sécurité, les données et les conditions d’exploitation. Elle apporte aussi son expérience des projets complexes et voit des dépendances que chaque direction, concentrée sur son propre périmètre, distingue moins facilement. Elle ne peut cependant pas décider seule qui valide une commande, quelles données commerciales deviennent obligatoires ou comment les responsabilités seront réparties entre deux services. Ces choix appartiennent aux directions qui devront ensuite assumer le fonctionnement et les résultats.
La confusion commence souvent dans le vocabulaire. Nous parlons du « projet SAP », du « projet CRM » ou du « projet Workday ». Le nom de l’outil remplace celui de la transformation et finit par orienter toutes les discussions. On parle paramétrage, interfaces et calendrier de déploiement alors que les règles de fonctionnement restent floues.
Je préfère nommer un projet par le résultat recherché. « Réduire le délai de clôture » donne une direction plus utile que « migrer l’ERP ». « Fiabiliser les prévisions commerciales » oblige à parler de données, de pratiques et de responsabilités avant de parler du CRM. Les mots rappellent pourquoi l’investissement a été autorisé et qui en attend un bénéfice.
Un sponsor doit décider
Le sponsor métier ne prête pas simplement son nom au projet. Il porte l’objectif, tranche les choix qui engagent son activité et mobilise les personnes dont la participation est indispensable. Lorsque deux directions défendent des pratiques incompatibles, il doit obtenir l’arbitrage. Lorsque les utilisateurs ne sont pas disponibles, il doit protéger le temps nécessaire.
Cette responsabilité demande davantage qu’une présence au lancement et au comité trimestriel. Les décisions difficiles apparaissent tout au long du projet. Elles concernent la standardisation des pratiques, la propriété de la donnée, les exceptions que l’on accepte de conserver et celles que l’on décide enfin de supprimer. Elles touchent parfois à des habitudes anciennes ou à des équilibres de pouvoir que l’outil rend soudain très visibles.
Le Project Management Institute recommande d’identifier le propriétaire des bénéfices attendus et de lui attribuer explicitement la responsabilité de leur réalisation. Prosci considère également le sponsor principal comme le dirigeant qui autorise le changement et répond des résultats recherchés.
Un sponsor absent laisse un vide que la DSI essaiera souvent de combler. Elle le fera pour éviter le retard, protéger les équipes et tenir l’engagement annoncé au COMEX. Cette bonne volonté entretient pourtant une illusion dangereuse : le projet semble avancer alors que personne ne porte réellement la transformation.
Le réflexe de compensation
Les équipes de la DSI savent faire avancer les sujets. Elles structurent, organisent, relancent et documentent. Quand une décision manque, elles proposent une hypothèse. Quand le métier tarde à répondre, elles cherchent une solution temporaire afin de ne pas bloquer l’intégrateur.
Ce réflexe est utile pendant une période courte. Il devient risqué lorsque l’exception se transforme en fonctionnement normal. Les développements se poursuivent alors sur des règles provisoires. Les maquettes sont validées par trop peu de personnes. Des décisions d’organisation se glissent dans les choix de paramétrage, sans avoir été véritablement débattues. La progression technique masque le retard pris sur le fond.
Le problème réapparaît pendant la recette ou juste avant le déploiement. Les utilisateurs découvrent un processus auquel ils ont peu participé. Les responsables contestent des choix qu’ils avaient laissés sans réponse. La formation tente d’expliquer une organisation qui ne fait pas encore consensus et les demandes de modification arrivent lorsque chaque changement coûte plus cher.
La DSI se retrouve alors tenue responsable d’une solution qu’elle a construite avec des décisions incomplètes. Son désir initial d’aider a fini par brouiller les rôles.
J’ai appris à me méfier des projets qui avancent trop longtemps sans sponsor actif. Quelques semaines de pause pour obtenir une décision coûtent moins cher que plusieurs mois de développement autour d’une organisation que personne n’assume.
Savoir rendre le projet
Rendre un projet à son propriétaire ne consiste pas à déposer le dossier sur un bureau avec une liste de reproches. Il faut établir les faits : les décisions encore ouvertes, les ateliers qui n’ont pas eu lieu, les données qui n’ont pas de propriétaire et les validations attendues. Il faut aussi montrer l’effet de chaque blocage sur le coût, le périmètre et le calendrier.
La formulation compte. Dire que « le métier ne fait pas son travail » installe une confrontation stérile. Je préfère expliquer que l’équipe projet a atteint la limite de ce qu’elle peut décider avec son mandat actuel. La DSI peut éclairer les choix et en mesurer les conséquences. Elle ne peut pas fabriquer seule la légitimité qui manque.
Le sponsor dispose alors de plusieurs possibilités. Il peut mobiliser les bons interlocuteurs, réduire le périmètre, déplacer la date ou demander une suspension. Ce choix lui appartient. Continuer sans réponse, simplement pour préserver le planning officiel, ne devrait pas en faire partie.
Il m’est arrivé de devoir interrompre des travaux. La décision est rarement confortable, surtout lorsqu’un budget a déjà été engagé et qu’une échéance a été annoncée. Elle reste préférable à la poursuite d’un projet dont les conditions de réussite ont disparu.
Suspendre permet parfois de sauver l’investissement. Les équipes reviennent avec des règles clarifiées, un sponsor présent et un périmètre enfin réaliste. Continuer par peur d’assumer un retard conduit souvent à livrer une solution dont personne ne veut vraiment prendre possession.
La DSI reprendra sa place dès que le projet retrouvera la sienne. Avec un sponsor qui décide, des métiers qui participent et un résultat dont quelqu’un accepte de répondre.
Sans cela, il reste un logiciel en construction. Et je ne laisserai pas la DSI porter seule l’échec d’une transformation que l’entreprise n’a pas voulu conduire.
