Les COQ : qu’est-ce que c’est ?

Les COQ sont les Coûts d’Obtention de la Qualité. Autrement dit, en inversant la maxime, « l’argent, c’est du temps » : les COQ sont simplement le temps nécessaire pour obtenir la qualité souhaitée.

Par exemple, si dans votre checklist, vous avez un point « produire une version imprimable des contenus via CSS », le coût d’obtention de la qualité est le temps nécessaire pour produire et tester cette version imprimable via CSS.

Quels types de coûts de Coûts d’Obtention de la Qualité

Les coûts de production directe de la qualité

Ce sont les plus évidents : obtenir un point de qualité peut prendre du temps, c’est donc un Coût d’Obtention de la Qualité. Parmi les coûts de production, il faut compter :

• le temps de formation ;
• le temps de vérification, d’évaluation, de suivi ;
• le temps de correction ;
• l’outillage pour les analyses ;
• le temps de spécification ;
• le temps dédié à la traçabilité (enregistrement des échantillons, preuves, etc.) ;
• dans le cas de l’informatique, le temps dédié à obtenir l’information qualité dans l’immensité des informations disponibles.

Les coûts de prévention

Bien évidemment, afin d’éviter des pertes douloureuses dues à des CNQ, il est important de prendre les devants. Formations, contrôles, progression, suivi, automatisation, etc. sont des coûts de prévention. Néanmoins, il serait plus juste de parler d’investissement : c’est au final de l’argent que l’on investit pour améliorer la qualité, ou diminuer la non-qualité le cas échéant.

Typiquement les développeurs sont très forts pour automatiser des processus pour gagner du temps ou « mettre en standard » telle possibilité. En fait, ils ne font que… diminuer les COQ. :)

Cet investissement est aussi une sécurité : on limite tout simplement les risques liés aux CNQ. Ce n’est pas un hasard si les qualiticiens parlent d’assurance qualité. La notion d’assurance est évidemment directement liée à la notion de gestion et de prévention des risques.

Calcul des COQ et des CNQ

Il serait facile de croire que ces coûts (COQ et CNQ) sont difficiles à estimer, et pourtant il existe une méthode très simple pour les estimer : comptez simplement le temps perdu occasionné par un CNQ, et multipliez par le taux horaire par intervenant. Si par exemple, la résolution d’un CNQ a mobilisé votre développeur pendant 4 heures : multipliez son taux horaire par 4.

Pour mettre en perspective ce coût, vous pouvez comparer avec le COQ. Si la tâche pour obtenir la qualité souhaitée durait une heure, dites-vous que vous avez simplement perdu une somme d’argent équivalente à 3 fois le taux horaire de votre développeur. Cet exemple se veut simple : nous calculons là la perte directe bien sûr, il est facile d’imaginer que des pertes indirectes sont possibles, autant en interne… qu’en externe.

Bien sûr, ce n’est qu’un exemple. Si l’on reprend l’exemple de l’article « la dette technique en exemple », on peut estimer le COQ à :

• vérifier les fonctions de chaque maillon (insertion dans les bases, interclassement de la base, import des données depuis le CRM, etc.) ;
• faire des tests.

Pris en amont, ce coût peut être très léger, une demi-journée de travail suffirait à vérifier cela pour un bon développeur, allez, mettons une journée pour avoir un compte rond ! Comparée aux CNQ engendrés décrits dans l’article, n’ayons pas peur des mots : c’est au bas mot un facteur 10 à 20. Rien qu’en coût développeur, vous imaginez le prix de 10 à 20 jours ?

Comment et quand agir ?

Un premier signal doit vous mettre la puce à l’oreille : si les CNQ sont supérieurs aux COQ, il est grandement temps d’agir. Vous constaterez que les remarques parfois rageuses de vos développeurs et autre techniciens prennent tout leur sens :

• « si j’avais eu le temps de faire ça proprement, je n’y serai pas revenu ! »
• « ces retours incessants sont insupportables ! »
• « mais pourquoi ne gère-t-on pas ce point en standard !!! »

Une blague vue sur le net résume bien ce problème : deux décideurs discutent, le premier dit « et si l’on forme nos employés et qu’ils s’en vont ? » le second lui répond « imaginons qu’on ne les forme pas et qu’ils restent ? ».

Si les CNQ vous grignotent complètement vos marges, vous êtes entrés dans un cercle très vicieux : pour reprendre l’analogie de la dette financière, les intérêts sont trop élevés et la capacité de remboursement est dépassée. Le surendettement a une conséquence connue : le danger de la banqueroute. À bon entendeur.

Une fausse bonne idée est souvent d’estimer les coûts de développement de manière très large pour justement inclure ces CNQ (le précédent article indiquait une étude chiffrant les CNQ à 50%). Imaginez le gain de compétitivité engendré si ces estimations étaient revues à la baisse si ces CNQ étaient ne serait-ce que divisés par deux ? Prenez un devis, et imaginez-le réduit de 25%, sans perte de qualité.
Je suppose que vous avez déjà eu un client vous disant que le devis proposé était trop élevé ? Et si dans ce devis, vous aviez des CNQ faciles à éradiquer ?
Ou mieux, vos devis au même prix mais votre marge augmentée de 25%.

Non-Quality cost killing et amélioration continue

Dans le domaine du Web, nous vivons dans le luxe et l’opulence. Pour peu que notre infrastructure technique soit bien choisie et que nos outils soient évolutifs, nous pouvons nous permettre le bonheur de l’amélioration continue. Ce qui est possible pour nous ne l’est pas dans l’industrie quand on construit un pont, un avion ou une voiture. Il est beaucoup plus facile en théorie de corriger un système informatique qu’un avion ou un pont. Dans le domaine du Web, il est possible et même souvent conseillé de construire quelque chose de manière progressive, sans risque excessif, et en faisant participer les utilisateurs finaux (en anglais, le fameux "release early, release often", que l’on peut traduire par « publier tôt, publier souvent »). Il est sans doute possible d’appliquer cette approche agile à la réduction des coûts de non-qualité.

Dans le domaine du management de la qualité, nous parlons de traitement des anomalies, des dérogations, des réclamations, des non-conformités, enfin bref, de tout ce qui représente un écart avec ce qui est attendu. Dans les systèmes qualité comme ISO9000, ce type de gestion est très formalisé, nous parlons d’actions correctives et préventives.

Pour ceci, nous devrions procéder de la façon suivante :

• nous doter d’outils, de bibliothèques, d’environnements et de standards qui nous permettront au maximum de corriger nos erreurs et de réduire nos coûts de non-qualité ;
• une fois ces éléments choisis et installés, tenter de détecter les erreurs le plus tôt possible dans le process ;
• à chaque fois qu’une erreur est constatée, veiller à ce qu’elle soit corrigée immédiatement ET veiller à ce qu’elle ne se reproduise plus.

Pour mettre en perspective

Il est capital de comprendre que les mécanismes impliquant les COQ et les CNQ sont liés. Pour reprendre la métaphore mécanique : c’est un tout homogène. Sur une voiture, certes un pneu n’est pas relié directement au réservoir d’essence, toutefois, s’il est sous-gonflé, vous allez augmenter votre consommation de carburant.

CNQ et COQ sont des vases communicants : en vous attaquant à la réduction des COQ, vous réduirez de facto vos CNQ. Réduisez vos CNQ, vous aurez du temps à consacrer pour vos COQ. L’idée est soit :

• de libérer du temps pour vous permettre de réaliser vos objectifs de qualité ;
• et/ou de réduire vos COQ pour les rendre réalisables.

Bien entendu, il faut que les COQ ne soient pas démesurément élevés par rapport au temps disponible, sinon le risque de sur-qualité va de suite pointer le bout de son nez.

En tout cas, soyez-en sûrs : nous complèterons les pistes évoquées dans ces deux articles pour trouver une ou des méthodologie(s) concrètes pour évaluer tous ces aspects. En attendant, n’hésitez pas à partager vos expériences sur ces sujets dans les commentaires.

Références, compléments

• Les coûts d’obtention de la qualité
• Le coût de la non-qualité sur le Web