5. Organisation de notre projet
Le projet a été structuré en plusieurs phases successives, permettant une progression logique de la découverte du logiciel jusqu’à la conception finale d’un outil pédagogique exploitable :
5.1 Prise en main du logiciel FlexSim
5.1.1. Les bases
Ce projet marquait notre toute première expérience avec un logiciel de modélisation 3D dédié à la logistique et à la gestion des flux. Avant de pouvoir construire un modèle cohérent, il nous a donc fallu passer par une phase d’apprentissage essentielle. Nous avons pris le temps de découvrir l’environnement de FlexSim, de comprendre sa logique de fonctionnement, d’explorer les bibliothèques d’objets et d’apprendre à connecter les différents éléments pour simuler un flux de production réaliste. La figure 1 illustre un premier exemple simple réalisé lors de notre prise en main du logiciel : l’acheminement de cartons depuis une source jusqu’à une zone de stockage. Ce petit exercice nous a permis de comprendre les bases du fonctionnement de FlexSim. Nous avons ainsi appris à créer des entités, à les faire circuler à travers différents postes, à les transformer (par exemple simuler une opération de fabrication ou d’emballage), puis à les stocker dans un espace défini.
Figure 1
À la suite de cette première exploration, nous avons approfondi notre utilisation de FlexSim en découvrant l’outil Dashboard. Il joue un rôle central dans la phase d’optimisation, car il permet de visualiser en temps réel des indicateurs clés tels que les taux de remplissage, les temps d’attente ou les niveaux de stock.
Sur la figure 2, le graphique généré par le Dashboard illustre, par exemple, la quantité de boîtes stockées dans les files d’attente Queue 1 et Queue 3. Ce type de représentation nous a permis de mieux comprendre les déséquilibres dans les flux et d’identifier les zones de congestion ou de surstockage, ouvrant ainsi la voie à des ajustements ciblés pour améliorer la fluidité du système.
Figure 2
Nous avons ensuite intégré un graphique supplémentaire visant à mesurer le temps de passage d’un carton à travers plusieurs zones clés du système, notamment Queue2, Conveyor1 et Conveyor2 (figure 3). Ce type d’indicateur temporel permet d’analyser plus finement les performances internes du processus. L’ajout de ce graphique illustre bien l’étendue des possibilités offertes par FlexSim en matière de collecte et d’analyse de données. En personnalisant les indicateurs suivis, il devient possible de surveiller précisément chaque étape du flux, de repérer les lenteurs éventuelles, et ainsi d’appuyer les décisions d’optimisation sur des données objectives et visuelles.
figure 3
5.1.2. Les fluides
Nous avons ensuite appris à utiliser les ressources fluides pour représenter des quantités continues (litres, kilogrammes, etc.) (figure 4). Cette partie du logiciel est plus complexe, notamment en raison du manque de tutoriels et du nombre important de paramètres à configurer pour chaque machine.
figure 4
Par exemple, figure 5, l’interface du FluidConveyor montre un nombre important de paramètres. Faute de documentation claire, nous avons dû les tester un par un pour comprendre le fonctionnement du système.
figure 5
La figure 6 illustre un système intéressant qui combine objets discrets et ressources fluides. Deux machines rendent cela possible : ItemToFluid et FluidToItem. Ici, l’opérateur transporte un carton, qui est ensuite transformé automatiquement en cinq cylindres fluides.
figure 6
Ci-dessous, les interfaces de ces deux machines.
ItemToFluid (figure 7) :
Supposons qu’un carton corresponde à 15 kg de liquide. Dans l’onglet Input Ports, il suffit de définir la valeur de Fluid per Discrete Unit à 15. Ainsi, chaque carton entrant sera automatiquement converti en 15 kg de fluide.
figure 7
FluidToItem (figure 8) :
Pour transformer les 15 kg de fluide en 5 barils, il faut que chaque baril représente 3 kg. Dans l’onglet FlowItem Output, on règle la valeur de Fluid per Discrete Unit à 3. Le système générera alors un baril pour chaque tranche de 3 kg de liquide.
figure 8
Figure 9 illustre un système de mélange de fluides. Cette configuration vise à mélanger 0,25 L de liquide 1 avec 0,75 L de liquide 2, puis à stocker le mélange obtenu. Pour cela, nous avons utilisé deux générateurs distincts, un mixeur, un FluidConveyor pour le transfert, et un FluidTank pour le stockage final.
figure 9
L’interface du Mixer (figure 10) est relativement simple à prendre en main. Comme on souhaite mélanger deux liquides, on commence par définir “Number of Ingredients” à 2, puis on clique sur Update : deux lignes apparaissent.
figure 10
Chaque ligne comporte les paramètres suivants :
| Ingrédient | Port | Amount | Step |
| nom du liquide utilisé | numéro de l’entrée (1 pour le liquide 1, 2 pour le liquide 2) | quantité souhaitée pour chaque liquide | étape à laquelle le liquide est versé |
On configure dans la figure 10 les étapes (steps) :
| Step | Description | Delay | |
| la première pour verser le liquide 1, la seconde pour le liquide 2 | permet de nommer l’étape | temps d’attente après la fin de l’étape |
5.1.3. Logistique
La partie logistique a commencée part le stockage. Point assez compliqué mais faisable principalement grâce aux vidéos sur YouTube. Sur une étagère, il est possible de trier les objets en allant dans l’onglet “Triggers” de la source, on peut donner un nom et une valeur à l’objet généré. Ensuite, dans le rack on va assigner les emplacements par nom et par valeur correspondant à ceux de nos objets.
Un autre point important concerne la partie déplacement des opérateurs. Avec l’aide des “NetworkNodes” , “TravelNetworks” et “Traffic Control” on peut créer des chemins à suivre. Sans cela, les opérateurs font juste des lignes droites vers leur destination. Le feu de circulation quand à lui sert à imposer un nombre de limite d’utilisateurs par chemin. En d’autres termes, entre deux points de contrôle le feu empêche les autres opérateurs de passer tant que la voie n’est pas libre.
Un aspect similaire que celui vu au dessus est à propos des zones de contrôle. La différence avec le point expliqué précédemment est qu’un opérateur ne peut pas passer dans la zone de contrôle tant que quelqu’un d’autre s’y trouve. Ce cas est utile quand deux chemins se croisent.
Le point ultime de la logistique se base sur le “ProcessFlow“. Son objectif, optimiser et améliorer les possibilités des items.
Nous l’avons utilisé deux fois dans notre projet :
- Premièrement, le façonnage de la pâte. Le but était de définir une quantité moyenne à créer en production continue car avant cela, les ingrédients arrivaient par vague ce qui n’était pas très réaliste. D’autre part, dès que la production atteint le volume souhaité, il est possible d’arrêter la machine pendant une durée déterminée. Par exemple on peut faire approximativement 100 pizzas puis arrêter la production 30 minutes en répétant cette opération autant de fois que nécessaire.
- Deuxièmement, la mise en carton. Durant le conditionnement, les opérateurs reçoivent des boîtes de pizza envoyées équitablement entre les deux postes. De plus si l’un des deux est trop lent, son tapis sera plein. Alors le “Process Flow” permet de rediriger les cartons sur la voie non remplie.
Grâce à l’ensemble des outils explorés, nous étions désormais prêts à lancer la simulation complète de notre pizzeria. Les fonctions essentielles — mélanger, transformer, transporter et stocker — avaient été comprises et maîtrisées. Nous disposions donc des compétences nécessaires pour modéliser un processus de fabrication de pizzas cohérent et fonctionnel.