L’automatisation des flux documentaires est l’orchestration des étapes que traverse un document après sa capture, notamment l’orientation, l’approbation, la gestion des exceptions et la livraison vers un système d’enregistrement, la séquence étant imposée par le logiciel et non par les personnes.
Automatiser signifie ici que le processus avance de lui-même. Une personne peut encore prendre des décisions, mais personne n’est responsable de se souvenir de l’étape suivante ni de faire passer le travail d’un poste à l’autre.
Les composants
L’orientation détermine où va un document, en fonction de sa nature et des données qui en ont été extraites. Une facture sous un certain seuil peut être comptabilisée directement ; une facture au-dessus de ce seuil peut nécessiter une approbation ; une facture provenant d’un fournisseur non reconnu peut d’abord exiger son intégration comme fournisseur. Les décisions d’orientation supposent que la classification documentaire et l’extraction de données documentaires ont déjà été effectuées.
Les approbations enregistrent une décision prise par une personne habilitée. Les questions de conception sont les suivantes : qui approuve quoi, l’autorité varie-t-elle selon le montant ou le type, que se passe-t-il quand un approbateur est indisponible, et l’approbation peut-elle être déléguée.
La gestion des exceptions couvre tout ce qui ne peut pas avancer automatiquement : un score de confiance de l’extraction sous le seuil, un échec de validation, une référence qui ne se résout pas, un document qui n’aurait pas dû être envoyé. Les exceptions ne sont pas des cas marginaux : elles représentent une part permanente et significative du volume et méritent autant d’attention de conception que le scénario nominal.
L’escalade fait avancer le travail lorsqu’il stagne. Une étape sans échéance de réalisation devient une file d’attente sans fin, et la cause habituelle d’un processus lent n’est pas un travail lent, mais un travail qui attend une personne qui ignore qu’elle est attendue.
Orchestration de type BPMN
Business Process Model and Notation (BPMN) est une norme qui permet de décrire les processus sous forme de diagrammes à la fois lisibles par un humain et exécutables par une machine. Son intérêt est que le diagramme constitue l’implémentation elle-même : le processus dessiné par un analyste métier est celui qui s’exécute réellement.
Les concepts qui comptent dans le traitement documentaire sont les flux de séquence, les passerelles pour les embranchements, les chemins parallèles pour les étapes pouvant s’exécuter simultanément, les événements temporisés pour les échéances et l’escalade, et la compensation pour annuler un travail partiellement accompli lorsqu’une étape ultérieure échoue.
L’avantage d’un modèle explicite est que le processus peut être analysé, versionné et audité. Le risque est la sur-modélisation : un diagramme qui capture chaque variante concevable devient impossible à maintenir, et ces variantes relèvent généralement de la configuration ou d’un chemin d’exception plutôt que de branches supplémentaires.
Tous les processus n’ont pas besoin de BPMN. Une validation en deux étapes s’exprime mieux comme une validation en deux étapes. La norme justifie sa complexité lorsqu’un processus comporte réellement des embranchements, du parallélisme et des échéances.
Taux de traitement sans intervention
L’indicateur qui compte est le taux de traitement sans intervention : la proportion de documents qui achèvent l’ensemble du processus sans aucune intervention humaine.
C’est la bonne mesure, car elle traduit le bénéfice réel : le temps humain non consommé. Les indicateurs partiels induisent en erreur. Une précision d’extraction de 95 % semble excellente, mais si les 5 % restants atterrissent dans une file d’attente qui prend quatre minutes par document, le gain de main-d’œuvre est plus faible que ne le laisse penser le chiffre de précision.
Deux ajustements le rendent réellement utile en pratique. Le mesurer par type de document, car un taux global masque les types qui ne s’automatisent jamais. Et le rapprocher du coût en temps des exceptions, car un système à 70 % avec une revue rapide peut surpasser un système à 85 % avec une file d’attente lente.
Améliorer ce taux repose sur deux leviers : une meilleure extraction et validation pour réduire le nombre de documents rejetés, et l’abaissement des seuils de confiance pour réduire le nombre de documents retenus pour revue. Le second levier ne coûte rien mais augmente le taux d’erreur, ce qui explique pourquoi les seuils doivent être fixés en fonction du coût des erreurs, et non ajustés pour améliorer artificiellement l’indicateur.
Les erreurs courantes
La file d’exceptions est pensée en dernier. Elle est conçue en dernier, reçoit le moins d’attention, et devient l’endroit où le processus consomme le plus d’effort humain.
Aucune étape n’a de responsable. Le travail orienté vers un groupe sans personne individuellement responsable reste en attente jusqu’à ce que quelqu’un s’en charge.
Le processus est automatisé tel quel. Reproduire un processus manuel existant étape par étape conserve des approbations qui existaient parce que l’information était indisponible, et non parce que le contrôle était nécessaire. Réexaminer quelles étapes restent justifiées est généralement la source des gains les plus importants.
Les reprises sont invisibles. Un document traité après trois corrections compte comme traité, et ces corrections n’apparaissent dans aucun indicateur. Suivre le nombre d’interventions par document permet de révéler ce phénomène.
Le succès se mesure en volume. Le nombre de documents traités par heure augmente quand une file est survolée plutôt qu’examinée. Rapprocher le débit du taux d’erreur en aval évite de récompenser cette dérive.
Contellect One orchestre ces étapes dans le cadre de l’automatisation intelligente des processus.
