Le comité annonce que le futur back-office économisera deux équivalents temps plein, mais personne ne sait quels dossiers, quelles tâches ni quelles erreurs composent ce gain. Le budget paraît précis alors que sa référence tient dans une estimation orale.
Le problème devient visible quand chaque équipe attribue au même outil des lenteurs différentes. Le signal faible est un ROI qui augmente à mesure que le devis augmente, avec un risque de compter simultanément temps gagné, délai réduit et erreur évitée sur le même événement.
Une situation de référence économique doit être observable avant le choix de la solution. Elle sépare travail actif, attente, reprises, incidents et opportunités perdues, conserve l’incertitude et rend enfin comparables statu quo, simplification, SaaS et développement sur mesure.
Une équipe de développement web sur mesure exige cette preuve avant de figer l’architecture. Le projet d’application métier transforme ensuite processus, données et droits en restant mesurable face à cette référence.
Comprendre la fonction de la baseline
La baseline décrit ce qui se passe sans le projet, sur une période et une population définies. Elle ne cherche pas à prouver que l’outil est nécessaire ; elle fournit le scénario de référence contre lequel chaque option pourra être évaluée.
Elle mesure volume, coût, délai, qualité et capacité au même grain. Un changement de volume ou de mix peut sinon être présenté comme un gain produit alors qu’il vient d’une saison, d’un recrutement ou d’une politique commerciale.
Le Green Book 2026 du HM Treasury distingue l’appréciation avant décision de l’évaluation après mise en œuvre et demande de comparer plusieurs options, y compris ce qui se passe sans intervention.
La baseline devient un actif de gouvernance : définitions, sources, période, exclusions, hypothèses et incertitudes sont figées avant le choix. Toute correction ultérieure conserve une version et son impact sur le business case.
Choisir processus et population
Délimiter un résultat métier
Le périmètre part d’un résultat terminé : commande validée, dossier instruit, contrat signé, intervention planifiée ou facture rapprochée. Une liste d’écrans ou de tâches ne montre pas si le processus délivre réellement sa valeur.
Les événements de début et de fin sont observables, avec les réouvertures. Un dossier fermé puis repris pour correction ne devient pas deux succès ; il conserve un cycle et une branche de reprise identifiables.
Stratifier les dossiers
La population distingue canal, complexité, client, site, urgence et exception lorsque ces facteurs modifient le travail. Mesurer uniquement les cas nominaux surévalue le gain d’une automatisation qui laissera les dossiers difficiles aux équipes.
Le périmètre note aussi les activités déplacées hors système : tableur, email, appel, double saisie dans l’ERP ou vérification dans le CRM. Leur invisibilité technique ne les retire pas du coût métier.
Mesurer temps actif et attente
Observer le travail réellement mobilisé
Le temps actif comprend saisie, recherche, contrôle, décision et coordination humaine. Il est mesuré par observation ponctuelle, journal d’activité borné ou événements applicatifs, puis confronté au discours des utilisateurs.
Le temps ouvert à l’écran n’est pas du temps de travail. Un onglet laissé en arrière-plan, un dossier traité en parallèle ou une réunion interrompue exige une convention afin de ne pas gonfler artificiellement la charge actuelle.
Conserver le délai traversé
L’attente entre deux actions n’économise pas toujours du salaire, mais elle peut retarder revenu, service ou décision. Temps actif et délai calendaire restent deux métriques avec deux mécanismes de valeur distincts.
Une automatisation peut réduire dix minutes de saisie et deux jours d’attente ; les additionner en heures serait absurde. Le modèle valorise la saisie par capacité mobilisée et le délai par conséquence économique prouvée.
Valoriser erreurs et reprises
Une erreur possède détection, correction, conséquence et probabilité de récurrence. Le coût direct additionne temps de reprise, avoir, expédition, support et éventuelle pénalité ; la conséquence durable reste une hypothèse séparée.
Les quasi-erreurs détectées avant sortie consomment une capacité réelle. Elles ne produisent pas le même dommage qu’une erreur client, mais révèlent un contrôle manuel dont l’outil futur devra reprendre ou supprimer la cause.
Le taux est calculé sur une unité stable : ligne, dossier ou décision. Diviser des incidents de gravités différentes par des écrans consultés ne permet ni comparaison ni arbitrage.
Chaque erreur reçoit cause contrôlable et owner. Une mauvaise donnée source ne devient pas automatiquement un bénéfice du nouvel outil ; il faut démontrer que validation, intégration ou workflow corrigera ce mécanisme.
Chiffrer incidents et indisponibilité
Un incident combine durée, utilisateurs touchés, travail bloqué, backlog créé, perte ou dégradation de service et effort de récupération. Multiplier toute la masse salariale par chaque minute d’arrêt surévalue souvent la perte.
La chronologie conserve détection, diagnostic, mitigation, rétablissement et résorption du backlog. Le service peut être revenu alors que les équipes absorbent encore plusieurs heures de reprise et de communication.
Le chapitre Monitoring Distributed Systems du livre SRE de Google relie l’observabilité aux objectifs du service. La baseline doit donc mesurer ce que l’incident empêche, pas seulement la disponibilité technique.
Le coût attendu utilise fréquence et impact par classe, avec une fourchette pour les événements rares. Un incident majeur historique n’est ni ignoré ni annualisé comme s’il se répétait toujours au même rythme.
Traiter les opportunités perdues
Une opportunité perdue exige un événement observable : devis non envoyé avant échéance, capacité inutilisée faute de planification, commande abandonnée après erreur ou client refusé par délai. Une ambition commerciale générale ne devient pas un bénéfice.
La valeur est pondérée par probabilité de conversion, contribution et capacité réelle. Le chiffre d’affaires brut n’est pas additionné au gain de temps si la même équipe ne pourrait pas produire ou servir le volume supplémentaire.
La preuve distingue corrélation et causalité. Un dossier tardif peut être perdu pour le prix, l’offre ou le concurrent ; la baseline conserve motif connu, attribution incertaine et fourchette plutôt qu’une valeur certaine avantageant le projet.
Les opportunités non monétisées restent visibles dans la scorecard : conformité, satisfaction, continuité ou capacité de croissance. Leur importance peut justifier une option même sans conversion artificielle en euros.
Éviter les doubles comptes
Une même erreur peut consommer trente minutes, retarder le dossier et provoquer un avoir. Ces trois effets sont distincts, mais le modèle vérifie que le délai n’inclut pas déjà la reprise et que l’avoir ne représente pas la même perte de contribution.
Le graphe de valeur relie cause, effet intermédiaire et résultat. L’automatisation d’une saisie réduit le temps ; ce temps peut augmenter la capacité ; seule la capacité effectivement utilisée peut ensuite produire un revenu supplémentaire.
Les transferts sont distingués des gains. Déplacer une tâche de l’administration vers le commercial ou le client ne supprime pas son coût ; le nouvel owner, l’effort et l’effet sur l’expérience doivent être mesurés.
Contre-intuitivement, le temps libéré n’est pas automatiquement une économie de masse salariale. Il devient capacité réallouée, coût évité futur ou réduction de recours externe selon une décision de management documentée, un volume absorbable et une date à laquelle cette valeur pourra réellement être constatée.
Construire un échantillon crédible
Couvrir la variabilité
L’échantillon traverse jours chargés, périodes calmes, sites, profils et complexités. Une semaine choisie pendant un effort exceptionnel ou après nettoyage manuel ne représente pas le scénario habituel.
Les exceptions sont suréchantillonnées pour comprendre leur coût, puis repondérées selon leur fréquence réelle. Cette séparation évite de concevoir tout le logiciel pour les cas rares ou de les ignorer dans le ROI.
Publier l’incertitude
Médiane, percentiles, moyenne et intervalle répondent à des questions différentes. La capacité se dimensionne sur la distribution, tandis que le budget annuel utilise volume, coût moyen et scénario prudent.
Si l’intervalle change la décision d’investissement, alors l’équipe collecte davantage. S’il ne change que la deuxième décimale du payback, elle conserve l’incertitude et arrête de mesurer.
Instrumenter sans perturber le travail
Croiser les preuves
Les entrées comprennent événements du legacy, observations, tickets, exports ERP ou CRM et échantillons manuels ; les sorties exposent cycles, temps, erreurs, incidents et niveau de confiance. Le contrat attribue owner, droits et durée de conservation.
L’instrumentation respecte la minimisation des données et informe les équipes. Elle mesure le processus, pas la productivité individuelle ; aucun score nominatif n’est déduit d’un historique incomplet ou d’un rythme dépendant des dossiers.
Préparer la comparaison future
Les événements cibles sont conçus avec l’architecture frontend et backend, l’API, les tests QA et le workflow. Une version commune permet de comparer la baseline au déploiement sans reconstruire les définitions après coup.
Le monitoring suit complétude, latence, doublons et ruptures de séquence ; le runbook décrit reprise, dépendance et rollback. L’observabilité reste assez légère pour ne pas devenir un second outil métier à maintenir.
Former le modèle économique
Le scénario de référence projette volumes, salaires complets, coûts externes, incidents et contraintes sans projet. Les options ajoutent construction, licences, intégration, migration, conduite du changement, run, maintenance et remplacement futur, avec un calendrier commun qui empêche de comparer un bénéfice immédiat à un coût artificiellement repoussé.
Le Cost Estimating and Assessment Guide du GAO recommande notamment baseline technique, structure de coûts, hypothèses, analyse de sensibilité, risque et mise à jour par les coûts réels. Ces principes s’appliquent aussi à un logiciel métier.
Les bénéfices montent selon l’adoption et la couverture réelle. Une fonctionnalité livrée ne produit aucun gain sur les dossiers restés dans le tableur, les interfaces legacy ou les sites dont la migration est différée ; chaque cohorte conserve donc sa date d’entrée et son périmètre effectivement traité.
La comparaison publie valeur actuelle, payback, fourchette et principaux drivers. Le ratio seul ne remplace pas l’abordabilité, les risques, la dépendance fournisseur ni la capacité de l’organisation à absorber le changement.
Comparer statu quo, SaaS et sur mesure
Reconstruire le coût par dossier
Exemple concret : une équipe traite huit mille dossiers annuels. L’observation montre 22 minutes actives, 17 % de reprises et un délai médian de quatre jours ; si la validation par email est supprimée, alors ces trois effets doivent être remesurés avant de valoriser le gain.
Le modèle prudent valorise seulement le temps actif supprimable et le coût prouvé des erreurs. L’opportunité commerciale reste hors bénéfice central faute de preuve causale, mais apparaît comme scénario haut avec sa probabilité, sa capacité requise et la décision qui permettrait de la vérifier.
Comparer trois options
La simplification du workflow supprime une validation sans développement majeur ; le SaaS couvre le nominal mais laisse les exceptions ; l’application sur mesure traite états, droits, intégrations et reprises. Chaque option possède coût, couverture, délai d’adoption, dépendances et valeur résiduelle au terme de l’horizon étudié.
Si la simplification capture plus d’un quart du gain en moins de deux mois, alors elle doit partir avant le logiciel. La baseline sera remesurée ensuite afin que le futur outil ne revendique pas ce bénéfice déjà acquis.
Savoir quand la mesure mérite quatre semaines
La méthode est prioritaire lorsque plusieurs équipes, outils et contournements participent au même résultat, lorsque le ROI justifie un budget important ou lorsque SaaS et sur mesure doivent être comparés.
Un petit processus peut commencer avec vingt dossiers contrastés, volume mensuel, temps actif, reprises et coût d’incident. Le niveau de détail augmente seulement si une incertitude peut réellement inverser le choix.
Il faut différer le modèle financier complet si les événements de début et de fin ne sont pas définis. La première étape devient la cartographie du processus et la réconciliation d’un cycle complet.
Il faut refuser une mesure nominative utilisée pour évaluer les personnes. Le contexte, la complexité et le travail invisible rendent ce détournement injuste, tout en incitant à manipuler les traces qui devaient éclairer le projet.
Écarter les calculs qui faussent la référence
Erreur fréquente : demander une estimation moyenne en atelier. Les tâches rares, parallèles et invisibles sont oubliées, tandis que les irritants récents reçoivent un poids disproportionné.
Autre erreur : valoriser chaque minute au salaire puis annoncer une économie. Sans décision de capacité, de non-remplacement ou de sous-traitance évitée, le temps libéré n’est pas du cash.
Erreur de causalité : attribuer toutes les opportunités perdues au legacy. Prix, offre et capacité peuvent expliquer le résultat ; le logiciel ne reçoit que la part dont le mécanisme est prouvé.
Erreur de référence : modifier la baseline après sélection de l’option pour préserver le ROI annoncé. Les corrections légitimes restent versionnées et sont appliquées symétriquement à tous les scénarios.
Construire la référence en quatre semaines
Semaine 1 : fixer résultat et grain
Métier, finance et produit choisissent processus, population, période et événement terminé. Ils définissent temps actif, attente, reprise, erreur, incident et opportunité avec leurs sources et exclusions.
Le plan d’échantillon couvre nominal, complexité, sites et saison. Les droits d’accès, la minimisation et la communication aux équipes sont validés avant toute observation ou extraction.
Semaines 2 et 3 : mesurer et contredire
L’équipe rapproche traces, observations et dossiers, puis calcule volume, distributions et coûts. Chaque bénéfice potentiel reçoit cause, preuve, owner, couverture future et intervalle d’incertitude.
Une revue contradictoire recherche transferts, doubles comptes et opportunités non causales. Les options statu quo, simplification, SaaS et sur mesure sont comparées sur la même référence.
Semaine 4 : décider et préparer l’évaluation
Le comité choisit l’option avec sensibilité, risque, abordabilité et capacité de changement. Les métriques cibles, événements, population témoin et date d’évaluation sont inscrits dans le contrat de delivery.
La baseline est gelée, versionnée et accessible. Après chaque amélioration préalable, elle est remesurée afin que le projet suivant ne récupère pas une valeur déjà produite par une décision indépendante.
- À faire d’abord : définir le résultat terminé, le grain, la population et les événements qui bornent chaque cycle métier.
- À mesurer ensuite : séparer temps actif, attente, reprises, incidents et opportunités avec sources et incertitudes explicites.
- À tester puis valider : chercher doubles comptes, transferts et causes externes avant de comparer les options sur la même baseline.
- À refuser : tout ROI sans scénario de référence versionné, couverture d’adoption et mécanisme permettant de vérifier le bénéfice après livraison.
Relier processus observé et retour sur investissement
Ces analyses apportent la cartographie, l’inventaire des exceptions et les modèles de ROI nécessaires pour transformer une observation économique en périmètre produit et en hypothèses vérifiables.
Comprendre le travail avant l’outil
La cartographie du processus métier relie événements, décisions et coûts, tandis que l’inventaire des exceptions mesure la complexité que le futur logiciel devra supprimer, assister ou assumer.
La baseline utilise ces deux preuves pour éviter de mesurer seulement le chemin nominal et pour rattacher chaque coût à l’état, à la règle ou à l’attente qui le produit.
Passer du coût à la décision
Le modèle de ROI d’un portail B2B détaille adoption et payback, tandis que l’analyse du ROI d’un back-office métier approfondit le coût par dossier.
Ces cadres interviennent après la référence : ils modélisent comment une option transforme le coût actuel, avec une montée en charge, un run et une contre-preuve qui empêchent de confondre livraison et bénéfice.
- À conserver : sources, dossiers témoins, définitions, périodes, exclusions et versions ayant produit la baseline approuvée.
- À réviser : volumes, mix et coûts après une amélioration indépendante qui modifie réellement le scénario sans projet.
- À exclure : les gains commerciaux sans mécanisme causal, capacité disponible ni règle empêchant leur double comptage avec le temps libéré.
Conclusion : investir contre une preuve
Une application métier ne crée pas de valeur parce qu’elle remplace des écrans anciens. Elle doit modifier un mécanisme observable de temps, qualité, délai, continuité ou capacité sur une population qui adopte réellement le nouveau workflow, sans déplacer silencieusement le travail vers un autre rôle.
La baseline rend ce mécanisme réfutable. Elle distingue travail et attente, coût et transfert, capacité et cash, corrélation et opportunité prouvée, puis compare plusieurs options sans avantager la plus spectaculaire.
Le projet possède alors une référence, des hypothèses, une fourchette et un plan d’évaluation durable. La décision peut accepter un bénéfice non monétisé, mais elle ne le cache plus dans un ROI artificiellement précis et fragile.
Dawap vous accompagne pour construire cette preuve et concevoir une application web sur mesure dont la valeur reste mesurable après le déploiement, du premier processus instrumenté jusqu’au run, avec des indicateurs communs à finance, métier, produit et équipe technique pour chaque revue de bénéfices et chaque décision de périmètre ultérieure.
