🧠 1. Lean, Six Sigma : deux méthodes qu’on croit industrielles (et c’est vrai)… mais pas que !
Quand on entend Lean Six Sigma (Lean et/ou Six Sigma), beaucoup pensent d’abord à des chaînes de montage, des casques jaunes et des boîtes à outils rangées au millimètre. Bref, un monde de production pure et dure. Et ce n’est pas faux : ces méthodes sont nées dans les usines (Toyota pour le Lean, Motorola pour le Six Sigma).
Mais voici le twist : ces approches s’appliquent parfaitement aux services IT, et notamment à un domaine souvent malmené — le support utilisateur.
⚙️ Lean : « Et si on arrêtait de perdre du temps pour rien ? »
Le Lean, c’est avant tout une méthode pour supprimer les gaspillages dans un processus. Pas pour accélérer les gens, mais pour accélérer les flux.
Et dans le monde IT, des flux… il y en a partout :
- Des tickets qui attendent d’être traités 🕑
- Des mails transférés trois fois avant d’atterrir au bon endroit 📤📥
- Des relances internes, des escalades, des scripts oubliés…
Le Lean aide à remettre de l’ordre là-dedans.
📊 Six Sigma : « Fiabilité, stabilité, zéro surprise (ou presque) »
De son côté, le Six Sigma a pour mission de réduire la variabilité :
- Pourquoi deux tickets identiques n’ont-ils pas le même temps de résolution ?
- Pourquoi certains agents trouvent la solution en 2 min et d’autres en 2 heures ?
- Pourquoi certains incidents (coucou Active Directory 👋) reviennent en boucle sans qu’on comprenne vraiment pourquoi ?
Six Sigma repose sur une démarche rigoureuse (le fameux DMAIC), mais ne nécessite pas d’être statisticien pour faire le job. Il s’agit d’apprendre à mesurer, comprendre, corriger, stabiliser.
💡 Leur alliance : Lean Six Sigma
Ensemble, Lean + Six Sigma, c’est le duo gagnant :
- Lean fluidifie le flux
- Six Sigma en fiabilise le contenu
Et dans l’IT, ça donne un support :
- plus rapide 🏃♂️
- plus fiable 🧰
- et beaucoup moins frustrant (pour l’utilisateur et l’agent) 😌
🖥️ 2. Support IT : un terrain parfait pour tester ces méthodes
Si le Lean Six Sigma devait choisir une porte d’entrée dans le monde de l’IT, ce serait sans hésiter celle du support utilisateur.
Pourquoi ? Parce que c’est là que les flux sont visibles, les irritants quotidiens palpables, et que les améliorations ont un impact immédiat sur la qualité de service… et sur la santé mentale des équipes 😅
🔍 Un flux, c’est quoi en support ?
Un flux, ce n’est pas juste une série d’étapes. C’est un enchaînement d’actions, de décisions, de transferts et d’attentes… depuis le moment où un utilisateur signale un problème jusqu’à sa résolution (ou son abandon dans l’oubli des backlogs éternels).
Exemple classique :
📬 « Je ne peux plus accéder à mes fichiers partagés, ça urge. »
🎟️ Ticket créé → affecté → réaffecté → diagnostiqué → escaladé → corrigé → fermé → relancé → corrigé (vraiment) → clôturé.
Chaque étape est un point potentiel de friction, de perte de temps, ou d’erreur. Et c’est précisément ce que Lean Six Sigma aime analyser.
🧩 Des problèmes très Lean, très Six Sigma
| Problème courant | Symptôme | Diagnostic |
|---|---|---|
| Ticket traité 3 jours après ouverture | Attente invisible | ⏱️ Gaspillage (Lean) |
| Agent de niveau 1 déborde alors que le niveau 2 joue à Tetris | Mauvaise répartition de charge | 🎯 Déséquilibre (Lean + Sigma) |
| Résolution différente selon l’agent | Variabilité qualité | 📉 Instabilité (Six Sigma) |
| Utilisateur relance plusieurs fois | Flux non maîtrisé | 🔁 Boucle inutile (Lean) |
| Les mêmes bugs AD reviennent chaque semaine | Symptôme récurrent | 📌 Cause racine ignorée (Sigma) |
🛎️ Le support, un bon laboratoire Lean Six Sigma
Pourquoi c’est un bon terrain de jeu pour améliorer les choses ?
- Parce que tout est traçable (tickets, délais, réponses)
- Parce que les flux sont récurrents
- Parce qu’il y a souvent peu de standardisation réelle
- Et parce que… tout le monde râle (utilisateurs ET support) → donc les irritants sont connus, il suffit de les canaliser 💡
⚠️ Bonus : ne pas confondre « activité » et « valeur »
Un ticket déplacé 4 fois entre groupes techniques n’a rien de « valeur ajoutée » pour l’utilisateur.
Ce qu’il veut, c’est récupérer ses accès ou relancer son poste. Point.
👉 Le Lean nous force à nous poser la question : ce que je fais à chaque étape, est-ce utile pour l’utilisateur ?
👉 Le Six Sigma, lui, nous demande : est-ce que je le fais de manière stable et maîtrisée ?
🧹 3. Lean appliqué au support IT : on chasse les « TIMWOOD »
Le Lean nous invite à partir à la chasse… pas aux tickets ni aux utilisateurs grincheux, mais aux gaspillages invisibles qui pourrissent l’efficacité au quotidien.
Ces gaspillages sont regroupés dans un acronyme bien connu : TIMWOOD. Et oui, ça sonne comme un nom de série B des années 80, mais en réalité ce sont 7 sources de perte de temps ou d’énergie que l’on retrouve partout… surtout dans le support IT.
🔍 TIMWOOD en support IT : traduction et cas concrets
| 🧱 T | Transport : déplacements inutiles d’informations |
|---|---|
| 🧩 Exemple : un ticket transféré trois fois entre équipes car mal catégorisé à l’entrée. | |
| ➡️ Chaque transfert est une perte de temps, et le ticket n’avance pas. |
| 📦 I | Inventory : files d’attente, backlog, tickets non traités |
|---|---|
| 🧩 Exemple : 200 tickets en file non priorisée dans l’outil, dont certains datent de 3 semaines. | |
| ➡️ Ça s’entasse, ça dort, ça explose un jour. |
| 🕺 M | Motion : gestes inutiles, clics superflus, doubles saisies |
|---|---|
| 🧩 Exemple : copier-coller les infos du mail utilisateur dans le ticket à la main… alors que l’outil pourrait le faire automatiquement. |
| ⏳ W | Waiting : attente, blocage, délais inutiles |
|---|---|
| 🧩 Exemple : attendre la réponse d’un autre service (réseau, infra) pour diagnostiquer un ticket, faute de documentation ou d’accès. |
| 🏭 O | Overproduction : faire trop, trop tôt, pour rien |
|---|---|
| 🧩 Exemple : documenter un ticket résolu en 2 minutes avec une procédure de 2 pages… parce que « il faut bien remplir le champ ». |
| ⚙️ O | Overprocessing : complexité excessive, redondance |
|---|---|
| 🧩 Exemple : multiples validations managériales pour réinitialiser un mot de passe… |
| ❌ D | Defects : erreurs, tickets mal traités, rework |
|---|---|
| 🧩 Exemple : mauvaise clôture du ticket, problème non résolu → retour utilisateur → réouverture. | |
| ➡️ Double effort, double agacement. |
🎯 Résultat : une machine qui s’encrasse doucement…
Chacun de ces gaspillages ralentit les flux, aggrave la charge mentale des agents support, et altère l’expérience utilisateur.
Mais la bonne nouvelle, c’est qu’ils sont :
- identifiables ✅
- mesurables 📏
- corrigeables 🔧
Et c’est exactement là que le Lean brille : en faisant apparaître ces micro-ralentissements comme des opportunités d’optimisation, pas comme des fautes humaines.
📉 4. Six Sigma : pas besoin d’être data scientist pour en tirer du bon
Le nom fait un peu peur : Six Sigma. On imagine des matrices, des histogrammes, des réunions pleines de stats incompréhensibles… Et pourtant, c’est bien plus accessible qu’il n’y paraît, surtout quand on reste centré sur l’objectif principal : réduire la variabilité et fiabiliser les processus.
🧪 Concrètement, c’est quoi la variabilité dans l’IT ?
Dans le support utilisateur, c’est simple :
- Deux tickets identiques, mais deux délais complètement différents
- Une solution qui fonctionne lundi… mais plus vendredi
- Une procédure bien documentée, mais appliquée de 4 façons différentes selon l’agent
- Des incidents récurrents jamais vraiment analysés
Bref, c’est l’incertitude permanente. Et quand l’utilisateur dit « je ne sais jamais si ça va marcher ou pas avec vous », c’est exactement ce que Six Sigma veut corriger.
🎯 Le super-pouvoir : le DMAIC
Le Six Sigma repose sur un cycle simple, que même ton stagiaire peut retenir : D.M.A.I.C.
Voici la version 100 % support IT :
| Étape | Ce qu’on fait | Exemple dans un incident |
|---|---|---|
| Define | On définit le vrai problème | Trop de tickets récurrents sur l’authentification |
| Measure | On mesure les données réelles | 43 tickets/mois sur l’AD, 70% non traités au niveau 1 |
| Analyze | On cherche les causes racines | Mauvaise conf GPO + manque de documentation |
| Improve | On agit pour corriger durablement | Ajout de script de vérif, formation ciblée |
| Control | On vérifie que ça tient dans le temps | Suivi des tickets, KPIs mensuels, retour terrain |
Ce n’est ni sorcier, ni réservé aux ingénieurs process industriels.
C’est juste une façon rigoureuse de traiter les vrais problèmes à la racine, et éviter les rustines qu’on colle à la va-vite.
💥 Focus : les incidents Active Directory
Prenons un cas bien connu de beaucoup de supports IT : les incidents AD.
👉 Un ticket typique :
« Je n’arrive plus à me connecter, mon compte semble bloqué. »
Ce genre de ticket peut exploser en cascade :
- compte verrouillé par une attaque brute force via VPN
- absence de MFA
- logs d’authentification non centralisés
- temps de réponse trop long → perte de productivité → pression sur le support
🎯 Appliquer un DMAIC ici permet de :
- cartographier les causes
- sécuriser le flux
- standardiser les réponses
- déclencher des actions SSI structurées, pas juste du « dépannage »
Et ça, c’est exactement ce qu’on cherche : du traitement intelligent, fiable, et durable.
🧭 5. Mettre en place un modèle vertueux Lean Six Sigma : mode d’emploi
Appliquer Lean Six Sigma à un service support IT, ce n’est pas dérouler un plan de transformation à la McKinsey.
C’est avant tout réfléchir comme un artisan : observer, simplifier, fiabiliser.
🗺️ Étape 1 : cartographier vos flux (VSM)
VSM = Value Stream Mapping
→ Une cartographie simple qui montre chaque étape du flux : de la création du ticket à sa résolution.
💡 Exemple typique :
Utilisateur → Ticket → Analyse → Affectation → Résolution → Clôture
Sur ce flux, identifiez :
- où ça bloque ⛔
- où ça boucle en rond 🔁
- où les gens attendent pour rien 🕑
- où vous perdez de l’info 💥
Un bon VSM permet de poser à plat les dysfonctionnements structurels, bien mieux que 12 pages de slides.
📊 Étape 2 : choisir les bons indicateurs (pas les KPI gadget)
❌ Ne mesurez pas juste « le nombre de tickets traités » → ça ne dit rien sur la qualité.
✅ Mesurez plutôt :
- % de tickets résolus au premier contact (First Call Resolution)
- % de tickets récurrents dans une période
- temps moyen de traitement par catégorie (pas par agent)
- taux de satisfaction client
- taux de tickets escaladés évitables
Un tableau de bord léger, visible, mis à jour régulièrement : c’est le nerf de la guerre.
👥 Étape 3 : intégrer l’équipe dans l’amélioration continue (Kaizen)
Le support, c’est souvent l’équipe oubliée des projets de transformation.
➡️ Grave erreur : c’est là que les dysfonctionnements apparaissent en premier.
➡️ Encouragez le terrain à proposer des idées d’amélioration, même minuscules.
Exemples de micro-kaizen :
- modifier un champ obligatoire dans l’outil de ticketing 🧾
- créer un modèle de réponse pour une erreur courante
- mettre une alerte auto pour les tickets de type « AD/connexion » en cas de pic
C’est rapide, utile et responsabilisant.
📐 Étape 4 : formalisez… sans bureaucratiser
Un process standard, ce n’est pas un PDF de 18 pages lu par personne.
C’est :
- un schéma clair, affiché dans l’open space ou l’intranet
- des scripts techniques accessibles
- une formation légère mais régulière
- des bonnes pratiques ITIL adaptées, pas imposées
📦 Étape 5 : améliorez, testez, mesurez, recommencez
Le modèle vertueux Lean Six Sigma est vivant. Il se base sur des cycles courts :
Observation ➜ Amélioration ➜ Mesure ➜ Réajustement
Tu veux aller loin ?
🔁 Mets en place un retour d’expérience mensuel, avec :
- les incidents récurrents
- les tickets en anomalie
- les suggestions d’agents
🎯 L’objectif : moins de tickets, plus de sérénité.
🚫 6. Ce qu’il ne faut pas faire (sinon c’est du taylorisme 2.0)
Tu te souviens de Frederick Taylor ? Le gars du début du XXe siècle qui voulait découper le travail en gestes chronométrés et robotiser les ouvriers ?
Eh bien, appliqué n’importe comment, Lean Six Sigma peut vite devenir son héritier direct, version IT.
Voici donc la liste noire des dérives à éviter absolument :
📉 ❌ Mesurer pour contrôler, pas pour améliorer
Le but des indicateurs Lean Six Sigma, ce n’est pas de surveiller les agents, mais d’identifier les blocages dans les processus.
🔻 Mauvaise pratique :
« Tu as fermé 14 tickets aujourd’hui, c’est moins que Pierre. Pourquoi ? »
➡️ Résultat : stress, triche sur les stats, démotivation.
✅ Bonne pratique :
« Pourquoi ce type de ticket prend toujours plus de temps ? Voyons ensemble comment on peut l’améliorer. »
📋 ❌ Surcharger avec des procédures rigides
Une procédure de 10 pages pour traiter un simple mot de passe oublié ? Non merci.
Lean Six Sigma vise la clarté et la simplicité, pas l’usine à gaz.
🔻 Mauvaise pratique :
Toute résolution passe obligatoirement par 4 validations managériales, même pour une demande basique.
✅ Bonne pratique :
On fiabilise, puis on automatise ou délègue. On fluidifie, puis on formalise l’essentiel, pas tout.
⛔ ❌ Utiliser des KPI absurdes
🔻 Mauvais KPI :
- Nombre de clics pour créer un ticket (on s’en fiche)
- Nombre de tickets fermés par heure (à la chaîne, façon usine)
- Temps moyen de traitement sans tenir compte de la complexité
✅ Bon KPI :
- % de résolution au premier contact
- Délai moyen entre ouverture et prise en charge
- Réduction des tickets récurrents sur 30 jours
🧠 ❌ Oublier l’humain (et le terrain)
Un projet Lean Six Sigma doit être fait avec les équipes, pas sur elles.
🔻 Mauvaise pratique :
Projet lancé par la direction, sans concertation avec les agents support. Résistance garantie.
✅ Bonne pratique :
Ateliers Kaizen mensuels avec l’équipe, retours intégrés, indicateurs partagés et compris.
⚠️ Résultat des dérives : Lean washing + burn-out
Quand mal utilisé, Lean devient :
- une usine à tableaux Excel
- un prétexte à fliquer les agents
- une source d’angoisse au lieu d’amélioration
Et c’est dommage, parce que bien utilisé, c’est l’un des meilleurs leviers pour améliorer le quotidien d’un service support.
🎯 Bref : ne traquez pas la performance des gens. Traquez les causes structurelles de l’inefficacité.
✅ Conclusion – Lean Six Sigma dans l’IT : pas de magie, mais un vrai levier de mieux
Si tu ne devais retenir qu’une chose, c’est celle-ci :
Lean Six Sigma n’est pas un outil de contrôle, c’est un catalyseur de bon sens.
Appliqué intelligemment, c’est ce qui transforme un service IT :
- d’un centre de coût râleur 😤
- en un centre de valeur réactif 💡
Ce n’est ni une mode, ni un dogme. C’est une boîte à outils que tu peux adapter à ton contexte :
- Tu veux réduire les tickets redondants ? ➜ Analyse des causes.
- Tu veux fluidifier l’affectation ? ➜ VSM + élimination du gaspillage.
- Tu veux réconcilier utilisateurs et support ? ➜ Fiabilisation + écoute terrain.
Le tout sans jargon, sans transformation radicale… mais avec méthode et régularité.
🧰 Bonus : Kit de démarrage Lean Six Sigma pour ton support IT
📋 Questions à te poser :
- Quelles sont les étapes d’un ticket type ?
- Où est-ce que ça bloque, ça patine ou ça revient ?
- Quels types de tickets reviennent en boucle ?
- Est-ce que les utilisateurs reçoivent des réponses cohérentes ?
🧠 Méthodes utiles :
- Value Stream Mapping → pour visualiser le flux
- DMAIC → pour corriger les problèmes récurrents
- Kaizen → pour impliquer l’équipe dans les améliorations
- Pareto → pour cibler les vrais 20 % qui causent 80 % des soucis
❌ À éviter :
- KPI gadget
- Procédures lourdes
- Mesure individuelle au lieu de collective
- Projet Lean lancé par les chefs, sans les agents
