Convaincre sa direction d'investir dans une application métier

Je vois régulièrement d’excellents projets refusés, et de moins bons acceptés. La différence tient rarement au projet lui-même — elle tient à la façon dont il a été présenté.

Voici ce qui fonctionne, du point de vue de quelqu’un qui aide à préparer ces dossiers.

L’erreur de départ

Présenter le coût du projet en premier.

Une direction qui entend « 180 000 € » sans point de comparaison compare ce chiffre à zéro. Zéro gagne toujours : ne rien faire semble gratuit.

Or ne rien faire coûte quelque chose. Ce coût est simplement invisible, parce qu’il est réparti en heures perdues, en erreurs rattrapées et en occasions manquées, et qu’il ne figure sur aucune ligne budgétaire.

Le travail consiste à le rendre visible. À partir de là, la conversation change de nature : on ne compare plus un devis à zéro, on compare deux coûts.

Chiffrer la situation actuelle

Quatre postes, à documenter avec des chiffres même approximatifs — un ordre de grandeur assumé vaut mieux qu’une précision inventée.

Le temps perdu. Combien de personnes, combien de minutes, combien de fois. Une ressaisie de dix minutes, trois fois par jour, pour quatre personnes, représente environ 500 heures par an. Valorisées à un coût horaire chargé, cela se chiffre.

Les erreurs et leur rattrapage. Combien de factures corrigées par mois, combien d’avoirs, combien de temps pour les traiter. Ces chiffres existent souvent déjà en comptabilité.

Ce qu’on ne peut pas faire. Un devis qu’on met trois jours à sortir alors qu’un concurrent répond en une heure. Une information que personne ne sait extraire. C’est le poste le plus difficile à chiffrer et souvent le plus important.

Le risque. Un fichier critique sur un seul poste, une personne unique à savoir faire tourner un processus. Ce n’est pas un coût annuel mais un risque, et il se présente comme tel.

Le dossier, en une page

Le problème, en trois lignes. Factuel, sans emphase.

Ce que la situation actuelle coûte par an. Le tableau des quatre postes, avec la méthode de calcul. La méthode compte autant que le résultat : c’est elle qui rend le chiffre discutable — et donc crédible.

Ce que le projet coûte. L’investissement initial, et le coût annuel de fonctionnement. Annoncer le second est indispensable : un dossier qui l’omet perd sa crédibilité au premier comité qui pose la question.

Le point d’équilibre. À partir de quand le cumul des gains dépasse le cumul des coûts. Sur un projet applicatif bien ciblé, c’est généralement entre dix-huit et trente mois.

Ce qui se passe si l’on ne fait rien. Le coût actuel se reconduit, et il augmente si l’activité croît. C’est la partie la plus persuasive, et celle qu’on oublie le plus souvent.

Photo : Matt Moloney — licence CC0.

Les trois arguments qui ne marchent jamais

« C’est nécessaire pour la transformation numérique. » Trop vague pour être arbitré. Une direction ne peut ni valider ni refuser ce qu’elle ne peut pas mesurer.

« Nos concurrents l’ont fait. » Cela suscite au mieux une question — laquelle, et avec quel résultat ? Sans réponse précise, l’argument se retourne.

« Les équipes le demandent. » Légitime et insuffisant. Les équipes demandent beaucoup de choses, toutes ne se financent pas. Ce qui compte, c’est ce que ça coûte de ne pas le faire.

Découper pour rendre la décision plus facile

Un budget de 200 000 € en une fois demande un arbitrage lourd. Le même projet en trois lots de 70 000 €, avec une décision à chaque étape, passe beaucoup plus facilement.

Ce n’est pas un artifice de présentation : c’est aussi la bonne façon de conduire le projet. Le premier lot livre quelque chose d’utilisable, on mesure, et l’on décide de la suite en connaissance de cause.

Cela transforme un pari en série de décisions réversibles — ce qui est exactement ce qu’une direction sait faire.

Photo : Kristin Hardwick — licence CC0.

Anticiper les trois objections qui viennent toujours

Un dossier solide prévoit les objections dans le document, plutôt que de les découvrir en séance.

« Et si les besoins changent en cours de route ? » La réponse est le découpage en lots avec décision à chaque étape. C’est précisément ce qui rend le projet compatible avec un besoin mouvant, et il faut le dire ainsi plutôt que de promettre une spécification définitive.

« Qu’est-ce qui nous garantit que ça marchera ? » Rien ne le garantit, et prétendre le contraire décrédibilise. Ce qu’on peut garantir, c’est le montant maximal exposé avant la première mise en service réelle. Un premier lot livré et utilisé en trois mois borne le risque à ce lot.

« Pourquoi maintenant ? » L’objection la plus fréquente et la plus fatale, parce qu’un report paraît toujours sans conséquence. La réponse tient dans le coût annuel de la situation actuelle : reporter d’un an, c’est le payer une fois de plus.

Qui doit porter le dossier

Le point le plus déterminant, et le moins technique.

Un dossier porté par la direction informatique est perçu comme un projet informatique. Un dossier porté par le responsable métier qui subit le problème est perçu comme un projet d’entreprise. Le second passe beaucoup plus souvent que le premier, à contenu identique.

Ce que je conseille : que le chiffrage du coût actuel soit présenté par celui qui le subit, et la solution par celui qui la construira. Cette répartition n’est pas cosmétique — elle montre que le besoin vient du terrain et non d’une envie de technologie.

Ce que je conseille de ne pas promettre

Un retour sur investissement précis à la décimale. Personne n’y croit, et un chiffre trop précis décrédibilise le reste. Une fourchette assumée est plus solide.

Des économies de poste. C’est tentant et rarement vrai : les gens sont rarement remerciés, ils font autre chose. Promettre une réduction d’effectif qui n’arrivera pas détruit la confiance dans le projet suivant.

Un délai sans marge. Annoncer six mois quand on en pense huit produit un retard de deux mois au lieu d’un projet livré à l’heure. La crédibilité du prochain dossier se joue là.