🏭 Planificateur d'atelier — Recuit simulé en direct
Observez un véritable recuit simulé rechercher des plannings d'atelier sur un diagramme de Gantt en direct, échappant aux minima locaux grâce à des échanges aléatoires contrôlés à mesure que la durée totale diminue vers l'optimum.
À propos de cette simulation
Cette simulation exécute une véritable recherche par recuit simulé sur des plannings d'atelier pour une usine synthétique : 6 tâches, chacune une séquence fixe d'opérations sur 5 machines, doivent être séquencées de sorte que chaque machine exécute une opération à la fois et que les opérations de chaque tâche se terminent dans l'ordre. À chaque itération, l'algorithme propose un planning voisin aléatoire — un échange adjacent de deux opérations mises en file sur une machine — le simule vers l'avant avec une véritable logique à événements discrets pour obtenir sa durée totale exacte, puis l'accepte ou le rejette à l'aide du véritable critère de Metropolis, exp(−Δ/T), tandis qu'un programme de refroidissement réduit la température T avec le temps.
🔬 Ce que ça montre
Un diagramme de Gantt en direct (machines en lignes, opérations colorées par tâche) se redessine à chaque itération à mesure que le planning actuel change. Un second panneau trace la durée totale brute actuelle par rapport à l'itération — y compris les petits sauts vers le haut dus aux mouvements dégradants acceptés qui permettent à la recherche d'échapper aux minima locaux — aux côtés de la meilleure durée totale trouvée jusqu'ici, qui ne fait que s'améliorer, et de la courbe de température à mesure qu'elle refroidit.
🎮 Comment l'utiliser
Réglez la température initiale (50–2000), le taux de refroidissement (0,98–0,9995 par itération) et les itérations exécutées par image d'animation, puis appuyez sur Exécuter pour laisser le recuit rechercher en continu, ou Étape pour avancer par lot fixe en pause. Réinitialiser relance la recherche sur le même problème à 30 opérations à partir d'un planning simple par ordre de priorité ; Rebrasser génère une toute nouvelle instance aléatoire d'atelier. Cliquez sur n'importe quelle barre du diagramme de Gantt pour inspecter la tâche, la machine, l'heure de début/fin et la durée de cette opération.
💡 Le saviez-vous ?
La planification d'atelier est NP-difficile : même des instances de taille modeste ont bien trop d'ordonnancements d'opérations possibles pour être vérifiés exhaustivement. Le recuit simulé ne garantit pas le véritable optimum, mais en acceptant occasionnellement un planning dégradé — bien plus souvent quand c'est « chaud », presque jamais une fois « froid » — il trouve de façon fiable des plannings proches de l'optimal bien plus rapidement que la force brute, ce qui explique pourquoi la même idée est utilisée dans les véritables logiciels de planification d'usine, de conception de circuits et de tournées de véhicules.
Questions fréquentes
Qu'est-ce que le recuit simulé ?
Le recuit simulé est une métaheuristique d'optimisation combinatoire inspirée du procédé métallurgique consistant à chauffer puis refroidir lentement un matériau pour réduire les défauts. L'algorithme maintient une solution candidate, propose à répétition un petit changement aléatoire (un voisin), et décide de l'accepter ou non : les mouvements améliorants sont toujours acceptés, tandis que les mouvements dégradants sont acceptés avec une probabilité exp(−Δ/T), où Δ est l'ampleur de la dégradation du candidat et T la température actuelle. Un programme de refroidissement abaisse progressivement T, de sorte que la recherche accepte de nombreux mouvements dégradants au début (favorisant l'exploration et l'échappement aux minima locaux) et presque aucun à la fin (favorisant la convergence vers un fort optimum local).
Comment un planning d'atelier est-il représenté et évalué ici ?
Chaque tâche est une séquence fixe d'opérations qui doivent s'exécuter sur des machines spécifiques dans un ordre spécifique ; un planning est choisi en sélectionnant un ordre pour les opérations mises en file sur chaque machine. Étant donné à la fois l'ordre des tâches et l'ordre des machines, le véritable temps de fin de chaque opération est calculé par une simulation à événements discrets : une opération ne peut démarrer qu'une fois l'opération précédente de sa tâche terminée et une fois la machine dont elle a besoin libérée de toute opération mise en file auparavant. La durée totale globale est le temps de fin de la toute dernière opération sur toutes les machines.
Pourquoi certains plannings proposés sont-ils rejetés d'emblée ?
Échanger deux opérations adjacentes sur une machine peut, dans de rares cas, créer un véritable blocage de planification : l'ordre machine de l'opération A exige qu'elle s'exécute après B, tandis que l'ordre tâche de B exige qu'elle s'exécute après A. Ce planning candidat n'a pas de temps de fin valide (un cycle non résolu dans le graphe de précédence), il est donc traité comme ayant une durée totale infinie et est toujours rejeté par le critère de Metropolis, quelle que soit la température.
Pourquoi la courbe de durée totale brute monte-t-elle parfois ?
Ces sauts vers le haut sont des mouvements dégradants acceptés — tout l'intérêt du recuit simulé. Si la recherche n'acceptait jamais que des améliorations, elle se comporterait comme une simple escalade de colline et pourrait rester bloquée définitivement dans le premier minimum local atteint. En tolérant certains plannings dégradés, surtout tôt quand la température est élevée, la recherche peut traverser une zone défavorable et trouver un meilleur bassin de l'autre côté ; la courbe de la meilleure valeur jusqu'ici n'enregistre que de véritables améliorations, elle ne monte donc jamais.
Le calcul de la durée totale est-il exact ?
Oui. Étant donné un planning complet (ordre des tâches plus l'ordre des machines choisi), l'heure de début et de fin de chaque opération est calculée en triant topologiquement le graphe de précédence combiné et en propageant les heures de début au plus tôt vers l'avant — la même approche de simulation vers l'avant utilisée dans les véritables systèmes de planification de production. Il n'y a ni raccourci ni score fabriqué : le nombre affiché est le véritable temps de fin de la véritable dernière opération sous ce planning exact.
Un véritable recuit simulé sur une instance d'atelier à 6 tâches et 5 machines : voisins par échange adjacent, évaluation exacte de la durée totale par événements discrets avec détection de cycle, le critère d'acceptation de Metropolis et un programme de refroidissement géométrique, visualisés sur un diagramme de Gantt CanvasTexture en direct et un graphique d'itération sous une caméra Three.js orthographique.
3D · Three.js / WebGL renderer · 60 FPS target · runs fully client-side, no install