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 dirty1, 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 moral2, 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 3 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 !
