Comment l'IA analyse réellement les documents métier ambigus : le problème du multi-intention dont personne ne parle

Prenez n'importe quel document opérationnel qui circule réellement dans une entreprise de 200 personnes : le SOP d'accueil client, la politique de retours, le manuel de réponse aux incidents, la checklist d'approbation fournisseur. Lisez-le une fois, lentement. Ce que vous allez trouver, presque sans exception, ce n'est pas un processus unique. Ce sont deux ou trois processus tressés ensemble, plus une branche d'exception, plus une note de gouvernance, plus un paragraphe qui décrit une sous-tâche comme s'il s'agissait de sa propre procédure.

Ce n'est pas une mauvaise rédaction. C'est la façon dont la connaissance institutionnelle s'accumule réellement. Quelqu'un a écrit la version un du SOP d'accueil en 2018 pour le chemin heureux. Quelqu'un a ajouté l'exception de signalement de fraude en 2020 après qu'un faux compte soit passé. Quelqu'un a annexé la section d'escalade VIP en 2022 quand le directeur commercial s'est plaint que les clients entreprise étaient traités comme des inscriptions en libre-service. Le document que vous lisez aujourd'hui est l'enregistrement archéologique de cinq années d'apprentissage opérationnel, et personne n'a le budget pour le réécrire de zéro.

Quand un consultant lit ce document, il n'essaie pas de le diagrammer littéralement. Il construit un modèle mental de quelles parties décrivent le flux principal, quelles parties décrivent des exceptions au flux principal, et quelles parties décrivent un processus entièrement différent qui se trouve partager quelques étapes. Cette séparation mentale est l'étape invisible qui rend le diagramme utilisable. Sautez-la et le diagramme est structurellement faux avant que la première boîte ne soit dessinée.

Le reste de cet article traite de cette partie difficile. À quoi ressemblent les trois patterns d'enchevêtrement d'intention dans la vraie vie, ce qu'un analyseur naïf en fait, et ce qu'un analyseur doit faire à la place pour produire un diagramme qu'un propriétaire de processus approuvera réellement.

Après avoir analysé quelques milliers de documents opérationnels de PME, trois patterns d'échec représentent l'écrasante majorité des intentions enchevêtrées. Ils apparaissent dans les manuels de support client, les procédures de clôture financière, les guides d'approvisionnement, les dossiers d'accueil RH, et presque tous les SOP rédigés par l'équipe opérationnelle elle-même.

Pattern 1. Procédure, exception et escalade dans le même paragraphe

Le pattern le plus courant. Un seul paragraphe commence par décrire la procédure principale (étapes un à quatre), puis glisse vers une exception (« si le client a une facture en retard, faire ceci à la place »), puis se termine par une escalade (« si cela ne peut pas être résolu en 48 heures, transférer au gestionnaire de compte »). Pour un lecteur humain, les changements sont évidents par le contexte. Pour un analyseur littéral, ces trois flux se lisent comme une seule procédure continue avec une logique de branchement qui n'a en réalité aucun sens.

Pattern 2. Chemin heureux et cas limite rare narrés comme équivalents

Le deuxième pattern est l'aplatissement narratif. Le document décrit le chemin standard qui se produit 95 pour cent du temps, puis donne un poids narratif égal à un cas limite qui se produit une fois par trimestre. Les deux sont décrits comme « ce que nous faisons », sur le même ton, sans aucun indice de fréquence. Un diagramme qui leur donne un poids visuel égal produit un processus qui semble deux fois plus complexe qu'il ne l'est réellement, et l'équipe opérationnelle le rejettera parce qu'il ne correspond pas à la réalité qu'elle vit.

Pattern 3. Processus macro et sous-tâche sans frontière

Le troisième pattern est la collision d'échelle. Une phrase décrit un résultat métier de niveau macro (« clôturer les comptes du mois »). La phrase suivante décrit une action mécanique à la minute près (« saisir l'ajustement de réconciliation à la ligne 47 du modèle GL »). Il n'y a pas de frontière de sous-processus, pas d'indice d'imbrication, pas de changement de couloir. L'analyseur soit promeut l'action mécanique au rang de pair du processus macro, ce qui est absurde, soit rétrograde le processus macro à une seule tâche, ce qui est pire.

• Le tressage procédure plus exception plus escalade, qui est le mode d'échec dominant pour les documents face au client.
• Le cas limite narratif aplati, qui est le mode d'échec dominant pour les documents opérationnels et de conformité.
• La collision d'échelle entre processus macro et sous-tâche, qui est le mode d'échec dominant pour les documents financiers et de back-office.

Un analyseur à intention unique suppose que l'entrée décrit un seul processus et traite chaque phrase comme une preuve de ce processus unique. Quand on lui fournit un document avec trois intentions tressées ensemble, il ne refuse pas. Il produit un diagramme. Le diagramme est structurellement erroné d'une manière spécifique et prévisible, et il vaut la peine de nommer ce mode d'échec parce que c'est ce que la plupart des outils IA-vers-BPMN livrent encore aujourd'hui.

La sortie typique est un seul couloir avec quinze à trente tâches en séquence, plus deux ou trois portes placées là où le paragraphe d'exception apparaissait, plus un groupe lâche d'événements de fin dont personne ne sait quoi faire. Le chemin heureux est enterré dans la branche d'exception. L'escalade est représentée comme une tâche parallèle plutôt que comme un transfert. La sous-tâche du pattern trois est dessinée comme un pair du processus macro, donnant au propriétaire un organigramme où « clôturer les comptes » et « saisir la ligne 47 » sont dans des boîtes de même taille.

Quand le propriétaire du processus voit cela, la réaction n'est jamais « c'est faux de façon intéressante que nous pouvons corriger ». La réaction est « ce n'est pas mon processus », l'outil perd sa crédibilité, et la conversation de transformation se termine. Nous avons vu ce mode d'échec tuer plus de programmes pilotes que tout autre problème technique, parce qu'il atterrit dans les cinq premières minutes de la première démo.

La leçon est que l'analyseur doit explicitement modéliser la possibilité que le document contienne plus d'un processus. Cela ne peut pas être déduit de la propreté structurelle de la sortie. Ce doit être une étape de premier ordre dans le pipeline.

La détection multi-intention est une étape de prétraitement qui s'exécute avant la génération BPMN. Son rôle est de produire une courte liste de processus candidats que le document décrit, avec une classification de la relation de chaque candidat avec les autres (flux principal, exception du flux principal, escalade du flux principal, processus séparé qui se trouve partager du vocabulaire). Le générateur BPMN en aval reçoit alors une entrée structurée plutôt que du texte brut, et le diagramme de sortie reflète la topologie réelle.

Les passes heuristiques

La détection s'exécute en trois passes. La première passe identifie les phrases noyau de processus : verbes en voix opérationnelle, rôles nommés, séquencement temporel. La deuxième passe regroupe ces phrases par cohérence de sujet : quelles phrases noyau décrivent des étapes qui pourraient plausiblement appartenir au même processus, et lesquelles rompent la chaîne. La troisième passe étiquette chaque groupe avec un rôle (principal, exception, escalade, séparé) en regardant les conditions de déclenchement, les indices de fréquence et le langage de transfert.

L'étape de confirmation humaine

On ne demande pas à la détection d'avoir raison toute seule. On lui demande de produire un brouillon que l'utilisateur peut confirmer ou corriger en moins de 30 secondes. L'interface montre la liste de candidats avec de courts résumés : « Candidat 1 : accueil client, le flux principal décrit dans les sections 1 à 3. Candidat 2 : exception fraude, se ramifie à l'étape 4 du candidat 1. Candidat 3 : escalade VIP, processus séparé qui partage l'étape de création de compte. » L'utilisateur clique pour confirmer, fusionner ou supprimer. Cela prend moins de temps que la lecture du document, et c'est la seule façon de gérer l'ambiguïté que le document lui-même introduit.

La décision fusionner-ou-garder-séparé

L'appel le plus difficile est le second. Les tressages du pattern un (principal plus exception plus escalade) sont généralement conservés comme un seul processus avec des portes explicites et des événements de fin explicites pour le chemin d'escalade. Les tressages du pattern trois (macro plus sous-tâche) sont généralement séparés, la sous-tâche devenant un sous-processus appelé. Le pattern deux (cas limites aplatis) est un jugement : si la fréquence du cas limite est supérieure à 10 pour cent, le garder dans le flux principal avec une porte ; en dessous de 10 pour cent, le séparer en un processus d'exception distinct qui est lié mais pas dessiné en ligne.

La détection multi-intention de LucidFlow s'exécute automatiquement sur chaque document téléversé pour la génération BPMN. L'utilisateur voit un panneau de processus candidats avant que le diagramme ne soit dessiné, avec généralement deux à quatre candidats pour un document de trois à dix pages. L'utilisateur confirme ou ajuste la séparation, et le pipeline en aval produit un BPMN par candidat confirmé, plus des liens explicites entre processus liés (exception-de, escalade-vers, appelé-par).

La détection est biaisée vers la séparation plutôt que la fusion, car un processus séparé à tort est plus facile à corriger dans l'interface qu'un processus fusionné à tort. Fusionner deux diagrammes après coup nécessite de les redessiner ; séparer un diagramme fusionné à tort nécessite de démêler la logique des portes, ce que les utilisateurs ne feront tout simplement pas d'après notre expérience. La plupart du temps, ils abandonnent le diagramme et recommencent.

L'étape de confirmation est délibérément rapide. Si l'utilisateur y passe plus d'une minute, la détection ne gagne pas sa place. La cible est de 20 à 30 secondes par document, car la valeur de la détection multi-intention est qu'elle évite une session de nettoyage de 30 minutes à l'étape de revue du diagramme, et ce calcul ne fonctionne que si le coût en amont reste faible.

La détection multi-intention fonctionne bien sur les documents opérationnels de PME : trois à quinze pages, la perspective d'un seul expert métier, le langage d'une seule unité d'affaires. La raison pour laquelle elle fonctionne, c'est que l'ambiguïté dans ces documents est locale. Une frontière au niveau paragraphe ou section suffit à séparer les intentions, et le nombre de candidats est faible (typiquement deux à cinq).

À l'échelle entreprise, le problème est plus difficile de manières qui ne sont pas encore résolues par cette classe de technique. Un manuel d'approvisionnement de 200 pages rédigé par comité a des intentions qui traversent les sections, un vocabulaire qui dérive entre chapitres, et des couches de gouvernance qui modifient les étapes opérationnelles depuis une altitude différente. La bonne réponse implique probablement là des catalogues de processus explicites au niveau section construits par des humains, avec l'IA aidant à réconcilier le langage entre sections plutôt qu'à extraire l'intention de zéro.

Pour une PME entre 20 et 2000 employés, les documents sont presque toujours dans la plage où la détection multi-intention fait son travail. Si vous êtes dans cette plage et que votre outil IA-vers-BPMN ne fait pas cette étape explicitement, il produit des diagrammes qui ont l'air correct et sont structurellement faux. La solution n'est pas de lire le document plus attentivement. La solution est de séparer les intentions avant de dessiner.