Making IT Lean

Feb 5 / Damien Philippe

Les professionnels de l'informatique vivent souvent dans un paradoxe : ils sont les architectes de l'automatisation pour l'entreprise, mais leurs propres processus internes sont souvent manuels, chaotiques et réactifs.

Dans leur ouvrage Making IT Lean : Applying Lean Practices to the Work of IT, Howard Williams et Rebecca Duray offrent une solution pragmatique : cesser de voir l'IT comme un art mystérieux et commencer à le gérer comme une chaîne de production.

Cette synthèse explore comment l'application des principes du Lean peut résoudre les problèmes chroniques de délais, de qualité et de surcharge de travail dans les services informatiques.

Le livre pose un diagnostic clair : beaucoup de problèmes informatiques viennent d'une mauvaise compréhension de la nature du travail. Les auteurs utilisent l'approche Operations Management (OM) pour classer le travail selon trois variables : le volume, la variété et la variation.

Le piège du "job shop" vs la "ligne de production".

Dans l'industrie, on distingue deux modèles principaux :

Le "job shop" (Atelier) : c'est un modèle adapté à la haute variété et aux faibles volumes. Le flux y est "mélangé", non linéaire, et nécessite souvent des experts hautement qualifiés qui naviguent d'une tâche à l'autre de manière flexible.

La "line" (ligne de production) : il s'agit d'un modèle adapté aux tâches répétitives et standardisées, avec un flux linéaire et séquentiel.

L'erreur classique dans l'IT : de nombreuses équipes traitent des tâches routinières (comme une demande de serveur standard, un patch de sécurité ou un reset de mot de passe) comme s'il s'agissait de projets uniques et artisanaux ("job shop"). Cela crée une complexité artificielle : chaque technicien réinvente la roue, créant des délais et de la variabilité dans la qualité.

La solution Lean : Il faut identifier les "flux linéaires cachés" dans ce chaos. Par exemple, l'installation de correctifs est souvent gérée de manière ad hoc, alors qu'elle devrait suivre un processus linéaire rigoureux et standardisé.

Le Lean n'est pas magique, c'est une approche scientifique basée sur deux piliers :

Le cycle PDCA (Plan-Do-Check-Act) : au lieu de grands projets monolithiques qui échouent souvent ("Plan-Do-Stop"), le Lean préconise de petits cycles d'amélioration continus. On planifie une petite correction, on l'exécute, on vérifie le résultat avec des données, et on standardise si cela fonctionne.

La pensée A3 : inspiré par Toyota, le rapport A3 tient sur une seule page. C'est un outil de réflexion rigoureux qui force à définir le problème avec des faits, analyser la cause racine, proposer des contre-mesures et planifier le suivi. Ce n'est pas juste un formulaire administratif, c'est un processus de mentorat et de dialogue pour développer la capacité de résolution de problèmes des équipes.

Le gaspillage (Muda) est omniprésent dans l'IT, mais il est souvent invisible car il ne s'agit pas de stocks physiques de pièces, mais de "stocks numériques". Le livre identifie 8 types de gaspillages spécifiques à traquer :

Work-in-Progress (WIP) / Stocks : c'est le fléau n°1. Tickets ouverts non résolus, projets commencés mais en pause, emails non lus dans la boîte de réception. Le WIP cache les inefficacités, allonge les délais de livraison et augmente le stress des équipes.

Attentes : temps perdu à attendre une réponse d'un autre département (silos), attendre la fin d'un scan serveur, ou attendre une approbation budgétaire pour un projet déjà validé techniquement.

Défauts : bugs logiciels, déploiements ratés nécessitant un "rollback", tickets réouverts car mal qualifiés ou mal résolus du premier coup.

Sur-traitements (overprocessing) : ajouter des fonctionnalités que le client n'a pas demandées ou des procédures de validation excessivement lourdes pour des risques faibles...

Mouvements : devoir chercher une information dispersée dans trois wikis différents, ou marcher physiquement pour trouver un collègue parce que l'information n'est pas disponible en ligne.

Transports : escalades inutiles de tickets entre les niveaux 1, 2 et 3. Chaque fois qu'un ticket change de main sans être résolu, c'est du transport sans valeur ajoutée.

Surproduction : imprimer des rapports que personne ne lit, générer des logs inutiles qui saturent le stockage, ou développer du code qui ne sera jamais mis en production.

Potentiel humain (le 8ème gaspillage) : utiliser des ingénieurs hautement qualifiés pour des tâches administratives répétitives (comme la réinitialisation de mots de passe), menant au burnout et à la démotivation, tout en privant l'entreprise de leur créativité.

Le livre insiste : on ne résout pas les problèmes depuis une salle de réunion, mais en allant sur le Gemba (le lieu réel où le travail se fait). Il faut observer le travail tel qu'il est fait, et non tel qu'on imagine qu'il est fait.

VSM (Value Stream Mapping) : cet outil permet de cartographier le flux d'information et de travail. contrairement à un diagramme de processus classique, la VSM met en évidence le temps de création de valeur (Value Added) vs le temps d'attente (Non-Value Added). Elle révèle souvent que sur un processus de résolution de 3 jours, il n'y a que 2 heures de travail réel ; le reste n'est que de l'attente.

5S (Trier, Ranger, Nettoyer, Standardiser, Maintenir) : souvent associé à l'usine, le 5S s'applique à l'IT pour créer un environnement de travail clair. Cela peut signifier nettoyer les disques partagés, standardiser les nomenclatures de fichiers, ou organiser la base de connaissances pour que l'information critique soit trouvée en moins de 30 secondes par un technicien au téléphone.

Les 5 Pourquoi (5 Whys) : face à un incident, au lieu de blâmer "l'erreur humaine" (qui n'est jamais une cause racine valide en Lean), on demande "pourquoi" cinq fois de suite pour trouver la faille systémique.

Par exemple : le serveur a planté
-> Pourquoi ? -> Disque plein
-> Pourquoi ? -> Logs non purgés
-> Pourquoi ? -> Pas de procédure automatique
-> Pourquoi ? -> L'équipe n'a pas défini de standard lors de l'installation.

L'une des contributions majeures de l'ouvrage est de réconcilier Lean et ITIL. Si ITIL définit le "Quoi" (les processus nécessaires comme la gestion des incidents ou des changements), le Lean définit le "Comment" : comment rendre ces processus rapides, efficaces et centrés sur la valeur.

L'exemple du Service Desk : Du "Push" au "Pull" :
La plupart des Service Desks fonctionnent en mode "Push" : les tickets s'empilent dans une file d'attente (stock) et sont poussés vers des techniciens souvent surchargés. Le Lean propose de passer à un système "Pull" (tiré). Concrètement, on limite le travail en cours (WIP) pour chaque technicien. Le technicien ne "tire" un nouveau ticket que lorsqu'il a terminé le précédent. Cela réduit le multitâche (source d'erreurs et de stress) et, paradoxalement, accélère le flux global de résolution car les tickets ne stagnent plus ouverts pendant des jours.

Comment démarrer ? Surtout pas par un énorme projet de réorganisation de 2 ans. Williams et Duray recommandent les rapid improvement events (ou événements Kaizen),.

Ce sont des ateliers intensifs de 2 à 5 jours, avec une équipe multidisciplinaire, focalisés sur un problème précis et urgent (ex: "réduire le délai de création des comptes utilisateurs de 5 jours à 4 heures").

Préparation : collecte de données et cartographie de l'état actuel.
L'événement (2-3 jours) : l'équipe analyse les causes racines, imagine l'état futur (Future State) débarrassé des gaspillages, et conçoit les nouvelles procédures.
Actions immédiates : l'objectif est de commencer l'implémentation des solutions immédiatement après l'atelier, pas de faire un rapport.

L'application du Lean à l'IT demande un changement de culture : passer du mode "héros" (qui est récompensé pour éteindre les feux) au mode "gestionnaire d'opérations" (qui empêche les feux de démarrer par des processus robustes). En rendant le travail visible, en respectant les standards et en chassant sans relâche le gaspillage, l'IT peut enfin s'aligner sur la vitesse du business.