Tout le monde se dit « en flux tiré » aujourd'hui. C'est devenu une évidence de façade, presque une politesse qu'on se doit entre professionnels de la supply chain. Et pourtant, ouvrez l'écran de calcul de besoins de la plupart des planificateurs, et vous verrez surgir, mêlés dans la même colonne de chiffres, des commandes fermes… et des prévisions. Le tout habillé du même habit de confiance. Comme si une hypothèse et un fait se valaient.
Ils ne se valent pas. Et c'est là, je crois, que se joue la vraie signification du flux tiré — pas dans les éditoriaux, pas dans les certifications, mais dans ce qu'on décide de mettre, ou de ne pas mettre, devant les yeux d'un planificateur un mardi matin à 8h.
Dans une véritable solution en flux tiré comme Intuiflow, il existe deux calculs de besoins. Le premier ne travaille que sur la demande ferme — commandes clients, ordres fermes, quel que soit le niveau de nomenclature, produit fini ou composant enfoui trois niveaux plus bas. Celui-là, on peut lui faire confiance : il ne raconte que ce qui est réellement engagé.
Le second intègre des hypothèses de prévision. Il est utile, parfois nécessaire — on ne pilote pas un délai de douze mois sur des commandes fermes qui n'existent pas encore. Mais il faut s'en méfier.
Pas l’ignorer, s'en méfier.
Une prévision reste une prévision : une probabilité qu'on habille en chiffre unique pour la faire tenir dans une colonne d'ERP, mais qui n'engage personne — ni le client, ni la réalité. Plusieurs scénarios de prévisions et des plages de probabilité sont salutaires pour que tout décisionnaire évalue au mieux la projection.
Le problème, ce n'est pas d'avoir les deux calculs. Le problème, c'est de les présenter au même niveau. De montrer par défaut au planificateur un besoin qui mélange du certain et du possible, sans étiquette, sans distinguo. Résultat : il finit par piloter sur du sable en croyant piloter sur du roc.
C'est le même mécanisme que celui du stock projeté — cette courbe rassurante qu'on vous montre en MRP classique et qui vous dit : voici votre stock dans quatre semaines. Mais cette courbe n'arrivera jamais. Elle est construite sur un jeu d'hypothèses figées à l'instant T, qui auront toutes bougé avant que la semaine ne soit terminée.
Le calcul de besoins conventionnel souffre de ce vice caché : il vous donne un chiffre unique, présenté avec l'autorité d'un fait, alors qu'il est en réalité la somme d'un fait (la commande ferme) et d'un pari (la prévision). Des besoins issus des stocks de sécurité d’articles parents s’infiltrent aussi dans le mix, pour ajouter à la confusion.
Le résultat est confortable — un seul chiffre, une seule ligne à lire. Mais c'est exactement cette fausse simplicité qui vous fait perdre le réflexe le plus précieux d'un bon planificateur : savoir sur quoi il peut vraiment s'appuyer.
De plus, dans de nombreuses organisations, les prévisions ont été établies par quelqu’un d’autre, puis enfouies dans le système pour générer des besoins auxquels je suis censé me conformer – que puis-je faire d’autre ?
Alors oui, montrer par défaut la seule demande ferme, c'est inconfortable. J'ai vu la réaction chez plusieurs industriels : le planificateur qui découvre un besoin réduit à peau de chagrin sur son horizon proche à l'impression, l'espace d'un instant, de piloter à l'aveugle. « Où sont passées mes prévisions ? On me cache quelque chose ? » Non. On ne lui cache rien — on lui montre enfin ce qui est vraiment engagé, et on garde le reste, la part d'hypothèse, dans un calcul séparé, accessible, mais jamais confondu avec le premier.
C'est la logique de l'équation de flux net en DDMRP : on ne pilote pas le réapprovisionnement sur un empilement d'hypothèses, on le pilote sur la demande qualifiée — les commandes fermes et les pics réellement avérés. Le reste — les moyennes, les prévisions, les scénarios — sert à dimensionner les buffers en amont, pas à générer l'ordre du jour. Chacun son rôle. Chacun sa place dans le flux de décision.
Le distinguo entre demande ferme et demande prévisionnelle n'est pas une fonctionnalité qu'on active dans un coin de l'écran. C'est un choix de gouvernance de la donnée, qui doit être assumé — et expliqué — avant même de parler d'outil.
Techniquement, séparer les deux calculs n’est pas très compliqué. Le vrai chantier est ailleurs : c'est d'accepter, en tant qu'organisation, qu'un planificateur puisse voir un besoin « pauvre » sur son horizon proche sans que cela déclenche une crise de confiance dans l'outil. C'est d'expliquer que ce vide apparent n'est pas une absence d'information, mais l'information elle-même — la vraie, la seule sur laquelle on peut engager une commande ferme sans regret.
Ça peut prendre plusieurs semaines pour s’acclimater à ce changement de perspective. Mais progressivement on gagne en confiance, car les recommandations issues de la demande ferme démontrent leur pertinence et efficacité. Et progressivement les équipes arrêtent de chercher à « remplir » l’horizon pour se rassurer, et commencent à lire le distinguo comme un signal utile — celui qui leur dit, en un coup d'œil, jusqu'où elles peuvent avancer les yeux fermés, et à partir d'où elles doivent ouvrir les yeux et explorer les scénarios d’adaptation.
La vraie signification du flux tiré n'est pas un supplément d'âme méthodologique. C'est ce moment précis, très concret, où on décide de ne plus mélanger le certain et le possible sur le même écran — et d'assumer l'inconfort que cela produit, le temps que la confiance se reconstruise sur des bases plus solides.