Aussi impliqués et passionnés que nous puissions l’être dans nos métiers d’informaticiens, il ne faut pas se voiler la face, le nerf de la guerre en matière de projets reste tout de même les finances.
Pour que la réalisation d’un produit soit considérée comme un réel succès par toutes les entités d’une organisation, il est primordial qu’il reste rentable.
L’assurance qualité, chargée de mettre en place une organisation de confiance, et le contrôle qualité, chargé de contrôler et d’évaluer la production, apportent de réelles plus valus aux projets en tant que levier essentiel de la satisfaction client. Cependant, ces activités peuvent devenir très rapidement des pôles de dépenses relativement conséquents.
Il y a donc un équilibre à trouver entre l’investissement dans les activités liées à la qualité et leur rentabilité, c’est-à-dire avoir une bonne qualité de produit sans faire ce qu’on pourrait nommer de la surqualité. Cependant, quand notre rôle se situe justement au centre de ces activités, cette phrase, “Attention, ne faisons pas de surqualité !“, sonne étrangement.
Mais à quel moment se fait la bascule entre qualité et surqualité ? Et que signifie réellement surqualité ?
Comment définir la qualité
Pour comprendre la surqualité, il faut d’abord revenir sur la définition de la qualité.
Le terme “qualité“ est utilisé quotidiennement par tout un chacun dès qu’il s’agit d’éprouver un produit ou un service. Dans son utilisation courante, il lui est très aisément associé des qualificatifs comme “bonne“, “mauvaise“, “excellente“… Cependant, si nous souhaitons définir précisément ce terme, nous réalisons rapidement que cela est une épreuve en soi voire un sujet de philosophie.
“Il n’y a pas de qualité, il n’y a que des preuves de qualité“
Pour éviter de trop nous perdre, nous allons rester dans le monde de l’industrie et nous attarder sur la vision de la qualité telle qu’elle est abordée dans ce domaine. Dès le début de l’ère industrielle, les grandes entreprises et organisations ont compris l’enjeu de la qualité. Au fils des années, l’intérêt général est tel que des organismes nationaux et internationaux sont spécifiquement créés afin de produire et faire vivre des référentiels qualités : les normes. Ces organismes de normalisation sont donc devenus les références incontournables en matière de qualité (ISO, AFNOR, CEN, …).
Impossible alors de définir sérieusement la qualité sans le sens industriel du terme sans faire référence à un organisme comme l’AFNOR (AFNOR – ISO/FDIS 9000:2015).
La célèbre norme ISO 9001 (Management de la qualité) définie cette dernière de la façon suivante :
La qualité est l’aptitude d’un ensemble de caractéristiques intrinsèques d’un objet à satisfaire des exigences.
“Intrinsèque“ par opposition à “attribué“, signifie présent dans l’objet.
Le terme “qualité“ peut être utilisé avec des qualificatifs tels que médiocre, bon ou excellent.
La qualité n’est pas qu’une caractéristique à proprement parler (intrinsèquement “bonne”, “mauvaise”, …) comme perçu dans le langage courant, mais elle est l’évaluation des caractéristiques d’un produit en fonction d’un référentiel. Elle est donc un fait que l’on observe, un phénomène mesurable.
Dans “30 histoires hors normes” édité par l’AFNOR, nous pouvons trouver à propos de la norme ISO/9001 cette citation qui résume à elle seule cette approche de la qualité : “De fait, c’est un peu comme en amour : il n’y a pas de qualité, il n’y a que des preuves de qualité.”
La qualité logicielle
Le produit logiciel, bien que porté par un matériel physique, est un produit intellectuel, ce qui le distingue d’un produit industriel classique. Les grandes lignes de la qualité industrielle se retrouvent dans le domaine du logiciel. Cependant, les caractéristiques immatérielles de ce type de produit vont obliger à avoir une approche différente de celle d’un produit de l’industrie classique.
Contrairement à un produit solide, la réponse à toutes les exigences écrites et conscientisées n’est pas suffisante pour qu’un produit soit considéré comme de “bonne qualité”. Il faut aussi qu’il réponde à des attentes d’utilisation implicites qui ne sont pas spécifiées clairement. Les référentiels sur lesquels la qualité logicielle s’appuie peuvent donc être concrets et d’autres totalement abstraits.
De plus, aujourd’hui, un logiciel ou un SI est un agrégat de produits, outils, bibliothèques… qui transforment nos SI en systèmes complexes. La maîtrise parfaite et l’évaluation précise de leurs niveaux de qualité devient alors presque impossible. Chaque dimension (financière, technique, fonctionnelle, …) apporte son lot d’indicateurs et son lot de défaillances potentielles plus ou moins latentes ou prévisibles. Certaines corrections ou amélioration peuvent faire monter les niveaux de qualité de la même façon pour deux indicateurs différents, mais aussi, à l’inverse, les faire progresser de façon opposée (exemple : une correction fonctionnelle qui impacte négativement la performance).
La sélection des indicateurs qualités est donc un enjeu dont peut dépendre le succès d’un projet au même titre que la sélection des seuils qui déterminent les niveaux dit de sous-qualité, qualité ou surqualité.
La stratégie de contrôle des niveaux de qualité tout au long du projet est aussi primordial au succès général. Ce sont eux qui permettront des changements de pilotage appropriés.
La surqualité ou le mieux serait l’ennemi du bien
La surqualité fait partie des notions essentielles des méthodes de management et de gestion “sans gaspillage” comme le Lean Management. C’est une notion générique introduite dans le monde de l’industrie pour trouver des pistes d’économie. Elle consiste à concevoir des produits dont la qualité va au-delà des attentes du client en entraînant, dans un même temps, des coûts inutiles et inattendus.
La surqualité n’est dans le fond, pas une problématique de qualité. La norme ISO 9000 qui est la référence en matière de management de la qualité n’en donne d’ailleurs aucune définition. Elle est avant tout un problème de rentabilité du produit final, donc un problème essentiellement financier. Pour pouvoir parler de surqualité, il est alors nécessaire d’avoir des exigences financières au même titre que des exigences fonctionnelles ou de performance.
En quoi consiste l’idée de la surqualité en matière de logiciel ?
Est-ce faire trop de vérifications ou trop d’améliorations ?
L’augmentation de qualité du logiciel n’est pas liée directement aux contrôles, elle en est la résultante. Cette augmentation dépend des améliorations qui sont apportées aux produits suite aux défaillances détectées lors des contrôles. Il suffit donc de ne pas apporter les corrections qui n’ont pas d’intérêt pour la satisfaction client pour ne pas passer le seuil de surqualité.
Cependant, le contrôle qualité a un coût. Une vérification se fait dans l’optique de trouver un défaut. Faire trop de tests, c’est donc alors chercher des défauts dont la découverte n’aurait pas forcément d’intérêt pour le projet.
Confusion ?
Le contexte dans lequel se retrouve le plus couramment cette expression est lors de la mise en place de la stratégie qualité et de l’évaluation des budgets qui lui seront alloués. Quand la qualité tombe dans les activités les moins prioritaires, dans le cas ou des contraintes juridiques ou de sécurité ne contraignent pas le projet, les responsables et managers n’en voient qu’un centre de coût dont la plus-value n’est pas forcement bien identifiée. La rentabilité d’une démarche qualité dans son ensemble étant difficile à démontrer, la crainte d’une surqualité émerge alors très facilement.
Il n’y a pas réellement de confusion entre qualité et surqualité, mais une difficulté à utiliser de façon pertinente l’une ou l’autre des notions dans le domaine du logiciel.
La surqualité est un problème financier à ramener systématiquement au centre d’un problème de qualité logiciel, déjà complexe et difficile à maîtriser. Elle est le dépassement de la “qualité attendue”, quel que soit l’indicateur sur lequel cette qualité porte, au détriment de l’indicateur de rentabilité financière. Cette notion impose donc l’ajout systématique de la vision financière lorsque est évoqué un risque de surqualité. Son l’utilisation devrait être accompagné de toute une série de question comme :
- Sur quels critères porte cette surqualité ?
- Peut-on toujours mettre une ligne budgétaire face à tous les indicateurs ?
- Et peut-on parler de surqualité sur l’ensemble du projet lorsque certains niveaux de qualité peuvent évoluer dans des sens opposés ?
- A-t ’on pris le temps de mesurer la rentabilité réelle d’un processus qualité ?
- Et comment mesurer la qualité du management de la qualité ?
Conclusion
Si la qualité est l’adéquation à une conformité, la surqualité peut alors prendre une forme de non-conformité en lien direct avec une exigence de rentabilité.
Certes, un équilibre est à trouver entre les dépenses en prévention et détection des défaillances et le coût supposé des défaillances elles-mêmes, mais il faut rester vigilant lorsque notre produit est un agrégat de besoins plus ou moins exprimés et exprimables, représentés et représentables par une multitude d’indicateurs.
N’oublions pas aussi que la multi-dimensionnalité des projets logiciels engendre une multiplicité des points de vue sur la qualité et ses indicateurs (performance, utilisabilité, attraction commerciale, qualité des données, …). La qualité n’est pas perçue de la même façon par les développeurs, l’utilisateur, le marketing, la gestion de projet, les financiers… Ce qui paraît être perçu comme de la qualité pour les uns peut être au final de la surqualité ou sous-qualité pour les autres.
D’un point de vue personnel
Méfions nous de cette notion de surqualité : à trop l’utiliser pour résoudre les problèmes d’économie, il y a un risque de tuer la qualité elle-même, ou encore de tomber dans une spirale dans laquelle ce qui est considéré à un instant T comme de la qualité devient à T+1 de la surqualité et ce qui était de la sous-qualité devient de la qualité.
L’amélioration continue de la qualité est, à sa façon, une sorte de R&D intrinsèque. En bloquant ce processus, c’est aussi prendre le risque de se priver d’innovations et de nouvelles pistes de ressource économique.
Pour finir, n’oublions pas la crise du logiciel qui sévit depuis plusieurs dizaines d’années. Les quelques études faites à propos de la qualité des SI démontrent qu’une grande majorité des projets sont largement en dessous des attentes en matière de qualité et qu’aucune application a été médiatisé comme étant en surqualité
Donc pas de panique !
Il y a de la marge avant que la surqualité soit un réel problème
Références :
L’assurance qualité logicielle 1, Concepts de base de Alain April et Claude Laporte.
ISO 9000:2015 Systèmes de management de la qualité — Principes essentiels et vocabulaire de l’AFNOR.