Les modèles de qualité : l’ISO/IEC 25010 et comment l’utiliser

À quoi sert un modèle de qualité

La section 2.1 a soutenu que les attributs de qualité déterminent l’essentiel d’une architecture. La question suivante est évidente : quelles qualités ? Livrées à elles-mêmes, les parties prenantes citent les deux ou trois qui les ont fait souffrir en dernier, généralement la vitesse et la disponibilité, et oublient le reste jusqu’à ce qu’il soit trop tard. Un modèle de qualité est une liste structurée de caractéristiques de qualité, chacune découpée en sous-caractéristiques plus fines, avec des noms et des définitions convenus. Il remplit deux fonctions. Il donne à tous un vocabulaire commun, afin que « fiabilité » signifie la même chose pour le product owner, le testeur et le fournisseur. Et il sert de liste de contrôle, en vous incitant à envisager des qualités que personne n’a encore évoquées.

Un modèle ne vous dit pas quelles qualités comptent pour votre système, ni quel niveau de chacune il vous faut. Cela vient des parties prenantes et des objectifs métier (section 2.8). Il ne vous dit pas non plus comment les atteindre ; c’est le rôle des tactiques, des patrons et du reste de ce cours. C’est une carte du territoire, pas un itinéraire pour le traverser.

L’ISO/IEC 25010:2023 : le modèle de qualité des produits

Le modèle le plus souvent cité est l’ISO/IEC 25010, qui fait partie de la famille de normes SQuaRE (Systems and software Quality Requirements and Evaluation). La deuxième édition, publiée en novembre 2023, définit un modèle de qualité des produits en neuf caractéristiques. Elle s’applique aux produits logiciels et, plus largement, aux produits TIC, et la norme en énumère les usages : spécifier des exigences, vérifier que les exigences sont complètes, fixer des objectifs de conception et de test, définir des critères d’acceptation et établir des mesures de qualité. D’autres normes de la famille définissent comment mesurer chaque sous-caractéristique (ISO/IEC 25023) et comment évaluer un produit.

Les neuf caractéristiques sont l’adéquation fonctionnelle, l’efficacité des performances, la compatibilité, la capacité d’interaction, la fiabilité, la sécurité, la maintenabilité, la flexibilité et la sûreté. La première indique si le système fait les bonnes choses correctement ; les huit autres décrivent à quel point il les fait bien et à quel point il peut être exploité, protégé et modifié. Le schéma ci-dessous montre la structure ; le tableau qui le suit énumère chaque sous-caractéristique avec un exemple de question qu’un architecte pourrait poser.

Quelques définitions méritent d’être connues avec précision, car elles diffèrent de l’usage courant. Dans l’ISO/IEC 25010, la disponibilité est une sous-caractéristique de la fiabilité : le degré auquel un système est opérationnel et accessible lorsqu’on en a besoin. L’absence de fautes est le degré auquel un système exécute ses fonctions sans faute en fonctionnement normal. La capacité, sous l’efficacité des performances, est la limite maximale d’un paramètre, comme le nombre d’utilisateurs simultanés ou de transactions par seconde, qui satisfait encore les exigences. La scalabilité se range sous la flexibilité, ce qui reflète une vision du passage à l’échelle comme capacité à s’adapter à une charge changeante plutôt que comme une question de vitesse brute. La résistance, nouvelle sous la sécurité, est la capacité à maintenir les opérations en cours d’attaque. Les sections 2.4 à 2.7 reviennent en profondeur sur ces qualités ; la section 2.5 montre comment calculer la disponibilité.

Ce qui a changé depuis l’édition 2011

La première édition, l’ISO/IEC 25010:2011, a remplacé l’ancien modèle ISO/IEC 9126 et est devenue la référence pendant une décennie. De nombreux manuels, dossiers d’appel d’offres et gabarits utilisent encore ses huit caractéristiques ; il vaut donc la peine de savoir ce qui a changé.

Les changements de nom sont plus que cosmétiques. « Capacité d’interaction » élargit le champ de la facilité d’utilisation à l’ensemble des échanges d’informations entre les utilisateurs et le produit dans différents contextes d’utilisation, et la nouvelle sous-caractéristique d’inclusivité place l’accessibilité pour des personnes d’âges et de capacités différents au centre plutôt qu’en marge. « Flexibilité » regroupe les qualités qui permettent à un produit de faire face aux changements de son environnement : nouvelles plateformes, nouvelles cibles d’installation, et charge plus ou moins forte. L’ajout de la sûreté comme caractéristique de produit reflète la part de logiciel qui pilote désormais des objets physiques, des voitures aux dispositifs médicaux.

Le second changement structurel est que la qualité en utilisation, c’est-à-dire la qualité vécue par les personnes qui utilisent le produit dans un contexte réel, dispose désormais de sa propre norme, l’ISO/IEC 25019:2023. Ses trois caractéristiques sont le caractère bénéfique (utilisabilité, accessibilité et adéquation en utilisation), l’absence de risque (risques économiques, pour la santé, pour la vie humaine, et risques environnementaux et sociétaux) et l’acceptabilité (expérience, confiance et conformité). Cette séparation clarifie une distinction utile pour les architectes : la qualité du produit est ce que vous construisez et pouvez tester dans le produit ; la qualité en utilisation est le résultat pour des personnes réelles, qui dépend aussi de la formation, du contexte et de la manière dont le produit est déployé.

D’autres listes que vous rencontrerez

L’ISO/IEC 25010 n’est pas la seule taxonomie, et les praticiens utilisent souvent des listes plus simples ou découpées autrement. FURPS+ est issu de FURPS, une classification développée chez Hewlett-Packard et exposée par Robert Grady et Deborah Caswell dans Software Metrics: Establishing a Company-Wide Program (1987). FURPS regroupe les exigences en fonctionnalité, utilisabilité, fiabilité, performances et supportabilité ; l’extension « + », plus tardive, ajoute les contraintes : contraintes de conception, d’implémentation, d’interface et physiques et, dans certaines versions, règles métier. FURPS+ s’est popularisé grâce au Rational Unified Process et à ses successeurs. Sa force est sa concision ; sa faiblesse est que la « supportabilité » met dans le même sac maintenabilité, testabilité, configurabilité, facilité d’installation et localisation.

Bass, Clements et Kazman, dans la quatrième édition de Software Architecture in Practice (2021), ne cherchent pas l’exhaustivité. Ils consacrent un chapitre à chacune des qualités qui orientent le plus souvent les architectures : disponibilité, déployabilité, efficacité énergétique, intégrabilité, modifiabilité, performances, sûreté, sécurité, testabilité et utilisabilité, suivis d’un chapitre sur le travail avec les autres qualités. Pour chacune, ils donnent un scénario général et un catalogue de tactiques. Leur liste est organisée autour de la conception plutôt que de l’évaluation, ce qui la rend particulièrement utile aux architectes.

Mark Richards et Neal Ford, dans Fundamentals of Software Architecture, emploient le terme de caractéristiques d’architecture et les répartissent en groupes : opérationnelles (disponibilité, performances, scalabilité), structurelles (modifiabilité, extensibilité, portabilité) et transversales (sécurité, accessibilité, aspects juridiques). Le modèle ouvert Q42 de Gernot Starke, tenu à jour parallèlement au modèle arc42, adopte encore une autre approche : il associe bien plus d’une centaine de qualités nommées à neuf dimensions (efficace, flexible, maintenable, exploitable, fiable, sûr, sécurisé, adapté, utilisable) et fournit des exemples d’exigences pour chacune.

Ces listes divergent dans le détail mais se recoupent largement. Ce désaccord est lui-même instructif : il n’existe pas de décomposition unique et correcte de la « qualité », seulement des décompositions plus ou moins utiles selon l’objectif. Utiliser un modèle normalisé aide lorsqu’il faut communiquer avec les achats, les auditeurs ou d’autres organisations ; une liste plus légère peut mieux servir une équipe produit au quotidien.

Utiliser un modèle comme liste de contrôle sans créer de bureaucratie

Le grand risque d’un modèle de qualité est qu’il devienne un formulaire. Un gabarit d’exigences comportant une rubrique pour chacune des 40 sous-caractéristiques incite à remplir chaque case, et le résultat est un document rempli d’énoncés comme « le système doit être maintenable » que personne ne lit et que personne ne teste. L’effort se répartit uniformément sur des qualités dont l’importance est très inégale, et les deux ou trois qualités qui décideront réellement de l’architecture se perdent parmi les autres.

Une meilleure approche consiste à traiter le modèle comme point de départ d’une conversation. Parcourez les caractéristiques avec les parties prenantes une fois, rapidement, en demandant pour chacune : est-ce important pour notre système et, si oui, à quoi ressemblerait un échec ? Écartez explicitement celles qui ne sont pas pertinentes (écrire « sûreté : sans objet, l’app ne peut causer aucun dommage physique » est utile, car cela consigne une décision). Transformez celles qui sont pertinentes en un petit nombre de scénarios concrets et mesurables (section 2.3). Classez-les (section 2.8). Puis rangez le modèle jusqu’à la prochaine revue.