L'interaction entre les étapes explique pourquoi les règles de dispatching locales, et les outils construits dessus, échouent dans les hybrid flowshops

Le planning de chaque étape peut être défendable et la ligne peut quand même finir en retard. Le mélangeur fait tourner les jobs courts en premier, parce qu'ils libèrent le plus vite la file d'attente. La remplisseuse suit la même logique sur sa propre file. Le job critique du client attend derrière les jobs courts aux deux étapes, et personne n'a pris de mauvaise décision. Chaque décision locale était raisonnable. Le planning de production auquel la ligne aboutit ne l'est pas.

C'est le schéma dont les règles de dispatching locales ne peuvent pas s'échapper dans un hybrid flowshop. La règle n'est pas mauvaise dans son rôle. Elle ne peut simplement pas voir les étapes autour de celle qu'elle sert.

Ce que décide réellement une règle de dispatching

Une règle de dispatching — parfois appelée règle de priorité — répond à une seule question sur une seule file d'attente : quel job l'étape ou la machine prend-elle ensuite ? Elle peut utiliser le temps d'exécution le plus court, la date d'échéance la plus proche, l'ordre d'arrivée des jobs, ou l'une des variantes décrites dans la littérature. La littérature de recherche opérationnelle en avait déjà recensé plus d'une centaine en 1977, et la liste n'a cessé de s'allonger depuis.

Ce qui les rend utiles est aussi ce qui les limite. Une règle n'a besoin que de l'information visible sur la file qu'elle sert. Elle ne voit jamais l'encombrement en aval, la disponibilité de la matière en amont, ni quelle machine de l'étape suivante sera libre à l'arrivée d'un job. Pour une machine unique avec une seule file d'attente, c'est souvent suffisant. Pour une ligne d'étapes, ce ne l'est pas.

Le mécanisme : les étapes interagissent, et les décisions locales ne s'additionnent pas

Dans un flowshop, la sortie d'une étape est l'approvisionnement de l'étape suivante. La séquence dans laquelle les jobs quittent une étape détermine quand l'étape suivante les reçoit et quelle quantité de matière elle détient à chaque instant. Un hybrid flowshop ajoute un second couplage : chaque étape peut contenir plusieurs machines en parallèle, si bien que la ligne décide non seulement de la séquence, mais aussi de la machine sur laquelle chaque job tourne. Ces décisions ne sont pas indépendantes. Elles se transmettent des effets les unes aux autres.

La littérature sur les anomalies de flow shop le dit directement. Une analyse de 2020 par Panwalkar et Koulamas a montré que, dans un flow shop, réduire le temps d'exécution d'une seule opération, retirer un job, ou même retirer une machine peut aggraver le planning global. Les plannings qui interdisent qu'une machine reste inoccupée, qu'un job attende entre les étapes, ou qu'une étape retarde son démarrage rendent ces anomalies plus probables. Une modification locale propage son effet à travers les étapes voisines, si bien qu'améliorer une opération isolément n'est pas une démarche saine.

Un exemple concret montre l'effet. Deux étapes, l'une alimentant l'autre. L'étape en aval applique une règle du temps d'exécution le plus court, si bien qu'elle retire les jobs courts de sa file en premier. Un job long attend pendant que les jobs courts défilent. En amont, l'étape qui alimente continue de fournir ce que la file en aval vide, parce que c'est tout ce que sa propre règle peut voir. Le job long glisse plus tard à chaque étape, et tous les jobs derrière lui glissent aussi. Chaque étape fait exactement ce que sa règle dit. La ligne fait la mauvaise chose.

Le cadencement des changements de série montre la même interaction. Quand le temps de changement de série dépend de la séquence, une étape qui séquence ses jobs pour minimiser ses propres changements peut transmettre à l'étape suivante une séquence qui en ajoute là-bas. La première étape a gagné un temps qu'elle ne reverra jamais, et la seconde étape le paie. Optimiser le temps de changement de série d'une étape, ce n'est pas optimiser celui de la ligne.

Le coût : un outil qui ignore l'interaction hérite de l'aveuglement

Un outil d'ordonnancement construit sur des règles de dispatching locales n'échoue pas parce que ses règles sont grossières. Il échoue parce qu'il montre au planificateur la même vue locale de file d'attente et l'appelle un planning terminé. Le planificateur voit le planning de chaque étape, chacun défendable, et aucun endroit où le vrai problème de la ligne apparaît.

Ce que le planificateur ne voit pas, c'est ce que coûte l'interaction. Les étapes en aval sont affamées pendant qu'un job critique attend en amont. Les tampons grossissent parce que les étapes sont alimentées dans la séquence que leurs propres règles préfèrent, pas dans celle dont la ligne a besoin. Le temps de production total augmente insensiblement, et le planning est figé avant que le schéma ne devienne visible.

L'écart est mesurable. Dans une étude de 2020 portant sur un véritable hybrid flowshop à deux étapes avec changements de série dépendant de la séquence, une approche d'optimisation par simulation a produit de meilleurs plannings que les règles de dispatching standard que les usines font couramment tourner. Le résultat est spécifique au cas étudié, et aucun pourcentage général ne doit en être tiré. C'est la direction qui compte : sur un véritable hybrid flowshop, coordonner les décisions sur toute la ligne l'emporte sur décider chaque file localement.

Ce que change l'ordonnancement de toute la ligne

L'ordonnancement de toute la ligne fait l'inverse d'une règle de dispatching. Au lieu de répondre à une file à la fois, il décide ensemble la séquence de production, l'affectation des machines et le cadencement, et laisse une simulation de la route complète arbitrer le résultat. La simulation est la clé. Elle fait passer chaque job par ses étapes et voit les interactions que les règles ne voient pas : quand une étape en aval manque de matière, le planning montre une pause d'attente de matière au lieu de cacher le blocage dans une file d'allure défendable.

Cela change ce que le planificateur peut voir et faire. L'affamement en aval apparaît comme des pauses d'attente de matière sur le planning, si bien qu'il cesse d'être invisible. Le regroupement des changements de série sert désormais le temps de production total plutôt que le temps de préparation d'une seule étape. L'affectation des machines est coordonnée par étape, et dans un mode qui fixe la séquence de production, elle optimise quand même l'affectation à l'intérieur, si bien que les usines dont la séquence est opérationnellement fixe ne sont pas forcées de re-séquencer pour obtenir le second axe.

Ce n'est pas un optimiseur général d'usine. La vue de toute la ligne vit à l'intérieur d'un ensemble de contraintes modélisées : les étapes, les machines, les calendriers, les changements de série et les temps de transfert réellement saisis par l'usine. L'objectif unique est le temps de production total. Il ne pèse pas le coût contre le temps, il n'impose pas les dates d'échéance, et il ne modélise pas les routes qui convergent ou divergent. Dans cette ligne modélisée, les décisions sont prises ensemble, et les interactions entre étapes font partie de la décision.

À retenir

Une règle de dispatching locale est une bonne réponse à une file unique. Ce n'est pas une bonne réponse à une ligne, parce que dans un hybrid flowshop les étapes sont couplées, et qu'une décision locale de file ne peut pas voir le couplage. Les outils qui construisent leur planning à partir de ces règles héritent de cet aveuglement, et le coût apparaît comme de l'affamement, des tampons, et un temps de production total plus long.

Quand vous évaluez un outil d'ordonnancement, posez une question : voit-il toute la route, ou une étape à la fois ? S'il ordonnance chaque étape contre sa propre file, il a déjà pris la décision qui défait le planning. L'outil qui coordonne la séquence, les machines et le cadencement sur toute la ligne traite le problème réel de l'usine.