3. La qualité : une propriété construite
Pourquoi ce chapitre existe
« Qualité » est un mot consensuel qui cesse souvent d'être utile dès qu'une décision doit être prise. Pour l'une, c'est l'absence de défaut ; pour l'autre, la lisibilité du code ; pour une troisième, la rapidité de livraison. Chacune décrit une dimension réelle, mais aucune ne suffit seule. Sans définition partagée, l'équipe optimise ce qui est facile à voir et découvre trop tard le reste.
Ce chapitre propose une définition opérationnelle : un logiciel de qualité continue de produire les effets attendus pour ses utilisateurs, de manière suffisamment sûre et prévisible, tout en restant possible à faire évoluer à un coût acceptable.
Les idées essentielles
- La qualité est multidimensionnelle : comportement, fiabilité, sécurité, exploitabilité, performance et capacité d'évolution s'influencent mutuellement.
- Elle se construit dans la conception et la livraison ; l'inspection finale ne peut pas compenser une intention mal comprise.
- Une assertion de test, une revue ou une métrique est une preuve partielle. La bonne question est toujours : quelle affirmation cette preuve soutient-elle ?
- La qualité est contextualisée par l'usage et le coût de l'erreur ; elle n'est pas synonyme de perfection abstraite.
Une qualité qui se constate dans le temps
Un logiciel peut être correct sur l'environnement de test et décevoir en production. Il peut donner le bon résultat tout en exposant une donnée sensible, répondre rapidement mais devenir impossible à modifier, ou être parfaitement conçu pour un usage que personne n'a réellement. Ces situations montrent que la qualité ne peut pas être réduite au passage d'une suite de tests.
Les dimensions suivantes doivent être considérées ensemble :
| Dimension | Question révélatrice | Exemple de preuve |
|---|---|---|
| Exactitude fonctionnelle | Le résultat respecte-t-il les règles importantes ? | Cas métier, invariants, test de contrat |
| Fiabilité | Continue-t-il à rendre le service sous des conditions réalistes ? | SLO, scénarios de panne, récupération |
| Sécurité et confidentialité | Protège-t-il les accès et les données ? | Revue de menace, contrôles d'autorisation, journalisation |
| Exploitabilité | Peut-on comprendre et restaurer le service lorsqu'il échoue ? | Tableaux de bord, traces, runbook, exercice d'incident |
| Performance | Reste-t-il utilisable au volume pertinent ? | Mesure de latence et de saturation sous charge représentative |
| Évolutivité | Le prochain changement local reste-t-il local ? | Frontières lisibles, tests ciblés, faible couplage |
Ces dimensions peuvent entrer en tension. Chiffrer davantage de données peut augmenter une latence. Une mise en cache peut rendre le système plus disponible mais moins immédiatement cohérent. La qualité naît de la capacité à rendre ces tensions explicites et à choisir selon le contexte.
De l'assurance qualité à la construction de qualité
L'assurance qualité est parfois comprise comme une étape chargée d'attraper les défauts produits par les autres étapes. Ce modèle est rassurant parce qu'il donne un lieu où les problèmes seraient arrêtés. Il est aussi structurellement fragile : plus une erreur est détectée tard, plus son diagnostic, son correctif et ses effets collatéraux coûtent cher.
Construire la qualité consiste à poser les bonnes questions tôt et à conserver des preuves au fil du travail. Pendant la découverte, on clarifie les comportements et les risques. Pendant la conception, on protège les invariants et les modes de défaillance. Pendant l'implémentation, on produit un changement lisible et vérifiable. Pendant le déploiement, on limite l'exposition. En production, on observe les conséquences réelles.
La QA a un rôle important dans ce modèle, mais il est distribué : elle contribue à explorer les scénarios, rendre les risques visibles et évaluer les preuves. Elle n'est pas seule responsable de la qualité, pas plus qu'un développeur n'est seul responsable d'un système qu'il ne peut ni observer ni opérer.
La force d'une preuve dépend de son périmètre
Un test unitaire peut établir avec précision qu'une règle calcule correctement un montant pour des entrées données. Il ne montre pas que cette règle est appelée avec les bonnes données, que le schéma reçu est compatible ou que le déploiement utilise la bonne configuration. Un test de bout en bout peut couvrir la chaîne visible, mais être lent, fragile et peu explicite sur la cause d'un échec.
La stratégie de qualité consiste à combiner des preuves complémentaires. Chercher un test qui prouve tout produit souvent une suite lente et opaque. Empiler des tests de même nature laisse des angles morts similaires.
Une couverture élevée indique quels chemins le test a exécutés ; elle ne dit pas si les bonnes attentes ont été vérifiées. Une couverture faible peut révéler un angle mort réel. Dans les deux cas, l'analyse doit repartir des comportements qui comptent et des conséquences de leur défaillance.
Arbitrer les dimensions de qualité sans les opposer
Les dimensions de qualité ne sont pas une liste où l'on coche tout au même niveau. Elles sont souvent en tension et leur priorité dépend de la promesse faite aux utilisateurs. Une administration interne peut accepter une cohérence différée de quelques minutes pour rester disponible. Un calcul de facture ne peut pas accepter la même approximation. Un export analytique peut tolérer une indisponibilité ponctuelle ; un contrôle d'accès ne peut pas échouer ouvertement pour améliorer la disponibilité.
Le travail d'ingénierie consiste à rendre ces arbitrages explicites avant qu'ils ne soient imposés par les défauts par défaut du système.
| Tension | Question de décision | Compromis explicite possible |
|---|---|---|
| Disponibilité / cohérence | L'utilisateur peut-il agir sur une donnée légèrement ancienne ? | Afficher une fraîcheur connue et différer la mise à jour |
| Performance / sécurité | Quel contrôle supplémentaire protège un risque réel ? | Accepter une latence mesurée sur l'opération sensible |
| Simplicité / évolutivité | Quelle variation est réellement probable ? | Dupliquer temporairement plutôt que généraliser trop tôt |
| Rapidité de livraison / vérification | Quel dommage rend une preuve supplémentaire nécessaire ? | Déployer une tranche limitée avec observation plutôt que bloquer tout le projet |
Un compromis de qualité devient dangereux lorsqu'il reste caché. Par exemple, une équipe peut introduire un cache pour tenir une cible de latence, sans documenter que le solde affiché peut dater de trente secondes. Le système paraît performant jusqu'à ce qu'un utilisateur prenne une décision sur cette information. Une phrase dans le contrat, un indicateur de fraîcheur et un comportement de correction transforment une approximation implicite en choix maîtrisé.
Une qualité soutenable se construit dans les détails de travail
Les grandes propriétés — fiabilité, sécurité, performance — dépendent de décisions apparemment ordinaires : un timeout choisi par défaut, un champ ajouté à un événement, une valeur vide traitée comme « non », un flag non retiré, une exception de données sans propriétaire. Une équipe ne peut pas convoquer une revue de qualité stratégique pour chacun de ces détails. Elle a besoin de standards, composants, tests et modèles de décision qui rendent la bonne option plus simple à prendre que l'option risquée.
La qualité durable est donc autant une propriété du système de travail que du logiciel. Lorsque les outils rendent visible une incompatibilité, qu'un composant encapsule une interaction accessible ou qu'un pipeline vérifie la provenance d'un artefact, l'organisation déplace une partie de la vigilance individuelle vers une capacité partagée.
Anti-patterns
Mesurer la qualité par la seule absence de tickets
Les défauts non déclarés ne sont pas nécessairement absents. Ils peuvent être invisibles, contournés par les utilisateurs ou reportés au support. L'absence de signal est rassurante seulement lorsque le système est suffisamment observable et que les utilisateurs peuvent remonter un problème.
Confondre qualité du code et qualité du produit
Un code élégant peut implémenter une règle métier erronée. À l'inverse, une correction urgente peut être peu esthétique tout en protégeant les utilisateurs. La lisibilité, le design et les tests sont des moyens puissants de soutenir la qualité, jamais une dispense de vérifier l'effet produit.
Reporter les exigences non fonctionnelles
« Nous traiterons la performance, la sécurité ou l'observabilité plus tard » échoue quand ces propriétés dépendent de choix déjà figés : modèle de données, frontières d'autorisation, protocole, sémantique de reprise. Elles doivent être abordées dès que le risque apparaît, sans nécessairement être surconçues.
Bonnes pratiques
Formuler des attributs de qualité observables
« Le système doit être rapide » est trop vague pour guider une conception. « Le parcours de confirmation répond à 95 % sous 300 ms pour 500 requêtes par seconde, hors dépendance partenaire dégradée » est discutable, mesurable et conduit à des choix explicites. Tous les objectifs n'ont pas besoin d'une précision numérique immédiate ; ils doivent au moins décrire l'usage et le dommage évité.
Associer chaque risque à une ou plusieurs preuves
Pour une modification de règles de remise, une table de cas peut prouver la logique ; un test de contrat peut protéger le consommateur d'un événement ; une métrique peut révéler l'effet sur les commandes ; un déploiement par cohortes peut limiter le rayon d'action. Cette association force l'équipe à constater ce que chaque mécanisme sait — et ne sait pas — démontrer.
Checklist — Définir la qualité d'un changement
- Quel comportement doit rester vrai pour les utilisateurs et les systèmes voisins ?
- Quelles erreurs seraient graves, silencieuses ou difficiles à réparer ?
- Quelles propriétés non fonctionnelles sont affectées dès maintenant ?
- Quelle preuve soutient chaque attente importante, et quels sont ses angles morts ?
- Comment détecterons-nous un écart après la livraison ?
- Quel compromis de qualité avons-nous consciemment accepté, et pourquoi ?
À retenir
La qualité est la capacité durable d'un système à mériter la confiance qui lui est accordée. Elle ne résulte pas d'une porte de sortie appelée « recette ». Elle se construit par des choix explicites, des preuves adaptées et une observation continue du comportement réel.