Ce que nous prenons en compte
Les exigences non fonctionnelles définissent la qualité du système au-delà des fonctionnalités. Les décisions architecturales impactent directement ces attributs.
| Attribut | Description | Considérations architecturales |
|---|---|---|
| Performance | Temps de réponse, débit, latence | Cache, CDN, traitement asynchrone, optimisation base de données |
| Évolutivité | Gérer une charge croissante | Conception sans état, mise à l'échelle horizontale, équilibrage de charge |
| Disponibilité | Uptime, tolérance aux pannes | Redondance, health checks, auto-healing, multi-région |
| Fiabilité | Comportement cohérent et prévisible | Politiques de réessai, circuit breakers, dégradation gracieuse |
| Sécurité | Protection contre les menaces | Authentification, autorisation, chiffrement, journalisation d'audit |
| Maintenabilité | Facilité de modification | Couplage faible, documentation, code propre, tests automatisés |
| Observabilité | Comprendre le comportement du système | Journalisation, métriques, traçage distribué, alertes |
La disponibilité en chiffres
Chaque neuf supplémentaire a un coût : nous convenons d'abord de l'objectif avec le métier, puis nous concevons la redondance adaptée.
Ce que signifie vraiment un objectif
Objectif de disponibilité
Indisponibilité autorisée
Par an3j 15h
Par mois7h 18min
Par semaine1h 40min
Disponibilité composite d'une charge de travail
App Service 99.95%Azure SQL 99.99%Service Bus 99.9%
Disponibilité attendue
99.84%
≈ 14h d'indisponibilité par an
Exemple illustratif