Premier jour de formation en Lean Management ; le formateur propose un tour de table pour connaître l’origine et le niveau de connaissance en Lean des personnes présentes. Chacune se présente et arrive mon tour. J’égraine mes prénom, nom, fonction, entreprise, mon niveau de connaissance en Lean et ce que j’attends de cette formation.

Réponse du formateur à mes propos : « Vous, les informaticiens, vous testez trop ! ». La personne suivante se présente.

« Okay ! Euh… ben, c’est pour s’assurer que le produit fonctionne bien ; il peut y avoir des enjeux humains derrière les logiciels… », pensais-je en écoutant les autres personnes.

Les pieds dans le béton

Je passais la première journée à ruminer et à retourner dans tous les sens la remarque du formateur… « Vous, les informaticiens, vous testez trop ! » J’avais l’impression d’avoir essuyé une remarque blessante, voire désobligeante d’une personne qui d’après son expérience ne semblait pas connaître l’informatique. Une provocation pour laquelle je préssentais que mes arguments ne seraient pas bons. Mais que voulait-il dire ?

Au fil des heures de la formation, les sujets s’enchaînent les uns après les autres : faire bon du premier coup, créer de la valeur, détecter les défauts au plus tôt, faire la chasse aux gaspillages, résoudre les problèmes… C’est bien ce qu’on essaie de faire tous les jours ! Certes, nous ne formalisons pas toujours la résolution de nos problèmes. « Certes, nous ne sommes pas toujours en train de mettre la dernière touche, le cachet final nécessaire à un haut niveau de qualité, mais quand même ! », maugréais-je.

Et la terre s’ouvrit sous mes pieds

Et puis vint le déclic quand je compris que le collaborateur devait traiter le défaut dès qu’il le détectait pour ne pas le transmettre à l’équipe suivante. Dit autrement, le collaborateur doit arrêter – en tirant l’Andon – la chaîne de création de valeur pour corriger le défaut, sinon il se propage et risque de se retrouver entre les mains du client.

Une faille sourde et profonde venait de s’ouvrir dans mes vingt années d’expérience en développement logiciel et ses principes établis par le cycle en V ou encore par le CMMI-DEV et ses processus comme VER (vérification : recette interne) et VAL (validation par le client). C’était comme un tremblement de terre dans mon modèle mental que je pratiquais au quotidien. C’était comme si tout ce que j’avais appris en matière de processus pour assurer la qualité des logiciels s’effondrait.

Apprenons à voir le réel

Courage ! Relevons nos manches et concentrons-nous sur une recette interne qui, pour les non-initiés, permet de tester de bout en bout (ou presque) le logiciel réalisé avant de le fournir au client (qui le testera aussi avant de le mettre en production et d’ouvrir le service à ses utilisateurs). Honnêtement, que remarquons-nous ? Qu’il y a de nombreux défauts détectés ? Ces défauts entraînent de facto des corrections (ce qu’on appelle aussi des retouches), car il s’agit de problème de qualité ; un des 7 gaspillages (Muda) du Lean Management générant des délais et des coûts supplémentaires.

La double question à laquelle nous devons répondre est la suivante : pourquoi a-t-on besoin de cette équipe de test et pourquoi la phase de test est-elle aussi longue et coûteuse ? Allez, on y est presque… parce que le client ne sait pas ce qu’il veut, que son cahier des charges n’est pas assez précis, qu’il ne valide pas en temps et en heure les spécifications ?

Oubliez les excuses pour ne pas voir le problème et changez de cadre, de vue, de position… La réponse ? Parce que le système ne permet pas aux équipes de développement de faire bon du premier coup et qu’elles ne peuvent pas détecter les défauts qu’elles engendrent. Aïe, c’est dit ! Ça pique un peu, n’est-ce pas ? C’est normal, c’est la « dure » réalité.

En Lean Management, la qualité (le pilier Jidoka du TPS) est un élément fondamental pour protéger le client interne (l’équipe de test est le client de l’équipe de développement) et externe (le client final).

Si l’on s’intéresse d’un peu plus près aux défauts trouvés par les équipes de test (en utilisant un Pareto visuel, par exemple), on s’aperçoit que pour un très grand nombre, ils auraient pu être détectés pendant la phase de développement. Pendant cinq ans, j’ai pu mesurer et analyser les défauts constatés lors des recettes internes. La même cause dans des proportions quasi identiques se répétait sans cesse : « peu ou pas de tests unitaires » pendant la phase de développement. En cinq ans, les raisons (ou plutôt de mauvaises excuses) ont toujours été les mêmes : « pas le temps » ; « gérer les JUnit et les dbUnit c’est trop coûteux » ; « les stagiaires n’ont pas été formés » ; « on est déjà en retard » ; « c’est de la sûr-qualité » ; « on fera les corrections une fois l’application en production, sur le budget exploitation qu’on a survendu » ; « on a vendu une provision de X % pour corriger les anomalies » ; « le client paie pour une 2 CV, on ne va pas lui faire une Ferrari ! »… Je mets de côté les « la qualité, ce n’est pas la priorité de la première version » ;
« mon chef m’a dit de livrer aujourd’hui, même si je n’ai pas fini de tester »…

La crainte

Mais, cela veut-il dire que l’équipe de test va être supprimée ? Que va devenir cette équipe formée aux tests logiciels (certification ISTQB) ? En remontant la détection des défauts au début de la chaîne de création de valeur (les développeurs, voire avant pendant la phase de définition des besoins), l’équipe de test va être libérée d’une charge de travail qui n’était pas la sienne : détecter les défauts dus à un manque de tests unitaires. Elle va donc pouvoir se concentrer sur sa valeur ajoutée : les tests métiers qui ne peuvent pas toujours être réalisés pendant les développements.

En poussant la résolution de problème plus loin, on pourrait aussi se demander pourquoi ces tests-là ne pourraient pas être réalisés pendant la phase de développement… Intégrer les testeurs dans l’équipe de développement, voire de conception ? Je vous laisse méditer.

Changer de modèle de vision

Je compris alors que la réponse du formateur n’était ni une remarque blessante ni une provocation, c’était juste l’éblouissante réalité. Quand on s’intéresse au Lean, comme l’explique Taiichi Ohno, il est nécessaire d’avoir l’humilité de mettre de côté ce que l’on sait (et mieux : admettre qu’on se trompe la moitié du temps) pour écouter, entendre et assimiler les principes du Lean. Il faut accepter de voir les choses sous un autre angle, celui du terrain (humilité -> humus -> terre), le Gemba en Lean, là où se font les choses.

Et vos équipes informatiques, passent-elles trop de temps à tester ? Avant de répondre, prenez le prisme du Lean Management.

Source photo : Harwell Dekatron fabriqué en 1950, http://www.minimachines.net