Faites l'essai un jour, avec vos enfants ou en réunion pour détendre l'atmosphère : posez une corde par terre et essayez de la pousser par un bout pour qu'elle avance en ligne droite. Elle se tord, elle s'accumule, elle part dans tous les sens sauf celui que vous voulez. Maintenant tirez sur le même bout. La corde se tend, suit votre main, avance proprement. C'est tout bête… et c'est pourtant exactement le débat qui oppose depuis 40 ans le flux poussé et le flux tiré dans nos supply chains.
Le MRP calcule un plan à un instant T - nomenclatures, délais, stocks de sécurité - et le pousse dans le système : « voici ce qu'il faut produire, dans cet ordre, à ces dates ». C'est carré, rationnel, ça a l'immense mérite d'exister depuis les années 70 et d'avoir structuré toute une profession. Le problème, tout planificateur le sait, c'est que la réalité de demain ne racontera pas la même histoire que le plan d'aujourd'hui. Une commande urgente arrive, une machine tombe en panne, un fournisseur livre en retard… et il faut repousser la corde, encore et encore, avec à chaque fois un peu plus de mou qui s'accumule en cours de route. C'est l'effet coup de fouet : une toute petite variation en bout de chaîne, et c'est le tsunami trois maillons plus haut.
Le flux tiré fonctionne à l'envers, et c'est bien pour ça qu'il fonctionne tout court : c'est la consommation réelle, à l'aval, qui tire l'approvisionnement à l'amont. Toyota l'a démontré depuis des décennies avec le kanban : on ne produit que ce qui a été consommé, on ne remplace que ce qui a disparu du stock. La corde est tendue en permanence par la vraie demande, pas par une prévision. Le DDMRP reprend exactement ce principe avec l'équation de flux net : on ne pilote pas sur un stock projeté - une hypothèse, une fiction - mais sur ce qui est réellement disponible, engagé et consommé, aujourd'hui.
Alors pourquoi ne pas généraliser le flux tiré à toute la chaîne, du client final jusqu'au minerai d’origine ? Parce qu'une corde, ça a une longueur. Et plus elle est longue, plus tirer dessus depuis un seul bout devient inefficace : le signal s'étire, se dilue, arrive avec un temps de retard tel qu'il ne veut plus dire grand-chose à l'autre extrémité. Demandez à un avionneur de tirer sa demande de titane brut directement depuis la livraison d'un A320 : le délai cumulé se compte en années. Aucun kanban physique ne survit à ça.
C'est là qu'entre en scène le mouflage - ce système de poulies qu'utilisent les grutiers et les marins pour démultiplier une force et la faire changer de direction sans jamais la « pousser ». Une poulie ne pousse rien : elle relaie une traction, elle la redirige, et surtout elle absorbe localement les à-coups avant de les retransmettre plus loin, lissés. C'est ce que font les points de découplage en Demand Driven.
Mais il y a une deuxième famille de poulies, tout aussi utile : celles qu'on appelle des tendeurs - le galet tendeur d'une courroie, d'une chaîne de vélo, d'un tapis roulant. Leur rôle n'est pas de rediriger la traction mais de la réguler en permanence : quand la longueur de corde disponible varie, le tendeur avance ou recule, tout seul, pour que la tension reste constante - ni trop tendue, ni trop molle. C'est aussi ce que fait un buffer DDMRP : une boucle de régulation qui absorbe en continu les variations de consommation et de délai, et qui remonte ou redescend dans ses zones (rouge, jaune, verte) pour maintenir la bonne tension sur le flux, sans que personne n'ait à intervenir à chaque à-coup.
Un point de découplage, avec son buffer, joue le rôle de la poulie : il relaie le signal de traction de la demande vers l'amont, mais il ne transmet jamais brutalement la variabilité qu'il vient d'encaisser. La zone rouge absorbe l'aléa, la zone jaune couvre la demande sur le délai découplé, la zone verte régule la fréquence et la taille des ordres. Résultat : chaque maillon tire véritablement sur son propre tronçon de corde, court et maîtrisé - son délai découplé - sans avoir à supporter le délai cumulé de toute la chaîne, ni à répercuter chez son fournisseur le moindre soubresaut du client final. On a démultiplié la traction en la relayant, exactement comme un palan démultiplie l'effort d'un seul bras pour soulever une charge qu'aucune main ne pourrait tirer directement.
C'est ce que fait le DDOM à l'échelle d'une chaîne end-to-end : positionner les bonnes poulies (les points de découplage), aux bons endroits, avec les bons buffers - de stock, de temps ou de capacité selon le cas - pour que chaque segment reste tirable, et que la traction se propage sans jamais dégénérer en poussée aveugle. Sur les tronçons trop longs, trop incertains ou trop capacitaires pour être pilotés en direct - un carnet de commandes aéronautique, un composant à cadence goulot - on garde une logique de programmation, un cadencement type Drum-Buffer-Rope, mais toujours synchronisé sur le rythme réel de consommation du goulot, jamais sur un plan poussé depuis le sommet.
Voilà pourquoi je me méfie autant des débats binaires « flux tiré contre flux poussé » que des promesses de logiciels qui prétendent tout piloter par un seul plan optimal. Le bon sens du terrain, c'est de reconnaître qu'aucune chaîne de valeur réelle n'est une corde unique, tendue d'un seul bloc du fournisseur de rang 5 jusqu'au client final. C'est un système de tronçons reliés par des poulies bien positionnées, chacune capable d'encaisser sa part de variabilité sans la refiler telle quelle au maillon suivant.
Le Demand Driven ne renie ni le MRP ni le Lean : il les orchestre, il installe les bonnes poulies aux bons endroits du flux, et il accepte que sur certains segments on continue à programmer - mais jamais à pousser aveuglément. Il faut juste accepter de lâcher la corde là où elle doit être tirée, et d'installer un mouflage là où elle est trop longue pour l'être d'un seul geste.