Tout ce qui appartient à un article sur FlowVisual : textes courts prêts à l’emploi en trois longueurs, les faits sous-jacents, images en taille réelle, citations à citer — et la section que la plupart des kits de presse omettent : ce que l’outil ne peut pas faire. Libre d’utilisation, sans demande préalable.
Chaque texte est révisé et peut être repris sans modification — comme communiqué, comme encadré, comme paragraphe courant. Aucune approbation nécessaire, aucun délai d’embargo.
FlowVisual est un simulateur de processus de bureau pour macOS et Windows : il fait fonctionner un processus métier, indique l’engorgement et chiffre une modification prévue en euros et en temps.
FlowVisual est un simulateur de processus pour macOS et Windows. Au lieu de dessiner un diagramme de flux, il fait fonctionner le processus : le travail circule dans le modèle, la charge s’accumule sur les rôles et les systèmes, un test de contrainte Monte Carlo sur des milliers de journées de travail identifie le goulot d’étranglement. Chaque changement planifié est recalculé intégralement et présenté en avant/après en euros et en temps — sous forme d’une fourchette, jamais comme un chiffre embelli. Tout s’exécute localement, sans compte et sans cloud.
FlowVisual est un simulateur de processus pour le bureau des consultants, responsables Lean et organisateurs opérationnels — macOS et Windows, développé par la Balane GmbH à Munich. Un diagramme montre l’ordre des étapes ; il n’indique pas quel rôle manquera d’heures en premier, combien coûte le troisième transfert de l’année ou si une recommandation tient aussi lors d’une semaine difficile. FlowVisual répond à ces questions, car il exécute le processus : les durées sont saisies comme des intervalles (« 8 à 20 minutes »), un test de contrainte Monte Carlo envoie le modèle pendant des milliers de jours et livre le temps de cycle en P50 et P90, le débit et la probabilité de ne pas tenir l’engagement. Pour chaque modification, l’application recalcule l’intégralité du modèle au lieu d’additionner des économies — c’est pourquoi on voit aussi quand une amélioration au mauvais endroit ne sert à rien et que le goulot d’étranglement se contente de se déplacer. À la fin se trouve un PDF d’offre sur votre propre papier à en-tête, avec un registre des hypothèses et une bande P10–P90. La modélisation et le calcul sont gratuitement disponibles en permanence.
La Balane GmbH est un éditeur de logiciels à Munich. Il développe des outils pour le travail sur les processus — FlowVisual pour la simulation, Flowrefy.com pour la méthode associée. Le directeur général est Jonas David Höttler. Les produits sont vendus directement, sans investisseurs derrière.
« FlowVisual » — un mot, F majuscule, V majuscule, pas d’espace, pas de capitales. Le fabricant s’appelle « Balane GmbH », pas « Balane » seul, lorsque cela devient juridique. La méthode voisine s’appelle « FLOW » et appartient à Flowrefy.com — elle n’est pas le produit.
La version courte pour quelqu’un qui doit décider en deux minutes si c’est une histoire.
Le processus est enregistré, dessiné, une mesure est recommandée. Puis la direction demande : Qu’est-ce que cela apporte ? La réponse est encore aujourd’hui une diapositive avec un chiffre rond dessus, et la première question critique dans la salle la démonte. Entre des outils de dessin à 15 € par mois et des logiciels de simulation à cinq chiffres par an se trouve précisément l’écart où la plupart du travail de processus a lieu.
Il calcule. Le travail circule sous forme d’opérations dans le modèle, des files d’attente se forment, la charge atterrit sur les rôles, les équipes et les systèmes qui la portent. Un test de contrainte Monte Carlo fait passer le processus par des milliers de journées de travail et indique où ça coince — le jour moyen et le jour fort, le dixième jour de travail avec afflux. Rouge signifie dans toute l’application exactement une chose : plus de travail que de capacité.
Personne ne doit deviner où une modification agit. C’est pourquoi FlowVisual n’additionne pas les économies, mais recalcule pour chaque variante l’intégralité du modèle — processus partiels inclus. C’est la différence entre un tableau où deux mesures sont simplement additionnées et un outil qui montre : la deuxième mesure n’apporte plus rien parce que la première a déjà déplacé le goulot d’étranglement. Des améliorations au mauvais endroit achètent approximativement zéro débit — ce n’est pas une opinion, c’est le résultat du deuxième passage.
À côté du goulot d’étranglement actuel se trouve une courbe de fragilité : à partir de quel volume le processus bascule, et quelle étape reprend alors le rôle du goulot d’étranglement ? La grille d’options propose elle‑même des variantes — alléger le goulot, automatiser l’étape la plus coûteuse, supprimer une rupture de média, regrouper les deux meilleures —, simule chacune entièrement et les trie par effet. Avant et après sont côte à côte, chaque chiffre évolue pendant la saisie.
Tant que les saisies sont estimées, « Préliminaire » figure au‑dessus du résultat, avec le chiffre à côté qui doit être recueilli en premier. Dans l’offre, l’origine de chaque indicateur est indiquée — donnée client, estimation ou mesure — et un registre de toutes les hypothèses sur lesquelles repose le calcul. S’y ajoute un contrôle de plausibilité qui contredit en page de couverture si une mesure économise de l’argent mais détériore le temps de traversée ou le débit. Un outil qui contredit son propre chiffre vaut plus dans la discussion avec le CFO qu’un outil qui ne fait que confirmer.
Un PDF de proposition sur votre en‑tête : le goulot d’étranglement, la mesure, la valeur en heures et en euros — comme bande P10–P90, avec un registre de toutes les hypothèses derrière, et avec un contrôle de plausibilité qui contredit sur la page de garde si une mesure économise de l’argent mais détériore le temps de traversée. Avec documentation du processus, Word, draw.io, SVG, JSON et CSV.
La section pour la demande de précision que tout bon article pose : d’où vient le chiffre ? Tout cela figure tel quel dans le code source livré — vérifiable dans l’application elle‑même.
Étapes, décisions, abandons, sous‑processus. Par étape : qui le fait, quel système, combien de temps — en intervalle, pas en nombre.
400 itérations. Chaque itération est une journée de travail avec son propre volume de cas et ses propres temps de traitement.
L’étape qui bride — avec la charge le jour moyen et le jour fort, à côté la courbe à partir de laquelle la situation bascule.
Variantes proposées, chacune entièrement resimulée, triées par effet. Rien n’est additionné.
Origine de chaque chiffre, registre de toutes les hypothèses, contrôle de plausibilité par rapport à sa propre recommandation.
Offre, documentation de processus, données brutes — sur votre propre en‑tête.
Une étape n’est considérée comme achevée que lorsqu’un vrai résultat existe : un modèle avec étapes, une exécution avec résultat, un goulot que cette exécution a nommé. Une barre qui se remplit au clic serait l’indicateur de progression que ce produit refuse partout ailleurs.
La quantité journalière est tirée, pas fixée : une loi lognormale autour de la valeur indiquée, pilotée par variabilité, probabilité de pic et facteur de pic. La même variabilité entre aussi comme variance d’arrivée dans la file d’attente.
« 8 à 20 minutes » est lu comme P10–P90 d’une loi lognormale. Ainsi, un point aberrant occasionnel au‑delà de la borne supérieure peut survenir — une loi uniforme entre 8 et 20 pourrait précisément ne jamais le générer, et c’est celui qui ruine la journée.
Le temps d’attente naît selon Kingman (G/G/1) : le facteur (variance d’arrivée + variance de traitement)/2 multiplié par utilisation/(1−utilisation). Près de la limite de capacité, le terme est linéarisé, au‑delà il est mené en saturation — au‑dessus de la limite, une file d’attente n’a plus d’état stable calculable.
La fréquence à laquelle une étape est visitée par cas est résolue comme point fixe plutôt que triée topologiquement. Ainsi, le retraitement est compté : une boucle « retour pour correction » disparaît dans un tri, et avec elle la moitié de la charge de l’étape. Les cycles sont trouvés par l’algorithme de Tarjan ; des branches parallèles qui se rejoignent comptent le cas une fois au lieu de deux.
Plusieurs étapes peuvent puiser sur une équipe, un système ou un pool de licences. Si le pool est restreint, l’étape individuelle n’est que le symptôme — le rapport mentionne alors le pool. Les sous‑processus remontent avec capacité et temps de traitement vers l’étape parente, c’est pourquoi une intervention trois niveaux plus bas modifie l’effectif.
Temps de cycle en P50 et P90, débit, part des jours au‑dessus de la capacité, coût par jour en bande P10–P90 — plus la moyenne des pires cinq pour cent des jours et l’efficacité du flux, c’est‑à‑dire traitement divisé par le temps de traversée. Celle‑ci se situe dans les processus réels le plus souvent dans une fourchette en pour‑cent à un chiffre et c’est le chiffre le plus dérangeant de toute l’analyse.
La même exécution encore une fois à 0,8 · 0,9 · 1,0 · 1,1 · 1,2 · 1,35 · 1,5 fois la quantité. On mesure non pas la valeur mais la courbure : le dommage croît de manière surproportionnelle avec la charge, aussi ce qui est aujourd’hui une étape verte peut être le premier à devenir non linéaire lors d’une semaine chargée.
Une étape pour laquelle personne n’a indiqué de capacité ne peut pas remporter le goulot d’étranglement — et ne sera pas colorée comme de l’air. Si aucune étape ne déclare quoi que ce soit, le résultat est « Goulot d’étranglement indéterminé » plutôt qu’un chiffre inventé.
Les seuils sont dans le code source, pas dans une brochure : 85 % d’utilisation est le point d’inflexion à partir duquel le temps d’attente croît de façon disproportionnée ; à partir de dix pour cent des jours au‑dessus de la capacité, l’état s’appelle « tendu ». Et le hasard a une graine fixe — le même modèle donne au second chargement le même chiffre. Une offre dont le résultat change au recalcul n’en serait pas une.
Tout ce qui tient dans un encadré d’information. Les chiffres qui changent sont automatiquement à jour ici — ils proviennent de la même source que le reste de la page.
Prix en euros, prix finaux clients TTC, facturation annuelle. La clé de licence est valable simultanément sous Windows et macOS.
Toutes les captures proviennent de la fenêtre réelle du programme, rendues en 3520 × 2000 pixels — pas de maquette, pas d’interface reconstituée. Un processus de démonstration est montré ; il n’y a pas de données clients.
Une capture de 3520 pixels de large est illisible dans une colonne d’article de 700 pixels. Ces trois extraits proviennent des mêmes fichiers et sont fournis sans réduction — chacun montre exactement une chose.
Le signe est un F dont la barre horizontale est rouge : la même couleur qui signifie « surchargé » dans l’application. L’accent est violet (#6B5BB0), la police IBM Plex. La marque verbale est fournie en SVG de tracé, afin qu’elle s’affiche correctement sans police installée.
Pour une citation littérale, sans autre autorisation. Pour un entretien ou une question personnelle : contact en bas.
Un diagramme de processus est une affirmation. Dès qu’on le fait fonctionner, il devient vérifiable — et dans la plupart des ateliers le résultat surprend d’abord celui qui a dessiné le diagramme.
La phrase sur laquelle toute l’application repose : Personne ne doit avoir à deviner où une modification agit. C’est pourquoi nous n’additionnons pas des économies, mais recalculons pour chaque variante l’intégralité du modèle. Ce n’est qu’ainsi que l’on voit que la deuxième mesure n’apporte plus rien, parce que la première a déplacé le goulot d’étranglement.
Nous ne fournissons en principe aucun chiffre unique. Une économie sans intervalle est la première chose qu’un groupe sceptique démonte — et à juste titre.
L’outil doit tenir dans la salle où l’on prend les décisions. C’est pourquoi il existe un mode présentation et pas d’export de diapositives : la question du groupe reçoit sa réponse sur le modèle en cours, elle n’est pas reportée à la séance suivante.
Cette section figure ici parce qu’elle raccourcit la recherche. Qui vérifie l’une de ces limites la trouve telle qu’elle est présentée ici.
Nous ne publions pas de chiffres d’installation, pas de logos de référence et pas d’études de cas avec des noms de clients. Pas par goût du secret, mais parce que des chiffres solides font défaut. Si vous en avez besoin dans l’article, vous ne les obtiendrez pas — de personne.
FlowVisual ne lit pas d’event logs depuis des ERP et n’observe pas le travail sur écran. Les chiffres viennent des personnes qui font le processus. C’est un choix : ne pas requérir un projet de données en amont est l’argument de vente — pas la lacune.
L’application peut analyser des documents, mais seulement via un point de terminaison d’IA que vous fournissez vous-même, avec obligation de citation — et rien n’atterrit dans le modèle avant d’avoir été accepté ligne par ligne. Un assistant de chat intégré n’est pas livré.
Il n’y a pas de compte, pas de serveur, pas d’édition simultanée. Une équipe partage un dossier de projet sur son propre disque. Qui cherche des workflows d’approbation et un référentiel de processus cherche un autre produit.
Le résultat vaut ce que valent les entrées. L’application le dit elle-même : tant que des chiffres sont estimés, « Préliminaire » figure au-dessus du résultat, et dans l’offre est indiqué sur quoi repose le chiffre — indication client, estimation ou mesure.
L’outil trouve le goulot d’étranglement et chiffre la modification. Quel processus est touché et comment l’organisation le supporte reste décidé par un humain. La méthode derrière se trouve sur Flowrefy.com, pas dans l’application.
Des clés de revue pour la version Pro sont fournies gratuitement aux rédactions et aux auteurs spécialisés — sans condition sur la couverture et sans demande de ce que vous écrirez.
Les deux stores proposent la même version ; la clé de licence vaut dans les deux. Modéliser et calculer ne nécessitent ni compte ni clé — pour une critique la portée gratuite suffit jusqu’au PDF final.
macOS 13 ou ultérieur (Apple Silicon et Intel) · Windows 10/11 (64-Bit)
Objet « Presse » suffit. Réponse en règle générale le même jour ouvrable.
Le chemin le plus court vers le point où se décide si l’outil sert à quelque chose :