Perspectives et limites

Le Lean hors de l'usine

Né dans des usines d'automobiles, le Lean a été transposé au développement de logiciels, à la création d'entreprise, à l'hôpital, aux administrations et, plus timidement, à l'école. Cet article présente les principaux passeurs et leurs ouvrages, des cas hospitaliers célèbres et ce que montrent les études indépendantes. Il distingue ce qui se transpose bien de ce qui se perd en route.

Seattle, 2002 : des médecins dans une usine japonaise

En juin 2002, une trentaine de dirigeants de l'hôpital Virginia Mason, à Seattle, passent deux semaines au Japon. Leur directeur général, le médecin Gary Kaplan, a tenu à ce que toute l'équipe de direction fasse le voyage. Ils ne visitent pas les usines en spectateurs : ils travaillent dans les ateliers à des exercices d'amélioration. À leur retour, l'hôpital adopte ce qu'il appelle le Virginia Mason Production System, dont Charles Kenney a raconté l'histoire dans Transforming Health Care (2010).

L'emprunt le plus connu est l'alerte de sécurité du patient (Patient Safety Alert). C'est une transposition de l'andon, le signal par lequel un ouvrier de Toyota arrête la ligne quand il voit un défaut (voir l'andon et le poka-yoke). Tout salarié qui constate un risque pour un patient doit le signaler aussitôt, et la direction s'engage à réagir sur-le-champ. Le soin peut être suspendu tant que le problème n'est pas traité.

En novembre 2004, Mary McClinton, 69 ans, meurt dans cet hôpital. Au cours d'une intervention sur un anévrisme cérébral, on lui a injecté un antiseptique à la place du produit de contraste, deux liquides incolores ayant été confondus. L'hôpital reconnaît publiquement l'erreur, modifie la procédure et fait de la sécurité des patients sa première priorité. Un prix interne porte depuis le nom de la patiente.

Cet épisode montre deux choses. Adopter une méthode venue de l'industrie ne met pas un hôpital à l'abri de l'accident. Et ce que Virginia Mason a pris à Toyota tient moins à des outils qu'à une façon de réagir : exposer le problème au lieu de le cacher, puis corriger le processus.

Les passeurs : de l'atelier aux principes

La sortie de l'usine a été rendue possible par un livre. Dans Lean Thinking (1996), James Womack et Daniel Jones résument le Lean en cinq principes formulés sans référence à l'automobile : définir la valeur du point de vue du client, identifier la chaîne de valeur, créer un flux, tirer ce flux par la demande et viser la perfection (voir les cinq principes du Lean). Les mêmes auteurs les appliquent aux services et à la consommation dans Lean Solutions (2005). Un principe général ne fait pourtant pas une pratique, et chaque domaine a eu ses propres traducteurs.

Le logiciel : sept principes et un tableau

Mary et Tom Poppendieck publient en 2003 Lean Software Development: An Agile Toolkit. Ils y proposent sept principes : éliminer le gaspillage, amplifier l'apprentissage, décider le plus tard possible, livrer le plus vite possible, donner le pouvoir à l'équipe, intégrer la qualité dès la conception et voir l'ensemble. Ils traduisent aussi les sept gaspillages d'Ohno. Le travail commencé et non terminé est l'équivalent du stock. Les fonctions que personne n'utilisera correspondent à la surproduction. Le passage incessant d'une tâche à l'autre, les attentes et les défauts complètent la liste.

Leur remarque la plus utile est que développer un logiciel ressemble à la conception d'un produit bien plus qu'à sa fabrication. Chaque fonction est nouvelle, et la variation apporte de l'information au lieu d'être un défaut à supprimer. Deux de leurs principes, amplifier l'apprentissage et décider le plus tard possible, n'ont donc pas d'équivalent sur une ligne d'assemblage. Les Poppendieck s'inspirent d'ailleurs du développement des produits chez Toyota plus que de ses ateliers.

Deux autres filiations relient le logiciel à Toyota. David Anderson adapte le kanban aux équipes informatiques dans Kanban (2010), en limitant le nombre de tâches en cours : l'article Kanban et le Lean logiciel du corpus Agilité le présente. Scrum doit son nom à un article de Hirotaka Takeuchi et Ikujiro Nonaka (1986) sur le développement de produits dans des entreprises japonaises, comme le rappelle l'article Scrum en bref.

La startup : apprendre avant de construire

Eric Ries publie The Lean Startup en 2011. Il s'appuie sur son expérience de cofondateur de la société IMVU, sur la méthode de « développement de la clientèle » de Steve Blank (The Four Steps to the Epiphany, 2005) et, explicitement, sur les idées de la production Lean. Pour Ries, une startup est une organisation qui crée quelque chose de nouveau dans une incertitude extrême. Son pire gaspillage est de construire, dans les délais et le budget prévus, un produit dont personne ne veut.

Il propose donc une boucle en trois temps, construire, mesurer et apprendre, que l'on parcourt le plus vite possible. Le produit minimum viable est la plus petite version qui permette de tester une hypothèse sur les clients. Au vu des résultats, l'équipe décide de persévérer ou de « pivoter », c'est-à-dire de changer d'hypothèse.

Ries garde du Lean la définition du gaspillage par le client, le travail par petits lots et les cinq pourquoi. Il laisse de côté le takt time, le travail standardisé et la stabilité du processus, parce qu'une startup cherche encore son modèle au lieu d'exécuter un modèle connu. Le mot « lean » change alors de sens : il désigne le fait d'apprendre vite avec peu de moyens.

Les preuves sont surtout des récits de réussite. Une étude se distingue : en 2020, Arnaldo Camuffo et ses collègues ont publié un essai randomisé mené auprès d'une centaine de jeunes entreprises italiennes. Les fondateurs formés à formuler des hypothèses et à les tester avec rigueur ont obtenu de meilleurs résultats et ont plus souvent changé d'idée en cours de route. L'étude porte sur une « approche scientifique » de la décision, proche du Lean Startup sans se confondre avec lui.

L'hôpital : des récits aux revues de preuves

Avec Virginia Mason, l'autre cas célèbre est ThedaCare, un groupe hospitalier du Wisconsin. Son directeur général de 2000 à 2008, John Toussaint, en a fait le récit avec Roger Gerard dans On the Mend (2010). Dans les deux cas, les résultats annoncés sont rapportés par les établissements eux-mêmes ou par des auteurs qui leur sont favorables. Ils sont aussi fragiles. À ThedaCare, des observateurs appartenant au mouvement Lean ont rapporté que la démarche s'était affaiblie après plusieurs changements de direction dans les années 2010.

Les synthèses indépendantes sont plus réservées. En 2016, John Moraros et deux collègues publient une revue systématique de 22 études sur les interventions Lean en santé. Ils ne trouvent pas d'association statistiquement significative avec la satisfaction des patients ni avec leur état de santé. Ils relèvent une association défavorable avec les coûts et avec la satisfaction du personnel. Les bénéfices sur le déroulement des soins, comme la circulation des patients, leur paraissent possibles mais inconstants. Ces chercheurs de l'université de la Saskatchewan écrivaient au moment où leur province mettait fin, en 2015, à un vaste programme Lean confié à un cabinet de conseil américain et très contesté pour son coût. Leur revue porte sur peu d'études, de qualité inégale. Elle montre au moins que le bénéfice pour les patients reste à démontrer.

La transposition est plus difficile qu'il n'y paraît. Une voiture ne modifie pas le processus qui la fabrique, alors que chaque patient apporte sa propre variabilité. Le « client » est multiple : le patient, sa famille et l'organisme qui finance. Enfin, le déplacement d'une infirmière jusqu'à la chambre d'un patient inquiet ressemble à un geste inutile sur un schéma, alors qu'il fait partie du soin.

Les services et l'administration

L'exemple le mieux documenté est celui de l'administration fiscale britannique (HMRC). À partir du milieu des années 2000, un programme Lean y réorganise le traitement des dossiers : le travail est découpé en tâches courtes et standardisées, et des objectifs horaires sont affichés sur des tableaux. En 2011, Bob Carter et ses collègues publient une enquête menée auprès des agents. Ceux-ci décrivent une perte d'autonomie et de qualification, ainsi qu'une pression accrue. Le titre de l'article reprend le mot de l'un d'eux : « Il ne leur manque qu'une chaîne ».

Zoe Radnor et Stephen Osborne tirent un bilan plus général en 2013. Dans les services publics, écrivent-ils, le Lean a trop souvent été réduit à une boîte à outils tournée vers l'efficacité interne, sans réflexion sur ce que l'usager attend du service. John Seddon, pourtant lecteur attentif d'Ohno, avait formulé une critique voisine dans Freedom from Command and Control (2003). Il appelle « demande d'échec » (failure demand) la demande provoquée par le fait de n'avoir pas fait quelque chose, ou de l'avoir mal fait, pour l'usager. Standardiser et accélérer le traitement de cette demande revient à perfectionner un gaspillage.

L'école

Dans l'enseignement, la plupart des applications concernent l'administration des universités : les admissions, les inscriptions ou la gestion des examens. C'est l'objet du livre de William Balzer, Lean Higher Education (2010). Dans les écoles et les collèges, il existe des expériences dispersées, décrites par leurs promoteurs. À notre connaissance, aucune évaluation ne montre un effet sur les apprentissages des élèves.

La partie administrative d'un établissement a pourtant des flux comme toute organisation. Imaginons une demande d'aménagement pour un élève dyslexique déposée le 15 septembre et appliquée en classe le 10 décembre, soit 86 jours plus tard. Le travail réel (la lecture du bilan, une réunion d'une heure, la rédaction du document et sa signature) représente environ trois heures. Tout le reste est de l'attente entre deux étapes. Dessiner ce parcours, comme l'explique l'article sur la cartographie de la chaîne de valeur, est ici légitime et utile à l'élève.

Dans la classe elle-même, la prudence s'impose. Le temps qu'un élève passe à chercher n'est pas une attente à supprimer, et l'erreur y est un matériau de travail avant d'être un défaut. Ce qui se transpose est plutôt l'amélioration par petits pas menée par les enseignants eux-mêmes. Le Japon en offre un exemple avec l'« étude de leçon » (jugyō kenkyū), que James Stigler et James Hiebert ont fait connaître dans The Teaching Gap (1999) : des enseignants préparent ensemble une leçon, l'observent en classe et la révisent. Cette pratique ne doit rien à Toyota. Elle repose sur la même idée que le kaizen, selon laquelle ceux qui font le travail l'améliorent pas à pas en observant les faits.

Ce qui se transpose

La colonne de gauche réunit des manières de regarder le travail et d'apprendre. La colonne de droite contient des techniques nées d'une production répétitive, qui supposent une demande stable et un produit défini à l'avance.

Limites et pièges

Le premier piège est de transposer les outils sans le second pilier. Beaucoup de programmes gardent la chasse au gaspillage et oublient le respect des personnes. Le cas de l'administration fiscale britannique montre le résultat : un travail appauvri et intensifié, vécu comme un retour à la chaîne.

Le deuxième piège est le temps. Toyota a construit son système en une trentaine d'années, par essais successifs. Un hôpital ou une administration attend des résultats d'un programme de deux ans conduit par des consultants. L'exemple de ThedaCare suggère que ces démarches résistent mal à un changement de direction.

Le troisième piège est le vocabulaire. « Client », « valeur » et « gaspillage » ont un sens clair dans une usine. Ils deviennent discutables dans un service public ou une école, où l'usager participe au résultat et où plusieurs finalités coexistent. Les employer tels quels fait passer pour acquis ce qui devrait être discuté avec les intéressés.

Enfin, les récits positifs viennent pour l'essentiel de ceux qui ont conduit les transformations, et les revues indépendantes sont nettement moins affirmatives. L'article Critiques et état des preuves examine cet écart.