Application sur mesure : comment estimer sa rentabilité

Personne ne peut vous dire à l’avance qu’une application sur mesure sera rentable : ni un prestataire, ni une moyenne tirée d’autres entreprises. En revanche, vous pouvez estimer son retour sur investissement de façon honnête. Il s’agit de partir d’un processus précis, de chiffrer ce qu’il coûte aujourd’hui, de lister tout ce que coûtera l’outil sur sa durée d’usage, puis de comparer. Le résultat est une fourchette fondée sur vos hypothèses, pas une promesse.

Voici la méthode, les postes de coût souvent oubliés et les hypothèses à vérifier avant de décider.

Partir d’un processus, pas d’une envie d’outil

Un retour sur investissement se calcule sur quelque chose de mesurable. « Mieux s’organiser » ne l’est pas ; « traiter une demande d’intervention, de sa réception à la facture » l’est. Choisissez un ou deux processus que l’application doit prendre en charge, et décrivez-les tels qu’ils se déroulent réellement, y compris les ressaisies, les relances et les exceptions.

Pour chacun, notez le nombre d’occurrences par mois, les personnes qui interviennent, le temps passé à chaque étape, les erreurs constatées et ce qu’elles coûtent : avoir émis, déplacement refait, facture envoyée en retard. Ces relevés peuvent être approximatifs, mais ils doivent venir de votre activité. Une journée d’observation ou un échantillon de dossiers vaut mieux qu’une estimation de mémoire.

Les gains à estimer, sans les compter deux fois

Les gains se rangent en trois familles. Ne les fondez pas dans un seul chiffre : elles n’ont pas la même solidité.

• Temps de travail : ressaisies supprimées, recherches d’information évitées, validations plus rapides. C’est le gain le plus facile à estimer, à condition de dire ce que deviendra ce temps : une autre tâche, davantage de dossiers traités, des heures supplémentaires évitées.
• Erreurs et pertes : factures oubliées, doublons, litiges faute de trace. Estimez-les à partir de cas réellement constatés sur une période, pas d’un pourcentage théorique.
• Capacité : traiter plus de demandes avec la même équipe, proposer un nouveau service, répondre plus vite à un client. Ce gain peut être réel mais reste incertain ; présentez-le à part, comme un scénario.

Attention au double comptage : si une étape disparaît, le temps qu’elle prenait et les erreurs qu’elle provoquait ne doivent être comptés qu’une fois chacun. Et un temps libéré ne devient un gain financier que s’il est effectivement réemployé.

Tous les postes de coût, sur toute la durée d’usage

Le coût d’une application ne s’arrête pas à sa livraison. Pour une comparaison juste, raisonnez sur la durée pendant laquelle vous comptez utiliser l’outil, et incluez :

• le cadrage et la conception : ateliers, maquettes, écriture des règles de gestion ;
• le développement et les tests, y compris la reprise des données existantes ;
• l’hébergement et les services tiers facturés à l’usage, comme l’envoi d’e-mails, la cartographie ou le stockage de fichiers ;
• la publication sur les stores, s’il s’agit d’une application mobile ;
• la maintenance : mises à jour de sécurité, compatibilité avec les nouvelles versions des systèmes et des navigateurs, corrections ;
• les évolutions, c’est-à-dire les demandes qui arriveront une fois l’outil utilisé ;
• le temps interne : celui des personnes qui participent au cadrage, testent, forment leurs collègues et administrent l’outil.

Ce dernier poste est souvent oublié alors qu’il conditionne tout le reste : une application que personne n’a le temps de prendre en main ne produit aucun gain. Pour la maintenance, notre article sur la maintenance évolutive d’une application d’entreprise détaille ce qu’il faut prévoir.

Comparer avec les autres options, pas avec rien

Le bon point de comparaison n’est pas « ne rien faire », mais les alternatives réalistes : mieux organiser l’existant, adopter un logiciel du marché, ou développer. Un logiciel standard a lui aussi des coûts : abonnement par utilisateur, paramétrage, connecteurs, contournements quand il ne couvre pas une règle. Dans certains cas, il sera la meilleure réponse, et le calcul doit pouvoir le montrer.

Mettez les options côte à côte avec les mêmes hypothèses de volume et de durée. Si une solution standard couvre l’essentiel pour un coût total inférieur, l’exercice a rempli son rôle. Un logiciel métier sur mesure se justifie plutôt lorsque des règles importantes pour votre activité restent mal couvertes, ou lorsque l’outil doit s’intégrer étroitement à vos autres logiciels.

La mécanique du calcul, avec ses hypothèses

Voici une trame de calcul, à remplir avec vos propres relevés. Elle ne contient volontairement aucune valeur : un chiffre emprunté à une autre entreprise ne dirait rien de la vôtre.

1. Gain annuel de temps = nombre de dossiers par an × minutes économisées par dossier ÷ 60 × coût horaire chargé des personnes concernées.
2. Gain annuel sur les erreurs = nombre d’erreurs évitées par an × coût moyen constaté d’une erreur.
3. Coût total = coût initial (cadrage, développement, reprise des données) + coûts annuels (hébergement, maintenance, services tiers) × nombre d’années + temps interne.
4. Résultat sur la période = gains annuels × nombre d’années − coût total.

Faites ensuite varier les hypothèses les plus fragiles. Et si le temps économisé était moitié moindre ? Et si l’adoption prenait plus longtemps que prévu ? Si le projet reste intéressant dans un scénario prudent, c’est un bon signe. S’il ne l’est que dans le scénario optimiste, réduisez le périmètre ou reportez la décision. Le point à partir duquel les gains cumulés dépassent les coûts cumulés vous donne, pour chaque scénario, un ordre de grandeur de la durée nécessaire pour rentabiliser l’outil.

Les hypothèses à vérifier avant de signer

• Les volumes sont-ils mesurés ou estimés, et sur quelle période ?
• Les futurs utilisateurs ont-ils été consultés sur leur façon de travailler ?
• Le temps libéré sera-t-il réellement réemployé, et à quoi ?
• La reprise des données existantes a-t-elle été évaluée ?
• La maintenance est-elle comptée sur toute la durée d’usage ?
• Le premier périmètre est-il assez restreint pour être livré, utilisé et mesuré ?

Ce dernier point est le levier le plus efficace pour réduire le risque. Un premier périmètre étroit, par exemple la partie du processus où se concentrent les ressaisies, permet de constater un gain réel avant d’investir davantage. Si votre sujet concerne des équipes qui travaillent hors du bureau, notre article sur l’application métier entre terrain et bureau complète cette réflexion.

Après la mise en service, mesurez les mêmes indicateurs qu’avant. C’est la seule façon de savoir si l’estimation était juste, et de décider des évolutions suivantes sur des faits plutôt que sur des impressions.