Votre projet de conception de réseau vient d'identifier 4,2 M$ d'économies annuelles. Le modèle s'est exécuté sans problème. Les résultats sont convaincants. La direction est prête à aller de l'avant.
Puis, quelqu'un décide de valider le scénario de référence. Les trajets les plus utilisés ont été évalués avec des tarifs de chargement partiel (LTL), alors que, dans la réalité, ils sont expédiés en chargement complet (FTL). Résultat : les coûts actuels du réseau sont en fait 18 % plus bas que ceux utilisés par le modèle. Comme les économies sont calculées à partir d’un scénario de référence surestimé, il gonfle inévitablement les gains potentiels. Les économies prévues passent alors de 4,2 M$ à 2,1 M$. La moitié des économies prévues disparaît. Pourtant, une seule donnée d'entrée a changé.
C'est avec cet exemple que les consultants en simulation de SimWell, Jean-Daniel Mathieu et Ershad Jahagirdar, ont ouvert leur conférence à anyLogistix Conference 2026. Après des années à accompagner des entreprises dans leurs projets de conception et d'optimisation de réseaux, leur constat est clair : « La plupart des projets n'échouent pas parce que les calculs sont mauvais. »
Ils échouent bien avant d'en arriver là.
Au début de chaque mandat, l'équipe de Jean-Daniel Mathieu pose toujours la même question : Sommes-nous en train de construire un modèle ou de répondre à une décision d'affaires?
La nuance est importante. Construire un modèle est un objectif technique. Répondre à une question d'affaires, c'est aider une organisation à prendre une décision. Lorsqu'un projet est lancé dans le seul but de développer un modèle, il prend souvent plus de temps, coûte plus cher et peine à susciter la confiance nécessaire pour que les résultats soient réellement utilisés.
À l'inverse, lorsqu'on commence par identifier les décisions à soutenir, il devient beaucoup plus facile d'établir les objectifs du projet, de choisir les bons scénarios et de déterminer le niveau de précision réellement nécessaire. Les décideurs demeurent impliqués tout au long du processus, ce qui favorise leur confiance envers les résultats.
Tous les facteurs d'échec présentés dans cette conférence découlent du fait d'aborder le problème à l'envers. Le scénario de référence ne reflète pas la réalité. Les problèmes de données sont découverts trop tard. La logique de transport ne correspond pas aux opérations réelles. Les unités de mesure ou les tarifs sont mal interprétés. Le modèle répond à une question que personne ne se pose. Les scénarios sont exécutés… mais aucune décision n'en découle.
Ce qui est frappant, c'est ce qui n'apparaît pas dans cette liste : les solveurs, les algorithmes ou la puissance informatique n'en font pas partie.
Chez SimWell, près du quart d'un projet est consacré à une étape qui précède toute modélisation. L'objectif n'est pas encore de construire un modèle. Il s'agit d'abord de comprendre le problème, les données et le fonctionnement réel de la chaîne d'approvisionnement.
Pour y arriver, Ershad Jahagirdar privilégie une approche étonnamment simple : le jumeau papier. Réunissez les parties prenantes autour d'une table. Prenez une feuille et un crayon. Dessinez le réseau : fournisseurs, usines, centres de distribution et clients. Ajoutez ensuite les liens entre eux, les flux, puis les informations importantes comme les coûts, les capacités et les délais.
Comme il le résume lui-même :
« Si vous êtes incapable de dessiner votre chaîne d'approvisionnement sur une feuille de papier, vous ne serez pas capable d'en construire un modèle. »
Cet exercice remplit deux objectifs. D'abord, il fait ressortir le vocabulaire propre à l'organisation. Les centres de tri, les stations satellites, les dark stores… autant de termes qui ne figurent pas dans les schémas théoriques, mais qui reflètent la réalité des opérations et la façon dont le réseau fonctionne au quotidien. Ensuite, il permet d'établir une compréhension commune avant d'entreprendre le travail de modélisation. Un diagramme de Sankey représentant les expéditions des douze derniers mois remplit le même rôle pour les flux. En moins d'une heure, il devient possible de visualiser les mouvements de produits à travers le réseau, mais aussi de mettre en évidence les incohérences dans les données. Par exemple, lorsque les volumes entrants ne correspondent pas aux volumes sortants parce qu'une partie de l'inventaire provient d'une période précédente.
À cette étape, un crayon, une feuille de papier et les bonnes personnes autour de la table valent bien plus qu'un logiciel. Le modèle est construit à partir de cette représentation commune de la chaîne d'approvisionnement. En dessinant ensemble le réseau et en s'entendant sur son fonctionnement, les équipes commencent déjà à développer la confiance qui sera essentielle lorsque viendra le temps d'interpréter les résultats.
Dans ce type de projet, près de 30 % des efforts sont consacrés à la modélisation du transport.
Un modèle de conception de réseau compare les coûts de votre réseau actuel à ceux d'un réseau repensé. Pour les trajets déjà en activité, les coûts de transport sont connus puisqu'ils reposent sur des données réelles. En revanche, un réseau optimisé introduit souvent de nouveaux trajets qui n'ont jamais été utilisés. Leurs coûts doivent donc être estimés. Les économies projetées correspondent à l'écart entre ces deux scénarios : l'un est basé sur des données réelles, l'autre sur des estimations. La crédibilité de l'analyse repose donc directement sur la qualité de ces estimations.
Pour obtenir des résultats fiables, l'équipe recommande trois bonnes pratiques.
D'abord, évitez d'utiliser un coût moyen par kilomètre pour l'ensemble des trajets. Les coûts de transport évoluent en fonction de la distance; une moyenne unique risque donc de fausser les résultats.
Ensuite, pour le transport en chargement complet (FTL), privilégiez des modèles de régression ou des tarifs de référence établis selon le type de véhicule et la région. Dans ce contexte, un simple coût moyen au kilomètre ne reflète pas adéquatement la réalité.
Enfin, validez les unités de mesure. Un modèle qui exprime la capacité des véhicules en mètres cubes alors que les produits sont comptabilisés en palettes produira des calculs de chargement inexacts, avec des répercussions sur l'ensemble des résultats.
Comme le résume Ershad Jahagirdar : « N'essayez pas de simplifier la réalité à tout prix. »
Les économies estimées ne sont fiables que si la logique de transport sur laquelle elles reposent l'est tout autant.
Une dernière bonne pratique consiste à éviter d'imposer des contraintes rigides dès les premières étapes de la modélisation.
Une contrainte rigide est une règle que le modèle doit respecter en tout temps, par exemple satisfaire l'ensemble de la demande ou respecter toutes les limites de capacité. Or, au début d'un projet, les données sont rarement parfaites. Elles contiennent souvent des incohérences ou des informations contradictoires. Si le modèle repose uniquement sur des contraintes rigides, il ne pourra tout simplement pas trouver de solution. Il retournera un résultat infaisable, sans indiquer clairement quelle donnée est à l'origine du problème. Les équipes peuvent alors passer des semaines à tenter de comprendre ce qui a fait échouer le modèle.
L'approche proposée consiste plutôt à commencer avec des contraintes souples. Au lieu d'interdire certaines situations, on leur attribue une pénalité. Le modèle peut ainsi s'exécuter malgré les incohérences, et ces pénalités deviennent un outil de diagnostic. Par exemple, si 10 % de la demande d'un client ne peut être satisfaite, il devient possible d'en chercher la cause. Il peut s'agir d'un trajet manquant, d'une erreur dans les capacités ou encore d'une restriction sur les flux de produits qui n'a jamais été documentée. Chaque exécution permet ainsi de mettre au jour un nouveau problème de données. À mesure que les données sont validées, les contraintes peuvent être resserrées, une à la fois.
En réalité, les premières exécutions du modèle servent d'abord à valider les données. Les réponses viendront ensuite.
Jean-Daniel Mathieu et Ershad Jahagirdar ont conçu cette présentation pour les professionnels qui développent des modèles. Mais les pièges qu'ils décrivent ne concernent pas uniquement les modélisateurs. Ils peuvent tous être évités. Pour les dirigeants qui envisagent un projet de conception de réseau, leurs recommandations se transforment en une liste de vérification toute simple : six questions à se poser avant d'aller de l'avant.
Si une proposition ne permet pas de répondre à ces questions, aussi performant soit-il, aucun modèle ne pourra compenser.
Jean-Daniel Mathieu et Ershad Jahagirdar sont consultants en simulation chez SimWell. Leur présentation complète, « Best Practices – Supply Chain Design and Optimization Projects », donnée dans le cadre de la Conférence anyLogistix 2026, est disponible sur ici
Téléchargez la présentation ici (disponible en anglais)