Pourquoi un projet numérique se joue avant sa première ligne de code

La situation

Une organisation d’environ trois cents personnes décide de remplacer l’outil qui gère son activité depuis quinze ans. La décision paraît évidente. L’application est ancienne, son ergonomie date, les utilisateurs s’en plaignent régulièrement et l’éditeur annonce la fin du support. Le comité de direction valide un budget et un calendrier.

Dix-huit mois plus tard, le nouvel outil est en production. Il fonctionne. Les données ont été reprises, les utilisateurs ont été formés, le prestataire a livré ce qui figurait au contrat. Personne ne peut dire que le projet a échoué.

Pourtant, quelque chose ne va pas. Deux services ont repris les fichiers Excel qu’ils utilisaient auparavant. Les délais de traitement n’ont pas diminué. Les mêmes réunions de coordination se tiennent, avec les mêmes points de blocage. Et lorsqu’on interroge les responsables métier, la réponse revient sous une forme presque identique : l’outil est plus moderne, mais nous rencontrons toujours les mêmes problèmes qu’avant.

Cette situation est fréquente. Elle ne relève ni d’une faute technique, ni d’un mauvais prestataire, ni d’un défaut de gestion de projet. Elle relève d’un moment antérieur, que personne n’a identifié comme critique : le moment où l’organisation a décidé de remplacer l’outil sans avoir formulé ce qu’elle cherchait à résoudre.

Cette situation ne décrit aucune organisation en particulier. Elle rassemble ce que l’on observe dans beaucoup d’entre elles.

Pourquoi cette situation apparaît

La première raison tient à la confusion entre le symptôme et le problème. Une application vieillissante, des utilisateurs mécontents, un support qui s’arrête : ce sont des symptômes. Ils sont visibles et ils appellent naturellement une réponse. Le problème, lui, est ailleurs. Il peut résider dans des façons de travailler que personne n’a revues depuis dix ans, dans une répartition des responsabilités devenue floue, dans une information saisie deux fois parce que deux services ne se parlent plus. L’outil ancien ne créait pas ces difficultés. Il les rendait visibles. En le remplaçant, on a changé la couleur de la voiture, pas la voiture.

La deuxième raison est plus inconfortable à reconnaître. Choisir une solution est une décision agréable. Elle produit de l’action, elle rassure, elle permet d’annoncer quelque chose. Comprendre un problème ne produit rien de visible pendant plusieurs semaines. Dans une organisation sous pression, le cadrage est alors perçu comme un temps mort avant le vrai projet, alors qu’il en constitue la partie la plus déterminante.

La troisième raison tient au fonctionnement du marché. Lorsqu’une organisation consulte des éditeurs ou des intégrateurs en leur expliquant qu’elle souhaite remplacer son application, elle obtient des propositions de remplacement. Elle n’obtient pas la question qui aurait dû être posée en premier : pourquoi voulez-vous la remplacer, et qu’est-ce qui aurait changé si vous ne le faisiez pas. Ce n’est pas de la mauvaise foi. C’est simplement que la question ne relève pas du rôle de celui qui vend la solution.

Les erreurs fréquemment observées

Traiter le cadrage comme une formalité administrative. Dans beaucoup d’organisations, le cadrage se réduit à un document produit en quelques jours pour justifier une décision déjà prise. Il décrit le périmètre, le budget et le calendrier. Il ne décrit jamais le problème.

Recueillir les besoins comme on recueille des commandes. L’analyse est souvent conduite en interrogeant chaque service sur ce qu’il attend du futur outil. Chacun répond en décrivant l’outil qu’il voudrait, à partir de son poste et de ses habitudes. On obtient une liste de fonctionnalités, parfois contradictoires, jamais une compréhension partagée de ce qui dysfonctionne. La somme des demandes individuelles ne constitue pas un besoin.

Un exemple vaut mieux qu’une démonstration. Dans un laboratoire, un responsable demande une fonction qui génère un tableau de type Excel, dans lequel il encoderait les références des échantillons qu’il aurait transférés dans un lieu de stockage en vue de leur traitement. La demande est précise, réaliste, chiffrable. Elle est aussi la description exacte de sa méthode du moment : au fur et à mesure qu’il déplaçait des échantillons vers le stockage, il en recopiait les références à la main dans un tableur, pour pouvoir les retrouver plus tard. En l’écoutant expliquer non pas ce qu’il voulait mais ce qu’il faisait et pourquoi il le faisait, le vrai besoin apparaît, et il est plus simple : sélectionner les échantillons à traiter pour obtenir l’impression d’une liste de travail permettant d’aller les chercher au moment de leur traitement. La fonction demandée aurait fonctionné. Elle aurait coûté plus cher, elle aurait figé une méthode de travail dans un logiciel neuf, et elle n’aurait rien résolu.

C’est la raison pour laquelle la bonne question n’est pas « que voulez-vous », mais « expliquez-moi ce que vous faites, et pourquoi vous le faites ainsi ».

Confier le cadrage à celui qui vendra la suite. L’intention est rarement mauvaise et le travail est parfois de qualité. Mais un cadrage réalisé par un acteur dont le chiffre d’affaires dépend de la suite du projet ne produira pas une option qui consiste à ne rien faire, ou à faire beaucoup moins.

Reprendre les processus existants sans les interroger. C’est l’erreur la plus coûteuse, parce qu’elle est invisible. On demande au nouvel outil de reproduire ce que faisait l’ancien, y compris des étapes qui n’ont plus de raison d’être. On paie alors pour moderniser des habitudes.

Fermer le périmètre technique trop tôt. Il n’est pas rare que la technologie soit choisie avant l’analyse, pour des raisons de continuité, de relation existante ou de conviction personnelle. Toute la réflexion ultérieure se déroule alors à l’intérieur d’un cadre qui n’a jamais été discuté.

Une approche plus pertinente

L’idée directrice tient en une distinction : trois questions sont habituellement traitées comme une seule, alors qu’elles appellent des temps et des interlocuteurs différents.

Quel est le problème. Il se formule en termes d’effets sur l’organisation, jamais en termes d’outil. Non pas « notre application est obsolète », mais par exemple « le traitement d’un dossier mobilise trois personnes et deux saisies parce que l’information ne circule pas entre le service qui reçoit la demande et celui qui la traite ». Un problème correctement formulé se reconnaît à une propriété simple : il reste vrai si l’on change de technologie.

Quelles décisions l’organisation doit-elle prendre. Un projet numérique est une suite de décisions, dont certaines sont irréversibles. Faut-il harmoniser les façons de travailler entre entités ou préserver leurs particularités. Faut-il reprendre l’historique des données ou repartir d’une base propre. Qui tranche en cas de désaccord entre deux directions métier. Ces décisions relèvent de la direction, pas du prestataire. Les identifier avant le lancement, et désigner qui les porte, évite qu’elles soient prises par défaut au milieu du chantier.

Quelle solution. Elle vient en dernier, et elle vient plus facilement. Lorsque le problème est formulé et les décisions prises, le choix de la solution devient une question technique, comparable et documentable. C’est la partie du travail que le marché sait bien traiter.

Changer de logiciel, c’est l’occasion de tout remettre à plat

Une organisation ne remet presque jamais ses façons de faire en question dans son fonctionnement quotidien. Le changement d’outil est l’un des rares moments où elle s’y autorise, parce que tout est de toute façon appelé à bouger. C’est une occasion qu’il serait dommage de gaspiller.

Concrètement, cela signifie interroger chaque étape d’un processus, non pas pour la critiquer, mais pour comprendre ce qu’elle produit. La réponse « on a toujours fait ainsi » n’est pas une réponse : elle signale une étape dont plus personne ne connaît la raison d’être. Parfois cette raison existe encore, et il faut la documenter. Souvent elle a disparu avec la réglementation, le client ou l’outil qui l’avait rendue nécessaire, et l’étape peut disparaître avec elle. Reproduire à l’identique dans le nouvel outil ce qu’on faisait dans l’ancien revient à payer très cher pour ne rien changer.

Ce travail n’est possible qu’à deux conditions, qui méritent un développement à part entière : que celui qui conduit l’analyse puisse poser les questions inconfortables, et que la direction tranche sur la base de ce qu’il rapporte.

Une conséquence pratique découle de tout ceci. La qualité d’un cadrage ne se mesure pas à la vitesse avec laquelle il aboutit à une solution, mais au nombre d’options crédibles qu’il maintient ouvertes le plus longtemps possible. Un cadrage qui produit trois scénarios contrastés, y compris celui de ne pas remplacer l’outil, a fait son travail. Un cadrage qui confirme la solution pressentie dès le premier atelier n’a servi à rien, sinon à donner une apparence de rigueur à une décision déjà prise.

Les questions à se poser

Avant d’engager un projet numérique, quelques questions permettent de vérifier que le travail préalable a réellement eu lieu.

Sommes-nous capables d’expliquer ce que nous cherchons à résoudre sans nommer une seule technologie ?

Si nous ne faisions rien pendant deux ans, que se passerait-il exactement ? La réponse « ce serait ingérable » n’en est pas une tant qu’elle n’est pas étayée.

Les difficultés que nous constatons proviennent-elles de l’outil, ou de la manière dont nous travaillons avec lui ?

Combien d’étapes de nos processus actuels sommes-nous capables de justifier autrement que par l’habitude ?

Quelles décisions devrons-nous prendre au cours de ce projet, et qui, nommément, les prendra ?

Et enfin, question plus inconfortable : à quel moment avons-nous décidé de la solution, et cette décision est-elle intervenue avant ou après l’analyse ?

Conclusion

Un projet numérique ne commence pas le jour où l’on choisit un outil, ni le jour où le développement démarre. Il commence le jour où l’organisation devient capable de dire, sans nommer de technologie, ce qu’elle cherche à changer dans son fonctionnement.

Tant que cette phrase n’existe pas, tout ce qui suit consiste à moderniser un symptôme. Le résultat peut être techniquement irréprochable et rester sans effet, ce qui constitue la forme d’échec la plus coûteuse : celle que personne ne peut reprocher à personne.