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 :

• l’analyse fonctionnelle
• l’analyse de la valeur pour l’optimisation coût / valeur de la production
• l’ingénierie de la valeur pour la création de nouveau produit en éliminant, dès la conception, le superflu

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

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.

The post Lean et Toyota : pourquoi on se trompe (presque) tous appeared first on Yohan Pagnoux.

On a tendance à présenter la gestion de projet comme un ensemble de méthode.

Waterfall. Agile. Scrum. Prince2.

Comme s’il suffisait de choisir la bonne pour réussir.

C’est faux.

La gestion de projet ne repose pas sur une méthode.

Elle repose sur du bon sens, de la logique… et de la communication.

Le business de la méthode qui « marche », et de la méthode qui ne « marche pas »…

Beaucoup de contenus vendent des méthodes comme des solutions universelles.

« Applique Scrum et ton projet va fonctionner. »
« Structure ton projet en cycle en V et tout sera maîtrisé. »

Le problème, c’est que ces discours reposent souvent sur des cas particuliers.

Ce qui a fonctionné dans un contexte précis est présenté comme une vérité générale.

C’est un biais classique.

Mais un projet n’est jamais reproductible à l’identique.

Un projet ne commence pas par une méthode, mais par une question simple

Avant de parler d’outils, de planning ou d’organisation, il y a une question fondamentale :

👉 Est-ce qu’il y a réellement un problème à résoudre ?

Et surtout :

👉 Est-ce que ce problème justifie un projet ?

C’est ça, le vrai point de départ.

La gestion de projet n’est pas une exécution.

C’est un processus de questionnement.

Le cadrage : l’étape que tout le monde sous-estime

C’est dans la phase de cadrage que tout se joue.

C’est là que vous devez définir :

• le problème réel
• les résultats attendus
• les bénéfices pour l’organisation
• les ressources nécessaires

Mais surtout : c’est là que vous choisissez comment vous allez travailler.

Deux situations possibles :

• Soit la solution est claire, déjà connue, documentée.
• Soit elle ne l’est pas, et vous allez devoir explorer.

Et ces deux cas ne se gèrent pas de la même manière.

Adapter l’approche, au lieu de suivre une méthode…

C’est probablement l’erreur la plus fréquente : choisir une méthode… avant de comprendre le projet.

Dans la réalité :

• certains projets nécessitent une planification prédictive
• d’autres nécessitent une exploration progressive
• beaucoup nécessitent un mélange des deux

Ni Waterfall ni Agile ne garantissent quoi que ce soit.

Ce sont des cadres.

Rien de plus.

Le vrai travail consiste à construire une organisation adaptée à votre contexte.

L’itération est une nécessité, pas une option !

Un projet n’est jamais parfaitement défini dès le départ.

Il évolue. Votre compréhension évolue. Les contraintes évoluent.

C’est pour ça que la gestion de projet repose sur des cycles :

• collecter de l’information
• analyser
• tester
• ajuster

Encore et encore.

Ce processus est au cœur du pilotage. Pas la méthode.

Les outils ne sont que des supports…

Gantt, Trello, Jira…

Peu importe.

Un outil ne rend pas un projet meilleur.

Il rend simplement une organisation visible.

Le bon outil est celui qui correspond :

• au type de projet
• aux besoins de l’équipe
• au niveau de complexité

Certains projets nécessitent une planification détaillée.

D’autres fonctionnent mieux avec des cycles courts.

Et dans beaucoup de cas, il faut combiner plusieurs outils.

Un projet n’est jamais homogène !

Autre erreur fréquente : vouloir appliquer une seule méthode à tout le projet.

Dans la réalité, un projet est souvent composé de plusieurs phases très différentes.

Par exemple :

• une phase d’infrastructure
• une phase de développement
• une phase de déploiement

Chaque phase a ses propres contraintes. Et nécessite une organisation adaptée.

Une méthode unique ne permet pas de s’adapter à chaque situation.

La formation : le point souvent négligé !

Beaucoup rejettent la théorie.

« Ça ne correspond pas à la réalité. »

En réalité, le problème n’est pas la théorie.

C’est sa mauvaise compréhension.

Une bonne maîtrise des concepts permet :

• de comprendre les outils et les méthodes
• de choisir les bonnes approches
• d’adapter intelligemment les méthodes

Sans ça, on applique des choses… sans savoir pourquoi.

La communication : le vrai levier d’une méthode qui marche

Si vous devez retenir une seule chose, c’est celle-ci :

👉 un projet réussi est un projet où les gens se parlent

C’est par les échanges que vous :

• comprenez le besoin
• alignez les acteurs
• prenez les bonnes décisions
• ajustez votre trajectoire

Sans communication, tout le reste devient fragile. Et aucune méthode ne permet de corriger cela.

Conclusion

La gestion de projet n’est pas une méthode.

C’est une capacité à :

• comprendre une situation
• structurer une réponse
• s’adapter en permanence

Les méthodes, les outils, les frameworks…

Tout ça ne sert qu’à une chose : vous aider à réfléchir.

Mais ils ne remplaceront jamais le bon sens.

The post La gestion de projet n’est pas une histoire de méthode appeared first on Yohan Pagnoux.