Moi je fais le dev et toi tu fais la qualité

Cette phrase est une caricature, mais elle ne vise pas si loin de la réalité. Elle révèle une conception de la qualité qui, nous allons le voir, est dysfonctionnelle.

Tout part d'une bonne volonté, pourtant. Nous avons des problèmes de qualité, il faut donc créer un "Département Qualité". C'est un peu de la pensée magique, mais cela semble tout de même aller dans le bon sens.

Dans les faits, on observe généralement deux grands scénarios : le département "mouche du coche", qui embête tout le monde et ne sert à rien, et le "filet de sécurité", qui rattrape les erreurs des autres.

C'est une cellule de qualiticiens pleins de bonnes intentions mais non opérationnels, qui demandent aux développeurs de remplir tout un tas de matrices d'évaluation des risques et de mesurer des KPIs ésotériques, tout en leur expliquant la façon dont ils devraient travailler : pyramide de tests, Test-driven development et autres best practices. Pour les développeurs, déjà sous pression, les interventions du Département Qualité ne sont pas du meilleur aloi…

Rapidement, les KPIs deviennent des KPIs pastèques, verts dehors mais rouges dedans. Ce terme désigne autrement la loi de Goodhart  : les développeurs finissent par dire ce que les qualiticiens attendent afin que ces derniers les laissent enfin travailler. Au final, personne n'est content et la qualité n'est pas au rendez-vous.

L'alternative à cette situation n'est pas vraiment plus désirable : le Département Qualité est cette fois-ci totalement opérationnel, puisqu'il fait les tests que les développeurs ne font pas. Des tests manuels, le plus souvent, ou bien des tests automatisés de haut niveau (notamment end-to-end), parce que l'application n'est pas architecturée pour être testée à plus bas niveau, en particulier au niveau unitaire.

Ce cas est problématique, parce que les développeurs n'ont aucune incitation naturelle à faire moins de bugs et de régressions, leurs erreurs de développement étant corrigées par le Département Qualité. Le lecteur avisé aura reconnu ce que les économistes appellent une externalité négative, que l'on corrige en "réinternalisant l'externalité". Une taxe sur les bugs ? Quand-même pas…

Que certaines personnes se focalisent plus spécifiquement sur la qualité n'est pas un problème tant que vous êtes dans une approche "Quality as a Practice" (cela fait d'ailleurs partie des attributions des managers, techniques ou non-techniques). La qualité, on ne devrait pas en parler en tant que telle : tout devrait être qualité. On ne peut pas distinguer le développement et la qualité, on ne peut pas distinguer le faire et le faire mieux.

Vous, qui organisez l'entreprise, ayez à cœur de faciliter l'amélioration continue, d'offrir la formation nécessaire, d'aider les équipes à poser un cadre. Pensez Lean plutôt que Département Qualité : la qualité ne devrait pas être un rôle, elle devrait être une exigence intégrée au quotidien du développement.

Et à la fin, tout est affaire de culture d'entreprise et de recrutement. Vous voulez des développeurs que vous n'aurez pas à convaincre qu'un code non testé, c'est un code qui ne vaut rien. Vous voulez des développeurs qui aient envie d'améliorer leur façon de travailler. Peut-être leur manquera-t-il des éléments de méthode, et vous serez là pour les aider, mais a minima l'envie de bien faire, la curiosité intellectuelle seront là et vous pourrez travailler.