- Home
- Lean Corner
- Du site pilote au standard groupe : cinq décisions qui déterminent si le Lean passe à l’échelle
Du site pilote au standard groupe : cinq décisions qui déterminent si le Lean passe à l’échelle
- Décision 1 : qui construit le standard sur chaque site
- Décision 2 : trouver qui « accroche » avant de déployer l’outil
- Décision 3 : traiter la formation comme une étape distincte, pas une conséquence
- Décision 4 : mesurer la visibilité des problèmes, pas les métriques de résultat
- Décision 5 : traiter le déploiement comme un apprentissage, pas comme un projet
- Ce que ça donne sur un réseau multi-sites
Le pilote réussit presque toujours. Les équipes sont motivées, le directeur de site est impliqué, les premiers résultats arrivent rapidement. Puis vient le déploiement sur les autres sites, et la trajectoire change. Non pas parce que le Lean ne fonctionne pas ailleurs, mais parce que cinq décisions ont été prises par défaut, sans être vraiment pensées. Elles sont réversibles si on les identifie tôt. Elles deviennent structurantes si on les laisse s’installer.
Décision 1 : qui construit le standard sur chaque site
Le mauvais réflexe. L’équipe méthodes écrit le standard sur le site pilote, puis le « déploie » sur les suivants. On documente les meilleures pratiques, on prépare les supports de formation, on planifie les sessions de présentation. Cela semble logique. C’est la source du problème.
La bonne approche. Le standard doit être construit sur chaque site, avec les pratiquants de ce site.
Il existe une anecdote précise qui illustre pourquoi. Des ingénieurs méthodes français visitent une ligne Toyota au Japon. Ils observent, documentent, mesurent. Ils reviennent en France et présentent aux opérateurs une ligne standardisée calquée sur le modèle japonais.
Réponse : refus en bloc, arrêt d’usine. Un sensei japonais prend ensuite le même mandat. Il va voir chaque opérateur individuellement, observe son travail, construit le standard avec lui. Quelques semaines plus tard, chaque opérateur a sa propre séquence standard. Les comparaisons s’organisent naturellement, les discussions s’engagent, les améliorations s’enchaînent. Quelques mois après, la ligne atteint les performances japonaises.
Décision à prendre : le standard du site pilote est une référence, pas un modèle à dupliquer. Chaque site reconstruit le sien, en partant de la référence, avec ses propres opérateurs.Décision 2 : trouver qui "accroche" avant de déployer l'outil
Le mauvais réflexe. Déployer par ordre géographique ou hiérarchique. Former les managers de site lors d’un séminaire central, leur remettre le kit, leur fixer un objectif de déploiement.
La bonne approche. Avant d’arriver sur un site, identifier la personne qui va porter la démarche localement.
Ce n’est pas forcément le directeur de site. C’est souvent un team leader, un responsable d’atelier, parfois un chef d’équipe de nuit. La méthode : lancer des kaizen sur le site non pas pour améliorer les indicateurs, mais pour observer qui s’engage naturellement. Qui pose des questions précises ? Qui essaie sans qu’on lui demande ? Ensuite former cette personne en priorité, lui donner du temps, construire autour d’elle.
Un outil qui arrive sur un site sans porteur local arrive dans un désert. Les formulaires seront remplis. Les indicateurs seront corrects. Les réunions auront lieu à l’heure. Et le Lean sera mort six mois après le départ de l’équipe de déploiement.
Décision à prendre : le calendrier de déploiement doit intégrer une étape préalable d’identification du porteur local. Si personne n’accroche lors des premières semaines d’observation, ce n’est pas le bon moment pour déployer sur ce site.
Décision 3 : traiter la formation comme une étape distincte, pas une conséquence
Le mauvais réflexe. Supposer que le standard écrit se transmet de lui-même. Organiser une présentation d’une heure, distribuer le document, considérer que la formation est faite.
La bonne approche. Former au standard est une étape distincte, avec un accompagnateur qui observe le geste en conditions réelles.
Un brief le matin, une journée de production, et personne pour faire le point en fin de shift : c’est l’équivalent d’une équipe de football qui jouerait ses matchs sans jamais analyser ses performances. Les gestes s’installent, bons ou mauvais, sans correction possible. Former au standard, c’est prévoir le débrief : quelqu’un qui observe le geste en conditions réelles, qui voit où ça bute, et qui corrige avant que la mauvaise habitude ne devienne le nouveau standard non écrit.
Écrire ne transmet pas. Ce qui transmet, c’est faire le geste ensemble, dans les conditions réelles, avec quelqu’un qui observe où ça bute et corrige sur le moment. Le standard est le support de la formation, pas son substitut. Dans un réseau multi-sites, cela implique de décider : qui forme qui, selon quelle méthode, avec quel temps prévu en observation du geste.
Décision à prendre : pour chaque site, définir qui sera formé, par qui, et combien de temps le formateur passera à observer le geste en conditions réelles.
Décision 4 : mesurer la visibilité des problèmes, pas les métriques de résultat
Le mauvais réflexe. Suivre le TRS, le taux de conformité, le taux d’adoption des outils, et considérer qu’un site est « dans la démarche » si ses chiffres sont verts. Ce suivi est nécessaire. Il est insuffisant, et parfois trompeur.
La bonne approche. En Lean, le bon signal n’est pas l’absence de problèmes. C’est leur visibilité.
Un site qui ne remonte aucun problème ne fonctionne pas nécessairement mieux que les autres — il les cache. La mécanique est connue : quand les équipes perçoivent que remonter un problème déclenche une pression plutôt qu’une aide, elles cessent de remonter. Les indicateurs restent corrects parce que les problèmes sont gérés localement, sous le tapis, sans apprentissage collectif.
La règle lean est simple : rien sous le tapis. Un tableau d’anomalies bien rempli, des équipes qui signalent sans hésiter, un manager qui présente ses problèmes non résolus en Tier 2, voilà les signaux d’une démarche vivante. La dérive d’un site ne se détecte pas sur les KPIs. Elle se détecte sur ce qui ne remonte plus.
Décision à prendre : ajouter dans le tableau de bord de déploiement un indicateur de remontée de problèmes. Ce n’est pas un indicateur de performance. C’est un indicateur de santé de la démarche.
Décision 5 : traiter le déploiement comme un apprentissage, pas comme un projet
Le mauvais réflexe. Supposer que parce qu’on a écrit le standard, formé les équipes et installé les outils, le déploiement est terminé. Cette hypothèse est au cœur de la plupart des échecs de passage à l’échelle. Elle a un nom : le rêve des process. Supposer que parce qu’on écrit quelque chose, des équipes sur vingt sites vont l’appliquer uniformément. C’est totalement irréaliste.
La bonne approche. Planifier des boucles d’apprentissage, pas seulement des jalons de déploiement.
La résistance qui apparaît sur les sites n’est pas toujours du refus. C’est souvent « on a toujours fait comme ça », un réflexe de survie psychologique, pas de la mauvaise volonté. Les équipes ont développé des façons de compenser les dysfonctionnements du système, souvent invisibles pour le management. On leur demande de remplacer ces compensations par une méthode nouvelle dont elles ne voient pas encore les bénéfices.
Ce qui change la dynamique : accepter que les sites apprennent à des vitesses différentes, et que chaque site découvre des choses que le pilote n’avait pas découvertes. Ces découvertes doivent pouvoir remonter et enrichir le standard groupe. Un déploiement sans mécanisme de remontée des apprentissages locaux produit des sites conformes en apparence, et un standard qui ne progresse plus.
Décision à prendre : définir qui est responsable de faire remonter les apprentissages des sites et d’actualiser le standard groupe. Ce rôle doit exister avant que le déploiement commence, pas après.
Ce que ça donne sur un réseau multi-sites
[Section produit – proposition de rédaction, à valider et finaliser par l’équipe éditoriale iObeya.]
Sur un site unique, ces cinq décisions peuvent être gérées de façon informelle. Le directeur de site connaît ses équipes, voit les problèmes remonter ou non, ajuste en direct. Sur cinq sites ou dix, la gestion informelle ne tient plus : on ne sait plus quelle version du standard est appliquée où, on ne détecte pas la dérive avant qu’elle soit installée, et les apprentissages locaux restent locaux.
iObeya permet de connecter les boards de management visuel de chaque site à un niveau groupe, pour que le directeur de site puisse voir si les problèmes remontent sur chaque site, si les standards locaux restent cohérents avec la référence groupe, et si les apprentissages d’un site alimentent les autres. La question n’est pas « avons-nous un outil digital de déploiement lean » — c’est « pouvons-nous voir, depuis le groupe, si la démarche est vivante sur chaque site ? ».
Pour les critères de sélection d’une plateforme de management visuel multi-sites, voir notre article dédié.
