Le processus documenté n’est pas le processus réel

Le processus documenté n’est pas le processus réel

Demandez à une entreprise quelle est la première étape d’un processus et vous obtiendrez presque toujours une réponse nette : un e-mail arrive. Posez la question à la personne qui ouvre réellement cette boîte de réception et la réponse s’allonge. Quarante expéditeurs différents, pas deux formats identiques, la moitié des informations enfouies dans des pièces jointes PDF, et une décision de routage pour les cas ambigus qui n’existe que dans la tête d’une seule personne, construite au fil des années et jamais consignée nulle part. Construisez l’automatisation sur la première réponse et vous l’aurez construite pour un processus qui n’existe pas.

C’est cette dernière ligne qui mérite qu’on s’y attarde. Ce ne sont pas les exceptions en général qui pénalisent un processus. Les processus gèrent en permanence des exceptions connues, et les gèrent bien, parce que quelqu’un a déjà pensé à leur prévoir un circuit. C’est l’exception que personne n’a consignée qui fait des dégâts, précisément parce que rien dans le système n’y est préparé. Un projet d’automatisation hérite de cette même vulnérabilité, à grande échelle, dès qu’il est mis en service sur un processus cartographié à partir d’une conversation plutôt qu’à partir du travail lui-même.

Pourquoi l’entretien donne la mauvaise réponse, systématiquement

Ce n’est pas un défaut de documentation qu’une meilleure documentation corrigerait. C’est structurel. Un manager décrit la règle, parce que c’est de la règle qu’il est responsable et c’est elle qu’il sait formuler clairement dans un atelier d’une heure. La personne qui fait le travail au quotidien connaît elle aussi la règle, mais elle connaît également les deux douzaines de façons dont les données réelles ne s’y conforment pas, et les ajustements informels qui permettent discrètement au processus de continuer à fonctionner malgré tout. La recherche académique sur cet écart appelle cette seconde catégorie des contournements : des écarts délibérés que les acteurs du processus pratiquent pour franchir un obstacle que le processus documenté ne prévoit pas. Une étude de 2025 parue dans Business & Information Systems Engineering montre que les données d’événements issues de l’exécution réelle des processus ne correspondent souvent pas au modèle documenté précisément à cause de ce phénomène, et que cet écart n’est pas un bruit à nettoyer. C’est là que se trouve le processus réel.

Personne ne ment pendant l’atelier. La réponse du manager est vraie pour la règle. Elle n’est simplement pas vraie pour le travail, et l’écart entre les deux reste invisible jusqu’à ce que quelqu’un observe le processus assez longtemps pour voir où la réalité s’écarte discrètement de la version de l’organigramme.

Pourquoi le process mining ne suffit pas à combler cet écart

Le process mining, la discipline qui consiste à reconstituer le déroulement réel d’un processus à partir des journaux d’événements générés par les systèmes plutôt qu’à partir d’entretiens, représente un vrai progrès par rapport à l’atelier, et il vaut la peine de l’utiliser partout où le travail laisse déjà une trace numérique propre. La vérification de conformité, sa technique centrale, compare le modèle documenté « to-be » à l’exécution « as-is » enregistrée dans les journaux et fait apparaître chaque point où ils divergent.

La limite se situe en amont de la technique, pas dans la technique elle-même. Le process mining ne peut reconstituer que ce qu’un système a enregistré. L’essentiel de ce qui fait échouer une première tentative d’automatisation se produit avant que quoi que ce soit ne touche un système : un appel téléphonique, une décision prise à la lecture d’un PDF, une exception orientée à l’instinct plutôt que selon une règle documentée. Un journal ne peut pas vous montrer une décision qui n’a jamais généré d’entrée. C’est l’écart que comble une personne qui observe le travail réel, et non un meilleur tableau de bord posé sur le travail déjà instrumenté.

Ce que produit réellement la phase de découverte

C’est l’argument pour traiter la découverte comme une phase distincte et payante, plutôt que comme un appel de courtoisie avant que le « vrai » travail ne commence. Un Sprint de cartographie de cinq jours, passé aux côtés de celles et ceux qui font le travail plutôt qu’à interroger les personnes qui les encadrent, produit un Registre des exceptions : chaque écart réel par rapport au processus documenté, consigné au moment précis et auprès de la personne précise où il se produit, plutôt que reconstitué de mémoire des semaines plus tard lors d’un atelier.

C’est ce registre qui fait d’un devis de développement à prix fixe un vrai chiffre, et non une supposition affublée de décimales. Cadrez un développement sur le processus documenté et le prix est fixé sur une fiction : le système rencontre l’exception non documentée dès le premier jour en production plutôt que pendant la découverte, exactement là où, selon la recherche citée plus haut, les dégâts sont les plus importants, parce que rien dans le développement n’y était préparé. Cadrez-le plutôt sur le Registre des exceptions, et le prix reflète le processus qui passera réellement par le système, pas la version qui tenait proprement sur un tableau blanc.

Le test pour savoir si vous en avez besoin

Tous les processus n’ont pas besoin d’un sprint de cinq jours. Le signal qui l’indique est simple : demandez à la personne responsable du processus ce qui se passe dans le cas qui ne rentre pas dans le schéma, et observez si la réponse est une règle documentée ou un haussement d’épaules suivi de « on s’en occupe, c’est tout ». Si la réponse honnête est la seconde, le processus documenté et le processus réel ont déjà divergé, et construire une automatisation avant de combler cet écart revient à découvrir la divergence en production, là où elle coûte cher à corriger plutôt que peu à consigner.

C’est aussi la raison pour laquelle, à ce stade, le risque repose sur nous plutôt que sur vous. Si le Sprint de cartographie ne fait rien apparaître que vous ne sachiez déjà, vous ne le payez pas. Ce n’est pas un argument marketing : c’est le véritable test de la valeur de la découverte, et c’est pourquoi le livrable compte plus que l’exercice. L’objectif n’est pas d’avoir fait de la découverte, c’est de repartir avec un registre que vous n’auriez pu produire d’aucune autre façon. Pour la place de ce registre dans le reste de la mission, voir comment acheter une mise en œuvre de l’IA qui aboutit vraiment, et pour ce à quoi ressemble le développement une fois le processus réellement connu, voir pourquoi la majeure partie du système qui en résulte ne devrait pas du tout être de l’IA.

À quoi ressemble concrètement une description écrite du processus réel : un Registre des exceptions et une Carte des frontières IA caviardés, issus du traitement des commandes d’un industriel, avec les informations du client masquées plutôt qu’inventées.

Sources & références