Sécurité, utilisabilité, interopérabilité, coût et durabilité en tant que qualités

La sécurité en tant qu’attribut de qualité

La sécurité est la capacité du système à protéger les données et les fonctions contre l’accès et l’utilisation non autorisés, tout en continuant à servir les personnes autorisées. Les architectes partent souvent de la triade CIA : la confidentialité (seules les parties autorisées peuvent lire les données), l’intégrité (les données et le code ne sont pas modifiés sans autorisation, et toute modification est détectable) et la disponibilité (les utilisateurs autorisés peuvent utiliser le service quand ils en ont besoin). Les attaques se rattachent à ces trois propriétés : voler des fiches clients porte atteinte à la confidentialité, modifier les coordonnées bancaires d’un bénéficiaire porte atteinte à l’intégrité, et une attaque par déni de service porte atteinte à la disponibilité.

L’ISO/IEC 25010:2023 affine ce tableau. Sa caractéristique de sécurité comporte six sous-caractéristiques : la confidentialité, l’intégrité, la non-répudiation (on peut prouver que des actions ou des événements ont eu lieu, de sorte qu’une partie ne puisse pas les nier ensuite), l’imputabilité (les actions peuvent être attribuées de manière univoque à l’entité qui les a effectuées), l’authenticité (on peut prouver que l’identité d’un sujet ou d’une ressource est bien celle qui est revendiquée) et, nouveauté de l’édition 2023, la résistance (le produit continue de fonctionner comme prévu lorsqu’il est attaqué par un acteur malveillant). Dans ce modèle, la disponibilité relève de la fiabilité, c’est pourquoi elle a été traitée à la section 2.5.

Rédiger des scénarios de sécurité

« Le système doit être sécurisé » ne permet ni de concevoir ni de tester. Un scénario de sécurité nomme une source (qui attaque, avec quel accès), un stimulus (ce qu’elle tente), un artefact (ce qui est visé), un environnement (en ligne, pendant un incident, avec l’attaquant déjà à l’intérieur du réseau), une réponse et une mesure. En sécurité, les mesures portent souvent sur le délai de détection, l’ampleur des dégâts ou le délai de rétablissement, car « aucune attaque ne réussit jamais » est invérifiable.

Trois exemples pour une banque en ligne. Bourrage d’identifiants (credential stuffing) : un attaquant externe essaie des paires nom d’utilisateur et mot de passe ayant fuité contre l’API de connexion, à raison de 50 tentatives par seconde depuis de nombreuses adresses ; le système détecte le schéma en moins de 2 minutes, soumet les adresses sources à une vérification supplémentaire ou les bloque, et l’attaquant ne prend le contrôle d’aucun compte protégé par l’authentification multifacteur. Falsification interne : un employé du support disposant d’un accès légitime modifie les coordonnées d’un bénéficiaire d’un client ; la modification requiert l’approbation d’une deuxième personne, et le journal d’audit enregistre qui, quoi et quand sous une forme que l’employé ne peut pas modifier. Sauvegarde volée : un attaquant obtient une copie de la sauvegarde de la base de données de la semaine dernière ; toutes les données personnelles qu’elle contient sont chiffrées avec des clés stockées séparément, si bien qu’aucune donnée client n’est lisible.

Notez que chaque scénario implique une architecture différente : limitation de débit (rate limiting) et détection d’anomalies en périphérie, circuit d’approbation à quatre yeux et journaux révélant toute altération, et chiffrement avec une gestion des clés séparée. Trouver ces scénarios de manière systématique est le rôle de la modélisation des menaces, traitée au chapitre 8.

Tactiques de sécurité : vue d’ensemble

Bass, Clements et Kazman regroupent les tactiques de sécurité selon le moment où elles agissent. Résister aux attaques : identifier, authentifier et autoriser les acteurs, limiter l’accès et l’exposition (moins de ports ouverts, moins d’endpoints publics, moindre privilège), chiffrer les données en transit et au repos, séparer les entités (données sensibles dans leur propre stockage ou segment de réseau), modifier les paramètres par défaut et valider les entrées. Détecter les attaques : détection d’intrusion, détection du déni de service, vérification de l’intégrité des messages et repérage des délais ou des schémas inhabituels. Réagir aux attaques : révoquer l’accès, verrouiller les comptes après des échecs de connexion, informer les opérateurs et les utilisateurs. Se rétablir après une attaque : restaurer un état sain connu (à nouveau les tactiques de disponibilité) et conserver une piste d’audit pour comprendre ce qui s’est passé et étayer la non-répudiation.

Cette section ne fait que présenter ces familles. Les principes comme la défense en profondeur et le moindre privilège, les protocoles d’identité, le chiffrement, le zero trust et la sécurité de la chaîne d’approvisionnement sont l’objet du chapitre 8. Le point architectural ici est que la sécurité est une propriété de toute la structure, et non un composant que l’on ajoute à la fin : l’emplacement des frontières de confiance, le composant qui détient telle ou telle donnée et la manière dont les services s’authentifient mutuellement sont des décisions précoces et coûteuses à changer.

Utilisabilité, capacité d’interaction et accessibilité

L’ISO/IEC 25010:2023 a renommé l’utilisabilité en capacité d’interaction : le degré auquel des utilisateurs spécifiés peuvent interagir avec un produit pour échanger des informations via l’interface utilisateur afin d’accomplir des tâches spécifiques. Ses sous-caractéristiques sont la reconnaissabilité de l’adéquation, la facilité d’apprentissage, l’opérabilité, la protection contre les erreurs de l’utilisateur, l’engagement de l’utilisateur (qui a remplacé l’esthétique de l’interface utilisateur), l’inclusivité, l’assistance à l’utilisateur et l’autodescription. Une grande partie de tout cela relève du design d’interaction plutôt que de l’architecture, mais plusieurs préoccupations d’utilisabilité touchent profondément la structure.

La réactivité est la plus évidente. Des recommandations de longue date en ergonomie, popularisées par Jakob Nielsen, fixent trois limites : environ 0,1 seconde paraît instantané, environ 1 seconde préserve le fil de la pensée de l’utilisateur, et environ 10 secondes constituent la limite de l’attention. Les respecter peut exiger du cache, un traitement asynchrone avec indication de progression, ou des mises à jour optimistes. Annuler et interrompre sont des questions d’architecture : prendre en charge annuler les cinq dernières actions exige des commandes réversibles, et interrompre un long envoi de fichier exige une opération qu’on peut arrêter proprement. Le fonctionnement hors ligne d’une app mobile exige un stockage local et une synchronisation avec gestion des conflits. Il est bien moins coûteux de prévoir tout cela dès la conception que de l’ajouter après coup.

L’accessibilité, c’est-à-dire la possibilité pour les personnes handicapées d’utiliser le produit, est de plus en plus une contrainte légale plutôt qu’une préférence. Les Web Content Accessibility Guidelines version 2.2 (WCAG 2.2), recommandation du W3C depuis octobre 2023, définissent des critères de succès testables aux niveaux A, AA et AAA ; le niveau AA est la référence habituelle sur le plan légal et dans les marchés publics. Les WCAG 2.2 ont ajouté neuf critères, dont des tailles minimales de cible pour les dispositifs de pointage et l’authentification accessible (aucune étape de la connexion ne peut dépendre d’un test de fonction cognitive, comme mémoriser un mot de passe ou recopier un code, sauf si l’utilisateur se voit proposer une autre méthode ou une aide, comme le collage depuis un gestionnaire de mots de passe ; quelques autres exceptions limitées s’appliquent). Dans l’Union européenne, l’acte européen sur l’accessibilité (directive (UE) 2019/882) s’applique depuis le 28 juin 2025 à de nombreux produits et services destinés aux consommateurs, dont le commerce électronique, les services bancaires, les livres numériques et les services de transport de voyageurs. Pour un architecte, l’accessibilité est donc une contrainte à recueillir tôt : elle influe sur le choix du framework frontend, le design system, le parcours d’authentification et le pipeline de test (vérifications automatisées de l’accessibilité en intégration continue, plus des tests manuels avec des technologies d’assistance).

Interopérabilité

L’interopérabilité est le degré auquel deux systèmes ou plus peuvent échanger des informations et utiliser les informations échangées. L’ISO/IEC 25010 la range sous la compatibilité, à côté de la coexistence. Elle comporte deux niveaux. L’interopérabilité syntaxique signifie que les systèmes s’accordent sur le format et le protocole : tous deux parlent HTTP et JSON. L’interopérabilité sémantique signifie qu’ils s’accordent sur le sens : "amount": 1050 est exprimé en pence, pas en livres ; status: "closed" signifie payé, pas annulé. La plupart des échecs d’intégration sont d’ordre sémantique.

Les secteurs d’activité réduisent le coût de l’accord sémantique grâce à des normes communes : HL7 FHIR pour l’échange de dossiers de santé, ISO 20022 pour les messages financiers, GTFS pour les horaires de transports publics. Les tactiques architecturales comprennent la découverte de services via un registre, l’adaptation des interfaces au moyen d’adaptateurs et de traducteurs, et une gestion explicite des versions pour que les partenaires plus anciens continuent de fonctionner. Un scénario d’interopérabilité pourrait s’énoncer ainsi : Un nouvel hôpital rejoint le réseau et échange des résumés de dossiers patients à l’aide de ressources FHIR R4 en moins de 4 semaines, sans modification du service central de dossiers.

Le coût en tant que qualité

Le coût figure rarement dans les modèles de qualité, et pourtant il contraint chaque décision d’architecture. Distinguez le coût de construction (l’effort nécessaire pour créer le système), le coût d’exploitation (infrastructure, licences, services tiers, support) et le coût du changement (l’effort nécessaire pour chaque modification future, ce dont traite la modifiabilité). Dans le cloud, le coût d’exploitation est variable et directement façonné par l’architecture : des services trop bavards paient le transfert réseau, des clusters surdimensionnés paient de la capacité inutilisée, et un schéma de requêtes négligent peut multiplier la facture de base de données.

Une manière utile de faire du coût un attribut de qualité est le coût unitaire : coût par transaction, par utilisateur actif ou par commande. Contrairement à une facture mensuelle totale, il montre si l’architecture devient plus ou moins efficiente à mesure que l’activité croît, et il peut s’écrire sous forme de scénario : À 3 millions de commandes par mois, le coût d’infrastructure reste inférieur à 1 penny par commande. Les pratiques FinOps pour le gérer sont traitées au chapitre 10.

Efficacité énergétique et durabilité

Le logiciel n’émet pas de carbone lui-même, mais le matériel sur lequel il tourne consomme de l’électricité et porte en lui les émissions de sa fabrication. La spécification Software Carbon Intensity (SCI) de la Green Software Foundation, publiée par l’ISO sous la référence ISO/IEC 21031:2024, définit un taux : les émissions opérationnelles (l’énergie E multipliée par l’intensité carbone I de l’électricité) plus les émissions incorporées M, divisées par une unité fonctionnelle R, comme un utilisateur, un appel d’API ou une commande. Elle identifie trois leviers : l’efficacité énergétique (consommer moins d’électricité pour le même travail), l’efficacité matérielle (utiliser moins d’appareils, et les utiliser plus pleinement et plus longtemps) et la conscience carbone (exécuter le travail flexible quand et là où l’électricité est plus propre).

L’architecture influe sur les trois. Le bon dimensionnement et un taux d’utilisation plus élevé améliorent l’efficacité matérielle ; le cache, des formats de données efficaces et l’absence de travail inutile améliorent l’efficacité énergétique ; les files d’attente et le traitement par lots permettent de décaler le travail dans le temps ou dans l’espace. La durabilité va souvent dans le même sens que le coût, mais pas toujours : maintenir un warm standby (secours tiède) dans une deuxième région améliore la disponibilité et double les émissions incorporées. Les grands modèles d’IA rendent la question plus pressante, comme l’explique le chapitre 12.

Sûreté (safety)

La sûreté est l’absence de risque inacceptable de dommage aux personnes, aux biens ou à l’environnement. Elle diffère de la sécurité : la sécurité protège le système contre des personnes mal intentionnées ; la sûreté protège les personnes contre le système, y compris quand personne n’est malveillant. L’ISO/IEC 25010:2023 a ajouté la sûreté comme neuvième caractéristique, avec pour sous-caractéristiques la contrainte opérationnelle, l’identification des risques, la sécurité intrinsèque en cas de défaillance (fail safe), l’avertissement de danger et l’intégration sûre.

Les domaines critiques pour la sûreté ont leurs propres normes, qui imposent une architecture et un processus : IEC 61508 pour la sécurité fonctionnelle en général, ISO 26262 pour les véhicules routiers, IEC 62304 pour les logiciels de dispositifs médicaux et DO-178C pour les logiciels embarqués aéronautiques. Les tactiques typiques sont un comportement par défaut sûr (un train s’arrête quand les signaux sont perdus), des canaux de surveillance indépendants capables de prendre le pas sur le contrôleur principal, la redondance avec vote, et une séparation stricte des composants critiques pour la sûreté de tout le reste, afin qu’une faute (fault) dans le système d’infodivertissement ne puisse pas atteindre les freins. Notez que sécurité intrinsèque et haute disponibilité peuvent entrer en conflit : un système à sécurité intrinsèque s’arrête souvent, ce qui est sûr mais indisponible.

L’observabilité, une qualité émergente

L’observabilité est le degré auquel vous pouvez comprendre l’état interne d’un système depuis l’extérieur, à partir des données qu’il émet, suffisamment bien pour répondre à des questions que vous n’aviez pas anticipées lors de sa construction. Elle ne figure pas dans l’ISO/IEC 25010, même si l’analysabilité et l’imputabilité s’en approchent. Dans les systèmes distribués, elle est devenue une qualité à part entière, car le délai de rétablissement, et donc la disponibilité, dépend de la rapidité avec laquelle on parvient à trouver ce qui ne va pas. Sur le plan architectural, elle exige des journaux structurés, des métriques et des traces distribuées avec des identifiants de corrélation qui suivent une requête d’un service à l’autre, prévus dès le départ. Un scénario pourrait être : Pour toute étape de paiement en échec, un ingénieur d’astreinte peut identifier le service défaillant et le chemin de la requête en moins de 5 minutes. Voir l’observabilité au chapitre 9.

Qualités juridiques et réglementaires

Les lois et règlements créent des qualités faciles à négliger jusqu’à un audit. La résidence des données exige que certaines données soient stockées ou traitées dans un pays ou une région donnés ; elle peut découler de règles sectorielles, de contrats du secteur public ou d’exigences de clients. Le RGPD lui-même n’exige pas que les données restent dans l’UE, mais les transferts hors de l’UE nécessitent un fondement juridique et des garanties, ce qui, en pratique, détermine où s’exécutent les services et les sauvegardes. L’auditabilité consiste à pouvoir montrer, après coup, qui a fait quoi et quand : des journaux révélant toute altération, conservés pendant une durée définie, avec des horloges synchronisées. Les règles de conservation et de suppression exigent que les données soient conservées pendant une durée minimale (registres financiers) et supprimées après une durée maximale ou sur demande (données personnelles), ce qui est difficile dans des systèmes comportant de nombreuses copies, caches et sauvegardes. L’explicabilité et le contrôle humain sont exigés pour certaines décisions automatisées, comme l’explique le chapitre sur le règlement européen sur l’IA.

Traitez-les comme des contraintes assorties de critères d’acceptation : « les données clients des clients allemands du secteur public sont stockées et traitées uniquement dans des régions de l’UE, sauvegardes et journaux compris » est testable, et exclut d’emblée certains services managés. Les exigences de protection de la vie privée sont traitées dans la protection de la vie privée dès la conception et le RGPD.