24. Prouver les propriétés non fonctionnelles
Pourquoi ce chapitre existe
Un système peut produire le bon résultat dans un test nominal et échouer pour les raisons qui comptent le plus : une latence qui fait abandonner un paiement, une saturation qui rend la reprise impossible, une autorisation contournée, une donnée sensible exposée, un backup impossible à restaurer. Ces propriétés sont souvent appelées « non fonctionnelles », comme si elles étaient secondaires. Pour l'utilisateur affecté, elles font partie intégrante du comportement.
Les idées essentielles
- Performance, fiabilité, sécurité, confidentialité et exploitabilité sont des comportements observables sous certaines conditions.
- Elles doivent être formulées avec un contexte : charge, durée, acteur, dommage, seuil et mode de défaillance.
- Les preuves combinent tests, analyse, instrumentation et exercices ; aucune seule ne suffit.
- Le meilleur moment pour les aborder est avant que le choix de données, de contrat ou de déploiement ne les rende coûteuses à changer.
Rendre l'attribut testable
« Le service doit être rapide » devient une conversation utile lorsqu'il décrit un parcours, une population et un seuil : « la confirmation reste sous 400 ms au 95e percentile à 200 requêtes/seconde, avec une dépendance de catalogue lente ». Cette formulation conduit à des décisions : timeout, cache, dégradation, alerte et test de charge.
| Propriété | Question de preuve | Exemples de mécanismes |
|---|---|---|
| Performance | Quelle latence et saturation sont tolérables ? | Profilage, charge représentative, SLO |
| Résilience | Que se passe-t-il si une dépendance échoue ? | Tests de timeout, jeu de panne, canari |
| Sécurité | Qui peut faire quoi, avec quelles traces ? | Revue de menace, tests d'autorisation, analyse de dépendances |
| Confidentialité | Quelles données sont collectées, visibles et retenues ? | Contrôle de flux, tests d'accès, audit de rétention |
| Restaurabilité | Peut-on retrouver un état correct dans le délai attendu ? | Restauration exercée, réconciliation, runbook |
Tester des scénarios de défaillance plausibles
Un test de charge qui ne touche qu'un endpoint vide ou une simulation de panne qui ne teste pas la reprise donnent peu d'information. Les scénarios doivent refléter les dépendances, données et décisions critiques du produit. Il n'est pas nécessaire de reproduire toute la production : il faut représenter les mécanismes susceptibles de provoquer le dommage étudié.
Collecter CPU, latence ou erreurs ne suffit pas. Définir ce qui déclenche une action, qui l'exécute et quelle dégradation est acceptable. Sans cela, la métrique n'aide pas l'équipe à maîtriser le risque au moment où elle en a besoin.
Anti-patterns
Tester la performance après avoir figé le modèle
Attendre la fin pour mesurer peut révéler qu'un accès ou un contrat fondamental ne tient pas la charge. Une mesure précoce et modeste suffit souvent à invalider une hypothèse avant que tout le système ne dépende d'elle.
Confondre scan automatique et sécurité démontrée
L'analyse de dépendances, le lint et les scans sont des barrières précieuses. Ils ne comprennent ni le modèle d'autorisation, ni les abus métier, ni la sensibilité d'un flux. Les risques significatifs demandent aussi une revue de menace et des tests d'accès ciblés.
Concevoir la reprise comme une documentation sans exercice
Un runbook de restauration peut contenir des accès expirés, des volumes irréalistes ou des étapes impossibles sous pression. Un exercice proportionné transforme cette promesse en information réelle sur le temps et la capacité de récupération.
Bonnes pratiques
Construire une preuve progressive
Commencer par une hypothèse et un test local ou environnemental, puis compléter par un déploiement limité et des métriques de production. Ce chemin évite de choisir entre « tout simuler » et « découvrir directement en production ».
Lier les propriétés aux scénarios métier
Une indisponibilité n'a pas la même gravité sur une page de consultation et pendant une confirmation de paiement. Relier l'attribut au parcours et au dommage permet de choisir des objectifs réalistes et de concentrer l'investissement là où il protège vraiment les utilisateurs.
Checklist — Une propriété importante est-elle crédible ?
- Quel parcours, acteur, volume et dommage définissent cette propriété ?
- Quel seuil ou comportement de dégradation est accepté ?
- Quels modes de défaillance plausibles ont été testés ou analysés ?
- Les contrôles de sécurité et de confidentialité couvrent-ils le modèle réel d'accès ?
- Quels signaux de production confirmeront ou infirmeront l'hypothèse ?
- La restauration, compensation ou dégradation a-t-elle été exercée à une échelle utile ?
À retenir
Les propriétés non fonctionnelles ne sont pas un supplément de qualité. Elles sont la manière dont le comportement tient lorsque le système rencontre charge, erreurs, acteurs malveillants et temps. Les rendre observables et testables protège les usages qui comptent le plus.