Quand une direction financière construit une application de pilotage, elle y consacre du temps et un certain budget. Et si l’application, construite sur-mesure, n’est pas ou plus utilisée au bout de quelques temps par les équipes utilisatrices, alors se pose la question de la refonte de l’application ou d’un changement d’outil.
On associe souvent le non-usage d’une application à un mauvais choix de l’outil. Cependant, la problématique d’un outil peu ou pas utilisé vient souvent d’ailleurs : une construction qui ne répond pas aux besoins exprimés, une application trop complexe pour l’usage, des besoins qui ont évolués, un manquement des utilisateurs finaux dans la prise en main, une résistance au changement…
Les outils, eux, peuvent tout faire, à condition que l’équipe projet ait bien pris en compte les besoins fonctionnels. Les points essentiels résident plutôt dans la bonne compréhension et rédaction des spécifications, la logique de la modélisation en amont et la bonne documentation de l’application… Quand ces conditions ne sont pas réunies, se pose le choix entre une refonte totale ou une capitalisation sur l’existant. Les consultants Intis nous racontent leur expérience d’accompagnement de leur client dans le choix de la restructuration de leur application.
Interview de Corentin, consultant confirmé en pilotage de la performance
Le contexte
Tu as repris une application de pilotage peu utilisée chez l’un de tes clients. Quel était le contexte ?
« Les spécifications de l’application, élaborée en méthode agile, avaient été faites avec le client, Responsable du Contrôle de gestion. Par ailleurs, son équipe utilisait peu l’application et avec de grosses difficultés. Aucun utilisateur clé n’avait participé à la conception. Côté intégrateur, un chef de projet et un développeur en autonomie sur le projet accompagnaient le client. »
Comment expliquer l’utilisation laborieuse de cette application de pilotage ?
« Il y a deux raisons qui peuvent l’expliquer. D’une part, les besoins exprimés par le client changeaient continuellement et ses exigences évoluaient dans le temps. Des couches et surcouches s’ajoutaient jusqu’à obtenir une usine à gaz, avec un budget largement dépassé et des difficultés à recetter le projet. L’équipe projet a donc passé beaucoup de temps, pour répondre aux besoins du client, sur des choses finalement peu utiles à l’usage prévu. Le client a donc obtenu une application très lente, très rigide, assez peu évolutive, truffée d’erreurs techniques et fonctionnelles. D’autre part, le développement technique de la solution était complexe et rendait l’application peu performante. »
Les actions correctives : le choix d’une refonte
Comment avez-vous géré l’application une fois ces difficultés constatées ?
« Au départ, le client ne souhaitait pas refondre l’application car il avait utilisé le budget alloué pour sa mise en œuvre. Il était difficile de se dire, et d’expliquer en interne, qu’il fallait recommencer. Pendant longtemps, nous avons mis des pansements, corriger des erreurs, avec pour conséquence de rajouter de la complexité à l’outil.
La préconisation était de refaire l’application. Cela a fini par arriver quand nous nous sommes heurtés à de nouveaux besoins qui ne pouvaient être ajoutés à l’application existante, notamment la création d’un nouvel axe d’analyse. Il a alors été facile de démontrer qu’il était plus simple et plus rapide de refondre l’application que d’ajouter des pansements sur l’existant. Reconstruire se justifie particulièrement lorsque le besoin évolue. »
Le travail fourni sur la première version de l’application a-t-il tout de même été utile ?
« Oui, car grâce au travail effectué en amont, nous avons pu obtenir une vision globale dès le début de la refonte. Quand on démarre de zéro, il est plus difficile d’avoir une vision du produit fini ou de la demande finale, puisque l’on avance brique par brique, sans visibilité sur la suite.
La première version de l’application a permis de savoir exactement ce que l’on voulait faire et comment l’obtenir. Nous avons pu bénéficier de l’expérience à la fois du client et des consultants, qui ont tirés les conclusions de ce qu’il fallait éviter de reproduire. L’ effet d’apprentissage des équipes et le fait d’avoir bien documenté le projet précédent a permis d’obtenir une nouvelle application plus simple, plus rapide et plus souple. On a également pu constater que refaire l’application a coûté moins cher que de faire évoluer l’existant car l’écart avec les nouveaux besoins était trop grand. »
Les conseils
De manière plus générale, dans quels cas conseillerais-tu de reconstruire une application et dans quels cas préconiserais-tu de faire évoluer l’existant ?
« Cela dépend de comment l’application est construite. Si celle-ci permet d’absorber les nouveaux besoins et qu’elle est bien documentée, on peut la faire évoluer sans trop de difficultés. En revanche, si les attentes ont évolué et que les nouveaux besoins à intégrer sont importants, il ne faut pas hésiter à refaire une application, surtout en sachant que ce qui a déjà été fait n’est pas forcément perdu.
Si une application n’est pas utilisée mais qu’elle répond aux besoins alors on peut supposer qu’il y a eu une mauvaise interprétation des besoins des utilisateurs. C’est pour cela que la participation des utilisateurs finaux dans l’expression des besoins est fondamentale.
Dans le cas d’une application qui rencontre des problématiques de performance, on peut conserver l’existant et chercher à l’optimiser. Il est tout à fait possible de refondre un processus tout en conservant la structure de l’application. J’ai rencontré ce cas sur des applications jugées sous-performantes car trop lentes. Il nous a suffit de modifier le processus métier d’un lien en temps réel, par règles de calculs, à un transfert de données quand nécessaire, par processus. Le temps réel peut être utile, mais lorsqu’il s’agit de récupérer des données historiques, cela n’a pas toujours de sens. La structure est inchangée, les données sont les mêmes, mais la réactivité et la performance de l’application ont été décuplées… »
Interview de Xavier, consultant senior en pilotage de la performance financière
Quelles raisons rencontre-t-on souvent expliquant la non-utilisation d’une application qui correspond pourtant aux besoins exprimés ?
« L’une des raisons peut être le manque de maîtrise et d’implication des utilisateurs sur des outils. J’ai pu l’observer suite à la mise en place d’un outil de BI, qui avait pour objectif de produire des reportings très poussés. Bien qu’il y ait eu des sessions de formation, les utilisateurs n’utilisaient pas la solution et demandaient aux consultants d’exploiter cette application pour sortir leurs rapports. L’application leur aurait pourtant permis d’analyser les chiffres dans le détail avec différents critères, en totale autonomie. »
Comment implique-t-on les utilisateurs ?
« Pour tout outil, il faut prendre le temps d’apprendre à le maîtriser. Il peut y avoir un malentendu car les outils sont souvent adoptés avec l’idée qu’il fait tout, qu’il n’y a rien à faire. L’investissement des utilisateurs dans la prise en main est pourtant essentiel. Lors de ce projet BI, l’expression du besoin avait été centralisé par un utilisateur, ce qui a peut-être empêché le reste de l’équipe de s’embarquer dans le projet.
Impliquer plus de monde et être en direct avec l’utilisateur final aurait peut-être été judicieux. La difficulté est qu’il faut tout de même garder une certaine harmonisation des usages de l’outil. L’objectif est que toute l’équipe adopte la même vision, la même méthode. Il est risqué de basculer dans l’hyper-personnalisation, en répondant à toutes les demandes des différents utilisateurs.
Il existe également une résistance au changement liée à l’utilisation de l’outil précédent, que les utilisateurs maîtrisent parfaitement, en général Excel. Continuer à utiliser l’ancien outil crée une résistance car l’équipe sait qu’elle a la possibilité de contourner le nouvel outil. Si on instaure une coupure réelle, que l’usage du nouvel outil est encouragé et l’ancien mis de côté, les utilisateurs finaux seront plus enclins à investir la nouvelle application.
Les consultants en régie représentent également une facilité pour répondre aux demandes, favorisant la dépendance des utilisateurs à un tiers. »
Comment permettre la réutilisation d’une application qui correspond aux besoins initiaux ?
« Avant tout, il est nécessaire de comprendre pourquoi l’application n’est pas utilisée. Il est ensuite important de faire comprendre que l’implication des utilisateurs est primordiale dans l’adoption du nouvel outil.
L’accompagnement joue un rôle extrêmement important. Cela suppose de pas faire pour eux, mais avec eux. Il faut donc prévoir une période d’accompagnement conséquente pour les guider dans la découverte de l’outil. »
