Qualité et qualité
Lorsque je travaillais dans l’industrie (la vraie, celle qui fabrique quelque chose de matériel), on m’a dit que la qualité importante (du point de vu de l’industriel), c’est celle que le client perçoit lorsqu’il utilise ce que l’on fabrique.
Beaucoup de démarche qualité insistent sur les process plus que sur les produits. Pourquoi ?
Parce que le but de ces démarche n’est pas fondamentalement d’améliorer la qualité, mais plutôt de rendre la qualité reproductible pour un coût maîtrisé.
La méthode pour y parvenir est d’intervenir en amont car le coût de correction d’une erreur augmente dans le temps. Ceci est en tout cas vrai dans l’industrie traditionnelle car il faut souvent démonter l’objet pour remplacer une pièce défaillante. Ne parlons pas du coût d’un remplacement après livraison.
Les préceptes du cycle en V pour le développement logiciel disent la même chose. Il vaut mieux corriger une erreur de design avant le début de développement qu’une fois que le développement est terminé, ou pire qu’après la mise en exploitation ou la commercialisation du logiciel. Ce point est en parti remis en cause par les méthodes agiles comme eXtreme Programming, mais c’est un autre sujet.
Pourtant la quasi-totalité des éditeurs fournissent des logiciels buggés (et souvent en connaissance de cause). Et tout le monde semble trouver cela normal (ne parlons pas des contrats de maintenance). C’est même devenu pour certain un principe qu’il n’existe pas de logiciel sans bug. Personnellement je considère cette assertion comme une belle arnaque.
Ce qui fait une grande différence entre un logiciel et un bien matériel, c’est qu’il existe des organismes de contrôle vérifiant la qualité (et notamment la robustesse) des produits et délivrant des normes dont l’obtention est obligatoire pour avoir le droit de commercialiser un type de produit.
En temps que parent, lorsque j’achète un siège-bébé, je veux qu’il possède le label NF. Que l’entreprise qui le produit soit certifié ISO 9000 ne m’intéresse pas particulièrement.
Évidement lorsque j’achète un logiciel je n’ai pas cette possibilité de me referer à un label de qualité. Il existe bien des certification comme la compatibilité Windows, CheckMark pour les antivirus, etc, mais leur obtention n’est pas obligatoire pour avoir le droit de commercialiser. Heureusement d’ailleurs, car sinon que deviendrait les logiciels Open-Source ? Faute de budget, beaucoup de projet n’aurait pas de certification. La qualité est souvent l’argument des éditeurs pour défendre leur produits propriétaires, mais malheureusement la qualité n’est pas toujours à la hauteur du discours.
Si je suis DSI et que j’achète une prestation de développement à une SSII, alors dans ce cas le fait qu’elle soit CMM5 est vraiment un plus, car j’ai plus de change d’obtenir un développement de qualité. A la condition que j’ai correctement exprimé mes besoins dans le cahier des charges, parce qu’un bon développement sur un besoin mal exprimé donne souvent un logiciel qui finira au cimetière des projets informatiques (aussi célébre et rempli que le cimetière des éléphants).
Donc ne confondons pas :
- démarche qualité, nécessaire pour maîtriser les coûts d’obtention d’un produit de qualité
- produit de qualité, possédant les caractéristiques que recherche l’utilisateur comme la robustesse, la facilité d’emploi…
- produit répondant à un besoin, et que donc l’utilisateur utilisera.
Trop souvent on mélange ces concepts. La stratégie de la plupart des éditeurs est d’abord de livrer un produit répondant à un besoin, ensuite d’améliorer sa qualité dans les versions successive. Pour pouvoir le faire en maîtrisant les coûts, une démarche qualité s’avère nécessaire.
En conclusion pour paraphraser un sketch célébre, il y a qualité et qualité…
octobre 21st, 2007 à 15:22
Je vous propose un autre regard sur la qualité et les processus sur le site Brèves de couloir (humour, langue et management) : http://www.brevesdecouloir.fr/breves_couloir-bestof_processus.htm