Module
Module 2 sur 6Leçon 2 sur 2~16 min

Des attentes vagues aux exigences mesurables

Tant que « rapide » ou « fiable » restent des adjectifs, personne ne peut comparer deux architectures ni juger un projet réussi. Cette leçon montre comment convertir ces attentes en exigences non fonctionnelles vérifiables, choisir une mesure qui ne masque pas les utilisateurs lésés et garder seulement les scénarios qui pèsent sur la décision.

Suivre cette leçon : première formation offerteVoir le programme complet

Objectif de la leçon

À la fin de cette leçon, vous serez capable de nommer les attributs de qualité qui comptent pour votre produit, de réécrire une attente vague (« rapide », « fiable », « évolutif ») en scénario mesurable en six parties, et de choisir une mesure honnête, comme un percentile plutôt qu'une moyenne.

Thèmes abordés

  • exigences non fonctionnelles
  • attributs de qualité
  • scénario d'attribut de qualité
  • percentile de latence
  • ISO 25010

Dans quel module

Lire une architecture

Comment lire un schéma d'architecture et dire précisément ce que le système doit garantir ?

Leçons du module

  1. Lire un schéma d'architecture avec le modèle C4
  2. Des attentes vagues aux exigences mesurables (cette leçon)

Ce que vous apprendrez dans la formation

Cette leçon fait partie de la formation Lire et challenger une architecture technique

  • Lire un schéma d'architecture (niveaux contexte et conteneurs du modèle C4) et y repérer composants, flux, frontières et zones floues.
  • Transformer des attentes vagues (« rapide », « fiable », « évolutif ») en exigences non fonctionnelles mesurables, sous forme de scénarios d'attributs de qualité.
  • Comparer monolithe, monolithe modulaire et microservices, puis appels synchrones et traitements asynchrones, selon l'équipe, la charge et les conséquences pour l'utilisateur.
  • Évaluer les choix de données (source de vérité, transactions, réplicas, cohérence), de montée en charge et de cache, et repérer le goulot d'un parcours.
  • Évaluer les dépendances à des services tiers (disponibilité composée, mode dégradé, dépendance au fournisseur) et une décision construire ou acheter.
  • Formuler un arbitrage d'architecture, le tracer dans un ADR et traiter la dette technique comme une décision produit.
  • Conduire une revue d'architecture de son produit ou d'une proposition, avec dix questions, un registre des risques et des arbitrages explicites.

Formations liées