Fin septembre, la communauté du process management se retrouve à Stuttgart pour All about Process Management. Deux jours de keynotes, de masterclasses et de tables rondes, et si l'on en croit le programme, un thème traversera la plupart d'entre eux : les agents IA, et ce qu'il faut pour les laisser agir au sein d'un processus métier. Nous y serons en tant qu'exposant, et voici l'argument que nous comptons y défendre.
Tout commence par quelque chose qui n'a rien à voir avec un logiciel. Dans la plupart des entreprises, découvrir ce qui ne va vraiment pas dans un processus suppose d'abord que quelqu'un le soupçonne.
Voyons comment ce genre de chose émerge habituellement. Un fournisseur se plaint d'un retard de paiement. Un manager remarque que les validations semblent prendre plus de temps qu'avant. Une équipe a l'impression de refaire deux fois le même travail. Quelqu'un pose la question, et c'est seulement là que le travail commence vraiment : extraire les données, construire l'analyse, présenter les résultats, s'accorder sur une mesure. Des semaines plus tard, une réponse arrive, et elle est généralement bonne.
Mais remarquez ce qui a dû se passer avant tout cela. Quelqu'un a dû avoir une intuition. Et une intuition ne se forme que là où quelqu'un est suffisamment proche du travail pour sentir que quelque chose cloche. Tout ce que personne ne se trouve à ressentir reste invisible : le service qui ne se plaint jamais, l'étape du processus dont personne n'est responsable, l'exception devenue discrètement la norme. Non pas parce que les données manquent, mais parce que personne n'a pensé à demander.
La réponse standard est un dashboard. Mettre les chiffres à l'écran, les actualiser régulièrement et laisser les gens regarder.
Cela aide, mais ne règle pas le problème de fond. Un dashboard attend toujours d'être interrogé. Il récompense la personne qui sait déjà quel graphique ouvrir, quel filtre poser et quel chiffre est inhabituel pour cette période de l'année. Il permet de vérifier une intuition plus vite, mais il ne donne pas l'intuition elle-même. Les mêmes angles morts survivent donc, désormais derrière une interface plus agréable.
On le voit dans la façon dont les dashboards sont réellement utilisés. Une poignée de spécialistes les consultent en permanence. Presque tous les autres les ouvrent quand on le leur demande, jettent un œil à la ligne du haut et les referment. Non par désintérêt, mais parce qu'examiner une vue de processus à la recherche d'anomalies est un travail réellement difficile, et la plupart des gens ont déjà un autre métier.
Il y a une étape que presque tout le monde saute, parce qu'elle semble administrative plutôt qu'intelligente. Si l'on veut qu'un système signale qu'un problème est survenu, il faut d'abord lui dire à quoi ressemble ce qui est correct.
La plupart des organisations possèdent ce savoir, mais il vit aux mauvais endroits : dans un manuel qualité que personne ne lit, dans un document de politique interne, dans la tête de la personne qui fait ce métier depuis onze ans. Il existe comme une intention. Il n'existe pas sous une forme que l'on puisse vérifier.
Une fois correctement mis par écrit, ce savoir s'avère étonnamment simple et étonnamment concret. Une facture ne devrait pas être payée avant d'avoir été validée. Une commande ne devrait pas être modifiée trois fois après confirmation. La personne qui fait une demande ne devrait pas être celle qui la valide. Une demande client ne devrait pas rester sans réponse plus de cinq jours. Rien de tout cela n'est sophistiqué. C'est ce que les personnes du processus croient déjà, simplement rendu explicite.
Chez Process.Science Intelligence, c'est exactement ce que sont les Process Norms : vos propres attentes concernant un processus, écrites sous forme de règles, puis confrontées à ce qui s'est réellement passé dans vos systèmes — pour chaque cas, et non sur un échantillon. Là où les données ne permettent pas un verdict clair, cela est indiqué comme tel, plutôt que discrètement compté comme conforme.
C'est là toute la condition préalable. Une fois en place, le sens du travail peut s'inverser.
Le chemin classique va du dashboard vers l'insight. Une personne ouvre une vue, cherche quelque chose qui semble anormal, formule une hypothèse, filtre, creuse, et finit par arriver à une cause racine. Ce chemin dépend entièrement du fait que quelqu'un décide de regarder, sache où regarder, et regarde assez souvent. Il évolue avec le nombre de spécialistes disponibles, autrement dit, il ne passe pas à l'échelle.
Process.Science Intelligence dispose d'une fonction appelée Alerts qui parcourt ce chemin dans l'autre sens. Plutôt que d'attendre d'être interrogé, le système confronte le processus à vos normes et pointe directement les endroits où la réalité a divergé : ici, dans cette partie de l'activité, contre cette règle, tant de fois, aussi fréquemment ces derniers temps. Depuis cette alerte, on accède directement à l'analyse pertinente, puis à la cause racine : quels cas sont concernés, ce qu'ils ont en commun, ce que cela coûte en temps. Il n'y a plus à reconstituer le chemin, car il est déjà tracé.
Non pas du dashboard vers l'insight, mais de l'insight directement vers le bon endroit du dashboard, la cause racine déjà en vue. Et lorsque l'analyse montre que les écarts se concentrent autour d'un fournisseur, d'un site ou d'un type de document, c'est exactement ce qu'elle indique. Une forte indication de l'endroit où regarder ensuite vaut énormément — ce n'est pas pour autant une preuve, et nous ne la présentons donc jamais comme telle.
La conséquence, c'est un changement dans le public visé par le travail sur les processus. L'ancien chemin servait des spécialistes connaissant suffisamment l'outil, les données et le processus pour naviguer entre les trois à la fois. Le nouveau sert les personnes propriétaires du processus : chefs d'équipe, contrôleurs de gestion, responsables de service et responsables de centres de services partagés. Ils n'ont pas besoin de savoir construire une analyse. Ils ont besoin qu'on leur indique où regarder, puis de pouvoir suivre la piste par eux-mêmes.
Pendant des années, c'était une question d'efficacité. Moins d'angles morts, des réponses plus rapides, moins de dépendance envers quelques analystes surchargés. Utile, mais pas urgent.
L'automatisation change la donne. Un logiciel qui valide, commande, enregistre et répond seul n'a pas d'intuition. Il ne remarque pas qu'un fournisseur est inhabituel, qu'une chaîne de validation a été contournée, ou qu'une étape a été sautée parce que quelqu'un était en congé. Les humains absorbent ce type d'ambiguïté en permanence et silencieusement. Une machine n'en absorbe rien. Dès l'instant où l'on laisse un logiciel agir au sein d'un processus, les règles non écrites doivent devenir des règles écrites — non pas pour les besoins de l'analyse, mais pour définir la frontière : où la machine est-elle autorisée à décider, et où doit-elle rendre la main ? Une organisation qui n'a jamais formulé ce qu'est « correct » n'a aucun moyen d'y répondre, ni de savoir si sa réponse tiendra encore dans six mois.
La valeur se manifeste à trois endroits. Les problèmes sont détectés pendant qu'ils sont encore peu coûteux, car un écart devient visible dès la semaine où il survient, et non plus au trimestre où quelqu'un finit par poser la question. Les personnes propriétaires du processus peuvent agir elles-mêmes, ce qui signifie que l'amélioration cesse d'attendre la disponibilité d'un analyste et se produit là où se fait le travail. Et l'organisation se retrouve avec quelque chose qu'elle n'avait pas avant : un standard écrit et testé décrivant comment ses processus sont censés fonctionner. C'est ce standard qui rend l'étape suivante défendable — qu'il s'agisse d'un accord d'objectifs, d'un audit, ou du transfert d'une partie du processus à une machine.
Rien de tout cela ne dépend d'un grand programme. Cela dépend de la volonté d'écrire ce que l'on croit déjà à propos de son processus — puis de laisser les données vous contredire.
Nous préférons en discuter plutôt que l'affirmer, car ce qui est intéressant, c'est toujours le processus concret : quelles règles une entreprise est suffisamment sûre d'elle pour les écrire noir sur blanc, et lesquelles se révèlent finalement plus négociables que prévu.
Nous serons présents à All about Process Management les 30 septembre et 1er octobre 2026 à l'ICS de Stuttgart, et nous montrerons volontiers Alerts en direct, d'un simple écart jusqu'à la cause racine. Passez nous voir sur notre stand pour en discuter.
Vous préférez en parler plus tôt ? Utilisez Parler à un expert pour organiser une démo, que nous ferons sur l'un de vos propres processus. Nous nous réjouissons de ces échanges.
