Découverte des processus : définition, méthodes et cas d’usage métier

La plupart des équipes pensent comprendre le fonctionnement de leurs processus. Elles disposent d’une procédure documentée quelque part, peut-être une page Confluence, peut-être une procédure opérationnelle standard imprimée en 2019 que tout le monde considère comme la source de vérité. Puis quelqu’un cartographie réellement ce qui se passe dans les systèmes, et le document comme la réalité ne partagent peut-être que 60 % de leurs étapes.

C’est précisément cet écart que la découverte de processus vise à combler. Il ne s’agit pas de concevoir un meilleur processus, de lancer un projet d’automatisation ou de cocher les livrables d’un consultant. Il s’agit simplement d’établir ce qui se passe réellement avant que quiconque n’intervienne. Cela semble être une exigence minimale. Ce ne l’est pas. La plupart des organisations ignorent cette étape ou l’exécutent mal, puis passent des mois à automatiser la mauvaise chose ou à repenser un processus qu’elles n’ont jamais compris avec précision.

L’affirmation centrale à défendre ici est la suivante : la découverte de processus est l’étape préalable qui distingue les projets d’automatisation efficaces de ceux qui déploient à grande échelle un processus défaillant. Vous pouvez contester cela. Certaines équipes vous diront avoir automatisé avec succès sans cette étape. La plupart de ces équipes ont découvert plus tard qu’elles avaient automatisé une solution de contournement plutôt qu’un processus.

Ce que les équipes apprennent trop tard

• La découverte de processus produit un modèle de l’existant, et non un plan de refonte.
• Les journaux d’événements révèlent ce que les entretiens atténuent : écarts, boucles de reprise, solutions de contournement.
• La découverte de processus intervient avant l’automatisation ou la refonte, et non parallèlement à celles-ci.
• La découverte de processus est une technique au sein du process mining, et non un synonyme de celui-ci.

Ce que signifie réellement la découverte de processus

La définition académique, issue de la littérature sur le process mining, est précise : la découverte de processus consiste à construire un modèle de processus à partir d’un journal d’événements, sans connaissance préalable du processus. Vous lui fournissez des données sur ce qui s’est produit. Elle construit un modèle du processus. Vous ne partez d’aucune structure présupposée. C’est la définition.

En langage opérationnel courant : vous extrayez les enregistrements de ce que vos systèmes ont réellement fait, et un modèle du processus réel émerge de ces enregistrements. Personne n’a besoin de se mettre d’accord sur l’apparence que devrait avoir le processus. Les données montrent à quoi il ressemble réellement.

Ce guide de la découverte de processus est particulièrement important sur le plan pratique. Le résultat de la découverte de processus est un modèle de processus de l’existant, différent d’une recommandation de refonte, d’un plan d’automatisation ou d’une analyse des écarts. Il s’agit d’une représentation de l’exécution actuelle du processus, rien de plus. Ce que vous en faites vient ensuite. La découverte elle-même consiste à établir cette vue de l’état actuel avant le début de tout travail d’amélioration ou d’automatisation.

Pour que la découverte de processus fonctionne avec des outils automatisés, les données sous-jacentes du processus doivent respecter une structure minimale. Selon le cadre d’Appian concernant les exigences relatives aux journaux d’événements, chaque entrée de journal nécessite au moins trois champs : un nom d’activité (ce qui s’est passé), un horodatage (quand cela s’est passé) et un identifiant de dossier (à quelle instance du processus cela appartient). Sans ces trois éléments, vous ne pouvez pas construire un modèle de processus cohérent à partir du journal. Vous n’obtenez que des fragments.

Il est utile de vérifier cette exigence minimale de données avant de commencer. Je vois des initiatives d’amélioration des processus s’enliser parce que l’équipe a lancé le travail de découverte, puis constaté en cours d’exercice que son système enregistrait un horodatage et une activité, mais aucun identifiant de dossier. Elle ne peut pas relier les événements au sein d’une même instance de processus. La découverte produit du bruit au lieu d’un modèle.

L’exécution du processus doit laisser une trace numérique pour que la découverte automatisée fonctionne. Lorsqu’elle n’en laisse pas, les méthodes manuelles comblent le manque. Les deux approches ont des rôles légitimes.

Découverte manuelle de processus ou découverte automatisée des processus métier

Le choix entre la découverte manuelle et la découverte automatisée des processus métier (ABPD) ne relève pas vraiment d’une préférence. Il dépend des données disponibles et du niveau de précision dont vous avez besoin. Voici comment les deux approches se comparent selon les critères qui comptent réellement lorsque vous évaluez celle qui convient à votre situation.

Les approches traditionnelles de documentation des processus privilégient le volet manuel. La découverte automatisée extrait les données directement des systèmes eux-mêmes. Pour la plupart des processus du monde réel, aucune approche n’est complète à elle seule, raison pour laquelle les deux méthodes sont souvent combinées plutôt que considérées comme concurrentes.

Quand la découverte manuelle de processus reste pertinente

La découverte manuelle de processus est écartée plus rapidement qu’elle ne devrait l’être. Les ateliers et les entretiens avec les parties prenantes sont lents, chaotiques et sujets aux mêmes biais que toute donnée déclarative. Je vois régulièrement cela dans les échanges avec des équipes opérationnelles qui ont vécu un exercice de découverte manuelle difficile et veulent savoir si elles peuvent éviter le suivant grâce à l’automatisation. Parfois, oui. Parfois, non.

Le rôle légitime des méthodes manuelles concerne les activités qui ne laissent aucune trace numérique. La manière dont Automation Anywhere présente le task mining l’exprime bien : toutes les interactions significatives entre les personnes et les systèmes ne se retrouvent pas dans les journaux backend. Un agent du service client qui ouvre cinq applications pour répondre à un seul ticket, copie manuellement des informations entre les fenêtres et utilise une checklist papier pour vérifier l’achèvement suit un processus que le système ne journalise, au mieux, que partiellement. Les utilisateurs métier dans ces rôles détiennent une connaissance du processus qu’aucun journal d’événements ne révèle. L’inefficacité est réelle. Le journal ne la voit pas.

Les ateliers et les entretiens restent également l’outil approprié lorsque l’objectif est de faire émerger les connaissances tacites de parties prenantes qui gèrent un processus de manière informelle depuis des années. Le problème de la connaissance institutionnelle est réel. Un bon interlocuteur fait ressortir les solutions de contournement, les voies d’escalade informelles et les arbitrages qui n’ont jamais été intégrés à la procédure opérationnelle standard. Tout cela est invisible pour un outil automatisé.

Comment la découverte de processus propulsée par l’IA change la donne

Le problème central des ateliers manuels est l’effet observateur. Lorsque vous demandez à quelqu’un comment fonctionne un processus, cette personne en décrit une version. La version décrite est façonnée par ce qu’elle pense que vous voulez entendre, par ce dont elle se souvient et par la manière dont le processus est censé fonctionner plutôt que par son fonctionnement réel. Cet écart est précisément le problème que la découverte de processus cherche à résoudre, et les ateliers manuels ne le comblent que partiellement.

Les outils de découverte de processus propulsés par l’IA adoptent une autre approche. Ils extraient les flux de processus directement depuis les systèmes métier, ce qui signifie que le modèle reflète l’exécution réelle plutôt que l’exécution reconstituée de mémoire. Le cadre proposé par Celonis est juste : une extraction directe depuis les systèmes produit une vue en temps réel de l’exécution des processus, plus précise que n’importe quel résultat d’atelier. Il n’existe pas de biais d’observation dans un journal d’événements. Le système a enregistré ce qui s’est passé et à quel moment, sans que personne décide de ce qu’il convient d’inclure.

Cela dit, ces outils dépendent des données d’une manière qui crée leur propre limite : ils ne voient que ce qui est journalisé. Une étape de processus réalisée dans un tableur, lors d’un appel téléphonique ou sur un post-it est invisible pour la découverte automatisée. Les outils d’IA et de découverte de processus sont performants pour les activités transactionnelles médiées par les systèmes. Le jugement humain, la coordination informelle et les étapes hors système nécessitent toujours un complément manuel. La combinaison des deux approches est généralement plus précise que chacune prise séparément.

Comment fonctionne la découverte des processus métier : des journaux d’événements au modèle de processus

Il est important de comprendre le mécanisme avant d’évaluer si la découverte de processus convient à votre situation. Voici ce qui se passe réellement, étape par étape, sans discours commercial.

Étape 1 : collecte des journaux d’événements. Le point de départ consiste à extraire un journal d’exécution du processus depuis les systèmes concernés. Chaque entrée de journal représente un événement dans une instance de processus. Conformément aux exigences minimales de données établies dans la documentation d’Appian, chaque entrée doit comporter un nom d’activité, un horodatage et un identifiant de dossier. L’identifiant de dossier permet à l’algorithme de reconstruire une séquence d’événements sous la forme d’une trace de processus unique, plutôt que d’une liste d’activités déconnectées. Si votre CRM enregistre « opportunité créée », « proposition envoyée » et « affaire conclue », mais ne les relie pas au même identifiant d’opportunité, vous ne pouvez pas reconstruire le processus commercial. Vous avez des événements sans processus.

Étape 2 : construction du modèle de processus. Les algorithmes de découverte analysent le journal d’événements afin d’identifier des motifs parmi de nombreuses traces de processus. Quelles activités suivent habituellement une séquence donnée ? Quelles activités apparaissent parfois, mais pas toujours ? Où se produisent les boucles, c’est-à-dire les étapes répétées avant que le processus n’avance ? Le résultat est un modèle de processus : une représentation structurée des étapes réelles du processus, des points de décision et des parcours observés dans les données. Il s’agit du modèle de processus de l’existant, qui montre le fonctionnement réel du processus plutôt que la manière dont quelqu’un imaginait son fonctionnement.

Étape 3 : analyse détaillée du processus et validation humaine. Un modèle de processus généré à partir d’un journal d’événements nécessite une interprétation humaine. L’algorithme identifie des motifs. Il ne distingue pas une boucle représentant une reprise réelle d’une boucle reflétant une particularité du système de journalisation. Les experts métier doivent examiner le modèle, valider les noms des activités et confirmer que les identifiants de dossier délimitent correctement les instances de processus. Cette étape permet aussi de traiter les questions de définition du processus : s’agit-il d’un processus ou de deux ? Ces éléments sont-ils des variantes du même flux ou des processus vraiment distincts ?

Ce que les journaux d’événements capturent et que les entretiens manquent

C’est le point qui mérite que l’on s’y attarde. Lorsque vous demandez à quelqu’un de décrire le déroulement d’un processus, cette personne décrit le parcours qui se passe généralement bien. Elle décrit la séquence principale : réception de la demande, validation, approbation, finalisation. Ce qu’elle ne décrit pas, du moins pas spontanément, ce sont les retours en arrière, les étapes qu’elle saute lorsqu’elle est sous pression, la solution de contournement inventée il y a six mois et désormais considérée comme la méthode officielle.

Les journaux d’événements révèlent une image différente. Un processus de bon de commande que l’équipe décrit comme « trois approbations, puis émission du bon de commande » peut apparaître dans le journal sous la forme suivante : trois approbations, bon de commande émis, corrigé, réémis, approbation secondaire, bon de commande émis à nouveau. Cette boucle de reprise représente du temps réel, des coûts réels et une variation réelle du processus. Le goulot d’étranglement est visible dans les données du journal d’une façon qu’il ne le serait jamais lors d’un atelier.

La manière dont Automation Anywhere présente le task mining va encore plus loin : même les interactions avec l’interface utilisateur qui se produisent hors des journaux backend peuvent être capturées par l’enregistrement des interactions. Un agent de saisie qui copie manuellement des informations entre deux systèmes non connectés ne laisse de trace dans aucun des journaux d’événements de ces systèmes, mais laisse une trace claire dans un enregistrement d’écran. Ce type de travail invisible est précisément ce qui crée l’écart entre l’apparence des opérations métier sur le papier et leur coût réel dans la pratique. Sans le capturer, la découverte reste incomplète.

Construire la cartographie du processus de l’existant avant toute intervention

Le résultat spécifique visé est une cartographie du processus de l’existant : une représentation visuelle ou structurée de la manière dont le processus s’exécute réellement, incluant le parcours principal, les variantes, les boucles et le traitement des exceptions. Cela diffère d’un document de conception de processus, qui montre comment quelqu’un souhaite que le processus fonctionne. La cartographie de l’existant montre ce qui fonctionne réellement à cet instant.

Le fait que Nintex présente la découverte de processus comme une première étape préalable est pertinent pour une raison précise. Les équipes qui ignorent cette étape et passent directement à l’automatisation ou à la refonte prennent des décisions sans référence de départ. Elles automatisent ce qu’elles pensent être en train de se produire. Lorsque l’automatisation se comporte de façon inattendue, elles ne savent pas s’il s’agit d’un problème technique ou d’un problème de découverte, car elles n’ont jamais cartographié avec précision ce qu’elles automatisent. Cette phase de diagnostic devient coûteuse plus tard.

Une découverte de processus efficace produit une cartographie que les parties prenantes des opérations, de l’automatisation et de la conformité peuvent toutes lire et sur laquelle elles peuvent réagir. Avant le début de tout travail d’amélioration des processus métier, cette cartographie doit exister. La refonte, le plan d’automatisation et l’examen de conformité en dépendent tous. Les équipes qui commencent sans elle repensent essentiellement sur la base d’hypothèses. J’ai vu cela se terminer de deux façons : soit elles redécouvrent le processus à la dure après que l’automatisation a échoué, soit elles ne réalisent jamais ce qu’elles ont manqué et vivent simplement avec un résultat sous-optimal.

La cartographie de l’existant n’est pas l’objectif. C’est l’autorisation de faire tout ce qui vient ensuite.

Les avantages de la découverte de processus au-delà de l’identification des opportunités d’automatisation

C’est ici que je souhaite nuancer la manière dont la découverte de processus est habituellement présentée. La plupart des articles sur le sujet, y compris de nombreux contenus de fournisseurs, la traitent comme la première étape d’un projet d’automatisation. On identifie ce qui doit être automatisé, puis on l’automatise. Cette présentation est juste, mais incomplète, et cette incomplétude crée un problème précis : les équipes réalisent une découverte de processus une fois, extraient les candidats à l’automatisation, puis passent à autre chose. Elles passent à côté des deux autres éléments révélés par l’exercice.

Selon la présentation d’Appian des utilisations réelles de la découverte de processus, les trois applications principales sont l’identification des opportunités d’automatisation, la révélation des problèmes de conformité et de contrôle, et le diagnostic des variations de processus qui affectent la performance opérationnelle. Cette troisième catégorie, la performance et la variation des processus, est celle où une grande partie de la valeur significative reste inexploitée.

Excellence opérationnelle grâce à l’analyse des variations. Tout processus exécuté à grande échelle développe des variantes : différentes équipes exécutant différemment une même étape, différences géographiques ou entre lignes de produits que personne n’a documentées, adaptations informelles apparues parce que le parcours officiel était trop lent. Ces variations ne représentent pas toujours une inefficacité. Elles peuvent parfois constituer des adaptations utiles. Mais vous ne pouvez pas le déterminer avant de les avoir identifiées. La découverte de processus fait émerger ces variantes comme résultat naturel de la construction du modèle. Les équipes qui exploitent ces informations améliorent la standardisation des processus et réduisent l’écart de performance entre les instances les plus et les moins performantes.

Détection des écarts de conformité. C’est le cas d’usage systématiquement sous-estimé. Dans les secteurs réglementés en particulier, le processus exécuté dans les systèmes et celui décrit dans la documentation des politiques doivent rester alignés. La découverte de processus rend cet alignement vérifiable. Lorsque le journal d’événements montre qu’une étape d’approbation obligatoire est ignorée dans 23 % des cas, il s’agit d’un écart de conformité, visible précisément parce que la découverte a produit un modèle pouvant être comparé au parcours attendu. Les équipes qui identifient les opportunités d’automatisation sans jamais effectuer le contrôle de conformité passent entièrement à côté de cela.

Identification des inefficacités et des goulots d’étranglement de performance. Les boucles de reprise, les délais de transmission et les temps d’attente entre les étapes sont visibles dans les données des journaux d’événements d’une manière que les entretiens et l’observation ne permettent pas de détecter. Les identifier ne concerne pas uniquement l’automatisation. Parfois, la bonne solution est une modification du processus, une action de formation ou un problème d’accès à un outil, et aucune de ces solutions ne nécessite de créer une automatisation.

🤔 Attendez.
Les équipes concentrées sur les initiatives d’automatisation réalisent souvent une découverte de processus une seule fois et n’en extraient que la liste des candidats à l’automatisation. Les écarts de conformité et les signaux de variation des processus étaient pourtant présents dans le même modèle depuis le départ. Réexaminer les résultats de la découverte sous l’angle de la conformité six mois plus tard constitue un deuxième exercice qui aurait dû être le premier.

Découverte de processus pour les opportunités d’automatisation

L’identification des opportunités d’automatisation est le cas d’usage qui conduit la plupart des équipes à la découverte de processus. La valeur réside ici dans la précision : au lieu d’automatiser des processus en fonction de l’intuition de quelqu’un sur ce qui est répétitif, le modèle de découverte montre quels workflows présentent réellement un volume élevé, une structure cohérente et un parcours prévisible qu’un système fondé sur des règles peut gérer de manière fiable.

Le cadre de Nintex sur l’utilisation de la découverte pour automatiser à grande échelle est pertinent ici. Avant d’engager des ressources RPA ou de créer une automatisation de workflow, la cartographie du processus vous indique si le processus est suffisamment stable pour être automatisé. Un processus qui présente une forte variation, des parcours d’exception fréquents et des reprises importantes dans le journal d’événements est un mauvais candidat à l’automatisation, quel que soit son volume. L’automatiser de manière fiable exigerait de gérer chaque variante, et vous savez désormais combien de variantes existent. Cela modifie l’analyse coûts-bénéfices avant de commencer, c’est précisément à ce moment-là que vous voulez que cela se produise.

Découverte de processus pour la conformité et les variations de processus

Les équipes d’audit, de gestion des risques et de conformité utilisent la découverte de processus pour une raison qui n’a rien à voir avec l’automatisation : elles doivent détecter les écarts par rapport aux parcours de processus attendus avant qu’un auditeur ne le fasse.

Le cadre des cas d’usage d’Appian est direct à ce sujet. La découverte de processus produit un modèle visible de ce qui s’exécute réellement. Ce modèle peut être comparé au cadre de contrôle, à la documentation des politiques ou à l’exigence réglementaire. Là où ils divergent, vous avez un écart de contrôle. Cet écart peut être bénin : une solution de contournement informelle qui atteint le même résultat par un chemin différent. Ou il peut représenter une exposition au risque réelle. Dans les deux cas, l’identifier relève de la mission de l’équipe conformité, et la découverte de processus le rend visible d’une manière que l’échantillonnage manuel des transactions n’atteint jamais pleinement.

L’idée fausse selon laquelle la découverte de processus n’est qu’un outil d’automatisation est particulièrement dommageable dans ce contexte. Les équipes conformité qui entendent « découverte de processus » et supposent qu’elle relève de l’équipe d’automatisation passent à côté d’un cas d’usage légitime pour leur propre travail. Le même journal d’événements qui révèle un candidat RPA révèle également un contournement d’approbation non autorisé. Les deux figurent dans le modèle. Leur importance dépend entièrement de la personne qui le lit.

Découverte de processus et process mining : d’où vient la confusion

Je constate régulièrement cette confusion. Quelqu’un pose une question sur le process mining alors qu’il parle de découverte de processus. Quelqu’un évoque une « découverte de processus » alors qu’il décrit en réalité l’ensemble du cycle de vie du process mining. Les termes sont utilisés de manière interchangeable suffisamment souvent pour qu’il soit utile d’expliquer clairement leur relation.

La découverte de processus est une technique au sein de la discipline plus large du process mining. Ce n’est ni un synonyme de process mining ni une approche concurrente. Le process mining est le cadre global : il englobe la découverte, la vérification de conformité (comparaison de l’exécution réelle avec un modèle de référence) et l’amélioration (enrichissement d’un modèle de processus avec des données supplémentaires). La découverte de processus est la première de ces trois techniques, et constitue le fondement dont dépendent les autres. Vous ne pouvez pas effectuer de vérification de conformité sans un modèle découvert auquel vous comparer.

L’indication de Celonis sur la manière dont le process mining modernise la découverte de processus renvoie directement à cette relation. Les logiciels et les solutions de process mining fournissent la suite analytique complète : la découverte comme point de départ, puis la conformité et l’amélioration construites par-dessus. Lorsque les fournisseurs parlent d’intelligence des processus, ils décrivent généralement l’ensemble de la pile de capacités du process mining, et non uniquement la couche de découverte.

Pourquoi cette confusion a-t-elle une importance pratique ? Parce que les équipes qui pensent avoir besoin de « process mining » alors qu’elles ont en réalité besoin de « découverte de processus » investissent souvent dans des outils de process mining dotés de capacités qu’elles ne sont pas prêtes à utiliser. Le processus de découverte produit le modèle de l’existant. C’est souvent tout ce dont une équipe a besoin pour la première phase. Les capacités de vérification de conformité et d’amélioration d’une solution complète de process mining sont véritablement utiles, mais elles exigent que l’équipe ait déjà opérationnalisé la découverte.

Le process mining et la découverte de processus ne sont pas concurrents. L’un est une sous-discipline de l’autre. Se tromper sur ce point conduit soit à surinvestir dans les outils, soit à ne pas comprendre suffisamment ce qu’ils font.

Cas d’usage de la découverte de processus pour les équipes opérations, automatisation et conformité

Trois équipes apparaissent le plus systématiquement comme les principaux publics des travaux de découverte de processus, et leurs cas d’usage sont suffisamment distincts pour qu’il soit utile de donner à chacune une illustration concrète plutôt qu’une description générique selon laquelle « différentes équipes en bénéficient ».

Les cas d’usage spécifiques sont liés à la manière dont chaque équipe exploite le résultat, car c’est là que se situe la véritable différence. Les équipes opérations, automatisation et conformité réalisent le même exercice de découverte et prennent des décisions différentes.

Un exemple concret mérite d’être cité pour les équipes d’automatisation : un responsable de l’automatisation dans un groupe opérationnel de taille moyenne cartographie son workflow de traitement des factures via l’extraction de journaux d’événements et constate que 40 % des factures suivent un parcours variant qui implique une étape de ressaisie manuelle absente de la procédure opérationnelle standard. Avant la découverte de processus, le plan était de créer un workflow d’automatisation robotisée des processus pour gérer le parcours principal. Après la découverte, l’équipe sait que le parcours variant existe, peut en estimer le volume et décider si elle doit le traiter dans l’automatisation ou s’attaquer d’abord à la cause racine. Cette décision n’est possible que parce que la cartographie du processus de l’existant existe. Dans Latenode, une équipe menant ce type de découverte structurée pourrait créer un workflow récurrent qui récupère les exports de journaux depuis son ERP, exécute une synthèse basée sur l’IA pour faire ressortir les schémas d’activité variants, puis achemine le résultat structuré vers le responsable des opérations pour examen, sans maintenir une base de données vectorielle distincte ni développer de zéro un connecteur d’enrichissement personnalisé.

Équipes opérations : documenter ce qui se passe réellement par rapport à ce que dit la procédure opérationnelle standard

Les équipes opérations sont confrontées à un problème précis : leur documentation de gestion des processus métier était correcte à un moment donné, peut-être il y a plusieurs années. Depuis, l’équipe s’est adaptée, a trouvé des solutions de contournement, a hérité de contraintes système et a accumulé des pratiques informelles. La procédure opérationnelle standard dit une chose. Les journaux système en montrent une autre. Personne ne considère cette divergence comme un problème jusqu’à ce qu’une nouvelle recrue suive exactement la procédure et produise des résultats inattendus, ou qu’une initiative d’amélioration révèle que le « processus actuel » utilisé par tous comme référence n’est pas réellement le processus actuel.

Pour les opérations, la découverte de processus consiste à établir la vue de l’état actuel avant le début de toute discussion sur la refonte. Optimisez les processus à partir de données d’exécution réelles, et non à partir d’un document qui peut dater de 18 mois. La gestion des processus métier à grande échelle dépend d’un modèle précis de ce qui s’exécute réellement. Ce modèle est le résultat de la découverte. Sans lui, la refonte n’est qu’une estimation éclairée.

Équipes d’automatisation : identifier les bons processus à automatiser

Voici l’erreur de départ que je constate le plus souvent chez les équipes d’automatisation et de RPA : elles choisissent les candidats à l’automatisation selon ce que quelqu’un décrit comme « répétitif et manuel », ce qui est vrai, mais insuffisant. Répétitif et manuel ne signifie pas automatisable. Un processus répétitif, manuel et très variable parce que chaque dossier exige des arbitrages différents est un mauvais candidat à l’automatisation, quel que soit le temps qu’il consomme.

Les résultats de la découverte de processus indiquent aux équipes d’automatisation trois éléments utiles : à quelle fréquence un processus suit chaque parcours (volume par variante), à quel point la structure des parcours est cohérente (est-elle suffisamment fondée sur des règles pour l’automatisation ?) et où se concentrent les exceptions (que devrait couvrir la gestion des exceptions ?). Une bonne solution de découverte de processus rend cela visible avant le début de toute création d’automatisation. Les équipes qui passent la découverte et automatisent sur la base de volumes estimés finissent souvent par gérer une automatisation capable de traiter le parcours principal, mais qui échoue bruyamment sur chaque variante. La décision de prioriser une automatisation exige d’abord la cartographie du processus.

La capacité de task mining d’Automation Anywhere est un exemple pratique de la manière dont les équipes d’automatisation étendent la découverte afin de capturer la couche d’interaction que les journaux backend manquent. Si le processus implique des copies entre applications, l’enregistrement de task mining les capture. Le script RPA peut alors les reproduire. Sans cette couche, l’automatisation est conçue autour des événements système visibles, et les étapes manuelles invisibles la font échouer en production.

Ce qui rend une approche de découverte de processus efficace

Une découverte de processus efficace ne consiste pas à choisir l’outil le plus cher. Elle repose sur l’application des méthodes adaptées aux données adaptées, avec les bonnes personnes impliquées. Voici les points de décision qu’il convient de vérifier avant de commencer ou avant de sélectionner une solution de découverte de processus.

• Vérifiez la structure de vos journaux d’événements avant de vous engager dans une découverte automatisée

  Le mode d’échec ainsi évité : investir dans un outil de process mining ou un workflow ABPD pour découvrir que vos journaux ne disposent pas d’identifiants de dossier, rendant la construction du modèle impossible. La vérification pratique : extrayez un échantillon de 100 entrées de journal depuis votre système cible et confirmez que chaque entrée comporte un nom d’activité, un horodatage et un identifiant unique de dossier ou d’instance. Si un champ manque, résolvez le problème à la source avant de commencer.

• Définissez les limites du processus avant l’exécution du modèle

  Le mode d’échec : l’algorithme produit un modèle couvrant plusieurs processus distincts parce que l’identifiant de dossier couvre un périmètre trop large, ou manque un processus complet parce que le journal est segmenté entre plusieurs systèmes sans clé partagée. La vérification pratique : documentez l’événement de début et l’événement de fin du processus que vous souhaitez découvrir avant d’exécuter quoi que ce soit. Confirmez que ces deux événements existent dans vos données de journal.

• Incluez la validation des parties prenantes comme étape clairement identifiée, et non comme une réflexion tardive

  Le mode d’échec : un modèle précis auquel personne ne fait confiance parce que les experts métier n’ont pas participé à la validation des noms d’activité et des définitions de dossier. Les décisions d’optimisation des processus fondées sur un modèle auquel les équipes opérations ne font pas confiance ne sont pas mises en œuvre. La vérification pratique : planifiez les sessions de validation avec les parties prenantes avant le début de la découverte, et non après la construction du modèle.

• Utilisez la découverte fondée sur les données pour les processus transactionnels, et les méthodes manuelles pour les connaissances tacites

  Le mode d’échec consistant à choisir l’une et ignorer l’autre : soit un modèle qui manque les étapes informelles hors système les plus importantes, soit une description issue d’ateliers biaisée par la mémoire et la pression sociale. La vérification pratique : répertoriez chaque étape du processus et identifiez celles qui laissent une trace dans le système et celles qui n’en laissent pas. Planifiez la méthode de découverte selon le type d’étape.

• Prévoyez trois cas d’usage, pas un seul

  Le mode d’échec : réaliser une découverte uniquement centrée sur les candidats à l’automatisation et manquer les signaux d’écart de conformité ainsi que les données de variation des processus présentes dans le même modèle. La vérification pratique : attribuez à une personne l’examen du résultat du modèle pour chacun des trois cas d’usage principaux — automatisation, conformité, optimisation des opérations — plutôt que de filtrer pour un seul. C’est l’utilisation de la technologie de découverte de processus dans son véritable périmètre.

• Traitez la découverte comme un exercice récurrent, et non comme un prérequis ponctuel

  Le mode d’échec directement lié aux initiatives de transformation numérique : les équipes réalisent la découverte, conçoivent l’automatisation, puis ne vérifient jamais si le processus a dérivé du modèle six mois plus tard. Les variantes de processus s’accumulent. Le modèle devient obsolète. L’automatisation commence à gérer des exceptions pour lesquelles elle n’a pas été conçue. La vérification pratique : planifiez une actualisation trimestrielle ou semestrielle du modèle dans le cadre de la routine de gestion des processus, et non uniquement au début d’un projet d’amélioration.

📊 En pratique :
Le journal d’événements minimal viable pour démarrer une découverte automatisée de processus comporte exactement trois champs : nom de l’activité, horodatage et identifiant de dossier. Avant de sélectionner une technologie de découverte de processus ou de mobiliser du temps d’équipe pour l’extraction, ouvrez un exemple d’export de journal et confirmez que les trois sont présents et renseignés de manière cohérente. Cette vérification prend dix minutes. L’ignorer a coûté des semaines à certaines équipes.

Ce que les équipes font des résultats de la découverte de processus

La découverte de processus produit un modèle. Ce modèle n’est pas la ligne d’arrivée. Ce que les équipes en font au cours des semaines suivantes détermine si l’exercice a porté ses fruits.

La première décision concerne la priorisation. La cartographie du processus de l’existant montre chaque parcours, chaque variante, chaque goulot d’étranglement. Tous ne justifient pas une action. Les équipes d’automatisation utilisent la cartographie pour évaluer les candidats : les étapes à fort volume, à faible variation et fondées sur des règles remontent en tête du backlog d’automatisation. Les candidats à la refonte vont aux responsables des opérations. Les écarts de conformité sont transmis à la fonction risques ou audit. Sans ce triage, la cartographie du processus reste dans un dossier et est mentionnée lors de la prochaine revue trimestrielle comme « un sujet à revoir ».

Pour les équipes qui évoluent vers l’automatisation, la cartographie de processus alimente directement la conception de l’automatisation robotisée des processus ou la planification de l’automatisation des workflows. Le modèle découvert, exprimé sous la forme d’un diagramme de modélisation et de notation des processus métier ou d’une spécification de flux de processus, fournit à l’équipe de mise en œuvre une vue validée de ce sur quoi elle construit. Lorsque le RPA ou le workflow rencontre un parcours d’exception, l’équipe sait déjà qu’il existe parce qu’il figurait dans la cartographie. Cette connaissance modifie la manière dont la gestion des exceptions est conçue.

La seconde grande voie d’exploitation concerne l’intégration au process mining. Les équipes qui souhaitent une visibilité continue plutôt qu’un instantané ponctuel intègrent le modèle découvert dans une plateforme de process mining pour une surveillance continue de la conformité. Le modèle devient la référence. Les écarts par rapport à celui-ci apparaissent dans le tableau de bord en quasi temps réel. C’est là que le task mining et la détection de variantes assistée par l’IA transforment la découverte initiale en opération continue. Le goulot d’étranglement apparu dans la cartographie initiale déclenche une alerte en direct lorsqu’il réapparaît trois mois plus tard, après qu’une modification du processus l’a réintroduit.

Les équipes qui ignorent les étapes de triage et de surveillance doivent souvent refaire l’exercice de découverte six mois plus tard, sans avoir exploité ni les signaux de conformité ni les données de variation des processus obtenues la première fois. C’est une manière coûteuse d’apprendre que l’optimisation exige plus qu’une cartographie.