Le Lean appliqué à l’IT

Le Lean comprend deux piliers, qui sont le jidoka d’une part et le juste-à-temps d’autre part. Ces deux piliers sont intimement liés et sont souvent mis en œuvre conjointement.

Le jidoka

Le premier pilier du Lean, ou jidoka, peut se traduire approximativement par “automatisation avec une touche humaine”. On trouve parfois le terme “autonomation”. Il s’agit de donner aux machines la capacité de détecter les problèmes et d’arrêter immédiatement la production dès qu’un problème est détecté. Cette notion “d’arrêt au défaut” est importante, car elle permet de limiter la propagation des défauts.

En arrêtant la production au moment même où le problème survient, on évite de produire des pièces défectueuses qui sont diffusées en aval et potentiellement intégrées au produit final. Ces pièces défectueuses contribuent à amoindrir la qualité du livrable et, in fine, réduisent la satisfaction du client.

Appliqué au développement logiciel, le jidoka consiste par exemple à stopper la production de code dès qu’une anomalie est détectée, et ce, le plus tôt possible. Il peut s’agir d’une spécification peu claire, de tests insuffisants ou tout simplement d’échecs, d’anomalies révélées par l’analyse statique, le typage, etc. Toute anomalie détectée correspond en réalité à un écart constaté par rapport à une attente particulière, un standard. La définition de ces standards est une composante importante du jidoka.

Idéalement, ces anomalies sont détectées à l’endroit même où elles peuvent se produire : dans le code lui-même, c’est-à-dire dans l’éditeur de code. Les mécanismes de pipeline de build et de déploiement (communément appelés pipelines CI/CD) font partie de ces dispositifs qui visent à arrêter la production du logiciel et à empêcher la livraison de logiciels défectueux qui s’écartent des standards attendus.

Le juste-à-temps

Le deuxième pilier, ou juste-à-temps, consiste à produire uniquement ce qui est nécessaire, quand c’est nécessaire, et en quantité suffisante. Il s’agit de réduire les stocks à un instant donné ainsi que les délais de production. Cela implique notamment une étude du lead time, c’est-à-dire le temps nécessaire pour produire un produit entre le moment où cette production est décidée et le moment où elle est terminée.

Appliqué au développement logiciel, le juste-à-temps consiste à produire des fonctionnalités en petites quantités et à les livrer dès qu’elles sont prêtes, afin de les confronter le plus fréquemment possible aux utilisateurs finaux. Cette confrontation régulière permet de recueillir leur ressenti, d’évaluer leur niveau de satisfaction et d’ajuster éventuellement les développements logiciels suivants pour mieux répondre à leurs attentes.

L’un des composants du juste-à-temps est le flux tiré, qui consiste à déclencher un réapprovisionnement en fonction de la consommation réelle. Une illustration du flux tiré consisterait donc à ne déclencher la production d’une nouvelle “user story” que lorsque le développement de la user story en cours est terminé et livré en production.

Le juste-à-temps est, quant à lui, le mécanisme global qui vise à synchroniser l’offre et la demande de consommation.

Une conséquence du juste-à-temps est de réduire la taille des backlogs, qui sont autant de tickets spécifiés trop tôt et dont la pertinence dans le temps risque de décroître faute de confrontation régulière aux utilisateurs finaux.