Limites et biais d’une simulation de flux

Mis à jour le 4 sources citées

Une simulation ne se trompe pas seulement par ses calculs : elle se trompe par ses entrées, son protocole et son interprétation. La validation du programme ne protège de rien dans ces trois cas. Les biais qui suivent survivent à un modèle techniquement irréprochable, et quelques-uns s’aggravent à mesure que le rendu devient convaincant.

Vérifier n’est pas valider

Quatre activités sont régulièrement confondues, alors qu’elles répondent à des questions différentes.

Activité Question posée Preuve attendue
Vérification Le programme fait-il ce que je crois qu’il fait ? Relecture du code, cas tests, invariants, loi de Little
Validation Le modèle représente-t-il le système réel ? Confrontation à des indicateurs observés, écarts acceptés
Calibration Quelles valeurs de paramètres reproduisent le passé ? Ajustement documenté, jeu de données réservé
Analyse de sensibilité La conclusion tient-elle si les entrées changent ? Classement des entrées influentes, scénarios contrastés

Un modèle peut être vérifié sans être validé : il tourne correctement et décrit une organisation qui n’existe pas. Il peut aussi être validé sur un mois et se révéler faux le mois suivant, parce que la gamme a changé. Les deux contrôles sont nécessaires, aucun ne remplace l’autre.

Huit biais qui survivent à la validation

Biais Mécanisme Parade opérationnelle
Confirmation Les hypothèses sont ajustées jusqu’à retrouver l’intuition initiale Hypothèses figées et datées avant exécution ; scénarios contradictoires
Ancrage théorique Les durées viennent de standards jamais mesurés dans l’atelier concerné Relevé daté, périmètre de mesure, valeurs extrêmes conservées
Précision illusoire Trois décimales publiées sans intervalle de confiance Nombre de réplications annoncé, intervalle pour chaque indicateur
Transitoire ignoré La période de chauffe est moyennée avec le régime établi Durée de chauffe déclarée, ou mesure séparée des premières heures
Événements rares absents Une panne trimestrielle ne sort pas d’une réplication d’une journée Horizon allongé ou événement injecté explicitement
Sur-ajustement de calibration Les paramètres sont réglés sur l’unique jeu de données disponible Jeu de validation réservé, jamais utilisé pour le réglage
Modèle périmé La gamme, l’implantation ou les effectifs ont changé depuis la construction Date de construction affichée, péremption déclarée, revue annuelle
Rendu 3D comme preuve L’animation rend crédible une hypothèse inventée Séparer communication et démonstration : la preuve est dans les chiffres

Ces biais ont un point commun : aucun n’est détecté par un test unitaire. Ils se traitent par le protocole — ce qui est écrit avant, ce qui est daté, ce qui est conservé — et non par un outil supplémentaire.

La sensibilité, seul contrôle qui porte sur la conclusion

Une conclusion de simulation est une comparaison entre scénarios. L’analyse de sensibilité teste cette comparaison : elle mesure de combien le résultat bouge quand les entrées bougent, et lesquelles comptent.

La méthode locale — faire varier un paramètre à la fois, toutes choses égales — est la plus répandue et la plus trompeuse. Elle ne voit pas les interactions : deux hypothèses peuvent se compenser, une durée de traitement plus longue étant masquée par un taux de panne plus faible. Les méthodes globales font varier les entrées ensemble et attribuent la variabilité du résultat à chaque entrée ; la théorie est documentée, et les outils existent.

Deux usages suffisent à une revue de projet :

Reconnaître une étude fragile en dix minutes

Six questions, à poser dans cet ordre. Une étude solide y répond sans documents supplémentaires.

  1. Les hypothèses sont-elles datées et antérieures aux résultats ? Une note de cadrage signée avant l’exécution vaut mieux que n’importe quelle déclaration d’intention.
  2. D’où viennent les durées, et sur quelle période ? « Temps standard » sans relevé n’est pas une source. La définition d’un modèle de simulation exige des entrées traçables, pas des entrées plausibles.
  3. Combien de réplications, et quel intervalle pour l’indicateur principal ? Un chiffre unique est une anecdote, quel que soit le soin apporté au modèle.
  4. Quelle période de chauffe a été écartée ? Sur un système qui démarre vide, les premières heures ne représentent rien d’observable.
  5. Quels scénarios contredisent la conclusion, et ont-ils été exécutés ? Une étude qui ne teste que des variantes favorables est une justification.
  6. Le modèle est-il livré, avec ses conventions ? Un rapport seul ne se reprend pas ; il se croit. Les files d’attente et la loi de Little offrent d’ailleurs un moyen simple de recouper les ordres de grandeur annoncés.

Une étude qui échoue à la question 3 ou à la question 1 n’est pas réparable en aval : le défaut est dans le protocole, pas dans le modèle.

Ce que cette page ne contient pas

Aucune statistique sur le taux d’échec des projets de simulation : elle n’existe pas de manière comparable d’un périmètre à l’autre, et un chiffre cité sans définition d’« échec » serait plus nuisible qu’utile. Aucune donnée client non plus : cette page décrit des mécanismes, pas des performances.

La suite

Pour la vue d’ensemble des méthodes et du déroulé d’une étude, revenez à la page pilier sur la simulation de flux. Pour la construction d’un modèle conforme à ces exigences, la page sur la définition et le vocabulaire donne les quatre notions et les questions de cohérence.

Pour situer ce site et son éditeur, consultez l’accueil de simulation-de-flux.com.

Citer cette page

Simulation de flux — OPTIFLUX SAS. « Limites et biais d’une simulation de flux ». Mis à jour le 4 novembre 2026. https://www.simulation-de-flux.com/comprendre-la-simulation-de-flux/limites-et-biais/

Sources

Les liens externes sont fournis pour vérification. Les affirmations de cette page sont limitées à ce que ces documents établissent ; aucune donnée client n’y figure.