Automatisation des processus : le dossier pour choisir la bonne approche

Une direction demande « d’automatiser » le traitement des factures fournisseurs. Le prestataire propose un robot logiciel qui recopie les montants d’un écran à l’autre. Un éditeur suggère un module de lecture automatique des documents. L’équipe informatique rappelle que le logiciel comptable dispose d’une interface de programmation. Un consultant, enfin, fait remarquer que la moitié des factures pourraient être reçues sous forme électronique structurée, ce qui rendrait la lecture inutile. Quatre réponses, quatre budgets, quatre risques différents, et personne n’a encore regardé le processus lui-même.

L’automatisation des processus n’est pas une technologie mais une famille d’approches, qui conviennent à des situations différentes. Ce dossier les présente côte à côte, propose une démarche pour choisir, et traite ce qui fait réussir ou échouer un projet dans la durée : la place de l’humain, la mesure, l’exploitation.

Avant toute technologie : simplifier

Le premier réflexe devrait être de se demander si chaque étape est nécessaire. Un processus qui a grandi par ajouts successifs comporte presque toujours des contrôles redondants, des validations héritées d’une organisation disparue, des copies d’un même document dans trois systèmes. Automatiser ces étapes revient à les rendre plus rapides, et plus difficiles à supprimer ensuite.

Une cartographie honnête, faite avec les personnes qui exécutent le processus et non à partir de la procédure écrite, révèle généralement trois catégories d’étapes : celles qui apportent de la valeur ou répondent à une obligation, celles qui compensent un défaut en amont (une information manquante, un formulaire mal conçu), et celles que personne ne sait justifier. Les deuxièmes se corrigent à la source, les troisièmes se suppriment. C’est seulement sur ce qui reste que la question de l’outil se pose.

Automatiser un processus mal conçu, c’est produire plus vite les mêmes erreurs, avec moins de personnes pour les remarquer.

Six familles d’approches

Le moteur de workflow

Il orchestre les étapes d’un processus : qui reçoit quoi, dans quel ordre, avec quel délai, et ce qui se passe en cas d’absence ou de retard. Les règles sont décrites explicitement, souvent de façon graphique, et chaque instance du processus laisse une trace. C’est l’approche naturelle pour les circuits de validation, les demandes internes, les processus administratifs qui font intervenir plusieurs services. Sa limite : il structure le cheminement, mais ne lit pas les documents ni ne prend de décision à la place des personnes.

L’intégration par interfaces de programmation

Lorsque deux applications savent échanger des données par des interfaces documentées, la saisie manuelle de l’une vers l’autre peut disparaître. L’intégration est robuste, rapide et traçable. Elle suppose que les applications disposent de ces interfaces, que leurs éditeurs les maintiennent, et que quelqu’un gère les correspondances entre les données de chaque système. Pour les échanges entre organisations, les formats normalisés (facture électronique structurée, messages d’échange sectoriels) jouent le même rôle à plus grande échelle.

Les robots logiciels

L’automatisation robotisée des processus (RPA, pour robotic process automation) reproduit les gestes d’un utilisateur sur les écrans des applications : cliquer, copier, coller, valider. Elle permet de relier des applications anciennes sans les modifier, ce qui explique son succès. Elle est aussi fragile : un changement d’écran, une fenêtre inattendue, un délai de réponse plus long, et le robot s’arrête ou, pire, saisit au mauvais endroit. Elle demande une surveillance continue et des comptes techniques dont les droits doivent être contrôlés.

Le traitement automatique des documents

Reconnaissance de caractères, classification, extraction des informations utiles : ces techniques transforment un courrier, une facture, un formulaire scanné en données exploitables. Elles ont beaucoup progressé avec l’apprentissage automatique, au point de traiter des documents peu structurés. Leur taux de réussite n’est jamais total ; le processus doit donc prévoir une vérification humaine des cas douteux, et mesurer la part de documents qui y passent.

Les modèles de langage et les agents d’IA

Les modèles de langage savent lire un texte libre, en extraire une intention, rédiger une réponse, résumer un dossier, et, lorsqu’ils sont reliés à des outils, enchaîner des actions. Ils ouvrent à l’automatisation des tâches qui en étaient exclues, parce qu’elles reposaient sur la compréhension du langage. Ils introduisent aussi un risque nouveau : un résultat plausible mais faux, produit sans signal d’erreur. Leur usage dans un processus suppose des garde-fous explicites, présentés plus loin.

L’automatisation matérielle

Automates programmables, convoyeurs, robots de manutention, capteurs : dans l’industrie, la logistique ou les archives physiques, l’automatisation concerne aussi les gestes. Elle obéit à des contraintes propres, de sécurité des personnes, de maintenance et de continuité de production, et s’articule de plus en plus avec les systèmes d’information. Un même processus peut combiner les deux : un document reçu, enregistré, puis une boîte d’archives déplacée par un équipement automatisé.

Comparer les approches sur les mêmes questions

Ce tableau ne hiérarchise pas les approches. Il montre qu’elles répondent à des questions différentes, et qu’un même processus en combine souvent plusieurs : un workflow qui orchestre, une lecture automatique qui alimente, une interface qui transmet, un contrôle humain qui décide.

Quatre questions pour choisir

Les règles sont-elles stables et explicites ? Si l’on peut écrire, sans ambiguïté, ce qui doit se passer dans chaque cas, une approche déterministe (workflow, intégration, règles) est préférable. Elle est prévisible, testable et explicable. Si les cas sont trop variés pour être énumérés, l’apprentissage automatique ou les modèles de langage deviennent pertinents, avec le contrôle que cela implique.

Les données sont-elles structurées ? Des données déjà présentes dans une application, avec des champs définis, s’échangent par interface. Des documents papier ou des courriels libres passent d’abord par une étape de lecture. Avant d’investir dans cette lecture, il vaut la peine de se demander si l’on peut obtenir les données sous forme structurée à la source : un formulaire en ligne plutôt qu’un courrier, une facture électronique plutôt qu’un PDF.

Quelle part de jugement le processus comporte-t-il ? Certaines étapes appliquent une règle, d’autres demandent d’apprécier une situation. Les premières s’automatisent ; les secondes peuvent être préparées par l’automatisation (dossier complet, informations rassemblées, proposition argumentée) mais la décision reste humaine dès qu’elle engage une personne.

Que coûte une erreur ? Une erreur de routage d’un courrier interne se corrige vite ; une erreur dans le calcul d’une prestation sociale ou d’un remboursement de soins a des conséquences réelles. Plus le coût de l’erreur est élevé, plus l’approche doit être explicable, et plus le contrôle humain doit être fort.

Retour aux factures fournisseurs

Reprenons la situation du début, en appliquant ces questions au lieu de choisir entre les quatre propositions.

La cartographie montre d’abord que le circuit compte deux validations successives pour les petites factures, l’une par le service demandeur, l’autre par un responsable budgétaire qui signe sans vérifier, faute de temps. Une règle simple, un seuil en dessous duquel une seule validation suffit, supprime une étape avant toute technologie.

Elle montre ensuite que les factures arrivent par trois canaux : courrier papier, PDF par courriel, et, pour une part croissante, format électronique structuré envoyé par les plus gros fournisseurs. Pour ces dernières, aucune lecture n’est nécessaire : les données sont déjà là, il suffit de les intégrer au logiciel comptable par son interface. Pour les PDF et le papier, un traitement automatique des documents extrait les montants, les références de commande et les coordonnées du fournisseur, avec une vérification humaine lorsque le niveau de confiance est faible ou que la facture ne correspond à aucune commande.

Le circuit de validation lui-même relève d’un workflow : la facture rapprochée de sa commande est envoyée au bon valideur, avec relance et suppléance en cas d’absence. Le robot logiciel, finalement, n’a sa place qu’à un endroit : une application ancienne de gestion des marchés, sans interface, dont il faut extraire chaque soir les engagements. Il y est utile, à condition d’être surveillé, et son remplacement est inscrit dans la feuille de route du jour où l’application sera modernisée.

Quant à la décision de payer, elle reste humaine dans les cas qui sortent de la règle : écart de montant, fournisseur nouveau, coordonnées bancaires modifiées. Ce dernier cas mérite une attention particulière, car la modification frauduleuse de coordonnées bancaires est une escroquerie courante, que l’automatisation ne doit pas faciliter.

Le résultat n’est pas l’une des quatre propositions initiales, mais une combinaison de cinq approches, chacune à sa place, précédée d’une simplification qui ne coûtait rien.

Une démarche en six temps

1. Cartographier le processus réelAvec ceux qui l’exécutent : étapes, acteurs, systèmes, documents, délais, exceptions. Mesurer les volumes et le temps passé, même grossièrement.
2. SimplifierSupprimer les étapes injustifiées, corriger à la source les défauts compensés en aval, réduire les pièces demandées. Valider le processus cible avec les responsables métier.
3. Découper et choisirPour chaque étape restante, appliquer les quatre questions et retenir l’approche adaptée. Identifier les décisions qui resteront humaines.
4. Mener un pilote bornéUn périmètre limité, des indicateurs fixés avant de commencer, un critère d’arrêt écrit. Le pilote se juge sur des données réelles, pas sur une démonstration.
5. IndustrialiserSurveillance, gestion des exceptions, documentation, comptes techniques, procédure de reprise manuelle si l’automatisation s’arrête.
6. Réexaminer régulièrementLes règles changent, les applications évoluent, les volumes aussi. Une automatisation qui n’est jamais revue finit par appliquer une règle que plus personne ne connaît.

Garder l’humain sur les décisions

La formule est courante ; elle mérite d’être traduite en dispositions concrètes. Dans un processus automatisé, l’humain intervient à trois endroits : pour traiter les exceptions que la machine signale, pour valider les décisions qui engagent une personne, et pour contrôler, par sondage, que les cas traités automatiquement le sont correctement. Chacun de ces rôles demande du temps, des compétences et des outils : une file d’exceptions lisible, un dossier complet au moment de décider, un échantillon tiré au hasard plutôt que choisi.

Le cadre juridique va dans le même sens. Le règlement général sur la protection des données encadre les décisions fondées exclusivement sur un traitement automatisé lorsqu’elles produisent des effets juridiques ou affectent de manière significative une personne. Le règlement européen sur l’intelligence artificielle, entré en vigueur le 1er août 2024, interdit certaines pratiques depuis le 2 février 2025 et prévoit, pour les systèmes classés à haut risque (accès à des services publics essentiels, emploi, évaluation de solvabilité notamment), des obligations de contrôle humain, de documentation et de journalisation dont la majorité s’appliquera à partir d’août 2026.

Mesurer ce qui compte

Le premier indicateur cité est souvent le temps de travail économisé. Il est utile, mais trompeur s’il est isolé : une automatisation peut faire gagner du temps de saisie tout en allongeant le délai global, parce que les exceptions s’accumulent dans une file que personne ne traite.

Quatre indicateurs donnent une image plus juste. Le délai de bout en bout, du dépôt de la demande à la réponse, tel que le perçoit l’usager ou le client. Le taux de traitement sans intervention, qui montre la part réellement automatisée. Le taux de reprise manuelle, c’est-à-dire les cas que l’automatisation a traités mais qu’il a fallu corriger. Et le taux d’erreur détecté a posteriori, par les contrôles par sondage ou les réclamations. Ces quatre mesures se fixent avant le pilote, sur la situation existante, pour pouvoir comparer.

Ce que coûte réellement une automatisation

Le budget d’un projet d’automatisation se concentre souvent sur l’outil et sa mise en place. Les coûts récurrents sont moins visibles : licences ou consommation, surveillance, correction des échecs, adaptation aux évolutions des applications, contrôle par sondage, formation des nouveaux arrivants. Pour les robots logiciels, la maintenance peut représenter une part importante du coût total, parce que chaque modification d’une application source oblige à les reprendre. Pour les modèles de langage facturés à l’usage, la dépense suit les volumes et doit être suivie comme toute consommation. Un calcul de retour honnête intègre ces postes sur plusieurs années, et les compare au coût d’une simplification ou d’une intégration plus robuste.

Exploiter dans la durée

Les automatisations ont un cycle de vie. Elles naissent dans un projet, puis doivent être surveillées, corrigées, adaptées aux évolutions des applications et des règles. C’est à ce moment que beaucoup d’initiatives se dégradent : le prestataire est parti, la personne qui avait conçu le robot a changé de poste, et une automatisation critique tourne sans que personne ne sache exactement ce qu’elle fait.

Quelques dispositions évitent cette dérive. Un inventaire des automatisations, avec pour chacune un responsable métier, un responsable technique et une documentation à jour. Une surveillance des échecs, avec des alertes qui arrivent à quelqu’un. Des comptes techniques dédiés, aux droits limités au strict nécessaire, et dont les accès sont revus. Une procédure de reprise manuelle, testée, pour le jour où l’automatisation s’arrête. Et une journalisation qui permet de répondre, des mois plus tard, à la question : qui, ou quoi, a fait cette opération ?

Cette dernière exigence prend une importance croissante. Lorsqu’une partie des opérations est faite par des robots ou des modèles, la traçabilité ne peut plus reposer sur la mémoire des agents. Elle doit être conçue dès le départ, dans les outils.

Les erreurs les plus fréquentes

Choisir l’outil avant d’avoir regardé le processus. L’outil est souvent acheté pour un premier projet, puis utilisé pour tout, y compris là où il ne convient pas.

Automatiser le cas général et oublier les exceptions. Les exceptions représentent parfois une part modeste des volumes et la majorité du temps de traitement. Si elles ne sont pas prévues, elles reviennent aux agents, sans les informations nécessaires.

Confondre démonstration et production. Une démonstration sur dix documents bien choisis ne dit rien de la performance sur dix mille documents réels. Seul un pilote sur données réelles permet de juger.

Laisser les agents en dehors du projet. Ce sont eux qui connaissent les exceptions, les contournements, les raisons cachées de certaines étapes. Les associer dès la cartographie améliore le résultat et l’adhésion.

Promettre des suppressions de postes. Annoncer l’automatisation comme une réduction d’effectifs garantit la méfiance des personnes dont le savoir est indispensable au projet. Les gains de temps se réaffectent utilement : accueil, traitement des cas complexes, contrôle.

Par où commencer

Le premier pas est modeste : choisir un processus fréquent, aux règles stables, dont l’erreur coûte peu, et le cartographier avec ceux qui l’exécutent. Cette cartographie produit à elle seule des gains, par la simplification, et donne les éléments pour choisir l’approche sans parti pris technologique.

Notre expertise automatisation des processus suit cette démarche, de la cartographie à l’exploitation, pour l’automatisation logicielle comme matérielle. Lorsque le processus est d’abord documentaire (courrier, factures, dossiers), notre solution GedFlow associe gestion des documents, circuits de traitement et traçabilité. Et pour identifier les processus qui méritent d’être traités en premier, le Diagnostic Anti-Friction part des frictions observées sur le terrain.

Questions fréquentes

Par quel processus commencer ?

Par un processus fréquent, aux règles stables, dont les données sont déjà numériques et dont l'erreur coûte peu. Il permet de mesurer un gain réel et de rôder l'organisation avant de s'attaquer à des processus plus sensibles.

Les robots logiciels (RPA) sont-ils une bonne solution durable ?

Ils sont utiles lorsqu'aucune interface de programmation n'existe et qu'il faut relier rapidement des applications anciennes. Ils restent fragiles : une modification de l'écran de l'application source peut les arrêter. On les considère donc souvent comme une solution transitoire, à remplacer par une intégration plus robuste lorsque c'est possible.

L'IA générative peut-elle automatiser un processus entier ?

Elle peut prendre en charge des tâches que l'automatisation classique ne savait pas traiter : lire un courrier libre, résumer un dossier, proposer une réponse. Pour un processus entier, elle doit être encadrée : règles explicites pour les étapes déterministes, contrôle humain pour les décisions, journalisation de ce que le modèle a produit.

Faut-il une équipe dédiée à l'automatisation ?

Au-delà de quelques automatisations, oui : quelqu'un doit tenir l'inventaire, surveiller les échecs, gérer les comptes techniques et arbitrer les priorités. Sans cette fonction, les automatisations deviennent des boîtes noires que personne n'ose modifier.