exigence-technique – Zoom In and Out

Que vaut une application ?

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, vue comme un chainon dans la chaine de valeur

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.

Les rôles informationnels de l’application

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.

Plan de masse du code d’un composant d’exposition API REST

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.).

La loi de Pareto appliquée à la valeur métier du code.

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é.

Les exigences techniques, l’antidote au « quick and dirty »

Pour éviter le quick & dirty systématique, la définition et la mise en oeuvre des exigences techniques peuvent aider.

La définition des exigences techniques et leur mise en œuvre effective font partie des pratiques les plus difficiles sur les projets informatiques, toutefois nécessaires. Que se passe-t-il quand elles ne sont pas réalisées ? Face à un métier pressé, la solution rapide, dite quick and dirty¹, est une option attrayante. Et quand elle est déployée, il est difficile d’avoir l’accord du métier pour la refaire en plus solide. Après tout, le métier a eu ce qu’il veut et ne voit pas, de prime abord, le bénéfice à ce refactoring. La maintenance du code est le problème des informaticiens ! Face à cet aléa moral², la pratique des exigences techniques peut apporter une réponse.

Les exigences techniques ne sont pas les exigences de l’IT

Les exigences techniques (ou exigences non-fonctionnelles) sont aussi nécessaires que les exigences fonctionnelles pour permettre à l’application (ou au produit) de répondre aux attentes. Une application, qui n’adresserait que des exigences fonctionnelles, serait certes utile, mais pas utilisable et donc pas utilisée (d’où quelques frustrations !). Par exemple, un utilisateur face à une interface lente (problème de performance) ou confronté à des informations peu fiables (manque d’intégrité) ou encore échangeant avec un système non sécurisé (divulgation d’information) finira par trouver d’autres possibilités plus acceptables avec son mode opératoire.
À la différence des exigences fonctionnelles, elles ont une portée globale et leur validation passe par d’autres mécanismes que la recette fonctionnelle (tests de performance, tests de sécurité, tests de robustesse, qualimétrie, …).

Les exigences techniques sont désignées de la sorte, car leur validation passe par des moyens techniques et non parce qu’elles sont à l’origine des acteurs IT !

Ce malentendu, probablement dû à un nommage malheureux, peut faire croire aux acteurs Métier qu’ils ne sont pas concernés (ou qu’ils peuvent se sentir légitimes à ne pas les prendre en considération !).

L’acronyme FURPS+ permet de se rappeler une classification des exigences dans leur ensemble. Dans cette méthodologie, le point de départ est un ensemble de questions qui s’adressent au métier pour l’aider à qualifier les exigences. Toutes ces questions sont intéressantes pour le métier.

Fonctionnalité : Que veut-faire le métier ? Les besoins liés à la sécurité sont aussi inclus sous ce terme.
Facilité d’Utilisation : Dans quelle mesure le produit est-il efficace du point de vue de la personne qui s’en sert ?
Résilience : Quel est le temps d’arrêt maximal acceptable pour le système ? Comment redémarrer le service ?
Performance : Quelle doit être la rapidité du système ? Quel est le temps de réponse maximal ? Quel est le débit ?
Supportabilité : Est-il testable, extensible, réparable, installable et configurable ? Peut-il être supervisé ?

Le ‘+’ final désigne des considérations IT qui peuvent ne pas intéresser directement le métier telles les contraintes de conception, d’implémentation ou encore de déploiement. Toutefois, leur mise en œuvre affecte la qualité du produit et concerne in fine le métier.

Piloter la complexité du SI

Les architectes sont garants de la bonne santé du système d’information, mais aussi de la proportionnalité des moyens alloués par rapport aux objectifs attendus. Cela se traduit par la maitrise de la complexité du SI dans un cadre spatio-temporel.

Sur un plan spatial, la complexité devrait être concentrée dans les zones du SI où elle apporte de la valeur. La complexité n’est jamais gratuite ! Le framework Cynefin est une bonne méthode tactique pour adapter la réponse au problème. Pour les situations simples, des solutions simples… et pour des situations complexes, des approches émergentes ! Ce principe semble marquer au coin du bon sens. Pourtant, la tentation des solutions « Et ce serait cool si … » est très forte pour des technophiles et autres adorateurs de la nouveauté. Malheureusement, quand l’effet « cool » s’essouffle, la maintenance devient un problème épineux et les adorateurs de la première heure peuvent être déjà partis… À un niveau plus stratégique, on peut s’appuyer sur le Core Domain Chart est pour prioriser les domaines où insérer de la complexité peut être payant, par exemple pour se différencier (en bien !).

Abordons maintenant la dimension temporelle. La complexité a la fâcheuse propriété à augmenter dans le temps. Cela peut se faire de façon passive avec le phénomène d’entropie, obtenu par un cumul de changements dans le code, dégradant la conception du système, mais aussi de façon active quand l’application répond à de sollicitations de plus en plus grandes. Paradoxalement, une application qui connait une réussite dans son usage peut se voir injecter une dose de complexité qui pourra finir par la tuer, victime de son succès en quelque sorte !

Quand la complexité devient trop importante, l’application n’est plus maintenable et évolutive, ce qui implique sa fin de vie à plus ou moins brève échéance. Les projets en Quick and Dirty ³ arrivent plus vite que les autres à ce stade fatidique.

L’idéal est de réaliser, maintenir et opérer des applications qui atteignent les exigences tout en minimisant la complexité le plus bas possible.

Si les exigences ne sont pas posées, alors la complexité peut ne pas être adaptée au besoin (et c’est souvent le cas, en pratique) que ce soit par insuffisance (une solution simpliste qui ne répond pas au besoin) ou par excès (un « marteau pour écraser une mouche », aussi connu comme l’anti-pattern Marteau doré)

Base du contrat de confiance entre métier et SI

L’exigence peut servir à écrire des articles dans le contrat de confiance entre métier et IT, à condition d’être SMART.

Pour se rappeler ces bonnes caractéristiques, l’acronyme SMART est un bon moyen mnémotechnique.

L’exigence est Spécifique pour ne pas être qu’un souhait.
L’exigence est Mesurable pour ne pas être qu’une promesse en l’air.
L’exigence est Atteignable pour être un engagement sincère.
L’exigence est Raisonnable pour avoir du sens.
L’exigence est Traçable pour être une propriété effective de l’application.

« Faire ce qu’on fit et faire ce qu’on dit » est généralement une bonne pratique pour instaurer une bonne relation de confiance ! L’exigence permet de poser et partager un attendu et de se donner les moyens de l’atteindre effectivement.

Tout le monde a des attentes !

Toutes les parties prenantes ont des attentes par rapport au SI. Elles peuvent être en dehors du cadre de l’organisation (administrations, partenaires, clients) ou à l’intérieur (direction générale, contrôle interne, direction métier, direction informatique, etc).

Ces attentes peuvent être déclinées en exigences. Entre l’attente et l’exigence, l’écart sera plus ou moins important en fonction du caractère contraignant de l’attente (par exemple, une disposition règlementaire) et de la marge d’interprétation. L’écart pourra être ajusté suite à une négociation.

Il est recommandé de collecter ces attentes le plus tôt possible et non de les découvrir à la fin de l’itération. Une attente pourra être suffisamment contraignante pour remettre en cause une partie de l’implémentation et sans doute le calendrier !

À l’inverse, il ne faut pas être plus royaliste que le roi. Pour les premières itérations, des exigences faibles pourront être acceptables, sachant que les exigences seront redéfinies pour les itérations finales dans des formes plus élevées. C’est un des principes de la Continuous Architecture et de l’ Architecture Runaway.

Comment calibrer les exigences ?

Si l’objet des exigences techniques est bien connue (FURPS+, cela vous parle ? 😉), en revanche le calibrage est plus difficile.

Prenons une exigence portant sur la vitesse d’affichage d’un écran. Comment définir la valeur à atteindre en cible ? Il faut à la fois tenir compte du fonctionnement de l’attention humaine (moins d’une seconde pour garder la fluidité dans l’interaction), des attendus des utilisateurs au travers de leur expérience digitale, que ce soit dans un cadre professionnel ou personnel (les services des GAFAM sont rapides !), et des moyens techniques communément atteignables par une organisation classiques. Une façon d’apporter une réponse est de se comparer au marché. Voulons-nous que l’application se situe dans le 1% des meilleurs, le premier décile, la première moitié ou peu importe ? C’est l’idée des Core Web Vitals, prendre en compte les statistiques de HTTP Archive et construire des cibles par rapport à ce que l’on fait. Une exigence construite sur ce principe a la particularité de varier dans le temps, car chaque année, le niveau peut monter (et même baisser, c’est possible).

Pour d’autres exigences plus normatives comme la sécurité ou l’accessibilité, il existe des normes avec des niveaux de conformité plus ou moins élevées à aller chercher (RGAA pour l’accessibilité, OWASP pour la sécurité, par exemple).

Le compétiteur ou la référence du marché peut aussi donner des idées. La concurrence a du bon ! C’est souvent un bon argument pour ajuster l’exigence à un niveau à la fois performant et raisonnable.

Et si malgré tout, on ne trouve pas toujours pas d’inspiration, on pourra se référer sur les référentiels d’exigences classiques comme DICT. Si les niveaux élevés de DICT sont atteignables par les moyens techniques mis à dispositions par les hyperscalers, les limites posées par la capacité financière et par l’organisation de l’exploitation restent toujours à adresser.

Passer du besoin à l’exigence

Les attentes peuvent être, au départ, implicites ou alors abstraites. Cela peut conduire à plusieurs écueils :

Le demandeur formule une exigence absolue (par exemple, une demande d’une disponibilité à 100%). La motivation peut être une aversion au risque (et un transfert de responsabilité à l’IT). Le demandeur peut aussi ne pas comprendre en quoi cette question le concerne alors que la qualité du résultat dépend du niveau d’exigence.
Le demandeur renvoie la question à l’IT en demandant ce qu’elle peut fournir au mieux.
Le demandeur n’a qu’une seule exigence, qu’il n’y a pas de problème ! 😒

Fournir un catalogue de niveau de service sur lequel l’IT peut s’engager est une bonne base de discussion. Ce catalogue consiste en une liste d’exigences SMART organisées par niveau de service.

Cela permet de ne pas partir d’une feuille blanche et de disposer d’un format synthétique pour faciliter les échanges. De plus, plus que 90% des applications rentrent certainement dans des niveaux standards. On a donc un gain de temps significatif dans la qualification des exigences. Cela permet de se concentrer sur les quelques applications critiques qui vont nécessiter des moyens particuliers pour atteindre des niveaux de service très élevés.

Disposer d’un niveau de service minimal permet de définir dans tous les cas un engagement explicite, y compris unilatéralement. Et si ce niveau ne correspond aux attentes effectives lors d’incident, alors il est toujours possible de requalifier le niveau de service et de lancer un chantier de remédiation.

Passer de l’exigence au business case

À ce stade, nous disposons d’exigences SMART. Elles sont suffisamment claires pour pouvoir évaluer les conséquences concrètes sur la construction et l’exploitation des applications. Nous disposons de bases pour estimer l’effort de fabrication, mais aussi le cout de fonctionnement.

Les exigences peuvent s’avérer trop onéreuses au regard de la valeur attendue ou alors trop complexes à mener au vu des ressources de l’organisation. À ce moment, le demandeur peut revoir le besoin afin d’améliorer le business case de la solution ou sécuriser sa mise en œuvre.

L’ajustement des exigences pour adapter l’effort à la valeur attendue permet de mettre le projet sur des bases équilibrées : le bon niveau d’effort pour le bon résultat attendu. Quand le métier et l’IT sortent tous les deux gagnants dans la réalisation du business case et dans la mise en place du produit, c’est une situation plutôt satisfaisante ! Pour cela, même si les exigences demandent de prendre un chemin parfois difficile, la récompense à l’arrivée en vaut la peine !