(Originally published on Kinder Wiser collaborative blog)

Informaticien depuis 25 ans, j’ai occupé un grand nombre de postes, dans des industries variées. J’ai eu la chance d’exercer dans plusieurs pays et sur plusieurs types de technologies, depuis les mainframes IBM des années 60 jusqu’aux technologies avancées des startups mobiles.

Ma stratégie de survie dans cette industrie qui change à toute allure a été de penser en termes de modèle. Une stratégie héritée du standard de l’informatique appelé “Design patterns” que l’on peut résumer de la façon suivante : chaque problème qui vous ralentit dans la conception d’un logiciel, a forcément déjà été rencontré et résolu dans une solution de conception spécifique.

C’est à la fois une bénédiction et une malédiction. Une bénédiction car cela m’a fait gagner beaucoup de temps et m’a permis de naviguer sans trop de dommages dans le monde des SI. La malédiction est que cela a profondément modelé ma façon de voir les choses ; au lieu de véritablement chercher à comprendre le problème, j’ai eu tendance à essayer de reconnaitre des situations connues pour y appliquer des modèles préétablis : à moi les idées préconçues et les conclusions hâtives !

Par ailleurs, cette façon de penser relève du « over-engineering » (une plaie du langage de programmation Java et du développement logiciel au sens large) et une tendance à appréhender la complexité du monde avec des solutions complexes, génériques et abstraites en forçant le modèle là où il n’est pas forcément pertinent.

Cela s’inscrit dans le prolongement de l’éducation qui nous est infligée : construire de stocks de savoir (accumuler les modèles comme des “guides” et les anti-modèles comme des “choses à éviter”), se dire que plus j’ai de stocks, mieux je suis armé pour résoudre les problèmes et faire taire les voix discordantes. Hélas, ça n’est pas ainsi que l’on éradique les problèmes : on ne fait que supprimer les symptômes ! C’est toute la différence entre réfléchir vite et réfléchir bien. Sans parler du manque de respect à l’égard des autres personnes impliquées dont on peut faire preuve dans ce cas-là.

Au cours des deux dernières années, j’ai compris que le mode de pensée Lean était différent. Le Lean a pour objectif de montrer du respect pour les gens en essayant de comprendre le problème, puis en formulant des hypothèses, en les testant, et en mesurant la différence entre le résultat attendu dans l’hypothèse et le résultat obtenu dans la vraie vie.  Apprendre en faisant et comprendre véritablement, en profondeur, ce qui entrave notre processus de réflexion et fait remonter nos idées préconçues.

Lors du Lean Tour Bordeaux, Christophe Riboulet CEO de Proditec a eu cette très belle remarque :

« Plus on avait d’ingénieurs moins on innovait. Nos ingénieurs sortant d’école savent résoudre un problème connu pour lequel il existe une solution connue. Mais il ne savent pas résoudre un problème inconnu pour lequel il faut avoir une approche scientifique avec le PDCA.”

Les modèles de conception (Design Patterns) acquis sont des stocks de savoir et donc des entités statiques, qui transforment (souvent à tort) chaque problème en une situation applicable à ces modèles. L’apprentissage est autre chose : un processus dynamique de découverte. Accumuler du savoir n’est pas apprendre : voilà un des enseignements du Lean.