Les limites du QE Score : entre indicateur puissant et piège à métriques

Le QE Score, présenté comme un indicateur de maturité en qualité logicielle, ambitionne de standardiser et d’objectiver l’évaluation des pratiques de Quality Engineering. Intégré à l’écosystème des outils DevOps (CI/CD, SonarQube, Jira…), il se veut un catalyseur de bonnes pratiques. Mais comme tout indicateur, il comporte ses forces… et ses faiblesses.

Voici un tour d’horizon des limites et contradictions potentielles du QE Score, afin d’en faire un usage éclairé, stratégique et surtout humain.

starterkit pour mise en place d'un quality engineering score

📏 1. L’illusion d’objectivité

Le QE Score se présente comme un indicateur “objectif” de la qualité logicielle, car il s’appuie sur des données mesurables issues d’outils standards comme SonarQube, Jira ou les pipelines d’intégration continue. Cette promesse d’objectivité est séduisante surtout dans un environnement où la qualité est souvent perçue comme quelque chose de flou ou de subjectif.

Mais cette objectivité est en réalité relative. Les données utilisées sont elles-mêmes le fruit de décisions humaines : comment les règles de qualité sont configurées dans SonarQube, comment les bugs sont catégorisés dans Jira, comment les tests sont structurés dans les pipelines… Deux équipes utilisant les mêmes outils peuvent obtenir des scores très différents, non pas parce que l’une est “meilleure”, mais simplement parce qu’elles n’ont pas la même maturité d’usage ou les mêmes priorités.

Le QE Score donne une impression de neutralité et de rigueur, mais il repose sur un socle interprétatif, contextuel, et parfois arbitraire. Il doit donc être lu avec recul, complété par des éléments qualitatifs, et jamais utilisé comme une vérité absolue.

🛠️ 2. Un biais “outil-centré”

Le QE Score repose fortement sur l’analyse de données issues d’outils techniques : SonarQube pour la qualité de code, Jira pour le suivi des anomalies, les pipelines CI/CD pour l’automatisation des tests et des déploiements. Cette approche présente un avantage évident de standardisation et de traçabilité, mais elle induit un biais fondamental : ne sont mesurées que les dimensions visibles, instrumentables et automatisables de la qualité.

Quality Engineering - QE score - Un biais “outil-centré” ne sont mesurées que les dimensions visibles, instrumentables et automatisables de la qualité

Ce biais peut créer un effet tunnel, où l’on considère comme prioritaire ce que l’on peut mesurer, au détriment d’éléments tout aussi critiques mais plus difficiles à quantifier — comme l’expérience utilisateur, la clarté fonctionnelle, la maintenabilité sur le long terme, la documentation, ou encore la qualité des échanges entre équipes.

En clair : ce que le QE Score ne mesure pas… n’existe pas (au risque de l’ignorer dans la stratégie qualité).

Le risque : orienter les efforts vers ce qui est mesurable, non vers ce qui est réellement important pour la réussite du produit.

Le QE Score reste un outil puissant pour objectiver certains aspects techniques, mais il doit être accompagné d’un regard critique et multidimensionnel, notamment en intégrant des feedbacks humains et des analyses qualitatives.

⚖️ 3. Comparer l’incomparable ?

Le QE Score se veut un outil de benchmarking entre projets, produits ou équipes. Mais peut-on vraiment comparer une scale-up en microservices, une application bancaire legacy et un produit en R&D exploratoire avec la même grille de lecture ?

Deux problèmes majeurs apparaissent :

• Les contextes diffèrent radicalement.

Certaines équipes ont des moyens d’automatisation poussés, d’autres non. Certaines travaillent sur des API, d’autres sur des systèmes sans interface exposée. Certaines peuvent facilement instrumenter leur code, d’autres évoluent dans des environnements très contraints (legacy, sécurité, hardware, etc.).

• Tous les critères ne s’appliquent pas

Par exemple, un produit qui ne possède pas d’API publique ne pourra logiquement pas être évalué sur les tests d’API. De la même manière, si le code source n’est pas auditable par un outil comme SonarQube que ce soit en raison de sa nature compilée ou d’une technologie non supportée alors toute une dimension du score, liée à la qualité du code, sera absente ou sous-évaluée.

L’uniformisation du score peut produire une illusion d’équité, alors qu’elle masque une diversité réelle de contextes, de contraintes et d’objectifs.

🧼 4. Score-washing et loi de Goodhart

“Lorsque qu’une mesure devient un objectif, elle cesse d’être une bonne mesure.” - Loi de Goodhart

Quality Engineering - QE Score - Score-washing et loi de Goodhart

À force d’être scruté, affiché et valorisé, le QE Score peut finir par devenir une fin en soi, plutôt qu’un outil d’amélioration continue. C’est le phénomène bien connu du score-washing : on optimise le score… sans nécessairement améliorer la qualité réelle du produit.

Exemple concret : une équipe, sous pression pour faire monter son QE Score, décide d’ajouter massivement des tests automatisés pour faire grimper son taux de couverture. Mais ces tests sont superficiels, ne couvrent pas les cas critiques, et sont rarement maintenus. Le score augmente, mais la valeur réelle de ces tests est faible. L’illusion de qualité est là, mais le risque logiciel reste entier.

Autre cas fréquent : des bugs sont fermés rapidement dans Jira pour éviter qu’ils ne fassent baisser le score parfois sans réelle résolution, ou en les classant comme “non reproductibles”.

Le danger ici est double : d’un côté, on prend des décisions sur la base d’un indicateur faussé, et de l’autre, on installe une culture de la performance “cosmétique” qui peut nuire à la qualité profonde du produit.

On parle alors de score-washing : masquer des problèmes profonds derrière des indicateurs flatteurs.

👤 5. L’utilisateur final : le grand absent

Le QE Score évalue la qualité logicielle à travers des indicateurs techniques : couverture de tests, bugs ouverts, qualité du code, stabilité des pipelines… Mais il ne prend pas en compte un élément fondamental : le ressenti de l’utilisateur final. Aucun critère du score ne mesure la satisfaction client, l’adoption réelle du produit ou encore le taux de churn.

Quality Engineering - QE Score - L’utilisateur final : le grand absent

En d’autres termes, un produit peut afficher un score technique élevé — avec des tests automatisés impeccables, un code bien structuré et aucun bug connu — et pourtant échouer une fois en production. Pourquoi ? Parce qu’il peut être compliqué à utiliser, peu intuitif, ou simplement hors de propos par rapport aux attentes réelles des utilisateurs.

Prenons un exemple concret : une application de gestion de notes de frais. Du point de vue qualité technique, elle est exemplaire : tests automatisés complets, zéro bug critique, performance irréprochable. Pourtant, les utilisateurs finaux la trouvent laborieuse : les étapes sont trop nombreuses, l’interface est peu claire, et l’expérience mobile est frustrante. Résultat : l’adoption stagne, les équipes terrain préfèrent continuer à remplir des fichiers Excel, et le produit est peu utilisé malgré son “QE Score” élevé.

C’est là toute la limite d’un indicateur purement technique : il ne dit rien sur l’utilité perçue, la fluidité d’usage ou la satisfaction générée. Or, qu’est-ce qu’un produit de qualité, si ce n’est un produit utile, fiable… et apprécié ?

🤖 6. L’automatisation ne dit pas tout

Le QE Score repose en grande partie sur l’automatisation : tests, pipelines, analyse statique… Cela permet de produire des indicateurs réguliers et fiables, mais cela ne couvre qu’une partie techniquement visible de la qualité.

Des aspects cruciaux échappent à cette logique : la lisibilité du code, la maintenabilité, la documentation, la pertinence réelle des tests ou encore l’évolutivité de l’architecture. Tous ces éléments sont difficiles à capturer automatiquement, mais ont un impact direct sur la qualité perçue et la productivité à long terme.

Exemple : une application peut avoir un excellent QE Score, mais être un cauchemar à maintenir, faute de clarté ou de structure compréhensible. Inversement, un système plus simple, mais bien conçu et documenté, offrira une bien meilleure expérience… sans que cela se voie dans le score.

L’automatisation est un atout, mais elle ne remplace pas l’analyse humaine. Le QE Score ne peut donc pas être l’unique reflet de la qualité d’un produit.

🔐 7. Des enjeux de confidentialité et d’intégration

Agréger des données de multiples outils implique un accès profond à l’environnement de développement. Cela soulève des questions de sécurité, de gouvernance de la donnée, et de complexité d’intégration dans des écosystèmes hétérogènes.

🧭 Conclusion : QE Score, un outil précieux mais pas infaillible

Le QE Score est une boussole, pas une carte.

Il peut orienter les efforts, déclencher des discussions, identifier des dérives. Mais il ne saurait, à lui seul, résumer la qualité d’un produit ou d’un processus.

À nous, praticiens de la qualité, de garder le sens critique, le contexte et surtout l’humain au cœur de nos démarches d’ingénierie. Car si l’on prend conscience de ses limites techniques, humaines, structurelles, le QE Score devient un véritable levier d’amélioration continue. Utilisé avec recul et intelligence, il peut structurer des conversations, aligner les équipes sur des objectifs qualité, et valoriser les progrès réels.

C’est dans cet équilibre entre mesure et discernement que réside sa vraie puissance.