Le Lean est partout.

Dans la tech, le produit, les startups avec le Lean Startup, le management.
On en parle comme d’une évidence, d’un standard, presque d’une vérité universelle.

Et pourtant, plus on creuse… plus une question apparaît :

Est-ce qu’on comprend vraiment ce qu’est le Lean ?

Le problème : un Lean réduit à des outils

Aujourd’hui, le Lean est souvent résumé à :

  • réduire les gaspillages
  • optimiser la Value Stream
  • livrer plus vite
  • améliorer en continu

Bref, une logique d’efficacité opérationnelle.

Le problème ?

Le Lean vient essentiellement du Toyota Production System (TPS).

C’est-à-dire : la production de voiture chez Toyota, et pas le développement de produit en lui-même.

Ce que l’on oublie : Toyota ne fait pas que du TPS

Toyota n’est pas performant uniquement parce qu’il optimise ses usines.

👉 Son vrai avantage est ailleurs : sa manière de concevoir ses produits

C’est ce qu’on appelle aujourd’hui le Toyota Product Development System (TPDS).

Et c’est là que tout change.

TPS vs TPDS : deux logiques « Lean » différentes

Le TPS (production) c’est :

  • optimiser
  • standardiser
  • éliminer les variations
  • améliorer l’existant

Ici, la logique est adaptée à la production de systèmes stables.

Le TPDS (développement produit), c’est :

  • explorer
  • apprendre
  • expérimenter
  • converger

Ici, la logique est adaptée à la création de systèmes complexes.

Ce qui veut dire que le TPS optimise ce qui est connu. Le TPDS explore/test ce qui ne l’est pas.

Le vrai problème : on applique le mauvais modèle !

Beaucoup d’organisations font aujourd’hui une erreur simple : elles appliquent une logique TPS… à des problèmes TPDS.

Exemples :

  • planifier une roadmap produit comme une ligne de production
  • figer une solution trop tôt
  • optimiser un produit avant de savoir s’il a du sens

Résultat : rigidité, rework, et décisions fragiles à répétition…

De plus, dans un environnement produit, les besoins évoluent, les contraintes interagissent et les solutions ne sont pas connues à l’avance

Et on dépasse rapidement le cadre simple d’un produit, pour entrer dans un système complexe.

Et dans un système complexe :

❌ on ne peut pas tout prévoir
✔️ on doit apprendre en avançant

L’impact de l’ingénierie et de l’analyse de la valeur chez Toyota…

Le Lean, et plus largement les systèmes développés par Toyota (TPS pour la production, TPDS pour le développement produit), ne sortent pas de nulle part..

Toyota a intégré dès les années 50–70 :

Toutes ces techniques viennent des États-Unis (General Electric, Lawrence D. Miles, années 40)

Et dans les années 70, le choc pétrolier vient bouleverser l’industrie automobile mondiale.
Les constructeurs occidentaux, centrés sur des véhicules lourds et une production de masse rigide, se retrouvent en difficulté.

Toyota, de son côté, était déjà prêt. Grâce à cette intégration entre conception, coût et production, leurs véhicules sont plus économes, plus fiables, mieux adaptés aux contraintes du marché, et la production est standardisée, permettant une meilleure gestion des coûts.

Leur avantage ne vient donc pas uniquement de leur système de production, mais aussi de la cohérence entre ce qu’ils conçoivent et ce qu’ils produisent.

Et plutôt que d’appliquer les techniques comme des outils isolés, ils les ont progressivement intégrées dans un système complet de développement produit. Ce système évoluera ensuite vers un système d’apprentissage produit : le Set-Based Concurrent Engineering.

Aujourd’hui, le TPS applique une philosophie d’analyse de la valeur, et le TPDS applique l’ingénierie de la valeur.

Le cœur du système : le Set-Based Concurrent Engineering.

Toyota ne développe pas ses produits comme on l’imagine.

Ils ne font pas : définir → développer → tester

Ou en tout cas, pas de manière strictement séquentielle…

Ils font plutôt : explorer → apprendre → décider

L’application est simple… mais contre-intuitive :

Au lieu de choisir UNE solution très tôt :

  • ils explorent plusieurs solutions en parallèle
  • ils les testent progressivement
  • ils éliminent celles qui ne tiennent pas

Jusqu’à converger vers une solution robuste.

Cette pratique définit le Set-Based Concurrent Engineering

Set-Based Concurrent Engineering

Et en application ?

Concrètement, ça donne ça :

1. Identification des solutions possibles : toutes les options techniques sont envisagées.

2. Exploration parallèle : plusieurs équipes travaillent en même temps sur différentes pistes.

3. Convergence progressive : les contraintes (coût, production, qualité…) éliminent progressivement les options.

4. Décision tardive : on ne fige qu’une fois qu’on a suffisamment appris.

Et surtout :

On itère là où on apprend.
Quand on n’apprend plus, on fige. Puis on produit en série.

Le point clé : les équipes ne travaillent pas indépendamment…

Et c’est là que beaucoup se trompent sur Toyota ou le Lean en général.

Ce n’est pas juste des équipes en parallèle qui convergent tranquillement.

En réalité : les équipes se contraignent mutuellement.

Exemple :

  • une décision sur un sous-système élimine des options ailleurs
  • les contraintes circulent
  • les solutions se réduisent puis se combinent

La convergence n’est donc pas un choix. C’est une élimination structurée et qui prend du temps.

Pourquoi ça marche ?

Parce que Toyota a compris une chose fondamentale…

Le développement produit est un processus de création de connaissance. Et pas juste un processus de production.

Et la recherche du zéro défaut structure fortement les décisions chez Toyota, car, ce qui compte le plus, c’est la satisfaction du besoin des utilisateurs, tout en gérant les coûts que cela engendre (la fameuse valeur dont tout le monde parle…)

Mais ce modèle crée un paradoxe : Toyota explore plus lentement… mais va plus vite.

Pourquoi ? Parce que moins de rework, des décisions plus robustes et moins d’erreurs tardives.

Aujourd’hui, beaucoup d’équipes produit :

  • itèrent
  • testent
  • livrent

Mais sur une seule solution, et sans avoir réfléchi avant. Ce qui entraine des retouches à répétition, et à l’élaboration progressive de système lourd, que les infrastructures ou organisations environnantes ne peuvent pas supporter.

Et ça, ce n’est ni du TPDS, ni du Lean.

Conclusion.

Le problème n’est pas le Lean, ou les techniques que Toyoto a démocratisés. C’est le contexte dans lequel on les applique.

Dans les systèmes stables, le Lean optimise la production.
Dans les systèmes complexes, le Lean doit évoluer pour basculer sur le produit et devenir un système d’apprentissage.

Toyota, avec leur TPS/TPDS, ne cherche pas à avoir raison tôt. Ils cherchent à apprendre assez pour avoir raison tard.
Et c’est exactement l’inverse de ce que font la plupart des équipes aujourd’hui.