Normes, cadres de mesure et dette technique¶
Ce chapitre rassemble les cadres qui définissent ce qu'est la qualité d'un logiciel et la manière de mesurer la performance d'une organisation qui le produit : les normes ISO, Six Sigma, Accelerate et ses successeurs, les pratiques de Google, et la recherche sur la dette technique. Ils sont moins empiriques que les chapitres précédents, mais ce sont eux qu'on invoque quand on écrit une politique qualité.
Les normes ISO¶
ISO/IEC 25010 : ce qu'est la qualité d'un produit logiciel¶
La norme ISO/IEC 25010 définit le modèle de qualité du produit logiciel. Elle a remplacé en 2011 la norme ISO/IEC 9126 (1991, révisée en 2001), et a été révisée en novembre 2023 (catalogue ISO). La version 2023 compte neuf caractéristiques :
| Caractéristique | Exemples de sous-caractéristiques |
|---|---|
| Adéquation fonctionnelle | Complétude, exactitude, pertinence |
| Efficacité de performance | Temps de réponse, capacité |
| Compatibilité | Coexistence, interopérabilité |
| Capacité d'interaction (ex-utilisabilité) | Apprentissage, protection contre l'erreur, inclusivité |
| Fiabilité | Absence de fautes, tolérance aux fautes, disponibilité |
| Sécurité | Confidentialité, intégrité, résistance |
| Maintenabilité | Modularité, analysabilité, modifiabilité |
| Flexibilité (ex-portabilité) | Adaptabilité, évolutivité, installabilité |
| Sûreté (nouvelle en 2023) | Contrainte opérationnelle, identification des risques, sécurité intrinsèque |
(Liste des sous-caractéristiques selon arc42, qui cite le texte officiel ; le texte de la norme n'a pas pu être consulté. La place de la testabilité — sous maintenabilité ou sous flexibilité — diffère selon les sources.) Le modèle de qualité en usage a été déplacé en 2023 dans une norme séparée, ISO/IEC 25019. Les mesures associées sont définies par ISO/IEC 25023 (2016), qui ne fixe ni niveaux ni seuils.
Usage pour un orchestrateur
La norme sert de liste de contrôle des caractéristiques : un plan de contrôle qui ne surveille que l'adéquation fonctionnelle (« les tests passent ») laisse sept ou huit caractéristiques sans aucun contrôle. Le plafond de 56 % de Veracode sur la sécurité alors que la syntaxe approche 100 % (Ce que disent les données) en est l'illustration.
ISO/IEC/IEEE 90003 : ISO 9001 appliqué au logiciel¶
La norme 90003 (2018) donne des lignes directrices pour appliquer ISO 9001 (système de management de la qualité) au logiciel. Elle n'ajoute aucune exigence à ISO 9001 et n'est pas un référentiel de certification. Elle concerne l'organisation (processus, responsabilités, revues), pas la qualité mesurée du code.
Six Sigma et le logiciel¶
Six Sigma, né chez Motorola au milieu des années 1980, vise 3,4 défauts par million d'opportunités et structure l'amélioration en cinq étapes (Définir, Mesurer, Analyser, Améliorer, Contrôler). Son application au logiciel est documentée surtout par des études de cas et de petites enquêtes (Mahanti et Antony, 2005-2009) ; ce rapport n'a trouvé aucune revue systématique de Six Sigma en génie logiciel. Une critique ancienne (Binder, IEEE Software 1997) soutenait qu'un modèle conçu pour la fabrication ne convient pas au logiciel — la même objection que celle opposée au SPC du SEI (Trente ans de SPC).
Accelerate, SPACE et DevEx : mesurer la performance des équipes¶
Accelerate (2018)¶
Le livre de Forsgren, Humble et Kim, tiré des enquêtes State of DevOps, défend que vitesse et stabilité ne s'opposent pas : les équipes les plus performantes sont bonnes sur toutes les métriques à la fois. DORA le maintient aujourd'hui avec cinq métriques (dora.dev).
Les critiques portent sur la méthode : enquêtes déclaratives, échantillons auto-sélectionnés, données brutes non publiées, sponsors commerciaux (Puppet, puis Google Cloud). Elles viennent surtout de blogs et de sondages concurrents (Junade Ali, avec l'institut Survation) ; ce rapport n'a pas trouvé de critique méthodologique publiée dans une revue à comité de lecture.
SPACE (2021)¶
Le cadre SPACE (Forsgren, Storey, Maddila, Zimmermann, Houck, Butler, ACM Queue et CACM 2021) répond au mésusage des métriques de productivité. Ses cinq dimensions : Satisfaction et bien-être, Performance, Activité, Communication et collaboration, Efficacité et fluidité (flow). Ses recommandations :
- la productivité « ne peut pas être mesurée par une seule métrique » ;
- mesurer au moins trois dimensions ;
- choisir des métriques en tension les unes avec les autres, « à dessein » ;
- « aucune métrique ne peut être un indicateur parfait ».
DevEx (2023)¶
Le cadre DevEx (Noda, Storey, Forsgren, Greiler, ACM Queue 2023) retient trois dimensions de l'expérience développeur : les boucles de retour (attendre un build, un test, une approbation de revue), la charge cognitive et l'état de flow. Il insiste pour mesurer à la fois les perceptions et les flux réels.
Le principe des métriques en tension
La recommandation de SPACE est l'équivalent organisationnel de la carte de contrôle à plusieurs caractéristiques : surveiller une seule mesure (le débit, le nombre de PR) invite à la dégrader en améliorant les autres. L'étude Cursor (Productivité) en est la démonstration : vitesse en hausse, avertissements et complexité en hausse. Seules des métriques en tension — vitesse et dette, débit et reprise — rendent ce compromis visible.
Les pratiques de Google¶
Le livre Software Engineering at Google (Winters, Manshreck, Wright, 2020, en ligne) documente plusieurs règles de qualité :
- revue de code (chapitre 9) : chaque modification exige une vérification de correction par un autre ingénieur, l'approbation d'un propriétaire du code, et celle d'une personne certifiée en « lisibilité » du langage ; la plupart des revues ont un seul relecteur ; une petite modification fait « environ 200 lignes » ; la vérification de la correction n'est pas le principal bénéfice de la revue — le partage de connaissances l'est ;
- tests (chapitre 11) : répartition visée d'environ 80 % de tests unitaires, 15 % d'intégration, 5 % de bout en bout ; taux de tests instables d'environ 0,15 % ; la « règle de Beyoncé » : if you liked it, then you shoulda put a test on it ;
- mesure (chapitre 7) : le cadre « objectifs, signaux, métriques », et une règle de tri — ne mesurer un processus que si une décision concrète dépend du résultat.
La dernière règle est le meilleur filtre pour un plan de contrôle d'orchestrateur : une carte qui ne peut déclencher aucune action est du décor.
La dette technique¶
Ward Cunningham a forgé la métaphore en 1992 (texte) : livrer du code imparfait, c'est s'endetter, et une dette non remboursée accumule des intérêts. Trois travaux la mesurent :
- Besker, Martini et Bosch (2018-2019) : sur 43 développeurs suivis, la dette technique fait perdre en moyenne 23 % du temps de travail, surtout en tests supplémentaires (temps déclaré, petit échantillon) ;
- Ernst et al. (ESEC/FSE 2015, 1 831 participants) : les choix d'architecture, souvent pris tôt, sont une source clé de dette, et les outils se concentrent à tort sur l'analyse du code ;
- SQALE (Letouzey, 2010) convertit les violations de règles de code en coût de correction ; c'est la méthode derrière l'indicateur de dette de SonarQube — et donc derrière les mesures de l'étude Cursor. Elle ne voit pas la dette d'architecture.
À retenir
- ISO 25010 fournit la liste des caractéristiques de qualité (neuf depuis 2023) ; un contrôle centré sur les tests n'en couvre qu'une.
- Six Sigma et le SPC se heurtent aux mêmes objections dans le logiciel ; les preuves sont des études de cas.
- SPACE : au moins trois dimensions, des métriques en tension.
- Google : ne mesurer que ce qui peut déclencher une décision.
- La dette technique coûte environ un quart du temps selon une étude déclarative ; les outils qui la mesurent voient le code, pas l'architecture.