Simulation

Objectif

La simulation répond à une question d'une forme précise: si l'on procède ainsi, que se passe-t-il et de combien? Elle y répond avant toute construction ou modification, en chiffres, dans l'unité même où la décision se prend. Les autres méthodes de prototypage produisent quelque chose à regarder, une suite de vignettes ou une interface dessinée à la main, que la partie prenante commente. La simulation produit quelque chose à exécuter, dont la partie prenante lit les résultats.

Le BABOK décrit la technique en deux phrases, chacune portant une réserve qu'il faut garder telle quelle: la simulation sert à démontrer une solution ou des composants de solution, et elle peut mettre à l'épreuve des processus, des scénarios, des règles métier, des données et des entrées. La vocation de mesure est ancrée ailleurs, à un seul endroit: dans la tâche Mesurer la performance de la solution, où le BABOK écrit que le prototypage sert à simuler une solution nouvelle afin que des mesures de performance puissent être déterminées et collectées. C'est la seule place du référentiel où le prototypage est rattaché à la mesure. Le référentiel l'écrit du prototypage en général, par le verbe « simuler ». La seule méthode de la famille qui l'accomplit est celle-ci. Les deux ancrages disent des choses différentes qu'il vaut la peine de tenir séparées: l'un dit ce que la technique exerce, l'autre ce qu'elle rapporte.

Le livrable se compose de sept objets. Le modèle exécutable. La fiche de paramètres, qui porte pour chacun sa provenance: mesuré, ajusté ou supposé. Le procès-verbal de validation, qui confronte le modèle à une période dont les résultats réels sont connus et énonce la tolérance retenue. Les définitions de scénarios. Les résultats des runs, assortis de leurs intervalles. L'analyse de sensibilité, qui désigne le paramètre sur lequel la décision repose réellement. Et la note de décision, qui énonce le domaine de validité du résultat, c'est-à-dire les conditions sous lesquelles il a été établi et hors desquelles il cesse de valoir.

Ce que l'organisation achète à ce prix, c'est la possibilité de se tromper à vide. Une politique de relance, un palier tarifaire, un guichet supplémentaire, une règle d'acheminement: appliqués en vrai, ces changements coûtent leur mise en œuvre, leur retour en arrière et le tort causé entre-temps. Exécutés dans un modèle, ils coûtent une nuit de calcul. Le BABOK observe d'ailleurs, à propos de la définition de l'état futur, que le prototypage pourrait aussi aider à déterminer la valeur potentielle d'une option; la simulation est celle des méthodes qui la détermine en la mesurant.

Usage

Quand l'utiliser

• Changement de règle à conséquence dénombrable: relances, paliers tarifaires, critères d'éligibilité, règles d'acheminement.
• Question de capacité ou de débit: file d'attente, temps d'attente, taux d'occupation, un guichet de plus ou de moins.
• Options qu'on ne peut pas essayer en parallèle: deux politiques de relance sur les mêmes clients, impossible en réel.
• Changement coûteux ou difficile à défaire: le run est le moyen le moins cher de se tromper.
• Mesures de performance attendues avant la mise en service: la valeur promise se chiffre pendant qu'on peut encore renoncer.
• Un modèle de processus existe déjà, le déclencheur le plus fréquent: le rendre exécutable coûte peu.
• Comportement d'ensemble contre-intuitif: un goulot qui se déplace, une file qui explose au-delà d'un seuil.

Quand ne pas l'utiliser

• La décision coûte moins cher que le modèle: faire le changement et mesurer le réel, par un pilote, un déploiement limité ou un test A/B.
• La question porte sur l'apparence de la solution: rien à exécuter, prendre le prototypage papier ou le storyboarding.

Description

Deux axes indépendants

Le BABOK classe les prototypes sur deux éléments distincts. L'approche dit ce que le prototype devient: on le jette, ou on le fait grandir jusqu'à la solution. La méthode dit comment il est fabriqué et exercé: par un storyboard, sur papier, par une simulation ou par la modélisation des flux de travail, qui figure sur cet axe comme une méthode empruntée dont la maison est la modélisation des processus. Tout prototype répond sur chacun des deux axes, indépendamment. Un prototype papier est toujours un prototype jetable. Une simulation peut être jetable ou vivre dans un outil qui la fait durer, ce qui la range du côté du prototypage évolutif. Demander « est-ce jetable ou est-ce une simulation? » revient à poser une question sans réponse: c'est le prototypage pris dans son ensemble qui règle l'aiguillage entre les deux axes.

Le verbe simuler traverse cette famille et y crée une confusion particulière. Plusieurs formes de prototype savent simuler un processus ou une règle, et le référentiel le dit pour l'outil évolutif à condition qu'un logiciel spécialisé soit employé: c'est une capacité de l'outil. La Simulation est la méthode dont c'est la finalité entière et le seul produit. La question qui l'isole des autres tient en une ligne: le prototype doit-il être exécuté ou seulement regardé? Exécuté, c'est celle-ci. Regardé, c'est un storyboard ou un prototype papier.

Conduire une simulation

Cadrer la question avant qu'un modèle existe

Nommer la décision, puis les mesures qui la tranchent. C'est la modélisation conceptuelle: choisir ce que l'on modélise et ce que l'on laisse dehors. Robinson la donne pour l'activité la plus difficile, la moins comprise et probablement la plus importante d'une étude de simulation. Un modèle construit sans décision attachée produit un nombre que personne n'utilise. Le détail se justifie par la décision: chaque élément ajouté doit déplacer une mesure qui compte, sans quoi il ajoute un paramètre à estimer et une source d'erreur à porter.

Partir du modèle de processus existant

Une simulation s'exécute sur un modèle de processus, produit par la modélisation des processus, avec sa notation et ses règles propres. La simulation charge ce dessin de ce qui le rend exécutable: des durées sur les activités, des probabilités sur les branchements, des ressources avec leurs capacités et leurs horaires, des disciplines de file (premier arrivé premier servi, priorité, abandon au bout de tant de minutes) et une loi d'arrivée des cas. Un modèle dessiné est une carte; les mêmes boîtes, assorties de ces cinq familles de paramètres, deviennent une machine.

Rendre les règles exécutables

Une règle cesse d'être une phrase que l'on lit et devient une condition que le run évalue. « Le client est relancé en principe dans le mois » ne s'exécute pas: il faut le seuil en jours, l'ordre d'évaluation des conditions, le sort du cas limite et l'exception que tout le monde applique sans l'avoir écrite. C'est le travail de l'analyse des règles métier. La simulation révèle les règles restées floues: une règle ambiguë ne se code pas, et le modélisateur en découvre l'ambiguïté au moment de l'écrire.

Paramétrer sur des données réelles et inscrire la provenance de chaque paramètre

Chaque paramètre du modèle est mesuré (il sort d'un système et on peut le montrer), ajusté (une distribution a été calée sur un historique) ou supposé (personne ne l'a observé, quelqu'un l'a jugé). Un paramètre supposé est une hypothèse et porte ce nom sur la fiche de paramètres. Sargent nomme cette exigence la validité des données: s'assurer que les données nécessaires à la construction du modèle, à son évaluation et à la conduite des expériences sont adéquates et correctes. NASA-STD-7009B en fait un objet d'évaluation à part entière, le pedigree des entrées, la crédibilité d'un résultat dépendant d'abord de celle de ce qui entre dans le modèle. Le mode d'échec est banal: un paramètre supposé qui a l'air mesuré, parce que rien dans le tableau ne les distingue.

Vérifier, puis valider

Ce sont deux questions différentes, dont la première est la plus facile. La vérification demande si le programme fait ce que l'on a spécifié: elle s'assure que le modèle informatisé et son implémentation sont corrects. La validation demande si le modèle est juste pour l'usage qu'on en fait: Sargent la définit comme la démonstration qu'un modèle possède, dans son domaine d'applicabilité, une exactitude satisfaisante au regard de l'application visée. Un modèle sans le moindre bogue peut se tromper de bout en bout, parce qu'il reproduit fidèlement un processus qui n'est pas celui de l'organisation. L'instrument de la validation est le scénario de référence: on exécute le modèle avec les règles déjà en vigueur, sur une période dont l'organisation possède les résultats réels, et l'on accepte le modèle seulement s'il les reproduit dans une tolérance fixée avant le run. Fixée avant, parce qu'une tolérance choisie après l'exécution est choisie pour être tenue.

Répliquer

Un modèle stochastique rend une réponse différente à chaque exécution, et l'écart entre deux exécutions n'a rien de marginal. Law en donne la démonstration la plus économique: sur un modèle de guichet bancaire, cinq réplications indépendantes du même scénario produisent des attentes moyennes en file de 1,53 · 1,66 · 1,24 · 2,34 · 2,86 minutes, et il conclut qu'une exécution unique ne produit manifestement pas « les réponses ». Le mode d'opération qu'il décrit comme courant, une exécution unique de longueur arbitraire dont on traite le résultat comme la vraie caractéristique du modèle, peut exposer à une probabilité non négligeable d'inférer des conclusions erronées sur le système étudié. Le nombre de réplications se décide donc avant, en fonction de la précision voulue sur la mesure qui tranche la décision. Law en donne une procédure mécanique: on lance un lot pilote, une dizaine de réplications, on calcule sur la mesure décisive la demi-largeur de l'intervalle de confiance, et l'on ajoute des réplications jusqu'à ce qu'elle passe sous la précision dont la décision a besoin. Une décision qui se joue sur cinq coupures exige un intervalle plus étroit que cinq coupures. Ce calcul fixe le nombre, et les vingt réplications de l'exemple en sortent.

Savoir si le modèle se termine ou s'il tourne en régime

Une simulation qui a un début et une fin naturels, une année de facturation par exemple, est dite terminante: le système et le modèle démarrent à vide, et chaque réplication rejoue la période entière. Un modèle de régime permanent est interrogé sur le comportement du système une fois stabilisé, et il démarre lui aussi à vide, files vides et guichets oisifs, dans un état étranger à celui que l'on veut mesurer. La période de chauffe est le temps qu'il met à sortir de ce transitoire, et les observations qu'elle produit se suppriment avant tout calcul. L'erreur classique consiste à lire un temps d'attente moyen où l'on a fait entrer une heure de files vides: la mesure devient optimiste, d'autant plus que l'exécution est courte. Les questions de capacité et de file, déclencheur le plus fréquent de la technique, tombent presque toujours du côté du régime permanent. Le modèle de relance de l'exemple est terminant, et la question de la chauffe ne s'y pose pas.

Lire le résultat avec son incertitude et trouver le paramètre qui porte la décision

Un résultat de simulation est un intervalle: on le rapporte avec ses bornes. Vient ensuite l'analyse de sensibilité: on fait varier les paramètres supposés, un à un, dans la plage où ils restent crédibles, et l'on observe lesquels déplacent la mesure qui décide. Souvent un seul le fait, et l'exercice a rendu son meilleur service: il a dit sur quoi la décision repose et où il vaudrait la peine d'aller mesurer plutôt que de continuer à supposer. NASA-STD-7009B tient tout cet appareil pour une exigence d'ingénierie et sépare deux crédibilités, celle du modèle et celle des résultats qu'il a produits, en demandant pour ces derniers la caractérisation de l'incertitude, l'analyse de sensibilité et un compte rendu en règle.

Décider et enregistrer le domaine de validité

Sargent le formule sans détour: un modèle peut être valide pour un jeu de conditions expérimentales et invalide pour un autre. Le domaine de validité fait donc partie du livrable, au même titre que le chiffre. Il énonce ce que le modèle a été validé à faire, sur quelles données et dans quelles bornes de volume et de comportement. Il empêchera, dans six mois, qu'on interroge sur une question de tarification un modèle validé pour une question de capacité.

Ce qui fait échouer une simulation

Le modèle plausible que personne n'a validé

Il tourne, il sort des nombres, les nombres ont des décimales, et nul n'a jamais vérifié qu'il reproduit une année que tout le monde connaît. C'est le piège central de la technique, et sa parade est structurelle: le scénario de référence et une tolérance arrêtée avant l'exécution.

La fausse précision d'une exécution unique

Un seul run d'un modèle stochastique est un tirage: le donner pour la réponse est l'erreur.

Confondre vérification et validation

Le modèle fait exactement ce qu'on lui a demandé, et ce qu'on lui a demandé est faux. La revue du modèle rassure sur la première question et reste muette sur la seconde.

Un paramètre supposé qui porte toute la décision

Il n'a jamais été observé, il est écrit comme les autres, et le résultat bascule avec lui. L'analyse de sensibilité est ce qui le débusque.

Le modèle réemployé hors de son domaine

Validé pour une question de capacité, interrogé six mois plus tard sur une question de tarification. Il répond sans garantie.

Le théâtre de la fidélité

Polir le détail du modèle pendant que ses entrées restent supposées. Le BABOK relève que, quand le système ou le processus est très complexe, le processus de prototypage peut s'enliser dans la discussion du « comment » au détriment du « quoi »: le débat sur la finesse du modèle occupe la place du débat sur la qualité des données.

Considérations IA

Une remarque, propre à cette technique, commande toutes les autres. Interrogé sur ce qui se passerait si l'on resserrait les règles de relance, un modèle de langage rendra un résultat: fluide, plausible, formulé avec assurance, du genre « les coupures augmenteraient d'environ 5% ». Il n'a rien exécuté. Il a produit une supposition, dans le registre d'un résultat. La simulation existe pour remplacer cette phrase par une phrase mesurée. Un modèle de langage raconte une issue, une simulation la calcule, et la confusion des deux est d'autant plus facile que la version racontée se lit mieux et arrive en trois secondes.

Là où l'outillage rend un service réel, il le rend en amont et en aval du run. En amont, l'ajustement des distributions d'entrée sur un historique de facturation ou un journal d'événements est un travail statistique fastidieux que la machine fait bien, et elle fait mieux encore une chose que le praticien néglige: signaler les séries trop maigres pour qu'on y ajuste quoi que ce soit, ce qui est exactement le problème du pedigree des entrées. La construction du squelette du modèle à partir d'un modèle de processus existant ou d'un journal d'événements, par la fouille de processus, fait gagner des jours. La génération du balayage de scénarios évite d'écrire vingt variantes à la main. En aval, un modèle de substitution appris sur les propres runs de la simulation dégrossit un grand espace de scénarios à faible coût, en réservant les exécutions coûteuses aux survivants, et la rédaction de l'analyse de sensibilité se délègue sans dommage.

Trois choses restent hors de portée de l'outil. La réaction comportementale est une hypothèse, et une IA en fournira une avec aisance: la manière dont les clients réagissent à une règle qui n'a jamais été appliquée est ce qu'aucune donnée historique ne contient, et une élasticité inventée a le même ton qu'une élasticité mesurée. La validation exige un référent, c'est-à-dire une réalité connue à laquelle confronter le modèle: aucun outil ne la possède, et c'est l'organisation qui la détient dans ses propres systèmes. La sensibilité des données, enfin: un historique de facturation identifie des personnes réelles, et il se pseudonymise avant d'entrer dans un modèle, a fortiori avant de partir chez un tiers.

Exemples

Des services industriels communaux révisent leurs règles de relance. La question que le run doit trancher: les règles proposées encaissent-elles davantage et à quel prix pour les habitants?

Le modèle est le plus faible là où les effectifs sont les plus petits: les coupures tiennent la tolérance à 4,9%, de justesse, et une décision qui se joue sur les coupures repose donc sur la cellule la plus mince du modèle.

Les règles proposées encaissent CHF 92'000 de plus à 90 jours et raccourcissent le délai moyen de 6,5 jours, au prix de 1'333 premiers rappels et de 131 seconds rappels supplémentaires et de 5 coupures supplémentaires chez des habitants. Chiffrer cet arbitrage en francs demanderait un coût unitaire du rappel et un coût social de la coupure, que ce run n'a pas produits.

Visualisations

La technique produit deux objets, chacun prenant la forme qui découle de sa nature. Le run est un objet spatial: des entrées qui convergent, un modèle que l'on exécute un certain nombre de fois, des mesures qui en sortent assorties d'intervalles et surtout une arête de retour, celle qui remonte d'une référence observée vers le modèle et conditionne tout le reste. Cette arête, propre à la simulation, se dessine: un tableau à trois lignes la détruirait. La fiche de paramètres et le tableau de run sont au contraire des lignes et des colonnes, avec une colonne de provenance et une colonne d'écart qui se lisent d'un coup d'œil: ils restent en cellules.

Trois contrôles suffisent à auditer une étude de simulation réelle. Chaque entrée porte-t-elle une provenance déclarée, ou certaines sont-elles arrivées sans que quiconque sache d'où? Le compteur de réplications affiche-t-il un nombre supérieur à un? Et l'arête de retour a-t-elle été empruntée, autrement dit le modèle a-t-il été confronté à une période dont l'issue était déjà connue? Une étude où cette arête manque s'est arrêtée avant l'étape qui rendait ses chiffres lisibles.

Coût

Outils

L'outil le plus simple est la feuille de calcul, et il faut savoir ce qu'elle sait faire et où elle s'arrête. Elle porte très bien un modèle déterministe: des volumes, des taux, des durées moyennes, et l'on y lit l'effet d'un changement de règle. C'est là que vit la majorité des choses qu'on appelle des simulations, et c'est légitime tant que la question ne dépend pas de la variabilité. Dès qu'il y a une file d'attente, une ressource partagée, un abandon ou une distribution à queue lourde, la moyenne devient trompeuse, parce que le comportement d'un système à ressources contraintes ne se déduit pas de la moyenne de ses entrées. La feuille de calcul cesse alors de répondre à la question posée.

Au-dessus viennent les moteurs de simulation de processus, qui prennent un modèle de processus déjà dessiné et lui ajoutent le paramétrage qui le rend exécutable. La spécification BPSim de la WfMC existe exactement pour cela: elle définit un format d'échange qui accroche des scénarios et leurs paramètres (durées, ressources, coûts, probabilités, lois d'arrivée) à un modèle BPMN ou XPDL, ce qui permet de paramétrer dans un outil et d'exécuter dans un autre. Plusieurs plateformes de modélisation métier et de fouille de processus l'implémentent, ce qui en fait le chemin le moins cher quand le modèle de processus existe déjà.

Pour les questions de capacité et de file, les outils de simulation à événements discrets (Simul8, Arena, AnyLogic, SimPy pour qui programme) sont le bon niveau: ils portent nativement les ressources, les files, les priorités, les horaires et les lois de probabilité, et ils rendent des intervalles de confiance. Ce sont eux qui savent conduire les réplications et l'analyse de sortie sans qu'on les réécrive. Les plateformes de fouille de processus jouent un rôle complémentaire et sous-estimé: elles reconstruisent le processus réel depuis les journaux d'événements du système, ce qui fournit d'un coup le modèle et une partie des paramètres mesurés, et elles substituent le processus exécuté au processus déclaré.

L'exécution peut aussi se passer de machine. Le BPM CBOK de l'ABPMP pose l'alternative en deux termes: une simulation est manuelle ou électronique lorsqu'elle passe par un outil de simulation de processus. Il décrit le premier terme sous le nom de laboratoire de processus, où une petite équipe interfonctionnelle fait passer à la main des transactions fictives d'un bout à l'autre du processus, dans un travail d'amélioration, de reconception ou de réingénierie.

Le choix de l'outil pèse enfin beaucoup moins que la qualité de ce qu'on y verse. Une simulation menée dans une feuille de calcul sur des données mesurées et validée contre une année connue vaut mieux qu'une simulation menée dans le meilleur moteur du marché sur des paramètres supposés. L'outil décide de ce que le modèle peut prendre en charge; les données décident de ce que ses résultats valent.

Sources

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.36 Prototyping: la simulation comme méthode de prototypage, ce qu'elle démontre et ce qu'elle peut mettre à l'épreuve, ainsi que la limite de l'enlisement dans le « comment ».
• ABPMP, Guide to the Business Process Management Common Body of Knowledge (BPM CBOK), §3.10.2 Simulation Tools and Environments: la simulation manuelle ou électronique et le laboratoire de processus, où une petite équipe interfonctionnelle exécute à la main des transactions fictives de bout en bout.
• Robert G. Sargent, Verification and Validation of Simulation Models, Proceedings of the 2010 Winter Simulation Conference, pp. 166-183: la vérification, la validation et la validité des données comme trois questions distinctes et la validité toujours relative à l'usage visé.
• Averill M. Law, Statistical Analysis of Simulation Output Data: The Practical State of the Art, Proceedings of the 2015 Winter Simulation Conference, pp. 1810-1824: les réplications, la longueur des exécutions et les intervalles de confiance et la démonstration chiffrée qu'une exécution unique ne produit pas de réponse.
• NASA-STD-7009B, Standard for Models and Simulations, 2024: la crédibilité d'un modèle et celle de ses résultats traitées comme deux évaluations séparées, avec le pedigree des entrées, la caractérisation de l'incertitude, l'analyse de sensibilité et le compte rendu des résultats.
• Stewart Robinson, A Tutorial on Simulation Conceptual Modeling, Proceedings of the 2017 Winter Simulation Conference, pp. 565-579: le cadrage du modèle, ce que l'on modélise et ce que l'on laisse dehors.
• WfMC, Business Process Simulation Specification (BPSim) v2.0: le format d'échange qui paramètre un modèle de processus BPMN ou XPDL pour le rendre exécutable.