Réponse courte : pour calculer le ROI d'une application métier, comparez le fonctionnement actuel et l'option applicative sur le même horizon. Mesurez les bénéfices réellement utilisables, retranchez tous les coûts de construction, de transition et d'exploitation, puis calculez au moins trois résultats : ROI simple, délai de retour et valeur actualisée. Présentez enfin un scénario prudent et le point de bascule. Une heure libérée qui n'est ni supprimée, ni réaffectée, ni convertie en capacité utile n'est pas automatiquement une économie.
Le calcul n'a pas pour fonction de défendre un logiciel déjà choisi. Il doit rendre visibles les hypothèses qui changent la décision : volume, adoption, qualité, part du temps récupérable, coût de maintenance, durée de vie et risque d'échec. Les formules sont simples ; obtenir des données comparables l'est beaucoup moins.
Le calcul compare deux systèmes, pas un logiciel à rien
L'option de référence n'est jamais « zéro coût ». Le fonctionnement actuel consomme déjà du temps, des licences, des contrôles, des ressaisies, du support et parfois des incidents. L'application proposée crée de nouveaux coûts et peut en déplacer d'autres. Le business case doit donc comparer :
- le scénario de référence : ce qui se produira si l'entreprise conserve son organisation actuelle, avec ses volumes et son évolution probable ;
- le scénario applicatif : le même périmètre après construction, migration, adoption et stabilisation ;
- les autres options crédibles : simplifier le processus, mieux configurer un outil existant, connecter deux logiciels ou acheter un SaaS.
Le Green Book 2026 du Trésor britannique est destiné à l'évaluation publique, pas au calcul financier d'une PME. Sa discipline reste néanmoins transposable : décrire le fonctionnement habituel, comparer plusieurs options, recenser coûts, bénéfices et risques, puis tester la sensibilité aux hypothèses au lieu de présenter un résultat unique.
Fixez un horizon compatible avec la décision : douze mois pour une preuve courte, trois ans pour une application appelée à durer, ou une autre période justifiée. Utilisez le même horizon pour toutes les options. Ne choisissez pas la durée qui rend seulement le projet rentable.
Figer la référence avant de compter le premier gain
Mesurez le travail actuel avant de modifier le processus. Le Digital and Data Benefits Framework, publié par le gouvernement britannique le 7 avril 2026, insiste sur l'établissement d'un coût de référence incluant exploitation, infrastructure et support avant de quantifier un bénéfice numérique.
Une fiche de référence exploitable contient au minimum :
| Champ | Mesure | Preuve à conserver |
|---|---|---|
| Volume | Dossiers, commandes ou demandes par période | Journal système, échantillon daté ou comptage partagé |
| Temps actif | Minutes réellement travaillées par opération | Observation ou journal de temps, séparé de l'attente |
| Qualité | Reprises, erreurs, abandons et escalades | Motif et gravité, pas seulement un total |
| Coût actuel | Travail chargé, licences, prestataires et incidents | Source comptable et règle d'allocation |
| Service rendu | Délai, disponibilité, satisfaction ou résultat métier | Définition stable et période de mesure |
Mesurez plusieurs périodes représentatives. Une semaine de clôture comptable et une semaine creuse ne décrivent pas le même système. Notez les événements exceptionnels et conservez les valeurs brutes : une moyenne sans distribution peut masquer les dossiers qui concentrent le coût ou le risque.
Le protocole proposé dans Pourquoi les PME perdent du temps avec des outils non connectés ? aide à séparer ressaisie, attente, rapprochement et reprise avant de transformer une friction en hypothèse financière.
Reconnaître un bénéfice sans monétiser une fiction
Classez chaque bénéfice dans un registre. Deux lignes ne doivent jamais rémunérer deux fois le même effet.
| Famille | Calcul possible | Condition de reconnaissance |
|---|---|---|
| Coût évité | Dépense actuelle supprimée ou contrat non renouvelé | Montant, date et conséquence de la suppression établis |
| Capacité réaffectée | Heures libérées × coût chargé × taux d'utilisation | Travail supprimé et capacité affectée à une demande réelle |
| Revenu incrémental | Marge contributive des ventes additionnelles attribuables | Chemin causal et comparaison avec une référence |
| Erreur ou incident évité | Fréquence × coût moyen documenté | Historique suffisant, sans compter le même temps ailleurs |
| Qualité non monétisée | Délai, traçabilité, satisfaction ou continuité | Indicateur et seuil conservés hors du total financier |
La nuance la plus importante concerne le temps. Si une application libère cent heures mensuelles mais que les salaires, les effectifs et la production ne changent pas, la trésorerie n'augmente pas de cent heures multipliées par un taux chargé. L'entreprise a créé une capacité. Cette capacité devient un bénéfice reconnu seulement si elle évite une dépense, absorbe un volume supplémentaire, raccourcit une contrainte ou remplace un travail à plus forte valeur démontrée.
Ajoutez donc un taux_de_réalisation à chaque bénéfice : part du gain technique que l'organisation saura effectivement obtenir. L'adoption, les exceptions, les doubles saisies maintenues pendant la transition et le contrôle humain réduisent souvent cette part. Le taux n'est pas un benchmark : il doit venir d'une preuve ou d'un scénario explicite.
Construire le coût total sur le même horizon
Le dénominateur ne se limite ni au devis ni aux licences. Le dossier Combien coûte réellement un logiciel métier en 2026 ? détaille le coût total ; pour le ROI, répartissez ces postes dans le temps :
- avant mise en service : investigation, cadrage, conception, achat, développement, intégration, migration, nettoyage des données, tests, sécurité et préparation du retour arrière ;
- pendant la transition : formation, accompagnement, double fonctionnement, baisse temporaire de productivité, correction et support renforcé ;
- en exploitation : hébergement, abonnements, supervision, support, propriétaire produit, maintenance, sauvegardes, sécurité, dépendances et gestion des incidents ;
- à la sortie : export, réversibilité, archivage, migration et arrêt des anciens composants.
Le Secure Software Development Framework du NIST organise les pratiques de sécurité autour de la préparation, de la protection du logiciel, de sa production et de la réponse aux vulnérabilités. Il ne donne pas un pourcentage de budget. Il rappelle pourquoi exigences, provenance, correction et réponse aux vulnérabilités doivent être financées sur le cycle de vie plutôt qu'ajoutées comme un imprévu.
Conservez aussi le coût d'opportunité séparément : que ne pourrez-vous pas financer ou construire pendant que l'équipe porte cette application ? Ne l'ajoutez pas mécaniquement au ROI comptable si vous ne savez pas le valoriser, mais exposez-le dans l'arbitrage.
Pour une décision prise aujourd'hui, séparez enfin les coûts futurs des coûts déjà engagés et irrécupérables. Ces derniers expliquent l'historique, mais ne doivent pas rendre artificiellement attractive la poursuite d'une mauvaise option. En revanche, les dépenses futures nécessaires pour migrer, arrêter ou sécuriser l'existant restent bien dans la comparaison.
ROI, délai de retour et valeur actualisée répondent à trois questions
Pour un horizon H, une définition de travail du ROI simple est :
ROI simple = (bénéfices cumulés - coûts cumulés) / coûts cumulés
Un résultat de 0,10 signifie que le bénéfice net représente 10 % des coûts sur l'horizon choisi. Cette métrique permet une lecture rapide, mais elle ne dit pas quand les flux arrivent.
Le délai de retour est la première période où le cumul des flux nets devient positif :
flux_net_t = bénéfices_t - coûts_t
délai_de_retour = premier t où somme(flux_net_0...t) ≥ 0
Deux projets peuvent afficher le même ROI à trois ans et immobiliser la trésorerie pendant des durées très différentes.
La valeur actualisée nette tient compte de la date des flux :
VAN = somme(flux_net_t / (1 + r)^t)
r est le taux d'actualisation par période choisi par l'entreprise selon son coût du capital, son risque et sa politique financière. Le Green Book utilise ses propres taux pour l'évaluation publique britannique ; ils ne constituent pas un taux universel pour une PME. Faites valider le taux et le traitement comptable par la fonction financière compétente.
Exemple fictif : un ROI positif mais fragile
L'exemple suivant est pédagogique. Il ne décrit ni un client, ni un projet, ni un résultat de Forge Labs. Les montants sont des hypothèses destinées à montrer le calcul.
Une équipe traite 1 500 dossiers par mois. Une observation sépare quatre minutes de travail actif supprimable par dossier, soit :
1 500 × 4 / 60 = 100 heures de capacité théorique par mois
Le coût chargé retenu dans l'exemple est de 38 € par heure. L'équipe estime qu'elle pourra utiliser 60 % de la capacité pour absorber une demande déjà présente :
100 × 38 × 60 % = 2 280 € de capacité reconnue par mois
Les journaux fictifs montrent également 22 heures mensuelles de reprise évitables, mesurées séparément du temps précédent, soit 22 × 38 = 836 €. Une ancienne licence de 900 € par mois peut être arrêtée. Le bénéfice mensuel total de l'exemple est donc 4 016 €.
L'investissement initial est de 70 000 € et couvre, dans cet exemple, construction, intégration, migration, formation et transition. L'exploitation mensuelle comprend 600 € d'infrastructure et licences, 800 € de maintenance et support, puis huit heures de pilotage à 38 €, soit 304 €. Le coût récurrent est donc de 1 704 € par mois.
| Calcul à 36 mois | Formule | Résultat pédagogique |
|---|---|---|
| Bénéfices cumulés | 4 016 × 36 | 144 576 € |
| Coûts cumulés | 70 000 + (1 704 × 36) | 131 344 € |
| Bénéfice net | 144 576 - 131 344 | 13 232 € |
| ROI simple | 13 232 / 131 344 | 10,1 % |
| Délai de retour économique | 70 000 / (4 016 - 1 704) | Au cours du 31e mois |
| VAN économique illustrative | Flux mensuels actualisés, taux annuel de 8 % | Environ 4 084 € |
Ce 10,1 % est un ROI économique, pas un ROI de trésorerie. Dans cet exemple, seule la licence supprimée produit directement 900 € de coût évité par mois ; les 3 116 € restants sont de la capacité valorisée. Avec 1 704 € de coûts récurrents, les seuls flux de trésorerie décrits ne remboursent donc pas l'investissement. Il faudrait démontrer que la capacité absorbe une demande rentable ou supprime une autre dépense pour reconnaître un retour en trésorerie.
La VAN de 4 084 € utilise, uniquement pour illustrer le calcul, des flux mensuels constants en fin de période et le taux mensuel équivalent à un taux annuel hypothétique de 8 %, soit (1 + 8 %)^(1/12) - 1, environ 0,643 %. Ce taux n'est ni une recommandation de Forge Labs ni une norme : l'entreprise doit faire valider son taux, la temporalité des flux, la fiscalité et l'inflation par sa fonction financière. Le tableur doit permettre de modifier chaque hypothèse.
Chercher le point de bascule plutôt qu'un chiffre flatteur
Dans l'exemple, si seulement 40 % de la capacité est réellement utilisée, le bénéfice mensuel baisse de 760 €. Sur 36 mois, les bénéfices deviennent 117 216 € pour 131 344 € de coûts : le ROI simple passe à environ -10,8 %. La conclusion change avec une seule hypothèse.
Construisez au moins trois scénarios :
- prudent : adoption lente, bénéfices retardés, coût de transition et exceptions élevés ;
- central : hypothèses les mieux documentées ;
- favorable : adoption, volumes et coûts au meilleur niveau encore étayé par les observations.
Calculez ensuite la valeur de bascule : volume minimal, taux de réalisation, marge ou coût maximal à partir duquel la VAN ou le ROI devient nul. Dans l'exemple, le ROI simple devient nul autour de 50,3 % de réalisation de la capacité, toutes les autres hypothèses restant identiques. Cette valeur est souvent plus utile qu'un pourcentage. Elle transforme la décision en question opérationnelle : « pouvons-nous atteindre et observer ce niveau ? ».
Le Green Book 2026 recommande explicitement l'analyse de sensibilité et la recherche des valeurs qui font perdre à une option son rapport coût-valeur. Là encore, la méthode est utile ; les paramètres publics britanniques ne sont pas transposés tels quels.
Documentez aussi où le risque est traité. Un même risque ne doit pas réduire les flux dans un scénario puis être facturé une seconde fois dans le taux d'actualisation. Faites valider cette convention avec le taux par la fonction financière.
Une rentabilité ne compense pas une porte non franchie
Conservez hors du numérateur les exigences qui conditionnent simplement le droit ou la capacité d'exploiter le système. La CNIL rappelle qu'une AIPD est requise lorsqu'un traitement de données personnelles est susceptible d'engendrer un risque élevé, et que finalité, nécessité, proportionnalité et droits des personnes relèvent d'exigences non négociables.
Avant d'accepter un ROI, vérifiez donc :
- protection des données, sécurité et contrôle des accès ;
- continuité d'activité et procédure manuelle de secours ;
- qualité minimale et erreurs critiques ;
- adoption réelle par les personnes qui opèrent le processus ;
- réversibilité et accès aux données ;
- propriétaire, budget et capacité de maintenance.
Une option qui échoue à une porte légale, de sécurité ou de continuité doit être corrigée ou écartée. Ajouter un coût moyen d'incident au tableur ne donne pas l'autorisation d'accepter un risque interdit.
Mesurer après la mise en service avec le même registre
Le business case devient testable seulement si la mesure continue après la mise en service. Le programme beta.gouv.fr demande à ses services numériques de mesurer usage et impact ; pour une application métier, ajoutez l'efficience et reliez chaque bénéfice annoncé à un indicateur observable.
Conservez pour chaque période :
- volume et population réellement couverts ;
- adoption, abandon et usage parallèle de l'ancien système ;
- temps actif, reprises, erreurs et délais selon les mêmes définitions qu'avant ;
- coûts d'exploitation, de correction et de support réellement payés ;
- bénéfice reconnu, taux de réalisation et justificatif ;
- incidents, effets indésirables et bénéfices non monétisés ;
- écart entre scénario, prévision et réalisé.
Fixez avant le projet les dates de décision : après la preuve, après la transition puis à intervalles réguliers. À chaque revue, choisissez explicitement de poursuivre, corriger, réduire ou arrêter. Un ROI prévisionnel ne doit pas survivre intact aux données réelles.
Le résultat attendu est une décision vérifiable
Un calcul défendable tient dans un classeur auditable. Pour chaque ligne, documentez l'unité, la référence observée, la valeur de l'option, la source, le caractère trésorerie ou capacité, le responsable et les valeurs des scénarios prudent, central et favorable. Séparez les hypothèses des mesures, conservez des flux mensuels, les portes éliminatoires et le propriétaire de chaque bénéfice. La réponse à la question du titre n'est donc pas un pourcentage isolé.
Calculez la différence entre le système actuel et l'option applicative, reconnaissez seulement les bénéfices utilisables, financez le cycle de vie complet, puis observez le point de bascule. Si le projet ne reste intéressant qu'avec 100 % d'adoption, aucune exception et aucun dépassement, le tableur n'a pas démontré sa rentabilité : il a documenté sa fragilité.
Sources consultées
- UK Government — Digital and Data Benefits Framework, 7 avril 2026.
- HM Treasury — The Green Book 2026, mis à jour le 5 février 2026.
- NIST — Secure Software Development Framework, page mise à jour le 13 avril 2026 ; version finale SSDF 1.1 citée.
- CNIL — Analyse d'impact relative à la protection des données, consultée le 31 juillet 2026.
- beta.gouv.fr — Indicateurs d'impact, consultée le 31 juillet 2026.