Une chose n’a pas une valeur parce qu’elle coûte, comme on le suppose, mais elle coûte parce qu’elle a une valeur.
Daniel Webster, Discours de 1826
Réaliser et opérer une application dans le système d’information implique d’allouer des moyens économiques et des équipes. En revanche, il est plus difficile de comprendre, voire de mesurer la valeur qu’apporte cette application. Et pour répondre à cette problématique, une autre question peut être posée : d’où vient la valeur de l’application ? De là, une approche peut être posée pour soit optimiser l’allocation de moyen pour maximiser la production de valeur (efficience), soit accélérer le flux de valeur à moyen constant (vélocité) (en fonction de la conjoncture !)
Valeur économique
L’application n’a pas de valeur en soi. C’est son intégration dans le système d’information et dans les processus métier qui permet à l’organisation d’opérer efficacement et de réaliser sa mission, qu’elle soit économique ou associative. Comment évaluer sa quote-part dans la « valeur ajoutée » de l’organisation ?
L’application peut contribuer aux processus d’entreprise en réalisant une activité, en renforçant l’intégrité du processus ou en donnant des indications pour améliorer le processus. On peut schématiquement lister ces rôles :
- Capteur : Capter une donnée
- Transformateur : Transformer une donnée ou la combiner avec une autre donnée
- Diffuseur : Exposer une donnée
- Interface : Réaliser une interaction avec un acteur humain (client, collaborateur…)
- Ambassadeur : Réaliser une interaction avec une autre organisation ou entité, dans l’écosystème de l’organisation.
- Orchestrateur : Tenir l’avancement d’un processus et renforcer sa cohérence
- Pilote : Consolider des indicateurs dans le passé ou des estimateurs dans le futur pour aider au pilotage du processus et à son amélioration.
Le processus a une importance (ou criticité) dans l’organisation qui est évaluable. En revanche, il est plus compliqué de lui donner une valeur économique : les processus opérationnels sont liés à du cashflow tandis que d’autres ne le sont pas directement tout en étant nécessaires au bon fonctionnement (fonction support et pilote). Les démarches visant à faire ruisseler la valeur économique dans les équipes (showback et chargeback) sont méritantes, mais restent complexes et subjectives.
Évaluer la valeur de l’application comme contribution à l’organisation est une approche certes fondée, mais difficile à faire. S’il est possible de rattacher une application à un ou plusieurs processus, comment d’une part définir la quote-part de l’application dans le processus et valoriser le processus lui-même ?
En revanche, il est possible de définir des indicateurs clés de performance (ou Key Performance Indicator, KPI) sur les processus et mettre le coût de possession de l’application (ou Total Cost of Ownership, TCO) au regard des KPI. Le ratio du TCO sur le KPI (ou une somme pondérée de KPI) peut donner une indication de la pertinence économique de l’application. Par exemple :
- Une marketplace prend 5% du chiffre d’affaires en commission. Si la marketplace permet d’augmenter suffisamment le chiffre d’affaires pour compenser la perte de marge unitaire, c’est un bon calcul.
- Une application de gestion d’offre bancaire supporte à coût constant une augmentation du PNB d’un facteur 5. Cela peut motiver à reverser une partie des gains économiques pour poursuivre l’entretien et la modernisation de cette application.
En considérant l’évolution dans le temps du ratio TCO sur KPI, on peut apprécier les gains d’efficience de l’application ou au contraire sa dégradation. La maintenance d’une application peut dégager une performance si l’application gagne en efficience.
Valeur Métier
L’application réalise des cas d’usages (comment ?) autour d’un modèle métier (quoi ?) avec un niveau de qualité requis (traduisible par les exigences non fonctionnelles). Sa valeur est donc fonction de la qualité de l’implémentation des cas d’usage et de l’adéquation du modèle métier au contexte.
Quand le cas d’usage est bien implémenté, la cinématique proposée fluidifie le parcours utilisateur, l’exposition à l’utilisateur est intuitive (en écran ou en API) et le comportement du système est prévisible. Quant au modèle métier, on cherche à disposer d’un vocabulaire fonctionnel commun et précis (Ubiquitous Language), d’une organisation de concept permettant de décrire des cas simples, mais aussi des cas avancés de façon élégante et d’une capacité à gérer l’écart avec la réalité.
L’application évolue naturellement avec le mode opératoire de l’organisation. Les cas d’usage sont donc susceptibles de changer plus vite que le modèle métier. Aussi, la valeur issue des cas d’usage demande un investissement régulier pour se maintenir. A contrario, l’effort sur le modèle métier produit une valeur plus durable.
Le code lié à la définition et à la manipulation du modèle métier représente une part mineure du code.
Pour illustrer ce point, considérons un composant applicatif qui expose une entité par une API REST. En utilisant JHipster, il est possible de le générer à partir d’un DSL décrivant le modèle métier. Cette génération produit une implémentation tout à fait honorable : cache de persistance, internationalisation, contrôle d’accès, tests, interface d’administration… Le DSL représente seulement 1% de la totalité du code généré.
Cette génération automatique démontre que la valeur de ce composant dépend entièrement de ce 1% de code. On pourrait objecter que ce cas est limite. Pourtant, il est observé régulièrement, bien qu’il puisse poser un certain nombre de problèmes, à commencer par l’observation de l’anti-pattern, le domaine anémique.
Dans la production de la valeur métier, on dépasse la loi de Pareto qui pourrait s’exprimer comme « 20% du code est responsable de 80% de la valeur ». Le ratio est encore plus prononcé : quelques pourcents sont à l’origine de quasiment toute la valeur ! On pourrait appuyer ce propos en considérant que la plupart des fonctionnalités ne sont pas utilisées (voir le rapport Chaos à ce sujet, même si c’est une source un peu ancienne.).
Aussi, la conception est une étape clé dans la production de la valeur métier. La construction du modèle métier doit être pensée soigneusement afin de donner à l’application une fondation solide. C’est néanmoins une étape négligée pour « gagner du temps » dans le but de tenir les premiers jalons. Y compris dans une approche agile, la dette sur le modèle métier est difficile à rattraper.
Valeur technique
The trouble with quick and dirty is that dirty remains long after quick has been forgotten.
Steve McConnell
La qualité de l’application se constate par l’atteinte d’exigences techniques (disponibilité, intégrité, sécurité, performance…). Plus le niveau d’exigence est élevée, plus l’application se doit d’être de qualité. Le propos semble évident. Et pourtant ! Combien de fois attend-on d’une réalisation en quick and dirty une qualité dans l’exécution du service ?
La capacité d’une application à répondre à des exigences élevées (haute disponibilité, haute performance, haute sécurité…) est en soi une force. Une conception avancée et un soin particulier dans l’implémentation sont alors requis. Des démarches de qualité logicielle comme le Software Craftsmanship fournissent souvent le substrat culturel de telles organisations.
La valeur de l’application peut résider essentiellement dans la qualité. Par exemple, des applications peuvent adresser un modèle métier concis et des cas d’usage simple et supporter des charges de travail importantes avec une grande efficience. Elles permettent à leur organisation de baisser les coûts unitaires des services d’une organisation et prendre des parts de marché.
La qualité de l’application peut être mesurée par un indicateur calculé automatiquement comme la Fitness Function.
Pour que la qualité compte, il est nécessaire de s’assurer de son adéquation au besoin et donc de qualifier les exigences techniques. Également, il convient de mesurer l’atteinte des exigences de façon factuelle pendant l’exécution du service de façon à rendre cette qualité tangible. Sans ces deux conditions, la qualité n’est ni reliée au besoin, ni rendue crédible auprès des stakeholders et donc finit par sortir du contexte de travail.
Conclusion
La valeur de l’application peut être considérée au travers de 3 axes complémentaires :
- La valeur économique, définie comme la contribution de l’application à la performance des processus par la mesure du ratio KPI/TCO ;
- La valeur métier s’exprimant comme la concision du modèle métier à décrire le contexte métier et à évoluer avec et aussi l’efficacité des cas d’usage ;
- La valeur technique décrite comme la capacité à respecter des exigences techniques.
Pour que les applications délivrent la valeur attendue, une démarche active est nécessaire afin d’orienter les feuilles de route pour aller chercher plus de valeur et motiver les efforts pour protéger la valeur existante de l’entropie et de l’obsolescence. À l’inverse, quand la valeur de l’application n’est pas considérée, les efforts peuvent être dispersés dans la multiplication de quick wins qui finissent par atteindre la disposition de l’application à continuer de produire de la valeur et donc sa pérennité.