ROI d'une application métier : savoir si le sur-mesure est rentable avant d'écrire une ligne de code

Pendant deux à quatre semaines, observez le travail tel qu'il existe. Comptez les personnes, le temps, les doubles saisies, les recherches d'information, les corrections, les relances et les interruptions. Ne mesurez pas seulement le geste que l'application remplacera : mesurez la chaîne entière.

• —Nombre d'occurrences par semaine ou par mois.
• —Temps moyen par occurrence et personnes impliquées.
• —Taux de reprise : dossiers incomplets, erreurs, doublons et oublis.
• —Délai imposé au client ou à l'équipe suivante.
• —Licences et outils déjà payés pour maintenir le processus.

Le résultat est un coût mensuel de référence. Sans cette base, le ROI sera une impression habillée en chiffre.

Multipliez le temps consommé par un coût horaire complet : salaire chargé, encadrement et coûts directement liés. Puis appliquez un taux de récupération prudent. Une automatisation ne restitue presque jamais 100 % du temps : il reste des contrôles, des exceptions et de la coordination.

Formule de départ

Gain de temps mensuel = volume × temps actuel × part réellement supprimée × coût horaire. Ajoutez séparément les erreurs évitées et les licences supprimées afin de pouvoir contester chaque hypothèse.

Si le temps libéré ne réduit aucune charge et ne permet ni plus de production, ni plus de vente, ni un meilleur service, ne le valorisez pas entièrement comme une économie de trésorerie.

Certaines applications se justifient moins par le temps que par la fiabilité : mauvais tarif, dossier oublié, stock incohérent, relance absente ou document envoyé à la mauvaise personne. Utilisez l'historique disponible, pas une estimation optimiste.

• —Nombre d'incidents sur une période suffisamment longue.
• —Coût moyen de correction, remboursement ou temps commercial perdu.
• —Valeur des opportunités non suivies, pondérée par le taux de conversion réel.
• —Risque réglementaire ou contractuel, documenté mais jamais transformé arbitrairement en revenu.

Le devis initial n'est qu'une partie du coût. Ajoutez cadrage, migration des données, formation, hébergement, services tiers, maintenance, support et évolutions prévisibles. Le coût interne de disponibilité des experts métier doit aussi apparaître.

• —Année 0 : cadrage, conception, développement, reprise des données et mise en service.
• —Années suivantes : hébergement, sauvegardes, surveillance, support et petites évolutions.
• —Coûts variables : emails, SMS, stockage, paiement, IA ou API facturés à l'usage.
• —Coût de sortie : export des données, documentation et capacité d'un tiers à reprendre l'outil.

Notre guide sur le prix d'une application web sur mesure donne une fourchette de V1 et les facteurs qui font varier le budget.

Construisez un scénario prudent, central et haut. Le scénario prudent doit rester acceptable : adoption plus lente, seulement la moitié du temps récupéré et davantage de support. Si le projet n'est rentable que dans le scénario haut, le périmètre est probablement trop ambitieux.

Exemple illustratif, pas résultat client

Une équipe consacre 40 heures par mois à un flux, avec un coût complet retenu de 35 €/h. L'application supprimerait prudemment 60 % de ce temps : 840 € par mois. Elle éviterait aussi environ 250 € de reprises et 150 € de licences, soit 1 240 € de gain mensuel estimé.

Avec une V1 à 9 000 € et 290 € de coût mensuel complet, le gain net estimé serait de 950 € par mois. Le seuil simple se situe autour de dix mois après mise en service. Chaque valeur doit être remplacée par les données de l'entreprise.

Un outil techniquement réussi mais contourné par l'équipe a un ROI nul. Le calcul doit inclure le taux d'utilisation attendu et le temps nécessaire pour l'atteindre. Les personnes qui exécutent le processus doivent participer au cadrage et à la recette.

• —Nombre d'utilisateurs actifs attendus par rôle.
• —Parcours fréquents réalisables sans formation longue.
• —Exceptions que l'outil doit gérer ou transmettre clairement.
• —Responsable interne de l'adoption et du retour terrain.
• —Mesure après lancement : utilisation, temps réel, erreurs et satisfaction opérationnelle.

La meilleure V1 ne reproduit pas tous les outils existants. Elle traite le flux qui concentre le plus de volume, de friction ou de risque. Les fonctions de confort, le reporting avancé et les intégrations secondaires viennent après la preuve d'usage.

Une plateforme métier sur mesure peut évoluer par modules si les données, les rôles et les interfaces sont correctement pensés. Commencer petit ne signifie pas construire jetable.

• —Un flux principal de bout en bout.
• —Les rôles strictement nécessaires.
• —Une administration permettant de corriger les cas réels.
• —Les journaux, sauvegardes et exports indispensables à l'exploitation.
• —Des indicateurs qui prouvent ou réfutent l'hypothèse de ROI.

Le calcul doit pouvoir conclure que le sur-mesure n'est pas la bonne solution. Si un outil standard couvre 80 % du besoin avec un changement de processus acceptable, il peut être plus rentable. Si le volume est trop faible, une automatisation ciblée ou un meilleur tableur peut suffire.

• —Lancer si le scénario prudent atteint le seuil accepté dans la durée retenue.
• —Réduire le périmètre si une fonction coûte davantage qu'elle ne contribue au gain.
• —Tester en prototype lorsque l'adoption ou la règle métier principale reste incertaine.
• —Choisir un outil existant quand le besoin n'est pas différenciant.
• —Arrêter si personne ne porte les données, la recette et l'adoption en interne.

Cette possibilité de dire non est un signe de cadrage sain. Le but n'est pas de justifier une application ; il est de prendre une décision économique explicable.