Simulation Monte Carlo pour processus : ce qu'elle peut faire et quand elle ment

Inhaltsverzeichnis+

«Monte Carlo» sonne comme plus que ce que c’est, et c’est bien ainsi, car la méthode est agréablement simple. C’est jeter les dés avec méthode.

La méthode en quatre phrases

Vous n’indiquez pas qu’une étape dure 10 minutes, mais qu’elle dure de 5 à 20 minutes, le plus souvent 8. L’ordinateur laisse alors une instance traverser le processus et tire au sort pour chaque étape une durée dans cette fourchette. Il répète cela pour une journée entière d’instances, des centaines de fois. À la fin il n’a pas une seule durée de traitement, mais des centaines, et en tire une distribution.

C’est tout. Pas de modèle de l’univers, pas d’intelligence artificielle. Juste le refus de faire comme si le monde était exact.

Pourquoi les processus en ont besoin

L’objection évidente est : si je connais les moyennes, pourquoi le calcul avec les moyennes ne suffit-il pas ?

Parce que les processus sont non linéaires. Deux exemples qui le montrent immédiatement :

Files d’attente. Une étape à 85 % d’utilisation génère un temps d’attente équivalant à 5,7 fois son temps de traitement ; à 95 % c’est 19 fois. Si votre taux d’utilisation fluctue entre 70 % et 100 % dans la journée, la moyenne de ces temps d’attente n’est pas le temps d’attente au taux d’utilisation moyen. C’est nettement plus. (Le calcul est expliqué dans Calculer l’engorgement.)

Le chemin le plus long gagne. Si deux branches s’exécutent en parallèle et doivent toutes deux être terminées, la durée totale est le maximum des deux, et l’espérance d’un maximum est plus grande que le maximum des espérances. Un planning de projet qui calcule avec les moyennes est donc systématiquement trop optimiste.

Les deux ensemble forment l’inégalité de Jensen, connue sous le nom de «Flaw of Averages». Monte Carlo l’évite en ne moyennant pas d’emblée, mais en calculant puis en analysant.

Ce que vous devez saisir

La lacune la plus fréquente est la dernière. Sans calendrier, une instance arrivant le vendredi à 16:50 attend dix minutes. Avec calendrier, elle attend jusqu’au lundi.

Combien d’exécutions ?

La question revient toujours, et la réponse est insatisfaisante : autant que nécessaire jusqu’à ce que le résultat ne bouge plus.

Empiriquement :

• 100 exécutions suffisent pour voir quelle étape est le goulot. L’ordre est stable bien avant que les chiffres le soient.
• 500 à 1000 exécutions sont nécessaires pour des percentiles fiables, en particulier P90, qui dépend naturellement d’événements rares.
• Plus de 5000 n’apporte presque jamais d’information supplémentaire pour des processus de cette taille, seulement du temps de calcul.

Vous pouvez le vérifier : lancez le même modèle deux fois avec une graine différente. Si les résultats diffèrent sensiblement, il y a eu trop peu d’exécutions.

Quelle distribution ?

Ici beaucoup commettent la deuxième erreur. Les durées de traitement sont rarement symétriques : une instance ne peut pas être plus rapide que «très rapide», mais peut être arbitrairement lente. La distribution a donc une longue queue à droite.

• Distribution triangulaire (minimum, valeur la plus probable, maximum) suffit pour la plupart des processus administratifs et a l’avantage que ces trois valeurs peuvent être obtenues en atelier.
• Distribution lognormale représente mieux la longue queue et est le bon choix quand les valeurs aberrantes dominent le processus.
• Distribution normale est presque toujours incorrecte. Elle est symétrique et permet des durées négatives.

Règle générale : si vous n’êtes pas sûr, prenez une distribution triangulaire et affichez le résultat comme une fourchette. Le choix de la distribution déplace les percentiles. Il ne change presque jamais quelle étape est le goulot.

Les quatre erreurs qui rendent le résultat inutile

1. Trop peu d’exécutions. Visible si deux exécutions donnent des réponses différentes. Vérifiable en deux minutes.

2. Distribution symétrique pour des durées asymétriques. Cela fait que P90 est nettement trop bas. Justement la valeur sur laquelle vous devez planifier.

3. Dépendances ignorées. Si un cas compliqué prend plus de temps à chaque étape, les durées sont corrélées. Un modèle qui tire chaque durée indépendamment efface cet effet et sous-estime la variance. Solution : séparer les types d’instance et les modéliser séparément, plutôt que d’étendre une seule distribution large à tout.

4. Phase de montée en charge incluse dans l’analyse. Au début d’une exécution le système est vide, il n’y a pas de files et les temps de traitement sont courts. Inclure cette phase dilue le résultat avec un état qui n’existe jamais en exploitation.

Comment lire le résultat

Une analyse Monte Carlo ne fournit pas un chiffre, mais au moins trois :

• P10 : le cas favorable. Aussi bien que cela ira environ un cas sur dix.
• P50 : la médiane. La moitié des cas est en dessous.
• P90 : le cas défavorable. C’est avec cela que vous planifiez la capacité, pas avec la moyenne.

Qui transforme cela en un seul chiffre dans une offre a fait tout ce travail pour rien. L’écart est le résultat. Comment le lire et pourquoi P50 peut induire en erreur est expliqué dans Bien lire P10, P50, P90.

Ce que Monte Carlo ne fait pas

Il n’améliore pas de mauvaises saisies. Si vos volumes sont estimés, les résultats le sont aussi. Mais avec des décimales. C’est le vrai danger de la méthode : elle génère une confiance que les données ne justifient pas.

C’est pourquoi chaque analyse doit documenter trois éléments : quelles entrées sont mesurées et lesquelles sont estimées, combien d’exécutions ont été faites, et quelle graine de départ a été utilisée. Si cela manque, le résultat n’est pas vérifiable. Et un résultat non vérifiable ne vaut rien en cas de doute.

FlowVisual calcule exactement ainsi et imprime la graine et le nombre d’exécutions dans le manuel. Pas par pédanterie, mais parce qu’un chiffre qu’on ne peut pas reproduire n’a rien à faire dans une note de décision.