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 Steam
  • 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 chez Toyota, et pas le développement produit.

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 à des systèmes stables ou compliqués

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

  • explorer
  • apprendre
  • expérimenter
  • converger

Alors qu’ici, la logique est adaptée à des systèmes complexes qui doivent être développés.

Ce qui veut dire que le TPS optimise ce qui est connu. Le TPDS explore 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
  • décisions fragiles

La réalité : le développement produit est un problème complexe

Dans un environnement produit :

  • les besoins évoluent
  • les contraintes interagissent
  • les solutions ne sont pas connues à l’avance

On est dans un système complexe.

Et dans un système complexe :

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

Comment Toyota produit réellement ?

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

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

Ils font : explorer → apprendre → décider

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

Le principe est simple… mais contre-intuitif :

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 s’appelle le 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.

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

C’est là que beaucoup se trompent.

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 pas un choix. C’est une élimination structurée.

Pourquoi ça marche ?

Parce que Toyota a compris une chose fondamentale : le développement produit est un processus de création de connaissance

Pas juste un processus de production.

L’impact de l’ingénierie et de l’analyse de la valeur dans le Lean

Le TPS et le Lean ne sortent pas de nulle part.

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

Mais ils ne s’en sont pas arrêtés là. Ils l’ont transformée en 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 paradoxe de Toyota et du Lean

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

Pourquoi ?

  • moins de rework
  • décisions plus robustes
  • 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.

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

Conclusion

Le problème n’est pas le Lean. C’est le contexte dans lequel on l’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 ne cherche pas à avoir raison tôt. Ils cherchent à apprendre assez pour avoir raison tard.