La qualité, c’est relatif

Bien qu’abordée par les méthodes, la qualité d‘un produit est relative et peu facilement mesurable. Elle est un sujet qui se retrouve donc délaissé dans la plupart des projets, à tort. Car si le numérique nous permet de faire beaucoup de choses, il est loin d’être gage de qualité… surtout si ses développeurs ne prennent pas la peine ni le temps de se mettre d’accord sur ce qu’elle signifie, sur ce qu’elle doit être et sur comment l’atteindre. 

Dans ce nouvel article de la série du Vieux Singe, je m’attaque à la notion de qualité dans le domaine du numérique – un domaine que je connais particulièrement bien, ayant été responsable de la qualité des systèmes d’information pour un grand groupe français pendant quelques années.  

Ce que j’ai remarqué, c’est que la qualité ne devient souvent qu’un sujet lorsqu’une équipe n’est pas d’accord sur certains aspects du produit livré, lorsqu’il y a divergence sur la façon dont chacun imaginait le visuel ou les fonctionnalités d’un nouvel outil, ou sur les avantages attendus de la mise en place d’un nouveau canal digital, par exemple. 

Paradoxalement, quand il n’y pas de désaccord, on ne parle pas de qualité, bien qu’ignorer cette question fondamentale à tout projet réussi puisse apporter un bon gros lot de prises de têtes, de pertes de temps, de révisions budgétaires et tout simplement d’échecs plus ou moins cuisants.  

La non-qualité ne devrait pas être une option  

Les méthodes de projet nous ont toujours encouragé à intégrer la notion de qualité à nos bonnes pratiques et réfléchir à nos critères de qualification et de tests en période de pré-réalisation. En somme, il faut bien commencer à imaginer la qualité quelque part si l’on veut réussir son projet…  

Or en pratique, la qualité à tout bonnement tendance à sauter sur 99 % des sujets technologiques abordés par les PME et par beaucoup de grandes structures (hors domaines tels que la construction d’avions, de fusées et autres machines de la sorte, bien entendu). Coupe budgétaire ou non, c’est le premier sujet à être écarté du projet, à être remis à plus tard. 

Pourtant, la qualité doit bel et bien commencer dès le début d’un sujet et doit être intégré dans la réflexion sur la faisabilité de celui-ci. 

Je pense d’ailleurs au Président de l’ISTQB (International Software Testing Qualifications Board) Olivier Denoo, qui s’indigne souvent par rapport au fait que les entreprises ne se donnent jamais les moyens d’appliquer les bonnes pratiques nécessaires à l’obtention d’un niveau de qualité acceptable pour chacun de leurs projets. Comme lui, je ne crois pas que les niveaux attendus pour de simples projets technos soient trop élevés, mais pour les atteindre, il faudrait déjà acquérir la capacité d’écoute nécessaire pour comprendre l’objectif émis par le bénéficiaire du projet, parce que la qualité d’un projet, c’est en fait l’expression même des divergences émises par les collaborateurs d’un même projet. C’est aussi le résultat concret de ce qui n’a pas fonctionné en début de projet, c’est ce sur quoi on ne s’est pas mis d’accord.  

Si l’on fait un raisonnement par l’absurde, parler de qualité dans de nombreuses entreprises revient essentiellement à parler de non-qualité, qui elle-même naît de la divergence entre ceux qui réalisent et ceux qui font des expressions de besoins. Quand ces deux parties arrivent à parler de qualité, c’est quand elles ne se sont pas alignées en début de projet. 

Jamais deux sans trois  

Il existe principalement 2 niveaux de qualité dans les méthodes de projet. Réellement, il y en a 3 : 

• La Qualité Produite : Celle-ci concerne le nombre de bugs signalés, la fréquence des défauts, etc. Une anomalie est repérée tel le plantage d’un logiciel ou l’apparition d’un écran bleu est facile à mesurer, sans doute plus anticipable. La Qualité Produite est aussi connue sous le nom de Qualité Coût/Délai – plus on contraint le coût et les délais, plus la qualité en pâtit.  
• La Qualité Perçue : Celle-ci concerne ce qu’en pense l’utilisateur. Elle ne se mesure que par l’erreur, toujours a posteriori.  
• Et la qualité dont on ne parle jamais, la Qualité Attendue : Celle-ci est tirée directement de l’expression des objectifs et du contexte du bénéficiaire, non de ses besoins. Elle concerne, comme son nom l’indique, les attendus en termes de qualité du produit fini. 

La Qualité Attendue, ce n’est pas forcément 0 bug et aucune anomalie mais plutôt imaginer l’impact que la qualité aura sur le produit fini. Cette Qualité Attendue est très rarement partagée entre ceux qui demandent et ceux qui produisent probablement car ce n’est pas un exercice simple : une version qualitative attendue est de fait abstraite est devient donc relative… Mais loin d’être inutile !  

Pour éviter ces moments de non-qualité, il faut en partie avoir travaillé sur l’intelligence organisationnelle et sur l’empathie au sein de l’entreprise. Rappelons-nous : la non-qualité est, simplement dit, le fruit d’une mauvaise communication. Il faut avoir une posture comportementale de savoir-être et une bonne maturité organisationnelle pour tacler tout ce qui relève de l’expression, de l’échange, de la nuance, du domaine de l’abstrait et du relatif. Si l’on n’est pas dans une relation d’empathie et de confiance réciproque avec son client ou son consommateur, il est compliqué d’agir en fonction de ce qu’il attend. Plutôt logique, non ?  

Si un client non informaticien qui ne maîtrise aucun langage ne dit qu’il ne veut pas de bugs, ça ne veut rien dire. Moi, informaticien, je peux lui garantir qu’il n’aura aucun bug mais pour 100 fois le budget donné. A l’inverse, je peux rester dans les lignes du budget avec une bonne communication sur les attendus du bénéficiaire en amont du projet et lui livrer une solution sur-mesure, avec des erreurs sans doute productives et surtout, une solution de haute qualité puisqu’elle répondra à ses attentes.  

La verticalité, c’est dépassé 

Remettre la qualité à plus tard, c’est vouer un projet à butter sur de nombreuses difficultés et parfois même à l’échec. Quand j’étais DSI, j’avais mis en place des indicateurs de qualité produite assez simples, comme le nombre d’anomalies signalées par mois et par application. L’idée était de se fixer un objectif d’erreurs à ne pas dépasser chaque mois et de mesurer le temps moyen que le service mettait à résoudre l’anomalie ou peaufiner l’application. Pour la qualité perçue, j’avais mis en place des enquêtes de satisfaction pour demander aux utilisateurs d’évaluer soit l’application, soit le service de maintenance.  

En 3^e phase, j’ai également voulu encourager les équipes informatiques à noter la qualité perçue des métiers qui nous faisaient parvenir leurs demandes informatiques. Ça a malheureusement été mal perçu par l’entreprise, bien que ma proposition ne soit pas si illogique : comment faire appliquer un produit de qualité si ce qui est proposé n’est pas de qualité ? Pour la direction de ce groupe, le département informatique était « au service de », il ‘agissait d’une relation client-fournisseur, pas une relation de collaboration horizontale et ouverte.  

A l’époque, ça avait du sens. La relation de l’industriel avec l’informatique était au début très verticale, peu transverse et ça marchait… ça marchait parce que l’informatique produisait de la valeur facilement mesurable. Aujourd’hui, l’informatique apporte bien plus de nuances, les possibilités sont inimaginables, les fonctionnalités décuplées et toujours plus poussées, les relations avec clients et consommateurs sont différentes, les écosystèmes aussi, ont changé. L’informatique se « consomme » d’ailleurs aussi plus facilement dans les organisations possédant des solutions cloud sur étagères.  

Par ailleurs, les développeurs d’aujourd’hui ont assez de ressources – les langages et autres règles sont tellement encadrées (on ne dirait pas, mais l’informatique est extrêmement contrainte), qu’ils font au final très peu d’erreurs de développement. Les erreurs commises sont ultimement presque toujours liées à la conception et ce, parce qu’il n’y a pas eu de discussion sur la qualité attendue du produit fini. Résultat : 70 % des lignes de codes ne sont pas utilisées, on manque de temps, on fait des coupes budgétaires et on finit avec un produit sans qualité globale. Souvent, il peut y avoir quelques erreurs de qualité produite dont les dégâts sont moindres, mais surtout de gros couacs dans la qualité attendue pouvant mener à la révision entière du projet… Je pense donc que la qualité absolue dans un projet ne doit pas être recherchée, ou envisagée. Ce qui doit être recherché, c’est plutôt la qualité attendue : celle qui s’exprime par des mots simples, partageables. 

Le numérique : source d’opportunités, mais pas gage de qualité   

Le dernier point que j’aimerais aborder est celui-ci : j’entends souvent « qu’avec le numérique, on peut tout faire ». Alors oui, c’est vrai, on peut faire beaucoup si l’on sait l’utiliser, or le numérique est encore loin de savoir résoudre tous nos problèmes… Pour qu’un outil numérique fonctionne, il faut que l’équipe qui se trouve derrière se fasse confiance. 

Ici, le numérique fait référence à tout ce qui touche à la partie technique d’un projet, d’un  produit. Il fait référence au code, aux appareils, aux technicités réseaux. Le Digital, lui, est  l’interface entre le numérique est l’humain.   

En clair, il faut faire preuve de maturité technologique , soit comprendre qu’il y ait encore bien trop de paramètres à gérer au-delà même du numérique et arrêter de tout relayer sur celui-ci. Parmi ces paramètres, on y trouve des sujets comme l’éthique et la diversité, la confiance interne et avec les consommateurs, la relation client et, vous l’aurez deviné, la qualité. Des sujets qui ne sont pas imaginé par le numérique mais par l’échange d’humain à humain !  

Ainsi, parler de qualité attendue est applicable à nos livrables, études, audits, simples tests ou projet d’IA ultra-complexes. Elle n’est à négliger dans aucun projet, quel qu’en soit sa taille : quand la qualité attendue est abordée, les efforts réservés pour gérer désaccords et problèmes sont moindre et l’on peut alors se concentrer davantage sur la valeur de ce que l’on produit. 

Il est tout bonnement temps d’accepter que la qualité soit effectivement relative (à chaque projet, au marché, au contexte, aux objectifs…), que tout n’est pas mesurable à la perfection, mais qu’il faut bien commencer par quelque part et redébusquer la valeur des échanges et de l’écoute. Pour obtenir un produit de qualité et réussir un projet, il faut mettre toutes les parties impliquées d’accord sur ce que ce projet devrait donner. Plus facile à dire qu’à faire, mais plus facile à faire que de devoir rattraper de grosses erreurs de chantier… 

Yanniss Leloir

Photo d’illustration: © Johnathan Hoxmark